Intune

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. ...

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. ...

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: ...

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. ...

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. ...

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. ...

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): ...

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: ...

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). ...

I’m thrilled to introduce the intune-drive-mapping-generator which creates PowerShell scripts to map network drives with Intune. The tool is open source and built on ASP.NET Core MVC. The intune-drive-mapping-generator is your tool of choice to: Generate an Intune PowerShell script to map network drives on Azure AD joined devices Seamlessly migrate existing network drive mapping group policies Generate a network drive mapping configuration from scratch Use an existing Active Directory group as a filter to deploy all your drive mapping configurations within one script This all happens without scripting effort. You receive a fully functional PowerShell script for the deployment with Intune. ...