Wednesday, January 22, 2014

ConfigMgr and the Citrix Identity Store


I've been working in a couple of projects where I ran into this 'problem' or maybe it's 'by design' . Specifically the combination of ConfigMgr 2012 and XenDesktop 5.x/7.x. Microsoft and Citrix made some improvements in the integration of both products, but still there are some challenges.
ConfigMgr integrates with what Citrix calls the Citrix Identity Store. There is not much information on this, but it turns out just to be a file located on the system drive of the VDI that stores ConfigMgr identity information. ConfigMgr also supports storing this Identity store on the write cache if it’s based on a disk. However, some organizations use write cache in RAM, which it obvious seams, is not functional for storing the Citrix identity store.

When I shut down the golden image and prepare for a vDisk I run a couple of optimization scripts that remove identity information. Like:
Stop CCMEXEC service
Delete C:\Windows\SMSCFG.ini
Delete SMS certificates

When I do that, no duplicate GUIDs are created in ConfigMgr by machines running from the fresh created vDisk, but each machine registers itself with the same GUID only with a different machine name. The previous registered machine is overwritten by a machine that signs in at a later moment. So effectively there is 1 VDI machine in the ConfigMgr database.

It looks like the Citrix Identity Store file still has some specific machine information (which is copied to the SMSCFG.ini file at startup). What I did was making a logon/logoff policy which copies the Citrix Identity Store file from an SMB share and copies this back at logoff. So basically doing very much the same as we did in SCCM 2007.

All together this is not the solide solution I’m looking for. What is your experience/opinion in this? Very curious because I see and read a lot of different things, but no official solution from Microsoft/Citrix.

Edit: I stumbled onto an older post where someone experienced the same issue. What he did was (at closing image time) delete the file CCMCFG.BAK located in c:\programdata\citrix\pvsagent\LocallyPersistedData. So if you don't delete the file it will restore it's contents at system startup, but the content belongs to the MASTERVDI machine, so no good.
Check: http://www.raido.be/knowledge-center/blog/detail/sccm-2012-and-citrix-provisioning-services
Best solution would be to have a Write cache disk where this kind of machine specific information is stored.

Edit2: I finally found a working solution. So what's the situation. It started with Citrix PVS, the vDisk was configured as cache in RAM with failover on Disk. That means we have a (in this case) 5GB harddisk for storing the pagefile, eventlogs and some other settings like RES cache. As explained earlier a CCMDATA.BAK file is created storing the unique machine information which is exposed to SCCM for identification. So what we want to do is save that information so it stays updated after each reboot. I had to find a way to place that specific file. On a blog someone opted to use a Symbolic Link, bingo! That was what I was looking for. So what it basically does is redirect the CCMDATA location to the D:\ overflow disk. Important is to create the Symbolic Link before the Citrix Xendesktop Agent is installed.
These are the steps involved:
  • Create a folder "SCCM" on D:\
  • Start a command line and go to the location c:\programdata\citrix\pvsagent
  • Type the command Mklink /d /j "LocallyPersistedData" D:\SCCM
Thats it! Works like a charm.

Now when SCCM client infmation is saved is will persist on de D:\SCCM folder. No more duplicate Guids whatsoever.

3 comments:

  1. Hello,
    searching for many weeks for a solution.
    My question is, why is it important to create the Symbolic Link before the VDA installation?

    Next question is about the suggested workaround to delete CCMCFG.BAK: I can't open the folder. Is it by design?

    ReplyDelete
  2. I have no D-drive. Now what?

    ReplyDelete
  3. We run a community that promotes massage and leaves reviews, so why don't you come in and take a look?
    More info

    ReplyDelete