Wednesday, 27 March 2013

Deploying AppSense DesktopNow within a Standard Desktop or Server Image

Citrix Provisioning Server (PVS) has changed the way Citrix Administrators deploy and manage their servers and desktops. Administrators can now build a single image and very easily deploy that to several hundred servers in no time but what does this mean for AppSense Administrators?

Note: Ensure you understand the AppSense DesktopNow components and how they work by reading my post on the components of DesktopNow before reading this post.

My assumption is that you're an AppSense Administrator and have come here because your organisation is in the process of deploying XenApp or XenDesktop using Citrix Provisioning Server and you're looking for tips and tricks that you need to take into account when building your standard images.

A standard image means that each time that desktop or server is rebooted it will revert to a known image. All software installed since the previous reboot will be lost and any files not stored on a persistent volume will be lost.

This means that AppSense Agents (Client Communications Agent, Application Manager Agent, Environment Manager Agent and Performance Manager Agent) should be included within the standard image. Remember each of the agents, with the exception of the CCA, above include a driver of some sorts. This means that they will require a reboot to install and activate themselves correctly. If you deploy these using the AppSense Management Server and the Client Communications Agent when the machine is in standard mode you will end up in an endless loop because the machine will boot up, start installing the agent and automatically reboot and which point the installation will be lost and the process will start again.

The AppSense Client Communications Agent does not require a reboot but it does contain some key information that links each machine to a deployment group within the AppSense Management Center database. To ensure this is dynamically created on each endpoint your must perform the following sequence immediately before sealing your image:

  1. Stop the AppSense Client Communications Agent Service
  2. Stop the AppSense Watchdog Service
  3. Open regedit and browser to HKLM\SOFTWARE\AppSense Technologies\Communications Agent
  4. Delete the data for machineid value
  5. Delete the data for the groupid value
The other thing to take into account is that Environment Manager has Computer Startup, Computer Shutdown, Computer Process Started and Computer Process Stopped triggers that are often leveraged within a configuration. If the CCA is left to deploy a configuration to an image the actions assigned to these triggers will never be run. Best practice is to ensure you have your configuration built into the image. In fact, I would go one further and say in a Citrix Provisioning Server environment configuration deployment should always be managed as part of a vDisk update process and should be managed by your change control process. This isn't always easy but if you can I would suggest disabling the configuration installation and agent installation schedules within the AppSense Management Center to ensure no unapproved configurations can be deployed.

The reason for me saying this is because historically there have been issues with Environment Manager where deploying a configuration mid session has resulted in all actions applied within a configuration from being unapplied. This can be worked around by selecting "Apply policy settings permanently" for  ADM/ADM(x) actions and ensuring "Remove the folder redirection at log off or configuration change" is never selected. In addition an AppSense Engineering Key exists called PreventUnapplyOnConfigChange which can control this behaviour. 

That said, if you have made sure the above-mentioned pre-requisites are in place you could deploy a configuration during the session but any new logon actions configured would require the user to logoff and log back on in order for them to take effect at which point the machine would typically reboot and could result in a race condition between the user logging on and the updated configuration being installed. The end result could be that the user has a completely unlocked workstation with no folder redirection, etc applied. This is generally less of an issue in a XenApp environment but in a XenDesktop environment I've seen this on numerous engagements. 

Other recommendations worth noting for AppSense DesktopNow on a Standard image include:

Computer group policy actions should remain within active directory. Each time a change is required to a computer side group policy you would have no choice but to update the base image. In some instances an urgent security policy is required for compliance purposes, etc you will usually find the change control process to make a group policy change will be far simpler than to update your base image. 

AppSense has a technote published on myAppSense covering antivirus exclusions as well as CtxHooks. It is worth checking both of these articles out and applying them to your environment. The technotes are TN-150728 and TN-150517.

 If you're using a mandatory profile this is best placed on the local machines hard drive and then set this as the roaming profile path for users logging on to the platform. I generally don't bother creating a mandatory profile on provisioned XenApp and XenDesktop images and leverage the default profile. With a few customisations the default profile can load just as quickly as a mandatory profile particularly when used in conjunction with AppSense Environment Manager. You can then either use the snippet on AppSense Exchange to spoof a temporary profile (AEL00059) or simply rely on the reboot process to clear these profiles out. Either way, a local profile allows you to use the PKI infrastructure without any issues for applications like Microsoft Lync, etc. 

Another tip is if you're looking to leverage the built-in logging you should either move the AppSense Event log to an area of persistent storage or log to file and ensure this is located on persistent storage. The benefit of doing this is that log information is retained between sessions so you can retrospectively investigate issues when required. 

As always, any questions find me on twitter...