Wednesday, 10 April 2019

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......






Tuesday, 9 April 2019

CMG Connection Analyzer error - NameResolutionFailure

This week I've been rebuilding my ConfigMgr lab in preparation for demos at MMS 2019. Last night I added the Cloud Management Gateway. I had all the prerequisites in place. I had my certificates already and the CNAME for my external domain was configured. You can read about the certificate and CNAME requirements here


All looked good with the CMG.



There were no errors in the CloudMgr.log file.



The Azure Cloud Service had been created.



My first hint of a problem was the CMG Connection Point status, which remained Disconnected. I figured it was time to run the trusty CMG Analyzer. It's brilliant for pin-pointing where the issue is.



Oops - a lot of errors there.

First one - Failed to connect to the CMG service. Unexpected response status code is NameResolutionFailure. For more information, see SmsAdminUI.log.



Configuration version of the CMG service should be 4.
Failed to get CMG service metadata. For more information, see SmsAdminUI.log.



Connection status of CMG connection point 'ConfigMgr.GH.LOCAL' is 'Not Connected'. Routing to primary site 'GH1' may not be fully functional. For more information, see SMS_CLOUD_PROXYCONNECTOR.log on the CMG connection point.



Failed to test the CMG channel. Check SmsAdminUI.log for more details.

Let's have a look at the log files.



The SmsAdminUI.log file doesn't help very much.



Neither does the SMS_CLOUD_PROXYCONNECTOR.log file. There is nothing there to help me.

So what was the first error again? Failed to connect to the CMG service. Unexpected response status code is NameResolutionFailure.

I previously configured a CNAME record so I didn't quite understand that.


That was the problem - no CNAME record.



This is a test domain and someone had been messing around with the DNS records. The CNAME record had been deleted. I added it back.



Then the CNAME lookup was successful (this took about 8 hours).



The CMG Connection Point connected with no further action from me.



The CMG Analyser then executed perfectly. We're back in business. 

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

Wednesday, 13 March 2019

CMG Connection Analyzer Status Code 401

We were configuring a Cloud Management Gateway for one of our customers and, while running the CMG Connection Analyzer, we encountered a 401 error that we hadn't seen before. The error was for the last step "Testing the CMG channel for management point". 

Failed to refresh MP location. Status code is '401' and status description is 'CMGService_Not_Allowed_Root'.
A possible reason for this failure is the CMG service failed to forward the message to the CMG connection point. CMG service detected client certificate coming with not allowed root certificate. Check trusted root certificate authorities on site properties for client computer communication.


The CMG had been added and was in a Ready state. So, what was wrong? It was obviously certificate related and pointed in the direction of a root certificate.

We had used a third party certificate to configure the CMG service (DigiCert). It turned out that we had to add the DigiCert Root certificate as a Trusted Root Certification Authority in the ConfigMgr site properties (it was included in the package we downloaded from DigiCert).


Then we ran the CMG Analyzer successfully.


I hope this helps anyone who encounters the same problem. 

Until next time......




Monday, 28 January 2019

Intune Support for Azure Monitor - Public Preview

This is a great new feature of Microsoft Intune (Public Preview). Central logging has been a request for some time. Now we can send Audit and Operational Intune logs to Azure Monitor services. This allows us to:
  • Archive Intune logs to an Azure storage account to keep the data, or archive for a set time.
  • Stream Intune logs to an Azure event hub for analytics using popular Security Information and Event Management (SIEM) tools, such as Alien Vault, Splunk and QRadar.
  • Integrate Intune logs with your own custom log solutions by streaming them to an event hub.
  • Send Intune logs to Log Analytics to enable rich visualizations, monitoring, and alerting on the connected data.
In this example I'll archive the data to a storage account for analysis later.

What do we need?
  • Azure subscription
  • Intune
  • Global Admin or Intune Service Administrator account
  • Azure storage account with ListKeys permission (you'd need a different Azure service depending on where you want to route the logs)
So let's configure this logging.

In the Azure portal navigate to Intune


Select Diagnostics Settings and turn it on.

We can see three options:
  • Archive to a storage account: Saves the log data to an Azure storage account. Use this option if you want to save or archive the data. (this is the one we will use)
  • Stream to an event hub: Streams the logs to an Azure event hub. If you want analytics on your log data using SIEM tools, such as Splunk and QRadar, choose this option.
  • Send to Log Analytics: Sends the data to Azure log analytics. If you want to use visualizations, monitoring and alerting for your logs, choose this option

See the event hub configuration (if this was our preferred option).......



....or the log analytics (if this was our preferred option).



We'll just choose an Azure storage account (our option).



Enter a descriptive name for the diagnostic setting and configure the retention period in days. Save the setting.



The diagnostic setting has been created. You can edit this afterwards.


Cost

Remember that there will be a cost associated with this logging. See the Microsoft docs for more details.



Reviewing the logs


After an action the corresponding log will show up in the storage account between 5 and 15 minutes later and it's very easy to review the logs.

Navigate to Azure Storage accounts


and select the storage account you configured earlier.


Select Storage Explorer (also in Preview). You'll see a new Blob container - "Insights-log-auditlogs"


Drill down into the container and you'll find a .json file.


You can open the file in a browser to see the logs. See that some managed devices were deleted. I wonder who did that.


The Azure Storage Explorer tool is another option and is also handy for browsing this content. Download it from here


Install the tool and sign in to Azure.


Choose your subscription and select Apply.


How you can browse and open the logs.


Look who deleted the managed devices. I'll have to talk to him.


This is a brilliant new feature. I hope this blog post helps. Until next time.....