Monday, 1 February 2021

Further exploration and analysis of OEMConfig

 In a previous post published almost 2 years ago (wow time flies!) I briefly covered what OEMConfig meant in terms of Android device management and figured that now would be a good time to explore this functionality again with you. 

The fact that OEMConfig is supported in Intune isn't indeed hot off the press news, however its still a fairly new initiative which I feel both customers and tech folk alike are pretty much in the dark about. I would suggest that this is probably due to the value offered differing between OEM's and often handsets.

So, what actually is it? OEMConfig is a way of delivering device configuration value for settings that are mostly not available within Intune. These configurations are delivered via an OEMConfig app, which essentially controls the execution of these settings rather the MDM agent. The app differs across OEM's and sometimes, such as for the example I will be discussing in this post, across models of handset. You should also be aware that some elements of these settings may require additional licensing from one of the supported OEM's, all of  which are documented here

The key benefit of OEMConfig is the fact that each time the OEM wishes to release additional functionality, there is little to no development time in order for this to be available on devices. So no delay in waiting for a dedicated profile to be made available in Intune! However, what I would add is that in order to take advantage of this functionality it may actually mean the handset needs to be upgraded, or indeed if the new feature may come under the context of a setting that needs additional licensing. Most of the time I would expect this to be a case of an update needs to be installed on the device.

In this example, I have a Nokia 5.3 handset which in this scenario, requires an OEMConfig app specific to the model;

So the requirement now is to deploy this app to the device. Within the Microsoft Endpoint Manager admin center navigate to Apps > Android then select Add then Managed Google Play app as the app type

Search for the previously mentioned OEMConfig app for Nokia 5.3 devices (noting again that for Nokia devices there are OEMConfig apps per model)

Select it then click Approve twice, then Done before finally Sync to ensure that the app appears as available

Once the app appears in the list, select it then properties. Select edit next to assignments then add the appropriate target group as a required assignment. Save any changes

Now the configuration needs to be defined and then assigned. Navigate to Devices > Android > Configuration Profiles select Create Profile. Choose Android Enterprise as the platform and then OEMConfig for profile.

Give the profile a suitable name and then click Select an OEMConfig app to ensure the correct app is associated with the profile. After selecting Next you will now see the settings that are available, which can be configured using the default configuration designer

In this example, we are going to enforce location services on the device, so next to Location select Configure then Enabled from the drop-down menu on the next screen

Select Next twice and then assign the profile to the appropriate target group. Next then Create completes the assignment of the configuration.

As you can see, initially location services were disabled on my test device

Now you can see they are enabled, in addition, the prompts for the OEMConfig app install and confirmation of the setting being enabled are also visible

I have to admit that initially, I thought there was significant value in the ability to be able to control this setting on these handsets. The problem is that in this specific scenario it does not prevent the end-user from altering the setting, which is also clearly stated on the app within the store

I also attempted to modify the setting and wait for / force a sync to see if it reverted again without any luck. I intend to explore this further and will update this post if I have any further information on why this is the case. 

That aside I believe this still demonstrates the possibilities with using this technology and it should be something you should consider as a contributing factor when selecting company-owned Android devices.

Many thanks for reading this post, if you have any questions please feel free to reach out to me!

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

The same for the Google

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!