Docy Documentation

Endpoint Admin Assignment Profiles allows Endpoint Admin users to deploy applications to specific Azure groups for one or multiple applications.

Endpoint Admin will make use of the assignment functionality from Microsoft Intune, as well as reading Azure AD groups from the Microsoft Graph API allowing users to configure assignments for an individual group.

The assignment functionality can be found on a given Win32 app on a given Microsoft tenant on the following URL: https://endpoint.microsoft.com and comes in 3 different categories “Required“, “Available” and “Uninstall“, all with multiple options.

• The Assignment Profile is a feature that let users create a configuration logic for the Azure groups and save the configuration in a profile for more easily re-usability.
• An Assignment Profile requires only a name to be created, the group(s) can be added later to the Assignment Profile.
• An application can only be assigned to one Assignment Profile at a time.
• You have the option to create, delete, copy or edit an Assignment Profile after creating the Assignment Profile.
• The Assignment Profile has 3 group categories: “Required“, “Available“, “Uninstall“.
• To each Assignment Profile group category, you can add Azure groups.
• Azure groups can have the mode of “Included” or “Excluded“. An Azure group will be included, automatically, in the first assignment group category you add the Azure group to, but excluded if added to the rest. E.g.: you add the azure group “All users” first to the Assignment Profile group category “Required” and next to “Available”. It will be included in the first Assignment Profile group category “Required” but excluded in “Available”. You can manually change the to include mode for Assignment Profile group category, but it will be automatically excluded from rest.

Create a new Assignment Profile

To create a new Assignment Profile first you will have to access Assignment Profiles page under the applications tab in the sidebar menu.

On the Assignment Profile page, there will be a list containing all Assignment Profiles created with additional information like the number of applications that the profile is assigned to (1. Applications). The number of Deployment Schedules an Assignment Profile is used in (2. Deployment Schedules). And the last time it was updated (3. Last Updated).

To create a new Assignment Profile click on  the “+ New profile” button.

After clicking on the button “+ New profile” you will be redirected to another page where the Assignment Profile is created, and you can give the new Assignment Profile a name and optionally add Azure groups to the different assignment categories: Required, Available and Uninstall. Settings can be save using the save button.

After clicking on the “+ Add group” button under one of the 3 assignment categories, a popup will open where you can select the Azure groups that you want to be affected by the Assignment Profile.

It is important to know that each Azure group can only be added once as “Included” to one of Assignment Profile categories.

• For example, if we add the Azure group “All Users” to “Required” and “Available”, the “All users” will be included in the first assignment group “Required”, and excluded to the other assignment group “Available”. 

You have the option to manually include “All Users” in the second assignment group category “Available” where it was excluded before, but then it will be excluded from the first assignment group category “Required” automatically.

After creating a new Assignment Profile, you have the option to view details, copy, edit or delete the Assignment Profile, by clicking the 3 dots on the right side, to expand a meatball menu with the 4 options:

• First, the Details option: This will show the Assignment Profile in a read-only view, with no save button.
• Second, the copy options which will create a new Assignment Profile with the exact same groups selected and with the same name, but with no application assigned.
• Third, the edit option which opens the Assignment Profile and you can change its Azure groups or name.
• Fourth, is the Delete option that will delete the Assignment Profile.

Assign a profile to an application

Important, an application can have ONLY ONE Assignment Profile assigned at a time.

After the Assignment Profile is created, You can assign a Assignment Profile to an application, from the public and private repository page by clicking on the 3 dots on right side next of an application. This will expand the meatball menu.

• When you select the assign profile option from the meatball menu, it will open a new pop-up window with all the Assignment Profiles created on that subscription from which the you can choose
• You can ONLY assign a profile to deployed applications from private and public repositories. If the application is not deployed, the assign profile will be greyed out under the meatball menu.
• Another option is the “Clear Assignment Profile” which will remove the Assignment Profile from that application.
• When you have assigned a profile to an already deployed application, the name of the Assignment Profile will appear under the “Assignment Profile” column.
• After assignment, the “Assigned” state will change to “Yes” in the Intune that is integrated with your Endpoint Admin subscription.
• If you access the properties of the application, you can see the Assignments in Intune match the Assignment Profile in Endpoint Admin.
• If you choose to “Clear Assignment Profile” of an application the “Assigned” status in Intune will transition from “Yes” to “No” and it will clear Azure group from the application under Required, Available and Uninstall.

With Endpoint Admin’s newest feature Ring Group Automation (RGA), you can easily manage and control Windows Update for Business (WUfB) and Win32 apps deployment in Microsoft Endpoint Manager. In this article we will go through Endpoint Admins Ring Group Automation, the reasons why we create RGA, how does it work and step-by-step to implement it using Endpoint Admin.

Microsoft is investing heavily in cloud-based solutions and this means that on-premises solutions will be phased out to a greater extent. This also comes to device management and therefore, more and more companies are embarking on their journey towards the cloud and all the benefits that come with it. To kick-start this transition, Microsoft has developed the concept or terminology called “Co-Mangement” where devices have the SMS Agent and Intune agent installed at the same time and where sub configurations in the form of workloads from ConfigMgr can be moved in phases to be managed in Microsoft Endpoint Manager  (Intune) instead. Co-Management will not be covered in this article, but you can read more about it in Microsoft docs. What is interesting about this technology is that we can move Windows patching to the cloud as a stand-alone element.

For handling mobile devices and desktops, Microsoft Endpoint Manager (Intune) is the way to go and is a technology under strong development. WSUS with SCCM, which many system administrators have used for patching PCs, is not an option in the future. For a replacement, Windows Update for Business (WUfB) is the solution. You can read more about WUfB here Microsoft docs.

There are many pros and cons between the two technologies – to boil it all down – WUfB with Endpoint Manager does not share the strict control that you get with SCCM with in-depth reporting and limitation of patches to computers using collections and where you distribute patches. But WSUS, on the other hand, is a heavy and old technology that will most likely not be developed much further.
Another challenge with WUfB is that all updates come from the cloud and you will put a lot of pressure on your WAN line if you do not make your rollout in phases. Especially in large enterprises with thousands of devices. This is exactly the the challenge RGA can solve.

“So how do we stay control when we move the workload from WSUS to WUfB?”

As stated in the Microsoft docs we can only limit patches and control the rollout on the client using CSP profiles to defer or pause updates – bummer… that means we must segregate devices into groups like collections in SCCM to control the configurations on the clients and stay in control and do phased rollouts.

In Endpoint Admin you can create a ring group automation profile (RGAP), with the desired configuration. A RGAP consist of a desired number of rings, scope, exclude, detection interval and prefix.

• A ring consist of device-only security group in Microsoft Entra ID. It is only device-groups because of limitation in the Intune assignment engine as it does not support include/exclude of mixed user and device groups.
• Each Ring can be divided into a desired number of subgroups to support staged rollout and limit WAN utilization.
• You can add both user-based or device-based groups to a ring. When a user is added to a ring, it is the user’s primary devices from Microsoft Entra ID which are added to the ring.
• RGAP Scope: The scope can be global, meaning all devices in the Microsoft Entra ID. Or you can select a group. If you use a group as a scope, only devices which are a member of the scope will be affected by RGA.
• Exclude: Groups can be excluded from the RGA. All devices and user’s primary devices which a member of a group added to exclude, will not be affected by RGA.
• Device objects can only be a member of one ring.
• A user can use the Endpoint Admin shop, to move their devices into a different ring.
• RGA will automatically create a “Final ring”. All devices in the scope for the RGA will automatically be added to the final ring, if their are not a member of any other ring in the RGA.
• Detection interval is how often the RGAP should be executed and update ring membership.
• Prefix: Groups create by the RGAP will be prefixed with the given prefix.

In this section we will show examples of how to create an RGAP and how to utilize it.

Global RGAP example

In this example, we will create a RGAP using the scope global to affect all devices in our Tenant. We create 3 rings and RGAP will automatically add the final ring.

1. In Endpoint admin under Resource Management, select Ring Group Automation:
   
2. Select New Profile in the top-right corner:
   
3. The New RGAP page will look like this:
   
4. Now we will configure the RGAP:
   1. Name of the RGAP.
   2. Prefix for the groups that will be created by the RGAP.
   3. Enable the RGAP.
   4. Detection interval, in this example the RGAP will run every 4 hour.
   5. Scope of the RGAP. We use Global, meaning all devices will be affected by this RGAP.
   6. Exclude: Here we have added the group Global-RGAP-Exclude. All members of this group will not be affected by the RGAP.
   7. Add ring, clicking this button will add a ring. We have added 3 rings. Remember the final ring is automatically added to RGAP.
   8. User Groups: Here we can add groups with user-based membership to each ring.
   9. Device Groups: Here we can add groups with device-based membership to each ring.
   10. Target Rollout Group Count. Use this to choose the number of device sub-groups the ring should be divide into.
   11. Rollout Groups: When the RGAP have run once the rollout group can be seen here.
       
5. In the next step we have added groups to Ring 1-3:
   1. In Ring 1, we have added the user-based group “IT Department” under User Groups.
   2. In Ring 2, we have added the device-based group “Device Test” under Devices Groups.
   3. In Ring 3, we have added the user-based group “All IT Managers” under User Groups.

Deployment Schedules allows IT-administrators to deploy applications in stages, based on days from a application is updated/created or on dynamic dates – like second Tuesday of the month. Microsoft Endpoint Manager provide no such feature, forcing the IT-administrator to create new Win32 instances with new versions to allow them to have an old version scoped for the production environment while testing a new version.

Endpoint Admin with Deployment Schedules will make use of Assignment Profiles enabling applications to be available for users to install and also patch available installed applications. To do this Endpoint Admin will make use of 2 application instances in Microsoft Endpoint Manager:

• Base application instance: present when deployed via Endpoint Admin, and is using the Assignment Profile assigned. This application instance is updated when a Deployment Schedule is complete or if Auto Update is enabled and no Deployment Schedules are assigned.
• Patch application instance(s): the application instance used for patching. Potentially non-required base application installations will be patched using this instance. This application instance is created when a schedule is started and is not deleted after a completed schedule.

• The Deployment Schedule will deploy a new version of a given application based on the Deployment Schedule configuration assigned to a given application when updated. This allows users to deploy a new version utilizing a phased roll-out.
• Each Deployment Schedule has a name, a number of phases and a trigger.
• A phase has a name, an Assignment Profile that will be assigned to the application when the phase becomes active, an offset in days and a requirement script. The requirement script allows to only install/patch the new version on devices that have the application installed already.
• The defined offset for the initial phase is derived from the trigger, the offset for the remaining phases is based off of the initial phase.
• If the requirement script radio button is toggled on, then the phase will affect only the users/devices where the requirement.ps1 script returns 1.
• The trigger for a deployment schedule will decide when and how a deployment schedule is initiated, there are 3 options:
  1. When a new version is uploaded: the Deployment Schedule will start whenever a newer version of that application is uploaded.
  2. Weekly: the Deployment Schedule will start every week on the day specified. This allows you to deploy all new application versions starting on a given day of the week.
  3. Monthly: the deployment schedule will start every month in a specified week day of one of the first 4 weeks at 00:00. E.g. (first Monday of the month or third Wednesday of the month).
• When creating a new deployment schedule, the name and the Assignment Profile for each existing phase is required.
• An application can have only 1 deployment schedule at any given time.
• An application has to be deployed or else you can not assign a deployment schedule to it.
• You can not have a deployment schedule with less than 1 phase.
• You can not have a deployment schedule with more than 28 phases.
• The number of phases depends on the offset and on the trigger option, those 2 above are the minimum and maximum limits.
• If the trigger is set on Weekly, the maximum number of phases can not exceed 7. This is to ensure patch capability when new updates are made more than once a week.

Smart Patching

Smart Patching can be enabled for a Deployment Schedule. This creates a final phase called a Smart Patch phase. The Smart Patch phase ensures that the application that the schedule is assigned to will only have devices assigned as Required if the devices are detected to have the application installed, as this is the final phase, it will be applied at the end of the Deployment Schedule. All devices that are not detected to have the application installed will not be assigned or have their assignments removed from the application using the schedule.

Smart Patching Background

Patching devices in Endpoint Admin depends on having a patch application instance that includes a requirement script. This setup ensures that only devices with the specific application already installed will be patched. As a result, even if a user installed the application through the Company Portal or by other means, it will still be patched.

To optimize device resource utilization, we identify which devices actually have the software installed, so we can limit the scope of the patch deployment to only those devices. The Installations Dashboard already has the ability to map a specific Endpoint Admin application to the Discovered Apps on each device. We use this data to create an Entra ID group which contains the devices known to have the application installed.

When this approach is applied only to the Patch Application instance, users can still uninstall available applications via the Base Application instance in the Company Portal. In such cases, the Patch Application won’t be applied because its requirement script will no longer detect the app as installed. Therefore, there’s no conflict – even if there’s a delay between when a user uninstalls an application and when their device is removed from the Smart Patch application group.

For the Smart Patch functionality to work, the application must be properly installed on the endpoint and appear in the “Add or Remove Programs” (appwiz.cpl) list. Otherwise, it won’t be reported in Intune’s Discovered Apps list, and we won’t be able to detect its installation. Since some applications don’t register themselves in this way, the Smart Patch solution won’t be applicable to all applications. 

To create a new deployment schedule, access the Deployment Schedule page under the Applications tab in the sidebar menu.

To create a new deployment schedule press the “+ New schedule” button.

Every new deployment schedule is initialized with 3 phases as default and the trigger is set to “On new version”. Here you can add a name to the deployment schedule, you can also change the number of phases, the name of the phases, and a given trigger.

Clicking on the “Set” button of the trigger, a modal will open presenting you with the 3 options as shown:

• When a new version is uploaded: the Deployment Schedule will start whenever a newer version of that application is uploaded.

• Weekly: the Deployment Schedule will start every week on the day specified. This allows you to deploy all new application versions starting on a given day of the week.

• Monthly: the deployment schedule will start every month in a specific weekday, of the first 4 weeks at 00:00. Example: every second Tuesday of the month.

NOTE: Make sure to use Assignment Profiles which is configured with required assignments, otherwise each phase will only make the path application available for the end users/devices.

After saving the Deployment Schedule, go to either Public or Private repository and select an application that is deployed already and go to its meatballs menu, there we can see 3 options for this feature:

1. Assign deployment schedule: assigns a deployment schedule to the application. You can not assign a deployment schedule to an application that is not deployed (base application), or already has a deployment schedule running.
2. Clear deployment schedule: unassigned the Deployment Schedule that was assigned and allow for the option to delete the patch application instance from Microsoft Endpoint Manager.
3. Delete patch-app instance(s): deletes the patch application(s) instance(s) from Microsoft Endpoint Manager.
   

In this example we will assign the Deployment Schedule “Evergreen” mentioned earlier for the “FileZilla” application. By clicking the Assign deployment schedule button a new modal will appear where you can assign the schedule.

After clicking on the select button, you can see that the name of the Deployment Schedule is shown in the column “Deployment Schedule” of the application in the table.

You can also see that the application has 2 more columns regarding the deployment schedule:

• Phase state:
  • InProgress indicates that the patch application is in the progress to be pushed and/or having setting the given Assignment Profile for the given phase.
  • Finished indicates that the patch application is finished being pushed and/or having setting the given Assignment Profile for the given phase.
• Current phase: specifies current phase

Now to initate the deployment schedule you need to add a newer version of “FileZilla”.

Because the trigger is set to “On new version” the first phase will be initiated when a new version is registered to the repository.

When uploading the new application version you are informed that it exist already, this will trigger the Deployment Schedule for the given application matching on name.

After uploaded a newer version of “FileZilla” you will be presented with a status icon, indicative of the  Deployment Schedule being in progress.

When the Deployment Schedule has started Endpoint Admin will create the app in Microsoft Endpoint Manager.

Microsoft Endpoint Manager will have the following application instances present during a Deployment Schedule:

1. Patch App instance: This app instance will be created and handled throughout the Deployment Schedule. On each phase the assignment will be changed(not merged) to the Assignment Profile configured for the given phase.
2. Old Patch App instance: This app instance is present during a Deployment Schedule and is replaced by the Patch App instance when the Deployment Schedule is complete.
3. Base application instance: The app instance present when deployed via Endpoint Admin, and is using the Assignment Profile assigned. This application instance is updated when a Deployment Schedules is complete or if Auto Update is enabled and no Deployment Schedule is assigned.

Microsoft Endpoint Manager will have the Base and Patch app instance present on a finished deployment schedule.

NOTE: If new versions of a given application arrives while a Deployment Schedule is running, the schedule will finish before starting a schedule of the newest version.

Endpoint Admin provides several automation features for assignment, patching and deployment of applications distributed using Microsoft Intune / Microsoft Endpoint Manager, each of which is described as a subsection of this section.

Read about Smart Patching and Auto Smart Patching for automation of the creation, maintenance and assignment of device groups to applications.

Read about Auto Deployment to learn how to configure automatic deployment of applications to Intune based on detected unmanaged application instances found on the devices in your Entra ID tenant.

It is recommended to read about Smart Patching first, as Auto Deployment integrates with Auto Smart Patching to inform its deployment strategy.

All Deployment Automation settings can be found under the Application Management section of the Endpoint Admin portal:

Deployment Automation Settings Management as an MSP

As an MSP you can easily view the state of all the deployment automation settings of each managed subscription by clicking the “Managed Subscriptions Settings”-button inside of the Deployment Automation page: 

Clicking this button will open a modal containing a table of all subscriptions and the enablement state of each, you can then simply view or change the enablement state of each setting on each subscription: 

As an MSP, you still need to be aware of the needs of your clients before enabling any automation. Ensure to configure appropriate exclusions and device scopes if needed on each subscription before enabling one of the automations. 

Smart Patching

Smart Patching can be enabled for a deployment schedule and automatically creates and maintains Microsoft Entra ID groups, (Smart Patch groups), to be used in Patch Application assignments that only target devices that already have the software installed. This is done by leveraging the “Discovered Apps report” as known in the Intune Portal, in code and Microsoft documentation known as the App Inventory Raw Data Report (AppInvRawData), to detect which devices have an application installed. 

Smart Patching is only compatible with Windows applications in the public repository, who appear in the AppInvRawData, this accounts for most Windows applications. If the application cannot be found using “appwiz.cpl” in Windows, then Smart Patching will not be available. Support for macOS applications is planned and coming soon. 

Smart Patch group creation and maintenance 

Applications in the public repository that are in use in your subscription and have a deployment schedule assigned on them with Smart Patching enabled on the deployment schedule, will automatically get a Smart Patch Entra ID group created. The memberships of each Smart Patch group will be reevaluated several times every day, currently between every 4^th and every 8^th hour. 

Endpoint Admin maintains a detection name for each application in our public repository; this name is compared to the name of the applications found for each device in the AppInvRawData report. Based on this a set of AAD Device IDs is created, these AAD Device IDs then must be converted into a new set of IDs that represent the corresponding Directory IDs for the devices, as device objects cannot be added directly to Entra ID groups using their AAD Device ID.  

The IDs of the member objects in the Smart Patch group are then compared to the set of IDs that were constructed from converting the AAD Device IDs in the AppinvRawData report to their corresponding Directory ID. All the current member IDs that are not in the set of IDs created based on the report data will have the membership of the object removed from the Smart Patch group to which the directory ID corresponds. All IDs in the set of IDs constructed from the report data that were not found in the set of IDs of current member objects of the Smart Patch group will have its corresponding AAD Device Objects added as members of the Smart Patch group. 

The membership of devices in Smart Patch groups can be limited by the user by accessing the Deployment Automation page and selecting a group to use as the Device Scope group for Smart Patching. This is explained in the section “Limiting Smart Patching group memberships to a set of devices”. 

Assignment of Smart Patch groups to the Public Patch Application 

When a Smart Patch-enabled deployment schedule is assigned to an application, the final deployment phase of this Deployment Schedule will update the assignment of the Patch Application in Intune to contain a group assignment target, targeting the Smart Patch group. 

Note that the Phase Accumulative setting on a deployment schedule is ignored when Smart Patching is used, so that only the Smart Patch group is assigned. This may be subject to change in the future. 

The first time a deployment schedule with Smart Patching enabled is assigned to an application a Smart Patch group will be created immediately; this group will remain empty until the automation described in the preceding section is triggered. This means that it can take between 4 and 8 hours before the memberships are in place. 

The Smart patch group is named in the following format: 

EA_SmartPatch_{DeployableItemType}_{OS_Type}_{ApplicationName}_ ({Application_ID}) _{GroupNumber} 

Where {DeployableItemType} can be one of Public, Private, MSP, Public Configuration Set, MSP Configuration Set, Private Configuration Set. In practice you will for the time being only see “Public”, as Configuration Sets do not support patching yet, and only public applications have their detection names configured as of now. 

{OS_Type} is one of “Windows” or “MacOs”. Currently you will only see Windows here as macOS is not supported by Smart Patching yet. 

{ApplicationName} will be the name of the application as seen in the Endpoint Admin repository that corresponds to the {DeployableItemType}. Custom names from subscription level metadata are not taken into account. 

{Application_ID} is Endpoint Admin’s internal ID of the application from our database. We put this there in case several applications in the same repository happen to share the same name, as doing so avoids a potential name collision, as it is in practice possible to maintain several versions of the same app in each repository with the same name. 

{GroupNumber} is a number that has been speculatively added to make it easier to perform phased/ring rollouts of patch applications in the future. Currently it is always “001”. 

Smart Patching – Simple Practical Example 

In this section, a step-by-step guide with commentary is provided to showcase and explain how Smart Patching is used in a concrete example. 

Step	Description	Context
1.	In order to begin with Smart Patching, we either need to create or find an existing Deployment Schedule that we want to add Smart Patching to. If you already have one, you can skip this part.
1. a	Navigate to the Deployment Schedules list in the sidebar of the Endpoint Admin Portal
1.b	Decision – Click on an existing schedule that you want to enable Smart Patching for (1.d) or create a new schedule (1.c)
1.c	Click the “New Schedule”-button
1.d	Click an existing schedule by pressing on its row
1.e	Enter a name for your new deployment schedule in the name text field in the top left.
1.f	On the right-hand side of the page below the “New phase”-button you will see the “Smart Patching”-toggle. Toggle this on now.
1.g	If you created a new schedule, you would see that three default patch phases were added. For a simple patching setup where the patch of an application is not rolled out in phases, these should be removed. Click the Remove button for each of the three phases. Ensure that Smart Patching has been toggled before attempting this, as otherwise you will not be able to remove the last phase as the UI enforces that there is at least one phase in a deployment schedule, in our case this should be the “Smart Patch Phase”.
1.h	Ensure that the “Offset”-setting of the Smart Patch Phase is set to 0, so that deployment of new patches will occur as soon as they are available. The “Offset”-setting really means offset in days from when the deployment schedule is triggered until the deployment phase starts. By default, the deployment schedule starts when a new version of the application is available.
1.i	Ensure the trigger for the deployment schedule is set to “On new version”, otherwse change this using the “Set”-button.
1.j	Finally, press the save button.
2.	Now we’re going to assign the deployment schedule to an application.  However, if you edited an existing deployment schedule and it was assigned to one or more applications, then you can skip step 2 and go to step 3. At this point applications that were already using the existing schedule that you updated, will have its Smart Patch groups created if they did not exist.  Continuing with step 2: Go to the public repository for windows applications by clicking on the navigation link in the sidebar under the section “public repository”.
2.a	Find a Windows application that you wish to assign the Smart Patching deployment schedule to. The application must have its base app deployed and not have any patching or deployment operation underway.
2.b	Click on the application row somewhere where there isn’t text or another UI element to open up the application sidebar, then click the “Actions”-button to open its dropdown menu, and click the “Assign deployment schedule”-button
2.c	Search for the “Smart Patch” deployment schedule or whichever name you gave it. Select the schedule in the list by clicking on it, and then click the “Select”-button in the modal.
2.d	Now the deployment schedule should be assigned on the application.
3.	Now we move on to starting the deployment schedule to deploy the patch app. If you don’t do this step, then the changes we have just made will first take effect the next time a new version of the app is uploaded to our systems.
3.a	Open the “Actions”-dropdown in the “General”-tab in the application sidebar of the application that has the deployment schedule you’ve enabled Smart Patching for. Find “Start deployment schedule”-button in the dropdown entries and click on it. You will be asked to confirm this action after clicking.
3.b	Now the patch app deployment will start shortly. The process of uploading the patch app to Intune can take a few minutes depending on the size of the application.  While we wait for this, we can open the “Assignments”-tab in the application sidebar and view the currently active assignments, and which deployment schedule phases are pending.
3.c	When the patch app deployment is complete, you will be able to see that the Smart Patch Group has been added as a Required assignment.
3.d	You can view the members of the Smart Patch Group and other details by clicking “Show more” on the assignment pictured in the last step, and then clicking on either the name or the ID of the group
3.e	You will now see the members tab of the Entra ID group inside our Entra ID group management module.  If this is the first time a Smart Patch deployment schedule has been applied to the application, then this list should be empty, and will be populated in at most 8 hours.
3.f	After at most 8 hours all devices that have the application installed should appear as members in the group.  In this test system only 1 device has it installed.  You can speed this process up yourself by adding the devices that you think already have the software installed to the group. The system will automatically clean up those that it determined not to have the application anyway as part of the Smart Patching automation that is completed at least every 8th hour.

Auto Smart Patching

Auto Smart Patching is a setting that can be enabled on an entire subscription, or as an MSP, you can set whether it should be enabled or disabled by default for all your managed subscriptions. By default, this is disabled / not active. 

Enabling Auto Smart Patching causes all currently deployed applications that do not already have a deployment schedule set to be evaluated for Smart Patching eligibility.  

When enabled, all eligible applications that do not have a deployment schedule will have a Smart Patching deployment schedule set on them that is automatically created by the Auto Smart Patching module, this deployment schedule is named “Auto Smart Patch” when created, it can however be renamed by the end user. The applications that had the automatically created deployment schedule set on them will then have their deployment schedule started to begin the process of patch application deployment to managed endpoints governed by Microsoft Intune. When this happens, Smart Patching proceeds for each application as described in the preceding Smart Patching section. 

Furthermore, when this feature is enabled, the end-user will always be asked if they would like to deploy an application using Smart Patching as the deployment strategy when they manually deploy an application. The user can choose whether they would like to only deploy the base application, or whether they would like to employ the Smart Patching deployment strategy, which then assigns the Auto Smart Patch deployment schedule to the application, deploys the patch application and then the base application. 

Configuring Auto Smart Patching

To configure Auto Smart Patching, you must access the Deployment Automation page, which can be found in the Application Management section of the Endpoint Admin Portal sidebar. 

From this page, you will see multiple settings. As an MSP, you will both be able to see the defaults set on an MSP-level and what the current settings are for the subscription you are currently viewing. 

To enable the setting for all managed subscriptions that are set to inherit this setting from the MSP you must switch the toggle on displayed below: 

By default, all managed subscriptions are set to inherit from the MSP, but this setting can also be controlled individually for each subscription. 

If you are not an MSP user or if you wish to control this on the subscription-level you can use the dropdown select menu outlined in red below to control the setting value for Auto Smart Patching: 

Auto Smart Patching Application Exclusions

As seen in the two images above, there is a button called “Manage App Exclusions”. Clicking this button will display a table of all applications in each repository which can be set to be excluded from automation. This excludes them both from Auto Smart Patching and Auto Deployment. Auto Deployment is documented later in this document. 

Exclusions can be configured both on the MSP-level and the subscription level. 

Setting an application to be excluded from automation means that they won’t be considered eligible for Auto Smart Patching or Auto Deployment. If the Auto Smart Patch deployment schedule is already assigned to an application that you have just excluded, it will be unassigned, and the patch application instance of the application will be deleted. 

Pictured above is the current list of apps that can be excluded and their exclusion state seen from an MSP’s point of view. Excluded apps will always appear at the top of the list. In the picture, iTunes is marked as excluded as it has the checkbox in the first column checked off. 

Having an application set as excluded does not prevent a user from manually assigning the Auto Smart Patch deployment schedule to an application

Limiting Smart Patching group memberships to a set of devices

For the purposes of preventing some devices from being patched or for testing Smart Patching with a limited set of devices, it is possible to configure a set of groups from which the devices considered for being added to a Smart Patching group will be based on, this can be done by clicking the “Manage Device Scope”-button.  

Pictured above is the modal UI presented when the aforementioned button is clicked. You can search for any group in the Entra ID tenant that is connected to your current subscription and select a group to use as the device scope group or remove the currently selected group used as the device scope. In this example, the group “CN-VM-GRP” is selected. This means that only devices within the group CN-VM-GRP will be eligible to be in any Smart Patch group. If you already have devices in existing Smart Patch groups, then these will be removed when the automation runs every 4^th or 8^th hour if they are not in the selected device scope group. 

This group can be a group with nested groups in it containing devices as transitive membership API calls are used to collect all the IDs of the members. 

Auto Deployment, or shortened Auto Deploy, is a setting that controls whether unmanaged applications detected on managed devices which have a corresponding application in our public repository should be automatically deployed so that the unmanaged application becomes a managed application. This setting is disabled by default, and for subscriptions managed by an MSP the default setting is to inherit the setting value from the MSP-level configuration. 

Auto Deployment is currently only available for Windows applications, however, support for macOS applications is planned and coming soon. 

You can configure this setting by accessing the Deployment Automation page inside the Application Management section of the Endpoint Admin portal, as with Auto Smart Patching. 

To access the Deployment Automation page, find Application Management in the sidebar of the portal, expand it and click on the Deployment Automation entry: 

From here you can either change the MSP-level setting and the subscription-level setting for your current subscription, if you are an MSP user, or if you are a non-MSP user you can only change the subscription-level setting for your current subscription: 

Pictured above is the subscription-level setting. Below is the U.I. for the MSP-level setting:

Auto Deployment will start as soon as it is enabled, however, subsequent Auto Deployments will occur automatically every day at 11 PM UTC.

Detection and Deployment

As with Smart Patching the AppInvRawData report is used to catalogue all application instances, comparing our detection name of each public application with the application names given by the report, and then by comparing the applications list in Intune to this to figure out whether the application is managed or unmanaged. The AppInstallStatusAggregate intune report is used as the Intune managed applications list. Any application that isn’t deployed in Intune and can be found in the AppInvRawData report will be considered to be unmanaged. We further distinguish between EA Managed Applications and Managed Applications, based on whether we can detect that the Intune application matches a deployed EA application in any repository. 

When an unmanaged application instance that matches the detection name of a public application is detected, then the corresponding public application is automatically deployed to Intune. 

The detection and deployment occurs every day at 11 PM UTC.

Integration with Auto Smart Patching 

If Auto Smart Patching is enabled for the subscription in which Auto Deployment is deploying an application, then the Smart Patching deployment strategy will be used. The Auto Smart Patch deployment schedule will be created if it does not exist, and it will be assigned to the application being deployed. The Auto Smart Patch deployment schedule for the application will then be started, deploying the Patch Application instance first and then the Base Application instance after the Auto Smart Patch deployment schedule has finished all its deployment phases, this is typically only 1 phase (the Smart Patch Phase) unless this deployment schedule has been customized by the end-user. 

If Auto Smart Patching is not enabled, then only Base Application instances will be deployed. The end-user must then as with any base application, configure the base application assignments on the application before this becomes useful. Therefore, it is recommended to enable Auto Smart Patching when using this feature. 

Auto Deployment Application Exclusions 

As with Smart Patching, applications can be excluded from being automatically deployed. Exclusions can be configured both on the MSP and the subscription level. 

Pictured above is the current list of apps that can be excluded and their exclusion state seen from an MSP’s point of view. Excluded apps will always appear at the top of the list. In the picture, iTunes is marked as excluded as it has the checkbox in the first column checked off. This means that the iTunes app will not be automatically deployed on any managed subscription, unless an explicit subscription-level setting overrides the MSP configuration. 

The shopping feature is designed with application and feature management in mind. The main purpose of the feature is to allow users to request applications from the portal shop.endpointadmin.com

Requesting an application from the shopping portal will kick off the approval process, which notifies the manager of the end user to approve the software. Administrators can also approve software.

View the article “Configure Shop Applications” on how to configure Shop Applications.

Please follow the guidelines below in order to approve a shopping request for your employee

Note: The acting manager for an end user is fetched from Azure.

Congratulations. You’ve now approved a shopping request for an employee.

All Application uploads should happen in ZIP format, and should be configured as described in this article.

Download a package from the public repository and use as a template, e.g. 7-Zip.

The following needs to be placed in the root of the zip file.

• Application Icon
  • PNG format
  • Between 256×256 pixels – 512×512 pixels
  • named ‘icon.png’
• Powershell Detection Script
  • Named ‘Detect-Application.ps1’
• Execution file

The following fields should be modified to reflect the contents

The purpose of manually approving applications is to ensure that the customer is in control of which applications are deployed to the customers environment. For example if auto update is configured with manual approve for a given application, the application needs to be approved manually by the customer before it is deployed to the customers environment.

The Approval system in Endpoint Admin, can be configured for either a single application or for all applications, and future uploaded applications.

If the Manual Approve property is set for a given application, the user will automatically discover a notification in the Approval tab, whenever a new version of an application is uploaded to Endpoint Admin.

This will ensure that new application versions without a Deployment Schedule assigned will require an approval before being updated in Intune.

The Base application instance in Intune will now be updated.

The Base application(s) instance(s) in Intune will now be updated.

Users have the option to deploy applications to the Intune tenant that is linked to the Endpoint Admin subscription. This can be done on a singular basis, or with a bulk action.

Important Notice! All applications uploaded to Endpoint Admin must follow the packaging guidelines. Click here to view the guidelines described. This can be simplified by using the Endpoint Admin Package Tool (Win32) app found in the Public Repository or using the web Package Tool

When adding a new version of an existing application, make sure the name of the new version is identical to the name of the old version. The version should also be higher than the old version.

Once the application is deployed to the Endpoint Manager (Intune) tenant, the application will modify metadata and content of the old version, to reflect the metadata and content of the new version. Existing assignments of the application in Endpoint Manager will be kept.

Important Notice! All applications uploaded to Endpoint Admin must follow the packaging guidelines. Click here to view the guidelines described.

the Auto Update feature ensures that your environment always receives the newest software updates from Endpoint Admin, as soon as they are released. Auto update is enabled for your subscription per default.

Auto updates upgrades the current version of the software in the Endpoint Admin portal to the newest version. Users have the option to, in parallel, select manual or automatic approval, to decide whether the software should in addition, be automatically be pushed to the subscription Intune tenant.

Applications that are up-to-date will be displayed with a green check mark icon next to the version number.

An application will display a yellow exclamation mark icon, if the current version in the Intune tenant is not the newest version available, from Endpoint Admin. This is because the application still requires approval in , Endpoint Admin by the user.

Note: The Manual Approve option, cannot be enabled if the Auto Update feature is disabled.

Disable/Enable Auto update for a single application

Disable/Enable Auto update for all current/future applications

There are two ways to create the integration with Intune. One option is to create an App Registration in your tenant manually and configure the required permissions yourself. Alternatively, you can use the guided integration, which will create the App Registration for you. If desired, you can use the guided integration and then manually remove any unnecessary permissions afterwards.

Below, you’ll find a list of the mandatory and optional permissions used in the integration.

Azure Active Directory Graph

Microsoft Graph

The optional permissions are used in the following Endpoint Admin features and can therefore be excluded if not in use:

• Application Shop
• Microsoft Store Apps
• Device Primary User alignment
• Resource Management
  • Ring Group Automation
  • Entra ID Groups

This document contains an overview of the Graph APIs and Permissions used by each Endpoint Admin feature in alphabetical order. 

Some features do not interact with the Graph API directly, or uses existing EA features that already interface with the Graph API to accomplish its goals, these may not be described here.

1. Agent Powered Metering

Use Cases with Requirements 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

2. Application Shopping

Use Cases with Requirements 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

3. Application Management

Use Cases 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

4. Application Reporting

Use Cases 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

5. Configuration Sets

Endpoint Admin Configuration Sets currently work by implementing a subset of the Application Management specification, specifically only the parts that relate to Win32 Lob Apps, as a Configuration Set is currently a generated Win32 LoB App. In the future, this may change to involve APIs and Use Cases that cannot be handled via Endpoint Admin Application Management. Currently just refer to section 3. Application Management.

6. Device Reporting

Use Cases 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

7. Entra ID Group Management

Use Case 

Users need to be able to configure most aspects of Entra ID groups to facilitate their usage in Endpoint Admin, herein creation, updating, deletion, adding members. Creation of groups is limited to Security Groups. Dynamic Device and Dynamic User groups are supported, as well as regular groups with assigned memberships. 

Microsoft Graph APIs 

8. Ring Group Automation

Ring group automation is an Endpoint Admin feature that allows you to construct groups that automatically spread users and devices across several rings of groups according to your definitions. From this a Deployment Schedule can be generated which deploys software according to your specifications. 

Currently Ring Group Automation uses a subset of the permissions and APIs as defined in section 7. Entra ID Group Management.

To enhance endpoint security and reduce the overall attack surface, some organizations choose to configure BitLocker with a pre-boot PIN. This adds an additional layer of protection by requiring user authentication before the operating system can boot. However, configuring a BitLocker PIN typically requires administrative privileges – permissions that standard users usually do not possess.

To address this, an application capable of prompting for a BitLocker PIN while running with the necessary elevated privileges is available in the Public Repository (app is called ‘BitLocker PIN Setup Prompt’) . This application will prompt the user to set a PIN if one has not already been configured.

Detection Logic

The application is designed to exit with a success code (used for detection purposes) if any of the following conditions are met:

• BitLocker PIN key protector already set.
• The device is currently in OOBE (Out-Of-Box Experience).
• A BitLocker PIN prompt is already running.
• No interactive user session is present.
• The system is not configured to require a BitLocker PIN, as determined by the following registry settings:
  • HKLM:\SOFTWARE\Policies\Microsoft\FVE
    • UseTPMPIN
    • UseTPM

If the system is configured to support Enhanced PINs, the prompt will adapt accordingly – both in terms of requiring alphanumeric input and matching the defined character span policy.

Deployment Script Parameters

The application supports two optional script parameters to modify prompt behavior:

• PromptCancelClosingWindow
  • When enabled, the user is prevented from closing the BitLocker PIN prompt window. This helps enforce PIN setup and ensures the security policy is applied without user circumvention.
• PromptUseCustomPSADTBanner
  • If enabled, the custom PowerShell App Deployment Toolkit (PSADT) banner will be displayed in the prompt, provided one has been deployed to the endpoint. This allows for a consistent user experience in environments using customized branding.

Configuration Sets provide a simple and powerful way to manage registry-based configurations directly from a graphical interface. With this feature, administrators can easily create, edit, and deploy registry settings for both machine and user contexts – without writing custom scripts.

Each Configuration Set is automatically packaged and published as a Win32 app in Intune, making deployment and version control seamless. This allows you to distribute configuration changes across devices just like any other managed application, with full Intune compliance and reporting support.

Coming soon: Support for file deployment, firewall configuration, and the ability to link Configuration Sets as application dependencies.

Find the page under Public, Private or MSP Repository

• The Assignment Profile is a feature that let users create a configuration logic for the Azure groups and save the configuration in a profile for more easily re-usability.
• An Assignment Profile requires only a name to be created, the group(s) can be added later to the Assignment Profile.
• An application can only be assigned to one Assignment Profile at a time.
• You have the option to create, delete, copy or edit an Assignment Profile after creating the Assignment Profile.
• The Assignment Profile has 3 group categories: “Required“, “Available“, “Uninstall“.
• To each Assignment Profile group category, you can add Azure groups.
• Azure groups can have the mode of “Included” or “Excluded“. An Azure group will be included, automatically, in the first assignment group category you add the Azure group to, but excluded if added to the rest. E.g.: you add the azure group “All users” first to the Assignment Profile group category “Required” and next to “Available”. It will be included in the first Assignment Profile group category “Required” but excluded in “Available”. You can manually change the to include mode for Assignment Profile group category, but it will be automatically excluded from rest.

Create a new Assignment Profile

To create a new Assignment Profile first you will have to access Assignment Profiles page under the applications tab in the sidebar menu.

On the Assignment Profile page, there will be a list containing all Assignment Profiles created with additional information like the number of applications that the profile is assigned to (1. Applications). The number of Deployment Schedules an Assignment Profile is used in (2. Deployment Schedules). And the last time it was updated (3. Last Updated).

To create a new Assignment Profile click on  the “+ New profile” button.

After clicking on the button “+ New profile” you will be redirected to another page where the Assignment Profile is created, and you can give the new Assignment Profile a name and optionally add Azure groups to the different assignment categories: Required, Available and Uninstall. Settings can be save using the save button.

After clicking on the “+ Add group” button under one of the 3 assignment categories, a popup will open where you can select the Azure groups that you want to be affected by the Assignment Profile.

It is important to know that each Azure group can only be added once as “Included” to one of Assignment Profile categories.

• For example, if we add the Azure group “All Users” to “Required” and “Available”, the “All users” will be included in the first assignment group “Required”, and excluded to the other assignment group “Available”. 

You have the option to manually include “All Users” in the second assignment group category “Available” where it was excluded before, but then it will be excluded from the first assignment group category “Required” automatically.

After creating a new Assignment Profile, you have the option to view details, copy, edit or delete the Assignment Profile, by clicking the 3 dots on the right side, to expand a meatball menu with the 4 options:

• First, the Details option: This will show the Assignment Profile in a read-only view, with no save button.
• Second, the copy options which will create a new Assignment Profile with the exact same groups selected and with the same name, but with no application assigned.
• Third, the edit option which opens the Assignment Profile and you can change its Azure groups or name.
• Fourth, is the Delete option that will delete the Assignment Profile.

Assign a profile to an application

Important, an application can have ONLY ONE Assignment Profile assigned at a time.

After the Assignment Profile is created, You can assign a Assignment Profile to an application, from the public and private repository page by clicking on the 3 dots on right side next of an application. This will expand the meatball menu.

• When you select the assign profile option from the meatball menu, it will open a new pop-up window with all the Assignment Profiles created on that subscription from which the you can choose
• You can ONLY assign a profile to deployed applications from private and public repositories. If the application is not deployed, the assign profile will be greyed out under the meatball menu.
• Another option is the “Clear Assignment Profile” which will remove the Assignment Profile from that application.
• When you have assigned a profile to an already deployed application, the name of the Assignment Profile will appear under the “Assignment Profile” column.
• After assignment, the “Assigned” state will change to “Yes” in the Intune that is integrated with your Endpoint Admin subscription.
• If you access the properties of the application, you can see the Assignments in Intune match the Assignment Profile in Endpoint Admin.
• If you choose to “Clear Assignment Profile” of an application the “Assigned” status in Intune will transition from “Yes” to “No” and it will clear Azure group from the application under Required, Available and Uninstall.

Microsoft is investing heavily in cloud-based solutions and this means that on-premises solutions will be phased out to a greater extent. This also comes to device management and therefore, more and more companies are embarking on their journey towards the cloud and all the benefits that come with it. To kick-start this transition, Microsoft has developed the concept or terminology called “Co-Mangement” where devices have the SMS Agent and Intune agent installed at the same time and where sub configurations in the form of workloads from ConfigMgr can be moved in phases to be managed in Microsoft Endpoint Manager  (Intune) instead. Co-Management will not be covered in this article, but you can read more about it in Microsoft docs. What is interesting about this technology is that we can move Windows patching to the cloud as a stand-alone element.

For handling mobile devices and desktops, Microsoft Endpoint Manager (Intune) is the way to go and is a technology under strong development. WSUS with SCCM, which many system administrators have used for patching PCs, is not an option in the future. For a replacement, Windows Update for Business (WUfB) is the solution. You can read more about WUfB here Microsoft docs.

There are many pros and cons between the two technologies – to boil it all down – WUfB with Endpoint Manager does not share the strict control that you get with SCCM with in-depth reporting and limitation of patches to computers using collections and where you distribute patches. But WSUS, on the other hand, is a heavy and old technology that will most likely not be developed much further.
Another challenge with WUfB is that all updates come from the cloud and you will put a lot of pressure on your WAN line if you do not make your rollout in phases. Especially in large enterprises with thousands of devices. This is exactly the the challenge RGA can solve.

“So how do we stay control when we move the workload from WSUS to WUfB?”

As stated in the Microsoft docs we can only limit patches and control the rollout on the client using CSP profiles to defer or pause updates – bummer… that means we must segregate devices into groups like collections in SCCM to control the configurations on the clients and stay in control and do phased rollouts.

In Endpoint Admin you can create a ring group automation profile (RGAP), with the desired configuration. A RGAP consist of a desired number of rings, scope, exclude, detection interval and prefix.

• A ring consist of device-only security group in Microsoft Entra ID. It is only device-groups because of limitation in the Intune assignment engine as it does not support include/exclude of mixed user and device groups.
• Each Ring can be divided into a desired number of subgroups to support staged rollout and limit WAN utilization.
• You can add both user-based or device-based groups to a ring. When a user is added to a ring, it is the user’s primary devices from Microsoft Entra ID which are added to the ring.
• RGAP Scope: The scope can be global, meaning all devices in the Microsoft Entra ID. Or you can select a group. If you use a group as a scope, only devices which are a member of the scope will be affected by RGA.
• Exclude: Groups can be excluded from the RGA. All devices and user’s primary devices which a member of a group added to exclude, will not be affected by RGA.
• Device objects can only be a member of one ring.
• A user can use the Endpoint Admin shop, to move their devices into a different ring.
• RGA will automatically create a “Final ring”. All devices in the scope for the RGA will automatically be added to the final ring, if their are not a member of any other ring in the RGA.
• Detection interval is how often the RGAP should be executed and update ring membership.
• Prefix: Groups create by the RGAP will be prefixed with the given prefix.

In this section we will show examples of how to create an RGAP and how to utilize it.

Global RGAP example

In this example, we will create a RGAP using the scope global to affect all devices in our Tenant. We create 3 rings and RGAP will automatically add the final ring.

1. In Endpoint admin under Resource Management, select Ring Group Automation:
   
2. Select New Profile in the top-right corner:
   
3. The New RGAP page will look like this:
   
4. Now we will configure the RGAP:
   1. Name of the RGAP.
   2. Prefix for the groups that will be created by the RGAP.
   3. Enable the RGAP.
   4. Detection interval, in this example the RGAP will run every 4 hour.
   5. Scope of the RGAP. We use Global, meaning all devices will be affected by this RGAP.
   6. Exclude: Here we have added the group Global-RGAP-Exclude. All members of this group will not be affected by the RGAP.
   7. Add ring, clicking this button will add a ring. We have added 3 rings. Remember the final ring is automatically added to RGAP.
   8. User Groups: Here we can add groups with user-based membership to each ring.
   9. Device Groups: Here we can add groups with device-based membership to each ring.
   10. Target Rollout Group Count. Use this to choose the number of device sub-groups the ring should be divide into.
   11. Rollout Groups: When the RGAP have run once the rollout group can be seen here.
       
5. In the next step we have added groups to Ring 1-3:
   1. In Ring 1, we have added the user-based group “IT Department” under User Groups.
   2. In Ring 2, we have added the device-based group “Device Test” under Devices Groups.
   3. In Ring 3, we have added the user-based group “All IT Managers” under User Groups.

• The Deployment Schedule will deploy a new version of a given application based on the Deployment Schedule configuration assigned to a given application when updated. This allows users to deploy a new version utilizing a phased roll-out.
• Each Deployment Schedule has a name, a number of phases and a trigger.
• A phase has a name, an Assignment Profile that will be assigned to the application when the phase becomes active, an offset in days and a requirement script. The requirement script allows to only install/patch the new version on devices that have the application installed already.
• The defined offset for the initial phase is derived from the trigger, the offset for the remaining phases is based off of the initial phase.
• If the requirement script radio button is toggled on, then the phase will affect only the users/devices where the requirement.ps1 script returns 1.
• The trigger for a deployment schedule will decide when and how a deployment schedule is initiated, there are 3 options:
  1. When a new version is uploaded: the Deployment Schedule will start whenever a newer version of that application is uploaded.
  2. Weekly: the Deployment Schedule will start every week on the day specified. This allows you to deploy all new application versions starting on a given day of the week.
  3. Monthly: the deployment schedule will start every month in a specified week day of one of the first 4 weeks at 00:00. E.g. (first Monday of the month or third Wednesday of the month).
• When creating a new deployment schedule, the name and the Assignment Profile for each existing phase is required.
• An application can have only 1 deployment schedule at any given time.
• An application has to be deployed or else you can not assign a deployment schedule to it.
• You can not have a deployment schedule with less than 1 phase.
• You can not have a deployment schedule with more than 28 phases.
• The number of phases depends on the offset and on the trigger option, those 2 above are the minimum and maximum limits.
• If the trigger is set on Weekly, the maximum number of phases can not exceed 7. This is to ensure patch capability when new updates are made more than once a week.

Smart Patching

Smart Patching can be enabled for a Deployment Schedule. This creates a final phase called a Smart Patch phase. The Smart Patch phase ensures that the application that the schedule is assigned to will only have devices assigned as Required if the devices are detected to have the application installed, as this is the final phase, it will be applied at the end of the Deployment Schedule. All devices that are not detected to have the application installed will not be assigned or have their assignments removed from the application using the schedule.

Smart Patching Background

Patching devices in Endpoint Admin depends on having a patch application instance that includes a requirement script. This setup ensures that only devices with the specific application already installed will be patched. As a result, even if a user installed the application through the Company Portal or by other means, it will still be patched.

To optimize device resource utilization, we identify which devices actually have the software installed, so we can limit the scope of the patch deployment to only those devices. The Installations Dashboard already has the ability to map a specific Endpoint Admin application to the Discovered Apps on each device. We use this data to create an Entra ID group which contains the devices known to have the application installed.

When this approach is applied only to the Patch Application instance, users can still uninstall available applications via the Base Application instance in the Company Portal. In such cases, the Patch Application won’t be applied because its requirement script will no longer detect the app as installed. Therefore, there’s no conflict – even if there’s a delay between when a user uninstalls an application and when their device is removed from the Smart Patch application group.

For the Smart Patch functionality to work, the application must be properly installed on the endpoint and appear in the “Add or Remove Programs” (appwiz.cpl) list. Otherwise, it won’t be reported in Intune’s Discovered Apps list, and we won’t be able to detect its installation. Since some applications don’t register themselves in this way, the Smart Patch solution won’t be applicable to all applications. 

To create a new deployment schedule, access the Deployment Schedule page under the Applications tab in the sidebar menu.

To create a new deployment schedule press the “+ New schedule” button.

Every new deployment schedule is initialized with 3 phases as default and the trigger is set to “On new version”. Here you can add a name to the deployment schedule, you can also change the number of phases, the name of the phases, and a given trigger.

Clicking on the “Set” button of the trigger, a modal will open presenting you with the 3 options as shown:

• When a new version is uploaded: the Deployment Schedule will start whenever a newer version of that application is uploaded.

• Weekly: the Deployment Schedule will start every week on the day specified. This allows you to deploy all new application versions starting on a given day of the week.

• Monthly: the deployment schedule will start every month in a specific weekday, of the first 4 weeks at 00:00. Example: every second Tuesday of the month.

NOTE: Make sure to use Assignment Profiles which is configured with required assignments, otherwise each phase will only make the path application available for the end users/devices.

After saving the Deployment Schedule, go to either Public or Private repository and select an application that is deployed already and go to its meatballs menu, there we can see 3 options for this feature:

1. Assign deployment schedule: assigns a deployment schedule to the application. You can not assign a deployment schedule to an application that is not deployed (base application), or already has a deployment schedule running.
2. Clear deployment schedule: unassigned the Deployment Schedule that was assigned and allow for the option to delete the patch application instance from Microsoft Endpoint Manager.
3. Delete patch-app instance(s): deletes the patch application(s) instance(s) from Microsoft Endpoint Manager.
   

In this example we will assign the Deployment Schedule “Evergreen” mentioned earlier for the “FileZilla” application. By clicking the Assign deployment schedule button a new modal will appear where you can assign the schedule.

After clicking on the select button, you can see that the name of the Deployment Schedule is shown in the column “Deployment Schedule” of the application in the table.

You can also see that the application has 2 more columns regarding the deployment schedule:

• Phase state:
  • InProgress indicates that the patch application is in the progress to be pushed and/or having setting the given Assignment Profile for the given phase.
  • Finished indicates that the patch application is finished being pushed and/or having setting the given Assignment Profile for the given phase.
• Current phase: specifies current phase

Now to initate the deployment schedule you need to add a newer version of “FileZilla”.

Because the trigger is set to “On new version” the first phase will be initiated when a new version is registered to the repository.

When uploading the new application version you are informed that it exist already, this will trigger the Deployment Schedule for the given application matching on name.

After uploaded a newer version of “FileZilla” you will be presented with a status icon, indicative of the  Deployment Schedule being in progress.

When the Deployment Schedule has started Endpoint Admin will create the app in Microsoft Endpoint Manager.

Microsoft Endpoint Manager will have the following application instances present during a Deployment Schedule:

1. Patch App instance: This app instance will be created and handled throughout the Deployment Schedule. On each phase the assignment will be changed(not merged) to the Assignment Profile configured for the given phase.
2. Old Patch App instance: This app instance is present during a Deployment Schedule and is replaced by the Patch App instance when the Deployment Schedule is complete.
3. Base application instance: The app instance present when deployed via Endpoint Admin, and is using the Assignment Profile assigned. This application instance is updated when a Deployment Schedules is complete or if Auto Update is enabled and no Deployment Schedule is assigned.

Microsoft Endpoint Manager will have the Base and Patch app instance present on a finished deployment schedule.

NOTE: If new versions of a given application arrives while a Deployment Schedule is running, the schedule will finish before starting a schedule of the newest version.

Smart Patching

Smart Patching can be enabled for a deployment schedule and automatically creates and maintains Microsoft Entra ID groups, (Smart Patch groups), to be used in Patch Application assignments that only target devices that already have the software installed. This is done by leveraging the “Discovered Apps report” as known in the Intune Portal, in code and Microsoft documentation known as the App Inventory Raw Data Report (AppInvRawData), to detect which devices have an application installed. 

Smart Patching is only compatible with Windows applications in the public repository, who appear in the AppInvRawData, this accounts for most Windows applications. If the application cannot be found using “appwiz.cpl” in Windows, then Smart Patching will not be available. Support for macOS applications is planned and coming soon. 

Smart Patch group creation and maintenance 

Applications in the public repository that are in use in your subscription and have a deployment schedule assigned on them with Smart Patching enabled on the deployment schedule, will automatically get a Smart Patch Entra ID group created. The memberships of each Smart Patch group will be reevaluated several times every day, currently between every 4^th and every 8^th hour. 

Endpoint Admin maintains a detection name for each application in our public repository; this name is compared to the name of the applications found for each device in the AppInvRawData report. Based on this a set of AAD Device IDs is created, these AAD Device IDs then must be converted into a new set of IDs that represent the corresponding Directory IDs for the devices, as device objects cannot be added directly to Entra ID groups using their AAD Device ID.  

The IDs of the member objects in the Smart Patch group are then compared to the set of IDs that were constructed from converting the AAD Device IDs in the AppinvRawData report to their corresponding Directory ID. All the current member IDs that are not in the set of IDs created based on the report data will have the membership of the object removed from the Smart Patch group to which the directory ID corresponds. All IDs in the set of IDs constructed from the report data that were not found in the set of IDs of current member objects of the Smart Patch group will have its corresponding AAD Device Objects added as members of the Smart Patch group. 

The membership of devices in Smart Patch groups can be limited by the user by accessing the Deployment Automation page and selecting a group to use as the Device Scope group for Smart Patching. This is explained in the section “Limiting Smart Patching group memberships to a set of devices”. 

Assignment of Smart Patch groups to the Public Patch Application 

When a Smart Patch-enabled deployment schedule is assigned to an application, the final deployment phase of this Deployment Schedule will update the assignment of the Patch Application in Intune to contain a group assignment target, targeting the Smart Patch group. 

Note that the Phase Accumulative setting on a deployment schedule is ignored when Smart Patching is used, so that only the Smart Patch group is assigned. This may be subject to change in the future. 

The first time a deployment schedule with Smart Patching enabled is assigned to an application a Smart Patch group will be created immediately; this group will remain empty until the automation described in the preceding section is triggered. This means that it can take between 4 and 8 hours before the memberships are in place. 

The Smart patch group is named in the following format: 

EA_SmartPatch_{DeployableItemType}_{OS_Type}_{ApplicationName}_ ({Application_ID}) _{GroupNumber} 

Where {DeployableItemType} can be one of Public, Private, MSP, Public Configuration Set, MSP Configuration Set, Private Configuration Set. In practice you will for the time being only see “Public”, as Configuration Sets do not support patching yet, and only public applications have their detection names configured as of now. 

{OS_Type} is one of “Windows” or “MacOs”. Currently you will only see Windows here as macOS is not supported by Smart Patching yet. 

{ApplicationName} will be the name of the application as seen in the Endpoint Admin repository that corresponds to the {DeployableItemType}. Custom names from subscription level metadata are not taken into account. 

{Application_ID} is Endpoint Admin’s internal ID of the application from our database. We put this there in case several applications in the same repository happen to share the same name, as doing so avoids a potential name collision, as it is in practice possible to maintain several versions of the same app in each repository with the same name. 

{GroupNumber} is a number that has been speculatively added to make it easier to perform phased/ring rollouts of patch applications in the future. Currently it is always “001”. 

Smart Patching – Simple Practical Example 

In this section, a step-by-step guide with commentary is provided to showcase and explain how Smart Patching is used in a concrete example. 

Step	Description	Context
1.	In order to begin with Smart Patching, we either need to create or find an existing Deployment Schedule that we want to add Smart Patching to. If you already have one, you can skip this part.
1. a	Navigate to the Deployment Schedules list in the sidebar of the Endpoint Admin Portal
1.b	Decision – Click on an existing schedule that you want to enable Smart Patching for (1.d) or create a new schedule (1.c)
1.c	Click the “New Schedule”-button
1.d	Click an existing schedule by pressing on its row
1.e	Enter a name for your new deployment schedule in the name text field in the top left.
1.f	On the right-hand side of the page below the “New phase”-button you will see the “Smart Patching”-toggle. Toggle this on now.
1.g	If you created a new schedule, you would see that three default patch phases were added. For a simple patching setup where the patch of an application is not rolled out in phases, these should be removed. Click the Remove button for each of the three phases. Ensure that Smart Patching has been toggled before attempting this, as otherwise you will not be able to remove the last phase as the UI enforces that there is at least one phase in a deployment schedule, in our case this should be the “Smart Patch Phase”.
1.h	Ensure that the “Offset”-setting of the Smart Patch Phase is set to 0, so that deployment of new patches will occur as soon as they are available. The “Offset”-setting really means offset in days from when the deployment schedule is triggered until the deployment phase starts. By default, the deployment schedule starts when a new version of the application is available.
1.i	Ensure the trigger for the deployment schedule is set to “On new version”, otherwse change this using the “Set”-button.
1.j	Finally, press the save button.
2.	Now we’re going to assign the deployment schedule to an application.  However, if you edited an existing deployment schedule and it was assigned to one or more applications, then you can skip step 2 and go to step 3. At this point applications that were already using the existing schedule that you updated, will have its Smart Patch groups created if they did not exist.  Continuing with step 2: Go to the public repository for windows applications by clicking on the navigation link in the sidebar under the section “public repository”.
2.a	Find a Windows application that you wish to assign the Smart Patching deployment schedule to. The application must have its base app deployed and not have any patching or deployment operation underway.
2.b	Click on the application row somewhere where there isn’t text or another UI element to open up the application sidebar, then click the “Actions”-button to open its dropdown menu, and click the “Assign deployment schedule”-button
2.c	Search for the “Smart Patch” deployment schedule or whichever name you gave it. Select the schedule in the list by clicking on it, and then click the “Select”-button in the modal.
2.d	Now the deployment schedule should be assigned on the application.
3.	Now we move on to starting the deployment schedule to deploy the patch app. If you don’t do this step, then the changes we have just made will first take effect the next time a new version of the app is uploaded to our systems.
3.a	Open the “Actions”-dropdown in the “General”-tab in the application sidebar of the application that has the deployment schedule you’ve enabled Smart Patching for. Find “Start deployment schedule”-button in the dropdown entries and click on it. You will be asked to confirm this action after clicking.
3.b	Now the patch app deployment will start shortly. The process of uploading the patch app to Intune can take a few minutes depending on the size of the application.  While we wait for this, we can open the “Assignments”-tab in the application sidebar and view the currently active assignments, and which deployment schedule phases are pending.
3.c	When the patch app deployment is complete, you will be able to see that the Smart Patch Group has been added as a Required assignment.
3.d	You can view the members of the Smart Patch Group and other details by clicking “Show more” on the assignment pictured in the last step, and then clicking on either the name or the ID of the group
3.e	You will now see the members tab of the Entra ID group inside our Entra ID group management module.  If this is the first time a Smart Patch deployment schedule has been applied to the application, then this list should be empty, and will be populated in at most 8 hours.
3.f	After at most 8 hours all devices that have the application installed should appear as members in the group.  In this test system only 1 device has it installed.  You can speed this process up yourself by adding the devices that you think already have the software installed to the group. The system will automatically clean up those that it determined not to have the application anyway as part of the Smart Patching automation that is completed at least every 8th hour.

Auto Smart Patching

Auto Smart Patching is a setting that can be enabled on an entire subscription, or as an MSP, you can set whether it should be enabled or disabled by default for all your managed subscriptions. By default, this is disabled / not active. 

Enabling Auto Smart Patching causes all currently deployed applications that do not already have a deployment schedule set to be evaluated for Smart Patching eligibility.  

When enabled, all eligible applications that do not have a deployment schedule will have a Smart Patching deployment schedule set on them that is automatically created by the Auto Smart Patching module, this deployment schedule is named “Auto Smart Patch” when created, it can however be renamed by the end user. The applications that had the automatically created deployment schedule set on them will then have their deployment schedule started to begin the process of patch application deployment to managed endpoints governed by Microsoft Intune. When this happens, Smart Patching proceeds for each application as described in the preceding Smart Patching section. 

Furthermore, when this feature is enabled, the end-user will always be asked if they would like to deploy an application using Smart Patching as the deployment strategy when they manually deploy an application. The user can choose whether they would like to only deploy the base application, or whether they would like to employ the Smart Patching deployment strategy, which then assigns the Auto Smart Patch deployment schedule to the application, deploys the patch application and then the base application. 

Configuring Auto Smart Patching

To configure Auto Smart Patching, you must access the Deployment Automation page, which can be found in the Application Management section of the Endpoint Admin Portal sidebar. 

From this page, you will see multiple settings. As an MSP, you will both be able to see the defaults set on an MSP-level and what the current settings are for the subscription you are currently viewing. 

To enable the setting for all managed subscriptions that are set to inherit this setting from the MSP you must switch the toggle on displayed below: 

By default, all managed subscriptions are set to inherit from the MSP, but this setting can also be controlled individually for each subscription. 

If you are not an MSP user or if you wish to control this on the subscription-level you can use the dropdown select menu outlined in red below to control the setting value for Auto Smart Patching: 

Auto Smart Patching Application Exclusions

As seen in the two images above, there is a button called “Manage App Exclusions”. Clicking this button will display a table of all applications in each repository which can be set to be excluded from automation. This excludes them both from Auto Smart Patching and Auto Deployment. Auto Deployment is documented later in this document. 

Exclusions can be configured both on the MSP-level and the subscription level. 

Setting an application to be excluded from automation means that they won’t be considered eligible for Auto Smart Patching or Auto Deployment. If the Auto Smart Patch deployment schedule is already assigned to an application that you have just excluded, it will be unassigned, and the patch application instance of the application will be deleted. 

Pictured above is the current list of apps that can be excluded and their exclusion state seen from an MSP’s point of view. Excluded apps will always appear at the top of the list. In the picture, iTunes is marked as excluded as it has the checkbox in the first column checked off. 

Having an application set as excluded does not prevent a user from manually assigning the Auto Smart Patch deployment schedule to an application

Limiting Smart Patching group memberships to a set of devices

For the purposes of preventing some devices from being patched or for testing Smart Patching with a limited set of devices, it is possible to configure a set of groups from which the devices considered for being added to a Smart Patching group will be based on, this can be done by clicking the “Manage Device Scope”-button.  

Pictured above is the modal UI presented when the aforementioned button is clicked. You can search for any group in the Entra ID tenant that is connected to your current subscription and select a group to use as the device scope group or remove the currently selected group used as the device scope. In this example, the group “CN-VM-GRP” is selected. This means that only devices within the group CN-VM-GRP will be eligible to be in any Smart Patch group. If you already have devices in existing Smart Patch groups, then these will be removed when the automation runs every 4^th or 8^th hour if they are not in the selected device scope group. 

This group can be a group with nested groups in it containing devices as transitive membership API calls are used to collect all the IDs of the members. 

Auto Deployment, or shortened Auto Deploy, is a setting that controls whether unmanaged applications detected on managed devices which have a corresponding application in our public repository should be automatically deployed so that the unmanaged application becomes a managed application. This setting is disabled by default, and for subscriptions managed by an MSP the default setting is to inherit the setting value from the MSP-level configuration. 

Auto Deployment is currently only available for Windows applications, however, support for macOS applications is planned and coming soon. 

You can configure this setting by accessing the Deployment Automation page inside the Application Management section of the Endpoint Admin portal, as with Auto Smart Patching. 

To access the Deployment Automation page, find Application Management in the sidebar of the portal, expand it and click on the Deployment Automation entry: 

From here you can either change the MSP-level setting and the subscription-level setting for your current subscription, if you are an MSP user, or if you are a non-MSP user you can only change the subscription-level setting for your current subscription: 

Pictured above is the subscription-level setting. Below is the U.I. for the MSP-level setting:

Auto Deployment will start as soon as it is enabled, however, subsequent Auto Deployments will occur automatically every day at 11 PM UTC.

Detection and Deployment

As with Smart Patching the AppInvRawData report is used to catalogue all application instances, comparing our detection name of each public application with the application names given by the report, and then by comparing the applications list in Intune to this to figure out whether the application is managed or unmanaged. The AppInstallStatusAggregate intune report is used as the Intune managed applications list. Any application that isn’t deployed in Intune and can be found in the AppInvRawData report will be considered to be unmanaged. We further distinguish between EA Managed Applications and Managed Applications, based on whether we can detect that the Intune application matches a deployed EA application in any repository. 

When an unmanaged application instance that matches the detection name of a public application is detected, then the corresponding public application is automatically deployed to Intune. 

The detection and deployment occurs every day at 11 PM UTC.

Integration with Auto Smart Patching 

If Auto Smart Patching is enabled for the subscription in which Auto Deployment is deploying an application, then the Smart Patching deployment strategy will be used. The Auto Smart Patch deployment schedule will be created if it does not exist, and it will be assigned to the application being deployed. The Auto Smart Patch deployment schedule for the application will then be started, deploying the Patch Application instance first and then the Base Application instance after the Auto Smart Patch deployment schedule has finished all its deployment phases, this is typically only 1 phase (the Smart Patch Phase) unless this deployment schedule has been customized by the end-user. 

If Auto Smart Patching is not enabled, then only Base Application instances will be deployed. The end-user must then as with any base application, configure the base application assignments on the application before this becomes useful. Therefore, it is recommended to enable Auto Smart Patching when using this feature. 

Auto Deployment Application Exclusions 

As with Smart Patching, applications can be excluded from being automatically deployed. Exclusions can be configured both on the MSP and the subscription level. 

Pictured above is the current list of apps that can be excluded and their exclusion state seen from an MSP’s point of view. Excluded apps will always appear at the top of the list. In the picture, iTunes is marked as excluded as it has the checkbox in the first column checked off. This means that the iTunes app will not be automatically deployed on any managed subscription, unless an explicit subscription-level setting overrides the MSP configuration. 

The shopping feature is designed with application and feature management in mind. The main purpose of the feature is to allow users to request applications from the portal shop.endpointadmin.com

Requesting an application from the shopping portal will kick off the approval process, which notifies the manager of the end user to approve the software. Administrators can also approve software.

View the article “Configure Shop Applications” on how to configure Shop Applications.

Please follow the guidelines below in order to approve a shopping request for your employee

Note: The acting manager for an end user is fetched from Azure.

Congratulations. You’ve now approved a shopping request for an employee.

All Application uploads should happen in ZIP format, and should be configured as described in this article.

Download a package from the public repository and use as a template, e.g. 7-Zip.

The following needs to be placed in the root of the zip file.

• Application Icon
  • PNG format
  • Between 256×256 pixels – 512×512 pixels
  • named ‘icon.png’
• Powershell Detection Script
  • Named ‘Detect-Application.ps1’
• Execution file

The following fields should be modified to reflect the contents

This will ensure that new application versions without a Deployment Schedule assigned will require an approval before being updated in Intune.

The Base application instance in Intune will now be updated.

The Base application(s) instance(s) in Intune will now be updated.

Important Notice! All applications uploaded to Endpoint Admin must follow the packaging guidelines. Click here to view the guidelines described. This can be simplified by using the Endpoint Admin Package Tool (Win32) app found in the Public Repository or using the web Package Tool

When adding a new version of an existing application, make sure the name of the new version is identical to the name of the old version. The version should also be higher than the old version.

Once the application is deployed to the Endpoint Manager (Intune) tenant, the application will modify metadata and content of the old version, to reflect the metadata and content of the new version. Existing assignments of the application in Endpoint Manager will be kept.

Important Notice! All applications uploaded to Endpoint Admin must follow the packaging guidelines. Click here to view the guidelines described.

This document contains an overview of the Graph APIs and Permissions used by each Endpoint Admin feature in alphabetical order. 

Some features do not interact with the Graph API directly, or uses existing EA features that already interface with the Graph API to accomplish its goals, these may not be described here.

1. Agent Powered Metering

Use Cases with Requirements 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

2. Application Shopping

Use Cases with Requirements 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

3. Application Management

Use Cases 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

4. Application Reporting

Use Cases 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

5. Configuration Sets

Endpoint Admin Configuration Sets currently work by implementing a subset of the Application Management specification, specifically only the parts that relate to Win32 Lob Apps, as a Configuration Set is currently a generated Win32 LoB App. In the future, this may change to involve APIs and Use Cases that cannot be handled via Endpoint Admin Application Management. Currently just refer to section 3. Application Management.

6. Device Reporting

Use Cases 

Microsoft Graph APIs 

Use Cases and APIs Used to Perform Use Case 

7. Entra ID Group Management

Use Case 

Users need to be able to configure most aspects of Entra ID groups to facilitate their usage in Endpoint Admin, herein creation, updating, deletion, adding members. Creation of groups is limited to Security Groups. Dynamic Device and Dynamic User groups are supported, as well as regular groups with assigned memberships. 

Microsoft Graph APIs 

8. Ring Group Automation

Ring group automation is an Endpoint Admin feature that allows you to construct groups that automatically spread users and devices across several rings of groups according to your definitions. From this a Deployment Schedule can be generated which deploys software according to your specifications. 

Currently Ring Group Automation uses a subset of the permissions and APIs as defined in section 7. Entra ID Group Management.

To enhance endpoint security and reduce the overall attack surface, some organizations choose to configure BitLocker with a pre-boot PIN. This adds an additional layer of protection by requiring user authentication before the operating system can boot. However, configuring a BitLocker PIN typically requires administrative privileges – permissions that standard users usually do not possess.

To address this, an application capable of prompting for a BitLocker PIN while running with the necessary elevated privileges is available in the Public Repository (app is called ‘BitLocker PIN Setup Prompt’) . This application will prompt the user to set a PIN if one has not already been configured.

Detection Logic

The application is designed to exit with a success code (used for detection purposes) if any of the following conditions are met:

• BitLocker PIN key protector already set.
• The device is currently in OOBE (Out-Of-Box Experience).
• A BitLocker PIN prompt is already running.
• No interactive user session is present.
• The system is not configured to require a BitLocker PIN, as determined by the following registry settings:
  • HKLM:\SOFTWARE\Policies\Microsoft\FVE
    • UseTPMPIN
    • UseTPM

If the system is configured to support Enhanced PINs, the prompt will adapt accordingly – both in terms of requiring alphanumeric input and matching the defined character span policy.

Deployment Script Parameters

The application supports two optional script parameters to modify prompt behavior:

• PromptCancelClosingWindow
  • When enabled, the user is prevented from closing the BitLocker PIN prompt window. This helps enforce PIN setup and ensures the security policy is applied without user circumvention.
• PromptUseCustomPSADTBanner
  • If enabled, the custom PowerShell App Deployment Toolkit (PSADT) banner will be displayed in the prompt, provided one has been deployed to the endpoint. This allows for a consistent user experience in environments using customized branding.