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]]moskowitz-inc.com

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?

Jan 2024
30

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
16

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.

Jan 2024
02

How to Use Scope Tags for Intune Configuration Profiles

How many times has this happened to you? You go about creating a new configuration profile using the Microsoft Intune Admin Center. You complete the setting creation process and now want to assign the profile to the designated groups. But before that, the wizard prompts you about Scope Tags as shown in the screenshot below.

Like other Intune administrators, you might often bypass scope tags by clicking Next, occasionally wondering about their purpose. Scope tags are vital for partitioning and controlling access to Intune resources, such as profiles, apps, and policies, to enable delegated administration. They allow for the classification of resources by department, function, or location, facilitating more efficient resource organization. This ensures administrators can readily manage resources relevant to their specific organizational segments. Although granular access control through scope tags might seem excessive for small to medium-sized organizations, it's incredibly beneficial for larger ones, enhancing security and compliance by restricting administrators' access only to their designated resources. This reduces the likelihood of unauthorized access or alterations to crucial settings.

Create Your Scope Tags

Start by generating your scope tags, envisioning them as segmentation tools that define which admins have access. Imagine a national company with offices across various regions. For this example, you'll create scope tags specifically for the administrative team stationed in this office that is responsible for managing the profiles and policies exclusive to the East Coast office. To configure this arrangement, you need to:

  • Create a member group called East Coast Admins which will contain the all admins of the east coast office that will have permission to manage policies and profiles for users and devices within the allotted scope.
  • Create a scope tag that will contain the east coast admin member group.

In this case I already have my east coast admin group. To create the scope tag using the Microsoft Intune Admin Center navigate to Tenant Administration > Roles > Scope Tags and create a scope tag and name it as shown below.

The next step is to add member group to the scope tag as shown here:

Next, finish the wizard to create your scope tag. With the scope tag established, you can apply it as necessary. The final step involves creating a configuration profile. When you reach the Scope Tag section this time, add the scope tag you've just created.

Then I will assign the device group that configuration profile will be applied to:

After finishing the wizard, I've set up a configuration profile targeted at East Coast computer devices. This allows East Coast admins to manage these devices specifically, utilizing the scope tag for focused oversight.

Dec 2023
18

Manage Defender Updates with-ADMX

With Windows 10, Group Policy administrators could configure whether Windows Defender receives its updates through standard Windows Update channels or alternative sources such as WSUS (Windows Server Update Services) or manually specified update locations. as shown below. You could set whether Windows Defender should receive updates through standard Windows Update channels, or through alternative means like WSUS (Windows Server Update Services) or manually specified sources.

In Windows 11, Group Policy administrators are now provided with the capability to select specific channels for acquiring virus signatures for both daily and monthly updates. This new feature offers enhanced control over how and from where these crucial security updates are sourced, aligning with the organization's specific requirements and IT infrastructure. The process is quite similar to the process of assigning devices to channels for Windows Update for Business. The new settings reside in the root directory of Microsoft Defender Antivirus as shown here.

 

First let’s talk about the different types of updates.

  1. Daily Security Intelligence Updates are frequent updates that provide the latest definitions for viruses, spyware, and other malware. These are essential for Microsoft Defender to recognize and protect against newly emerging threats once they have been identified.
  1. Monthly Engine Updates enhance the capabilities of Microsoft Defender’s threat detection such as scanning functionality and detection algorithms. In addition to improving threat identification and remediation, these updates help optimize the Defender’s performance and resource usage.
  1. Monthly Platform Updates introduce new functionality, features, and user interface modifications. They may also address identified bugs or vulnerabilities within the software itself.

Now, let’s talk about the various channels available.

  • Beta Channel: Devices assigned to it will be the first to receive new updates. These devices should be used for testing environments. Devices subscribed to the Windows Insider program are assigned to this channel by default.
  • Current Channel (Preview): Devices set to this channel will be offered updates earliest during the monthly gradual release cycle. This is recommended for devices in pre-production or validation environments.
  • Current Channel (Broad): Devices will be offered updates only after the gradual release cycle completes. Most of the devices in your production environment should be assigned here.
  • Current Channel (Staged): Devices assigned here will get updates later during the gradual release cycle but prior to the release to the majority of devices. Microsoft states that no more than 10% of your devices should be assigned to this channel.
  • Critical-Time delay: Devices will be offered updates with a 48-hour delay. This is suggested for devices in critical environments only.

The channel selection process for Monthly Engine and Monthly Platform updates is the same as shown in the screenshot below.

Daily Security Intelligence Updates have fewer channel options as they are much more pertinent.

Testimonials