Moving Group Policies into the Cloud

A common consideration when moving to the cloud is how do we control our users and endpoints still?

In this instance, we should think about using Microsoft Endpoint Manager (MEM) to manage the above where possible when moving to the cloud, and for everything else use AD in some capacity.

Why do we want to do this? Well, it’s very rare we get the opportunity to-do such a thing, many companies sit on redundant GPOs with no willingness to shift unless for big reasons so we want to use this opportunity to-do a few things.

Modernise our environment using tools such as MEM, this is essentially an evergreen solution in that in traditional environments where GPOS are used, we have to moderate our application settings manually, we have to update templates manually, however with MEM this isn’t the case - and vendors are adding more and more ADMX solutions into MEM all the time, so we don’t need to manually update our systems every time a new GPO is added, we can just jump in and tick a box and that’s it.

We can also take this as an opportunity to have a clear out, look at the GPOs being used - are they still relevant, can some GPOs be merged/bundled? Can those GPOs be moved into MEM instead? We have to accept that for most businesses, you will always still need AD in some capacity - simply some things can’t be migrated across so easily.

So, key take away points:

• Use MEM where possible to manage your policies.
• Use this as an opportunity to tidy everything up.
• Use AD only for settings that cannot be covered with MEM.

The above will allow us going toward to embrace the the cloud in many ways, using things such as the Cloud Adoption Framework (CAF) https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ to really help us drive this forward.

The idea is now, we use SaaS where possible, this allows us to:

• Use an evergreen solution, in that the software is always updated.
• Embrace serverless where possible, in that we don’t need as-many.
• Remove requirements for some hardware and the maintenance of it.
• Utilize azure automation to manage our estate and standards.

The idea is, going forward that you have your SaaS offerings, which have all the necessary boxes built into them that you can turn on/off, it’s kind of like ADMX as a service (sort of) - https://docs.microsoft.com/en-us/windows/client-management/mdm/understanding-admx-backed-policies.

An example would be, in your current environment you have a policy that controls something via GPO and you wish you move that into Azure, you could potentially use Intune and leverage Administrative Templates, see: https://docs.microsoft.com/en-us/mem/intune/configuration/tutorial-walkthrough-administrative-templates

The problem might come when you encounter a GPO that isn’t covered by the above, and the tool will tell you this upfront in its analysis - you would then need to consider if that policy is still required going into the cloud or if there is a better way forward and utilize another solution instead - there are a lot of 3rd party GPO type tools out there that don’t need an AD and emulate what it does instead.

However, most importantly we should always be looking to re-architect our solutions and not just lift and shift where possible as moving into the cloud is a great opportunity to drop some of the technical fat we sometimes carry around and there’s no better time to evaluate than when migrating.

Group Policy Analytics in Microsoft Endpoint Manager

We have a few options moving GPOs into the cloud, we’ll consider those later but for now lets take a look at a tool in preview called Group Policy Analytics which is available via Microsoft Endpoint Manager (MEM).

Group Policy analytics (preview) - https://docs.microsoft.com/en-us/mem/intune/configuration/group-policy-analytics

This tool will essentially analyse an exported report of your GPO settings and advise you on whether or not those policies can be migrated into relevant O365 offerings, such as Intune with either MDM or ADMX support.

In order to use this tool, we first need to jump onto a machine and fire up Group Policy Management.

We navigate to the GPO we want, right click and select “Back Up” and save this to a location on the local machine.

You now need to jump onto https://endpoint.microsoft.com/ and via the blade go-to Devices > Group Policy analytics (preview) and select Import.

Once you’ve imported the report, the service will then scan and give you it’s own report on varying factors as to whether or not those policies can be shifted into Azure.

It’s worth noting in the above, we know FSLogix is being used for my WVD solution so it’s a really bad example here of a GPO but I think it still bares relevance here and allows me to show what the interface looks like, irrespective of the data being fed into the tool itself.

Hypothetically speaking, if this wasn’t FSLogix and it was something else - in this instance, we’ve got quite a few options, some really the only way and some that are a bit odd.

• We could keep the on premises Active Directory and use AD Connect to hook our users/computers into Azure Active Directory.
• We could move the on premises Active Directory into Azure as IaaS using Azure Migration.
• We could utilize the managed Active Directory in Azure and push GPOs via an attached VM with GPO tools installed.
• We could bake our GPOs into a base image and use this, which sounds silly but is a possible option if it was a small site and the other GPOs were being handled by Intune policy equivalents.
• We could just say its a GPO we don’t care about anymore and get rid of it.
• We could say the GPO is needed but maybe there is another way to push that setting, maybe via a PoSH script that’s linked to a conditional in Intune and runs the PoSH script which tattoos the system with our settings and runs x times an hour for any changes and overwrites those changes if they don’t match the PoSH.
• And many more… the options are endless.

So what would I do?

We could go on and on about what solutions we can use, but I’d say the best option would be a hybrid one, so use AD in partnership with Intune which means anything Intune doesn’t have an application policy for we just continue with AD and give AD a good clean-up at the same time.

As the product matures, that virtual dial of balance will swing more in the direction of Intune until the reliance on traditional policy management goes away, which will be a while I imagine!

So initially, we would do the following:

Evaluation Phase:

• Scan our GPOs and export.
• Evaluate what we want to keep.
• Run what we want to keep through the GPA tool.
• Analyse the output and decide what stays and goes.

Testing Phase:

• Create a test OU and assign some existing machines and some fresh machines into that OU, it will be used to test the GPOs.
• Move required ADMX/MDM supported policies in to the cloud.
• Disable all those GPOs in our on-prem environment OU.
• Enable all our Cloud related GPOs against said OU.
• Grab some users to help test the changes, from varying departments.
• Re-evaluate the unsupported GPOs left, remove more if possible and re-test.

Production Phase:

• Downtime, plan a weekend for this change with plenty of time for testing and roll back if needed.
• Implement the testing phase into production, expanding the scope.
• Once done, grab a beer and celebrate the fact we’ve just modernized an environment, made peoples lives easier in managing our solutions and removed the reliance on-premises architecture and embraced evergreen solutions such as SaaS.

Coffee?

If the above was interesting and it helped, please consider buying me a coffee @ https://ko-fi.com/L4L542GI9