Citrix Provisioning Services and Microsoft System Center Configuration Manager 2012 SP1

March 27, 2013 at 12:54 pm in App-V, App-V 5.0, ConfigMgr 2012, ConfigMgr 2012 SP1, ConfigMgr, MP, PVS, SCCM 2012 SP1, XEN, Xenapp, Xendestop, XENSERVER by Kenny Buntinx [MVP]


Hi ,

Today colleague Frank Vandenbergh at my customer responsible for Citrix was fighting to get there Citrix Provisioning services up and running with clients registering into System center Configuration Manager 2012 SP1. He has written already a blog post about it here , but I want to share some background info with you and dig a little deeper.

We had tried this in ConfigMgr 2007 out of the box without great succes resulting in a blog post :”ConfigMgr on xendesktop with the usage of provisioning server : Unique GUID issue and the smscfg.ini

A little background :

Managing Virtual Desktops Created with PVS


Citrix Provisioning Services allows for multiple servers to stream their boot disk from the same master image (vDisk). During the boot process, PVS will make sure each server has a unique SID and dynamically apply the computername together with some other tasks to make those systems unique.

If you tried installing the SCCM client on a PVS image, you will notice that SCCM shows new machines with the same name every time a PVS target device reboots in standard mode. This is because the SCCM client changes the GUID when an image is pushed to new hardware. ConfigMgr uses the GUID to keep track inside his database.

ConfigMgr uses an ID that is generated on the Client to identify a machine inside the ConfigMgr hierarchy. This ID, also known as SMS GUID is generated during ConfigMgr Client installation.
An Algorithm, which combines the Timestamp (Time of ConfigMgr Client Installation) and the Universally Unique Identifier (UUID) is used to generate a unique Identifier.
A Client generates a new SMS GUID if the following things change

  • the SMBIOS serial number
  • the Machine SID
  • the Hardware ID (see appendix)

When VM is provisioned for the first time, the client will create a new GUID to register with server. If this client was discovered earlier by AD system discovery it can merge based on machine SID if previous history is present in SCCM site server DB. If server finds a match for this GUID in system_disc with exact AD machine account, the GUID and resource ID assigned will be same. If server finds a match based on AD machine SID in SID0, server will assign the GUID associated with the AD machine account and resource ID assigned will be the record that is the AD machine account. If it cannot find previous history using either of these methods, the server will assign the client passed in GUID and a new resource ID will be assigned.

Once new GUID is established for the VM, it will retain the same GUID for that VM based on machine SID as well as identity information restored locally on client from VDI persistent store. From the logs the client starts with GUID:78F1CF6F-814B-4E44-A2AE-729FB2C4F725 for reregistration that was established earlier and if cert changes it will associate the new cert with the GUID in re-registration. For any identity changes, client will retain the same GUID and same resource ID.

If resource ID changes (ItemKey in system_disc), it means there is no match in previous history for either client GUID or AD machine SID or client cert.

The heartbeat DDR will be sent when VM is provisioned for the first time i.e. when new ID is created. Thereafter it will depend on heartbeat discovery schedule set in the policy. Once DDR is sent by the client and gets processed by MP and site server, you should see all attributes in Admin console.

To ensure any desktops created with Provisioning Services operate correctly with ConfigMgr 2012, you must set the write cache to the target device’s hard drive. Using the Provisioning Services Console, in vDisk Properties, select Cache on device hard drive as the Cache Type. If you do not configure the cache this way, data required by ConfigMgr 2012 is not persisted when the desktops are restarted, which may result in unexpected behavior such as duplicate GUID’s or invalid inventory etc.

Unique Machine IDs for Shared Image Desktops

Virtual desktops built on the shared image provisioning solutions provided by XenDesktop (Provisioning Services and Machine Creation Services) presented a bit of a challenge for Configuration Manager 2007. 

With XenDesktop 5.6 and Configuration Manager 2012 / SP1 that problem is now history.  When you create your master image with either MCS or PVS simply install the SCCM agent and forget about it.  When you create cloned/streamed machines from that master image, the SCCM agent will automatically generate and store machine IDs that persist for the life of the VM.  Your virtual desktops will register and behave exactly like their physical counterparts.  One record per machine and that machine will continue to use the same ID across reboots.  This capability will also be available for XenApp servers streamed with Provisioning Services 6.1.

However it is not that simple …

Step 1 : Extending ConfigMgr Inventory for XenDesktop

XenDesktop makes available to ConfigMgr 2012 so that virtual desktops can be managed using this tool. The properties are available for the Citrix_virtualDesktopInfo class in the Root\Citrix\DesktopInformation namespace. See official info here :

The following properties are available. Property names are those used in the Windows Management Instrumentation (WMI) provider:

  • BrokerSiteName – The name of your XenDesktop site; returns the same value as HostIdentifier
  • DesktopCatalogName – The name of the catalog associated with the desktop
  • DesktopGroupName – The name of the desktop group associated with the desktop
  • HostIdentifier – The name of your XenDesktop site; returns the same value as BrokerSiteName
  • IsAssigned – False for a pooled-random desktop, otherwise true
  • IsVirtualMachine – True for a virtual machine, false for a physical machine
  • OSChangesPersist – False if the desktop operating system image is reset to a clean state every time it is restarted, otherwise true
  • PersistentDataLocation – The location where Configuration Manager stores persistent data. This is not accessible to users.
  • PersonalvDiskDriveLetter – For a desktop with a personal vDisk, the drive letter you assign to the personal vDisk

The properties BrokerSiteName, DesktopCatalogName, DesktopGroupName, and HostIdentifier are determined when the desktop registers with the controller, so they are null for a desktop that has not fully registered.

You can display the properties using the hardware inventory in Configuration Manager or using attributes of Configuration Manager objects. When you do, the names may include spaces or vary slightly in other ways.

On how to extend the HW inventory , Marius Sandbu has written an excellent acticle about that here :

Step 2 : Create your Master VM with care !


Keep in mind that your Master VM is a fully configured and running VM. You allow SCCM to install the client as normal and so the SCCM server is aware of the machine so I guess you can say the reverse it true as well. You do this install before you do create the catalog from the VM image of course. From there it should just work.

  • Install the Configuration Manager client software on the golden image as part of your automated Configmgr Task Sequence
  • Stop the SMS Agent Host service (CCMExec.exe) on the reference computer (net stop ccmexec).
  • Delete the C:\Windows\SMSCFG.INI file
  • Delete the current certificates in the "SMS" certificate store. ( open an MMC.exe)
  • Change the provisioning image from private to standard.
  • Stream the vdisk to target computers.

If you do not remove the certificates , you will get into the following problem that registration of the client will not succeed successfully. What will happen is :

1. System booting up in “private mode”, the master image. Hostname is TEST1.

2. Same disk is now booted in standard “readonly” mode. Hostname is TEST1. SCCM is correctly getting the persistent disk location from WMI . SCCM restores everything from CCMCFG.BAK, except the correct SMBIOS value. It reports SID unchanged, HWID unchanged, SMBIOS changed (it is still reading the SMBIOS value from the ‘master’ device in the SMSCFG.INI file in the default location.)

3. ClientIDManagerStartup reports: Detected hardware identity change, generating new certificates.The Client is re-registering with the SCCM server.

4. The SCCM service seems to be restarted following the registration witch is normal .The ccmexec service restart is expected even on non-VDI systems if any of the policy configuration require service to be restarted. The heartbeat DDR will be sent when VM is provisioned for the first time i.e. when new ID is created.

5. In the SCCM console the record is recreated and as a result we loose the software metering information / direct collection memberships. We did the test with removing the SMSCFG.ini file in the “master” disk. On next startup SCCM is reading everything correctly from the CCMCFG.BAK and reports “SMBIOS unchanged”.

6.The computer object is not recreated, but we have a feeling the client is still not registered correctly because the console is not updating its last hardbeat time etc.  .This is due the faulty SMS Client certificates being stuck in the “Master Images” . Remove the Certificates as said before and you’ll be fine .


Hope it Helps ,

Kenny Buntinx

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on Pinterest