Infrastructure Adventures


Understanding Citrix XenDesktop Machine Creation Services

Filed under: Compute, Virtualization — Tags: , , , , , , — Joe Keegan @ 3:09 PM

I’ve been trying to wrap my mind around XenDesktop’s Machine Creation Service (MCS). The documentation from Citrix is pretty terrible, but there is some good information out there on the web. This is my attempt to to take info from other sites and explain how XenDesktop MCS works.

Pooled vs. Dedicated

XenDesktop MCS can create two types of desktops:

  • Pooled desktops are the “disposable” stateless desktops that best practices dictate should make up most VDI deployments. Folder redirection, roaming profiles and the like are used to keep user data off the desktop’s hard disk image. Since user data is not stored on the desktop, the desktop is reset to it’s original state when a user logs out and in essence can be thrown away after each use. In this type of deployment a user can login to any desktop in the pool and get the same user experience since they “bring” all their data and profile settings with them.
  • Dedicated Desktops are similar to a traditional desktop deployment. Each user is assigned a desktop and it’s their desktop to love, cherish and potentially ruin. In this case all the changes made to a desktop are retained from session to session, and while using folder redirection/roaming profiles in dedicated desktops is till a best practice it is not required.  Since a dedicated desktop could be customized and contain data that is specific to that user then that user must always login to the same desktop.

MCS Overview

The following diagram gives an overview how Pooled and Dedicated desktops are provisioned by MCS.

It all starts with a VM which you plan to use as your Master Template. All the desktops in a catalog will be based off a Master Template. When creating the catalog you select the Master Template and choose if you want to create a pooled or dedicated desktop catalog.

MCS will then take a Private Snapshot and a public snapshot of the Master Template VM. The public snapshot is visible in the vSphere Client and is called Citrix_XD_CatalogName (Where CatalogName is the name of the catalog). The private snapshot is not visible via the vSphere client. The Public Snapshot can be removed without impacting the catalog and MCS.

Once the Private Snapshot is made then a Clone is created from that Snapshot. Each catalog will create it’s own snapshot and it’s own clone. So if you have two catalogs based on the same Master Template then you will have two clones. Also a clone is created for each data store included in that catalog. So if you have two catalogs each using the same five data stores then you will have ten clones, a clone for each catalog on each data store.

Each Desktop in a catalog is granted read only access to the clone on it’s data store. An Identity and a Difference vDisk are “layered” on top of the read only clone. The Identity vDisk includes all the specific desktop identity information such as host name, password, etc. The Difference vDisk is where all the writes and changes to the desktop are stored.  These Identity and Difference vDisks for each desktop are stored on the same data store as their related clone.

The difference between a Pooled or Dedicated desktop is what happens to the Difference vDisk when a user logs out.  In a dedicated desktop the differencing disk is retained after a user logs out while in a pooled desktop the differencing disk is deleted.

Updating Catalogs

One of the promises of VDI is to simplify desktop image management. This is usually handled by having the desktops share a master image. When the master is updated then all desktops using that master are updated also, usually just requiring a reboot. This is the case for MCS created pooled desktops, but not for dedicated desktops. The diagram below shows an overview of the updating process.

The Master Template has been updated and has been changed from the “Red” Image to the “Blue” Image.

To updated pooled desktops you select the “Update Machine” catalog option in Desktop Studio. You then point it at the new Master Template i.e. the “Blue” image. MCS then created the public and private snapshots and creates the clones. The pooled desktops are not updated until the restart, but when you “Update Machine” you can choose to do one of the following:

  • Nothing – The desktop will be updated whenever the user gets around to logging out, could be soon or could be a week from now.
  • Send a Message – A pop-up will display on the users desktop with a message that you can enter. Usually you ask a user to log off and back on when it’s convenient for them.
  • Reboot  – Do not pass go, just reboot it now. Not the most friendly thing to do to your users.
  • Send a Message and then Restart After a Delay – A pop-up will display on the users desktop with a message that you can enter. The desktop will the reboot in a set amount of time, defaulting to 1 hour.

In the meantime all new pooled desktops created from that catalog will use the new clone.

Dedicated desktops can not be updated like pooled desktops. Once a dedicated desktop is pointing to a clone it can not be changed. You can not even change the Master Template for a dedicated desktop catalog through the Desktop Studio, although you can with the following PowerShell command Publish-ProvMasterVmImage. if you do change the Master Template using the power shell command then all new desktops for that catalog will be based off the new “blue” image and clone, but the existing desktops will still be based off the old “red” clone.

Here are some links with MCS information:

The Silver is the New Black Theme. Blog at


Get every new post delivered to your Inbox.

Join 38 other followers

%d bloggers like this: