HowTo: One vDisk, Multiple Environments and Force GPUPDATE at Startup

This post is intended to solve two challenges:

1. I have a vDisk I need to use in multiple Citrix environments (different Delivery Controllers) and do not require customization of apps between environments (apps configured to go to different backends, etc.). I do not want to have to maintain one vDisk per environment just to change VDA registration params.
2. I want to ensure that on startup, my target devices refresh their GPO computer policies, as we generally can’t rely on AD to refresh GPOs immediately on boot-up.

1 and 2 go hand in hand for reliable application of VDA registration settings. VDA registration can be applied in a 7.x environment in numerous ways; directly on the VDA configuration within the image, via ListOfDDCs registry params, HDX policies (in studio or AD GPO), etc. When dealing with single environment platforms, I typically just configure the VDAs with their Delivery Controllers locally within the image. If there are multiple environments (NonProd, DR, Prod, etc) that can leverage the same image and it’ll remain relatively static between them, it’s much easier to maintain one vDisk for all environments vs. configuring updates for each of them independently.

In my experience the simplest means to do this has been to configure an HDX policy within an AD GPO, that sets the VDA registration parameters. Doing this via GPO gives us the flexibility to tie the GPO to appropriate OU structures, and allows us to ensure the settings are applied correctly. Ensuring at boot-up a computer refreshes their GPOs helps here to ensure a VDA registers with the correct controllers for its respective environment, based on machine to OU association.

Step 1 – Create a GPO Per Environment for VDA Registration

I find it easiest to install GPMC on your Delivery Controllers, then edit the new GPO(s) created per environment, which should be labelled accordingly (indicating environment, and VDAReg GPO, can also add other settings in here like WEM controllers etc). This will ensure the Citrix GPO extensions are visible. These settings for HDX policies will otherwise not be visible on say, a Domain Controller without the Citrix GPO extensions installed on that Domain Controller so the settings become visible in GPMC locally on that computer.

I edit the unfiltered policy for Computer settings, and for the ‘Controllers’ settings specify the Delivery Controllers for the given site. That is usually all I’ve had to do. In some instances I have had to disable in this policy auto-update of controllers as it was interfering with operations.

Link the GPO to the OU(s) containing the VDAs for the given site.

Step 2 – GPUDATE Script

This step involves creating a script that will be set to run at startup. Some things to watch for in its creation. If you have a single environment and just want GPUPDATE to run at startup to avoid opening up images in private or maintenance mode to cache new GPU computer settings updates for a consistent experience, you can follow these steps but omit and line items to start and stop services.

Be mindful of course, of impacts of GPUPDATE. If the environment size is comprised of a few dozen systems that might reboot at once, it is a negligible consideration. In large enterprise environments with hundreds of VDAs that might happen to reboot simultaneously, just be mindful that a GPUPDATE /FORCE (which is more intensive in its operations than plain GPUPDATE) will put some added load on your Domain Controllers to which the VDAs are associated with in your AD Sites & Services setup. I haven’t had this arise as a real concern, just good to be aware of.

In an existing Baseline Computers GPO for your VDAs, or even in your VDAReg GPO you created, we’ll be adding a batch file.

Edit the GPO, go to Computer Configuration > Windows Settings > Scripts > Startup

Click ‘Show Files’, which opens up a file explorer window. Here you’ll add a batch file containing the following contents:

gpupdate /force
net stop brokeragent
net start brokeragent
exit

What this essentially does is run a GPUPDATE at boot, stop the VDA Broker Agent, and start it, to ensure it reads the refreshed VDA registration settings. If you do not need to manage VDA registration settings (single environment) then omit the net commands.

Words to the wise:

• Do NOT name the script “gpupdate”, it will cause loops as its also the name of a command in the file.
• Do NOT save this as .cmd file, save it as a .bat. This will also cause loops. In both cases the experience of the loop will be the VDA service starting and stopping immediately, likely logging 1003 event ID errors in the event logs.

Move the batch file into the folder opened from ‘Show Files…’.

Then just click the “Add…” button and select the file just added.

Should be good to go, test it out rebooting a VDA in the OU to which the VDAReg GPO is applied to, you should see in the logs that post reboot the Broker Agent stops then restarts again.