Posts

Most of the people out there blogging have recently published numbers and figures about 2019. Starting the new decade I also want to publish some figures about 2019 and wish you a happy and successful start into 2020. Blog # On my blog I tried to focus mainly on Enterprise Mobility + Security topics and shared some experiences and how-to’s about the modern workplace. 28 blog posts published 101'074 page visits 04:08 (mm:ss) is the average time users spent on my site Tools # I published two open source tools in 2019, both are available on GitHub and both of them support your Microsoft 365 based workplace: The Modern Workplace Concierge is a helper tool to simplify Microsoft 365 configuration allowing bulk import and export operations. Project URL The Intune Drive Mapping Generator creates PowerShell scripts to map your on premises file shares to Intune MDM managed devices. Project URL More numbers # 2 sessions on community events 254 new followers on twitter 423 commits on GitHub 802 generated network drive mapping configurations (Intune Drive Mapping Generator) Final words # I really appreciate all the feedback and support I received from you and fellow readers. Also in 2020 I will try to blog as much as possible and giving the community something back while representing the message that even at a young age you can contribute to the community, share your knowledge end especially learn a lot because this is a lifelong and ongoing process.

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 assign a lot of Microsoft licenses to different Azure AD groups. Unfortunately Microsoft does currently not offer a solution to do this (yet). Instead of giving up on this I decided to analyze what actually happens when you assign a license to a group in the Azure portal and found some actions going on within the hidden portal API. As an outcome I built a PowerShell module to manage Azure AD group based licensing assignments. Full functionality for group-based licensing is available through the Azure portal, and currently PowerShell and Microsoft Graph support is limited to read-only operations. PowerShell and Graph examples for group-based licensing in Azure AD The PowerShell module # The PowerShell module uses the “main.iam.ad.ext.azure” API for the license operations and the AzureRM module to get an access token for the API. Please note that the mentioned API is not officially supported or documented. Although the API is being used by the Azure Portal for settings you configure via the portal. Kudos to Jos Lieben for his “pioneer work” documenting on how to get an access token for the API.

With Microsoft Graph we have powerful automation and configuration management capabilities. To further simplify this process I built the “Modern Workplace Concierge”. It is an ASP.NET application which uses an Azure AD multi tenant app to access the Microsoft Graph API on behalf to perform export and import tasks. The project uses the Microsoft Graph Beta API to access your tenant’s data. Modern Workplace Concierge # The Modern Workplace Concierge allows you to: Import and export Intune configuration and settings Import and export Conditional Access policies Download OSD ready offline Autopilot profiles Download stored PowerShell scripts in Intune (as PowerShell) This allows you to import your existing Intune and Conditional Access configuration in new tenants or demo tenants. The files in JSON format can be used for further processing or documentation. And this all via web browser no client side prerequisites or PowerShell code is required! The Modern Workplace Concierge The project and more information is available on GitHub feel free to provide feedback there. That's how I backup my Intune configuration with the #ModernWorkplaceConcierge. Curious? Give it a try. Of course also supporting imports .https://t.co/30H8b0olLn pic.twitter.com/g5X58l1e1i — Nicola Suter (@nicolonsky) December 3, 2019 More Information:

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:

Auditing Conditional Access events and changes is crucial regarding your hygiene in Azure AD for your modern workplace. With the goal that we receive appropriate notifications and alerts if special events occur. Thanks to Azure Log Analytics (also referred to as Azure Monitor) we can easily filter and create alerts based on events. This post starts where most of the others end - giving you practical examples of KUSTO queries to search your Azure AD Audit logs with Log Analytics. Default log retention in AAD # A point which get’s raised often is the default log retention in Azure Active Directory (AAD). Azure Active Directory stores all activity reports depending on your license for 7 or 30 days: Azure AD Free and Basic: 7 days Azure AD Premium P1 and P2: 30 days Source, more Information. To retain and further process Azure Active Directory Audit Logs for a longer time period (because a 30 day audit trail is likely too short for most organizations) we can: Stream to an Azure Event Hub Archive to Blob Storage Forward them to Azure Log Analytics With Log Analytics the KUSTO query language can be used to query the forwarded log entries and we can create alert rules based on custom queries.

Recently I have been troubleshooting a nasty Windows Hello for Business problem which prevented all users in a tenant from resetting their Windows Hello for Business PIN’s on Azure AD joined devices while getting the error CAA20004. Issue # When clicking on “I forgot my PIN”: After completing the account sign-in and MFA challenge the Error CAA20004 came up: Troubleshooting # The Azure AD Portal shows us “Failure reason: other”. While recording all the https traffic to Microsofts oauth2 endpoint with Fiddler this finally unveils usable information: AADSTS65001: The user or administrator has not consented to use the application with ID ’ 9115dd05-fad5-4f9c-acc7-305d08b1b04e’ named ’ Microsoft Pin Reset Client Production’. Send an interactive authorization request for this user and resource. The error indicates that an application registration is missing in the tenant for the application “Microsoft Pin Reset Client Production” Solution # After a short search I found a matching Microsoft docs article. Instead of reading through the whole article the only thing I needed to do was consenthing to the: Microsoft PIN Reset Service production application and also for the Microsoft PIN Reset Client production

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.

If you use the Enrollment Status Page (ESP) on your (Autopilot) devices in blocking mode (Block device use until all apps and profiles are installed) things can get ugly and complicated if you sign-in with another user account on that machine. So it might be better to disable the Enrollment Status Page for all users who sign-in after the initial device enrollment. ESP behaviour # I was not aware of the fact that only one ESP gets applied to a device and the first one applied will also remain on that device nevertheless if you configure additional ESP settings for different groups of users. In addition the ESP gets displayed for every account even if the account has no Intune license assigned and causing the ESP therefore to fail. The Enrollment Status Page can only be targeted to a user who belongs to an assigned group and the policy is set on the device at the time of enrollment for all users that use the device. https://docs.microsoft.com/en-us/intune/windows-enrollment-status Use cases from the field # I have came past the following use cases where you would want to disable the ESP after the initial enrollment: