You can create a "Settings Page Visibility List" policy that allows administrators to show only specific pages in the Settings app. The secret here is the "showonly:" string that appears in the custom OMA-URI settings. In this example I will choose the only the following settings to remain visible.

• bluetooth: Bluetooth settings
• camera: Camera settings
• about: System information
• sound: Sound settings
• easeofaccess-audio: Ease of Access audio settings
• windowsupdate-action: Windows Update actions
• sound-devices: Sound devices settings
• apps-volume: App volume and device preferences
• easeofaccess-visualeffects: Ease of Access visual effects
• appsfeatures-app: Apps & features
• installed-apps: Installed apps list
• privacy-webcam: Privacy settings for webcam

Using the Microsoft Intune Admin Center, navigate to Devices > Configuration > Create > New Policy. Select Windows 10 and later as the Platform and Custom as the Profile type. Name the policy and click Add to configure the OMA-URI settings as shown below.

The OMA-URI path is OMA-URI:

./Device/Vendor/MSFT/Policy/Config/Settings/PageVisibilityList

Choose String as the Data Type. The string will include the following:

Value: showonly:bluetooth;camera;about;sound;easeofaccess-audio;windowsupdate-action;sound-devices;apps-volume;easeofaccess-visualeffects;appsfeatures-app;installed-apps;privacy-webcam

When completed the OMA-URI settings will look something like this:

Then assign the designated groups to the policy and save.

Admins can tag devices using Microsoft Intune to enhance device management, organization, and security across their enterprise environment. Tags can be used to efficiently group and categorize devices based on various attributes such as department, location or function. This logical grouping enables IT teams to apply policies, updates and security measures more effectively. Tags can be automatically assigned and updated through dynamic rules, ensuring that device classification remains accurate and up-to-date. Some of the applications of tagging includes the following:

• Tags can be used to filter and search for specific devices in large environments to improve management efficiency.
• Tags can be used to apply specific policies, configurations, or software to groups of devices that share common characteristics.
• Tags can help in tracking and managing hardware assets across an organization.
• Tags can be used to identify devices that require specific security measures or compliance checks.
• Tags can provide additional context about devices, which can be helpful during troubleshooting or decision-making processes.

In other words, tagging provides numerous management options and can prove a way to simplify your MDM efforts.

Create a Configuration Policy

To implement tagging using the Microsoft Intune Admin Center, navigate to Devices > Configuration > Policies > and create a new policy. Choose Windows 10 and later as the Platform and select Custom Templates as the Profile type.

You will then apply a name for the policy and configure the OMA-URI Settings. The OMA-URI path is the most critical here so use the following path:

./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/DeviceTagging/Group

In the example below I selected String as the data type and made a tag called IT Employee.

You could also use a PowerShell script to create tags and deploy the script through Intune. I can then create a dynamic group in Azure AD that includes all devices with the “IT Laptop” tag. Security policies and configuration policies could then be applied to devices belonging to the IT role group.

Microsoft Intune offers two primary methods for managing Control Panel settings on Windows devices: Administrative Templates and the Settings Catalog. Administrative Templates are based on ADMX files, similar to Group Policy Objects (GPOs) in on-premises Active Directory. By using the administrative templates, you can configure a wide range of settings, including Control Panel visibility and functionality. This method provides a familiar interface for administrators who have experience with Group Policy.

To use this method, open the Microsoft Intune admin center and navigate to navigate to Devices > Configuration > Create New profile and select Windows 10 and later as the platform and Administrative Templates as the Profile type. In this example I want to hide Add or Remove Programs. In the screenshot below I went to User Configuration and chose “Remove Add or Remove Programs” and then enabled the setting as shown in the screenshot below.

Another approach might be to remove the Programs and Features page altogether. To do so, navigate to User Configuration > Control panel and select “Hide specified Control Panel items” and set the option to enabled. As shown in the screenshot below, list the Control Panel items you want to hide using their canonical names. Here Is chose to hide System Settings and Programs and Features. Complete the creation process by assigning the policy to the designated groups.

Using Windows Settings

You can also manage Control Panel with Intune without using administrative templates. In this case you will use the Settings Catalog that will apply to both the traditional Control Panel and the modern Settings app. Once again, navigate to Devices > Windows > Configuration profiles and click on "Create Profile". Then select "Windows 10 and later" as the Platform but this time choose "Settings catalog" as the Profile type.

In the Settings picker do a search for “control panel” and I chose “Add or Remove Programs” but this time I had more options to choose from. I then “Hide Add New Program page for users. Then I enabled the policy to the left as shown in the screenshot below.

You can also hide specific control panel items as well as shown below.

Both administrative templates and the settings catalog can be used to manage the Control Panel using Intune. The settings catalog offers more comprehensive options, including all settings available in Administrative Templates plus additional ones. It allows administrators to search for specific settings and create custom groups. However, in many cases, both alternatives may prove equally effective for managing Control Panel settings. The choice often depends on the specific requirements of the organization and the preferences of the IT administrators.

Companies want to control the background image on their workstations to maintain a professional appearance, reinforce brand identity, and ensure consistency across all devices. It also prevents "genreal messing around" and at least looks tidy. .

Setting up a background image for on prem corporate workstations using Group Policy was straightforward.

• An administrator stored the background image on a network share
• A GPO was created to point to the shared image

However, for mobile and remote machines, this approach is not feasible as these devices are often disconnected from the corporate network.

Intune provides a solution for assigning a background image to any Windows computing device it manages, regardless of location. The first step is to store your shared image on the internet as I have done below.

https://cdnsm5-ss9.fabrikam.com/UserFiles/Servers/Server_136424/Image/Departments/Technology/UserBackground.jpg

Then, using the Microsoft Intune Admin Center navigate to Devices > Configuration > Create New policy and select Windows 10 and later as the platform and settings catalog as the Profile type. Using the Settings picker, do a search for personalization. Then choose Desktop Image URL and input the URL as shown in the screenshot below.

Another key difference here is that with Group Policy, the image is not downloaded to the device. The policy simply points to the image in its shared location. Using Intune, both the policy and image file are pushed to the managed devices, and the image is stored on the device itself.

This makes Intune a preferred solution for off-premises machines. Like any configuration profile, the final step is to assign the policy to the designated groups, and you are done.

Nearby Sharing is a feature in Windows 10 and Windows 11 that allows you to transfer documents, pictures, and links to other compatible devices that are near each other using a combination of Bluetooth and wireless communication. It’s a great feature that fosters collaboration between team members. Maybe. So indeed, there are some instances in which you don’t want to allow this feature such as an educational environment where students are taking an online exam for instance. We will look at a couple of ways to disable this feature.

Nearby Sharing is found under Shared experiences in your system settings as shown below.

To manage Nearby Sharing using Group Policy, create a GPO and go to Computer Configuration > Policies > Administrative Templates > System\Group Policy > and disable “Continue experiences on this device” as shown in the screenshot below. When disabled, Windows device will not be discoverable by other devices and cannot participate in cross-device experiences.

If you want to use Intune, create a configuration profile, and select Windows 10 and later as the platform and choose Templates > Administrative templates as the profile. Then follow the same template path - Computer Configuration > Policies > Administrative Templates > System\Group Policy > and disable “Continue experiences on this device” as shown below.

Users will no longer be able to transfer files amongst each other on their enterprise devices.

There are no guarantees in life. That’s certainly the case with software updates. Sometimes an update that offers a new operating system version just doesn’t’ work out due to compatibility issues with a particular device. This can cause the update to either fail or rollback. Even worse, it could result in data loss or a loss of connectivity or key functionality.  That’s why Microsoft monitors quality and compatibility data to identify issues before they can affect too many machines. Issues may also be reported from Microsoft partners and customers as well. Once these issues are identified, Microsoft enacts a Safeguard Hold to prevent other devices with this known compatibility issue from being offered the designated feature update. The safeguard hold is enforced long enough to give Microsoft ample time to address the issue. Once a fix is derived and verified, the hold is lifted, and the Windows update will once again be readily offered to devices.

Disabling Safeguards

While its not necessarily recommended, you can disable safeguards so that devices will ignore them. Keep in mind that the update may likely fail. If you want to take the chance, however, create a GPO and go to Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business and enable the “Disable safeguards for Feature Updates” setting as shown below.

You can also do this using an MDM such as Microsoft Endpoint Manager with the DisableWUfBSafeguards CSP. The required custom OMA-URI settings are as follows:

• OMA-URI: ./Vendor/MSFT/Policy/Config/Update/DisableWUfBSafeguards
• Data type: Select Integer
• Value: 1

Safeguards for Two Types of Issues

New Windows feature updates that are deployed using either Windows Update service or Windows Update for Business are subject to Safeguard holds for a known issue.  A “known issue” is a confirmed problem that may occur after an upgrade for a specific set of devices. In addition to known issues, there are also “likely issues.” A likely issue means that the problem has not been confirmed by Microsoft but has been discovered through machine learning out in the ecosphere. Issues could involve rollbacks, connectivity issues, app or driver malfunction as well as problems with graphics and audio. Once identified, a temporary safeguard hold is enabled on the designated update until either the issue has been confirmed and upgraded to a known issue (in which the safeguard hold is continued) or it has been identified as a false positive, in which case the hold is removed.

The Windows Update for Business Deployment Service

The Windows Update for Business deployment service is a cloud service within the Windows Update for Business product family. It provides a next level of control concerning the approval, scheduling, and safeguarding of Windows updates. Here you can use safeguard holds against likely updates issues. You can also do things such as bypass preconfigured Windows Update for Business policies to manually deploy a security update on command across your organization should an emergency arise. To utilize this service, you must have one of the following subscriptions:

• Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5)
• Windows 10/11 Education A3 or A5 (included in Microsoft 365 A3 or A5)
• Windows Virtual Desktop Access E3 or E5
• Microsoft 365 Business Premium

You can then do a search for it in MEM and configure as you need to.

To see if you are affected by a Safeguard hold you can use Update Compliance in MEM to run a Safeguard Holds report that can provide insights into existing holds that are preventing devices from updating or upgrading. You can get more information about these reports here.

Microsoft just released a security baseline for Microsoft Edge version 104.  Be aware that when you go to download it you won’t see version 104 listed because it still utilizes version 98 as none of the security policies have changed yet. Microsoft v104 introduced 12 new settings that can be used within Computer and User policies. The new setting policies are as follows:

• Allow import of data from other browsers on each Microsoft Edge launch
• Configure browser process code integrity guard setting
• Define domains allowed to access Google Workspace
• Double Click feature in Microsoft Edge enabled (only available in China)
• Enable Drop feature in Microsoft Edge
• Get user confirmation before closing a browser window with multiple tabs
• Text prediction enabled by default
• XFA support in native PDF reader enabled
• Enables Microsoft Edge mini menu *
• Get user confirmation before closing a browser window with multiple tabs *
• Restrict the length of passwords that can be saved in the Password Manager

* These policies are available as both mandatory and user override settings

You can download the three ADMX templates new for Edge version 104 here as shown below.

One of these settings, “Configure browser process code integrity guard setting” restricts the ability to load non-Microsoft signed binaries. When enabled, there are three mode options:

• Disabled (0) = Do not enable code integrity guard in the browser process.
• Audit (1) = Enable code integrity guard audit mode in the browser process.
• Enabled (2) = Enable code integrity guard enforcement in the browser process.

Administrators are encouraged to run this setting in Audit mode (1) early on for compatibility purposes. Audit mode is currently the default but a future security baseline will change this to Enabled (2) once Microsoft has enough data to proceed.  The setting options are shown in the screenshot below:

If you haven’t yet imported the secruity baseline, you can do so by running the Baseline-ADImport.ps1 script as shown below.

You can refer to my blog on the Security Baseline for Edge v95 for more information about how to use security baselines for Microsoft Edge.

Welcome to Part 2 of this article series in which we take a look at the primary policy types that you can create and utilize in Microsoft Endpoint Microsoft (Intune).  In Part 1 we looked at Configuration Profiles and how they are the rough equivalent of GPOs in a traditional AD on premise domain in which some things were hidden, others revealed.  Here we will examine some of the other major components of MEM, all pertaining to security.

Security Baselines

Also referred to Security Profiles, Security Baselines are sets of Windows settings that are preconfigured by Microsoft Security engineers.  There are currently 3 Security Baselines as is shown below.  They are

• Windows 10 Security Baseline
• Microsoft Defender ATP Baseline
• Microsoft Edge Baseline

The baselines by themselves don’t really do anything until you use one of them to create a security policy.  To create a profile you simply click on the appropriate baseline and then create your desired policy.  Baselines should be looked at as minimum security standards, although for most enterprises, they would work admirably.  You can change any of the settings, but keep in mind that when you unconfigure a setting, you are making it less secure.  In most cases, you should simply accept the settings as is and deploy the policies to their targeted users and devices.  The screenshot below shows the preconfigured BitLocker settings within the Windows 10 Security Baseline.

Compliance Policies

Compliance Policies are used to determine whether a device is compliant with a pre-defined baseline.  Compliance Policies vary on the platform of the device.  Some examples of Windows 10 compliant baselines can include the following:

• BitLocker enabled
• Minimum OS version
• Password qualities
• Firewall enabled and configured
• Location of the device

You can then select a noncompliance action such as an email notification sent to the user informing them of their device’s noncompliance state.  You can even lock or retire a device that has been noncompliant for a specified duration.  An example of a Compliance Policy requiring a minimum Windows 10 OS version is shown below:

Conditional Access Policies

Conditional Access Policies work hand-in-hand with Compliance Policies.  They prevent access to noncompliant devices.  For instance, you can prevent devices connecting from anywhere outside of the U.S. for instance.  You can also list other conditional access requirements such as the installation of approved applications or MFA as shown in the screenshot below.  You should always test your Conditional Access Policies first as you could deny everyone access including yourself. 

Enrollment Restrictions

Although not a “policy” per se, Enrollment Restrictions play an important role in MEM security.  By default, authorized users can enroll 2 devices into the MEM portal.  If don’t want the default, you can create enrollment restrictions that will allow users to enroll anywhere from 1 to 15 devices.  You can also assign Device Type Restrictions that will prevent users from enrolling either personal devices, or designated device version platforms as is shown in the screenshot below.

Creating a MEM Strategy

As you can see, there are a lot of moving parts in MEM.  The key is to ensure that all of your policies and restrictive settings work in conjunction of one another in order to safeguard your organization as well as ensure that your users can perform their required digital workloads.  While MEM alone falls short of the granular setting coverability of Group Policy, it can play an important role for new startups and established companies that have significant numbers of mobile and remote devices.

One of the principles of proper AD administration is to congregate your users into groups to make it easier to assign permissions and rights.  We use groups within Intune as well for this same reason.  In this case, Intune uses Azure AD to manage access to your company’s resources which is controlled using roles in the directory.  There are two default groups within every implementation of Intune.

• All devices
• All users

If you are using Intune for Education and you use School Data Sync to import you school records, you have two additional default groups.

• All teachers
• All users

These default groups represent a very broad scope and by themselves probably aren’t of much use.  That is why we need to create custom groups that can be tailored to the needs of our organization. There are two types of custom created groups in Intune, one being Assigned Groups.  Assigned groups are used when you want to manually add specific users or devices to a group.  You can create groups by a number of criteria such as geographic location, department, hardware characteristics, etc.  For instance, you could create one assigned group for your Windows 10 devices and one for your iPads.  You could create one for your desktop PCs and one for your mobile devices.  You can separate users into separate groups as well such as HR, Finance and Marketing.  You can then use those groups to assign policies to users or deploy apps to a set of devices.  Note that the ability to create custom groups is available in any MDM service, not just Intune.

Creating a group is easy.  Go to the Groups section of Intune and click “New Group.”  Then add the required information for that group.  In this case we would select “Assigned” as the membership type. 

Once the group is made, you can then assign users to that group.  Note that just as in domain joined AD, you can nest groups within one another.  These subgroups can be used to break down large groups into smaller more manageable sizes.  Groups have a hierarchical structure to them in Intune which allows for inheritance.  Parent groups are at the top of the hierarchy and any settings applied to these parent groups are passed down to the subgroups.  This settings inheritance feature makes it easer to apply settings to large numbers of users and devices.  Know that you can only create subgroups under assigned groups.

So Assigned Groups are great and there are many uses for them.  But we live in a dynamic world today and our Azure/Intune environments are often reflective of that.  Things change, and sometimes we need our groups to adapt to those changes.  That is why we also have Dynamic Groups.  Rather than specifying the users or devices to add to a group, we set criteria to define the members of a Dynamic Group.   When the specified condition applies for a user or device, it is added to the group automatically.  Should a member no longer satisfy the rule, it is removed from the group.  The use of Dynamic Groups can greatly reduce the administrative overhead of constantly adding and removing users for large enterprise environments that perpetually change.

There are a couple of things that are different when creating Dynamic Groups.  First off, P1 or P2 licensing is required to create and use Dynamic groups.  Second of all, we must make separate groups for users and devices as is shown below.

Once we create our Dynamic Group, we need to populate it.  Remember, we don’t select the users or devices ourselves.  We cannot manually add or remove a member from a Dynamic group.  We create membership rules which will then populate the groups by querying Azure AD to find the members that meet the criteria of that rule.  Make note again that we cannot create a rule that contains both users and devices.

There are two types of rules, Simple and Advanced.  I assume everyone wants to start with the easier one first so let’s create a Simple Rule.

A membership rule has 3 components:

• A property
• An operator
• A value

Say we wanted to create a dynamic group to include all current users of the HR Department.  In this case the property would be “department,” the operator would be “equals,” and the value would be HR.  If this isn’t sounding very simple, think again, because the Simple Rule creator interface does a great job of guiding you through the process.  You just simply choose which option you want from each component menu.  This of course means that your rules are limited to the choices made available in the GUI.

So what about Advanced Rules?  Well sometimes you may want to run extensive queries that go beyond the confines of the Simple rule creation process.  Creating Advanced rules may look a little intimidating because there is no easy to follow GUI menu to guide you.  Instead you only get a text box where you write out your rule.  Actually its not that intimidating.  We could have created an Advanced rule for our previous example for those users who belong to the HR Department.  The “rule equation” per say would be as follows:

(user.department -eq "HR")

A good example of when you might need to use an Advanced rule would be if you are applying multiple criteria in a single rule.  For instance, you want to create a Dynamic device group for Windows 1809 devices.  In this example, the rule would have to first query for Windows devices and then perform a subsequent query for the build number, which in this case is “10.0.17758.”  The resulting rule would then be as follows:

(device.deviceOSType -eq “Windows”) -and (device.deviceOSVersion -startsWith “10.0.17758”)