Thursday, 2 April 2020

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!

Saturday, 28 March 2020

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!

Thursday, 30 January 2020

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!

Wednesday, 25 September 2019

Intune Basics Part 5: Modern Device Management with Android Enterprise - Configuring Fully Managed Devices

Welcome to part 5 of this series of posts which are intended on getting you started with managing Android devices using the Android Enterprise capabilities within Microsoft Intune.

Part 1 can be found here and covers setting up the various Android Enterprise enrollment methods

Part 2 can be found here and covers the configuration of Azure AD groups

Part 3 can be found here and covers the configuration of Work Profile devices

Part 4 can be found here and covers the configuration of Dedicated devices

This series is intent on getting you up and running as quickly as possible, therefore if you require further detail and explanation on Android Enterprise please refer to my previous post here which I am ensuring is kept up to date as newer functionality is supported within Intune.

This post will cover the enrollment and configuration of a Fully Managed device, which is well, pretty much exactly as it sounds - Intune has full control over the device and there is no facility provided for the user to have personal apps and data. If you followed my last post on Dedicated devices, you will see a similar process configuration wise, in fact the same Configuration Profile is used for both Dedicated and Fully Managed. A caveat to this statement is the setting Users and Accounts > Account Changes which is at this time not supported to be set to Blocked on Fully Managed Devices


Enabling the above will cause enrollment issues as described in Peter Egerton's blog here

There are different methods which you can use to enroll your device which is dependant on the OS as detailed in the documentation and in this example I am going to use the QR code method on an Android 7.0 device.

Ensure the device is either new out of the box or has been factory reset and at the first screen tap anywhere in the white space 6 times

Select Next


Connect to Wifi


The QR reader will now download and install


You can now scan the enrollment token


Encrypt the device if prompted.


Accept any terms then select Next


The device will commence updating Google Play Services


Accept the terms to launch Chrome


Authenticate with Azure AD credentials


I have deployed a compliance policy setting for encryption to my Android Fully Managed devices which means that secure startup must be enabled, this prevents the device from booting into the OS until a pin or password is entered. Select Start


Just to be clear - in this example we are being prompted to "enable" encryption because secure startup isnt enabled and not because the device isnt encrypted

Select Secure Startup


Select Set Screen Lock Type  in this example I am setting a PIN


Select a lock screen notifications option


Set up fingerprints if required


Select Require PIN when device powers on to enable secure startup, enter your PIN when prompted


Select the back button at the top left


Follow the prompts to commence installing apps


Select START to commence device registration


Sign in to the Microsoft Intune app when prompted


Select Next


Select DONE to complete device registration


And then one more time to complete the enrollment


With Fully Managed there is the ability to enable any system apps on the device and on the handset I am testing, a Samsung Galaxy A5 (2016),  I wish to enable the gallery application

To do this first I need the package name so in my example I have deployed the Package Name Viewer 2.0 application. On launching it search for Gallery you may need to try a search in both the User Apps and System Apps tabs


Within the M365 Device Management Console navigate to Client Apps > Apps



Add an app and for the app type select Android Enterprise system app


Enter the system app details including specifying the package name


Select OK then Add 

Deploy the app to an AAD group

Now you can see the system app enabled on the device


That's it for this post, feel free to reach out to me if you have any questions. Thanks for reading!