Client Management Suite

Anyone deployed altiris agents in a non-persistent environment with View or XenDesktop? We are looking to begin this effort shortly, however I have some concerns with regards to the Altiris agents.

First and foremost, I don't want the patching agent to come down to the machines since patching will be done by updating the master image and we don't want to bloat delta disk in between patching cycles.  My first though is to exclude by OU since we will have a dedicated OU for our VDI enviornment.  We don't currently do AD imports in Altiris so I'm concerned that whatever inventory that determines the Distinguised Name of the computer (which is what i'm intending to use to determine OU) might not happen in time to avoid the patch agent being installed on the client.  

Would I be better off excluding by IP range in a filter?  Or by a naming convention?

Also, I've seen some previous threads about creating various filters to spread out tasks that generally run all at once (for example, software inventories). I'll probably build out some mechanisms to run such policies in smaller chunks.  Any advice on other gotcha's would be much appreciated.  

If your VMs aren't persistent, you might want to decide how long they'll be active.  You may decide to exclude them entirely from software and hardware inventories, or to run very selective delta inventories.  If you do run inventories, keep an eye on performance in vCenter so you know what impact it's having on your hosts.  You could work with your virtualization team to determine what sort of randomization is necessary.

An AD import is the best way to ensure they get the correct policies.  A naming convention is the last option I would choose, and relying on Distinguished Name in inventory isn't great.  If you have certain IP ranges defined for these non-persistent VMs, or other inventory gathered by basic inventory (such as the adapter's MAC address, which you could translate the first and second octets into a vendor like VMWare), you could include them in a filter that's included in the target of your policies.

Most of them will be detected in the Default view as a Virtual Machine resource, but that might be too broad for your environment.

The default Software Update target includes all computers that are not included in other Software Update targets, so just ensure you have a policy assigned to these non-persistent virtual computers.  The policy should receive no patch approvals and have patch windows way in the future, just in case.  From a security perspective, however, you will still need to ensure the patches are applied to the VMs in a timely manner, and you'll have to remember that you're patching two environments: first the physical in Altiris, and then the virtual in your master image.

I'd also pay attention to local package caches for software deliveries, since there isn't much sense in keeping a 2.3GB package cached locally once it's been installed.  That would eat up expensive server disk.

As always, test everything first and then run a small pilot to ensure everything functions as you expect, before moving everything to production.

Great feedback.  I suspected you might say that the DN isn't the most reliable way.  I'll probably do an AD import targeted at the specific OU for our VDI environment. 

With regard to the non-persistent VM's, it will be a little interseting regardless of their lifespan since we will probably have a set # of VM's in a pool and when VM's are refreshed, the names will get re-used.  I'm not sure if that is going to cause duplicate machines to appear in Altiris?  I suppose we could just use a CMDB rule of some sort to do some nightly cleanup or something.

For testing purposes, we will have a few different pools of virtual machines, some of which would refresh at logoff.  A subset of our production virtuals would refresh that way where the machines assigned to users would most likely refresh monthly.

We will have a certain IP range, although currently that range hosts virtual machines that won't refresh at all so we wouldn't necessarily want to exclude them from more normal policies.  Maybe it makes sense to make a separate subnet for the non-persistent environement, then. 

For software update, I could just exclude the VM's from the software update agent installation policy, correct?  That way, it wouldn't get the point where it was trying to apply an update policy since it woudln't have the agent at all. 

Can you speak a little bit more about the package cache?  Does it eat up 2.3GB by default?  Or is that just what it will max out at?  What way can I either throttle this lower or avoid local caching?  I suppose I could write a script to clear the local cache as needed... Do I basically need to remember to exclude the non-persistent VM group from typical software deployments?

We will definitely be doing a lot of testing internal to IT before putting any "real" users in the system.  Figuring out the Altiris agent stuff will be one of the first of many steps that we have planned out for this environment.  Definitely a complex undertaking, but it's fun!

FWIW we had a meeting with Don Closser and brought this specific scenario up.  It was interesting to him and he said that he'd be taking the use case back to his development team as he recognizes that they'll have to natively support this in the future.

I am interested in this as well as we have a VDI inititiative and need to make these decisions.  Especially when it comes to audit time.