Citrix Provisioning Services (PVS) is a great tool. You can instantly update or roll back hundreds or thousands of XenApp or XenDesktop systems simply by restarting them. Machine image consistency becomes ensured – while at the same time large pools of machines can completely change their configuration, applications, and even OS in the time it takes them to reboot. Using this technology alongside AppSense Management Suite doesn’t have to be challenging – as long as you take heed of the possible issues when deploying Standard Mode vDisk images.
When using PVS with standard mode vDisks (and indeed any other disk streaming mechanism with a read-only mode, to be fair) you need to make sure that applications that reference machines by custom identifiers do not get confused between the various machines using the same image. Antivirus is a particularly well-known product for this, as are many monitoring tools. Often there are GUIDs in the Registry that need to be set or removed so that when the image boots in read-only mode attached to a production server, it is correctly identified and configured according to the settings of the particular application.
AppSense too has this contingency to be taken into account. Your machines will belong to Deployment Groups based on either name or OU membership, and based on that, various agents and configurations will be deployed. The details of this are all stored in the AppSense database, so when putting together a “gold” or “master” image that already has the AppSense agents and/or configurations installed, you’ll need to follow a certain procedure to make sure your image is “normalized” for the AppSense agents to function correctly when you put the system back into Standard (read-only) Mode.
Note that the process I am discussing here is to be done in addition to (not instead of) all the other normalization procedures that you’d follow when dealing with a PVS image. I know you’re all intelligent folks, but with a badly-configured PVS image you could possibly screw up thousands of shared systems, so I thought I’d just throw that little disclaimer in there 🙂
First you’ll need to install the agents. I’ve seen places where they’ve had specific deployment groups with only one agent installed, but in 99% of cases, regardless of your deployment group configuration settings, you’ll be installing the full set of agents. You can do this in any way you choose – manually, by script, or by letting the Deployment Group settings do it automatically. A reboot afterwards would be sensible, to allow the AppSense filter driver to initialize correctly while the system is still in read/write mode.
Next you can install the configurations (if you want to). If you have various Deployment Groups with different configurations, then you may want to simply leave them off until the image comes up in standard mode. However, don’t forget the problem with Computer Startup Actions (see here). If you want to apply machine-based settings, you will need to apply the configuration and perform a reboot prior to putting the system into standard mode. Additionally, rather than simply not applying a config, you could at this point apply a base configuration – if you then bring the image up on a machine in a deployment group with a different configuration, the new one will simply apply over the top of the baseline one. However, as mentioned previously, if there are Computer Startup actions in the new configuration, they won’t apply unless you “bake” them into the master image.
After you’ve restarted again (if necessary), the next step would be to stop all of the AppSense services. These are the AppSense User Virtualization Service (which may be shown as the Environment Manager Agent on older EM systems), the AppSense Client Communications Agent, the AppSense Application Manager Agent, the AppSense Performance Manager Agent, and the AppSense Watchdog Service. Take care if you’ve configured GPOs or other monitoring tools to auto-restart these services when they stop – they may unexpectedly begin to run again, which could have negative effects on your base image. If using GPOs to do this, it might be an idea to unlink the GPOs, run a gpupdate, and then reinstate the links when the image is shut down. However, it’s not generally good practice to have your master image subject to anything more than pretty basic GPOs anyway.
Anyway, back to the case in hand. Next task is to delete these two Registry values, which control the unique IDs that the AppSense Management Server uses to identify the system
HKLM\Software\AppSense Technologies\Communications Agent
Values: MachineID and GroupID
Also, delete any keys referencing any user SIDs within
HKLM\Software\AppSense\Environment Manager
And then finally, delete any folders within %systemdrive%\AppSenseVirtual
When all this is done, you should be able to shut down the system (without restarting the AppSense services, either manually or automatically!) and then convert your PVS disk to Standard Mode.
When you bring the image back up on your Xen systems in Standard Mode, as long as rules are configured within the Management Center to assign your systems to Deployment Groups, there should be no issues in picking up the correct configurations and applying the intended rules and actions.
One final note on this. A lot of customers I have worked with use a secondary, persistent disk (usually the D: drive) to store software configurations that normally have to be shoehorned in in this way (I’ve seen it done with various flavours of AV, Citrix EdgeSight, and other monitoring tools). AppSense, at the moment, can’t manage this, because it uses an MSI installer and the place the AppSense configurations are saved can’t be changed from %systemdrive%\AppSenseVirtual (at least as far as I’ve noticed – please correct me if I am wrong!) If we could redirect this to another drive, we’d avoid the problem with Computer Startup actions at the very least, and maybe some more little inconsistencies that sometimes crop up on PVS systems with AppSense loaded. Although maybe we could get around this by using a Computer Shutdown Action to copy the files out to a persistent location and a Startup Action to copy them back in? I will see if I can find out if that is feasible.
Update to this – I’ve put together a post on persisting configurations using a symbolic link
Anyway, this process should hopefully allow you to successfully use PVS Standard Mode images alongside your AppSense software. I should say a big thankyou to Richard Thompson of AppSense for providing invaluable help on the methods for doing this. Left to my own devices, this post may have taken much longer to write 🙂
Share
