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

A particular subset of SCCM client installation problems are those resulting from attempted Client Push installations. Before attempting to enable this feature, it’s strongly suggested (by Microsoft as well as I) that you test a manual installation. If a manual installation won’t work, you should iron out that problem before proceeding to Client Push installation.


  1. 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.”
  2. 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 AM
    ERROR: 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

  1. Incorrect Client Push Installation settings
  2. 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)
  3. Client Push Installation account isn’t allowed access by Group Policy “Restricted Groups” settings (if used)
  4. Client Push Installation Active Directory account was modified
  5. Client Push Installation account is locked out
  6. Network connectivity issues
  7. The ADMIN$ share is not present or not using default permissions
  8. DNS or WINS name resolution issues
  9. Server Service is not running on the client
  10. Corrupted WMI stack (particularly on Windows XP clients)
  11. Target computers are not in a trusted Domain

Event Log error messages

Event Log error messages


  1. 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.
  2. 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.
  3. 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.

Helpful links


Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account