Intune -Troubleshooting and Learnings

We are rolling out Intune Compliance and Configuration Policies. MDM (Enrolled) for corporate devices and MAM (unenrolled) for Personal devices. We are using MDM and MAM to rollout (Windows Information Protection) WIP. We are not using Config Manager, and all devices are Azure AD Hybrid Joined.

This blog focusses on Windows 10 devices and does not cover MacOS, iOS or Androids.

First off, let me tell you, you’re probably going to have to raise a ticket with Microsoft so if you haven’t done that yet, you might as well go and do it now. Two of my tickets ran for 4 months, in fact the second one for WIP is still running… I have spoken to around 12-15 different Intune support staff. Be prepared to run dsregcmd – a lot.

Remote Access: If you are troubleshooting your own device great! The support engineer at some point will ask to see the problem and direct you here https://support.microsoft.com/help  pop in a code and you can share the issue. However, if you are trying to resolve an end user device that is going to be pretty unlikely and very few support engineers are willing to come on to a Teams meeting and share screen that way. So now you have to act as the middleman and go back and forth with the end-user asking them to get screenshots, logs. Asking users to access the registry and event logs is really not something you want to do. They may be required to run certain tasks from an elevated prompt – which they might not be able to do.

For my first ticket it took a lot of escalation and ticket transfers only to learn that this “error”

State Details -2016345708 (Syncml(404):  The requested target was not found.) Error Code 0x87d10194

Simply means that Windows itself can’t report back to the Intune agent for Code integrity, BitLocker or Secure Boot. This is because the device does not support it and therefore the device does not in fact pass the test and is essentially simply NOT COMPLIANT. For us, this was because the workstations had older TPMs or no TPM.  For checking for BitLocker we had to go away from Windows Health Attestation Service evaluation rules “require BitLocker” and only use System Security and set Require Encryption of data storage on device

Minimum Requirements

The second thing I’ll tell you is that unless you are Using Windows 10 Enterprise with modern hardware, you’re probably not having much joy. If you are still using Windows 7 – Intune isn’t for you.

A few nuggets early on:

• Devices\All devices is where you see Intune enrolled devices
  • A device could be in Azure AD devices but not yet be enrolled into Intune
• Users need to be licensed for EMS
• Users need to be in the MDM user scope
  • Azure Active Directory > Mobility (MDM and MAM) > Microsoft Intune
• Users have to log on with a UPN that has a routable domain. e.g. john@contoso.local won’t work. I have also been advised that users should log in with their full Office 365 UPN, not the old way of DOMAIN\samaccountname
• MDM auto-enrolled via GPO will register the workstation as a Corporate Device
  • Thus check Computer account is syncing via AADC and appearing in Azure AD Devices
• MDM manually enrolled by any user will result in the workstation appearing in Intune as a Personal Device
• Manual enrollment requires Local Administration rights for the user doing the enrolment
• For manual enrollment do this at the “Access work or school”, top right hand side 4th one down – “Enrol only in device management” (Good Shortcut: ms-settings:workplace)
  • Don’t assume that opening Outlook, Word, Teams, OneDrive, Company Portal will MDM enrol it
• One device, one user. While Microsoft have addressed this is later versions of Intune and Windows 10, the expectation is a one to one mapping. So, if you are experiencing issues, try to arrange to have the user themselves complete the enrolment process
• If you don’t see: Connected to [organization name] MDM under “Access work or school” with the monochrome briefcase icon and the Info button available, then it is not MDM enrolled – use dsregcmd /status to confirm
• Compliance Policies and App Protection Policies are applied to the Device. So even though you will use Groups that contains users to assign policies, the users’ device is what actually gets the policy – BUT the user that enrolls the device has to be licensed for EMS
• Due to a lack of decent reporting, we ended up having to split Compliance Policies by setting so that we could see the woods for the trees
• Changing a Compliance Setting forces all devices to go to “Not Evaluated” until they next report in. So, once you have your optimal policy, you will need to try and leave it untouched, which is impossible if you are using minimum and maximum versions for Windows OS or Defender
• A device that is reporting an Error and Not Compliant for a setting within a Compliance Policy will show in Intune as Not compliant. You can’t just filter on Error devices
• We didn’t strike this ourselves, but I have read other people issues were resolved by removing older version of the Intune agent but they also had to do registry clean-up and other stuff. This seems to be mainly for older versions

Enrollment

Workstation accounts are synchronized to Azure AD via AAD Connect.  You may see the devices you want to work with in “Azure AD Devices” but not yet under “All Devices” All Devices is where you see Intune managed devices after they have been enrolled.  This is relevant when you are trouble shooting because you will find yourself at some point unenrolling devices at the workstation and deleting devices from Azure AD Devices and All Devices. At that point you need to then initiate an AAD Connect sync to get the device back.

NOTE: Only auto-enrolled devices via GPO will show up as Corporate. If a user or administrator undertakes any of the enrolment task manually at the device, then it will be recorded as a Personal Device

For Windows 10 we use a GPO to enrol Windows 10 machines into Intune: https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy

When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. Those computer accounts also obviously need to be in the OU where you are applying the GPO!

The task is called “Schedule created by enrollment client for automatically enrolling in MDM from AAD.” (Look for it in Task Scheduler Library\Microsoft\Windows\EnterpriseMgmt)

Places to look, tools to use

When (not if) you raise a Microsoft ticket they will want to know the version of Windows you are running, and then tell you to update it.

WinVer at start run, (or just run “ver” from a command prompt) e.g. Microsoft Windows [Version 10.0.18363.836]

Group Policy Objects

• Check the GPO was applied by running RSOP.  If you can run this with elevated privileges you can also see the Computer policies.
• GPResult /R will let you see the policies without all the actual settings and the OU the User and Compuer are in
  • GPUpdate /force will kick off the process of refreshing the GPOs for user and machine  (generally without having to log off and on) if you don’t see them from above output, but you do see the user and computer are in the correct OU

Task Scheduler

• Check the Task scheduler to see the task has been created from the GPO and has run or attempted to run

Access work or school and Advanced Diagnostic Report

Go to Windows Settings (Windows Key + I) \ Accounts\Access work or school. If you don’t see the monochrome briefcase icon, then your machine is not enrolled. Check at dsregcmd /status

Click on Info. Here you should see a useful section called: Areas managed by [organization name]

Policies e.g.

• DataProtection
• DeliveryOptimization

Further down  you also will see Device sync status. It is here where a user can manually initiate a device sync back to Intune

Advanced Diagnostic Report:

Scroll to Bottom “Create Report”

The report is created here: C:\Users\Public\Documents\MDMDiagnostics\MDMDiagReport.html There is useful extended information here.

• Device Info
• Connection Info
• Device Management Account
• Certificates
• Enrolled configuration sources and target resources
• Managed policies
• Blocked Group Policies
• Unmanaged policies

Device State – dsregcmd

From an elevated command prompt: dsregcmd /status

• Per this link below, the SSO status needs to run from the User context i.e. not the elevated prompt
• Troubleshooting devices using the dsregcmd command: https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd

Windows Event Logs:

• Applications and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider

Look at both Admin & Operations

Admin is where you will be mainly looking. You can also enable Debug by going to View on the Menu bar and choosing “Show Analytics and Debug Logs” Filter by Critical, Warning and Error

Windows Information Protection (WIP) is here:

• Applications and Service Logs\Microsoft\Windows\EDP-AppLearning\Microsoft Windows Information Protection Application Learning Log Channel

The registry:

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device
• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments

Reports

The Intune portal would lead you to believe it has good reporting capabilities. It doesn’t.

Sure, if you want some high-level overall stats then maybe, but if you want to do filtering down to certain types of issues it’s pretty much hopeless. There is no ‘one place’ that you can do reports from. It jumps all over the place. Sometimes you can filter and choose columns, other places you can’t. Some columns are sortable, some are not. Some views have the column for Error state, some do not. Policy compliance does, Settings compliance does not.

Now, you would think with Microsoft touting all its Machine Learning, AI, Big Data Analytics, Power BI it would be there. It isn’t. There is a Power BI module but there isn’t really any documentation how to make that work for your specific needs. It’s “pretty” of course.

I’ve heard people say “use the Graph API”. Well, that has limitations and it’s complicated to use when really you should just be able to drill down and down to what you need from the UI. Plus, the Graph has limitations due to throttling and often you will have to loop in batches of 100.

Report Request

What I wanted a report of was:

A list of only the Windows 10 Devices failing any one specific setting e.g. Require secure boot.

If I go to Microsoft Intune\Device compliance\Settings compliance I can see that I have:

• 1,344 not evaluated devices
• 62 noncompliant devices and
• 4 compliant devices

(Total 1,410)

Where is the Error devices column when you need it?! I know for a fact some are in an error state.

So I click on the row for my Compliance setting (Require secure boot) that I want to check. I can now see a list of devices with headings for: Device, UPN, Compliance Status, Device Model. I can’t filter here and I can’t sort on Compliance Status.

OK, no worries I’ll export the CSV and work with that. So I export the CSV and I have 3,526 rows returned?! What happened to the 1,410.

18 are listed as Compliance Status as Error.  Un, so is that error for the one setting I am wanting to work with, or a general error status for the whole device across all policies? Useless.

If I run de-dupe on the Device column, turns out I have 2,122 duplicate values.  Not sure I can use that data.  Even a full export from Devices returns me 1,421 Windows Devices (with 12 duplicates)

Every time I get on a call with Microsoft I ask them how I can do this.  I get a variation of responses from “I see your point, that would be a good feature”, to, “I’ll take that away and see what we can do” – so far I have not yet been able to get this report.

How did we get around this?

I ended up creating a single compliance policy per setting that I want to isolate then go to the Microsoft Intune\Device compliance\Policy Compliance (under Monitor). 

That shows me completely different numbers:

• 512 Compliant
• 226 noncompliant
• 15 error devices

When I click on my Policy row my headings are Device, UPN, Compliance Status, last update status. In here I also see a whole ton of not evaluated devices, so I export this to CSV.

I have 1,368 rows in the CSV – but at least I now have the 15 Error devices. (Three of which start with a devices name that should be excluded from this policy. Sigh).

The CSV export tells me I have 299 Compliant devices. Um…. what happened to the 512 number? 238 not compliant (so what was the 226?) 611 Not evaluated. I also have 5 Not applicable. That’s helpful.

If I pick one device name at random and go look in All devices it tells me it is Compliant – until I click on it and then I see it is only Compliant for the Built-in Device Compliance Policy but the other 7 are still not evaluated.

Did I already say that Intune Reporting is, shall we say, not where it needs to be?

Do’s and Don’ts

• Do click the sync button from the Device and from Intune
• Do delete from “All Devices” when troubleshooting. If it isn’t working, you’ll need to try again anyway
• Don’t ever use the option to rename a Workstation directly from Intune for Azure AD Hybrid joined. That does not go well… That does indeed rename the computer, and prompts for a reboot, but that computer account is now out of sync with On-Premises Active Directory and cannot log in. If there is no working local Admin account on that machine then you just bricked it
• Don’t Edit your Compliance Policies if you can help it. This toggles all devices affected by this policy to Not Evaluated. I have seen devices that have checked in and sync’d, but still not get evaluated for a week. You lose all meaningful visibility of your estate
• Do create multiple Compliance Policies to give you a more granular picture of the estate
• Do set Device cleanup rules. Stale devices clutter up your reporting and skew your figures. Interestingly the default is off
• Do learn about App protection policies – think carefully about deploying them and the impact they will have
• Do have a WIP excluded Group
• Don’t deploy Windows Information Protection (WIP) policies for Windows en-masse without THOROUGHLY testing and piloting for a good length of time. Your users will not thank you for getting this wrong
  • Get to know how to use Get-AppLockerFileInformation. You will need this to whitelist any and every app on a Workstation. Some apps spawn others exes when they run. Some VPNs and “run on demand” applications take a while to figure out
• Do raise a Microsoft ticket as soon as you hit a brick wall

Troubleshoot Windows device enrollment problems in Microsoft Intune https://docs.microsoft.com/en-us/mem/intune/enrollment/troubleshoot-windows-enrollment-errors

Notes on: SecureBoot, Code Integrity, BitLocker

For us, this is a baseline requirement along with Windows Defender and Firewall. If you want to do anything like Security checking of workstations including checking for BitLocker, SecureBoot and Code Integrity the golden rule will be:

• UEFI enabled BIOS
• PCR7 Configuration Bound
• TPM Version 2.x
  • In some instances will work with 1.2/1.3 but definitely don’t rely on that

Taken from here: https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/954cf796-a640-4134-b742-eaf0ed2663ff

• If PCR validation profile shows PCR 7, 11 (Uses Secure Boot for integrity validation), the system is configured correctly.
  • If the PCR validation profile says PCR 0, 2, 4, 11), this indicates that BitLocker cannot use PCR [7]

How to check.

From an elevated PowerShell prompt run:

• Confirm-SecureBootUEFI
• manage-bde -protectors -get $env:systemdrive
• msinfo32.exe

A Windows 10 device with secure boot enabled shows as Not Compliant in Intune https://support.microsoft.com/en-us/help/4456680/windows-10-device-with-secure-boot-enabled-shows-as-not-compliant-intu