Configuration Manager co-management considerations

Co-management allows you to cloud-attach your Configuration Manager infrastructure. Essentially it enables you to manage Windows 10 devices with the ConfigMgr agent and Intune MDM at the same time. Implementing co-management gives you instant access to invaluable features like conditional access.

I just want to share some information on co-management that I find useful.

Co-management scenarios

My previous understanding was that, without co-management, it was not possible to manage a Windows 10 device with ConfigMgr and Intune at the same time. However, as I recently discovered on a customer site, that is only partially true. It depends on the order.

On a recent customer engagement, I had configured co-management with a pilot collection.

I was very surprised to see co-managed devices in the Azure portal that were not members of the pilot collection. I now understand that it depends on the scenario.

If the ConfigMgr agent is running on a device and the device becomes Azure AD joined, no attempt is made to enrol in Intune, even if automatic Intune enrolment is configured. When co-management is configured, then automatic Intune enrolment kicks in and enrols the device in Intune.

However, what happens if the device is MDM enrolled first? In this case you can install the ConfigMgr agent. The device will be co-managed but will not receive any workloads if it hasn’t been added to a co-managed collection.

In this case you will see a co-management capability of 1, which is what I saw on my customer site. This means that the device is co-managed but hasn’t received any policy. The “real” co-managed devices had a capability of 45. 

Intune automatic enrolment

What happens if my devices are already Azure AD joined but I haven’t configured automatic Intune enrolment? 

I was concerned that automatic enrolment was a one-time thing i.e. when the device is joined to Azure AD it is automatically enrolled in Intune (if that is configured). I was concerned that if automatic enrolment is not configured first then the Intune enrolment doesn’t try again as the device will already be joined to Azure AD.

MDM URLs must be populated on the client before it can be successfully enrolled. These URLs are populated by the automatic Intune enrolment user scopes. When co-management is configured, the ConfigMgr agent periodically checks for these URLs and keeps retrying until they are populated. At that point, the device is enrolled in Intune. It is not a one-time thing.

ConfigMgr client settings

Hybrid Azure AD join, and automatic Intune enrolment are among the prerequisites for co-management. What happens if you configure hybrid AADJ using Azure AD Connect? Do you still need to configure this in ConfigMgr client settings (Automatically register new Windows 10 domain joined devices with Azure Active Directory to = Yes)?

The answer is no. You do not need it. This is a throwback to when you needed a GPO to tell devices to perform a hybrid AADJ. Current supported versions of Windows 10 will automatically join Azure AD if they find a Service Connection Point in Active Directory.

However, this is the default setting and you should leave it alone. If you turn it off, you may block devices from competing the AAD join.

GPO

As stated above you no longer need to configure a GPO to force a hybrid AAD join. For current supported Windows 10 devices, this should happen automatically.

Co-management display changes (April 2020)

There are some changes in the 2004 service release. On the All devices page, the entries for the Managed by column have changed:

• Intune is now displayed instead of MDM
• Co-managed is now displayed instead of MDM/ConfigMgr Agent

Learn more about co-management in the official Microsoft docs

I hope this helps you to understand and configure co-management. Until next time…..

AutoPilot CSV file formatting issues

I've been uploading hardware IDs to Intune for my customer so that the devices can be provisioned using AutoPilot and Intune. We create CSV files in batches of 50 and everything has been going well so far. However the process started to fail today.

Intune would not accept the formatting of the CSV files. 

Each row must have a minimum of 3 columns

The formatting looked ok to me though. It was a CSV file of 50 devices created using the -append parameter.

Get-WindowsAutoPilotInfo.ps1 -OutputFile .\batch1.csv -append

The project leverages Microsoft Teams for collaboration and I subsequently discovered that the files had been uploaded to Teams and downloaded again. This must have caused some subtle issue with the formatting. Once I got the original files I was able to continue as normal.

I've also noticed that a simple edit of the CSV file can cause formatting issues. There was a duplicate line in one of the files but simply deleting the line caused an issue.

In the end I uploaded the file with the duplicate and just accepted the import error.

I hope this helps anyone else scratching their head with AutoPilot CSV formatting issues. My advice:

1. Use the original CSV file only
2. Keep editing of the CSV file to a minimum

Until next time....

Deploying CMG with Enhanced HTTP (my experience)

I've configured a number of Cloud Management Gateways in the past, both for customers and in lab environments. In each case I've added a Management Point and configured it to use HTTPS. I've had to do that to manage Windows 7 clients over the Internet using traditional PKI. Recently I rebuilt my ConfigMgr lab to prepare demos for MMS 2019. As I'll just be using Windows 10 it has given me the opportunity to try Enhanced HTTP for the first time. I had a few problems to figure out along the way (with the help of Nick Hogarth, thanks Nick) but, now that it is configured correctly, everything works really well.

So what is Enhanced HTTP all about?

Traditionally we've used PKI to secure communication in ConfigMgr environments. Microsoft still recommends using HTTPS communication for all Configuration Manager communication. However they recognize that it can be challenging for some customers due to the overhead of managing PKI certificates. By using Azure AD integration we can simplify the process using Enhanced HTTP. In this scenario Azure AD-joined devices can communicate with a management point configured for HTTP. The site server generates a custom certificate for the management point allowing it to communicate via a secure channel. You can read about it here

The ConfigMgr admin doesn't need to do any IIS configuration as this is done in the background. We'll see that shortly.

Enhanced HTTP implementation steps

There are a number of steps which I implemented as follows.

Management Point configured for HTTP client communication

Enable the site option to Use Configuration Manager-generated certificates for HTTP site systems.

The SMS Role SSL Certificate was automatically configured and bound to port 443.

Onboard the site to Azure AD for cloud management

Using the Azure Services wizard.

Configure Azure AD User Discovery

Configure Hybrid AD Join

I was using domain joined devices for testing so I needed to configure Hybrid AD Join. Hybrid AD Join is configured using Azure AD Connect. A Service Connection Point is created during the process.

"Configure device options" was selected.

"Configure Hybrid Azure AD Join" was selected.

The SCP was created.

No further action should have been required because, once Hybrid Azure AD Join is enabled, devices will automatically join to Azure AD by default from Windows 10 Version 1607.

What issues did I experience?

I experienced a couple of issues during the process. In each case it's because I had forgotten to do something.

Firstly my test client could not be detected on the Internet. There were several errors in the CcmMessaging and LocationServices log files.

[CCMHTTP] ERROR: URL=http://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/ccm_system/request, Port=0, Options=1248, Code=87, Text=<null>

Successfully queued event on HTTP/HTTPS failure for server 'GERRYHAMPSON.EMSLAB.IE'.

Post to http://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/ccm_system/request failed with 0x87d00231.

CCMHTTP] ERROR: URL=https://GERRYHAMPSON.EMSLAB.IE/CCM_Proxy_MutualAuth/72057594037927939/SMS_MP/.sms_aut?SITESIGNCERT, Port=0, Options=1248, Code=0, Text=CCM_E_NO_CLIENT_PKI_CERT

Raising event:
instance of CCM_CcmHttp_Status
{
 ClientID = "GUID:76F79FF6-FA18-4E15-AA2F-9A4E71711ACC";
 DateTime = "20190410064418.902000+000";
 HostName = "GERRYHAMPSON.EMSLAB.IE";
 HRESULT = "0x87d00454";
 ProcessID = 3104;
 StatusCode = 0;
 ThreadID = 5368;
};


Also the CMG Analyser failed (it was OK when run against a certificate but not against an Azure AD User).

Failed to get ConfigMgr token with Azure AD token. Status code is '403' and status description is 'CMGConnector_Un-authorizedrequest'.
A possible reason for this failure is the CMG connection point failed to forward the message to the management point. The management point returned the following error: 'Un-authorizedrequest'. Check the specified Azure AD user is successfully discovered.

Troubleshooting

I had to figure out what was wrong and this is where Nick helped me. First I looked at the CMG Analyzer error. It looked pretty clear. "Check the specified Azure AD user is successfully discovered".

Also I could see errors in the CCM_STS.log file on the site server.

AAD user with ID 26800541-daf1-4334-aca0-c1a7d5d25a72 and SID S-1-5-21-3695679697-2106157007-715799775-1106 is not completely discovered

I knew that Azure AD Discovery was enabled but I still couldn't see any users. After I rebuilt the site I had forgotten to enable AD User Discovery. This is also a requirement.

I did that and could successfully run the analyser.

I also had an issue with the test device. It should have automatically joined Azure AD but it didn't.

See the output of the dsregcmd /status command. AzureADJoined: NO

The output also gave more information: The device object by the given ID is not found.

I couldn't understand that. I had configured Azure AD Join in Azure AD Connect which should have synchronized all the computer objects to Azure AD.

I had a look at the Azure AD Connect configuration again and realized that I had forgotten to select the Workstations OU to synchronise. I didn't need to before. I was only interested in users at the time.

After synchronization the device joined to Azure AD.

No more errors in the LocationServices.log file.....

...and in the ConfigMgr console the device was Online over the internet.

It could also be seen as a Hybrid Azure AD joined device in Azure AD.

I hope this helps someone else to configure the Enhanced HTTP solution. Until next time......

Externally publish an internal web app with Azure Application Proxy

EMS Landing page

The Azure Application Proxy allows you to externally publish your internal web apps seamlessly and in a very straightforward manner. You don't need to configure any complicated networking in advance. There are just a couple of steps involved in this process:

1. Prerequisites
2. Azure AD Application connector
3. Add and publish web app

1. Prerequisites

There are a few prerequisites so that you can implement the solution.

• You need to have an Azure Global Administrator account.
• You need Active Directory Premium licenses for the users that will consume the published app.
• The server on which the connector is to be installed requires Windows Server 2012 R2 or later.
• Turn off IE Enhanced Security on the server (installation of connector only).
• The ports in the screenshot below must be opened outbound from this server to msappproxy.net

A port tester can be used to verify the connectivity between the server and Azure.

Execute the tool from http://testport.cloudapp.net

Port test results.

2. Azure AD Application connector

Open your Azure directory and select Configure.

Scroll down to the Application Proxy section. Select "Download now".

Note the requirements and download the connector.

Install the connector as administrator on your local server.

Click Install.

The connector installs.

Log in to Azure when prompted.

The Azure Application Proxy has been installed.

Note the new services that have been installed.

• Microsoft AAD Application Proxy Connector
• Microsoft AAD Application Proxy Connector Updater

Now back in the Azure Portal select "Manage Connections".

Verify that the connector is active.

3. Add and publish web app

Now we must add the application to Azure and publish to users.

Navigate to the Azure applications.

Select to "Add an application".

In this case we should choose "Publish an application that will be accessible from the outside of your network".

Enter the app details. Enter a name and the internal URL of the app. Choose Azure AD as the pre-authentication method.

The app has now been added. Select "Assign accounts" to publish to users. Select the user group you require.

That's it. You have now externally published the app. It's so easy to do.

Now have a look at the properties of the app. You will see the external URL. This is based on the app name that you configured previously.

You can now access the app externally or through the MyApps Panel.

Configure Single Sign-on (optional)

You can now optionally configure SSO as follows:

• Configure the app to use Integrated Windows Authentication (IWA)
• Create a Service Principal Name  (SPN) for the app
• Enable the Application Proxy Connector to impersonate users in AD against your app (delegate control in properties of the server computer account)
• Configure the Azure app to use IWA
• Enter an internal application SPN in Azure (see below)

I hope this helps. Until next time....

Azure RMS Sharing App & RMS Document Tracking

EMS Landing page

In the last blog we looked at Azure RMS and how it can be used to protect emails. We saw an example of a "rights protected" email using Outlook Web App. However the solution is only supported using Microsoft email clients. What happens if we want to send an email to a colleague and they wish to open that protected email on an Android or iOS device. Enter the Azure RMS Sharing App. Microsoft released the RMS Sharing App at the end of 2014. The announcement was made in the Official RMS Team Blog. You can read that article here

This is an extract: 

"First, we know that you desire built-in support for RMS into Microsoft Office on all platforms. We currently support RMS in Office 2010, Office 2013, and Office 365 but lack comprehensive support on other platforms.

We’ve come up with a way of supporting the sharing of secured Office documents in advance of the native Office support. We’ve done so via the RMS application’s Share Protected button. When you invoke Share Protected to share Office documents we send your email recipients both an RMS protected version of the Office document and a protected PDF copy of the same file. 

The Share Protected button is added to Outlook, Word, Excel, and PowerPoint (v2010 and 2013) when you install the RMS app for Windows"

So how does this work. Download the App from the Microsoft Download Center

http://www.microsoft.com/en-ie/download/details.aspx?id=40857  

Install the App.

The installation requires a restart.

See the new "RMS Share Protected" button in Outlook. Create an email and click on the Share Protected button.

Log in using your Azure credentials (essentially your email address) so that your RMS license rights can be verified.

Choose the RMS rights. 

See the other configurable options:

• Set expiration date
• Email notification when someone opens the attached document
• Allow revoking of the document

The mail is then RMS protected. See that we now have two attachments - a protected Word document as normal and also a protected PDF document which can be opened on any device. Send the email..........

......and you get an immediate notification with a link to the RMS Document Tracking Site. Unfortunately this link doesn't work for me yet as it is currently just available in North America. When the site is available I will be able to track the document to see who has opened it and when. I will also be able to revoke the document at any time.

I will also be able to access the Document Tracking site from here.

The recipient receives the email. See that Word Online is not supported.

The recipient tries another app (Word in this case) and is given instructions on how to access the document. The user should select "Download" to install their version of the RMS Sharing App.

The recipient logs into the RMS Site........

....and is prompted to select and install the correct version of the app for their device. They can now open the document (I have no screenshots of this as they are disabled by RMS).

Finally I get an email to tell me that the recipient has opened the mail (with a link to the Document Tracking Site). 

This app is seriously cool.