Error: 80004005 during imaging

I saw this error in smsts.log when installing applications during OSD. AppEnforce.log had no errors.

I then found this error in CITaskMgr.log:

A little more sleuthing in the CAS.log showed the problem:

The cache was not big enough to download all of the required content. You can change your ConfigMgr client install parameters to increase the cache size (SMSCACHESIZE=XXXXX) to resolve this. In my case, I didn't want all clients to have the larger cache size, so I only applied this to one group of systems. In the section where I'm installing these apps, I add a PowerShell script to increase the cache size:

$Cache = Get-WmiObject -Namespace 'ROOT\CCM\SoftMgmtAgent' -Class CacheConfig
$Cache.Size = '20480'
$Cache.Put()
Restart-Service -Name CcmExec

Adobe Acrobat Pro DC installation failure - exit code 1603

I was getting this error when imaging a new machine. Other apps were installing fine. The error itself didn't offer much information.

I modified the command line to include verbose logging:

MSIEXEC /i "%loc%AcroPro.msi" /q /norestart TRANSFORMS="%loc%AcroPro.mst" /L*V "%loc%Acrobat.log"

I ran the install again and looked at the log file. There I found an error regarding Visual C++ Redistributable 2013. The install failed because this was not present.

Adobe kind of buries the workaround in their documentation, but addding "IGNOREVCRT64=1" to the command line ignores the Visual C++ Redistributable 2013 requirement and installs cleanly.

MSIEXEC /i "%loc%AcroPro.msi" /q /norestart IGNOREVCRT64=1 TRANSFORMS="%loc%AcroPro.mst" /L*V "%loc%Acrobat.log"

Class not registered (Error: 80040154; Source: Windows)

After setting up a new ConfigMgr site, I was testing OSD using a migrated task sequence. We use an HTA front end that collects some basic information about the user: department, building, room, role, etc. This HTA is part of a small package we built in ConfigMgr. However, when we selected the task sequence and the package tried to load, the task sequence failed:

A Google search did not shed any light on the issue. That's why I'm posting this blog, maybe it will help some poor soul.

The reason for this error is HTA support is not enabled by default in WinPE. Without it, HTA files fail to run. You can enable this by doing the following:

From the ConfigMgr console, navigate to Overview - Operating Systems - Boot Images. Right click your boot image (we use the x64 image), and select Properties. Click the Optional Components tab and check HTML (WinPE-HTA). We also added a few more options, such as PowerShell.

Once you do this, you will need to follow the steps to update your boot image.

Computer in console not showing client as installed

We found a handful of computers that had the ConfigMgr client installed, but the console was not reflecting this. After some investigation on an affected computer, I noticed the client certificate said "none":

This is not normal. In addition, some of the items under the Actions tab were missing. Fortunately, I found this blog post that contained the solution. 

The computer was stuck in provisioning mode. The simple fix was to change the HKLM\SOFTWARE\Microsoft\CCM\CcmExec\ProvisioingMode registry key to "false", then reinstall the ConfigMgr client.  SEE UPDATE BELOW

NOTE: The safest bet is to reimage the system in question. If the step that removes the computer from provisioning mode didn't work, it's quite possible there were other issues during imaging. But this is a quick fix if you can't reimage for some reason.

H/T Daniel Classon

UPDATE: Thank you to Microsoft MVP and all-around swell guy Nash Pherson for pointing out that the registry method does not entirely remove the computer from provisioning mode. This article shows how to do it properly via a WMI method:

Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false

Or, run the following from an elevated command prompt:

powershell Invoke-WmiMethod -Namespace root\CCM -Class SMS_Client -Name SetClientProvisioningMode -ArgumentList $false

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.

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!

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.