Unix and Linux support in ConfigMgr 2012 SP1

ConfigMgr 2012 isn’t just for Windows management anymore. ConfigMgr 2012 SP1 brought with it some very cool additional capabilities – one of them being the ability to directly manage UNIX and Linux clients. Now with the recent release of ConfigMgr 2012 SP1 Cumulative Update 2, the story gets even better. Managing UNIX and Linux servers is not as full featured as managing Windows systems but the capabilities are compelling and well worth the ConfigMgr administrators time to check out. Let’s take a look

What does it exactly mean that ConfigMgr 2012 SP1 supports UNIX and Linux? What distributions are supported? What features are supported? Why do I care as a ConfigMgr administrator? How is the ConfigMgr 2012 SP1 client for UNIX and Linux different from the Windows client? All valid questions that we will address shortly but let’s deal with the basics first.

Supported Distributions
ConfigMgr 2012 SP1 provided support for the following UNIX and Linux distributions

*Supported at initial release of SP1. Supported added for the remainder post SP1 release.

Supported Features
OK, cool – so quite the range of supported UNIX and Linux environments. So what about features – what can you actually DO with the ConfigMgr 2012 SP1 client on a UNIX or Linux machine?

Hardware Inventory
Software Inventory (via Hardware Inventory)
Software Distribution
Endpoint Protection (Linux Systems)
Unified Reporting
Maintenance Windows

Hardware inventory on a UNIX and Linux system is quite similar to what you might see on a Windows device. The one real difference in the SP1 release was that no way existed to customize hardware inventory. With the updated client, covered shortly, that problem is fixed and hardware inventory is fully extensible! And, just like a Windows client, hardware inventory gathers its information from WMI. What? WMI on a UNIX and Linux system. Yes. The ConfigMgr 2012 UNIX and Linux client installation actually creates a WMI instance on the UNIX or Linux system. More on that in a bit!

The software inventory capabilities of the UNIX and Linux client are derived from hardware inventory collection and are limited to the list of installed programs present on the UNIX or Linux systems – very similar to the Add/Remove programs view in Windows hardware inventory. There is no ability to inventory specific files or file types on a UNIX or Linux system.

Software Distribution to UNIX and Linux systems is accomplished using the traditional package model. The new application model is not supported for software deployment to these systems. So with all of the excitement around the application model, the package model still very much has relevance. The real issue is deciding which one to use on systems that support both. In most cases, the application model will be preferred but the package model should still be leveraged in some cases - often to deploy drivers, scripts, etc.

Inclusion of Endpoint Protection support for the Linux distributions allows full antimalware support for these systems.

Why do I care as a ConfigMgr administrator?

A simple answer to the ‘Why do I care’ argument is – you own ConfigMgr and, as a ConfigMgr administrator, you have extensive experience managing Windows systems so why not extend that capability to managing UNIX and Linux systems? In the current IT environments that exist in most organizations today, being able to show additional value with existing resources can only be a good thing! One question that may be on your mind is whether you have to learn UNIX and Linux to effectively manage those systems through ConfigMgr. There will be some learning that will be required but in no way do you need to be a full UNIX or Linux administrator to effectively leverage ConfigMgr to manage these systems. After all, the management concepts are similar – the only real difference is implementing the management. Let me say at the outset that I in no way consider myself an expert – or even proficient – at UNIX and Linux administration – but I am very proficient at ConfigMgr so with the ConfigMgr client am able to make UNIX and Linux sing! As you will soon see, the ConfigMgr client on a UNIX or Linux system is little different from the ConfigMgr client on a Windows system. The biggest hurdle is getting familiar enough with the UNIX or Linux system to know how to operate effectively. I’ll try to help you with that with a few hints below.

Other reasons that you may care to manage UNIX and Linux systems is the unified view this will bring to systems in your environment. Now not only can you deliver metrics on your Windows systems but UNIX and Linux as well!

The Unix and Linux client

The UNIX and Linux client is not distributed with the ConfigMgr 2012 SP1 or even the cumulative update 2 source. The client can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=36212. The screenshot below shows the UNIX and Linux files all downloaded into the same directory

Notice that there are separate files for some of the supported UNIX and Linux versions but not all supported platforms have their own unique installation files. Why? Good question. The answer is found in the last couple of files called the Universal installer. This Universal installer supports installing the ConfigMgr client on all supported Linux platforms – for the UNIX platforms you should continue using the unique files for each distribution. In the list of files you see for specific files for some Linux distributions – such SLES and RedHat. These files are the original release of the ConfigMgr client and not the updated one provided by the Universal client installation.

Working with UNIX and Linux
As already stated, I by no means consider myself a UNIX or Linux guru. In fact, working with UNIX and Linux was quite interesting for me. It’s quite unusual for me to sit in front of a computer and be totally lost! J If you are new to UNIX and Linux, you likely will find yourself feeling exactly that way! Let me try to help.

In my lab I run UNIX and Linux systems as Hyper-V virtual machines – and that was the first problem. When I loaded up my first Linux environment my natural tendency was to grab the mouse to try and get things configured. Alas, the mouse didn’t work. I quickly became frustrated because I couldn’t figure out how to navigate with keyboard to even get into a terminal window. Add to this that I didn’t have any network access because the Linux distribution I chose didn’t support the Hyper-V integration components! Argghhhh. Never a quitter I struck out with my trusty Bing search skills and quickly found my way. A summary of those tips below.

1. If you choose a distribution that does not have native support for the Hyper-V integration components you can add them by downloading and installing them to Linux manually. The files and instructions can be found at the links below.

https://www.microsoft.com/en-us/download/details.aspx?id=11674 (Windows 2008 R2 Hyper-V Integration Components)

https://social.technet.microsoft.com/Forums/windowsserver/en-US/0d2c5fa8-682c-4f5d-9fe7-388dd80a7e06/simplified-instructions-for-installing-the-linux-integration-components-into-hyperv-virtual (a nice write up on how to install mouse drivers into a Linux distribution)

NOTE: If you let a native UNIX or Linux person see you using a mouse they will laugh at you! J

2. If your distribution doesn’t support the native integration components for Hyper-V then likely networking won’t work. You can generally get around this by leveraging a Hyper-V legacy NIC.

3. On SUSE Linux, YaST is a fantastic utility for configuring the NIC – as you will see below. Other distributions have their own tools and the generic ones generally work as well. IfConfig is another tool useful for configuring the network – more on that one below as well. Persisting IfConfig settings requires editing the interfaces file as described in https://www.ubuntugeek.com/ubuntu-networking-configuration-using-command-line.html.

4. Putty is your friend! Just like you want to remotely manage Windows systems, you want to do the same with UNIX and Linux systems. Putty allows you to remotely connect to a UNIX or Linux system but only from a command line. Putty is available at https://www.putty.org/

5. WinSCP makes Windows admins feel at home. One of the biggest challenges I faced was figuring out how to connect my UNIX or Linux system to my Windows environment to copy and manipulate files. The instructions for setting up the client will give you some insight on how to do that but when it comes to browsing the system to view log files, understanding the client installation location and more, I found it quite handy to have a tool like WinSCP that will allow seamlessly moving files between a Windows and UNIX or Linux environment. WinSCIP is available at https://winscp.net/eng/index.php.

6. Text editor – VI – get used to it if editing on Linux console. WinSCP will help but unless running root you must use ‘sudo’ (as you will see soon) to save info in some cases – and it’s just easier to use VI. A good shortcut doc to get you started navigating vi is https://linuxservertutorials.blogspot.com/2008/11/ubuntu-command-line-text-editor.html.

The best way to understand how to use these tools to navigate UNIX or Linux is to see it in action – so let’s start from the beginning. In my lab I have two virtual machines – one running SUSE Enterprise Linux and the other running Ubuntu 12.04. The first step with these VM’s is to confirm they are up and running on the network. If you are running in a VM and if your distribution doesn’t recognize the native NIC (such as when running in a Hyper-V environment with a distribution that does not have the integration components included) then you may need to use a legacy NIC in order configure networking.

Let’s start by working through configuring network access for my SUSE Enterprise Linux client. Note that in my lab with the SUSE Enterprise Linux client I am logging on with root – which makes things a bit easier to configure but is also less secure. For the Ubuntu 12.04 system I’ll show configuration running as a non-root account.

With SUSE Enterprise Linux installed, login as root.

To configure networking (and many other things) in SUSE Linux, YaST is a fantastic tool! There is a GUI based version of YaST and a command line version of YaST. Since we are aspiring to be expert UNIX and Linux administrators, we will go with the command line version! J It’s also really easy to use in command line form, which helps. Launch YaST from the command line by typing ‘YaST’ and navigate to configure the network as shown in the next few slides. NOTE: Navigating YaST is easily done with <tab> and <shift><tab>.

Select Network Devices > Network Card

Make sure you use the Traditional method of setup – the other will seem to work but fail when committing changes if you don’t have the required components installed in your setup.

In this case I have two Network Cards – one that is the default but that doesn’t work for me in this setup since I don’t have the Hyper-V integration components – the other was added when I added the Legacy Hyper-V NIC.

To configure the NIC simply navigate to Edit on the NIC you want to configure and fill in the details for the options. The IP address and subnet mask, along with the hostname and DNS information will be most common. Once done, commit your changes and test to ensure you can ping another system on your network.

So now the network is configured in SUSE Linux using YaST. With this done most likely you don’t need to keep the VM up and running any longer – we will connect to it with a couple of extra tools shortly. Now, let’s configure the network on the Ubuntu 12.04 system.

For the Ubuntu system I will login as a non-root account.

YaST does not exist on Ubuntu so instead we will use a more traditional means of configuring the network. This approach should work on most, if not all, Linux distributions.

To get the network configured for a one time use we can use IfConfig from the command line as shown.

Interesting!  Notice the permission denied messages! Remember what I mentioned about logging in with a non-root account? That’s why I don’t have permissions to make this change. I can fix this quite easily by simply adding the ‘sudo’ command at the beginning of the command line.

And that’s it – network is configured as we see by the fact the system is now able to ping other devices on the network.

OK, so your actually not quite done. As long as you leave this session up and running, all is good. If you reboot though the network config is lost. So how do you configure the system to persist your network configuration? It’s actually not that hard but will require that we leverage a text editor and also launch that test editor with administrative permissions. I’ll also use this as an opportunity to explain the config a bit more.

The configuration file we need to modify is /etc/network/interfaces. By opening this file you can view the config but won’t be able to save it unless your editor is launched using sudo. The most ubiquitious test editor on Linux is VI so we can launch VI and edit our file as follows

I’ll select to Edit anyway and we get the file. In my case the configuration has already been added. A couple of things to note here. First, there are additional options for the network config vs. what I showed in the initial example. Second, there are very likely multiple interfaces on the system. You will need to reference and config each one appropriately. The tag, such as eth0, eth2, lo, will identify the config for each specific adapter.

NOTE: I find using VI to be utterly and unnecessarily confusing but once you get accustomed to the basic editing functions, it’s actually not that bad. The key is whether you are in command or authoring mode. Though nor exhaustive, the documentation at https://linuxservertutorials.blogspot.com/2008/11/ubuntu-command-line-text-editor.html is a great help and should be enough to get you to where you can edit and save the configurations you need in this file.

Edit the file as needed – the documentation at https://www.ubuntugeek.com/ubuntu-networking-configuration-using-command-line.html
is helpful for this. After you save if you want to ensure the network adapter configuration information is persisted, reboot and then run the configuration tool to validate, as shown.

OK, NOW you are all done with network configuration. Fun, huh? If we have full network connectivity to our VM’s then at this point there should be no need to maintain an open connection to your VM’s. I have closed my two sessions and will use two other tools to remotely manage my machines – Putty and WinSCP. I find both indespensible – for different reasons. We will use Putty now and WinSCP will come into focus when we begin discussing the client install.

Much like an RDP session in the Windows world, Putty allows remote connect to the command line of Linux machines. I will launch Putty and connect to as many systems as I need. From this point forward I will just use one of my VM’s because the steps forward are identical for whatever UNIX or Linux distribution you may be using.

After I specify the connection information I get connected to the remote system, supply my credentials and I’m in – just as if I were connected to the system locally.

Client Installation

Finally we are at the place where we can begin the client installation. As mentioned earlier, the universal client is the one we want to install on any supported Linux distribution. It has the latest code base and applies across all supported platforms, even when a named installer also exists (shown previously).

There is excellent step-by-step documentation for installing the ConfigMgr UNIX and Linux client. The process is to create a temporary directory, mount the client files from a remote Windows share, change the install mode so installation is allowed, install the client and then cleanup/explore. We will go through these steps here as well but I’ll also use this process to introduce WinSCP.

The first thing to do is create the temporary folder to hold our client files.

With the temporary directory made, the next step in would be to mount the client files from a remote Windows share using the command line below.

mount -t cifs -o username=<User Name>,password=<password> //<Windows computer Name>/<Client File Share> /tmp/CCMClient

This works but I see this as a great opportunity to introduce WinSCP which is an explorer like utility that is perfect for moving files between Windows systems and UNIX or Linux. So let’s use WinSCP to move the client files into the temporary directory. WinSCP is available at https://www.winscp.net.

Launch WinSCP and supply your connection details and credentials.

The connection establishes and opens into an explorer like view. The view here may be different depending on the options chosen during setup.

We will copy our installation files to the /tmp/CCMClient folder using copy & paste.

So the files are now copies and we are ready to continue with the install. So this was just a simple look at WinSCP but you hopefully already see how convenient it is. You can use WinSCP to edit text files, copy the ConfigMgr log file from the UNIX or Linux system to the Windows system to view with CMTrace and more.

With the files copied we will execute the command lines that will ready the Linux system to allow the install and then to perform the client install.

The client install completes – notice the highlighted parts. So what exactly is OMI? OMI is UNIX and Linux equivalent of WMI that Windows administrators will already find familiar. Just like the Windows ConfigMgr client, the UNIX and Linux client makes use of WMI/OMI for storing information for the client and retrieving hardware inventory. We will see this shortly.

So that’s it. The client is installed. If the client is able to communicate properly we will see it show up in the ConfigMgr 2012 SP1 console under devices. Depending on configuration you may need to approve the client. Once hardware inventory completes you will be able to see that reflected in resource explorer for the client, as shown.

If you want to practice with software distribution, that is done via packages. I build a test package using the OpsMgr UNIX or Linux agent.

Just like the Windows client, all of the activity on the UNIX or Linux client can be tracked in the log file. Different from the Windows client, all of the functions of the UNIX or Linux client are combined in a single log. Also, UNIX and Linux clients default to only show ‘Warning’ log entries. This is a different experience from the Windows client and I’ve seen many questions raised on how to read the log and

Interpret meaning. The answer is simple – add more verbosity to the log and it will then read very similar to a Windows client log file.

There are four levels of logging available – error, warning (default), info and trace. Trace is the most verbose level of logging you can have. Like verbose and debug logging, trace logging on a UNIX or Linux system is listed as something that should only be used for troubleshooting. To me, the extra level of logging provided by verbose/debug and trace makes it sufficiently valuable that I leave it on all the time – so if there is a problem I hopefully won’t need to go back and enable logging and again reproduce the issue. Each person will need to decide this for themselves. The most common argument for disabling verbose/debug or trace level logging is to prevent putting extra load on the system. For any modern device the extra load imposed by additional logging will not even be noticeable and provides great value.

To change the log level we will leverage WinSCP again and open the scxcm.conf file at /opt/microsoft/configmgr/etc/

With this level of logging in place we will restart the client and then take a look at the log. The commands to restart and interact with the client to trigger a policy or hardware inventory cycle are below.

Start, Stop, Restart
/etc/init d/ccmexecd start
/etc/init d/ccmexecd stop
/etc/init d/ccmexecd restart

Trigger Client Actions
/opt/microsoft/configmgr/bin/ccmexec –rs policy
/opt/microsoft/configmgr/bin/ccmexec –rs hinv

To take a look at the log file generated in CMTrace we use WinSCP to move the log file to our Windows system and then open in CMTrace.

OK, so one last thing to discuss. I mentioned earlier that the UNIX and Linux client makes use of OMI which is a WMI equivalent for UNIX and Linux. The beauty of this is that this allows ConfigMgr administrators who are already familiar with WMI to be able to apply those skills to the UNIX and Linux client. If we take a look at the ConfigMgr client install folder with WinSCP we will see some familiar territory. Note the highlighted area. If you have spent any time in WMI on a Windows client you will recognize these as WMI namespaces. The ccm and invagt namespace are ConfigMgr specific and the CIMV2 namespace is a system namespace ConfigMgr leverages for pulling inventory.

If we look in the cimv2 namespace we see familiar classes. Not all the classes we would see on a Windows machine – not by a long stretch – but familiar ones nonetheless – and the information in these classes is what we will collect with hardware inventory and what you will see in the console.

If we open a couple of these we will see the data that resides in each. Note that not every potential entry contains a value – same as when viewing this information on a Windows client.

And one more…

And that’s it – that’s the UNIX and Linux client – definitely worth taking a look at and hopefully this helps you along the process. One last thing to mention. As already pointed out, the UNIX and Linux client come as separate downloads. They are not part of the ConfigMgr 2012 media and, accordingly, there is no inbuilt mechanism to install the UNIX or Linux client. It’s really up to you to decide how best to do so – script, manually, whatever. Wouldn’t it be cool if we could do the install very similar to the way we are able to push the client with ConfigMgr? Hmmm…well, glad you think so. One of my colleagues, Neil Peterson, has put together a blog post on using System Center Orchestrator to do just that. The blog post is available at https://blogs.technet.com/b/neilp/archive/2012/10/17/system-center-2012-automating-configuration-manager-client-deployment-to-linux-systems.aspx. If you haven’t started looking at Orchestrator to automate your routine IT processes, you should. Orchestrator is very familiar territory for those familiar with task sequencing and something that should be in the back pocket of every ConfigMgr administrator!

What’s on your mind? Talk back to me by leaving a comment below.

Comments

• Anonymous
  July 29, 2013
  Hi - I'm interested in the extensibility of inventory for *nix clients. Can you, for example, customize it to inventory the list of local user IDs?  I.e. extend similar to customizing the MOF or NOIDMIFs.

• Anonymous
  January 27, 2014
  Fantastic write-up Steve. How about publishing one for MAC clients..

• Anonymous
  July 28, 2015
  Hi Steve, great article. But what happens when you use PKI for client authentication? Do you need to manually enroll the client certificate on the Linux server? I'd appreciate some more info on this topic. Regards,