UNIX and Linux clients for System Center 2012 R2 Configuration Manager common error wiki
Quick tips for UNIX and Linux
- Linux and UNIX are case sensitive
- To run a program outside the current directory specify the correct path
Installation Pre-requisites
- OpenSSL is required for the ConfigMgr client. OpenSSL is installed by default in all of the UNIX and Linux versions supported by Configuration Manager, so typically this requirement is met unless your UNIX or Linux configuration has been changed to remove or modify the OpenSSL runtime libraries
- When installing the ConfigMgr client, ensure that the user installing the client has root privileges
Logging
The ConfigMgr client creates a log file named scxcm.log. This log file includes details about the client and errors and warnings encountered through use. The error wiki will reference select events found in the log file.
Important paths
Name |
Default |
Non default path |
ConfigMgr Home Directory |
/opt/microsoft/configmgr |
Specified during installation |
ConfigMgr Log Config |
/opt/microsoft/configmgr/etc/scxcm.conf |
<ConfigMgr Home Directory>/etc/scxcm.conf |
ConfigMgr Log File |
/var/opt/microsoft/scxcm.log |
Specified in scxcm.conf file |
Configuration file
The configuration file contains the following text
FILE ( PATH: /var/opt/microsoft/scxcm.log MODULE: WARNING MODULE: scx.client WARNING ) |
Changing log levels
The configuration file can be altered to retrieve additional information when debugging certain problems. To enable a selected log level replace default “WARNING” Text with required level.
Levels supported from least to most verbose are as follows: ERROR, WARNING, INFO, and TRACE.
FILE ( PATH: /var/opt/microsoft/scxcm.log MODULE: WARNING MODULE: scx.client WARNING LOGALLCHARACTERS: x ) |
Enabling extended ASCII
Extended ASCII support on your machine is required to enable this option. Extended ASCII allows logging of additional characters such as mathematical glyphs, along with specific language based characters. To enable the larger character sets with extended ASCII add the LOGALLCHARACTERS line along with an ‘x’
Common errors during installation
Pre-Install validation failed with SHA-2/256
Description |
||
Running preinstall validator ERROR: SHA-2/256 is NOT supported on this platform. Prerequisite tests for OpenSSL failed! Please check OpenSSL version. SHA-2/256 is NOT supported on this platform. Pre-Install validator failed. Please check the version of OpenSSL with CM installation requirements. |
||
Causes |
||
|
||
Resolutions |
||
Please note that ignoring SHA-2/256 validation will result in less secure communication between the client and the management point
|
Permission denied during installation
Description |
|||
./install permission denied |
|||
Causes |
|||
|
|||
Resolutions |
|||
|
Incorrect management point specified
Description |
||||
<DATETIME> Warning [scx.client.locationservices.RefreshKeyInformation:134:16529:140674917541696] Failed to connect to the MP. Will retry again in 60 seconds. $$<LinuxUNIXClient><DATE TIME ><thread number> <DATETIME> Warning [scx.client.locationservices.RefreshKeyInformation:134:16529:140674917541696] Failed to connect to the MP. Will retry again in 120 seconds. $$<LinuxUNIXClient><DATE TIME><thread number>
|
||||
Causes |
||||
|
||||
Resolutions |
||||
|
Common errors in software deployment settings
ConfigMgr Linux/UNIX clients do not support all of the software deployment settings that are available for Windows clients. This includes settings on the Package, settings on the Program, and settings on the Deployment itself. The Linux/UNIX clients are intended for use on Linux and UNIX servers, and in such environments some of the settings are not relevant. In other cases Linux/UNIX operating system limitations resulted in the setting not being implemented.
Doing a software deployment with settings that are not implemented for Linux/UNIX clients can result in two outcomes:
- The setting is ignored, and the software deployment operation proceeds as if the setting is not enabled
- The setting causes an error, and the software deployment operation fails
Full documentation on the settings that are not implemented for Linux/UNIX clients, and the impact of using that setting, is here: http://technet.microsoft.com/en-us/library/jj573943.aspx.
To aid in debugging software deployment errors, some of the common errors that result in software deployment failures are listed below, along with the log file entries that are typically associated with the failure, and the steps to resolve the failure.
Package share settings
An error is generated and the software install fails
Description |
<DATETIME> Info [scx.client.locationservices.LocationServicesEndpoint:125:20572:140345482063632] Not supported location task : LSRefreshLocationsTask $$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
The UNIX/Linux clients for Configuration Manager do not support package share configurations. The client must download the software by using HTTP/HTTPS, and then run the command line from its local cache. |
Resolutions |
1. In the configuration manager console navigate to the Software Library option in the bottom left corner 2. In the left pane under Application Management select Packages 3. Right click problematic software package and select Data Access pane 4. Deselect any options under Package share settings |
After program executes reboot / logoff
An error is generated and the software install fails
Description |
<DATETIME> Error [scx.client.agent.SoftwareDist.SoftDistPolicy:2573:31785:140052393004816] Program completion action SMSReboots is not supported for this platform.$$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
The UNIX/Linux clients for Configuration Manager do not support system restart and user specific settings. |
Resolutions |
1. In the configuration manager console navigate to the Software Library option in the bottom left corner 2. In the left pane under Application Management select Packages 3. Open Properties for failing program in Package 4. Under General change After Running to No action Required
|
Program requires user login state
An error is generated and the software install fails
Description |
<DATETIME> Info [scx.client.agent.SoftwareDist.SoftDistPolicy:2641:23028:140723624218384] User logon requirement is not applicable to this platform. $$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
|
Resolutions |
|
Run another program first
An error is generated and the software install fails
Description |
<DATETIME> Error [scx.client.agent.SoftwareDist.SoftDistPolicy:2928:23859:139690730520336] Dependent policy is not supported for Linux/Unix clients. So aborting this software deployment! $$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
|
Resolutions |
1. In the configuration manager console navigate to the Software Library option in the bottom left corner 2. In the left pane under Application Management select Packages 3. Open Properties for failing program in Package 4. Under Advanced uncheck Run another program first:
|
Assignment schedule requires user login state
An error is generated and the software install fails
Description |
<DATETIME> Error [CCM::Client::Scheduler::Schedule:81:27463:140053674487568] Triggers for Logon/Logoff are not supported on the UNIX/Linux client. Policy will not be processed. $$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
|
Resolutions |
|
Run program from distribution point
An error is generated and the software install fails
Description |
<DATETIME> Error [scx.client.agent.SoftwareDist.SoftDistPolicy:2328:32253:140499233435408] Software distribution on this machine requires running from the local cache, or not running.RunFromDP was provided instead. $$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
|
Resolutions |
|
Software has unmet dependencies
An error is generated and the software install fails
Common errors in program command line
The command line specified in the ConfigMgr Program is simply ‘exec’ed by the ConfigMgr client, starting in a working directory that contains the downloaded Package content.
A number of errors can occur if the command line is not correct. For example, ConfigMgr does not implicitly supply a shell to execute the command, so if your command line includes shell-specific syntax (such as shell built-in commands, output redirection, or pipes), you must specify a shell as part of your command line. Other frequent errors include incorrect paths or incorrect capitalization.
Common description for errors in program command line |
<DATETIME> Info [scx.client.agents.softwaredist.ExecuteInThread:561:6619196:2833] stderr for AID:PID:PrID:X:Y Z:Install is Failed to start child process 'Linux Command' errno=2 $$<LinuxUNIXClient><DATE TIME><thread number> |
Incorrect path specified
Possible Cause |
||||
|
||||
Examples for correct format |
||||
For the filename installer.rpm the following command lines demonstrate proper format based on if the file is distributed or local.
|
Invoking shell for script
Possible Cause |
||||
If running a shell script, ConfigMgr does not automatically invoke a shell. You must explicitly declare which shell the client should use in the command line |
||||
Examples for correct format |
||||
For the filename installer.sh the following are examples of the correct command lines for different shells.
|
Incorrect file name specified
Possible Cause |
||
UNIX/Linux filenames are case sensitive. Additionally, file extensions must be declared in the command line. |
||
Examples for correct format |
||
For the filename HeLloWoRLd.py the following is an example of the correct command lines
|
Content in standard error
Additional log description |
<DATETIME> Info [scx.client.agents.softwaredist.ExecuteInThread:561:18350220:2577] stderr for AdvertisementID:PackageID:ProgramID:<Program ID>: Standard Error from the UNIX/Linux client $$<LinuxUNIXClient><DATETIME><thread number> |
Causes |
|
Resolutions |
|
OpenSSL Libcrypto.so Kernel General Protection Error
The problem is that Centrify installs its own version of OpenSSL and then changes some global defaults to the system's OpenSSL. In order for the SCCM client to work it must link its libraries to the Centrify ones and not the system OpenSSL libraries. A better resolution would be to change the global defaults so that the SCCM client does not need to be modified and uses the system's OpenSSL libraries.
Symptoms
CCMEXEC service will not stay running.
[root@system ~]# service ccmexecd status
Checking for service ccmexec ccmexec.bin is stopped
Centrify is installed on the system.
In the scxcm.log
You see that the client begins to run and discovers the management points.
There are no errors and may only be a couple of warnings about STATEID
The log files ends without error
In the /var/log/messages file the following errors are shown
kernel: ccmexec.bin[xxxx]: segfault at xxxxxx ip xxxxxxx sp xxxxxxx error 15
kernel: ccmexec.bin[xxxx]: general protection ip:xxxxxxx sp:xxxxxxxxx error:0 in libcrypto.so.1.0.1e[xxxxxxxxxxxxxx]
Troubleshooting
To determine if Centrify re-configured OpenSSL run the following commands.
[root@system ~]# locate libcrypto
/opt/microsoft/omi/lib/libcrypto.so.0.9.8
**
**/usr/lib64/.libcrypto.so.1.0.1e.hmac/usr/lib64/.libcrypto.so.10.hmac
/usr/lib64/libcrypto.so.1.0.1e
/usr/lib64/libcrypto.so.10
/usr/share/centrifydc/lib/libcrypto.so
/usr/share/centrifydc/lib/libcrypto.so.0.9.8
****You will see that there is a newer version of libcrypto library in the /usr/lib64/ directory compared to the ones in the Microsoft and Centrify directories.
[root@system ~]# rpm –qa openssl
openssl-1.0.1e-30
****This shows the version of OpenSSL that the OS originally installed.
[root@system ~]# openssl version
OpenSSL 0.9.8w-fips
****This shows that the currently registered version of OpenSSL is the one that Centrify installs and overrides the version that was originally installed on the system.
[root@system ~]# ls -lh /opt/microsoft/omi/lib
libcrypto.so.0.9.8 -> /usr/lib64/libcrypto.so
**
libssl.so.0.9.8 -> /usr/lib64/libssl.so**This will show all the files in the directory. Notice that the libcrypto.so.0.9.8 and libssl.so.0.9.8 files are links to the library files in the /usr/lib64/ directory (the system’s OpenSSL files).
[root@system ~]# find / -name "libcrypto*" -exec ls -l {} \
/opt/microsoft/omi/lib/libcrypto.so.0.9.8 -> /usr/lib64/libcrypto.so
**
/usr/lib64/libcrypto.so -> libcrypto.so.1.0.1e/usr/lib64/libcrypto.so.1.0.1e
/usr/share/centrifydc/lib64/libcrypto.so -> libcrypto.so.0.9.8
/usr/share/centrifydc/lib64/libcrypto.so.0.9.8
**This shows all the libcrypto files on the system. It shows that the Microsoft libcrypto file is linked to the /usr/lib64/libcrypto.so file and that file is linked to the libcrypto.so.1.0.1e library file. It also shows the Centrify libcrypto files are linked to its own version of the libcrypto file (the version that Centrify registers with the system and that overrides the originally installed version of OpenSSL).
Resolution
Now this is a problem because the OS has OpenSSL version 0.9.8 registered but the Microsoft SCCM client is linked to libraries associated with OpenSSL version 1.x. In order to fix this the links to the libcrypto and libssl files need to be changed to point to the Centrify version.
NOTE: The better way to fix this would be to change the global defaults so that the registered version of OpenSSL is the one that originally came with the system.
NOTE: This issue will not be noticed if the OS originally had OpenSSL 0.9.8 installed. Such as CentOS 5 or RHEL 5. I have only seen this issue with CentOS 6.x+ or RHEL 6.x+.
Verify that the CCMEXEC service is stopped.
[root@system ~]# service ccmexecd status
Checking for service ccmexec ccmexec.bin is stopped
**
**
Change the ln (link) reference for both libssl and libcrypto in the /opt/microsoft/omi/lib/ directory.
[root@system ~]# cd /opt/microsoft/omi/lib/
[root@system lib]# rm libssl.so.0.9.8
rm: remove symbolic link `libssl.so.0.9.8'? y
[root@system lib]# rm libcrypto.so.0.9.8
rm: remove symbolic link `libcrypto.so.0.9.8'? y
[root@system lib]# ln -s /usr/share/centrifydc/lib64/libcrypto.so libcrypto.so.0.9.8
[root@system lib]# ln -s /usr/share/centrifydc/lib64/libssl.so libssl.so.0.9.8
Start the CCMEXEC service
[root@system lib]# service ccmexecd start
Starting ccmexec: Starting ccmexec: [ OK ]
[root@system lib]# Logging Configuration File for SCX CM::/opt/microsoft/configmgr/etc/scxcm.conf
Check to see if the CCMEXEC service is running of if it stopped
[root@system lib]# service ccmexecd status
Checking for service ccmexec ccmexec.bin (pid xxxx) is running...
Another solution is to add the following line to the end of the /etc/bashrc file.
export PATH=/usr/bin:$PATH
Then install/reinstall the SCCM client.
Useful Commands
UNIX/Linux ccmexec commands should be run from bin directory inside Config Mgr home directory. Default path is /opt/microsoft/configmgr/bin
Command Line |
Function |
ccmexec –v |
Return the ConfigMgr client version |
ccmexec –rs policy |
Force the ConfigMgr client to run schedule on policy |
ccmexec –rs hinv |
Force the ConfigMgr client to run schedule on hardware inventory |
ccmexec –rs assign |
Force the ConfigMgr client to retrieve all policies assigned to the UNIX/Linux machine |
ccmexec –rs eval |
Force the ConfigMgr client to evaluate applicability for policies retrieved. |
Additional Documentation
Software Distribution http://technet.microsoft.com/en-us/library/jj573943.aspx
UNIX/Linux Log Rotation Wiki