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 meatballs 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 meatballs menu.

• When you select the assign profile option from the meatballs 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 meatballs 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 when installed. 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.

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: unassigns 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 following application instances present after a finished schedule:

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.

	Approve Shop Request
1.1	Go to shop.endpointadmin.com/requests
1.2	If there are any shop requests pending your approval they will be listed.
1.3	Press approve or deny. The end user will be notified.
1.4	Whenever an end user that you are manager for requests an application, you will be notified via e-mail.

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:

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

Example of ZIP file

Example of a Configuration.xml 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.

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.

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 larger 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.

1	Go to the ‘Private Repository‘ under the ‘Applications‘ section.
2	Review the old version of the application.
3	Choose the option ‘New application‘.
4	Choose a .zip file or drag and drop a .zip file containing the documented [application package guidelines], and select ‘Continue‘ when the transfer has finished.
5	Review the metadata, and confirm that it is correct. If anything is misconfigured, please modify the ‘Configuration.xml’ file in the zipped folder, and re-upload the package. Choose the ‘Add application‘ option.   NOTE: 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 larger than the old version.
6	The application has now been uploaded to your Private Repository. Note: Until the application has been approved, and synced to your Endpoint Manager (Intune) tenant, it will be marked as ‘Not up to date’. This usually takes between 1-10 minutes, based on application size.
7	The application is now ready to be Approved & Deployed
8	After the application has been Deployed, the checkmark will turn green, and the application will be visible in Endpoint Manager (Intune)

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

1	Go to the ‘Private Repository‘ under the ‘Applications‘ section.
2	Choose the option ‘New application‘.
3	Choose a .zip file or drag and drop a .zip file containing the documented [application package guidelines], and select ‘Continue‘ when the transfer has finished.
4	Review the metadata, and confirm that it is correct. If anything is misconfigured, please modify the ‘Configuration.xml’ file in the zipped folder, and re-upload the package. Choose the ‘Add application‘ option.
5	The application is now ready to be Approved & Deployed

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 checkmark 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

1

In the Applications menu, for the application you want to disable/enable Auto Update, click the “Auto Update” radio button.

Disable/Enable Auto update for all current/future applications

1	In the Applications menu, select to disable/enable auto update by clicking the radio button.
2	Choose the continue option after evaluating the consequences. Note: Future applications are also impacted by this change, and single applications can afterwards be configured singularly to  have auto update disabled/enabled.

• 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 meatballs 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 meatballs menu.

• When you select the assign profile option from the meatballs 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 meatballs 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.

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: unassigns 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 following application instances present after a finished schedule:

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.

	Approve Shop Request
1.1	Go to shop.endpointadmin.com/requests
1.2	If there are any shop requests pending your approval they will be listed.
1.3	Press approve or deny. The end user will be notified.
1.4	Whenever an end user that you are manager for requests an application, you will be notified via e-mail.

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:

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

Example of ZIP file

Example of a Configuration.xml file.

The following fields should be modified to reflect the contents

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

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 larger 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.

1	Go to the ‘Private Repository‘ under the ‘Applications‘ section.
2	Review the old version of the application.
3	Choose the option ‘New application‘.
4	Choose a .zip file or drag and drop a .zip file containing the documented [application package guidelines], and select ‘Continue‘ when the transfer has finished.
5	Review the metadata, and confirm that it is correct. If anything is misconfigured, please modify the ‘Configuration.xml’ file in the zipped folder, and re-upload the package. Choose the ‘Add application‘ option.   NOTE: 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 larger than the old version.
6	The application has now been uploaded to your Private Repository. Note: Until the application has been approved, and synced to your Endpoint Manager (Intune) tenant, it will be marked as ‘Not up to date’. This usually takes between 1-10 minutes, based on application size.
7	The application is now ready to be Approved & Deployed
8	After the application has been Deployed, the checkmark will turn green, and the application will be visible in Endpoint Manager (Intune)

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

1	Go to the ‘Private Repository‘ under the ‘Applications‘ section.
2	Choose the option ‘New application‘.
3	Choose a .zip file or drag and drop a .zip file containing the documented [application package guidelines], and select ‘Continue‘ when the transfer has finished.
4	Review the metadata, and confirm that it is correct. If anything is misconfigured, please modify the ‘Configuration.xml’ file in the zipped folder, and re-upload the package. Choose the ‘Add application‘ option.
5	The application is now ready to be Approved & Deployed