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.xSymptoms 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 Server’s 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 ServerComplete 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 non-

persistent 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.

4. 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 worker’s

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.