Intune

Apple tokens for Mobile Device Management like APNS certificates, DEP and VPP tokens need a renewal every 365 days. When an APNS certificate has expired you are forced to re-enroll all of your MDM managed apple devices. To avoid any headaches I put together a few lines of PowerShell which monitor the expiration with Azure automation and send a notification to Microsoft teams or email. Script # The script is intended to run recurring on Azure automation. And I recommend to setup a schedule which runs the script once a week. The script checks the following apple tokens and triggers the teams notification if it expires in less than the configured number of days: Push Notification certificate DEP (Device Enrollment Program) tokens VPP (Volume Purchase Program) tokens Hint : You can setup multiple DEP and VPP tokens in your Intune tenant. The triggered notification is delivered to Microsoft Teams as message card with some details about the token Prerequisites # In order to get the monitoring up and running you need at least: Azure automation account (ideally with a service principal), if you need a guide to set up an automation account read follow this article An incoming webhook for your Microsoft Teams team which will receive the notifications OR an email account to send mails The script from my Github techblog repository Create a Microsoft Teams Webhook # Navigate to your desired teams channel which should receive the notifications and add a new incoming webhook:

This post has the intention to give you an overview and starting point to automate things with the Microsoft Graph API and PowerShell. While having the focus on Intune and EM+S but the basics are also valid for other Microsoft services. The world is changing and so are you? # When talking about automation most people only think about some PowerShell code and scheduled tasks running on whatever box in an environment. But technology regarding Microsoft services and it’s automation possibilities have definitely evolved quickly. Automation can now be done with basically any scripting or programming language because Microsoft offers us the Microsoft Graph API. Although API (application program interface) sounds more like a developer term engineers should better get used to consuming API’s. As more and more services can be consumed as SaaS API’s are mostly offered for further data processing and automation. Microsoft Graph API # Microsoft describes it’s own Graph API as “Microsoft Graph is the gateway to data and intelligence in Microsoft 365”. Most of the API’s out there are built according the RESTful definition. A RESTful, also called REST API should implement the following operations (HTTP methods) to work with data:

As you might have noticed I have been doing quite a lot of automation stuff with Microsoft Graph for Intune and Azure AD. My preferred way to run PowerShell scripts which need to run on a regular basis is to use Azure automation. Unfortunately the official “Intune-PowerShell-SDK” does not support authentication with a client certificate. Therefore I updated the module and will show you how to use it with Azure automation. Why I don’t like client secrets # Azure automation brings us service principals (run as accounts) which simplify the access to Azure resources by providing an Azure AD app registration and certificates to authenticate against Azure AD. This provides more security and prevents the risk from having client secrets stored as plain text in scripts. Going with a client secret when having a nice certificate based authentication solution in place feels like making a step-backwards for me. This was the main reason why I decided to “upgrade” the Intune-PowerShell-SDK to support certificate based authentication. Why I love the Intune-PowerShell-SDK # This PowerShell SDK provides nice Cmdlets to do any kind of automation with Microsoft Graph, not only limited to Intune because it offers a helper cmdlets like:

Recently I needed to change a couple of groupTags on existing Windows Autopilot devices. Because Windows Autopilot profiles have been assigned based on the groupTag. Of course I could have done this with the portal (check out the devicemanagement.microsoft.com portal if not done yet!) but I am definitely an automation fan when I need to do repetitive work. Portal view and property mapping # In the Intune portal the Group Tag field on an Autopilot device maps to the Azure AD device property “OrderID”. Dynamic Azure AD Groups to assign Autopilot profiles to devices can be built with the following membership rule: (device.devicePhysicalIds -any _ -eq "[OrderID]:mOSD") The “Order Identifier” field on an Autopilot device maps to the Azure AD device property “PurchaseOrderId”. Dynamic Azure AD Groups to assign Autopilot profiles to devices can be built with the following membership rule: (device.devicePhysicalIds -any _ -eq "[PurchaseOrderId]:1234") PowerShell script to update groupTags # The following script updates the groupTag of one or multiple selected Autopilot devices. Selection is done with a PowerShell GridView. Please note:

After you have uploaded a PowerShell script to the Intune portal you won’t be able to view the script or its content. Therefore things become complicated when an Intune tenant is managed by multiple admins and someone wants to update or review a script. In addition to the unknown script content things can go from bad to worse if you can’t find the script anymore. Fortunately we can recollect our PowerShell scripts directly from the Microsoft Graph API. Taking advantage of the Intune-PowerShell-SDK # Install the Intune-PowerShell-SDK Consent MS Graph App registration if not done yet (uses default Microsoft Intune PowerShell App with ID: d1ddf0e4-d672-4dae-b554-9d5bdfd93547 ) Execute the snippet below Retrieve device configuration - PowerShell scripts # Final words # This was more a minimalistic self-serving post instead of a good explained one but it hopefully helps you if in need to export your PowerShell scripts in Intune without reinventing the wheel.

Recently I needed to delete a desktop machine from the Windows Autopilot service in order to use the machine in another tenant. But the problem was that the Intune and Azure AD device objects were already deleted. All attempts taken within the Microsoft 365 Device Management and Intune Portal were unsuccessful. Issue # Usually the autopilot device shows the associated Azure AD and Intune objects but here they were shown as N/A (not available) because they were already deleted. Every attempt to delete the device produced the following error: Device 8CC9082ZVE deletion failed. Please delete the associated Intune device before deleting this Autopilot device record. Solution # A quick visit to the Microsoft Store for Business resolved things because there I could delete the device without any issue. Direct URL to the Microsoft Store for Business. After a sync in the Intune Autopilot Devices pane the device had also gone from the Intune portal. Final words # This was a rather short post but I hope it prevents headache if you want to delete an Autopilot device with stale Azure AD / Intune records.

I’m happy to share some field notes and experiences with the Windows Autopilot White Glove feature which is available with the Windows 10 1903 release. I’ve done a lot of testing and engineering for a recent project which also included this brand new feature. First things first (requirements) # This is probably the most important information of this post. Really make sure to verify the following prerequisites for Autopilot White Glove. Because there are additional requirements compared to Autopilot enrollments. Basic Autopilot # Make sure that a “classical” Autopilot Deployment is working properly without any issues. Hardware and OS # Hardware with support for device Attestation (“Physical devices that support TPM 2.0 and device attestation; virtual machines are not supported.”) Physical devices with Ethernet connectivity (WiFi connectivity is not supported!) Windows 10, version 1903 with KB4505903 injected (equals OS Build 18362.267) Starting the white glove adventure # Preparing Windows 10 1903 # As mentioned by Michael Niehaus Windows multiple Autopilot issues were fixed by KB4505903. So we need to inject this cumulative update to the downloaded source. This was already the first hurdle to overcome because I’ve missed the fact that the Windows Setup (install.wim) actually contained multiple image indexes (yeah it’s kinda embarrassing). We achieve this by using dism offline servicing with PowerShell cmdlets.

While testing Autopilot White glove for a customer project my test machines always got stuck within the “Registering your device for mobile management” step and timed out after 12 minutes and returned the error “0x81036501” just before showing the White Glove Failed screen. I was doing my tests with Windows 10 1903 DE (German) with the most recent cumulative update installed, meaning OS build: 18362.267. The Issue # As normal Autopilot enrollments were working like a charm this one had to be related to the White Glove scenario. Here’s a screen capture showing the actual behavior (unfortunately with German display language): By pressing [shift] + [F10] i opened a command prompt and launched the event viewer (eventvwr.msc). In the “Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot” event log I found the following error popping up multiple times, including a retry attempt and limit: Autopilot discovery failed to find a valid MDM. Confirm that the AAD tenant is properly provisioned and licensed for exactly one MDM. HRESULT = 0x81036501 AutopilotManager failed during device enrollment phase DeviceDiscovery. HRESULT = 0x81036501 On the enrollment status page the error “0x81036501” got displayed for like one second before showing the red generic Autopilot White glove error screen.

The Intune Win32 app requirements feature is quite underrated and often overseen in my experience. The ability to specify a custom PowerShell scripts allow us to check for specific hardware or device properties in order to determine if an app or firmware update should be installed or not. So there’s no need to build multiple and complex dynamic Azure AD groups for the assignment of your apps. Use cases from the field # From recent projects I’ve discovered the following use cases to deploy Win32 apps only to specific hardware types: Install specific device drivers or hardware vendor’s software which is not available within the Windows update catalog (e.g. hotkey features, firmware updates) Install a VPN client only on notebooks and tablets (e.g. Palo Alto GlobalProtect Client) Win32 app requirements # Intune Win32 app requirements are evaluated by the Intune Management Extension to check if a device fulfills defined requirements for an application installation. Requirements support both built-in and custom rules. Built-in rules # Wit the built-in capabilities we can check for:

Here are 5 common recommendations based on misconfigurations I’ve came across in the field which will give your Intune tenant and devices a hard time to work smoothly. So better read this post that you not screw up your Intune tenant and maybe take advantage of the experiences others already gained. Housekeeping # It’s important to know which devices are actually being used and usually a nice addition to understand compliance data. Stale device entries in may give you a wrong impression of your Intune tenant and it’s health. So enable the automatic device cleanup rule to remove the enrolled device from Intune. Additionally you may also remove the device entries stored in Azure Active Directory (I created a little on-demand script for this which can also run in azure automation). Same applies to registered Autopilot devices. E.g. if you allow your employees to buy their old devices from the company if they get a new one make sure to remove the device from the Autopilot service. Otherwise you’ll see it again popping up in your tenant very soon. Thus it also prevents the device from being registered in another tenant as autopilot device.