In the last post I mentioned that one of the things that should be on your to do list when deploying Windows 10, Azure Active Directory and Intune is Group Policy to Mobile Device Management migration. This is something that can be quite a simple task (very rarely), or way more complex. The complexity of you organisation’s Group Policy Objects and the degree of documentation that explains them is going to determine where you fall.

If you keep your Windows 10 devices in Hybrid join mode rather than going down the Azure Active Directory Join path, you can still connect to your on-premises resources as you have previously, but now you get three big additions to your traditional capabilities. With Microsoft 365 Business, these include richer analytics and compliance reporting of clients that live in the cloud, Azure Active Directory’s Conditional Access capabilities for controlling SaaS app access, and and a variety of MDM/GPO coexistence or migration paths.

Back when organisations relied more heavily on VPNs to connect to on-premises workloads, it wasn’t that big of a challenge to get devices to check in regularly, get any policy updates that were required etc, but over time this has changed dramatically for some organisations. I’m seeing fewer and fewer SMBs using VPN connections regularly today, unless they still have a specific workload that they haven’t been able to move to the cloud. This means that pure AD joined devices can be in a bit of an known state until they come back in house.

By Hybrid joining the device and then enrolling in Intune, you now get reporting details showing up in a cloud based console. This means that even if you aren’t targeting these devices with Intune policies, just enrolling them starts to light up some additional information about them, as well as some additional controls. One of the things you could even do is start assigning these devices an Autopilot profile using Dynamic Groups. Dynamic Groups is something that I’ve only noticed lighting up in a Microsoft 365 Business recently, but that doesn’t mean it hasn’t been in there for a while.

Using Hybrid AADJ as an additional access control mechanism with Conditional Access means that you can apply additional requirements to allowed device types. There are two places you will see this, the first is under Conditions, with the preview of Device State, and the second has been there for quite a while as a Grant option.

The preview of Device State allows a policy to be applied to all devices, but then you can add exceptions for hybrid devices and/or compliant devices. You can read more about it here, but the summary is that we can use it as a way to exclude devices that meet these requirements from the policy so that we can potentially enforce additional session requirements to control unmanaged device access to workloads.

Using Hybrid join as an access control under Grant means that you can restrict the types of devices that can access the workload. In this case it could be Windows 10 Pro or Enterprise, but would have needed to have line of sight to a Domain Controller at some point to perform a domain join. This drastically reduces the number and types of devices that could successfully access the workload you are trying to protect.

The final item for this post is one that I’ll cover in more detail in the next post in the series, but that’s using Hybrid joined devices as a way of testing new policies via Intune versus rolling them out via Group Policy. This is a great way of rolling out new policies that will apply to pure AADJ devices as well as Hybrid joined devices as long as the assignment is configured correctly. You could also use this as a way to start policy migrations from on-prem to the cloud, leveraging tools such the MDM Migration Analysis Tool (MMAT).

MMAT helps to map Group Policies that are in place against Windows 10 MDM capabilities, helping to identify areas where easy mappings can be made, as well as identifying areas where there isn’t a direct MDM mapping. This doesn’t mean that many of the same things can’t be accomplished, but there maybe be some additional work involved. This will be the focus of the next post in the series, so stay tuned for that.