Good talking about Client Health common issues that we encounter in real world.

Good talking about Client Health common issues that we encounter in real world.   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. SCCM Tools available First up I want to list 3 of the primary tools I use for client side troubleshooting. Trace32 Log Reader SCCM Client Center JSandys CM Startup Script 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:\windows\system32\ccm (32bit) c:\windows\syswow64\ccm (64bit) HKLM\SOFTWARE\Microsoft\SMS\Mobile Client\Product Version (32bit) HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Product 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:\windows\ccmsetup or c:\windows\system32\ccmsetup 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: HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareWks, 1 HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareServer, 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. 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 Source : -http://www.myitforum.com/absolutenm/templates/Articles.aspx?articleid=23741&zoneid=89