ConfigMgr on xendesktop with the usage of provisioning server : Unique GUID issue and the smscfg.ini

February 4, 2011 at 8:25 am in citrix, ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, ConfigMgr 2012, ConfigMgr SP2, ConfigMgr, configmgr2007, ConfigMgr2007 R3, Deployment, PVS, R3, sccm, SCCM 2007, SCCM 2007 R2, SCCM 2007 R3, SCCM 2007 SP2, SCCM 2012, SCCM v.Next, sccm2007, Xenapp, Xendestop by Kenny Buntinx [MVP]

Have you ever tried to manage your XENDesktop or PVS target devices using Configuration Manager in combination with an App-V integrated scenario ? I have a few customers that started to use Citrix Provisioning services and where faced with some issues when they wanted to pre-cache there App-V packages with Configmgr 2007 SP2 R3 . In some ways, managing the devices using SCCM is irrelevant due to the nature of how PVS works, but I’ve run into a few companies that insist on using SCCM for inventory management  ,  License reporting and virtual application targeting. The ConfigMgr client, is not designed to work well in a streamed OS environment. 

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)

Criteria for Hardware ID monitoring:

  • FirstDriveSerial
  • MACAddress
  • CDROMDevice
  • DisplayAdapter
  • HwidVersion
  • ProcessorSerial
  • DiskDevice
  • SCSIAdapter
  • DiskAdapter
  • ProcessorType
  • RAMSizeMb
  • Dockable


This GUID is stored in the c:\windows\SMSCFG.ini file. You can read this value out by a vbscript

The problem we see is in a Citrix Provisioned desktop, this file comes up with a duplicate GUID each time. This causes the SCCM client t re-generate the GUID and create a new file on every boot.
You can find this information here

The Fix ( I got this content and script from Rick Rohne – citrix guru )

In order to persist the computers GUID, you must be using “cache to targets hard drive” when you place your systems in standard mode. We will use the hard drive to save the SCCMCFG.ini file after each reboot.
This also means that "cache to RAM" or "cache to Server" will not be sufficient because the cache will be purged on every reboot.

Step 1 :

To resolve this, first, you have to run a script when switching from private mode to standard mode. This is done by the XENDesktop Admin after he modifies the default image…

This script stops the SCCM service and deletes the c:\windows\SCCMCFG.ini file.

‘————————— SCCM Cleanup.vbs————————————–
‘Stop SCCM client strServiceName = "CCMExec"
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colListOfServices = objWMIService.ExecQuery("Select * from Win32_Service Where Name =’" & strServiceName & "’")
For Each objService in colListOfServices objService.StopService() Next ‘ Cleanup SCCM Set fso = CreateObject("Scripting.FileSystemObject") Set aFile = fso.GetFile("c:\windows\SMSCFG.ini") aFile.Delete

Step 2 :

Now, you have to run a shutdown script and startup script that basically places the ‘c:\windows\SCCMCFG.ini’ file on the Cache drive on shut down. When the computer boots up, it will check to see if the file exists on the cache drive.

If it does not, the SCCM client will register itself to the SCCM server and create a new c:\windows\SCCMCFG.ini file. Upon shutdown, the c:\windows\SCCMCFG.ini file is copied to the cache drive.

This is a simple batch file script that can be loaded into active directory as a computer startup script for the OU where XENDesktop computers reside.

Startup Script

IF EXIST G:\SMSCFG.ini COPY G:\SMSCFG.ini C:\Windows\SMSCFG.ini /y > c:\smserror.txt

Shutdown Script

COPY c:\windows\SMSCFG.ini G:\SMSCFG.ini /y > g:\smserror.txt

Conclusion :

PVS images that are managed by SCCM will show up as unique entries in the SCCM database. This will at least make sure that systems will keep their own SCCM computer record and not generate a new one on every boot, but still it requires management overhead as there is no way to tell that those systems will get the same SCCM configuration / advertisements if something will go wrong in the middle of this process !

Therefore I expect since Citrix and Microsoft SCCM are allianced together in the V-Alliance , we would also like to see that the integration between ConfigMgr 2010 and Citrix Provisioning services  and that there will be "PVS-Awareness" in Configmgr 2012.


Hope it Helps ,

Kenny Buntinx

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