SCCM 2007 Client troubleshooting - Part 2: Client Push installation

David Stein Thu, Apr 11 2013 system center, systems management 0

In the second part of my SCCM 2007 Client troubleshooting series I will cover Client Push installation problems.

Author
Recent Posts

David is an author and consultant, working for Endurance IT Services in Virginia Beach, Virginia, specializing in Microsoft enterprise systems and Business Process Automation.

Symptoms ^

Windows Event Log shows errors for client installation failures with event iD 53, and may often be preceded with events with “000004b3 - “No network provider accepted the given network path.”
The ccm.log file on the site server contains entries similar to the following:
7260 (0x1C5C)3/2/2013 12:11:31 AM
…
WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account CONTOSO\cm_client_installer (000004b3)SMS_CLIENT_CONFIG_MANAGER 7400 (0x1CE8)3/2/2013 12:11:34 AM
…
ERROR: Unable to connect to remote registry for machine name "WS0052", error 53.SMS_CLIENT_CONFIG_MANAGER 660 (0x0294)3/2/2013 12:11:35 AMERROR: Unable to access target machine for request: "WS0052.KRC", machine name: "WS0052", error code: 53SMS_CLIENT_CONFIG_MANAGER 660 (0x0294)3/2/2013 12:11:36 AMStored request "WS0052.KRC", machine name "WS0052", in queue "Retry".SMS_CLIENT_CONFIG_MANAGER

If the issue is related to File and Printer Sharing for Microsoft Networks is not installed, or is configured incorrectly, you may also see an error that says:

“Error 67 – The network name cannot be found”

If you start seeing a pattern such as client push installations begin failing around a close date and time, it may be caused by the Client Push Installation account being locked-out. This can occur if the password has been changed, or a user or process has attempted to invoke the account using an incorrect password too many times. This can be evident if you see “Error code: 5” in the ccm.log on your site server, within the entry for each failed installation attempt. Error code 5 indicates security access was denied for the account being used to perform the installation.

Potential causes ^

Incorrect Client Push Installation settings
Client Push Installation account doesn’t have sufficient access rights on clients (it needs to have local administrator rights on each computer on which you want to push the installation)
Client Push Installation account isn’t allowed access by Group Policy “Restricted Groups” settings (if used)
Client Push Installation Active Directory account was modified
Client Push Installation account is locked out
Network connectivity issues
The ADMIN$ share is not present or not using default permissions
DNS or WINS name resolution issues
Server Service is not running on the client
Corrupted WMI stack (particularly on Windows XP clients)
Target computers are not in a trusted Domain

Event Log error messages

Solutions ^

If your environment uses Group Policy “Restricted Groups” to control membership in the local Administrators group on client computers, make sure that you include the Client Push Installation account. A quick test is to manually add the account to the local “Administrators” group on a test computer, then run GPUPDATE /FORCE and check that it’s still a member of that group. If not, you need to review your GPO settings. TIP: Most GPO-related errors will appear in the Windows “System” Event log within the event ID range of 7000-7999, so filtering can be very helpful in isolating those kinds of problems.
Dive into the SCCM Client logs, especially ccmsetup.log and client.msi.log. These are found under the %WINDIR%\System32\ccmsetup\ folder on x86 clients, and under %WINDIR%\ccmsetup\ on x64 clients.
Run WMIDIAG utility to verify WMI stack integrity. This seems most prevalent with Windows XP computers and especially those where users have local Administrator rights by default. There are some recommended hotfixes which can help mitigate the possibility of WMI corruption. (see LINK)

A Word of caution ^

It’s almost too easy to complain about log files, yet they are valuable and quite often the most useful tool you’ll find to isolate and eliminate problems. The client logs under %WINDIR%\System32\CCM\logs (or %WINDIR%\SysWOW64\CCM\logs), are indeed a goldmine of information to help you troubleshoot most any Configuration Manager client problem you may face. However, it’s tempting to react to the first thing you find in the first log file you open. Stop! Always look at several logs before taking any action. The reason is that in many cases, what looks like it is caused by something related to one log file is actually a derivative problem caused by another issue which may be reported in a different log file.

For example, you may find a client that repeatedly reports it cannot communicate with the Management Point, and doesn’t seem to be getting policy updates from another. It could be that the client certificate is invalid or missing, which would show up in the CertificateMaintenance.log file. Looking at the ccmexec.log all by itself could easily give a misleading picture of what real problem could be.

Once installation issues are eliminated, the next step is to diagnose the operational aspects. Start with ccmexec.log, and LocationServices.log as a bare minimum. Then I recommend looking at all the other logs, and don’t overlook the backed up copies with the date stamps in their file name.