Managing Linux clients with ConfigMgr 2012 R2

Back to ConfigMgr main menu

System Center Configuration Manager 2012 SP1 introduced an exciting new feature - the ability to manage UNIX and Linux clients. The list of supported operating systems has grown since that initial release. You can find the full list (and the names of the installation files) in the "Client Requirements for Linux and UNIX Servers" section of this TechNet Library article.

Supported Configurations for Configuration Manager

The following operating systems are supported:

• Red Hat Enterprise Linux (RHEL) 4,5,6,7
• Solaris 9,10,11
• SUSE Linux Enterprise Server (SLES) 9,10,11
• Centos 5,6,7
• Debian 5,6,7
• Ubuntu 10.04 LTS,12.04 LTS,14.04 LTS
• Oracle Linux 5,6,7
• HP-UX 11iv2,11iv3

Further information can be found in this TechNet article:

How to install the clients on Linux and UNIX computers

Client Push installation and automatic client push are not supported on non-Windows clients. You have to download the client installation files and manually copy them to the Linux servers. You then execute the installation manually. At that point you can retrieve hardware and software inventory. You can also automatically deploy updates and RPM files to the servers using traditional ConfigMgr packages and programs.

Please browse the following sections for details on Linux management. I have used a Red Hat Linux 6.5 Server (RHEL 6.5) for these labs.

Copying ConfigMgr client files to the Linux server

Installing ConfigMgr client

Linux client - machine policy and hardware inventory

Linux client - software distribution and patching

Issues I've encountered with Linux Management 

ConfigMgr 2012/ SCCM 2012 - add boundary for Direct Access clients

Back to ConfigMgr main menu

Many of us have seen the problem. We have configured our laptops to use Direct Access and we never see them again. The ConfigMgr 2012 client is installed but has never received it's policy or reported correctly.

This is the dreaded ConfigMgr client that has never received policy.

Only two actions.

What is the problem? The problem is that ConfigMgr is not allowed to send a policy to these devices as they do not belong to any of the known boundaries. The good news it that this is easy to fix. We have to configure an IPv6 boundary.

It's easy to get the information we need. Open the properties of one of your Direct Access clients.

See the IPv6 Prefixes.

Create a boundary for each IPv6 prefix.

New boundaries.

Restart the SMS Agent Host on the client to speed things up. Now examine the PolicyAgent.log file.

We see activity.

The policy is now being downloaded to the client.

Success - healthy client

See here for additional tip for finding your IPv6 Prefix.

Upgrade to MBAM 2.5

MBAM 2.5 was released with MDOP 2014 on 13th May 2014. This was an eagerly awaited release as it added functionality which transformed MBAM into a truly enterprise grade encryption product. In particular it now allows administrators to force users to encrypt their drives (I previously blogged about this here).

This blog post describes an upgrade from MBAM 2.0 SP1 to MBAM 2.5 but can be a reference for upgrades from other versions.

Have a look at the official documentation before you start.

Getting started with MBAM 2.5

http://technet.microsoft.com/en-us/liBRary/dn645302.aspx

Deploying MBAM 2.5

http://technet.microsoft.com/en-us/liBRary/dn645316.aspx

Deploying Server Infrastructure

http://technet.microsoft.com/en-us/liBRary/dn645380.aspx

Configuring MBAM 2.5 Server features

http://technet.microsoft.com/en-us/liBRary/dn645343.aspx

Validating MBAM 2.5

http://technet.microsoft.com/en-us/liBRary/dn645383.aspx

Upgrading to MBAM 2.5  from Previous versions

http://technet.microsoft.com/en-us/library/dn645354.aspx

This last TechNet Library document tells us the steps required to upgrade to MBAM 2.5 from each of the earlier versions.

 OK. Let's crack on. I carried out the following steps to upgrade my stand-alone MBAM environment to V2.5.

Step 1.

Identify the previous version.

MBAM Agent 2.0           --> 2.0.5301.1

MBAM Agent 2.0 SP1   --> 2.1.0117.0

 I see that my current version is MBAM 2.0 SP1 by looking in Programs & Features.

Step 2.
Back up the databases.

My attitude towards backups is - "I'd prefer to be looking at it than looking for it".

Please back up the databases before you start.

Step 3.
Uninstall previous MBAM version (don't worry - the databases will remain intact).

Step 4.

Update the MOF files

Even if you have already done this for a previous version you must do this step again. The MOF files for v2.5 are very slightly different (you have to look closely to see this).

Edit CONFIGURATION.MOF file

http://technet.microsoft.com/en-us/library/dn645321.aspx

Edit the SMS_DEF.MOF File

http://technet.microsoft.com/en-us/library/dn656927.aspx

See confirmation of the difference when you import the new SMS_DEF.MOF file.

Step 5.

Install MBAM 2.5

Step 6.

Configure MBAM 2.5

You have some choices to make (similar to previous versions).

Installation and configuration completed. See how it tells us that the databases already exist.

Note that I had a problem with prerequisites - required for v2.5 but not my previous version.

Step 7.

Update Group Policy

Have a look at "Deploying MBAM 2.5 Group Policy Objects"

http://technet.microsoft.com/en-us/library/dn645317.aspx

Download MBAM 2.5 Group Policy templates from here

http://www.microsoft.com/en-us/download/details.aspx?id=41183

Extract the admx and adml files and copy them to Sysvol on a Domain Controller.

Add the Group Policy Management feature (if you haven't already done so).

New MBAM 2.5 template

You can now force a user to encrypt

Step 7.

Upgrade clients

You can upgrade clients by creating and deploying a ConfigMgr application.

Step 8.

Test, test, test before rolling out to production.

ConfigMgr 2012 & Intune: Known authentication issues

There are some really cool new authentication features in Azure and ADFS. Unfortunately they don't play very nicely with Windows Intune and they can be really difficult to troubleshoot if you don't know what the problem is. There are no log files that can point you in the right direction. It just doesn't work.

I've recently seen two of these issues on customer sites:

When you use Multi-Factor Authentication and enroll a device with Windows Intune, you receive the error “This request couldn’t complete”
 
Workaround: Turn off Windows Azure Multi-Factor Authentication for the Windows Azure subscription you use with Windows Intune.

(Edit 25th November 2014: Azure Multi-Factor Authentication is now supported by Intune)

Windows Phone 8.1 devices fail to enroll with Windows Intune when device authentication is enabled in ADFS

Workaround: Disable device authentication on the ADFS server by unchecking "Enable device authentication" in Edit Global Authentication Policy

The workarounds aren't too clever. The feature is not supported - turn it off.

Here is another one (although I haven't seen this one in action)

When you enroll a Windows 8.1 device that must authenticate to a proxy server, the enrollment process fails with no visible indication as to the cause of the failure

Workaround: For Windows 8.1 devices that must enroll on a network that requires use of an authenticated proxy server, configure and save the credentials for the proxy server prior to enrollment of the device.

These issues have been documented in the "Release Notes for Windows Intune" 

http://technet.microsoft.com/en-us/library/jj662694.aspx

Alternate Login IDs cannot be used with ConfigMgr 2012 and Windows Intune

Back to ConfigMgr main menu

(Edit 17th May 2015: This issue has been resolved by Microsoft and Alternate Login IDs are now fully supported with the ConfigMgr/Intune hybrid solution. This involved updates to the Intune service. The WiKi article (referenced below) has been edited to reflect this. Thanks for the information Stefan Schörling and Jörgen Nilsson.)
 
I hope that this blog post helps other Consultants to avoid the trap that I fell into. "Alternate Login IDs" are a really cool new feature of Windows Server 2012 R2 Update. They are described in detail here

DirSync: Using Alternate Login IDs with Azure Active Directory

The process involves:

• Modifying the DirSync attribute flow for UserPrincipalName for provisioning/sync 
• Leveraging the Alternate Login ID feature of AD FS for Single Sign-On authentication

The concept is particularly useful for customers that cannot or will not change their on-premise UserPrincipalNames to use a different routable domain (changing the UPN is one of the first steps we have to do when deploying ConfigMgr/Intune). It works really well to authenticate your users in Azure for Office 365. An AD account with the UPN gerry.hampson@contoso.local can now synchronise with a cloud identity gerry.hampson@contoso.com. Lovely. The end result looks exactly the same as if we implemented using UPNs.

However, it doesn't work with the Unified Device Management solution of ConfigMgr 2012 and Intune. This is because ConfigMgr handles AD user accounts differently. When a user is first discovered all the AD attributes are committed to the ConfigMgr database. This includes the UPN (eg. gerry.hampson@contoso.local). When I add this user to my "Intune Users" collection this change cannot be synchronised to Intune. The CloudUserSync log tells us that the internal AD UPN is being used to sync to Azure. As the DirSync Direct Mapping is not involved in this process it fails - UserNotFound. Of course it does - gerry.hampson@contoso.local does not exist in Azure.

The article above has warned me that I might have a problem:

"If you are an InTune Hybrid customers using the SCCM Connector there may be additional configuration required. Please contact your Account representative for more information."

I contacted Microsoft CSS for this "additional configuration". They were aware of this shortcoming. There is no supported solution at this time - and no estimated time for a possible solution. The suggested workaround is to run a script on the ConfigMgr database to change the UPN for the user accounts to use the public routable domain. Clearly this is not supported so I don't think it's a great idea.

A recent customer engagement had several phases. Phase 1 was an Office 365 migration. They were very pleased to implement the new features so that UPNs did not have to be changed. Phase 2 was the ConfigMgr/Intune solution - guess what - UPNs now had to be changed. It's a real shame because Alternate Login IDs are a cracking new feature.