Error: "Max Number of DHCP Retries Exceeded" when

Provisioning Services Target Devices are Unable to Boot from

PXE
Symptoms or Error
Provisioning Services (PVS) target devices are unable to boot from PXE with an error:

"Max number of DHCP retries exceeded"

This failure occurs very early in the boot process when the PXE client sends a Discover packet to the broadcast
domain to find a DHCP server.

Solution
To resolve this issue, enable IP Helper/DHCP Relay on the physical router(s) that divide(s) the subnets between the
PVS targets and the DHCP server designated to provide IP addresses.

Note: Depending on the type, brand, and model of your router, you might have to contact your vendor or visit their
Knowledge Base to get instructions on enabling IP Helper/DHCP Relay.

Problem Cause
The observed cause of this issue is the inability of the router to pass the PXE broadcast to other subnets in order for
the target device to discover a DHCP server that is on a different subnet and acquire an IP address.

Provisioning Services Console Error is Displayed During KMS

Activation

Symptoms or Error
When changing a virtual disk (vDisk) in private mode to KMS activation and then changing the mode to standard
image mode or changing the activation procedure to KMS for a vDisk in standard image mode, the following error
message appears, which can be seen in the console.log (when in debug level) or in the console popup:

Failed to map vDisk, no Driver

Solution
To resolve this issue:

Use a domain user account, which can be added as a local administrator to the Provisioning Server and then run the
Provisioning Server Configuration wizard to reconfigure the access of the user on the Database.

Or

Assign user the right for managing the Network Service account to perform volume maintenance tasks by completing
the following procedure:

1.

Open local security policy using gpedit.msc.

2.

Browse to Windows Settings > Security Settings > Local Policies > User Rights
Assignment > Perform volume maintenance tasks.

3.

Double-click on Perform volume maintenance tasks and add NETWORK SERVICE.

Note: For this resolution, there can be security concerns since network service account is used in other services
other than SOAP Service.

Problem Cause
The error occurs only when the SOAPServer.exe or Citrix SOAP Service is running with NT AUTHORITY\Network
Service account. The console passes a request to prepare the vDisk for KMS, which requires the SOAP service to

update the vDisk file system and registry entries. This update requires the vDisk to be mounted. The Network Service
account does not have SE_MANAGE_VOLUME_NAME privilege which causes an access is denied error when it
tries to mount the vDisk.

Provisioning Services Target Devices Boot Slow in ESX 5.x

Symptoms or Error
Provisioning Services (PVS) Target Devices in VMware ESX boot intermittently slow after upgrading the ESX hosts
5.x.

Background
This symptom appears randomly. It might happen on a single VM boot or five out of ten might boot as expected and
the remaining five might boot anywhere from 5 to 60 minutes later. When the Target Device is up and streaming
performance appears to normalize, the networking heap memory on the ESX host might show unusually lower than
expected in the host logs during provisioned guest boot(s).

Solution
Confirm the behavior with VMware and use the following command to disable the NetQueue feature on the ESX
hosts:
esxcli system settings kernel set -s netNetqueueEnabled -v FALSE

Problem Cause
NetQueue enabled on the ESX host has shown a significant increase in boot times of Provisioned Target Devices.
While the operating system is streaming to the Target Device during single IO burst phase, (approx. 300-400MB per
Device) a network trace will show at least 5-second gap between the PVS Server reply to a single Read disk IO
Request and the Target Devices next request. These gaps, over time, account for the excess time to boot

Write Cache Set to Provisioning Services Target Device Falls

Back to Server
Symptoms or Error
Write cache set to Provisioning Services (PVS) target device falls back to Server when the combination of the
following is applied:

HP ProLiant DL385 Generation 5 or 6

Controller: P800 or P410

Windows 2008

PVS Target device side debug log can be similar to the following:

DEBUG [TargetDeviceName: [wcHD Worker] Attempting to init HD cache.]

DEBUG [TargetDeviceName: [wcHD] Searching for local HDs qualified for

write cache usage]

DEBUG [TargetDeviceName: WcLocateCacheDrive: SCSI interface not

available]

DEBUG [TargetDeviceName: HD is not ready to init local write cache after

150 retries with 100 ms interval; Try to switch to server-side cache.]

Solution
Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

To resolve this issue, complete the following steps:

1.

Validate the write cache disk is formatted with NTFS.

Partition created is using MBR and not GPT disk partitioning (PVS does not support GPT). Ensure that the
minimum amount of free space on the local drive is 500MB. In case multiple drives are attached on the target,
remove the drives to validate the behavior is still occurring.

2.

For Windows 2012 targets devices, update the registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNIStack\parameters

DWORD WcHDInitRetryNumber: default 150, up to 200

DWORD WcHDInitRetryIntervalMs: default 100ms, up to 500ms

Problem Cause
Following are some scenarios that cause the cache to redirect to the PVS server:

Improper formatting of the write cache drive.

Drive not meeting the minimum required size.

Windows 2012 target devices appear to take a longer time to initialize the disk and bnistack.

Target Device Login Request Timed Out

Solution
Complete the following steps to fix the issue:

1.

Open the Provisioning Service console.

2.

Click the Servers folder.

3.

Right-click the Provisioning Server.

4.

Click Properties > Configure bootstrap.

5.

In the Options tab, the recommended Login Timeouts options are:

Login polling timeout = 5000 (5 seconds)

Login general timeout = 30000 (30 seconds)

Ensure that the recommended Timeout settings are retained.

Note: Do not modify the timeout.

Best Practice for Setting the Citrix Profile Manager Cache File
for Provisioning Services Server
Complete the following steps to fix the issue:
1.

Set your PVS Server to Private Mode.

2.

After you have logged on to the server in private mode, access the following:
32-bit: C:\Program Files\Citrix\User Profile Manager\
64-bit: C:\Program Files x86\Citrix\User Profile Manager\
A cache file will be available within the User Profile Manager folder.
Note: This file retains information sent over from the ADM template pushed down through the group policy.

3.

To have a clean master image:

a.

Stop User Profile Manager Service

b.

Delete the cache file on the master image

Shut down the server.

Configure the vDisk in Standard mode.

Each target device will recreate the cache file when the server restarts and the Change Journal's Journal ID is
updated.

Note: Citrix Profile Manager 5.0 does not use a cache file.

How to Enable HTML5 Connections to Provisioning Services

Based Catalogs
Enabling connections from Receiver for HTML5 to desktops deployed using Provisioning Services.

Background
Enabling connections from Receiver for HTML5 to desktops in Provisioning Services (PVS) based catalogs might
require additional steps to complete depending on the persistence of the write cache mode used for the vDisk.

The required policies to enable HTML5 connections can be configured using either Citrix Studio, with policy rules
saved in the XenDesktop site database, or the Group Policy Management Console, with policy rules saved in Active
Directory.

After applying the WebSockets connections policy to a worker, the machine must be restarted before it becomes
effective and will listen for and accept HTML5 connections on the specified port (default is 8008). Because of the nonpersistent nature that PVS based catalogs are generally deployed with, this policy must be part of the base image or
it will not be effective and connections from Receiver for HTML5 will fail.

Instructions
1.

Deploy a PVS based catalog and delivery group you want to enable HTML5 connections for.

2.

Enable the WebSockets connections policy required for HTML5 connections and optionally
the WebSockets port number andWebSockets trusted origin server list policies either through Citrix Studio or
through Active Directory so they apply to your PVS catalog.

3.

Shutdown a worker that is part of the catalog/delivery group.

3.

Using the PVS console, change the device type of the shutdown worker from Production to Maintenance:

5.

In the PVS console, create a new version of your vDisk and leave it in Maintenance mode:

6.

Boot the worker, select the maintenance vDisk version from the Boot Menu:

7.

Verify the following policies are in place in the registry:

Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

HKLM\Software\Policies\Citrix\ICAPolicies\AcceptWebSocketsConnections

HKLM\Software\Policies\Citrix\ICAPolicies\WebSocketsPort

HKLM\Software\Policies\Citrix\ICAPolicies\WSTrustedOriginServerList

Note: You must do this with a worker that is part of the catalog/delivery group or the policies will not be applied.

1.

Shutdown the worker.

2.

Change the workers type back to Production.

3.

Promote the new vDisk version to Production:

4.

Boot up your worker and reboot any workers currently running from the existing vDisk.

Additional Resources
If you do not utilize PVS vDisk versioning, it is possible to apply the policy in your base vDisk image by shutting down
all workers utilizing the vDisk and then placing the vDisk in Private mode in order to boot the worker and update the
image.

Note: Catalogs deployed with MCS do not require these additional steps as policies are cached on the workers
identity disk.

PVS catalogs that utilize a persistent write back cache modes such as Cache on device hard drive
persisted and Cache on server persisted also do not require these additional steps to implement HTML5
connections.

How to Use Multiple Activation Key (MAK) Activation with

Automatic Updates

Objective
This article describes how to use Multiple Activation Key (MAK) Activation with Automatic Updates.

Note: For Provisioning Server 6.x environment, using vDisk versioning is another alternative to update MAK-enabled
image.

Requirements

Knowledge of Provisioning Services and Microsoft Licensing

Knowledge of Automatic Updates

Volume Activation Management Tool (VAMT) 2.0 Tool

Prerequisites

Ensure that MAK activation is successful for multiple target devices. (Login to Target Devices > Properties >
check Windows Activation).

Restart these devices and ensure that reactivation is successful.

Assuming that the vDisk is set to standard image mode at this time.

Instructions
Complete the following set of procedures:

Preparing vDisk
1.

In the vDisks properties, navigate to the Auto Update tab.

2.

Select Enable automatic updates for this vDisk.

3.

Select Apply vDisk updates as soon as they are detected by the server. This allows the user to update
on demand. The other option allows the user to schedule the update.

4.

Enter the Class and type the same unique string. This string should be identical to the class properties in the
device properties of all the target devices that are getting the updated vDisk.

Copying vDisk
1.

On the Provisioning Services (PVS) server, open Windows Explorer.

2.

Navigate to the directory where the vDisks are stored.

3.

Copy both vDisk (.vhd) and Properties file (.pvp) files and paste where the original vDisk is located.

4.

Rename these two files with appropriate name.

Note: vDisk and .pvp file names have to be identical.

Adding Copied vDisk to Provisioning Services Database

1.

In the PVS console, right-click Store and choose Add Existing vDisk.

2.

Click Search and select the copied vDisk.

3.

Click Add to add the vDisk to the PVS database.

Switching Copied vDisk to Private Mode

1.

Open vDisk properties of the copied vDisk.

2.

In the General tab, change the access mode to Private Image.

3.

In the Auto Update tab, update increment Major #, Minor #, or Build # to signify that copied vDisk is the
updated vDisk.

Updating the Copied vDisk

1.

Create a new Virtual Machine (VM) to be used for updating the vDisk.

2.

Create a new device record from PVS console with a unique name.

3.

Type the MAC address of the VM and set it to start from vDisk.

4.

In the vDisks tab of new device, add the copied vDisk.

5.

Start the VM and update the copied vDisk.

6.

Shutdown the device after completing the update.

7.

Change the copied vDisk properties to Standard Image mode. Change the cache type to the cache type of
original vDisk.

Running Auto Update

1.

Open PVS console > Servers > PVS server.

2.

Right-click and select Check for Automatic Updates.

3.

Access the device location where all the target devices are located.

4.

Right-click and select Refresh.

5.

For Target devices, which are started from the original vDisk, take the updated vDisk from next restart.

6.

For Target devices, which are down, replace the updated vDisk with original vDisk.

Verifying MAK Reactivation

1.

Start the target devices.

2.

Right-click My Computer and select Properties.

3.

Activate Windows in the Windows Activation section.

If Windows is not activated, the following message is displayed:

"3 days until automatic activation. Activate Windows now."

That is, Windows has received all the necessary information required for activation, but Windows is delaying
activation.

Force Windows to activate immediately by completing the following procedure:

1.

Open a command prompt with elevated administrator privilege.

2.

Run the command slmgr ato with no quotes.

3.

When the command is successfully executed, right-click My Computer and select Properties.

4.

Verify that Windows is activated by checking Windows activation, which displays that Windows is
activated.

Desktops Do Not Register using XenDesktop and

Provisioning Server
Symptoms or Error
When using XenDesktop with Provisioning Service, the desktops do not register.
Note: XenDesktop might try starting all the machines in your desktop group on the VDA Event Viewer:

Under Application:
Desktop Service - Failed to start WCF services. Exception Log on Failure due to unknown user name or bad
password of type System.Securiy.Authentication.AuthenticationException

Under System:
Winlogon - Could Not authenticate with \\domain\domaincontroller>, a Windows domain controller for domain
XXXXX, and therefore this computer might deny log on requests.

Solution
Complete the following steps to fix the issue:

1.

Open vDisk > File Properties > Options.

2.

Ensure to select the Enable Active Directory machine account password management option, as shown
in the following screen shot.

3.

From the Provisioning Services Console, right-click on all machines having the issue.

4.

Select Active Directory.

5.

Select Delete Machine Account, as shown in the following screen shot.

6.

Right-click on Devices.

7.

Select Active Directory.

8.

Select Create Machine Account, as shown in the following screen shot.

9.

Open the Delivery Services console on the Desktop Delivery Controller (DDC). You have to recreate the
desktop group or Catalog and add the machine accounts again.

Problem Cause
The machine account cannot establish a secure channel with the domain and this might be because a password
reset of the machine has failed.

How to Capture a Memory Dump from a Provisioned Target in

VMware Environment
Objective
This article outlines the process to generate a memory dump file from a provisioned target device in a VMware
environment. Click the link VMware tool (vmss2core.exe) to download. There are no prerequisites to using this tool.
This is mainly a three-step process of which neither steps require any modification to the virtual machine.

Note: This tool is backward compatible and works with VMware workstation and ESX 3.5.

Instructions
Complete the following procedure to capture memory dump:

1.

After the provisioned target virtual machine is in an unresponsive state, proceed to suspend the virtual
machine.

Note: Suspending a virtual machine writes the state to a file with a .vmss extension. By default, the .vmss file is
stored in the directory in which the virtual machine configuration files (.vmx) are stored.

2.

Copy the .vmss file from the datastore to a local disk.

The size of the .vmss file is equivalent to the total memory assigned to the virtual machine.

Note: File should be compressed before uploading to FTP site.

The utility to convert the file from .vmss file to a dump file format is located in the <Program
Files>\VMware\VMware Workstationfolder on the device that VMware workstation 7 is installed.

3.

Run the following command to begin the conversion process:

vmss2core W filename.vmss

Note: Command is case sensitive.