ConfigMgr 2012 Client Install Errors

There are a number of reasons why the ConfigMgr client fails to install… permissions, WMI, environment variables, certificate errors etc. So this post is going to be a collection of the random installation errors that I have come across in my time and how they were resolved. As news ones are identified I will add to this post.

Symptom:

• Client installs successfully (%WinDir%\ccmsetup\Logs\ccmsetup.log)
• Software Center is blank (Client reinstall)
• On a new client install the logs directory (%WinDir%\CCM\Logs) is mostly empty
• Errors can be found in both the CertificateMaintenance.log and ClientIDManagerStartup.log

CertificateMaintenance.log

Crypt acquire context failed with 0x8009000f.
CCMDoCertificateMaintenance() failed (0x8009000f).
CCMDoCertificateMaintenance() failed (0x8009000f).
Raising pending event:
instance of CCM_ServiceHost_CertificateOperationsFailure
{
DateTime = "20140909183201.373000+000";
HRESULT = "0x8009000f";
ProcessID = 5080;
ThreadID = 4824;
};
CCMDoCertificateMaintenance() raised CCM_ServiceHost_CertificateOperationsFailure status event.

ClientIDManagerStartup.log

RegTask: Failed to get certificate. Error: 0x80004005

Resolution:

• On the client open the Services MMC snap-in and stop the SMS Agent Host service
• Navigate to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
• Locate the crypto file starting with “19c5cf”
• Backup the file to a temporary directory and then delete it
• Restart the SMS Agent Host service
• The client should recreate the crypto file starting with “19c5cf” and the go through the registration process

Symptom:

• Client install fails with error code 0x80004004 (%WinDir%\ccmsetup\Logs\ccmsetup.log)
• MSI error code 1789 referenced in the client.msi.log (%WinDir%\ccmsetup\Logs\client.msi.log)

ccmsetup.log

MSI: Setup failed due to unexpected circumstances
The error code is 800706FD
CcmSetup failed with error code 0x80004004

client.msi.log

ERROR: Failed to resolve the account <Domain\Account> (1789)

Resolution:

• On the client open the Services MMC snap-in and ensure that the Netlogon service is set to Automatic and it is running
• Open regedit and navigate to HKLM\Software\Microsoft\
• Delete the ccmsetup key
• Reboot the machine
• Reinstall the client

Symptom:

• Client fails to install with the Couldn’t find an MP source through AD. Error 0x80004005 (%WinDir%\ccmsetup\Logs\ccmsetup.log)

ccmsetup.log

Failed to get assigned site from AD. Error 0x80004005
GetADInstallParams failed with 0x80004005
No valid source or MP locations could be identified to download content from. Ccmsetup.exe cannot continue
Couldn't find an MP source through AD. Error 0x80004005

Resolution:

• Ensure that your boundaries and boundary groups in ConfigMgr are setup appropriately
• On the client ensure that the Netlogon service is running and set to Automatic
• Ensure the client is communicating with the domain properly
• Reinstall the client

Symptoms:

• Client installation fails with error code 1603 (%WinDir%\ccmsetup\Logs\ccmsetup.log)

ccmsetup.log

MSI: Could not access network location %APPDATA%
File %WinDir%\ccmsetup\<GUID>\client.msi installation failed. Error text: ExitCode 1603
Action: CostFinalize
ErrorMessages:
Could not access network location %APPDATA%\.

Resolution:

• Open regedit and navigate to HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
• Change the value for %APPDATA% to %USERPROFILE%\AppData\Roaming
• Reinstall the client (Reboot may be required)

Source found here.

Symptom:

• The client installs successfully however it will not report into it’s management point
• Registration errors can be found in the ClientIDManagerStartup.log
• Client does not show up as having an active client installed in the ConfigMgr client

ClientIDManagerStartup.log

<![LOG[RegTask: Failed to get certificate. Error: 0x80004005]LOG]!><time="<Time>" date="<Date>" component="ClientIDManagerStartup" context="" type="3" thread="5972" file="regtask.cpp:615">

Resolution:

• Backup all files in the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder for Windows 7 or C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys folder for Server 2003
• Remove the (19c5cf9c7b5dc9de3e548adb70398402_ac168ff2-23d3-4a00-bd1d-dd27ff040362) folder
• Restart the SMS Agent Host Service to recreate these certificates
• Client should now register and start pulling down policies

Symptom:

• Client fails to install with error code 80041002 (%WinDir%\ccmsetup\Logs\ccmsetup.log)

ccmsetup.log

MSI: Setup was unable to compile the file DiscoveryStatus.mof
CcmSetup failed with the error code 80041002

Resolution:

• Open an administrative CMD prompt
• Navigate to C:\Program Files\Microsoft Policy Platform
• run the following command mofcomp ExtendedStatus.mof
• Reinstall the client

Microsoft System Center 2012 Configuration Manager Servicing Extension

In December the Configuration Manager Sustained Engineering team officially released their Servicing Extension. This add-on helps administrators keep track of things like the release of new hotfixes and cumulative updates, lists the sites you manage and the current version they are running, a client targeting node that enables you to create queries for rolling out updates to machines and a blogs node that brings the latest updates from Microsoft’s official ConfigMgr blogs all from within the console.

Simply download the add-on from here and install it on a machine which has the ConfigMgr console installed. Once installed, open the ConfigMgr console and then open the Administration workspace and you will now see the Site Servicing node. Expand Site Serving and you will have the following nodes listed – Releases, Site Versions, Client Targeting and Blogs.

Site Servicing – The Site Servicing node displays a summary of the latest updates that have been released, the most recent blog posts from the System Center Configuration Manager Team blog as well as the The Official Configuration Manager Support Team blog as well give you the ability to configure proxy settings as well as display the current version of the Servicing Extension add-on installed.

Releases – The Release node displays a list of updates that have been published for ConfigMgr. You can list all updates or filter between ones specifically for SP1 or R2. Each release entry includes links for the KB article, the URL to download the update plus an option to create a query for the update. (For example to identify all clients missing the update) You can also mark an update or all update entries as Read. 

Site Versions – The Site Versions node will list all sites in your hierarchy and information like server name, site code, site name, base version and cumulative update installed.

Client Targeting – The Client Targeting node allows you to create queries to be used to identify clients for deploying updates.

Blogs – The Blogs node will automatically update as new updates are posted to Microsoft’s officially ConfigMgr blogs. Currently you can filter articles from the System Center Configuration Manager Team Blog and The Official Configuration Manager Support Team Blog. You also have the ability to mark articles as Read.

Overall I think this add-on and the information it provides is a great idea and I hope that this is something that Microsoft will integrate into the product for future releases.

Software Center returned error code 0x0041013 (-2147217389)

I've come across this issue a couple of times after upgrading the ConfigMgr client from 2007 (4.x) to 2012 (5.x) where Software Center will never open successfully and present a the user's applications. The 2012 client will install and seems to start communicating successfully however when a user goes to open Software Center they are presented with the following error:

Software Center cannot get the current status for some of the software. Software Center will list any items with available status. You can press F5 to refresh the view. If the problem persists, contact your help desk.

If you expand the More Information section you get the following error code:

Loading Software Center returned error code 0x0041013 (-2147217389).

No matter how long you leave the client, refresh policies or even after a reinstall the problem persists. After much searching online I finally found a post that referenced the same error code and how to resolve the problem. (My next step was a call to Microsoft so it saved me a bunch of time when I found it) Essentially the problem  stems from the 2007 client failing to uninstall cleanly leaving behind possibly two registry keys that can cause the issue. Check the following:

• Open regedit
• Navigate to HKEY_CLASSES_ROOT\CLSID\{555B0C3E-41BB-4B8A-A8AE-8A9BEE761BDF}\InProcServer32
• Ensure that the default value is set to C:\WINDOWS\CCM\ccmcisdk.dll
• Navigate to HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{555B0C3E-41BB-4B8A-A8AE-8A9BEE761BDF}\InProcServer32
• Ensure that the default value is blank (If not delete the value)
• Open the ConfigMgr client applet and kick off a policy refresh action
• Give it a few minutes (You can monitor the PolicyAgent.log file on the client)
• Once the policy refresh is complete open Software Center and the user should new be presented with their applications

SMS Migration Manager Stops Unexpectedly

Recently I was reviewing site server health in the Monitoring workspace in the ConfigMgr console and I came across the following error that a couple of site servers were reporting pretty consistently. The SMS_Migration_Manager component for each server was reporting the following message:

SMS Executive detected that this component stopped unexpectedly.
Possible cause: The component is experiencing a severe problem that caused it to stop unexpectedly.
Solution: Refer to your ConfigMgr Documentation or the Microsoft Knowledge Base for further troubleshooting information.

On the site server itself you will find the same errors listed in the Application event log and when reviewing the migmctrl.log file (<Install Location>\Microsoft Configuration Manager\Logs) you will see the following:

MigMCtrI: FAILED to CREATE JobManager instance, error = The parameter is incorrect., 80070057
MigMCtrI: FAILED to START WorkltemMgr. error = The parameter is incorrect., 80070057
MigMCtrI: FAILED to INITIALIZE, error = The parameter is incorrect,, 80070057

After some searching online I across this post which outlined the issue and provided information on how to resolve it.

• Browse to <Install Location>\Microsoft Configuration Manager\bin\X64
• Copy microsoft.configurationmanagement.migrationmanager.dll to a temp folder
• Browse to that site's parent a copy microsoft.configurationmanagement.migrationmanager.dll to the server and overwrite the original file
• Open an administrative cmd prompt and navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319
• Run the following:  

 regasm.exe <ConfigMgr Installation Directory>\bin\X64\microsoft.configurationmanagement.migrationmanager.dll /codebase

• You should get the following message in the cmd window

                     Types registered successfully

• Open services.msc and restart the SMS_Executive service

Monitor the migmctrl.log file and wait for the following entries:

MigMCtrI: the workitem queue is full!
MigMCtrI: WAIT 3 event(s) For 60 minute(s) and 0 second(s).

Give the server about an hour and check the log to ensure the errors have gone away. All migration jobs had been long completed and I only had this issue happen on a few secondary sites. I still have not found a root cause for this issue and it has yet to occur again.

Automatic Deployment Rule Fails to Download content

I currently use a Automatic Deployment Rule (ADR) for deploying System Center Endpoint Protection definition updates. Setting up an ADR is pretty straight forward however I was seeing the following error in the ruleengine.log file (Located at <ConfigMgr Installation Directory>\Logs)

Downloading content with ID <Unique Content ID> in the package
Failed to download the update from internet. Error = 1326
Failed to download ContentID <Unique Content ID> for UpdateID <Unique Update ID>. Error code = 1326

There are a few things that you need to be aware of when setting up a ADR:

• The ADR will run in the SYSTEM context
• If a proxy server is in use for internet access ensure that rules are setup appropriately for your site server
• Ensure that the permissions for the file share (Full) and source directory (Modify) are setup appropriately. If your source directory is located on a different server the computer account of your site server will need modify access to the package source directory
• The ADR will use the UNC path to access the share even when the directory is local to that site server

For my setup everything checked out. The site server and the package source were located on the same server so permissions weren't the issue. Proxy server rules were already setup to allow the site server to download the required content for specific sites. I double checked and verified that the site server was indeed able to connect to the URL required yet the problem persisted. This server had been recently upgraded to Server 2012 R2 and I was connecting to it using a CNAME so what I found was that when I was logged onto the server and then browsed to the share using the UNC path (Using a CNAME in place of the server name) I was prompted for credentials. So when the ADR would run it would fail at the point where it tried to access the share for the package source path. With Server 2008 R2 disabling strict name would resolve this problem however with Server 2012 R2 you need to disable loopback checking.

• Open Regedit.exe
• Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Lsa
• Create a new DWORD value called "DisableLoopbackCheck"
• Set the value to “1”
• Test by connecting to the UNC path using your CNAME (If you are still being prompted reboot your server)

Once loopback checking was disabled the ADR ran without issue.

System Center 2012 SP1 Drops

It’s been just over a week since the official announcement that service pack 1 for System Center Configuration Manager 2012 was released. This is a really important release for the System Center teams as SP1 really drives home the idea of unified device management. Service Pack 1 adds support for  Windows Server 2012 and Windows 8, Windows 8 tablet plus added support for Mac OS X, Linux and Unix platforms. This is exciting for our environment because there has always been a gap with managing the subset of machines running Mac OS X or Linux. Can you manage one of these platforms to the level that you can manage the Windows platform? No. However this is a step in the right direction. Admins want a single pane of glass view for managing their environment – SP1 moves System Center in the direction. Some other features of this release are support for Windows Embedded devices, full PowerShell support, Windows Azure based Distribution Points and the ability to subscribe to email alerts. 
When you dig a little deeper into the CM 2012 release you’ll find added support for user profile and data management with their new User Environment Virtualization product (MDOP 2012) and real time administrative tasks for endpoint protection, network cost support for application delivery, updates to Bitlocker including TPM and PIN, and the ability to deploy Windows 8 applications.

WMI and the ConfigMgr Client

If you still manage Windows XP machines with ConfigMgr I’m sure that you know that 9 out of 10 client health issues are WMI related. Whether it’s the CCM namespace getting corrupt or the entire WMI repository getting corrupt... Windows XP WMI + ConfigMgr = unstable.
Most of the time you can get away with simply deleting the ccm namespace and then reinstalling the ConfigMgr client to correct the problem. (More on that later) However there are times when the fix requires you to rebuild the entire WMI repository – which should be used as a last resort as there could be other applications on the machine that rely on WMI.
After searching around for WMI resources I came across this post which does a great job of detailing different ways to resolve your WMI issues based on your Operating System version. I've used many of these approaches in order to resolve client health issues but I’ve had the most success with the following command:

• From a command prompt run rundll32 wbemupgrd, RepairWMISetup

If you decide that rebuilding the WMI repository is what you need to do follow these steps for Windows XP:

• Open a command prompt and run the following
• net stop winmgmt
• Browse to %windir%\System32\Wbem
• Rename the Repository folder
• Go back to your command prompt and run the following to rebuild your repository
• net start winmgmt

As mentioned before, If you rebuild your WMI repository you run the risk of breaking other applications on that machine that require WMI. A safer method is to simply delete the CCM namespace and then repair the ConfigMgr client. One tool that I now use almost exclusively is SCCM Client Center. SCCM Client Center allows you to do a variety of things but one of the most handy options are it’s client repair options. After you install Client Center connect to the machine in question, (Top left-hand corner) click on the Agent Action menu (highlighted in the screen shot below) and as you can see there are a bunch of actions that you can kick off to repair the ConfigMgr client. Most of the time selecting Delete root \ccm will resolve your problem.



I find myself using this tool everyday for a variety of reasons.

ConfigMgr Reports Prompts for a Password

Out of the blue my web reporting for ConfigMgr started prompting for a password and no matter what account you entered it would be rejected. If you cancelled the prompt you would receive an access denied error. My reporting site was setup properly with all of the correct prerequisites as it had been online for a couple of years. Nothing seemed to work – no recent patches had been installed, logs were clean, permissions looked correct, IISRESET didn’t nor did a system reboot. Reports would also work fine from a local session on the site server. After much digging I finally came across a post on the TechNet forums that resolved the issue. Here are the steps that helped resolve the issue:

·         Open IIS Manager and navigate to your SMS_Reporting site

·         Click on the site and select Authentication under IIS from the main screen

·         From the Action pane select Providers

·         Ensure the NTLM is listed and it is at the top of the list

·         Open a command prompt and run IISRESET

After that I could access reports locally and from a remote session. All the more reason to migrate my ConfigMgr reporting to SQL Reporting Services.

PXE test request failed, status code is -2147467259, Error receiving replies from PXE server

Recently OSD on my primary site server stopped working – but only when connecting via PXE. If I was using an existing boot disk, I could connect and start the imaging process. The PXE control log had the following entry over and over:

“PXE test request failed, status code is -2147467259, Error receiving replies from PXE server”

I assumed that the Windows Deployment Services Server (WDS) service had stopped and all I had to do was restart it and it would start responding to PXE requests. I was correct on one thing, the WDS service had stopped however when I tried to restart the service I got a very similar error in the event viewer as references in this forum post:

Log Name: System
Source: Service Control Manager
General: The Windows Deployment Services Server service terminated unexpectedly.  It has done this 2 time(s).  The following corrective action will be taken in 600000 milliseconds: Restart the service.

Log Name: Application
Source: Application Error
General: Faulting application name: svchost.exe_WDSServer, version: 6.1.7600.16385, time stamp: 0x4a5bc3c1
Faulting module name: wimgapi.dll, version: 6.1.7600.16385, time stamp: 0x4a5be09a
Exception code: 0xc0000005
Fault offset: 0x0000000000032a8e
Faulting process id: 0x1338
Faulting application start time: 0x01cbfecfb154f4f3
Faulting application path: C:\Windows\system32\svchost.exe
Faulting module path: C:\Windows\system32\wimgapi.dll
Report Id: f089f975-6ac2-11e0-9ddc-005056970055

After rebooting the server the same error was logged and WDS would not start. Even after removing the boot image from my distribution points and then adding them back - WDS would still not start. I tracked them problem down to recent driver addition to the WinPE boot image. It looked like when ConfigMgr was recompiling the WIM file it corrupted the image. To resolve this issue I did the following:

·         Remove the boot image from all distribution points (monitoring the distmgr log file)

·         Removed all drivers from the WinPE image

·         Added all our drivers back to the image and allowed it to recompile

·         Added the boot image back to the distribution points (monitoring the distmgr log file)

·         When everything had replicated successfully I was able to restart the WDS service

An error occurred when loading the task sequence

Recently I ran into a problem where I was unable to open and edit any of my task sequences. It didn’t matter whether I was accessing ConfigMgr from a remote console or locally on one of my site servers – they would fail to open. The error that I was getting:

"An error occurred when loading the task sequence"
I tried rebooting the problem site server but still no luck. According to KB2468097 this is caused because the BDD_* WMI classes are no longer correctly registered under the \root\SMS\site_ namespace in WMI.

• Close all of your remote and local SCCM admin console sessions
• Log on to your Configuration Manager server and select Start -> All Programs -> Microsoft Deployment Toolkit -> Configure ConfigMgr Integration
• In the Configure ConfigMgr Integration wizard, select “Remove the ConfigMgr custom action definitions” and then click next to remove all the definitions
• Re-run Configure ConfigMgr Integration again, and select “Install the ConfigMgr extensions”

I also found that my site server needed to be rebooted after following the steps outlined above before the issue was resolved. This problem occurred on consecutive days a few weeks back but has yet to resurface since.

KB982399 - ConfigMgr site server stops responding while processing status messages

I find that from time to time a ConfigMgr site will stop responding. Some of the first symptoms that are noticed are software distribution will stop, site backups fail and you no longer get site status messages. In the Application event viewer you may notice the following error:

A timeout (30000 milliseconds) was reached while waiting for a transaction response from the SMS_EXECUTIVE service.

Generally restarting the SMS Executive service and the SMS Site Component Manger service or rebooting your site server will resolve the issue. (Temporarily) Microsoft has released a hotfix for ConfigMgr SP2 site servers that resolves this issue http://support.microsoft.com/kb/982399 According to the article the issue is caused by a deadlock situation in the SMS Executive service. I’ve applied the hotfix to one of my problematic site servers and I have not experienced a reoccurrence of this issue.

ConfigMgr PXE Certificate Renewal

When I originally setup my ConfigMgr environment setting up my OSD PXE certificaates was kind of a set and forget process so when my deployment team started getting a prompt about an expiring cert I thought "Oh ya I forgot about those."

In order to update your PXE certifcate you need to locate the site system that hosts the PXE Service Point where you want to update the certificate, double click the PSP role, on the database tab select create a self-signed PXE certificate and specify an appropriate date range and then click apply. As soon as you create your new certificate your old one will be blocked. It's just that simple but it's one of those tasks that you probably don't do that frequently.

If you are running in Native mode will have to import your new certificate from your root certificate authority. (CA)

Installing KB977384 ConfigMgr R3 Client Upgrade in a Task Sequence

R3 is the latest feature pack to be released for ConfigMgr 2007 – it is also the first R3 release in Microsoft’s history. The update includes a server side component as well as an upgrade for your ConfigMgr clients. Pushing the update out to your clients is one thing but when it comes to updating your OSD task sequences it gets a little tricky. If you simply attach the update as a install software step or call it from a script during your task sequence the sequence will fail because the R3 update stops the winmgmt service. In order to install the update during a task sequence you must add the correct command line to the installation properties of your ConfigMgr client install step. There are a couple of ways of doing this.

Locate the “Setup Windows and ConfigMgr” step in you task sequence and on the properties tab under Installation properties add one of the following command lines:

PATCH="%_SMSTSMDataPath%\OSD\Package ID\i386\hotfix\KB977384\SCCM2007AC-SP2-KB977384-x86-enu.msp"

Or you might need to specify a drive letter instead of using the SMSTSMDataPath variable

PATCH=”C:\_SMSTaskSequence\OSD\Package ID\i386\hotfix\KB977384\sccm2007ac-sp2-kb977384-x86-enu.msp"

However if you have set the advertisement for your task sequence to access content directly from a distribution point when needed by the running task sequence then you’ll need to change the SMSTSMDataPath variable or your local drive reference to the network location of your R3 patch. Like this:

PATCH=”\\Network Location\ConfigMgr Client Source Files Directory\hotfix\KB977384\sccm2007ac-sp2-kb977384-x86-enu.msp"

Unable to Delete Management Object in ConfigMgr

Recently I was having problem with one of my branch distribution points. I could no longer replicate packages to it and after some investigation I found that it had two machine records. (one was marked obsolete) The problem is that you can't delete the obsolete record until remove the Distribution Point role from the site system. After I removed the Distribution Point role from the server I was still unable to delete the record and this time the console gave me this error:

"Failure deleteing management object"

and if I expanded the details I got:

ConfigMgr Error Object:
instance of SMS_ExtendedStatus
{
 CauseInfo = "9";
 Description = "Error deleting discovery data in SQL";
 ErrorCode = 2168655109;
 File = "e:\\nts_sms_fre\\sms\\siteserver\\sdk_provider\\smsprov\\sspresource.cpp";
 Line = 388;
 Operation = "DeleteInstance";
 ParameterInfo = "SMS_R_System.ResourceId=3090";
 ProviderName = "WinMgmt";
 StatusCode = 2147749889;
};

I found the following post on myitforum.com and I ran the four SQL queries that were posted (about half way down the page) in the forum and I was then able to delete the record.

SELECT *
FROM PkgServers
WHERE NALPath='["Display=\\DP Name\"]MSWNET:["SMS_SITE=Site Code"]\\DP Name\'

DELETE
FROM PkgServers
WHERE NALPath='["Display=\\DP Name\"]MSWNET:["SMS_SITE=Site Code"]\\DP Name\'

SELECT *
FROM PkgStatus
WHERE PkgServer='["Display=\\DP Name\"]MSWNET:["SMS_SITE=Site Code"]\\DP Name\'

DELETE
FROM PkgStatus
WHERE PkgServer='["Display=\\DP Name\"]MSWNET:["SMS_SITE=Site Code"]\\DP Name\'

Windows Update Error Code 80072F8F

From time to time patch installations will fail during our OS deployment process leaving the workstation not fully patched. Once a machine has finished imaging someone from the deployment group will usually do a spot check and connect to Windows Update just to ensure that the workstation is fully patched. Last week I started to notice that many of the new Windows 7 workstations would not connect to Windows Update and get the following error:

An error occurred while checking for new updates for your computer.
Error(s) found:
Code 80072F8F

Checking online I found a Microsoft article that explained that this error usually results from a time mismatch between your machine and the Windows Update servers. However, these workstations were members of our domain and all of the time settings were correct. I found another post referencing root cert problems and the Windows Update error 80072F8F which reminded me of my post about Windows 7 failing to update its root certificates and causing Windows Live Messenger sign-in to fail. After updating to the latest root certificates (KB931125) Windows Update connected just fine.

Problems accessing file shares from Server 2008 R2 using the SMB protocol

My current ConfigMgr infrastructure includes distribution points scattered around North America and Caribbean. We are forced to use a simple file share as these devices don’t support IIS so packages are replicated using the SMB protocol. These remote devices were first used for our SMS environment where my primary site server was running Windows Server 2003 and I had very few problems. Since I have moved to ConfigMgr, where my primary site server is running Windows Server 2008 R2, I have had nothing but grief. Most of the time my site will fail to establish a connection to my remote devices until I reboot the server. The reboot is a temporary fix as the connection problem will resurface shortly. I’m able to connect to the share from other machines and my connection account is a local admin on the distribution points. I can ping the remote device from the site server but when I browse to the share I get the following error:

Error code: 0x80070035
The network path was not found.

After a little digging I came across Microsoft article KB2194664 referencing these exact symptoms. Essentially the Mrxsmb10.sys driver specifies a logon ID the first time that a connection is established to a remote share using the SMB protocol. The logon ID and the name of the server are saved in a server entry of the SMB Redirector. However, the Mrxsmb10.sys driver does not update the logon ID after the initial logon. Any attempt thereafter to use the name from the first connection will fail regardless of the user name. The hotfix referenced on the KB article will resolve this issue and has helped immensely in my environment.

MP needs to reload the hardware inventory class mapping table warnings

Recently during a ConfigMgr upgrade my SMS_MP_CONTROL_MANAGER was littered with the following warnings:

MP needs to reload the hardware inventory class mapping table when processing Hardware inventory. The MP hardware inventory manager cannot find a WMI class definition in the mapping table when processing a report. This should only happen if new definitions beyond those known to the SMS are added to the collected classes.


Possible cause: Inconsistent way the new definitions have been introduced.


Solution: Check that the mapping tables contain the information consistent with the hardware definition tables and that the definitions have been propagated properly.


Possible cause: Corruption of the data base.
Solution: Check the consistency of the data base.

After a little research I found that this is usually caused by clients that have a version of SMS.Def.mof that is out of sync from the version found on the site server. These messages should only happen once per client as they pull down and update the version of their SMS.Def.mof file. In my case I was upgrading from SMS 2003 to ConfigMgr and as more and more clients updated their SMS_Def.mof file these messages started to reside. If you continue to get these messages it would be a good idea to engage Microsoft CSS.

Clearing padlocks on SMS or ConfigMgr objects

During an in place migration from SMS 2003 to ConfigMgr a best practice is to build a new SMS site and attach it as a child so that you can replicate all of your objects, break the parent – child relationship and then upgrade to ConfigMgr. At that point you can decide if everything upgraded successfully, the new site is healthy, all objects have been replicated and then you can migrate your clients to the new ConfigMgr site. For more details on this migration strategy check out Kim Oppalfens’ blog post on how to transition from SMS 2003 to ConfigMgr 2007.


When you have a parent – child relationship any collection that is being replicated from the parent site will be locked and can be identified by the little gold padlock icon under the collection node. Now once that relationship is broken the objects that were being replicated will remain and the padlock should then disappear allowing you change that object’s properties. Once in while some of the padlocks will remain after the relationship is broken leaving the object locked and you unable to do anything with that object.

Sometimes the only way to unlock these objects is run a couple of commands in against your SQL database as outlined in Ed Aldrich's article on myITforum.com.

• Stop the SMS_Executive service
• Stop the SMS_Site_Component_Manager service
• Stop the Windows Management Instrumentation service
• Open Microsoft SQL Server Management Studio and connect to your site database
• Identify the collection ID that still has the padlock icon
• Right-click the database and select New Query
• Type select * from collections and click Execute (Red exclamation point on the SQL Editor toolbar)
• Type update collections set flags='18' where siteID='your collection ID' (Note all collection flags should be either 17 or 18)
• Restart your WMI, SMS_Executive and SMS_Site_Component services
• Open your SMS or ConfigMgr console and the padlock icon should be gone from the collection in question

Server 2008 R2 and wmiprvse.exe crashes

Recently I was checking the health of a couple of my primary site servers and as I was going through some of the logs I noticed in the application event log there where event 1000 application errors that kept reoccurring. It seemed that every couple of days wmiprvse.exe would crash and then restart but with little noticeable effect. After some digging I came across a blog entry describing a problem with SCVMM and WMI. It referenced a wmi hotfix (KB981314) that Microsoft released that deals specifically with event 1000 wmiprvse.exe errors. I decided to install the hotfix on the two site servers experiencing the problem as they are in a staging environment. Since installing the hotfix on both servers the number of wmiprvse.exe crashes has dropped significantly. It’s only been about three weeks but things are looking good…

Config Mgr Client Health Monitoring

One of the most important things in any ConfigMgr environment is the health of your clients. If your machines aren’t reporting in properly you’re dead in the water until you get the issue resolved. Since the ConfigMgr client is such a heavy hitter on WMI problems are not uncommon. For those who can’t afford a solution such as 1E’s WakeUp (which has client health monitoring built in) using a start-up or shutdown script is an inexpensive way of monitoring ConfigMgr client health. There are many scripts published out there but one of the best that I have come across is Chris Stauffer’s SCCM SP2 Health Check Startup Script found at myITForum.com. This script also works nicely during a SMS 2003 to ConfigMgr migration to ensure that all of your machines get upgraded properly. It's easy to configure and with the help of Active Directory can be deployed within minutes.