- How to deploy a scripted application installation with SCCM 2012 - Mon, Sep 23 2013
- How to deploy an MSI package with SCCM 2012 - Mon, Aug 19 2013
- SCCM 2007 – General client troubleshooting tips - Tue, Aug 6 2013
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.
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.
Helpful links
- How to Install Configuration Manager Clients Using Client Push
- How to Install Configuration Manager Clients Manually
- How to Troubleshoot Advanced Client Push Installation Issues
- Overview of Configuration Manager Client Deployment
- Troubleshooting Configuration Manager Client Issues
- Prerequisites for Configuration Manager Client Deployment
- Log Files for Managing Configuration Manager Clients
- Configuration Manager 2007 General Supported Configurations
- Configuration Manager and Name Resolution
- TechNet - WMI Troubleshooting Tips
- MSDN – WMI Troubleshooting