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.

Windows 10 enable Developer Mode error 0x80004005

We want to use the new Windows Subsystem for Linux (Beta) feature that was included with the 1607 build of Windows 10. To do that, you have to enable Developer Mode. But when we tried, we would get the error:

"Developer mode package failed to install. Error code 0x80004005"

The articles I've found that address this error refer to versions that are using a non EN-US language. That is not the case in our organization. In our case, our group policy settings were preventing the OS from downloading the package from Microsoft Update. The following is a workaround that has worked for us. Just be sure to reverse the settings when you're done.

• Launch regedit.exe and modify this key:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
• UseWUServer to 0 (to disable), restart
• Enable Developer Mode, restart
• Enable Windows Subsystem for Linux (Beta), restart
• Launch regedit.exe and modify this key:
• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
• UseWUServer to 1 (to enable), restart

Hope this helps you as well.

ConfigMgr wake-up proxy and port security

FYI, got the below message from one of our network guys. This involved another location, not us (thankfully!). Bottom line, if you're implementing port security, do NOT use ConfigMgr wake-up proxy:

We ran into a really “interesting” issue this week.  The SCCM guys decided to implement the SCCM “wake-proxy” feature on the SCCM.  Not quite the normal magic packet WOL procedure.  This has the SCCM server hit specific machines, which then go and hit the machines in their vlan.  However, these “manager machines” also spoof the mac addresses of the machines that go to sleep in their vlan in order to keep the MAC alive in the switch tables.

This is quite fun when you have port-security turned on that limits the number of mac addresses on the ports!  We had random machines dropping off the network, DHCP issues, etc.  It was quite fun to chase down what exactly was going on.  The only indication that we saw was that ports were showing multiple MAC addresses when we knew that there was only one device connected to it and it was not running a VM.  Wasn’t even logged into.

Fortunately, something ticked the back of my mind about a feature they were thinking about implementing on the SCCM and we were able to put the pieces together.  Otherwise, we would still be scratching our heads over this.

Bottom line?  DO NOT implement SCCM wake-proxy with any sort of port-security enabled.  Better yet, just don’t implement wake-proxy at all.

Here is a discussion we found afterwards, once we knew what to look for.
https://supportforums.cisco.com/discussion/11835361/mac-address-flapping-and-sccm-wake-proxy

I worked with ALU TAC all afternoon on this.  The only weirdness that we could see was that the packet capture showed that the computer was sending out replies to ARP packets that were not for his MAC address.

“Cannot edit the object, which is in use by ‘username’ at Site ‘configmgr site’

If you've ever been in the middle of editing an application and had the ConfigMgr console crash, you've likely seen this message.

myitforum.com has a quick and easy way to unlock the object so you can get back to editing! Article is linked below, but here are the two queries to run in SQL Server Management Studio:

This query gets the ID of the locked object:
select * from SEDO_LockState where LockStateID <> 0

This query will delete the locked object, allowing you to get access again:
DELETE from SEDO_LockState where LockID = ‘<LockID of the record identified in the previous query>’

http://myitforum.com/myitforumwp/2013/02/22/unlocking-configmgr-2012-objects/

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