Do I need to snapshot my master image when creating a pooled desktop catalog in Citrix XenDesktop 5.5 via Desktop Studio?

I know this may seem obvious but I’ve been asked a few times about whether to create snapshots for the master image that will be used for a pooled desktop catalog in Citrix XenDesktop 5.5 via MCS’ Desktop Studio.  Those who are familiar with VMware View would know that it’s mandatory for you to create a snapshot of your master image when creating a linked-clone pool but in the case of XenDesktop, the answer is yes and no.  Yes in the sense that your master image needs a snapshot in order for MCS to create the pool and no in the sense that if you don’t create a snapshot for your master image, MCS will do it for you. 

The only draw back I see of not manually creating a snapshot of your master image is that MCS will create a snapshot and name it with its naming convention.  The following is an example:

We have a Windows XP SP3 master image with no snapshot:

We proceed with creating a static pool:

We select the master image that has no snapshot:

We name the pool:

Test Pool

Once MCS begins to create the pool, you’ll see a snapshot that was automatically created.  The name convention MCS uses is:

Citrix_XD_

… then followed by the name you gave to the pool so in this example, it ends up being:

Citrix_XD_Test Pool

So where does the Citrix_XD_ come from?  I’m not sure and I know it doesn’t have any relation to whether the pool is static or random because I’ve created both type of pools and noticed that the name is the same.

So what would I recommend?  Create your own snapshot because you can give it a meaningful name and you’ll avoid the following mistake some people may accidentally make.

What to Avoid

Now that we’ve talked about how XenDesktop handles snapshots, I would like to demonstrate a situation that having XenDesktop’s MCS automatically create the snapshot for you would create an undesired result.  Say we already have a desktop catalog created with a master that has a snapshot created.  If we decide to create another desktop catalog using the same master image with the intention of having the new second pool in lockstep with the existing pool, but forget to select the snapshot during the creation of the pool, we’ll end up with the following:

Notice how XenDesktop just created another snapshot on top of the first pool.  This is probably going to be the undesired result because now you have the second pool’s snapshot stacked on top of the original one.  The next time you decide to update your original desktop catalog, you’ll need to either use the second pool’s snapshot or create another one from it.