SCCM PXE OSD for tablets using external USB NIC adapter

At the client I'm working for at the moment one wants to deploy multiple Dell Venue Pro tablets. The problem, or challenge if you like :), with these devices is the lack of an onboard NIC. Luckily there are multiple suppliers who deliver USB to RJ45 adapters or dockings to overcome this problem. For Dell Venue Pro tablets you have to have a specific build type of this adapter which they write about here.

So once we have a valid USB to RJ45 adapter we are good to go for a PXE deployment. At this moment we only have 1 USB - RJ45 adapter and multiple tablets to deploy, so what to do?
Mark Morowczynski and Neil Potter wrote this very nice article How to Use The Same External Ethernet Adapter For Multiple SCCM OSD which is the basis of this blogpost. The article includes a script for managing deployment on multiple tablets with this single USB - RJ45 adapter.

Bottomline is that the MAC address which is assigned to the connector is unique, but if you deploy multiple devices with it, there wil be some mess in your SCCM database. So we need to ensure the tablet we deployed is registered in the SCCM database, but with another MAC address. This is where the Wifi NIC comes in.
Basically we have to register the MAC address of the Wifi NIC in the SCCM database and overwrite the USB-RJ45 connector mac address. That is what the script exaclty does. But for the script to work we also need an active connection to the wireless network. This is were I had some trouble.

The steps that got me a working Wifi connection during OSD are as follows:

Import Wifi profiles:

Netsh wlan add profile <sourcelocation>\profilename.xml (e.g. c:\Wifi\Wifi_Profile.xml)

Restart computer: speeks for itself

Connect to Wireless network:
cmd.exe /c netsh wlan connect name=Wireless-Network-Name

NB, the steps to create a Wifi profile are explained in Mark Morowczynski article.

So the import profile step went well, I had to restart the computer (maybe a net stop wlansvc & net start wlansvc would suffice also) and then I had to specifically connect to the Wireless network. Only then I got my wireless network config and an IP address. I then could run the powershell script at the end of the Task sequence and succeed.

Before you deploy the next tablet, don't forget to clear the PXE deployment from the device if you used a deployment type of required, otherwise you won't be able to deploy other devices from the same USB-RJ45 connector.

ConfigMgr Cumulative Updates

Every now and then Microsoft releases Cumulative Updates. Twitter explodes on the new release, like everyone is going to deploy the update without a doubt.

However: when I read the Microsoft support article I come across the following lines:

A supported update is available from Microsoft Support. However, this update is intended to correct only the problems that are described in this article. Apply this update only to systems that are experiencing the problems described in this article. This update might receive additional testing. Therefore, if you are not severely affected by these problems, we recommend that you wait for the next service pack that contains this update.

So, I found that non of these apply to my customer(s). Should I apply the update anyway, or wait for the Service Pack to come?

The only things I see here are the additional testing and administrative burden that are involved applying the CU.

So what is your advice or way to go? Please leave your comments, just a line will do, I'm curious.

Thx!

WIM error deploying captured OEM image

Recently I have been struggling to capture a Thin Client (Windows Embedded Standard 8) image from a Dell Wyse device, specifically the D90D8 model.

These where some of the errors in the SMSTS.log:

Installation of image 1 in package P01000xx failed to complete. Permissions on the requested may  be configured incorrectly. Access is denied. (Error: 80070005; Source: Windows)

Failed to run the action: Apply Operating System Image. Permissions on the requested may be configured incorrectly. Access is denied. (Error: 800070005; Source: Windows)

WIM error:C:\_SMSTaskSequence\TSEnv.dat. Permissions on the requested may be
 configured incorrectly. Access is denied. (Error: 800070005; Source: Windows) Unable to apply (0x80070005)

Dell delivered the device preinstalled using an OEM license. Because of that we chose to capture the image to be able to deploy through ConfigMgr. Installing a non OEM licensed Windows Embedded version would raise the costs, and also extra effort by finding the right drivers.
Dell secures it's images thoroughly using certificates and secure boot. So when I prepared the image for capture using USB media and the Thin Client rebooted, it was unable to find the boot device. Apparently the capture preparation changed some settings which interfere with Dell's security policies. So eventually I prepared a PXE boot and did the capture manually using imagex, very easy and succesfull.

However, since the preparation didn't finish some leftovers stayed behind on the Thin Client and where captured in the image. This caused issues when deploying the WIM image. For example the folders C:\_SMSTaskSequence, C:\SMSTS still existed. Once I removed these from the image

• dism /mount-wim /wimfile:"D:\Captured Image.wim" /index:1 /mountdir:D:\Mount
• Removed leftover folders
• dism /unmount-wim /mountdir:D:\Mount /commit
• Updated DP's

Now I am good to go and the errors went away. Deploying like crazy!!

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.

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.