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