Here we will start getting into some interesting parts to enhancing modern application management.
We will talk about the assignments of Application Management, which can indeed sound very basic and perhaps come across like a repeat of multiple guides and step by step documents. However in this part we will look to iron out some ideas of best practices, strategies as well as bringing in an element of workflow and automation which can unlock the abilities of enhancing modern application management even more.
This part is really the foundation of what we want to setup before we get into the fun stuff. The most important thing is to structure the base correctly before we start to have a multitude of workflows happening. The core of any enhancement of application management really has to be done at all levels and this includes where we structure how everything will be deployed, where it will be deployed, and the understanding of the purpose of every container we form.
Also to note that everything discussed here applies to all platforms and not just Windows, although Windows is shown in the examples which follow.
How do we make applications available
This is where we enter a much wider subject matter now. I believe many of us (including myself) understand the concept of how to make an application available to be installed. But what makes the enhancing-the-modern-application-management series approach different is to analyze the overall picture of how we make this happen and the business justifications to make this happen.
Stepping away from SCCM Practices
Again to re-iterat, we don’t want to bring SCCM into Intune. Meaning that we don’t want to bulk up in any complexities which we may have to deal with when it comes to the deployment of applications to collection containers and bring the same kind of issues across to Intune.
This is the time in which we re-evaluate the processes so that we have a much cleaner and slicker way of providing applications to devices and users. The key to this journey is all around the simplicity, where once we get to that level THEN we can revisit and tweak where needed. Sometimes the logic scalability can go insane and next thing you know you can have nested layers of conditions on so many angles you will no longer have a track of what CI is eligible for a container. Even with auditing, reporting and great tracking it still doesn’t remove the complication which can derive from this.
Below in Figure 1.1 are a couple of diagrams which outline how over time an application management process may get if you were looking to bring over these kinds of structures into Intune.
What we see here is perhaps a typical kind of structure within SCCM, where sometimes the requirements can get more complicated overtime and that’s where additional query rules get added or direct devices get added on the fly, and then devices we may not want to be in there have to be removed in more of a clever way via exclusion membership rules.
To think this is really all on just the collection level, then we take into account the application packages which then may follow multiple global conditions around OS, architecture, resources and detection methods which may either further complicate or overlap the conditions set at the collection container level.
To summarize the deployment of the application to the collection can add another layer. When we look at the deployment statistics you may get a warped result because you’ll less-than-likely be able to know the true results of what object should be involved within the deployment and not be able to account for a multitude of errors which may arise.
What we want to do is to be able to evaluate and take advantage of features where the levels and conditions are a lot cleaner and easier to understand. This will be explained in the sections below.
Structure of Groups in Intune
First, before we can make ANYTHING available, at least in a structured workflow perspective, we will want to start around defining the groups which will contain the relevant users or/and devices for specific advertisements. This essentially is the first layer according to the image in Figure 1.1
Lets start off with the first and simplest part being the name. The important part of this is having a very understandable and clear name which gives insight to what the group is for. One of the things I like to do is to have a definition of the groups membership rule type, and the reason being I advise this is because when it comes to any rules which are dynamic they can sometimes be tricky to have a constant monitor of especially when it comes to devices or users which you may not want them to be a member of.
So as a precaution I define two options for each group which have a role based structure of a “Automated” process and then another driven as a “Self-Service” process as seen below in the example Figure 1.2
I find its important to just have the specific application/configuration/compliance to take the lead as its name but then to also append it with something like “Automated” where dynamic rules take place and “Self-Service” where manually assigned takes place.
Think about the perspective of testing. If you have a manual group its much easier to keep a track of when it comes to auditing as well as being able to effectively test on devices or users which you know would still be there.
Dynamic Rule best practices
The aim is to have a clear and precise membership rule that will pull in the correct objects to your group.
The best way to get this across is to try and not use conditions such as OS Type and OS version rules. These kind of conditions can be specified at the application level where it has a level of requirements to meet. So we want to be able to structure all of the layers within the application management process where conditions are clean and not overlapping.
The requirements setting of an application are shown in Figure 1.3
Having a rule here is what this group is specifically for, so if it has to be a container for certain manufacturers, models or OUs then these would be the best level to perform them at. I try not to get too involved with creating multiple expressions where the validate-rules column becomes more challenging to understand the criteria of which object fits the conditions to meet.
Criteria Definitions for Applications
The application level is the second layer where we make good on the structure to ensure the application has its requirement level structured well and specific to the applications settings and system requirements as shown in Figure 1.3
The best advice I can provide around this area is to utilize this at the simplest form as much as possible. I find that file and folder conditions perhaps work the best where applications are easily identifiable. Registry keys are good too but sometimes they can be hit or miss depending on the type of values or keys you are trying to track. MSI Product codes are also great for where you are using applications that do have one. But for where you may package applications such as Adobe Reader, which have a base version and an update package, can take some testing beforehand.
Where we have many applications we need to utilize some customization which may not always involve a PowerShell script to be the main installer. A custom script outlines the conditions of detection. This is perfect for where detecting of a file or folder or registry key may not be possible. I would advise to only use this option where it’s not possible to use other methods.
Assignment of application to a group
Not to focus on how we actually assign an application to a group, but we want to dive a little bit into the filtering capabilities.
Following off from the section about stepping away from SCCM practices, we could compare this feature typically to how a Include Collection Membership and Exclusion Collection Membership would work. The familiarity of this process is great but what we don’t want to do is treat it the same way.
Where I see the benefit here is perhaps more the exclusion levels where we can see devices which we might not want included for specific advertisements, but we want to make clear precise ones. For example, we have Figure 1.4 we have a filter based on personal devices. So if I may want or not want personal devices within a deployment we can have this ready to go. These are found in Tenant Administration – Filters
Then we revisit an application which is currently being advertised we can then toggle the filtering mode as seen in Figure 1.5
For our own sanity, its great to know that just one filter can be applied to avoid the possibility of us getting carried away! Having some filters created beforehand would definitely help going forward so we are ready to construct the advertisements as needed.
At this point we have a cleaner workflow for our base of the beginning of enhancing application management.
Next On Part 3
In the next part we will go into the structure of how we define the purposes of what applications we wish to make available through the company portal and what will be required. This is the second part to the foundation and with that completed we will then be expanding into much bigger areas moving forward. Until then, reach out via Live Chat, Email or Phone if we can help!