Windows not activated after OSD, ConfigMgr client not fully installed

I saw this email the other day on the Windows - Higher Ed mailing list:

I have run into a strange issue that I have not encountered before. I am trying to image a new Dell Precision T1700 desktop with Windows 8.1 using SCCM. I have imported all the drivers from the Dell CAB into CM. The machine images fine, loads software, joins the domain, etc. When I login, it fails to have the CM client fully installed, doesn't see our KMS server for activation, and oddly enough, is missing all the event logs that are normally found under “Applications and Services”. 

The exact same thing had happened to me the day before imaging a Dell OptiPlex 9020. The cause was a recent Microsoft security update that required two restarts. These updates sometimes will completely kill your task sequence, but sometimes will allow the image process to complete, only to find oddities like the emailer mentions above.

An easy workaround is to inject the problem updates directly into your WIM and update the distribution point in ConfigMgr. This way they won't cause any reboots during the task sequence. You can also just inject all updates if you choose (I do, as it makes the imaging process go a bit faster), but I've heard some users say they've had issues with this.

There are a couple ways to do this, one is using the DISM tool, which works great, but is done via command line. The other is to use the built-in ConfigMgr feature, Schedule Updates, which uses a GUI and is really easy. I prefer easy.

This should resolve this issue. Let's hope Microsoft doesn't release any more of these double restarters, but I'm sure they will. You can keep track of the known troublemakers here.

H/T to ConfigMgrBlog (although this is not just a Windows 7 issue)

Removing features from Office 2013 during imaging

Problem: Office 2013 is built into our base image, but some of our lab computers need Outlook and Lync removed.

First, I should say, this is not possible. You cannot simply remove Office features during the imaging process. However, there is a workaround.

What you need:

• Your custom Office installer that excludes Outlook and Lync (or whatever feature you're trying to exclude)
• The SilentUninstallConfig.xml file

In our scenario, we have a few labs that need a different Office configuration, plus some additional apps that are not included in our standard image. I set up groups for these areas in the TS (see image below) with settings only to run if certain conditions are met (ComputerName Like XXX, for example).

Create your SilentUninstallConfig.xml file, or download it here. 

SilentUninstallConfig.xml:

Place it in the ProPlus.WW folder in your Office share (be sure to update the content on your DP!).

Add a Run Command Line step in your TS before your Office 2013 custom install:

setup.exe /uninstall ProPlus /config .\ProPlus.WW\SilentUninstallConfig.xml

Be sure to include the path to your Office share in Start In:.

You're all set! This step only takes a few minutes and your custom Office 2013 install will work as expected.

PowerShell script to disable computers in Active Directory, update the description, and move to a disabled OU

We have always disabled stale AD accounts using a list of computers that hadn't logged onto the domain for a certain number of days (rather than just disabling them without the list). This allowed us to make sure we weren't disabling any known good computers.

We also moved the computer to a disabled computers OU and updated the computer description to indicate when it would be safe to delete the computer account.

We had been using a VB script to disable accounts, but it was unreliable. It never seemed to take care of every computer on the list, and I would have to manually disable these computer accounts that it missed.

This script also was fairly large and complex. Enter PowerShell! The script below was modified slightly from a script I found in the comments of this article. The script performs the following actions:

• Reads in a list of computers (c:\Scripts\ADCleaner\computers.txt) to be disabled.
• Updates the computer description to "ITSS - Delete on xx/xx/xxxx". The date it sets is 90 days from the current date.
• Disables the account
• Moves the account to the Disabled - PC & User folder in AD
• Logs the action (c:\Scripts\ADCleaner\computers.log)

This should only require minimal modification to work in your environment. Download script below.

AD-Disable.ps1.txt

$Today = Get-Date
$Desc = "ITSS - Delete on: " + $Today.AddDays(90)

$Computers = Get-Content c:\Scripts\ADCleaner\computers.txt

ForEach ($Computer in $Computers)
{ $ADComputer = $null
$ADComputer = Get-ADComputer $Computer -Properties Description

If ($ADComputer)
{ Add-Content c:\Scripts\ADCleaner\computers.log -Value "$Today - Found $Computer, disabled and moved to Disabled - PC & User OU"
Set-ADComputer $ADComputer -Description $Desc -Enabled $false
Move-ADObject $ADcomputer -targetpath "ou=Disabled - PC & User,dc=csuchico,dc=edu"
}
Else
{ Add-Content c:\Scripts\ADCleaner\computers.log -Value "$Today - $Computer not in Active Directory"
}
} 

Dell OptiPlex 9020 Windows 8.1 OSD Black Screen, No Cursor

When we tried to image a Dell OptiPlex 9020 with Windows 8.1, the screen would go black after applying the drivers, and we never got a logon screen. I had heard of this issue, but people would also get the mouse cursor. We were not. I tried multiple driver cabs from Dell, all had the same issue.

First, I disabled the 9020 driver step:

I ran the task sequence again, and the system imaged fine. There were only 3 devices missing drivers on the small form factor, and 2 on the tower. I was able to apply those from our existing extracted driver cab. 

I noted the missing drivers and then disabled all the 9020 drivers excepts these 4:

Both versions of the 9020 started imaging properly. I had one more issue, though. The deployment would fail after hanging on installing software updates. I found this article which recommends updating your WIM with the software updates to avoid this issue. That did the trick, and our 9020's are imaging happily!

Changing the ConfigMgr 2012 size and location

One of our labs requires different cache settings than the rest of the systems in our organization. I found some simple VB Scripts and PowerShell scripts that should accomplish this. Unfortunately, these would work when I ran them locally on the machine, but they would not run properly if deployed as an application.

As it turns out, modifying client cache location via app deployment does not work, because you're running the app from the existing cache location.

Rick Jones, a contributor on the ConfigMgr mailing list suggested creating a batch file that copies the VB Script to another folder and calling it from there. It's a nice little workaround!

Here's what I did (details below):

• Create a file called ChangeCacheSettings.cmd
• Create another file called ChangeCacheSettings.vbs
• Use the batch file to call the VBS file

Details of each file:

ChangeCacheSettings.cmd:

@echo off

MKDIR "C:\CCMCache"

:paths
SET loc=%~dp0

COPY "%loc%ChangeCacheSettings.vbs" "C:\CCMCache" /Y

cscript "C:\CCMCache\ChangeCacheSettings.vbs"

ChangeCacheSettings.vbs (mostly borrowed elsewhere online):

On Error Resume Next

'Sets cache size and location
Dim UIResManager 
Dim Cache 
Dim CacheSize
Dim CacheLocation

CacheSize=20480
CacheLocation="T:\"

Set UIResManager = CreateObject("UIResource.UIResourceMgr")

Set Cache=UIResManager.GetCacheInfo()

Cache.TotalSize=CacheSize
Cache.Location=CacheLocation

'Set registry key for detection method
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ 
strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\CustomSettings"
strValueName = "ConfigMgr-Cache-Config"
strValue = "TRUE"
oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

'Sleep 5 minutes to allow time for for this portion of the script to complete 
WScript.Sleep 300000

'Clean-up - Delete the C:\CCMCache folder
strPath = "C:\CCMCache"

DeleteFolder strPath

Function DeleteFolder(strFolderPath)
Dim objFSO, objFolder
Set objFSO = CreateObject ("Scripting.FileSystemObject")
If objFSO.FolderExists(strFolderPath) Then
 objFSO.DeleteFolder strFolderPath, True
End If
Set objFSO = Nothing
End Function

'Sleep 30 seconds to allow time for this portion of the script to complete 

WScript.Sleep 30000

Adding the sleep command ensures everything executes properly. 5 minutes for the first one may seem excessive, but the same guy that offered this method recommended it, it worked for me, so I stuck with it.

Also, note that I did not specify a folder name for the cache folder. It will default to "ccmcache", in this case T:\ccmcache. If I specified T:\ccmcache in the script, it would have ended up being T:\ccmcache\ccmcache.

Building the Application

Create a new application, and set ChangeCacheSettings.cmd as the program in your deployment type. Set your detection method as follows:

• Setting Type: Registry
• Hive: HKLM
• Key: Software\CustomSetttings
• Value: ConfigMgr-Cache-Config

There are other ways to set your detection method. You could use a dummy text file, or a number of other options. This one was just easy for me to do.

Lastly, I added return code "1" as a success, as that is what is returned. By default, it's not included in the return codes.

Deploy to your collection as required, and you're set!

Task sequence fails with 0x80004005 - error while retrieving policy

One of our technicians was getting this error on two Dell OptiPlex 980's. WinPE would boot, he would click Next, then instead of getting the task sequence selection window, it would bomb out with the error above.

I found many possible solutions, and some were pretty extreme (deleting the MP and re-adding it, rebuilding packages, etc.). I'm glad I didn't try the most extreme solution first. As always, start simple!

I found this article which suggested it might be a date/time issue. We checked the BIOS, and the date/time was way off. After setting it to the correct date & time, the task sequence window came up and he imaged with no issue!

Microsoft .NET Framework 4.5 not installing during OSD

I was trying to deploy .NET 4.5 during my OSD task sequence, as another app required it. At first, it seemed like the other app was the issue, as it would take the full 120 minutes of time to run, then wouldn't install. I hit F8, ran CMTrace, then opened the AppEnforce.log file and noticed this error:

Unmatched exit code (16389) is considered an execution failure.

It sure is! I had bundled this as an application, and the program was running "NDP451-KB2858728-x86-x64-AllOS-ENU.exe" /q /norestart. This should work. It did not. In fact, besides the error, it ran this step pretty fast. The .NET 4.5 framework tends to take a long time to install, so this was definitely not right.

Buried deep in this TechNet article is a response that suggested bundling .NET 4.5 as a package instead. So I did, and created a program inside with the same command line (minus the quotes), and it installed properly! The application that required it also installed properly.

Having trouble deploying an app? Try it as a software package instead and see what happens!

EDIT: See comment section for an alternative to this using Application instead of Package.