Intune -Troubleshooting and Learnings

Image 13

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

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

Conrad Murray

Conrad Murray is a Microsoft Certified IT consultant working in IT for over 20 years specialising in the Messaging arena and in particular Office 365 and previously Microsoft Exchange On-Premises and IBM Domino. Working with like minded colleagues now delivering very large scale complex migrations from Office 365 to Office 365 (tenant to tenant), Lotus Notes and On-Premises Microsoft Exchange to Office 365.

This Post Has 6 Comments

  1. Hi Conrad,

    Thanks for sharing your not only your pains but also your tips and tricks.
    We had the same issue with the rolling out of our new Surface Pro 7 estate.
    For first devices all went fine.

    All of a sudden we had the 2 errors:

    Require BitLocker
    Error
    -2016345708 (Syncml(404): The requested target was not found.)
    Require Secure Boot to be enabled on the device
    Error
    -2016345708 (Syncml(404): The requested target was not found.)

    We have followed your suggestion, but still devices were reported in error (and not “not compliant”).

    We tried to to force “update Windows Defender Security intelligence” from Device Overview, in device management portal, and shortly after the error was resolved.
    Devices are now compliant.

    Hope our feedback can save some time and mental health to other users.

    Thanks a lot,

    Regards,

    Nicola

    1. Hi Nicola, this issue was my first run in with Microsoft Support for Intune and the ticket was passed from pillar to post for months until I chucked my toys out the pram and it got escalated. When I got to the right person I was told that the “error” simply means that the Intune Agent can’t talk with the Windows 10 OS and the Machine is just “Not compliant”

      For this to work, (as I wrote in my blog) three things need to be true:
      • 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)

      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
      Mine returns True

      manage-bde -protectors -get $env:systemdrive
      Mine returns:

      Volume C: [Windows]
      All Key Protectors

      TPM:
      ID: {0929817B-5FBA-40EE-98BB-87F07A7DF130}
      PCR Validation Profile:
      7, 11
      (Uses Secure Boot for integrity validation)

      Numerical Password:
      ID: {***************}
      Password:
      ******************************************

      Run this elevated: msinfo32.exe (System Info)
      Mine returns
      • BIOS Mode UEFI
      • Secure Boot State On
      • PCR7 Configuration Bound

      If your says something different, you HAVE to fix it in the BIOS. Your OS may be reporting something like:
      TPM – Version 2.0
      BIOS Mode – UEFI
      PCR7 Configuration – Binding not possible
      Confirm-SecureBootUEFI – False
      PCR Validation Profile 0,2, 4, 11
      BitLocker shows it is enabled

      In your BIOS you might then have:
      UEFI Secure Boot Off, but Secure Boot Enabled and Security Chip Enabled

      In that case you need to do this:
      • F1 – Enter BIOS
      • Security Tab
      • Secure Boot Menu
      • Restore Factory Keys
      • F10 to save and exit.

      Hope that helps.

  2. Conrad, great post and thank you for sharing. I share your sympathy in working with Microsoft support. First-line support is bang head on wall irritating and everything is slow moving. Do you re-call having an issue where Compliance policy state on a device is “Not evaluated” and the User Principal Name is “None”? We have a simple compliance policy that is checking if Bitlocker is enabled and is assigned to “All users and devices”. However, have a handful of systems actively checking into Intune, with correct Primary (and EMS licensed) user assigned, with this issue. Did find the below info on this Microsoft page, but none of the reasons listed seem to apply. The “Built-in Device Compliance Policy” is in compliant state with correct UPN listed.

    https://docs.microsoft.com/en-us/troubleshoot/mem/intune/secure-boot-enabled-device-shows-not-compliant
    Not evaluated: An initial state for newly enrolled devices. Other possible reasons for this state include:
    -Devices that aren’t assigned a compliance policy and don’t have a trigger to check for compliance
    -Devices that haven’t checked in since the compliance policy was last updated
    -Devices not associated to a specific user, such as:
    -iOS/iPadOS devices purchased through Apple’s Device Enrollment Program (DEP) that don’t have user affinity
    -Android kiosk or Android Enterprise dedicated devices
    -Devices enrolled with a device enrollment manager (DEM) account

    1. i have definitely seen this. And annoyingly it happens when you edit a compliance policy, and any device that was getting that policy automatically switches to not Evaluated until the next sync. However, I could see the last contact times were recent. I waited and waited, up to two weeks. In the and, i simply deleted the device from Intune and Azure AAD. Once AAD Connect ran and brought the device back, the auto-enroll on the device ran again and it appeared evaluated. I have also just deleted from Intune without deleting from AAD and that worked too.

Leave a Reply

Your email address will not be published. Required fields are marked *

Search