Skip navigation

Tag Archives: configuration manager client

CM 2012 Linux Clients…

Post updated 1/24/15

With the SP1 release of Configuration Manager 2012 support for certain Linux distributions as a client platform has been introduced.  Interestingly enough, they’ve added a WMI type mock up that the client uses to interact with and gather data from these varied distributions.  It’s not a perfect solution, but certainly a step in the right direction.  I’ve spent a fair amount of time working through some of the Linux client problems (within Redhat) and have built an installer, and service control script, along with cron jobs to overcome some of the faults I’ve seen with the client failing to perform certain tasks in a timely fashion.

Before using any of my code, I recommend reviewing the Linux Configuration Manager installation documentation provided via Technet.  I’d also encourage you to read up on managing these clients from the Technet as well.  It’s fairly straight forward, but as I stated before it’s not a perfect solution.  I’ve found problems with zombied threads of the client on the box preventing policy updates, or needs for random restarts of the omiserver etc.

You are welcome to use parts of or all of the provided code as you see fit in your environments of course:

This first portion is a service control script that works for the Redhat distrubtions of the client.  I place this within the bin of all my assets to give simpler control of the services and for simplified cron entries.

#!/bin/bash

#CM Client Script
#Author: Daniel Belcher
#Date: 8/7/13 Modified: 1/19/15
#This script is intended for automation of services by cron and simpler
#asset management through the command line

#LDIR="/var/log/"
#DATE=`date '+%m%d%y'`
RUID=0
CCMEXEC="/opt/microsoft/configmgr/bin/ccmexec"
if [ "$UID" -ne "$RUID" ]
        then
        echo "User needs to be root to run $0 $1"
                exit 1
fi

start () {
$CCMEXEC
        sleep 1
echo
        exit 1
}

stop () {
$CCMEXEC -s
        sleep 1
echo
        if $(ps aux | grep [c]cmexec.bin) > /dev/null
        then
                kill $(ps aux | grep [c]cmexec.bin | awk '{print $2}')
        fi
exit 0
}

restart () {
$CCMEXEC -s
        sleep 2
                if [ $(ps aux | grep [c]cmexec.bin) ]
                then
                        kill $(ps aux | grep [c]cmexec.bin | awk '{print $2}')
                fi
        sleep 1
$CCMEXEC
        sleep 1
echo
        exit 0
}

trimlogs () {
        if [ ! $2 ];then
                SIZE=2048
        else
                SIZE=$(( $2 * 1024 ))
        fi

rollover $SIZE "/var/opt/microsoft/scxcm.log"
rollover $SIZE "/var/opt/mirorosft/scx/log/scx.log"
rollover $SIZE "/var/opt/microsoft/scx/log/scxcimd.log"
rollover $SIZE "/var/opt/microsoft/scxcmprovider.log"
}

rollover () {
FILESIZE=$1
LOGPATH=$2

if [ -f $LOGPATH ];then
LOGSIZE=$(du ${LOGPATH} | awk '{print $1}')
        if [ $LOGSIZE -gt $FILESIZE ];then
                cat /dev/null > $LOGPATH
                        echo "Clearing entries in $LOGPATH"
        fi
fi
}

policy () {
$CCMEXEC -rs policy
        sleep 1
echo
        exit 0
}

hinv () {
$CCMEXEC -rs hinv
        sleep 1
echo
        exit 0
}

sinv () {
$CCMEXEC -rs sinv
        sleep 1
echo
        exit 0
}

case "$1" in
        start)
                start
        ;;
        stop)
                stop
        ;;
        restart)
                restart
        ;;
        policy)
                policy
        ;;
        hinv)
                hinv
        ;;
        sinv)
                sinv
        ;;
        trimlogs)
                trimlogs $2
        ;;
        *)
                echo $"Usage: $0 (start|stop|restart|policy|hinv|sinv|trimlogs)"
                exit 1
esac

This next portion is a simplified installer script that can be used to build a unified installer for your environment that I’m currently using (it also places the script from above, and imports the cron jobs I’ve created).  It’s still required to place the client install files in the folder with this script of course:

#!/bin/bash

RUID=0
MP="management.point.server.com"
SITECODE="ABC"
if [ "$UID" -ne "$RUID" ]
        then
        echo "User needs to be root to run $0"
                exit 1
fi

if [ -f "fix-lib.sh" ]; then
        ./fix-lib.sh
fi

./install -mp $MP -sitecode $SITECODE -clean ccm-Universalx64.tar
        cp configmgr /bin/
#               crontab cm-crontab

sleep 5
configmgr stop
        sleep 30
cp scxcmprovider.conf /opt/microsoft/omi/etc/
if [ -f "/opt/microsoft/omi/scxcmprovider.log" ]; then
        echo "Moving scxcmprovider.log to /var/opt/microsoft/"
                mv /opt/microsoft/omi/scxcmprovider.log /var/opt/microsoft/
fi
configmgr start

These are the cron entries, to be used as an example:

#---Begin Configmgr Jobs---
0 0 * * 2,4,7 configmgr restart
1 * * * * configmgr policy
0 12 * * * configmgr hinv
0 8 * * 3 configmgr sinv
0 * * * * configmgr trimlogs 5
#---End Configmgr Jobs---

For more information regarding cron and what these entries mean, please read this.  They do a nice job of explaining this in a fairly straightforward manner.

Putting it all together….

This following link contains the tar.gz that can be used to install from.  Be mindful to read the README file and update the cm-installer script before you begin to insure you are pointing to a proper site.

Redhat CM12 Client Installer.

A further note that the Red Hat install I’m using here is based off the universal x64 binaries and will work for a lot of different distributions. Be sure to verify your distribution against the required package and substitute as needed.

CM client quick guide…

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.

  1. Trace32 Log Reader
  2. SCCM Client Center
  3. 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: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