PXE - content location - boundaries

What do these 3 things have in common? Well, When you run a PXE/USB boot, and receive content location errors in the smspxe.log you should have a look at your boundaries.

P0100002 is the boot image being requested.

Most likely the client received an IP-address that is not within the boundaries of the DP from which the content is received. So check you boundaries and add the right site to AD Sites and Services, or add the correct IP subnet to your boundary. The DP will now accept and trust the client requesting the content.

Hopefully this one saves you some time...

Cheers, Niels 

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.