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.


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

Thursday, 24 January 2019

SCCM PXE Responder and DHCP

One of the most eagerly awaited features of ConfigMgr Current Branch 1806 was the ability to enable PXE on Distribution Points without Windows Deployment Services (WDS). This was an enormous step forward as it can save customers money. I have customers with many PXE-enabled DPs throughout the world. That's a lot of server licensing. Previously a server OS was required simply for WDS. Now we can use a desktop operating system for the DP and enable it to use the lightweight PXE responder.

We were implementing this solution for a customer back in December and we had some trouble getting it to work. We were enabling the PXE responder on a server OS which may sound unusual but the customer was concerned about a possible reboot required for WDS and the logistics of organising this on 100 sites worldwide. It should still have worked - right?

The “Configmgr PXE responder servicewas running successfully but we still saw this error in the SMSPXE.log file.

PXE: bind() failed for DHCP, 00:15:5D:05:16:00,, 67. 0x80072740.        SCCMPXE            12/20/2018 5:28:37 AM         6448 (0x1930)

This actually made sense as this server was also configured as a DHCP server. Of course that was the problem. Both DHCP and the PXE requests use port 67. This is ok when using WDS as we can configure it not to listen on port 67. Unfortunately we didn't have the same option with the PXE Responder.

I reported this to the product group on the 21st December. Other MVPs chimed in (thanks @jarwidmark) and talked about the merits of making this work. I'm pleased to say that this fix was released yesterday 23rd Jan in Technical Preview 1901, only a month later. That's an amazing turnaround for a feature. Hats off to @TweetKerwin and @djammmer and this shows the power of the ConfigMgr community. 

Details of the fix can be found in the TP1901 docs

When you enable a PXE responder on a distribution point without Windows Deployment Service, it can now be on the same server as the DHCP service. Add the following settings to support this configuration:
  • Set the DWord value DoNotListenOnDhcpPort to 1 in the following registry key: HKLM\Software\Microsoft\SMS\DP
  • Set DHCP option 60 to PXEClient
  • Restart the SCCMPXE and DHCP services on the server.

Hopefully the fix will be available shortly in a production release.

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

Monday, 17 December 2018

First look at Windows 10 Security Baselines - Intune public preview

(First published in Dec 2018 but I was too early so I withdrew the post 😃)

This has been one of the most requested Intune features for quite some time and, yesterday, it was released as a public preview in Intune 1901. What is it all about? You can find the official documentation here

For many years now we have relied on Microsoft to provide guidance on the security settings that we should configure. In the on-premise Active Directory world we don't want to analyse every possible GPO that is available. That's why we implement the Microsoft security baselines as a starting point and then we change individual settings as required. Microsoft have now provided Windows 10 security baselines for the Intune MDM-managed world. I tested it today and it's really easy to implement. It works well too.

Remember that this is a public preview only and is only supported with Windows 10 version 1809 and later. It is not yet recommended for production.

So where do we start? In the Azure portal, navigate to All Services and search for Intune. Select Security Baselines (Preview).

Launch Security Baselines and we can see the Preview: MDM Security Baseline for October 2018 (beta).

Drill into the baseline. Click Create profile.

Enter some details (Name and Description) for your baseline (profile). The platform and baseline drop-down arrows are grayed out. These will probably become available as more baselines are released for different Windows 10 versions.

Have a look at the Settings. These are the kind of security heading that you would expect.

"Block toast notifications on locked screen" is enabled in the baseline. I'll check for that in my test computer in a minute.

The Browser settings look secure.....

....and these are the Device Lock settings. See that we will prevent the reuse of the previous 24 passwords. That's pretty secure. I'll check that on my test client also.

Once the profile has been created it should be assigned to a group (of devices or users).

Ok, on my test device, I've initiated a manual sync. Otherwise I'd have to wait up to 8 hours.

I've generated an MDM Diagnostics report.

These are the results. I can see that DevicePasswordHistory is now configured for 24. 

AllowToasts is now disabled.

So what happens if I make a change to a baseline? Let's change the toast notification setting to Not Configured.

After a manual sync I can see that this setting is no longer managed.

I can see a lot of potential with this feature. Try it out (although not in production yet).

Until next time......

Thursday, 6 December 2018

Wake on LAN in ConfigMgr 1810 and 802.1x authentication

I recently carried out some testing on the new Wake on LAN feature of ConfigMgr 1810 and published the result in this blog post. One of the things I pointed out was that the feature was not supported using 802.1x authentication. I wondered why so I carried out some additional research.

As with all Microsoft support statements, just because something is not supported doesn't mean that it will not work. It's either untested or will not work in all scenarios. This is the case with WoL and 802.1x authentication.

802.1x is a standard for port-based network access control that provides authenticated network access to 802.11 wireless networks and wired Ethernet networks. Port-based network access control uses the physical characteristics of a switched LAN infrastructure to authenticate devices that are attached to a LAN port and to prevent access to that port in cases where the authentication process fails. One of the features of 802.1x is that devices are quarantined when they are turned off. Therefore the switch ports becomes blocked in both directions and prevents the WoL magic packet from being delivered - a chicken and egg situation. 

I figured that this couldn't a new problem and that it would be possible to overcome this in the enterprise. I was right. I researched the main networking vendors and found that they had solutions.


The 802.1X authentication with Wake-on-LAN (WoL) feature solves the problem. When a host that uses WoL is attached through an 802.1X port and the host powers off, the 802.1X port becomes unauthorized. The port can only receive and send EAPOL packets, and WoL magic packets cannot reach the host. When the PC is powered off, it is not authorized, and the switch port is not opened.

When the switch uses 802.1X authentication with WoL, the switch forwards traffic to unauthorized 802.1X ports, including magic packets. While the port is unauthorized, the switch continues to block ingress traffic other than EAPOL packets. The host can receive packets but cannot send packets to other devices in the network. 
  • When you configure a port as unidirectional by using the dot1x control-direction in interface configuration command, the port changes to the spanning-tree forwarding state. The port can send packets to the host but cannot receive packets from the host. 
  • When you configure a port as bidirectional by using the dot1x control-direction both interface configuration command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.
Note: If PortFast is not enabled on the port, the port is forced to the bidirectional state.


The aaa port-access controlled-direction in command allows Wake-on-LAN traffic to be transmitted on an 802.1X-aware egress port that has not yet transitioned to the 802.1X authenticated state; the controlled-direction both setting prevents Wake-on-LAN traffic to be transmitted on an 802.1X-aware egress port until authentication occurs.

Note: Although the controlled-direction in setting allows Wake-on-LAN traffic to traverse the switch through unauthenticated 802.1X-aware egress ports, it does not guarantee that the Wake-on-LAN packets will arrive at their destination. For example, firewall rules on other network devices and VLAN rules may prevent these packets from traversing the network.

Aruba Networks (not Procurve)

In Aruba AOS (not Procurve) there is a MAC pinning feature which basically adds a static MAC address to the port and associates it to the authentication as a pinned-MAC. All traffic to that MAC address would be pre-authenticated and anything else would need to be authenticated.


For enterprise grade edge switches I would expect a solution for this problem. You may not be so lucky with low end switches and your mileage may vary. That's why this solution is not officially supported by Microsoft.  
I hope this helps. Until next time.......