You are browsing the archive for PVS.

Citrix Provisioning Services and Microsoft System Center Configuration Manager 2012 SP1

12:54 pm in App-V, App-V 5.0, ConfigMgr 2012, ConfigMgr 2012 SP1, ConfigMgr V.next, 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.inihttp://scug.be/sccm/2011/02/04/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 : http://support.citrix.com/proddocs/topic/xendesktop-ibi/cds-manage-sccm-ibi.html

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 : https://msandbu.wordpress.com/2013/03/27/excalibur-and-configuration-manager/

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

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

8:25 am in citrix, ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, ConfigMgr 2012, ConfigMgr SP2, ConfigMgr V.next, 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)

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 http://support.microsoft.com/kb/837374

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