I’ve been doing a bit of work recently around trying to get AppSense configurations installed onto a persistent disk in a Citrix Provisioning Services environment. It actually isn’t as intimidating a prospect as I initially erroneously thought, so we will run through the process briefly in this blog post.
Citrix Provisioning Services is – or was – more or less the standard for streamed disk deployments in XenApp environments. However, there are some schools of opinion that believe once MCS (Machine Creation Services) is able to provision XenApp servers – which may well happen as XenApp and XenDesktop move closer together in the new versions – that PVS may well end up being deprecated somewhat. With this in mind, the work done here may turn out to be slightly redundant – but I am sure a vast quantity of those enterprises currently utilizing PVS will continue to do so for at least the next few years.
The systems I tested this on were VMWare guests running Windows Server 2008 R2 in a Citrix PVS 6.0 environment. The system drive was on the non-persistent C: partition, with the persistent drive sitting on the D: partition. On the D: drive were many of the things you’d normally expect to see on a persistent drive – log files, antivirus, monitoring tools (EdgeSight in this case), the App-V cache, and the pagefile.
Firstly, the reason behind wanting to maintain your configurations on a persistent drive – after all, don’t a lot of places have the configurations set to install automatically, at the very least on startup? This is indeed true – but if you recall my very first post, Computer Startup Actions aren’t processed unless the configuration is already installed on the endpoint when it starts up. This also means that every time you want to update a Computer Startup Action you will need to update the master or “gold” image – a non-trivial operation in most environments and one that requires strict change control. If you can’t use Computer Startup Actions because of this reason, this also means that you can’t apply Computer Group Policy Objects and take advantage of the breadth of Conditions that AppSense Environment Manager ships with natively.
Now, what we really need to know to get this started is where AppSense stores its configurations! Fortunately, this information and a bit more had already been kindly pointed out to me by Matt Murphy, Neil T, and a few other commenters and emailers, which saved me raising a support call :-) On Windows Vista / 2008 / 2008 R2 / Windows 7, the configuration is downloaded to the %systemdrive%\ProgramData\AppSense folder. The configuration is a .aamp, .aemp or .apmp file dependent on the part of the DesktopNow suite that you are using. On systems using XP / 2003, I believe the default location would be %Allusersprofile%\Application Data\AppSense - but I haven't tested this, so if you are doing this on an older platform, you will need to do a bit of research first.
Unfortunately the AppSense software seems to have a nasty tendency to expect this location to be hardcoded. Even if you install the agents onto the persistent drive (in this case D:), the configuration is still expected to be in the %systemdrive%\ProgramData location. Moving the %systemdrive% variable to a persistent drive would completely negate the entire point of using PVS in the first place, so we need to redirect it somehow.
After a bit of research and discussion, it becomes apparent that there is a Registry key sitting at HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList that controls the location of the ProgramData folder. However – it wouldn’t make sense to redirect the entire folder, when all we are trying to deal with is the AppSense configurations. I did initially try to redirect the entire folder using this Registry key and quite spectacularly stopped the App-V client from working (although after some Registry hacking and a re-registration of all the WMI components, it came back to life). There’s also the distinct possibility you may leave your Windows OS unable to be serviced (i.e. patched) by redirecting the entire folder, so just going for the AppSense part is probably the safest option!
What we can do to achieve this, and what I suspect many of you will have already thought of, is the possibility of using something like subst or a symbolic link to achieve this redirection. Indeed, the symbolic link (or junction point, depending on what you want to call it) looks like the most reasonable option.
Symbolic links are created using the mklink command from an elevated command prompt. Don’t forget that the target directory (the one you want to redirect) cannot exist when you run the command. In the experience I had here I find it would probably be best to do this redirection prior to installing AppSense software, as you can be sure the target folder does not exist and there will be no hidden gotchas – however, you may be able to do it post-install with a bit of jiggery-pokery.
First you need to make sure that your PVS system is in Private Mode, as there will be no point redirecting the folder if the change is just going to disappear at next restart!
Ensure that the %systemdrive%\ProgramData\AppSense folder does not exist, and then run the following command
mklink /J c:\ProgramData\AppSense d:\ProgramData\AppSense
(Naturally, substituting the appropriate drive letters for your persistent and non-persistent areas)
You should now see a junction point appear in the folder as below
![]()
Which when double-clicked, leads you neatly into the corresponding folder on the persistent drive.
Note– you don’t specifically need to redirect the entire AppSense folder. As only Environment Manager (at present) has Computer Startup Actions, you could get away with simply using a junction point from %systemdrive%\ProgramData\AppSense\Environment Manager. However, for posterity and future-proofing, I opted to do send all of the configurations to the persistent disk – deciding on the way you wish to do it is entirely your own decision.
So the next action would be to install your AppSense agents as normal. Originally I thought you might need to install these to the persistent drive also, but if you are going to be (as you should) putting the agents into the master/gold image, then it doesn’t matter whether they are on the system drive or not.
Next it will be time to run the Imaging and Provisioning Wizard as part of the XenApp Role Manager utility, to ensure that your system is nicely normalized. After you’ve done this and run whatever other pre-sealing tasks you normally conduct, then it is time to shut the system down and put your image back into Standard Mode.
While your system is restarting this would be a good time to fire up Environment Manager and create a configuration with a Computer Startup Action in it. For the purposes of this demonstration we will choose something simple – setting an Environment Variable called TEST.
![]()
Now, bring the PVS system back up. If, like most people, your configurations deploy at startup time, as soon as it connects up you will see it obtain the new configuration.
Let’s check for the existence of the TEST environment variable. It doesn’t exist. This is exactly what we expected – the PVS system came up without a configuration, the configuration was assigned, but the Startup Action didn’t run because the Computer Startup trigger had passed before the configuration was assigned.
We’ll take a quick look in the redirected folder which points to our persistent drive, and as you can see below, the configuration is located in the correct folder.
![]()
So the next thing to do is restart the system. As it is a PVS system, it should then return to the base image it had before it was sealed.
When it comes up, we again see it pick the assigned configuration up at startup…
![]()
…but this time, when we log in, what we see is this time our Computer Startup Action has successfully run, meaning that the configuration we assigned has persisted between restarts! Sweet!
![]()
This is great news – we can now utilize the full power of Computer Startup Actions in an environment like PVS without worrying about updating the gold image every time we make a change!
There is one caveat I have found regarding this, however. In some environments configurations are not deployed using the Management Console – they use System Center Configuration Manager or another deployment tool. When the PVS system starts up in this way, the AppSense software queries the MSI database to see what is installed, and then uses this information to report to the Management Console. If you’ve got the Installation Schedule for Configurations set to Disabled, this will mean that the PVS system will report the configuration(s) as Pending Install– even when they are in fact installed, and active to boot. In these situations, this can make your administration and reporting from the Management Console look a little screwy.
But even with this caveat – and those of you who use the Management Center and have the configurations set to install won’t have this problem – this still is a good, reliable way of getting around the issue of using Computer Startup Actions in an environment where the system drive is non-persistent.
Note– this process should work for other technologies similar to Citrix Provisioning Services, it isn’t specifically intended for PVS. Not sure whether MCS will eventually be able to provision XenApp systems as well as XenDesktop, but when or if it does, I hopefully will get around to trying it on there – everything else I will probably leave in the capable hands of the rest of you :-)
One final note– if you’re using PVS, then I’d recommend taking a look at this article regarding normalization, and this article regarding automating the normalization, just in case you hadn’t come across them already.
And now – I fancy a barbecue, seeing as though the British summer has officially arrived, and will henceforth be gone within 48 hours!
Note– you don’t specifically need to redirect the entire AppSense folder. As only Environment Manager (at present) has Computer Startup Actions, you could get away with simply using a junction point from %systemdrive%\ProgramData\AppSense\Environment Manager. However, for posterity and future-proofing, I opted to do send all of the configurations to the persistent disk – deciding on the way you wish to do it is entirely your own decision.
So the next action would be to install your AppSense agents as normal. Originally I thought you might need to install these to the persistent drive also, but if you are going to be (as you should) putting the agents into the master/gold image, then it doesn’t matter whether they are on the system drive or not.
Next it will be time to run the Imaging and Provisioning Wizard as part of the XenApp Role Manager utility, to ensure that your system is nicely normalized. After you’ve done this and run whatever other pre-sealing tasks you normally conduct, then it is time to shut the system down and put your image back into Standard Mode.
While your system is restarting this would be a good time to fire up Environment Manager and create a configuration with a Computer Startup Action in it. For the purposes of this demonstration we will choose something simple – setting an Environment Variable called TEST.
Now, bring the PVS system back up. If, like most people, your configurations deploy at startup time, as soon as it connects up you will see it obtain the new configuration.
Let’s check for the existence of the TEST environment variable. It doesn’t exist. This is exactly what we expected – the PVS system came up without a configuration, the configuration was assigned, but the Startup Action didn’t run because the Computer Startup trigger had passed before the configuration was assigned.
We’ll take a quick look in the redirected folder which points to our persistent drive, and as you can see below, the configuration is located in the correct folder.
So the next thing to do is restart the system. As it is a PVS system, it should then return to the base image it had before it was sealed.
When it comes up, we again see it pick the assigned configuration up at startup…
…but this time, when we log in, what we see is this time our Computer Startup Action has successfully run, meaning that the configuration we assigned has persisted between restarts! Sweet!
This is great news – we can now utilize the full power of Computer Startup Actions in an environment like PVS without worrying about updating the gold image every time we make a change!
There is one caveat I have found regarding this, however. In some environments configurations are not deployed using the Management Console – they use System Center Configuration Manager or another deployment tool. When the PVS system starts up in this way, the AppSense software queries the MSI database to see what is installed, and then uses this information to report to the Management Console. If you’ve got the Installation Schedule for Configurations set to Disabled, this will mean that the PVS system will report the configuration(s) as Pending Install– even when they are in fact installed, and active to boot. In these situations, this can make your administration and reporting from the Management Console look a little screwy.
But even with this caveat – and those of you who use the Management Center and have the configurations set to install won’t have this problem – this still is a good, reliable way of getting around the issue of using Computer Startup Actions in an environment where the system drive is non-persistent.
Note– this process should work for other technologies similar to Citrix Provisioning Services, it isn’t specifically intended for PVS. Not sure whether MCS will eventually be able to provision XenApp systems as well as XenDesktop, but when or if it does, I hopefully will get around to trying it on there – everything else I will probably leave in the capable hands of the rest of you :-)
One final note– if you’re using PVS, then I’d recommend taking a look at this article regarding normalization, and this article regarding automating the normalization, just in case you hadn’t come across them already.
And now – I fancy a barbecue, seeing as though the British summer has officially arrived, and will henceforth be gone within 48 hours!