Jump to content


Updating Static Machine Catalogs conundrum

Started by Christopher Barlow , 08 January 2015 - 08:23 PM
4 replies to this topic

Christopher Barlow Members

Christopher Barlow
  • 56 posts

Posted 08 January 2015 - 08:23 PM

An interesting thought to ponder...  What would you do?  This is the scenario:


We re-baseline our desktop master images every quarter, ie. 4 times a year, to include all latest software updates.  This will include the master image for statically assigned virtual desktops.


For obvious reasons, XenDesktop does not provide the ability to update Static (Dedicated) machine catalogs, only Random (Pooled).  On the one hand this is ok, because once deployed by MCS, Static desktops will thereafter be maintained by SCCM, so we simply don't touch the already deployed machine catalog.  But where does that leave new desktops?  


I'm thinking that we would have to deploy a new machine catalog pointing to the new image/snapshot whenever we re-baseline each quarter.  This is where it starts to get interesting.  This approach would mean 4 new machine catalogs per year, per customer.   And we need to maintain these catalogs as long as there are people connecting to them.  The list of catalogs will become huge over time.


This gets even more interesting when you throw App Orchestration and CPSM into the mix.  For each of our customers, we would also need to also create the new catalog in App Orchestration, + a new Offering, + do the setup in CPSM Hosted Apps and Desktops service to point to the new Offering.  


And how do we stop users from requesting the old (pre re-baselined) desktop in CPSM?  As far as I know, this is not possible (see attached), which is a bit of an issue.


Apologies for the length of this and I hope it makes sense to someone.  Hopefully this is not as big of a potential nightmare as it first appears.  Am I missing a trick somewhere?  Any thoughts on this would be appreciated.

Attached Thumbnails

  • CPSM service offering subscription conundrum.png

Andy Zhu Citrix Employees

Andy Zhu
  • 140 posts

Posted 08 January 2015 - 08:38 PM

Hi Chris,


Because the frequency of your image updates, i recommend you to use the pooled/random catalog types only, one the backend either use MCS or PVS). And use romaing profiles to store some user preferences for different application, and use sharefile integration to store user data *because they tend to be large).


In this way, your users will always gets the latest application from the VDA and user data comes from some other central place, not tying to any particular VDA machines.


Just some thoughts

Christopher Barlow Members

Christopher Barlow
  • 56 posts

Posted 08 January 2015 - 09:24 PM

I tend to favour non-persistent + personal vDisk.  The decision was made however to manage static virtual desktops (once deployed) pretty much like we would a standard traditional desktop.

Alexander Soriano Members

Alexander Soriano
  • 2 posts

Posted 22 January 2016 - 04:35 PM


Thanks for posting this thread.  We are running into the same limitations.  There are some links/scripts out there for migrating machines from one catalog to another, but they seem fairly complex and I, for one, would be reluctant to attempt it on a production environment.



Is there any consideration to enabling the ability to update "static" MCS images? Of course, the understanding would be that updating the image would not affect existing machines, but it would be immensely helpful to be able to update an image for FUTURE deployments without cluttering the console with new catalogs every time a new image is needed.


In our case we are leveraging MCS to support web developers.  A solution like roaming profiles a bit of a nightmare to manage due to the large amounts of data the developers generate, which is what makes a static desktop ideal.


The ability to update the static MCS image to new baseline would be a fantastic enhancement.

Nicholas Burton Members

Nicholas Burton
  • 8 posts

Posted 17 February 2017 - 04:24 PM



I know this thread is old, but I recently created a blogpost for this, as I ran into this same issue.




I hope this helps you and all those in the same situation.


-Nick Burton