Group Policy and Intune both offer multiple ways to hide various components of the Windows operating system. One of these is the "Settings Page Visibility" setting that is specifically designed for managing the visibility of individual pages within the Windows Settings app introduced in Windows 10. This is distinct from the practice of hiding individual applets within the traditional Control Panel. By controlling visibility, you can streamline the user experience by ensuring they only see the settings they need, thus minimizing potential confusion or mistakes.

Note that the "Settings Page Visibility" policy only determines whether a page is visible or hidden to users. If you hide a settings page, users cannot see or access it, but this does not deactivate or override the actual functionalities or policies that might be set elsewhere.

I will show you how to configure the "Settings Page Visibility" policy in both Group Policy and Intune.

Group Policy

Create a GPO and go to Computer Configuration > Administrative Templates > Control Panel > Settings Page Visibility. You will then enable the policy and configure the settings as shown in the screenshot below.

You have two options for this setting.

• Use the hide: command to hide specific pages.
• Use the showonly: command to show only specific pages and hide all others.

You then follow either command by the Uniform Resource Identifier (URI) of the resource you want to apply the command to. For instance, if you want to hide the Window game bar you would type the following:

Hide: ms-settings:gaming-gamebar

If you want to hide additional settings, simply separate each URI by a semicolon. For instance, if you want to hide the Windows gamebar as well as advanced network and internet settings, the command will look as follows:

Hide: ms-settings:gaming-gamebar;ms-settings:network-advancedsettings

Let’s use an example for the showonly: command.

showonly:display;bluetooth

You can add as many URIs as you need to the policy. Once completed, assign the GPO to your designated groups and you are ready to deploy. You can refer here for a list of URIs.

Intune

To configure the "Settings Page Visibility" equivalent in Intune go to your Microsoft Intune admin center portal and navigate to Devices > Configuration profiles.

• Create a new profile and choose “Windows 10 and later” as the Platform and choose “Settings catalog” as the Profile type.
• Name the profile and click Add settings.
• In the settings picker type “visibility”
• Choose between the 2 Page Visibility List options

In this example I will choose Page Visibility List because I want to apply the profile to users as shown below.

Use the same command structure as in Group Policy.

Then assign any scope tags, your designated groups and complete the creation process.  

LAPS offers an effective method to limit local administrative privileges by generating a unique password for each Windows computer in your enterprise. However, for enhanced security and compliance, it's advisable to monitor who is accessing the passwords for specific machines. For Azure-joined devices go to your Azure portal and navigate to Devices > Audit Logs and then search for “Recover device local administrator password” as shown in the example below.

You can then click on the event to view more information as shown here.

This system effectively restricts access to clear-text passwords, ensuring only individuals with specific administrative roles, like Global Administrators, Cloud Device Administrators, and Intune Administrators, can access them.

Microsoft Defender for Identity (formerly known as Azure Advanced Threat Protection or Azure ATP) is a cloud-based security service offered by Microsoft to help protect your on-prem Active Directory environment. It leverages artificial intelligence, network, and behavioral analytics to detect abnormal behavior and activities that could be potentially threatening.  It can then provide security alerts and actionable insights to protect against cyber threats targeting identities and credentials. Some of its capabilities include the following:

• Analyze user behaviors and activities with learning-driven metrics
• Safeguard user identities and credentials within Active Directory
• Identify and investigate abnormal user behaviors and advanced threat patterns
• Provide incident details on a streamlined timeline for efficient resolution.

Requirements for Microsoft Defender for Identity

To use Microsoft Defender for Identity you will need a license for Enterprise Mobility + Security E5 (EMS E5/A5), Microsoft 365 E5 (M365 E5/A5/G5) or Microsoft 365 E5/A5/G5. Standalone Defender for Identity licenses are also available. You will also need an Azure AD tenant with at least one global/security administrator with a Directory Service account with read access to all objects in the monitored domains.

In this article I am only going to cover how to configure your on-prem Group Policy and AD environment for audit events. You can refer to this installation guide as to how to install Microsoft Defender for Identity on Active Directory or Active Directory Federation Services (AD FS) servers.

Configuring Group Policy

For Microsoft Defender for Identity to fully function, you must enable and configure certain audit events in Group Policy. Microsoft Defender for Identity then uses this audit data to detect suspicious activities and security vulnerabilities in real-time. To configure the audit events, you need use Group Policy Management Editor to either create a new GPO and link it to the Domain Controllers OU or edit and configure the Default Domain Controllers Policy. In the example below I am choosing to modify the existing policy.

Start by going navigating to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies. Start with the Account Logon policy and select “Audit Credential Validation.” Configure this and all the following audit events for both Success and Failure events as shown in the screenshot below. This will trigger Event ID 4776 in the security logs in Event Viewer.

Next will be the Account Management audit policy where you will enable the following subcategories for both Success and Failure.

Then move to the DS Access audit policy and enable “Audit Directory Service Access” for Event ID 4662 and then enable “Audit Directory Service Changes” for Event ID 5136. Wrap things up by moving on to the System audit policy and enable “Audit Directory Service Changes” audit for Event ID 5136.

Configure Object Auditing

Note that to collect 4662 events you will need to configure object auditing on the user, group, and computer objects. This is performed using Active Directory Users and Computers. Make sure you select the View menu and select Advanced Features as shown below.

Then right click on your domain, select Advanced Features > go to the Security Tab and click Advanced as shown here.

In Advanced Security Settings> choose the Auditing tab and Select Add.

Select Everyone as the principal. Upon returning to the Auditing Entry, configure these settings:

Choose "Success" for the 'Type'.

For 'Applies to', opt for 'Descendant User objects'.

In the Permissions section, navigate downwards and click the 'Clear all' button.

Now scroll up and choose "Full Control," which will auto-select all permissions. Next, deselect "List contents," "Read all properties," and "Read permissions." Click OK. This action sets the Properties to "Write" mode. As a result, any pertinent changes to the directory services will register as 4662 events. The final configuration is shown below.

Now complete the same steps but select the following object types for Applies to:

• • Descendant Group Objects
  • Descendant Computer Objects
  • Descendant msDS-GroupManagedServiceAccount Objects
  • Descendant msDS-ManagedServiceAccount Objects

Enable auditing on an ADFS object

In the steps above we configured auditing for the entire Domain. Some detections only require auditing in specific Active Directory objects however. Return to the Active Directory Users and Computers console, and choose the domain you want to enable the logs on.

• Navigate to Program Data > Microsoft > ADFS.
• Right-click on ADFS and choose Properties.
• Navigate to the Security tab and click on Advanced.
• Within Advanced Security Settings, go to the Auditing tab and click Add.
• Click on 'Select a principal'.
• In the field labeled 'Enter the object name to select', input 'Everyone'. Click 'Check Names', and then click OK.
• You'll be taken back to the Auditing Entry. Configure the following settings:
• For 'Type', choose 'All'.
• For 'Applies to', pick 'This object and all descendant objects'.
• In the Permissions section, first click 'Clear all'. Then select 'Read all properties' and 'Write all properties'.

Click OK out of all windows.

Enable auditing on the Configuration container

We just have one more step to go and here you will need to launch the ADSI Edit consol which you can access by typine ADSIEdit.msc in the Run Command.

• From the Action menu, choose Connect to.
• In the Connection Settings pop-up, from the 'Select a well known Naming Context' dropdown, choose Configuration, and then click OK.
• Navigate to the Configuration container and expand it. Inside, you'll find the Configuration node, which starts with "CN=Configuration,DC=..."
• Right-click on this Configuration node and choose Properties as shown below.

• Now navigate to the Security tab and click "Advanced."
• Once inside Advanced Security Settings, opt for the Auditing tab and click "Add."
• Click on "Select a principal."
• In the ensuing field, input "Everyone", then click "Check Names", followed by "OK."

Now, back in the Auditing Entry, adjust these settings:

• Set 'Type' to 'All'.
• Under 'Applies to', choose 'This object and all descendant objects'.
• Within Permissions, first hit 'Clear all', then check 'Write all properties' as shown in the example below.

Click OK out of all windows and you are done.

Most organizations have more than one wireless SSID for their users. For example, a school might designate separate SSIDs for staff and students. Similarly, a business could have distinct SSIDs for regular employees and those with privileged access. These SSIDs are then paired with specific access policies, managed either through the native wireless manager or external tools like SD-WAN solutions. In our school scenario, the student's SSID might provide direct internet access, whereas the staff's SSID offers connectivity to internal resources like printers. For IT teams or personnel requiring complete network access, there's typically an unrestricted SSID in place.

With Intune, you can designate a specific wireless SSID for users. Additionally, Intune facilitates the use of WPA2-Personal wireless configurations, automatically supplying computers with the pre-shared key. This eliminates the need for users to manually enter it and allows for the implementation of intricate passwords of up to 64 characters, bolstering security. With this setup, you can also keep SSIDs hidden so that the visible SSID on your premises is for the guest network.

To configure wireless policies using the Microsoft Intune Admin Center go to Devices > Configuration profiles and click Create Profile. Select Windows 10 and later as your Platform and WiFi Templates as your Profile. Name your profile and then configure the settings as shown below. Here I have enabled “Connect automatically when in range” and “Connect to this network even when it is not broadcasting its SSID.”

Once configured, assign the profile to your designated groups. When onboarding new computers using Autopilot or a package you will need to manually connect the Windows device to a wireless SSID. Once Intune delivers WiFi profile, the computer will possess the necessary SSID details to connect automatically to an assigned SSID depending on the user that signs in.

Group Policy admins have been mapping drives for years, while trying to map network drives using an MDM has proved challenging. The good news is that you can use both Group Policy Preferences and Microsoft Intune to map network drives for your users. Its just a lot easier with Group Policy.

Mapping Drives with Group Policy Preferences

Let’s start with Group Policy. Create a GPO using the Group Policy Management Console and go to User Configuration > Preferences> Windows Settings > Drive Maps. As this is a brand-new mapping I will select Create as the Action. Then type in the UNC path of the shared folder you want users to access. Check the Reconnect box to make it a persistent connection that will appear every time they log on. Under Drive Letter, I assigned a specific drive letter as shown below.

Because I am using Group Policy Preferences I can take advantage of Item-level Targeting to target the GPO more specifically at the exact users I want. Item-level Targeting is a feature not available in traditional Group Policy or Intune. In this case I want to target it to members of the managers group, but only have the mapping applied to desktop computers running Windows 10. The screenshot below shows how I did this after clicking on the Common tab.

Mapping Network Drives with Intune

For users who solely use their laptops for mobile or remote functions, mapping a network drive to a laptop managed by an MDM may not be logical. However, if all your computers are joined to Azure Domain and you wish to map drives, Intune doesn't provide a straightforward menu-driven method. You'll need to rely on PowerShell. Begin by creating a PowerShell cmdlet, structured as follows:

New-PSDrive -Name "M" -PSProvider FileSystem -Root "ADDRESSOFTHEFILESHARE" -Persist

In this instance, the cmdlet looks like this:

New-PSDrive -Name "M" -PSProvider FileSystem -Root “\\Fileserver1\Marketing” -Persist

BTW – If you wanted to use PS to map a local drive, it would look like the following:

New-PSDrive -Name "Document" -PSProvider "FileSystem" -Root "C:\Users\susan\Documents"

Save your PS script and now go to the Microsoft Intune Admin Center. Go to Devices > Scripts and Add a Windows 10 Script. Name the script and then configure the following settings as shown in the screenshot below.

Then assign the script to the designated users and finish out the wizard. For those who don’t want to use PowerShell, there are third-party solutions out there such as custom ADMX templates that you can download and then import into Intune

Typosquatting, often referred to as URL hijacking or domain mimicking, involves registering domain names strikingly similar to well-known websites. It preys on users who mistype web addresses, leading them to imitation websites instead of their intended destinations. Once there, users might unknowingly enter sensitive information or inadvertently download malware.

Major browsers like Microsoft Edge have built-in typosquatting protection. If users enter a potentially harmful site address by mistake, Edge alerts them. Though this feature is typically active by default, it's wise to verify its status. You can do this with Intune by creating a Configuration Profile.

Create a new Configuration Profile and select ‘Windows 10 and later’ as the Platform and choose the Settings catalog as the Profile. Click ‘Add settings’ > search for the word ‘typo’ and select:

Microsoft Edge \Typosquatting Checker Settings.

You can then choose either of the Configure Edge TyposquattingChecker options as shown in the example below. I chose both just to illustrate. Once selected you can enable the settings to the left. Then click Next and assign the policy to your designated groups and save it.

You’ve just deployed a new application or client-side extension to your Windows laptops and suddenly their system performance and battery life begin to crater. The culprit could be Windows Defender. Windows Defender automatically scans new software and its activities for potential threats as part of its real-time scanning feature. Naturally, this scanning process will manifest as higher CPU usage. If the new software handles a lot of data, such as in the case of a web filter client app, it could create perpetual CPU spikes that can degrade system performance and consume battery power.

If you trust the new software you've installed and don't want Windows Defender to continuously monitor it (and thereby use up CPU resources), you can set an exclusion path for it. An exclusion path tells Windows Defender to skip scanning the files and activities associated with a specific directory where trusted applications are installed. You can create an exclusion path policy using either Group Policy or an MDM such as Intune. Exclusions should always be used judiciously to maintain a strong security posture so only use them when you need to.

Creating Path Exclusions with Group Policy

Let’s use a scenario in which I need to create an exclusion path for a web filter client application simply called WebFilter. Create a GPO and go to Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Exclusions and enable “Path Exclusions.”  Once enabled you must then add the path(s) to be excluded. In this case there are two paths.

C:\Program Files (x86)\WebFilter\AuthenticationAgent\bin

C:\Program Files (x86)\WebFilter\MobileZoneAgent\bin

The policy configuration is shown below.

Another option is to create a process exclusion which would exclude a designated process or executable from being scanned. In this case the process path might be C:\ProgramFiles\WebFilter\WebFilter.exe. You can also use wildcards in a process exclusion list such as C:\ProgramFiles\WebFilter\*

Creating Path Exclusions with Group Policy

Using the Microsoft Intune Center, go to Devices > Configuration Profiles > and create a new profile using Windows 10 and later as the Platform and Administrative Templates for the Profile type. Name the policy and then navigate to Computer Configuration > Windows Components > Microsoft Defender Antivirus and Enable “Path Exclusions” as I did earlier with Group Policy as shown below.

You will then be prompted to provide the exclusion paths as shown below. Process Exclusions are also available if you want to go that way.

After implementing these path exclusions, you should witness a notable decrease in CPU utilization, effectively resolving the issue of CPU spikes and battery depletion.

Group Policy veterans will recall when it was common practice to redirect user files from the Windows known folders (like Desktop, Documents, and Pictures) to a central shared directory on an on-prem server. This allowed for roaming profiles, easier backups, and kept files off client devices. Well, you can also redirect those same files to OneDrive for Business to accommodate real-time collaboration and accessibility, compliance, and control.

If you aren’t currently utilizing OneDrive, you should as it offers a list of great features. First off, it maintains the user familiarity with file locations so folder navigation is the same. Because OneDrive is cloud bases, your users can access their files from anywhere on any device. It also offers file versioning and deleted items capabilities that allows users to perform self-service file recovering.  Here I will show you how to redirect the Windows known folders to OneDrive as well as a couple of other tips.

Using Group Policy to Manage OneDrive

If you have any existing Folder Redirection Group Policies, you will need to disable those before moving forward. Then make sure you have the necessary administrative template files. If you have OneDrive installed on your management machine you can get them using this file path.

%localappdata%\Microsoft\OneDrive\BuildNumber\adm

Which will look something like this in Windows Explorer.

Copy both template files to your central store and then create a GPO. In the Group Policy Management Editor, go to Computer Configuration > Administrative Templates > OneDrive. If you don’t see OneDrive, then you are missing the template files. The screenshot below shows the available settings.

To redirect files from the Windows Known folders, enable the “Silently move Windows known folders to OneDrive” and provide the Tenant ID for your enterprise. By default, all three known folders are selected but you can choose to only redirect specific ones as shown in the screenshot below.

Before implementing this, you may want to alert users of your intention for them to transition to OneDrive for Business by enabling the “Prompt user to move Windows Known folders to OneDrive.” Once enabled, your tenant users that sync their OneDrive will see a popup message that reads “Your IT department wants you to protect your important folders" the next time they sign in. A reminder notification will then appear in the activity center until all three known folders are moved.

Users also may have more than one OneDrive account so you may want to prevent them from uploading files to other organizations. You can do this by enabling the “Allow syncing OneDrive accounts to only specific organizations” and then list the allowed tenant IDs as is shown below.

Using Intune to Redirect Known Folders to Intune

Let’s do the same thing using Intune now. Using the Microsoft Intune Admin Center, navigate to Devices > Configuration profile > Create profile and select Windows 10 and later as the Platform and Administrative templates as the Profile type. Give a name to the profile and go to Computer Configuration > OneDrive and enable the “Silently move Windows known folders to OneDrive” setting as shown in the screenshot below.

To discourage users from uploading excessively large files or questionable file types, you can enable “Exclude specific kinds of files from being uploaded” and input keywords for the designated file types as shown below.

Blocking the C drive has always been one of the common restrictions that Group Policy admins enforced for standard user accounts. There are multiple reasons for restricting access to the C Drive for non admin users.

• The first is system stability because it prevents basic users from accessing, altering, or deleting critical system files on their computers, thus minimizing potential issues that disrupt desktop operations and initiate a help desk ticket.
• It reduces the chances of malware being introduced into the system and prevents users from installing unauthorized applications, opening suspicious files or clicking on malicious executables.
• Blocking the C drive in some cases may be required by compliance regulations to restrict user access to certain system resources.
• Keeping users out of the C drive can potentially simplify troubleshooting as it eliminates user file tampering.
• For shared desktop computers it can help protect the data of other users who have logged onto the device

Because Intune uses many of the same Windows Administrative Templates, it is easy to block C Drive access with Intune as well. Using the Microsoft Intune admin center, go to Devices > Configuration Profiles and click “Create profile.”  Select “Windows 10 and later” as the Platform and Administrative Templates as the profile. Name the configuration profile and go to User Configuration > Windows Components > File Explorer as shown in the screenshot below.

Scroll down through the settings and select “Prevent access to drives from My Computer” and choose Enabled. You can then select the drives you wish to block access to as shown below.

Click OK and click next. Then assign the configuration profile to the designated groups and you are done.

Personal Data Encryption (PDE) is a security feature introduced in Windows 11, version 22H2 that provides an additional encryption capability to Windows. PDE is different than BitLocker in that it encrypts individual files while BitLocker encrypts entire volumes. PDE utilizes Windows Hello for Business to link encryption keys with user credentials. This means you need only log on a single time while BitLocker requires a separate PIN be inputted. Another difference is that unlike BitLocker that releases data encryption keys at bootup, PDE releases them once a user signs in using Windows Hello for Business. Until then, users cannot access the protected file content.

There are 3 prerequisites for PDE:

1. The computer must be Azure AD joined
2. It must be running the Enterprise or Education edition of Windows 11, version 22H2 or later
3. Windows Hello for Business Overview

Windows Hello provides fully integrated biometric authentication based on either facial recognition or fingerprint matching. Many laptops today have fingerprint readers or integrated compatible cameras to support it.

You should consider PDE as just another encryption layer for Windows on top of BitLocker that administrators can use to safeguard sensitive data. Don’t be confused by its name because standard users cannot initiate PDE, nor can they protect personal files with it. When you stop to think about it, it makes sense as you wouldn’t want malicious insiders to use it to hide data they shouldn’t have on their corporate devices. PDE can only be implemented by administrators who also selectively choose which filles to encrypt. PDE is ideal for business applications that work with sensitive files and should be heavily considered by those organizations that must adhere to compliance requirements.

You can enable PDE through Intune. By default, PDE on Windows 11 Devices in the Intune settings catalog is disabled. There are two ways to enable PDE in the Microsoft Intune Admin Center. The easiest way is to navigate to Devices > Configuration profiles and choose the Settings catalog as the profile. Using the Settings picker, search for personal data encryption and select the PDE category. Then check enable “Personal Data Encryption” as shown below.

Assign the policy to the designated groups or users and save it. You can also use OMA-URI settings to create the policy using:

./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption

as the OMA-URI path.  Then choose integer as the data type with an assigned value as 1. The final configuration should look like the screenshot below.

While support for PDE is limited currently, more applications will utilize it in the future.