This is a topic I see quite often as well. Both on the TechNet forums as well as in the facebook groups I follow. So hereby a continuation of my back to basics series, giving you some insights on the Client Push installation process and how to troubleshoot some of the most common issues.
For good measures, find below the prerequisites for using the Client Push installation method:
- The site uses client push installation accounts to connect to computers to install the client. The account must be a member of the local administrators group on the destination computer.
- If you don’t specify a client push installation account, the site server uses its computer account.
- The site needs to discover the computer on which you’re installing the client. At least one Configuration Manager discovery method is needed.
- The computer has an ADMIN$ share.
- The client computer needs to communicate with a distribution point or a management point to download the source files.
Issue #1: No Client Push Account Configured
To start off with something that’s probably seen most often in new environments: A scenario where the account used for client push is simply not configured.
Most client push installation obstacles start off with investigating the site server log file: ccm.log. This log file records any problems from the site server when connecting to the destination computer.
Below picture displays the ccm.log when the client push account is not configured. SCCM then tries to use the site servers computer account, which in return doesn’t have access to the destination computers admin$ share.
“—> Warning: no remote client installation account found”
Make sure to properly configure and verify a client push account. This is done in the System Center Configuration Manager console on the Client Push Installation Properties page, in the Administration work space -> Site Configuration -> Sites
Issue #2: Client Push Account not a local admin
Now that we have fixed the first issue and properly configured a Client Push Account, next common issue is the lack of local administrative rights on the destination computer. Again, monitoring ccm.log on the site server while initiating another client push installation. This time we see that our account is used, authentication is successful but we are still denied access.
“—> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account KM\SCCM_CP (00000005)”
Add the Client Push Account to the local Administrator group on the destination computer. This can be done manually or by using the restricted groups feature within Group Policies. Using Group Policies is the preferred option.
Issue #3: Missing firewall exclusions
This brings me to the third and last (in this post) common issue: Missing firewall exclusions. We have verified that the Client Push Account is properly configured in SCCM and the account is a member of the local administrative group, but we still see errors in the ccm.log when trying to push the client to the destination computer. More specifically, we see following errors:
“—> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account KM\SCCM_CP (00000035)”
“—> Unable to connect to WMI on remote machine “MAB-TEST”, error = 0x80070005.”
Add inbound firewall rules for both File and Printer Sharing and Windows Management Instrumentation (WMI). Again, this can both be done locally on the computer or centrally using group policies. Group Policies is the preferred option.
Now that all the obstacles has been solved, initiating another Client Push installation, ccm.log now reveals that the connection to the destination computer was successful and that the ccmsetup service was started.
Which means that the rest of the process is monitored on the destination computer. More specifically, the log files found locally in C:\Windows\ccmsetup\Logs will be of interest from this point on.
A successful installation will be displayed in the ccmsetup.log
“CcmSetup is exiting with return code 0”