You always wanted to automate a specific action within Intune / the Microsoft Endpoint Manager Portal (MEM) but were afraid of the complexity? The Microsoft Graph API docs deliver you more questions instead of answers? Automating tasks within the MEM portal could be very easy, couldn’t it? I promise it will be much simpler with this magician trick.
Microsoft Endpoint Manager Portal # The MEM Portal UI relies on the Microsoft Graph API. This means that the UI where you create new settings and policies and the Intune backend are encapsulated with different layers. Communication between the UI and the backend happens with the Microsoft Graph API. With the developer tools we can trace network traffic and discover the request URLs and request body payload which are required to interact with the API.
{: .align-center}
Example about how to capture URLs and build a PowerShell script # Original request body:
When using device code authentication for PowerShell modules with conditional access you might receive prompts like: “Access has been blocked by Conditional Access policies. The access policy does not allow token issuance” or “AADSTS50097: Device authentication is required”. But what’s the reason for this error and is there a solution available?
Examples from the field # Device code flow is quite a convenient way to sign-in for an app within the web browser - at least if it works. If not you have to consider other options and that’s probably the reason why you’re reading this blog article.
Az PowerShell
Running the Az PowerShell module on PowerShell 7 uses device code flow to authenticate against your Azure tenant and might fail:
Connect-AzAccount: AADSTS50097: Device authentication is required. Timestamp: 2020-08-17 13:36:31Z: Response status code does not indicate success: 401 (Unauthorized). The sign-in to Azure is tied to the “Microsoft Azure Management” app that you can select within Conditional Access.
Microsoft Graph PowerShell
The same applies for the new Microsoft.Graph PowerShell modules - but here we receive a more detailed error message:
Connect-Graph: AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Timestamp: 2020-08-17 13:37:12Z The sign-in to the new Microsoft Graph Modules is tied to the “Microsoft Graph PowerShell (Preview)” app and some more apps I couldn’t determine.
Creating assignments and software deployment groups for Intune mobile apps is quite a repetitive and manual task. Because of that, I want to share a PowerShell script with you which allows you to automatically create software deployment groups in Azure AD and the assignments for various intents.
The script allows you to:
Create Azure AD groups (install uninstall purpose) Pick existing groups based on displayName Assign Intune mobile apps (tested for Win32 and MSI LOB apps) You can find the script on my techblog GitHub repository.
Because of the configurable group prefixes the script helps you to keep your Intune environment clean and implement a standard app assignment configuration.
The script uses the Microsoft Graph API and the following resources
https://graph.microsoft.com/beta/deviceAppmanagement/mobileApps https://graph.microsoft.com/beta/deviceAppmanagement/mobileApps/{AppID}/Assignments https://graph.microsoft.com/beta/groups It uses the preregistered app “Microsoft Intune PowerShell” which exists by default in all tenants. If you want to run the Script with PowerShell 7 you need to create an adjust the MSAL token section with the -DeviceCode parameter.
You can bulk select the apps you want to create the assignment and AAD deployment groups:
Hope this saves you some time.
Azure functions for PowerShell natively ship without additional cmdlets or PowerShell modules. In this post, I will show you how to add both public modules from the PowerShell gallery with automatic dependency management and custom modules.
For both options, we use the Kudu tools to adjust the configuration of our function app. You can launch them from the “Advanced Tools” section of your function app:
Afterwards, launch the PowerShell debug console and navigate to the wwwroot folder of your app:
Option 1: Automatic dependency management # Note: Installing modules which require license acceptance (e.g. the MSAL.PS module) currently cannot be installed with automatic dependency management. You can track the issue status here and here. {: .notice–warning}
Azure function apps running PowerShell come with a nice feature called managed dependencies. You can specify the modules you want to import from the PowerShell Gallery and the function app host will automatically process the dependencies.
In the requirements.psd1 add the module details:
# This file enables modules to be automatically managed by the Functions service. # See https://aka.ms/functionsmanageddependency for additional information. # @{ # For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'. 'Az' = '4.*' 'Microsoft.Graph.Authentication' = '0.*' } You can either specify an exact version available from the PowerShell Gallery or specify the major version with a wildcard. With the wildcard option it will use the latest version available.
The Office 365 Service Communications API provides information about Microsoft 365 service status for your tenant including service messages. I built a little PowerShell module to access the API with PowerShell cmdlets. In this post I want to show you some examples which help you to use the API.
PowerShell Module # I built a PowerShell module to access Microsoft 365 service status details natively with PowerShell. The PowerShell module and documentation is available on the PowerShell Gallery and on GitHub.
Before using the module an app registration is required. Setup instructions are also provided on GitHub.
CI/CD # By leveraging Azure DevOps I created a build and release pipeline which automatically builds the PowerShell module with Plaster.
Builds are only created if the commit on GitHub includes a version tag. This version tag gets automatically populated to the module manifest.
The build artifact gets then automatically published to the PowerShell Gallery as a new version. Furthermore, a new GitHub release including the module artifact is added to the project.
This process fully automates the publishing and build process for the module. For local development and maintenance, the module can also be built with Invoke-Build.
