This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.
First published on TECHNET on Jul 27, 2018
In this post we will discuss how we automated the publishing of internal line-of-business (LOB) applications to enrolled devices using Microsoft Intune. This is production automation that runs in the Microsoft environment to publish / upgrade LOB Applications in our Intune tenant. We have had long standing automation that publishes LOB applications through Configuration Manager and since we had the Intune connector configured, MDM enrolled devices were able to download applications through Company Portal. Now that we have migrated to an Intune stand alone environment, we maintain separate application publishing workflows through Configuration Manager and Intune. This post will aim to explain how you can automate an application publishing workflow through Intune using Microsoft Graph. A sample of the code can be found on GitHub here.
Scenario
In order to understand our production automation end to end we have to start with how an application request gets to us for publishing. We have an internal process where application publishers can request that their application be published internally. This will generate an XML file that contains relevant metadata about that application that we will then use for publishing. Relevant details include type of application, title, description, location to application files and other relevant details. Currently, we have over 200 internal production LOB applications published for MDM devices and we go through multiple updates / upgrades for each one of these applications. Since there are hundreds of LOB apps in our environment that go through multiple changes, it is necessary to run this automation since it would be very difficult for Admins to keep up with the amount of work generated from these requests.
Solution
Automated workflows in Intune can be accomplished by utilizing the Intune Graph API. In our automation we are utilizing PowerShell to make requests to the Intune Graph API for App Management:
/deviceAppManagement/mobileApps
. One important concept to understand is the Microsoft Graph permissions necessary. There are two types of permissions, delegated and application. For more information review the following link. In the case of the API’s we are utilizing for App Management, at the time of this writing, we need to utilize delegated permissions. This involves creating an Azure AD Application that has the proper permissions to the Microsoft Graph Intune APIs. Once we have an Azure AD App, we can utilize a service account that has the Application Manager RBAC role applied within Intune. The effective permissions of our automation are the least privileged intersection of the delegated permissions the Azure AD app has been granted and the privileges of the currently signed-in user, which is our service account. Even though our Azure AD App has all Intune Graph API permissions granted, our application workflow automation can never have more privileges then the limited Application Manager RBAC role that we assigned in Intune to our service account.
To demonstrate this, here are the steps that we use. First we pull our service account's credentials from KeyVault using a Service Principal. Once we have that, we can use the standard Get-AuthToken function supplying the user name and password for our service account. We updated the function with our Azure AD App ID in the
$clientId
variable. This will generate our delegated permissions auth token that we can then use in our requests when publishing applications within our Intune tenant.
Now that we have successfully authenticated, we can begin utilizing the Intune App Management APIs. First we start by parsing the XML we receive for an application publishing request. For each application type (iOS, Android, Windows) we have specific PowerShell functions that will handle the publishing. This is necessary because for each type, in order to publish to Intune, specific app metdata needs to be extracted from the application files. In the case of iOS, we need to parse Info.plist, for Android we need the AndroidManifest.XML and finally for Windows, the AppxManifest.xml. In the case of iOS we use the plutil.exe from Apple with the following options
-convert xml1 plistFile
to convert the Info.plist into an XML file. We can then extract the necessary metadata needed in Intune for publishing (CFBundleVersion, CFBundleIdentifier etc). For Android, we utilize aapt.exe from the Android SDK with the following options
dump xmltree apkFill
in order to generate the XML. Finally, for Windows, since an Appx/ AppxBundle file is an archive directory we can unzip the app file and extract just the appxManifest.xml file. In the case of an AppxBundle, we loop through each Appx folder and extract the relevant AppxManfiest.xml contained within the bundle. We then look at each AppxManifest.xml and determine the appropriate metadata for the AppxBundle. This is the first part of the process where we extract all the relevant metadata from the files that we wish to upload to the Intune service.
Once we have the necessary metadata, we can create / upgrade the LOB Application within the Intune service. By sending a POST request with the app metadata as JSON, we create a new application. If this is an upgrade to an existing App, then we go through the below steps to the existing AppID in Intune. The endpoint that we use is
/deviceAppManagement/mobileApps
. A sample JSON metadata for new Adroid app may look like this
.
{
"owner": "",
"fileName": "A_Online_Radio_1.0.5.4.apk",
"description": "A Online Radio 1.0.5.4",
"categories": [
],
"displayName": "A_Online_Radio_1.0.5.4.apk",
"minimumSupportedOperatingSystem": {
"v4_0": true
},
"@odata.type": "#microsoft.graph.androidLOBApp",
"identityVersion": "10",
"privacyInformationUrl": null,
"notes": "",
"informationUrl": null,
"developer": "",
"publisher": "A Online Radio",
"identityName": "com.leadapps.android.radio.ncp",
"isFeatured": false,
"VersionName": "1.0.5.4"
}
For this new or existing app object we then need a place we can store files. So we create a new content version for the application ID returned by the above POST request, then wait for an Azure storage URI to be generated. We do this by sending a POST request to the following URL once our app has been created
deviceAppManagement/mobileApps/ApplicationId/LOBType/contentVersions
.
Once we have this, we can encrypt our LOB application files and upload to Azure storage. When uploading files to the service we need to get information about the files and generate a file type that is suitable for upload. A .bin file is created then encrypted. We then provide information about the file, sizeEncrypted, size, manifest, name and @odata.type. This is explained further in the Readme.md file on GitHub. If we are uploading a Windows App with dependencies, then we must handle the upload of all dependencies as well. In our automation, we loop through all the dependency files, create the relevant dependency manifests, and upload relevant files to the Azure storage URI.
Once completed, we commit all the files in the Intune service and our application is created and ready to be assigned.
The final steps in our automation are to assign the application to an AAD security group and report back the status of publishing and any failures that may have happened. In order to assign the application, a sample function
Add-ApplicationAssignment
is available under the powershell-intune-samples / Applications folder. This will assign the application to the AAD security group ID with the relevant intent (available or required). Once the app is assigned users targeted will be able to see the application within Company Portal and install.
After our workflow runs, we report back and notify the application owner that their application has successfully been created and assigned. This high level diagram is an outline of how our automation runs:
Overview of Intune App publishing workflow
Key Benefits & Takeaways
Due to the volume of changes in our Application space, automation is necessary to reduce the amount of work for Admins. By implementing this automation we have a 0 touch solution for creating / maintaining LOB applications in our Intune environment. This has significantly improved our efficency in maintaing our LOB Apps in Intune in addition to decreasing the amount of time it takes for requestors to have their internal LOB App published / upgraded. Thank you for reading! Hopefully this post has helped you better understand how workflows can be automated in Intune and how it has helped keep the Microsoft environment in sync for LOB Apps published in Intune.