- Name and Description
- Displays the name of the Provisioning Server and a brief description. The maximum length for the server name is 15 characters. Do not enter FQDN for the server name.
- Power Rating
A power rating is assigned to each server, which is then used when determining which server is least busy. The scale to use is defined by the administrator.
For example, an administrator may decide to rate all servers on a scale of 1 to 10, or on a scale of 100 to 1000. Using the scale of 1 to 10, a server with a rating of 2 is considered twice as powerful as a server with a rating of 1; therefore it would be assigned twice as many target devices. Likewise, when using a scale of 100 to 1000, a server with a power rating of 200 is considered twice as powerful as a server with the rating of 100; therefore it would also be assigned twice as many target devices.
Using the default setting of 1.0 for all servers results in even device loading across servers. In this case, the load balancing algorithm does not account for individual server power.
Ratings can range between 0.1-1000.0; 1.0 is the default.
- Log events to the server's Window Event Log
- Select this option if you want this Provisioning Server's events to be logged in the Windows Event log.
- Advanced Server Properties
- Server tab
Threads per port — Number of threads in the thread pool that service UDP packets received on a given UDP port. Between four and eight are reasonable settings. Larger numbers of threads allow more target device requests to be processed simultaneously, but is consumes more system resources.
Buffers per thread — Number of packet buffers allocated for every thread in a thread pool. The number of buffers per thread should be large enough to enable a single thread to read one IO transaction from a target device. So buffers per threads should ideally be set to (IOBurstSize / MaximumTransmissionUnit) + 1). Setting the value too large consumes extra memory, but does not hurt efficiency. Setting the value too small consumes less RAM, but detrimentally affects efficiency.
Server cache timeout — Every server writes status information periodically to the Provisioning Services database. This status information is time-stamped on every write. A server is considered ‘Up’ by other servers in the farm, if the status information in the database is newer than the Server cache timeout seconds. Every server in the farm will attempt to write its status information every (Server cache timeout/2) seconds, i.e. at twice the timeout rate. A shorter server cache timeout value allows servers to detect offline servers more quickly, at the cost of extra database processing. A longer Server cache timeout period reduces database load at the cost of a longer period to detect lost servers.
Local and Remote Concurrent I/O limits — Controls the number of concurrent outstanding I/O transactions that can be sent to a given storage device. A storage device is defined as either a local drive letter (C: or D: for example) or as the base of a UNC path, for example \\ServerName.
Since the PVS service is a highly multi-threaded service, it is possible for it to send hundreds of simultaneous I/O requests to a given storage device. These are usually queued up by the device and processed when time permits. Some storage devices, Windows Network Shares most notably, do not deal with this large number of concurrent requests well. They can drop connections, or take unrealistically long to process transactions in certain circumstances. By throttling the concurrent I/O transactions in the PVS Service, better performance can be achieved with these types of devices.
Local device is defined as any device starting with a drive letter. Remote is defined as any device starting with a UNC server name. This a simple way to achieve separate limits for network shares and for local drives.
If you have a slow machine providing a network share, or slow drives on the machine, then a count of 1 to 3 for the remote limit may be necessary to achieve the best performance with the share. If you are going to fast local drives, you might be able to set the local count fairly high. Only empirical testing would provide you with the optimum setting for a given hardware environment. Setting either count to 0 disables the feature and allows the PVS Service to run without limits. This might be desirable on very fast local drives.
If a network share is overloaded, you’ll see a lot more device retries and reconnections during boot storms. This is caused by read/write and open file times > 60 seconds. Throttling the concurrent I/O transactions on the share reduces these types of problems considerably.
Maximum transmission unit — Number of bytes that fit in a single UDP packet. For standard Ethernet, the default value is correct. If you are attempting to operate over a WAN, then a smaller value may be needed to prevent IP fragmentation. Provisioning Services currently does not support IP fragmentation and reassembly. Also, if you are using a device or software layer that adds bytes to every packet (for security reasons for example), a smaller value may be needed. If your entire infrastructure supports jumbo packets (Provisioning Services NIC, target device NIC and any intervening switches and/or routers) then you can set the MTU to 50 bytes less than your jumbo packet max size to achieve much higher network throughput.
I/O burst size — The number of bytes that will be transmitted in a single read/write transaction before an ACK is sent from the server or device. The larger the IO burst, the faster the throughput to an individual device, but the more stress placed on the server and network infrastructure. Also, larger IO Bursts increase the likelihood of lost packets and costly retries. Smaller IO bursts reduce single client network throughput, but also reduce server load. Smaller IO bursts also reduce the likelihood of retries. IO Burst Size / MTU size must be <= 32, i.e. only 32 packets can be in a single IO burst before a ACK is needed.
Socket communications — Enable non-blocking I/O for network communications.
Boot pause seconds — The amount of time that the device will be told to pause if the Maximum devices booting limit has been reached. The device will display a message to the user and then wait Boot pause seconds before attempting to continue to boot. The device will continue to check with the server every Boot pause seconds until the server allows the device to boot.
Maximum boot time — The amount of time a device will be considered in the booting state. Once a device starts to boot, the device will be considered booting until the Maximum boot time has elapsed for that device. After this period, it will no longer be considered booting (as far as boot pacing is concerned) even if the device has not actually finished booting. Maximum boot time can be thought of as a time limit per device for the booting state for boot pacing.
Maximum devices booting — The maximum number of devices a server allows to boot at one time before pausing new booting devices. The number of booting devices must drop below this limit before the server will allow more devices to boot.
vDisk creation pacing — Amount of pacing delay to introduce when creating a vDisk on this Provisioning Server. Larger values increase the vDisk creation time, but reduce Provisioning Server overhead to allow target devices that are running, to continue to run efficiently.
License timeout — Amount of time since last hearing from a target device to hold a license before releasing it for use by another target device. If a target device shuts down abnormally (loses power for example) its license is held for this long.