ConfigMgr 2012 SP1 client not installing

It has been a while since I posted something on my blog. Last week I was in the process of deploying the new ConfigMgr 2012 SP1 client to my virtual servers at home. These servers already had a ConfigMgr 2007 SP2 client installed but the new client push method does a good job upgrading these clients. Unfortunately I encountered a problem with one server. (This server was part of a Windows cluster hosting SQL 2008 R2 and running Windows Server 2008 R2). When looking at the c:\windows\ccmsetup\logs\ccmsetup.log file I noticed this line: Download Update: Copy job has been queued. It would repeat every 5 minutes.

Of course google is your friend and I found bits of information to resolve the issue however not an entire solution. I verified with bitsadmin what the status was of all jobs with the following command:
bitsadmin /list /allusers. (Please run all commands used in the post as Administrator!).

(Or since that command is deprecated use this powershell command: Get-BitsTransfer -AllUsers).
(Please note that above command needs to have import-module bitstransfer loaded!).

The output showed that there were some problems with the job queue.

Now I figured that running Get-BitsTransfer -AllUsers | Remove-BitsTransfer would remove all jobs from the queue. Right.....?? Unfortunately this was not the case because the jobs were owned by the SYSTEM account. Some people would suggest running psexec with the -s command to remove the jobs. I have found this way to be unsuccesful because I ran into a new error message. This time complaining about not being logged on to the network. What I have found to be succesful is this:

Stop the ccmsetup.exe service!

Create a ps1 file like in my case bits.ps1 and add the following 2 lines to it:

import-module bitstransfer
Get-BitsTransfer -AllUsers | Remove-BitsTransfer

Create a batch file containing these lines:

@echo off
powershell -file "path_to_the_file\bits.ps1"
exit

Now open the windows task scheduler. Create a new task. Give it a name.
Now change the running user to the local SYSTEM account. Select run with highest privileges and change the Configure for to the highest possible OS lever available. In my case it was Windows 7, Windows Server 2008R2.

Under the actions tab, add a new program and point to the batch file which you just created. You can leave the rest default and click OK. Now that a new task has been created, just simply run it. It should clear out the bits queue. You can verify with a powershell the command: Get-BitsTransfer -AllUsers or bitsadmin /list /allusers. Once the queue is empty, remove the scheduled task and manually start the ccmsetup.exe service. Monitor the ccmsetup.log file in c:\windows\ccmsetup\logs. It should have no problems downloading the new client components.

Enable Autologon in MDT 2010

Eventhough my blog mainly focusses on SCCM, I'd like to add a post on how to enable autologon after finishing a TS in MDT 2010. By default, the autologon information which come from your unattend.xml answer file, is cleaned by the LTICleanup.wsf and LiteTouch.wsf script at the end of the TS. To avoid this behaviour, you could comment out the lines that cause this.

Open up LTICleanup.wsf and search for the following line: Clear the autologon registry keys
You can comment out the lines responsible for removing the autologin by adding a ' in from of the line. See the example below:

LTICleanup.wsf:

'//----------------------------------------------------------------------------
'//  Clear the autologon registry keys
'//----------------------------------------------------------------------------
'oLogging.CreateEntry "Removing AutoAdminLogon registry entries", LogTypeInfo
'On Error Resume Next
'oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon", "0", "REG_SZ"
'oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName", "", "REG_SZ"
'oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName", "", "REG_SZ"
'oShell.RegDelete "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword"
'oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoLogonCount", &H00000000, "REG_DWORD"
'On Error Goto 0

LiteTouch.wsf:

'oShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon", "0", "REG_SZ"
'On Error Goto 0

Problem publishing default management point to DNS.

Recently I noticed that there was an issue with getting the default management point published in DNS.

mpcontrol.log showed me this: CMPControlManager::PublishInDNS: DnsReplaceRecordsInSet() failed with status 9001.

Unfortunately google didn't returned much regarding error code 9001. When I started troubleshooting I noticed that manually creating the _mssms_mp_<sitecode> SRV record in DNS also failed. (What a surprise!)

This made me believe it was an issue in DNS. Upon looking at the AD DNS server(s) I noticed the name checking was set to Strict RFC (ANSI) instead of the default setting Multibyte (UTF8). Upon changing name checking to Multibyte (UTF8) and restarting the DNS service I was able to publish my default MP to DNS.

Updates not getting installed during build & capture task sequence

I have seen quite some CM admins struggling with getting the microsoft/windows updates installed during a build and capture TS. Recently I also faced this problem. I was trying to update my win2k8r2 wim image with the latest OS updates. Unfortunately the update part of my TS was not working anymore. It would not find any updates. Deployment of an image would get stuck on downloading updates with 0%). There are a variety of solutions available (KB2509007, SLP, publish default MP to DNS, refresh compliance state, etc.) on the internet however none of these were working for me. Log files on the client showed it was finding the management point for the site code. Log files also show there was a problem with getting the domain policy (gpo) for windows updates. To make a long story short, I changed the join domain account under Apply Network Settings in my TS. It still had an old account set which probably didn't have enough permissions to join the domain. Once I recreated my virtual machine and run my build & capture TS again the updates were finally getting installed. (And some might think I am not using SLP or don't have the default MP published to DNS, but this is not the case!)
Hope it might help others!

Dreadful message about vmci.sys missing after deploying VMware Workstation or Player?

Are you deploying VMware Workstation and/or Player and came across the dreadful You have an incorrect version of driver “vmci.sys”error message? Well I have. Are you like me and think that editing the .vmx file and setting vmci0.present to false is just a quick and dirty solution? You probably deploy these VMware product(s) by extracting the downloaded .exe file with the /e parameter and then use the .msi to kick of the installation. Well, that is how I do it but you have to make sure you also install the "vmwarevmcisockets.msi" for a 32-bit or "vmwarevmcisockets64.msi" for a 64-bit host system or else you will suffer the above mentioned error message! It's also recommend to install all available tools packages that comes with the vmware product(s). And last but not least, since VMware workstation 8 it seems the serialnumber property is no longer being used. One way to prevent the end-user to have to enter a valid product key is to import your volume license key under "HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Workstation\License.ws.8.0.e1.201010".