Search This Blog

Monday, December 6, 2021

How to implement update compliance and telemetry data

Log Analytics Workspace + Update Compliance = awesomeness

In this video we will cover 5 good reasons to implement update compliance and how to implement it in your environment. We will go through which settings to setup in settings catalog in order to have the right telemetry level linked with your workspace. Lastly we show a very cool report from the MSEndpointmgr site.

Monday, November 22, 2021

How to debug policies in the cloud - RSOP for Intune


I do see a lot of environments transitioning from On-prem towards the cloud. One of the tasks in this journey is Group Policies which normally will have a huge workload on the business when starting to analyze and transforming the needed policies. Not saying that you should move anything, but you don’t know before you have gone through the stack of policies applied to the current environment. Better be prepared than sorry.

What is this blog post about? When you have a hybrid setup, which most larger customers do have at the moment, you will see a period of time where you transition from GPO’s to cloud policies where you have policies coming from 2 authorities. If a certain policy is not behaving, as you think it should, it can be hard to know where to look.

I’ll walk you through how to debug with a tool made by Andrew



  • Intune managed device (either co-managed or Intune only)
  • Permission to add an app registration


Create app registration to fetch data from Intune

Before we do anything, we need to register an application in Azure, so the user running the Intune diagnostic tool, does not need to have permission to Intune or any other Azure related sources.

Go to -> Azure Active Directory -> App registrations



Give it a name like: Get-ClientIntunePolicyResult or whatever you like to call it. Doesn’t really matter, just that you will be able to identify what the app registration does later on.

Press Register



Write down the client ID and save it for later.



Press Certificates & secrets



Press new client secret



You can set it to never expire but I think it is good to have some kind of governance around this to not forget what you have given access to. If it is still in use after 24 month you will have to revisit the client secret and renew it.

Press add



Write down the value as we will need that for later.



Go to API permissions and press “Add a permission”



Press Microsoft Graph



Press Application permissions










Grad admin consent for xxxxxxx



Press Yes



RSOP for Intune managed devices

Finally, to the interesting part of the blog

Go to a client where you like to debug.

Open PowerShell with admin credentials


Install-module PSWriteHtml -force

install-module Microsoft.Graph.Intune -force

install-module WindowsAutopilotIntune -force

install-script get-clientintunepolicyresult -force



And to the part where we will use the module to get our report of what policy target our device/user and who the winning provider is:


Get-ClientIntunePolicyResult -asHTML -getDataFromIntune -credential $intuneREADAppCred -tenantID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx -showEnrollmentIDs



Enter the AppID and the AppSecret that we saved earlier in this guide.

Press OK



Watch the magic happen.



What do we see here?







MDM policy wins over GPO

Now that we see the "WinningProvider" very clear we can help our environment to MDM policy that is set and has an equivalent GP policy will result in the GP service blocking the setting of the policy by GP MMC. This is how it is done.

Go to and navigate to Devices -> Windows -> Configuration profiles

Create Profile


Give it a name
Write "MDM Wins" and select "MDM Wins Over GP"

Select "The MDM policy is used and the GP policy is blocked"


Assign it to all devices


Finalize the profile creation default values.



Using this tool will make your debugging options even more visual.

Could I have used the build-in diagnostic report?



Sure, you could, but does it provide the same amount of visibility?




You be the judge of that.

Happy debugging!


See more information on the topic from Andrew

Convert Intune MDMDiagReport.html to PowerShell object (

Get a better Intune policy report part 2. (

Get a better Intune policy report part 3. (

Sunday, November 21, 2021

Manage local administrator rights on Windows 365 Cloud PCs.

Managing local administrator rights on Windows 365 Cloud PCs.


I’ve been writing about Windows 365 over the past few months, and in the original Windows 365 blog post I quickly mentioned that users by default doesn't have local admin rights on their Cloud PC(s), and how to grant users local administrator privileges. The weather is cold and it’s raining today, and now that I'm just sitting here in my home office with a freshly brewed cup of coffee, why not write a post about how to manage local administrator rights on Windows 365 Cloud PCs.

I know that it can be done with a Group Policy Object (GPO) and via PowerShell, but in this blog post, I will be focusing on a custom configuration profile and the Windows 365 user settings.


The original blog post about - How to configure Windows 365 Enterprise in Microsoft Endpoint Manager

Managing local admin rights on Windows 365 Cloud PCs

Like in every great cooking show on television I’ve cheated a bit, and already prepared a security group within my on-prem Active Directory and it has been synced with AD Connect to Azure AD.

This security group is named “W365_Enterprise_Local_Admin” and will only contain users that I will grant local admin rights.



Manage local admin rights with a configuration profile

Let’s get started by visiting the Microsoft Endpoint Manager admin center.
Go to

First, we will create a filter for Cloud PCs.
Click on Devices | Filters (preview) | Create

I already created a filter for Windows 365 Cloud PCs, but you can copy the rule syntax used in my filter.
(device.model -contains "Cloud PC")

Once you have created the Windows 365 Cloud PC filter, you can go ahead and create the custom configuration profile.
Click on Devices | Configuration profiles | Create profile
Select Windows 10 and later in the drop-down menu.
Select Templates in the drop-down menu.
Select Custom on the list and click Create.

Fill in the required field and click Next.

Click Add.

Source: Microsoft   

Name Add Domain Group to Local Administrator Group
Description This is optional.
OMA-URI ./Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure
Data type String

    < accessgroup desc = "S-1-5-32-544">
        <group action = "U"/>
            <add member = "MINDCORELAB\W365_Enterprise_Local_Admin"/>

Note. For adding Azure AD users and/or groups please read more about that in the LocalUsersAndGroups CSP policy.  
Tip. You can use SID S-1-5-32-544 instead of the group name (Administrators). - I would especially recommend it if you are managing a multi-language environment since the SID is not language dependent.  
Fill in all the required fields and click Save.

Click Next.
Set scope tags if needed and click Next.

Add the security group and filter as Include in filter mode.
Click Next.
Set applicability rules if needed and click Next.

Review your configuration and click Create.

To monitor the status of the configuration profile, click on Devices | Configuration profiles and select the profile.


To check the filter evaluation on a Windows 365 Cloud PC, click on Devices | Windows and choose the Cloud PC.
Click on Filter evaluation (preview) and select the configuration profile from the list.

If I connect to my Cloud PC, I can confirm that the security group has been added to the local administrator group. Awesome!

Manage local admin rights with Windows 365 user settings


Another way to grant a user local administrator privileges, is to create a Windows 365 user setting.

The main difference between the two approaches is that the custom configuration profile adds a domain security group (which probably contains several users) to the local administrator group, and the Windows 365 user setting adds the logged-on user directly to the local administrator group (if that user is a member of the domain security group used in the user setting).

Both scenarios are quite dynamic as you only need to remove the user from the domain security group to take away the local administrator privileges from the end-user.

Click on Devices | Windows 365 | User settings
Click on Add.

Fill in the required field, tick the Enable Local admin check box, and click Next.

Add the security group and click Next.

Review your configuration and click Create.

The Windows 365 user setting didn't add the logged-on user to the local administrator group, on my current Windows 365 Cloud PC, probably because it was provisioned with a custom Windows 11 image where I changed the system local language to Danish before sysprep (which also translates the local group names to Danish during provisioning of new Cloud PCs).

If I reprovision my Windows 365 Cloud PC with a standard gallery Windows 11 image (which is in English), I can confirm that my user account has been added to the local administrator group, which kind of strengthens my suspicion that Windows 365 user settings are currently not working on custom images where you have changed the system local language.

After a while, the custom configuration profile will also be applied to my Cloud PC if the profile still has an assignment.


In this blog post you have learned how to grant a user local administrator privileges on their Windows 365 Cloud PC. If you are using a custom image and you have changed the system local language, the Windows 365 user settings will probably not work, but by the time of reading this blog post, it may have been fixed by Microsoft. Happy testing!

As always, if you have any questions regarding this topic, feel free to reach out to us.