Introduction
Covering from our previous part of the Microsoft Endpoint Manager series we looked at the layout of our application approval workflow and explored some of the native ways we can structure how we handle applications which require specific approval or relevant license tracking.
What we want to do now is to expand on this topic further by adding in the workflow parts which will be able to fully initiate and support any requests which we put in to our endpoint manager environment. Thus having a full automated and structured workflow where can support approvals where needed.
Intune Preparation
Before we get into the actual code we will use to start building the approval workflow, we need to understand how we will structure our Intune environment so we can easily identify the applications which we will make a part of this structure.
Category for Approval Required Applications
One way to define this is by using App Categories. Now if we have applications which we feel meet the criteria of the approval structure, then we can build a custom App Category for them.
In this example, we would define a new App Category called “Approval Required”.
With this defined, we can then start to look across all of the applications we have within our Intune environment. Once we see some applications that we would include then we can edit the properties and then assign the category of “Approval Required”.
Of course we can define this category much further if we want to include further information into the category and still have it where we can identify the application as it requiring approval, which we can go into more further in the article.
MS Graph Logic
We will go through a few sections of code. These have been categorised because we want to be able to have control over each area for when we do go into making any automatic workflows. These will all help populate any technology of our choosing which will take the role of going through the approval process.
Each section we can go through where we can control it through more granular options.
Connecting to Tenancy
The first part is to connect to your Intune tenancy and also your Azure AD tenancy. There is perhaps additional lines which may not be required every time such as the “Install-Module” line, if these are already installed then this can be removed or hashed out.
Pulling a List of Applications
Now the next part of the code is then to obtain a dynamic list of all of the applications. The first line is used to allow certain properties to be discovered such as the @odata.type. Now this particular property shows a raw format of all of the application categories which you can see below;
- #microsoft.graph.windowsStoreApp
- #microsoft.graph.managedAndroidStoreApp
- #microsoft.graph.managedIOSStoreApp
- #microsoft.graph.win32LobApp
- #microsoft.graph.microsoftStoreForBusinessApp
- #microsoft.graph.officeSuiteApp
- #microsoft.graph.windowsMicrosoftEdgeApp
- #microsoft.graph.managedAndroidLobApp
- #microsoft.graph.iosLobApp
- #microsoft.graph.androidLobApp
- #microsoft.graph.windowsMobileMSI
- #microsoft.graph.androidStoreApp
You may notice there are two lines getting the applications from Intune. So this would be to accommodate if you are wanting to incorporate all applications in the process, or any process which is required. But there is also a variable which will obtain all of the applications which use the “Approval Required” category as well.
Advertisement Details
The next section is now around obtaining the advertisement details around the application that has been selected. The $AppName variable contains just a text name of the application, but this can be controlled from the dynamic variable list in the above section or depending on which technology you will use for this, which we will go through various options later.
Another part of this code we also obtain the details of the Intune application, but we also include an additional line where we can filter the application out by its application type. If you use an application where you may have a Win32App, Windows Store, Android or iOS version then its good to be able to filter out the specific one you need if required to.
The last part of this code also has a dependency on the connection to your AzureAD tenancy, as this is used to get the AzureAD group and AzureAD Object related within the advertisement. Then we will understand where to add additional objects once the request has been approved.
Adding a device/user to a group
The last part of the code completes the request of adding the object to the group which is retrieved from the advertisement details.
The aim of this section is to enter the friendly name of the object whether that be a device or user, depending on the type of advertisement that you have of course and then this will then add the object to the group. Where you have room to build around your structure starts at the $ObjectName variable.
Applying to a approval solution
Now that we have all of the sections of code, we have enough to put together a solution. Of course the solutions which we might use to encapsulate the code within.
So below have listed a couple of options as an example.
Au2mator Self-Service Portal
Referencing from the previous part of this serie, where I displayed the Au2mator Self-Service Portal which could be in the middle of the application request process, where a user can request a service and specify the application and then gain approval, and once this approval is granted the authoritative team goes ahead and performs the request.
But now enhancing this user case, we can now use the code sections above to enrich the process even further. For example instead of typing out the application name in the self-service portal, you can have the ability to use a PowerShell Script which can dynamically obtain the Applications as seen in the Pulling List of Applications code section.
Once approval is gained you can have the same PowerShell template code which handles the questions then perform the Adding a device/user to group code section. But with all the components of the MS Graph code you can customise this whole experience out even further.
To find out more on how to setup the self-service portal solution it can all be found here!
System Centre Service Manager
Service Manager being a very powerful tool helps to make this application approval workflow process great. Considering its history with the SDK application approval workflow with SCCM, it has potential to bring the process to life by using the code sections mentioned above.
With its native integration with SC Orchestrator you can construct a runbook which can use the Initialize Data steps that can build the questions for the Service Manager tickets such as the following;
- Select Application
- Requester Name
- Reason for Application
, And then have another runbook which can then take the information and add the requester (or primary device) to the group which holds the advertisement of the application deployment.
Summary
Overall, how we think and put together a solution such as this it really comes all down to the user experience and the user case of providing a structure in which approval is required. From the previous part and then this part we have shown how the layout can potentially be, but also then providing an example of PowerShell code which then take it a step further if seeking a true automated process around application management.
The key is to have some kind of process where we can keep track of what we are pushing out but also where approval can also be audited, so all around we have a fully trackable lifecycle.
Next on Part 6
On the next part we will look into MAM policies which can help further enhance the application management process with a good emphasis around the mobile applications.
For further information, please click HERE to contact our support team.
