Symbolic Links to the rescue

Lately I needed a solution to redirect System Center Endpoint Protection 2012 R2 definition updates to a alternative location. The situation was it was installed on a VDI machine which means the C-drive is non-persistent.
So I created a brand new vDisk with the latest definition updates and brought it online. The first day the definition updates are all current, but after a restart of the VDI, it gets back to the initial state. It's not recommended nor desirable to create a new vDisk every day, but I wanted to stay current with the updates. So every day the VDI needs to download more definitions and is not current at startup.

I came up with a solution to use a Symbolic Link to redirect the definition updates to a persistent writecache or overflow disk.
So before the Endpoint Protection solution in installed I created a folder on the D-drive to store the updates.
Then I created the SymLink on C:\ProgramData\Microsoft

Mklink /d /j "Microsoft Antimalware" D:\SCEP

So what this does is create a Symbolic Link named "Microsoft Antimalware" and connect it to the actual location D:\SCEP. For the OS the Symbolic Link looks like any ordinary folder and is threated that way. Also when you browse through the folders it looks like your in the folder, while your actually browing D:\SCEP. So easy to setup and yet so powerfull!

So when the Endpoint Protection client is installed and downloads the definition updates, the updates are placed in the "Microsoft Antimalware" location which is.... right the D:\SCEP location. So now you have an up-to-date AV solution in your VDI deployment.

System Center Endpoint Protection 2012 R2 policy issue

Recently I came across this issue about SCEP update definitions not being applied on (in my case) Citrix VDI computers.

Errors in the C:\Windows\CCM\Logs\EndpointProtectionAgent.log
Failed to apply the policy C:\WINDOWS\CCM\EPAMPolicy.xml with error (0x80004005).
Failed to apply policy with error 0x80004005, retry number : 1 after 60 second.

But mainly visible in the Management Console.

Luckily there are some community colleagues who dealt with this issue before, I did not solve my issue, maybe because we use streamed vDisk, or because this issue already existed for a long time. Any way many people benefit from the solution.

See Henk's blog for a solution.

Edit: Another solution could be to remove the gpt.ini (C:\Windows\System32\grouppolicy) because it became corrupt.

Installing Citrix Provisioning Services Agent during ConfigMgr OSD deployment

The PVS Agent on a VM is necessary to create the vDisk in Citrix PVS. In this small post I describe the steps to take in order to get this successfully deployed during a ConfigMgr OSD TS.

Create a folder containing the following information. Also check the correct processor architecture (x86/x64). The the PVS_Device.exe (or PVS_Device_x64.exe) is copied from the PVS media/ISO.

The .sys files are copied from a machine where the PVS agent is already installed on the following location: c:\Program Files\Citrix\Provisioning Services\drivers


The install.cmd executes and logs the following:

set currentdir=%~dp0

"%currentdir%PVS_Device.exe" /S /v/qn" ALLUSERS=TRUE REBOOT=SUPPRESS /l* %WINDIR%\Temp\CitrixPVSDeviceTarget.log"

copy "%currentdir%CFsDep2.sys" %Windir%\System32\Drivers /y
copy "%currentdir%bnistack6.sys" %Windir%\System32\Drivers /y
copy "%currentdir%CNicTeam.sys" %Windir%\System32\Drivers /y
copy "%currentdir%CVhdMp.sys" %Windir%\System32\Drivers /y


Hope this helps some of you.

Cheers, Niels

Installing Citrix XenDesktop VDA Agent in ConfigMgr 2012 TS

Recently I have been struggling a little to get the XenDesktop VDA agent installed correctly during a ConfigMgr OSD deployment. I ended up with the following solution:

Create a folder (x86 and/or x64) and copy the following folders from the Citrix installation media. The XenDesktop installation will look for additional information in the other folders, so they are needed as well. Based on the installation parameters even more folders could be necessary.

Additional create a install.cmd with the following parameters:

set currentdir=%~dp0

SET OPTIONS=

SET OPTIONS=/QUIET

SET OPTIONS=%OPTIONS% /NOREBOOT

SET OPTIONS=%OPTIONS% /MASTERIMAGE

SET OPTIONS=%OPTIONS% /COMPONENTS VDA

SET OPTIONS=%OPTIONS% /CONTROLLERS "controller1,controller2"

SET OPTIONS=%OPTIONS% /OPTIMIZE

SET OPTIONS=%OPTIONS% /ENABLE_REMOTE_ASSISTANCE

SET OPTIONS=%OPTIONS% /ENABLE_REAL_TIME_TRANSPORT

SET OPTIONS=%OPTIONS% /ENABLE_HDX_PORTS

if "%PROCESSOR_ARCHITECTURE%"=="AMD64" PUSHD "x64\XenDesktop Setup"

if "%PROCESSOR_ARCHITECTURE%"=="x86" PUSHD "x86\XenDesktop Setup"

START /WAIT XenDesktopVDASetup.exe %OPTIONS%

This will install the VDA client with the correct parameters.

Hope this will help you out.

In the next blog I will add information on how to install the Citrix Provisioning Services Agent Software, as this is combined in many installations when deploying a VDI solution.

Cheers, Niels

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.