vDisk Replication - When manually copying a vDisk, you should always ensure that the vDisk is in standard image mode to ensure that the vDisk is read only. Otherwise, users may not be able to access the vDisk. For example, only one user will be able to connect to a vDisk that is copied while in private image mode without verifying that the file locks have been released, even if the vDisk is configured for standard image mode

PXE and Stream Services - If either the PXE or Stream services are not functioning properly, target devices will not be able to access the Provisioning Services host and will not be able to start. Target devices might also appear to stall during the start process

IP Address Allocation - Each target device that turns on from a Provisioning Services vDisk must be assigned an IP address from a pool of available IP addresses. If an IP address is not available, the target device will be unable to be turned on. Therefore, it is critical that you ensure that enough IP addresses are constantly available in the pool to cover all target devices that require one

Hardware Compatibility - The following target device hardware components must be consistent with an assigned vDisk to ensure that the target device operating system has all required drivers:
• Motherboard manufacturer and batch number
• Network card
• Video card
If target device hardware is changed or upgraded and no longer matches the assigned vDisk, the target device will encounter a blue screen error when the target device is turned on from the vDisk

Write Cache Size - All changes made while a target device is connected to a standard image mode vDisk are stored in the write cache. It is important that you allocate enough cache size to accommodate the data stored in the write cache while a target device is connected, in order to maintain performance. If the write cache has exceeded its limit, target devices that use that write-cache location might encounter a blue screen error

Provisioning Services Farm Membership - Issues with farm membership can result from lack of response from SQL Server services. During clean installations or upgrades, SQL Server services must be running and remote connections must be enabled on the SQL Server.

Daylight Savings Time or Summer Time - If Daylight Savings Time (DST) or Summer Time is observed by your
network, the change in time twice each year will affect your network. When a vDisk is created, the registry stores the time information representative of the current date. When Daylight Savings Time (DST) goes into effect or reverts to Standard Time in the local time zone, the original time setting in the registry of the vDisk is invalid. This time difference saved in the registry creates problems in Provisioning Services with Kerberos authentication for a target device that is assigned to one of these vDisks. The target device event log then records an event that it attempted to establish a Kerberos session but failed due to a time difference from the domain control server. The target device tries to apply Group Policies from the domain controller and fails due to the time difference. The target device then synchronizes the time but does not apply the Group Policy until the next cycle. If this configuration is off by more than one hour time difference, it impacts all streamed targets. Group Policies will not be applied to the target device until the target device properly synchronizes its time with the domain controller and a Kerberos session is established, which typically takes up to 90 minutes.
To avoid this scenario, a Windows service that executes the gpupdate /force command at system start up can be created and be made to run on the LocalSystem account. For more information about Daylight Saving Time Environment risks and potential fixes, see Citrix article Best Practices - Provisioning Services - CTX127549
Note: This issue does not apply for environments that are located in locations that do not observe Daylight Savings Time or environments that do not configure Group Policy Objects.