Using ADMX ingestion to configure the Zoom desktop application with Intune

Due to recent events I am seeing that organisations are having to come up with solutions quickly in order to enable their workforce, most of which it is the first time they are working from home. After working for a customer recently who wishes to deploy the Zoom desktop client to their whole organisation, I had a conversation with them and it was apparent that actually they were not entirely sure how specifically they wanted Zoom configured on install. On browsing the documentation I soon realised that there were some Group Policy templates available so, thinking ahead I thought it would be a good idea to see if I could import these policies to support any additional configuration requirements post install if the customers requirements changed over time.

So for a bit of background on this, as of Windows 10 1703 functionality was made available within the Intune service (and obviously the Window OS) giving the ability to support ADMX backed policies. So essentially the ability to transmit Group Policy settings in a format that are understood by the MDM client using the Policy CSP. This being achieved by importing or "ingesting" ADMX files and then configuring specific settings in relation to the ingested content. There are some caveats and considerations which  I am going to explain in this post and I want to keep it as simple as possible. Over time support has been provided for ADMX settings with the Administrative Templates profile within the Intune portal and most recently announced - these settings are now presented in an interface very similar to the experience of the Group Policy Management Console;

So how do we approach this then? First of all download the ADMX files for the Windows Desktop client. There are two versions, ZoomMeetings_HKCU if you want to deploy the policies within the users scope and ZoomMeetings_HKLM for devices. I went with the latter and then opened up the file with an xml editor.

From this, as per the documentation I needed to confirm that the registry keys for these policies were not within the exclusions list (I assumed this would be fine however its always worth a check)

I also wanted to look at the policies available and take note of the values supported for each policy, to use when creating the custom configuration profile to deploy the required settings

So lets take two settings in this example, we wish to prevent the end user from logging in using either their Google or Facebook credentials. What we essentially need to do now is deploy the ADMX file with an OMA-URI setting in order for it to be ingested and then disable these two settings using additional OMA-URI's for each. In order to know what values to use for these OMA-URI's a good approach (thanks Per Larsen for your excellent presentation at WMUG back in August 2019) is to deploy the ingested ADMX to the device first so these values are available in the registry.

First of all login to the Endpoint Manager admin center (EMAC) and navigate to Devices > Windows > Configuration Profiles > Create profile

Select Windows 10 and later as the platform and Custom as the profile type, give the profile a suitable name. Just as a reminder this profile will eventually contain both the fully ingested ADMX file and in addition the two OMA-URI strings for our settings.

Select add and then fill in the appropriate values;

Name; Something descriptive

Description; Add if required

OMA-URI; Should be in the following format with the items in bold being custom providing they are unique on the device ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/CustomZoomADMX/Policy/CustomZoomADMX

Data type; String

Value; The pasted contents of the ADMX file

Assign this to a device and then once the MDM profile has reported back as successfully deployed in Intune open the registry and navigate to HKLM:\Software\Microsoft\PolicyManager\ADMXInstalled to verify that the policy exists, there is a status and policy count

Now navigate to HKLM:\Software\Microsoft\PolicyManager\ADMXDefault and referring back to the ADMX file the settings we required were within the zoomgeneral category

Now we can go back to the profile we created earlier to add two more OMA-URI's using the above values

To enable the disable Facebook login policy

./Device/Vendor/MSFT/Policy/Config/CustomZoomADMX~Policy~ZoomUsCommunication~zoomgeneral/DisableFacebookLogin_Policy

The same for the Google

./Device/Vendor/MSFT/Policy/Config/CustomZoomADMX~Policy~ZoomUsCommunication~zoomgeneral/DisableGoogleLogin_Policy

Remembering that the available values for these settings can be found in the original ADMX file so the are both string and set to <enabled/>

Remember to change the beginning of the OMA-URI's to ./User if using user based ADMX policies

Originally the experience when launching the Zoom app on the device displayed the following options

After carrying out a policy sync you can now see the settings have applied

I hope you have found this useful, thanks for reading!

Getting started with Windows 10 device configuration options within Intune

If there is one thing that is noticeable when looking at the various Windows 10 configuration options within Intune and that's the fact that, well there are lots. But is this really necessary? What should be used and when?

In this blog post I thought I would summarise my findings along with some general tips that I have picked up along the way from both resources within the community and through my own experiences.

I am going to step through this in order of preference in which I would recommend to look at the various options.

Now to add at this point, this post has been in draft for a while and in that time the M365 Device Management Admin Console (DMAC) has significantly changed. Indeed with this months service release of Intune, there have been some significant additions that are now in public preview. In fact this console is now called the Endpoint Manager Admin Center (EMAC) and will provide in the future a unified interface to manage both Intune and Configuration Manager clients. The layout I feel is now much more intuitive, with more of a platform specific approach. At the time of writing the layout of this is different to that of what is available in the Intune console via the Azure portal, so please bear that in mind when following along with this post.

Security Baselines

One of the fundamental reasons for configuring Windows 10 is to provide a secure system for users within your organisation. Security baselines are a very simple way of deploying a super secure configuration in very little time at all. These are a groups of recommended settings developed from within Microsoft security engineering teams and are available in three types - Windows 10, Microsoft Defender ATP and Microsoft Edge. Individual settings can be changed to suit your organisation's needs and I would recommend to deploy the base set and take your time to test fully in a small pilot before proceeding. I will re iterate again - take your time on piloting any of these before rolling them out into widescale production

These settings are located within the EMAC, navigate to Endpoint Security > Security Baselines 

You can now select a specific baseline type, create, amend as appropriate and assign it. What I particularly like is way each individual setting is reported back as compliant or not, the baseline will then attempt to configure the device back to the setting specified within the baseline.

I have to admit though there are some aspects of baselines which are almost a "one size fits all" as there are some settings that it would appear cannot be set back to simply "not configured". Certainly a great way to get start though if applicable for your particular scenario.

Security Administrator focused policies

These policies contain in the most part the same settings that are available within the Device Restriction and Endpoint Protection policy types (explained further below) but are now exposed within the Endpoint Security node alongside baselines

If you are needing some additional flexibility and you are comfortable with the expectations of using public preview features, then take a look at these new options that will provide you with settings grouped within specific profile types. 

The new Microsoft Defender profile type within Antivirus (Preview) contains additional settings that are not available within the traditional Device Restrictions profile, so if you are using the Defender AV engine within your environment I would certainly recommend taking at look here first

Endpoint Protection and Device Restrictions

Until the recent announcement of the new Security Admin focused MDM Policies and fairly recent introduction of Security Baselines, traditionally security related policies were included within the Endpoint Protection and Device Restrictions profile types. These also provide a simple way of configuring settings of the same type and will provide additional options to secure Windows 10 outside of what is not currently available within baselines more related to restricting specific options being available to the end user. Settings for improving user experience are also found within the Device Restrictions profile type

To create these profile types navigate to Devices > Windows > Configuration Profiles

After selecting the correct platform the profile type can be selected

If you are in an organisation that already has these profiles deployed and are considering deploying Security Baselines, then I would recommend isolating a test device into its own Azure AD Group with the existing configuration deployed and then create a baseline and deploy to it. You will then be able to identify any conflicts that arise and remove settings from conflicting profiles as appropriate, leaving the setting available within the baseline.

Administrative Templates

Traditional device configuration settings have been delivered in the form of group policies to devices that are joined to an ADDS Domain using the ADMX format. The ability to support the configuration of traditional settings within Windows and Win32 Applications using this method was supported within Intune as of Windows 10 1703, this however required the importing of ADMX files via a process called ingestion which had its risks.

The Administrative Templates profile type contains various settings to configure Windows, Office and Microsoft Edge (Version 77 or newer) so this should be the next area you explore for your required settings.

More recently announced was a new intuitive change to the display of these settings very similar to the experience from with the Group Policy Management Console

Additional Windows 10 profile types

It is now at this stage I would recommend if there are any other settings you are looking for then to explore the additional Windows 10 and later profile types. These you will have seen within the profile type dropdown list in addition to Endpoint Protection and Device Restrictions

Configuration Service Providers (CSP's)

A CSP is an interface in which to manage configuration settings for modern settings and applications within Windows 10 via Intune. CSP's utilise a standards based protocol which is compatible across various MDM's known as Open Mobile Alliance Device Management (OMA-DM) and are transmitted in the form of Synchronisation Markup Language (SyncML) messages. Specific CSP settings can be defined using OMA-URI's (Uniform Resource Identifiers) within the "Custom" configuration profile option.

So essentially, if there is not a setting within any of the MDM profiles, check out the CSP reference documentation to see if there is a setting available for you to configure. Additional CSP's are released with each Windows 10 version which means that you have the benefit of being able to create this custom configuration right after release.

To create this custom configuration you will need to specify the OMA-URI, data type and value, this example is setting the timezone

That's all for this post, I hope you have found it useful. Thanks for reading!

Resolving Wifi display connection issues when deploying MDM baselines within Intune

I have been working with Windows 10 MDM within Intune for the past few months and after a conversation with my colleague I soon realised that this would make a good blog post, so I hope this quick tip saves you some time.

Security Baselines are great, simple to set up and deploy and a very quick way of ensuring your Windows 10 devices are secure. They are also a very quick way of crippling your estate if you are not careful with your testing beforehand, so I cannot stress this enough - test thoroughly before even attempting to deploy to any quantity of devices.

So just to recap, to deploy a security baseline is as simple as the following;

Log into the Microsoft Endpoint Manager admin center, navigate to Endpoint security > Security baselines

Under the Windows 10 Security Baselines heading select the MDM Security Baseline option

Select Create profile

Give your profile a suitable name, select Next

Now you will be able to see all of the settings available within the profile. We are just going to accept the defaults for demo purposes, however I stress again, test these settings thoroughly before attempting to deploy into production

Select the groups you wish to deploy the baseline to then click Next

Select Create to complete the deployment of the baseline

After a short test phase with my secure configuration, which includes MDM profiles, custom configuration and a security baseline, it was soon established that both the Windows + P (Select a display mode) and Windows + K (Quick connect) options were no longer available on devices. Not ideal for usability. 

It turns out this was related to the Windows 10 Device Restriction MDM profile setting General > Device discovery being set to Block

I had set this originally, following NCSC guidelines for Windows 10 MDM

Great, I thought, now connecting to wireless monitors shouldn't be a problem. But I soon found out that the connection was just timing out. I figured out that this time it was indeed the security baseline causing the issue, but which setting was it? My initial hunch was that it almost seemed firewall related, but when I viewed the local firewall settings on the device experiencing the issue, I could see the appropriate firewall rule was indeed configured

On further investigation I soon realised that the May 2019 MDM baseline contains a setting that by default prevents the merge of firewall rules within group policy and hence the settings contained in local group policy would not apply. It is documented here and affects the public profile

I therefore needed to create a Firewall exclusion and configured a new profile in the following manner;

Navigate to Devices > Windows 

Select Configuration Profiles and then Create Profile

Enter a suitable name, select Windows 10 and later for the platform and then Endpoint protection for the profile type

Navigate to Microsoft Defender Firewall under the Firewall rules heading select Add

Populate the settings based on the Wireless Display (TCP-In) Firewall rule

The profile should then be deployed to your devices enabling you to connect to Wi-Fi displays once more.

Thanks for reading this post!