So in the world of SCCM there are tons of moving parts and components. I want to take some time to focus on some common issues with client installation and communication issues, as well as a couple of tools that make troubleshooting infinitely easier.
Tools
First up I want to list 3 of the primary tools I use for client side troubleshooting.
Now the first item on that list, trace32 is by far the most valuable tool to the SCCM administrator outside of the console itself, perhaps even more so than the console. It allows filtering, highlighting, real time updates, and just generally makes the logs readable.
SCCM Client Center, this tool attaches to the cm WMI Namespace and allows for nearly full control of the client on the target machine. In terms of remediation, or even testing, there is no reason this tool shouldn’t be installed.
Config Manager Startup Script by Jason Sandys. This script is easily configured for implementation and has fairly rich logging power for a vbscript, it’s also lighter weight than some of the other health scripts. I highly recommend using this for maintaining client integrity, as well as offering an installer tool for the CM agent by secondary or third parties.
The Client
First, lets start with identifying the clients existence on the local machine.
Here’s where to look:
- Control Panel > Configuration Manager (this is one of the quickest methods)
- Task Manager (ctrl+shift+esc) > Processes > CcmExec.exe
- Task Manager > Services > CcmExec
- Control Panel > Admin Tools > Services > SMS Agent Host
- c:windowssystem32ccm (32bit)
- c:windowssyswow64ccm (64bit)
- HKLMSOFTWAREMicrosoftSMSMobile ClientProduct Version (32bit)
- HKLMSOFTWAREWow6432NodeMicrosoftSMSMobile ClientProduct Version (64bit)
This is a list of the primary locations to check for the presence of the client, it’s also useful for finding methods to script around identifying them.
The Client’s Jobs
Now lets discuss what the client does. First lets recognize that the client is just a dictator for the most case, it tells multiple windows services what to do to complete specific tasks. Until we need to break down what services do things specifically lets just treat the client as the primary initiator.
- Policy updates and application
- Manage downloads
- System scans
- Inventory reports
The client and server relationship relies heavily on BITS, Admin shares, RPC (at least for installation), WMI, AD, and WUA.
The client will regularly talk to the server, telling it about any changes it’s had since it’s last conversation, by way of xml. It will also ask the server what it should be doing differently, to which the server sends the client it’s latest policy. The client will review that policy then act, or do nothing depending on if there are any actionable changes.
Actionable changes could be installation of software, OS, OS configuration changes, even changes in the frequency of their conversations. These exchanges of course are called policy updates, and I believe by default they are set to 90 minutes (no real reason to change it either).
Client Installation
There are multiple ways to install the SCCM client, and in a lot of ways, that method will vary depending on your environment. I will stick to the basics and explain the process if done by server initiated push. I will also discuss what is required.
First the server begins by initiating a PUSH, using local admin rights, it will copy down the CCMSETUP.EXE file to either c:windowsccmsetup or c:windowssystem32ccmsetup
A service named CcmSetup is made and it begins transferring the client contents to the local machine and finalizing installation and cleanup of the directory.
A log of the transaction is left in the ccmsetup folder named ccmsetup.log
Once this process is complete, the client will perform it’s first policy update and make it’s active client existence known to it’s respective primary server.
So what if installation fails?
This isn’t a perfect world. If you are pushing into an existing environment, things may have accidentally found there way out of standards and or flat broken.
Lets discuss what is required on a local PC for a successful install:
- Resolvable hostname (proper DNS entry)
- Service account with local admin rights
- RPC access to OS components (such as registry)
- Admin$ shares
- WUA (Windows Update Agent)
Instead of explaining exactly why for each of these, lets explain how to resolve potential problems with each. I also want to treat this as an all inclusive troubleshooting guide for the client, so I won’t limit things to just install failures. Truthfully, if any of these breaks after installation, the client will most likely not function as intended.
Improper DNS entry:
From the local machine there is little you can do to resolve this problem. Two methods that could resolve the problem are:
ipconfig /registerdns
This will attempt to update the DNS records for all adapters of the local machine.
ipconfig /flushdns
This will dump all resolver cache data on the local machine. (long shot, but I’ve seen this clear up client DNS conflicts from the push)
Any additional resolution would need to be done by the Domain Admin on the DNS server with the improper pointer references.
Service Account with local admin rights:
This is a very simple solution. Add the appropriate service account to the local admins group on the client PC. For Installation and operation, this account needs to be set for the client to perform it’s jobs.
RPC Access:
This one can have you scratching your head at times, but a majority of the times it’s tied to a firewall. Make sure that local firewalls have exceptions built in for the SCCM server. When in doubt, disable the firewall software to verify if it’s the culprit or not.
Also ensure that the RPC (RpcSs) and RPC Endpoint Mapper (RpcEptMapper) services are Started.
Some of these changes may require a restart before taking effect so be aware of that while troubleshooting RPC denials. It’s also worth mentioning there are a multitude of applications that could disrupt this functionality, so be sure to thoroughly investigate the machine for potential culprits.
Admin$ Shares:
First off, the service Workstation (LanManWorkstation) is responsible for these shares, as well as all SMB protocols on the local machine. If it’s disabled, you will not have these shares.
One of the most direct methods for enabling admin shares is in:
HKLMSYSTEMCurrentControlSetServicesLanManServerParametersAutoShareWks, 1
HKLMSYSTEMCurrentControlSetServicesLanManServerParametersAutoShareServer, 1
Then restart the PC.
Be aware this setting can be viewed as a security risk, and with that being said, some security software may actively disable them. So treat your evaluation similarly to your RPC troubleshooting.
WUA Disabled:
The Windows Update service being disabled is a fairly simple solution provided there isn’t a GPO forcing it. You can either enable and set the Windows Update service to Automatic (wuauserv). Inside the control panel under Windows Update or Automatic updates set it to automatic.
WUA is responsible for system scans, patching, software delivery, essentially a vast majority of the clients functionality. It is imperative that WUA is enabled.
Bits Admin:
During client installation you may encounter issues with bits failing to download and continuing to re-queue. The issue is generally tied to a stuck job in the bits queue.
From a command prompt you can use
bitsadmin /list /allusers
This will give you a list of jobs, if you see jobs in there:
bitsadmin /reset /allusers
will clear them all out.
For windows XP machines without bitsadmin get it here.
For Windows 7 Machines or Server 08 use the PowerShell module:
import-module bitstransfer
get-bitstransfer -allusers | remove-bitstransfer
For additional bits module cmdlets type:
get-command -module bitstransfer
WMI Failing:
WMI is an integral component of Windows, it could also be linked to issues you might be seeing with WUA being disabled, and with failing clients post and pre install.
The quickest way to verify if WMI is functioning as intended is to check it’s service under Computer Management:
Right-Click My Computer > Manage > Services and Applications > WMI Control > Properties
If you see:
Successfully Connected to: <Local Computer>
Then WMI is functioning correctly. Be mindful though, parts of WMI can fail without the whole of WMI failing, CCM classes/namespaces in WMI could still require a rebuild so be sure to investigate further if the client is installed but not functioning.
Error verbiage that would link to WMI failures will state namespace failures or WMI authentication errors etc. Fortunately repairing a CCM WMI namespace problem is fairly simple.
Open a command prompt:
net stop winmgmt
rename %systemroot%\system32\wbem\repository repository.old
net start winmgmt
Uninstall, or cleanup your CCM/CCMSETUP directories as prescribed in the uninstall section to rebuild the CCM repositories.
If you want to try and rebuild the corrupt namespaces without performing a client uninstall reinstall the following steps can be done from the command prompt as well (requires that a client be installed):
net stop winmgmt
c:
cd %systemroot%\system32\wbem
rename %systemroot%\system32\wbem\repository repository.old
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in (‘dir /b /s *.dll’) do regsvr32 /s %%s
for /f %%s in (‘dir /b *.mof’) do mofcomp %%s
for /f %%s in (‘dir /b *.mfl’) do mofcomp %%s
net start winmgmt
Logs to Read, and Policy Updates
For the official list of log files, go here.
(http://technet.microsoft.com/en-us/library/bb693897.aspx)
I’m going to touch on the more immediate logs for troubleshooting the following issues.
- Health
- Policy
- Connectivity
- Licenses
- Installs
Health:
CcmExec.Log, this log is one of the first stops for suspected bad installs.
ClientLocation.log, this log is a good place to verify that client has a healthy install with a site server.
StatusAgent.log, status messages for client components. Also useful for connectivity issues.
Policy:
PolicyAgent.log, this holds policy request information, very helpful when pulling policy.
PolicyEvaluator.log, this log lets us know know if we are having issues applying policies.
Connectivity:
InternetProxy.log, if you are using unprotected DPs, this is the log to check.
Mpcontrol.log, logs record the state of the management point
LocationServices.log, attempted connectivity to MPs and DPs
Licenses:
Hman.log, if clients aren’t registering this is worth looking into.
Installs:
Ccmsetup.log, client installation happenings are recorded in this log.
Client.msi.log, output from the installer.
That concludes the overview of SCCM client installation and troubleshooting. Happy problem solving. For additional information on the client and troubleshooting check MSDN:
http://technet.microsoft.com/en-us/library/bb693982.aspx
and be sure to get involved with
http://www.myitforum.com/absolutenm/PPLSearch.aspx