How do you get smarter in MDM & Group Policy?

Upcoming Training Classes

With Jeremy Moskowitz

To purchase about a Live Group Policy Class (Public or Private), or the Group Policy Health Check, please call Jeremy at 302-351-8408 or email register[[att]]

Get serious, and perform “Best Practices” around Group Policy management. Take back control and get your IT life back!

Dates Class Actions
No Public Classes Scheduled

Call if you have 3 or more people to help us get started! In the meantime, click here to checkout our Online Class

How do you get smarter in MDM & Group Policy?

Feb 2024

How to Block Access to Windows Copilot with Group Policy and Intune

Windows Copilot is a feature designed to enhance user productivity and support through AI-powered assistance directly within the Windows operating system. It offers real-time suggestions, automates tasks, and provides contextual help based on user actions and behaviors. By integrating deeply with Windows, Copilot simplifies navigation, streamlines workflows, and helps users efficiently manage their tasks, making technology more accessible and intuitive for everyone.

Think of Copilot as a specialized variant of ChatGPT, seamlessly integrated into the Windows operating system to provide real-time assistance, task automation, and contextual support directly from the desktop environment. Despite its clear advantages, there are potential concerns that an organization might have:

  • Copilot’s ability to analyze user data and behaviors might raise privacy concerns.
  • The use of AI tools may conflict with some security compliances concerning the handling of data.
  • Copilot may not be suitable for some roles that require precise communication.
  • While it promises to boost productivity, reliance on Copilot could diminish users' problem-solving abilities.
  • The introduction of Copilot may lead to new errors that can potentially disrupt workflows
  • In scenarios such as public kiosks, the functionality of Copilot may be unnecessary or even inappropriate.

Block with Group Policy

To restrict user access to Windows Copilot, create a GPO using Group Policy Management and then navigate to Computer > Administrative Templates > Windows Components > Windows CoPilot and enabe “Turn off Windows Copilot” as shown in the screenshot below.

Block with Intune

While Intune currently lacks a direct menu option for configuring Windows Copilot, but it can be administered through OMA-URI settings. The essential settings required are as follows:

OMA-URI Path: ./User/Vendor/MSFT/Policy/Config/WindowsAI/TurnOffWindowsCopilot

Data type: Integer

Value: 1

Complete the profile by adding any desired scope tags and assign the profile to your designated groups and finish the wizard.

Feb 2024

Lock Down the Windows Settings App with Intune

In the past, group policy administrators focused on limiting standard users' access to various sections of the Windows Control Panel. Today, while controlling access to the Control Panel remains important, it's equally crucial to restrict access to the Windows Settings app. This approach is driven by several key objectives:

  • Prevent unauthorized modifications that could undermine system security.
  • Ensure compliance of regulatory standards
  • Enhance the reliability of client devices and systems to reduce ticket volume.
  • Safeguard against both accidental and deliberate data loss scenarios.
  • Ensure computers are optimized for business-critical functions.
  • Facilitate device management and troubleshooting by maintaining consistent settings across the organization.

One way to approach this is rather than creating an Intune policy that restricts access to specific ms-settings, you use an allow list approach that only allows access to a specific list of settings. To do so using the Microsoft Intune Admin Center go to Devices > Configuration and click “Create” to make a new profile. Choose Windows 10 and later as the Platform and Custom Templates as the Profile type.

Using custom templates, assign the profile a name and apply the following OMA-URI settings:

OMA-URI: `./Device/Vendor/MSFT/Policy/Config/Settings/PageVisibilityList`

Data type: String

For the String value, type showonly: and list each msi-setting you want immediately after the colon. Separate each msi-setting with a semicolon like this:


The screenshot below shows the process using Intune:

Complete the profile by adding any desired scope tags and assign the profile to your designated groups and finish the wizard.

You can find a complete list of ms-settings names on the Microsoft website

Jan 2024

Be Careful When Applying Intune Conditional Access Policies

Conditional Access policies in Microsoft Intune are designed to enhance security by ensuring that only authorized users under specific conditions can access your organization's applications and services. These policies are a critical component of a zero-trust security model, which assumes breach and verifies each request as though it originates from an uncontrolled network. Conditional Access Policies are a potent security mechanism, yet they require careful management to avoid inadvertently locking out individual users including yourself, or even the entire organization.

Let’s say you have all your users and computers contained within Azure Active Directory and you want to create a conditional access policy that restricts access to the Azure AD portal for only Azure administrators or other privileged users that require access to perform their job duties. To create a conditional access policy using the Microsoft Intune Admin Center you navigate to Devices > Conditional Access and create a new policy.

The default action of this policy will be to block access by default to the Azure AD portal. Thus, under “Include” I have selected All users. Note the warning directly underneath this selection that cautions me about locking myself out as the policy will apply to all users, even the person creating the policy and all high privilege administrators.

Thus, it is imperative that I assign groups that will be excluded from the default action. As shown in the screenshot below, I have selected an assembly of users and groups to exclude.

The next step is to select a Target Resource. The target resource refers to the applications, services, or data that the policy will protect. These resources are what the policy conditions apply to, determining how and when users can access them based on specific criteria such as user identity, device compliance, location, and risk level. Target resources can include cloud applications, which in this case is Windows Azure Service Management as shown below.

For this policy, I will not set any conditions, such as location or device platform, because I intend to block access irrespective of these factors. The final step is to specify what action will be granted to the Azure portal. Here I am going to block access for all users except for those specifically excluded from this policy. Since I have yet to exclude my own account or any group that includes my account, Intune is providing a final warning, cautioning that the policy I'm about to implement will prevent me from accessing the Azure portal.

Conditional Access policies are a powerful tool to enforce least privilege access to your critical resources. However, caution is necessary, as a single unintended click could lead to adverse outcomes.



Jan 2024

GPUpdate vs GPUpdate / Force

This is certainly a topic I have written about in the past, but revisiting how to manually update Group Policy is worthwhile, given the ongoing confusion surrounding the topic. The choice between using `gpupdate` alone or with the `/force` option is a common query.

First, let's recap the automatic Group Policy update mechanisms:

1. Computer-side Group Policy Settings automatically refresh upon the restart of a domain member computer.

2. User-side Group Policy Settings refresh when a user logs onto a domain member computer.

3. By default, Group Policy Settings undergo an automatic refresh every 90 minutes, with a random offset of up to 30 minutes to prevent system overload against the DCs, so they dont fall over and di.=e.

However, there are situations where waiting for an automatic refresh or disrupting a user's session with a logoff or reboot is impractical, especially when immediate action is required. That is when the gupdate command comes into play using either command prompt or PowerShell.

While `gpupdate /force` can be used in any situation, making it a go-to for ensuring all policies are applied, it's not always the most efficient method. Let's explore the nuances between `gpupdate` and `gpupdate /force` to understand when each should be used for optimal Group Policy management.

GPUpdate by Itself

This command efficiently updates Group Policy settings for either a computer or user, applying only the changes made since the last refresh without reapplying unchanged settings of other policies. This command is typically used to apply changes made to a single policy. It is a less intrusive option, often employed for routine Group Policy maintenance. Serving as the go-to command for most needs, it ensures that recent policy adjustments are implemented swiftly and with minimal disruption. It's especially useful for testing or when needing to apply a newly created or revised policy to a specific computer or user session.

GPUpdate /Force
This command forces a refresh of all Group Policy settings, regardless of whether any have changed or not. It re-applies all settings, which can be useful for solving issues related to policy application or when a computer or user receives new policies for the first time. However, because it reapplies all policies, it can be more disruptive, potentially causing logon scripts to run again and requiring a logoff or restart for some policies to reapply effectively. If nothing else, it takes longer to enact and leaves you sitting idle. Use `gpupdate /force` when troubleshooting policy application problems or when you need to ensure that all policies apply again, not just the recently changed ones.