Get Smarter

Unless you are an SMB, you are probably going to phase in your Windows 11 upgrade over time.  That means that you will have to manage both versions until the upgrade is complete, which might require you to manage their settings or application deployments differently.  If you are using Intune to manage your Windows machines, you can use filtering to reduce the complexity of doing so. 

You can use Intune filters to target configurations, policies, and applications to specific device attributes such as Manufacturer, Model and OS version.  In this case we will create two filters that each target a different OS version.  Using Microsoft Endpoint Manager go to Intune > Tenant administration > Filters and create a new filter and name it as shown below.

Create a rule and select osVersion as the property, StartsWith as the operator and 10.0.2 as the value which I did myself in the screenshot below.  Then finish out the wizard to complete the filter.

Now create a second filter.  There are a couple of options when creating these filters.  You could use the same approach as the previous filter and match it with the Windows 10 value.  In this example, we chose a different approach and instead used the NotEquals operator, typing in 10.0.2 as the value.  This means that any Windows version other than Windows 11 will be included in this filter.

Now that you have the filters created, you can start applying them when needed.  In the example below, I have created a configuration profile that I have assigned to a computer group.  The group is made up of both Windows 10 and Windows 11 machines.  Because I want this profile to only apply to Windows 11 machines, I will click the filter link and choose “include filtered devices in assignment” and select the Windows 11 filter I created earlier.

Finish out the wizard and the configuration profile will now only target Windows 11 devices.  Those familiar with Group Policy will note the similarity to WMI filtering.  Once you upgrade all your Windows 10 devices, simply delete its designated filter.   

Anyone who has been a Windows device admin for a school system that implements a student laptop program is aware of the constant battle to keep students in check when it comes to their devices.  A common ploy by the students is to reset their devices to factory default to bypass enforced security policies.  Even if students can’t get to system settings, they can always hold down the shift key while they use the mouse to select the Restart option from the Windows Start button.  This gets them to the Advanced Startup screen where they can then reset the device.  This of course starts the computer with a clean slate, giving students time to make local accounts on their device.  It also gives them access to the command prompt screen and other things.  For computers that are managed byGroup Policy, students that reset their devices off premise will enjoy a newfound freedom until the computer returns to campus and receives its assigned policies once again.  What’s more, a PC tech may have to manually deploy a package file to install the required applications, consuming precious time from both the student and the technician.  For those computers managed by an MDM provider, policies and applications will be deployed once the computer connects to the Internet, making any acquired freedom brief, but perhaps meaningful enough to be worth the effort to the student.

Even if you don’t work for a school system, you still might want to stop your users from resetting their devices.  Fortunately, there is an easy way to do it using AppLocker to create a policy that can be deployed using Group Policy or your preferred MDM solution that will prevent standard users from implementing a factory reset. 

Create an AppLocker Executable Rule

Using Windows Group Policy Management Editor, create a GPO and go to Computer Configuration > Security Settings > Application Control Policies > AppLocker > Executable Rules.  Right-click and select Create New Rule as shown in the screenshot below.

Using the wizard, choose Deny as the action.  You can target a specific group or just go with the default Everyone group as shown below.

In the next screen choose “Path” as the primary condition.  There are two path executables we need to block.  Each will require their own rule.  For this rule let’s choose:

C:\Windows\system32\systemreset.exe

as shown in the following screenshot.

Continue with the Wizard.  Name the rule and click Create.  Now create another executable rule using the same process.  This time we will use environmental variables for the file path which is %SYSTEM32\ReAgentc.exe.  Now you will have two rules as shown below.

Now assign the GPO to the targeted computers.  But what about Windows 10 devices that are managed by Microsoft Endpoint Manager or similar MDM provider?  In that instance, you can export the AppLocker rules by right-clicking on AppLocker and exporting the policy as shown below.

Name the policy and save it as an XML file.

Now import that XML file into MEM by going to Devices > Configuration profiles > Create policy > Windows 10 and later > Templates and choose Custom and click the Create button.

Now open the saved XML file with a text editor and highlight and copy all the content within the AppLocker tags as shown in the screenshot below.

Using the wizard, name the policy and go to configuration settings.  Here you will need to add the OMA-URI settings.  In the OMA-URI textbox you will input the following path:

/Vendor/MSFT/AppLocker/AppLocker/ApplicationLaunchRestrictions/apps/EXE/Policy

Choose String as the Data type and then paste the XML code you copied into the Value box as shown below.  Then click next until you finish out the wizard and create the policy.

You will then assign the policy to your targeted users.  The next time a student or user attempts a factory reset, they will receive a message informing them that the action is not allowed for their organization. 

Keeping your Windows devices updated is critical today, not only from a security point of view, but a productivity one as Microsoft continues to deliver new features that spawn greater user innovation.  Deploying these updates is only part of the equation when it.  A computer can download a feature update for instance, but unless the computer is rebooted, it won’t be fully installed.  Often, users will delay the rebooting process, thus prolonging the pending start status and preventing it from attaining compliance.  That’s why you must enforce compliance.  Both Group Policy and Microsoft Endpoint Manager (MEM) give admins the ability to create an enforceable compliance window to ensure that Windows update processes are fully completed.

Deadlines and Grace Periods

These compliance policies allow you to configure a deadline that defines the number of days until a device is forced to restart to ensure compliance.  You can also configure an additional grace period to give users a little extra window if needed.  Note that you are restricted to defined ranges when assigning these time windows.  For Group Policy the ranges are as follows:

• For quality updates the deadline can be between 0 and 7 days.
• For feature updates the deadline can be between 0 and 14 days
• Grace periods are limited to 0 to 3 days regardless of the type of update

MEM provides longer durations to accommodate mobile devices.

• For quality updates the deadline can be between 2 and 30 days.
• For feature updates the deadline can be between 2 and 30 days
• Grace periods are limited to 0 to 7 days regardless of the type of update

For quality updates, the deadline and grace period start once the update is offered to the computer.  In the case of feature updates, both start once the update has been installed and the computer reaches a pending restart state.

Configuring Compliance Policies

To enforce a compliance policy using the Group Policy Administrative Console, go to Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage end user experience and choose “Specify deadlines for automatic updates and restarts.”  You can then configure the deadline and grace periods for both quality and feature updates as shown below.

Note that you have other settings available concerning the restarting process that you can assign as well.

To configure deadline and grace period durations using the Microsoft Endpoint Manager admin center and go to Devices > Create Update ring for Windows 10 and later.  Turn on the Allow button to enable deadlines and then assign the deadline and grace period for each update category.    Note that the deadlines and grace periods are appended to any configured deferral period.  The process is shown in the screenshot below.

By enforcing update compliance for your Windows machines through GP or MDM, you can ensure that required update processes are completed, keeping your computers secure and maximizing user productivity. 

Many organizations are choosing to use some type of MDM provider to manage their mobile devices.  Some organizations are even turning to MDM for all of their client devices.  If you have been relying on Group Policy to deliver configuration and security settings to these your Windows devices, you should know that there is still a disparity gap between between Group Policy and an MDM such as Microsoft Endpiont Manager (MEM) when it comes to setting coverage.  While Microsoft has closed this gap considerably over the past couple of years, there are still a number of Group Policy settings that MEM and other MDM solutions don’t accommodate.   Obviously, you need to know what settings can’t be replicated when considering a move to MDM.

MEM now provides an easy to use tool called Group Policy Analytics (Preview) that will analyze your on-premise GPOs and determine how they will translate into the cloud.  It will analyze a specific GPO and identify which settings are supported in the MDM, which ones have been deprecated and which ones are simply not available.  The first step is to select the GPO you want to test out in the Group Policy Management Console.  As shown in the screenshot below, simply right click on your selected GPO and choose “Save Report.”  Save it as an XML file.

The next step is to import the XML file into MEM.  Using the MEM admin center, go to Devices > Group Policy analytics (preview).  Select Import and point to the saved XML file as shown in the screenshot below.  Note that the saved XML cannot be larger than 4 MB. 

Click the X in the upper righthand corner and wait for the analyzation process to complete.  You will then see the percentage of settings are supported by the MDM.

Now click on the stated percentage and review the status of all your settings.  The supported settings will list the corresponding CSP mapping in the righthand column as shown below.

Group Policy analytics is a great tool to determine the MDM setting coverage of your GPOs.  If any of the non-supported settings are critical to your management or security policies, you may want to continue using Group Policy for a while longer or utilize a third-party settings management solution.