Error initializing client registration (0×80040222)

I recently had a request from a customer to rename their PCs during an in-place upgrade of WinXP to Win7.  I’ve put together some custom scripts to detect the particular qualifying conditions for when the PC needs to be renamed, and these scripts work just fine (this is an upcoming blog post).

The problem that I ran into was that after completion of the task sequence, the CM07 client was unable to register with the site server.  Thereby it wouldn’t receive policies and did not operate.  The client’s ClientIDManagerStartup.log showed “Error initializing client registration (0×80040222)”.  As part of my troubleshooting, I was able to “fix” the client by deleting the old computer record instance and the generate a new GUID on the client.

Credit to one of my colleagues who was able to identify the scenario when I had overlooked it.  The real problem was that since the PC was being renamed, a Conflicting Record was being created since both the old and new instance had the same hardware ID information.  There are two ways to resolve this situation:

1. Manually resolve the conflicting records
2. Configure the site to automatically resolve the conflicting records

Option 2 is the most desirable since you can set it and forget it….so that’s we did!

 

 

Failed in WinHttpSendRequest API, ErrorCode 0x2ee7

Ran into a situation where all CM07 clients at a particular site were not installed/active within the ConfigMgr primary site.  Digging into the ccmexec.log file on the clients, errors were generated repeatedly with message “Failed in WinHttpSendRequest API 0x2ee7″.  In this particular scenario, I discovered that the client was attempting to communicate with the MP when the error occurred…and that the server’s name was incorrect.  So instead of trying to reach ServerA01, it was trying to reach ServerA (note the missing zero+one at the end of the name).  Turns out that when the Secondary Site was set up, whomever had created the site mistyped the name.

To fix this, the following needed to happen for me to eventually get this to work.

1. Update the Secondary Site’s specified FQDN to be the correct name as ServerA01
2. Uninstall the proxy MP on the secondary
3. Manually delete the SMS-MP records in the Systems Management container.  I had to do this because for some reason the site didn’t have the correct permissions, even though it really did.
4. …wait
5. Reinstall the proxy MP
6. Regenerate new GUIDs for the clients at the site (I used the SCCM Client Center tool to perform this).  I had to generate the new GUIDs because they were not receiving the corrected FQDN server name on their own.

And within minutes, all was clear and clients were functioning again!

ConfigMgr Client GPO Assignment Removal

On a recent upgrade project of ConfigMgr 2007 to 2012, the company I was assisting with the upgrade had previously deployed a group policy to enforce the client assignment to the 2007 site code.  However, simply removing the GPO could not correct the situation as the value was “tattooed” into the registry.  So as part of the ConfigMgr client upgrade, I included the below script to revoke the registry key.

' ***********************************************************
' This script was created by <a href="http://t3chn1ck.wordpress.com/">http://t3chn1ck.wordpress.com</a> to 
' delete the following registry value. The value will prevent 
' the abilityof anSCCM client to become reassigned to the new
' ConfigMgr 2012 site.
' HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\
' GPRequestedSiteAssignmentCode (REG_SZ) = ""
' ***********************************************************
Option Explicit
Const HKLM = &H80000002 Const sRegKey = "SOFTWARE\Microsoft\SMS\Mobile Client"
Const sRegValueName = "GPRequestedSiteAssignmentCode"
Dim oReg, iReturnValue
Set oReg = GetObject("winmgmts:\\.\root\default:StdRegProv")
iReturnValue = oReg.SetStringValue (HKLM, sRegKey, sRegValueName, "")
wscript.quit iReturnValue

SCCM & Cisco NAC

I ran into an interesting issue with a SCCM implementation in an environment that utilizes Cisco NAC to protect their system resources from unauthorized devices.  One of the goals of the implementation was to ensure the SCCM clients could still function when no user was logged into Windows, thus NAC agent not being authenticated with the production VLAN.  In order to accomplish this, ports used by SCCM needed to be opened, allowed, and unrestricted to the SCCM servers.

The issue that we found was when the computer was on the “dirty” VLAN, the SCCM client would switch from being an Intranet client to an Internet client.  Furthermore, the client’s LocationServices log showed that it was failing to locate the MP from AD and the SLP from AD.

Using a network monitoring tool called WireShark, we identified that the client was trying to communicate with AD on TCP port 3268.  This is a normal port used by AD for LDAP.  Checking into the configuration of NAC, it was certainly not allowing communication over that port.  As soon as that was allowed, the SCCM client immediately began functioning to download software updates and SWD packages.  Who knows whatever else was fixed through this discovery…

IIS Bindings and SCCM Software Updates

You may be asking, what does IIS bindings have to do with SCCM software updates.  Well, let me tell you lol.

I’ve stood up a new SCCM infrastructure including site configuration/roles and deployed a few clients.  When testing software updates on a client, software update scan/deployment cycles kept failing.  Upon investigation of logs, the scan were failing with “Scan failed with error = 0x80072efd”.  Furthermore, reporting showed scan error failure code -2147012867.  These errors indicate that the Windows Update Agent could not communicate with the defined source location.

The troubleshooting difficulty is that there are many possibilities of causing this.

• Local GPO “Specify intranet Microsoft update service location”.  When using SCCM software updates, the client sets this local GPO on the client pointing to the WSUS location.  In my case this wasn’t it.
• Windows Firewall blocking the ports used by WSUS, on either the client or server.  In my case this wasn’t it.
• A proxy or bad winhttp settings redirecting the traffic incorrectly from client to server.  In my case this wasn’t it.
• Various other things.

I believed that I had reached the end of the Internet at this point when finally I came across a posting on WindowsNoob that steered me in the right direction.  To fix a different technical problem with WSUS conflicting with Symantec Endpoint Protection, I swapped the Software Updates Component from using ports 80/443 to using ports 8530/8531.  I guess with this change, SCCM didn’t automagically configure the default website in IIS bindings to listen for requests on the newly defined port.

So to resolve the issue, I did the following:

1. Open IIS Manager
2. Right-click on the default website and select “Edit Bindings”
3. Add port 8530 as an IIS binding….and voila it works.

FAQs about Active Directory Domains and Forests with SCCM 2007

Came across this very useful article and FAQs about SCCM in a multi-domain or multi-forest scenario.

http://blogs.technet.com/b/configmgrteam/archive/2010/07/09/frequently-asked-questions-about-active-directory-domains-and-forests-with-configuration-manager-2007.aspx

IIS 7 causing SCCM client install problem

Recently I ran into a problem installing the SCCM client on some Windows Server 2008 R2 systems.  In digging through client.msi.log, I found errors 0×80004005 and 1603.  Steve Schofield, Microsoft MVP for IIS, discovered the problem was with the client install was, for some reason, performing IIS checks on anonymous authentication.  If the authentication is configured to use Application Pool Identity, which was a new feature in IIS 7, then the install will fail.  The workaround is simply to switch to using IUSR, install the client, and switch back to the Application Pool Identity.

This successfully resolved my issues on a dozen R2 servers!  Thank you Steve!!

The original post: http://www.iislogs.com/steveschofield/iusr-account-and-sccm-2007-r3-agent

More thorough explanation: http://www.iislogs.com/steveschofield/iis-7-iusr-account-sccm-2007-client-status-messages-not-working

Hotfix for Windows 7 Extremely Slow Boot Performance

When our company first implemented Windows 7, the performance was quite good and we were impressed.  However, now that Win7 has been in our organization for the last 1 1/2 years, we’re beginning to see a significant performance degradation in boot times.  What was a 1 minute boot time can now be anywhere from 4 to 10 minutes for Windows to get to Ctrl-Alt-Del screen.

In performing analysis on extremely slow boot/login times, I identified both the cause and a Win7 hotfix to correct the issue.  If you are having a similar problem, check out KB2505348 – High CPU usage or a lengthy startup process occurs during WMI repository verification when a large WMI repository exists in Windows 7 or in Windows Server 2008 R2.

One has to chuckle at Microsoft’s titled description on the issue as “lengthy startup process” which in the real world means “so slow that you never want ever EVER shut off your computer because every time you do, you consider making a switch to Linux”.

** Update 10/2/12: there is a newer version for Windows 7 SP1 at http://support.microsoft.com/kb/2617858 **

SCCM 2007 client crashes on Win2k8 R2

If a Win2k8 R2 server should experience an alert from SCOM that the SMS Agent Host (e.g. the client) service is running, then the resolution is to simply restart the server.  It is possible to prevent this on new server builds – Microsoft claims that restarting the server after installation of the SCCM client will keep the issue from occurring.

This alert is generated because the client crashes and then does a self-reinstall to recover from the error.  You can confirm the client is crashing by checking for application event ID 1000 and 1001 for ccmexec.exe or system log event 7031.  Microsoft has confirmed this is a recently discovered issue with SCCM 2007 clients on R2 servers and that the information is currently only published internally.  The root cause is that Microsoft has found a problem in the code, but it is only fixed in SCCM 2011 and won’t be for SCCM 2007.

***Update 8/17/11***
John Nelson may have isolated the cause of the client crash, attributing it to execution of the Resource Monitor. Check out his post at http://myitforum.com/cs2/blogs/jnelson/archive/2011/08/17/158887.aspx

***Update 7/24/12***
Now there is a hotfix available! See http://support.microsoft.com/kb/2724939/en-us

Save Software Inventory Scan XML Files

Sometimes when troubleshooting SCCM client software inventory, it is useful to retain the XML file which contains details on what the scan discovered.  To do this, simply create a file named “archive_reports.sms” within C:\WINDOWS\system32\CCM\Inventory\temp\.  If the scan is just reporting a delta, the file will be small.  But if it is a full SINV scan, then it could be large (the biggest I’ve seen is around 75 MB)