TABLE OF CONTENTS

• ACE:AI Status
  • Run ACE Examination Now
  • Sync With MS ACE Server Now
  • Periodically Sync MS ACE Server
• Automatically Normalise App Names
• ACE Based Rationalisation: Applications with an ACE recommendation vs Those Without
  • Applications with an ACE recommendation
    • Manual Rationalisation
    • Automatic Rationalisation
      • Accept/Rationalise to Higher Versions
      • Rationalise to Lower Versions
      • Reject
  • Applications without an ACE recommendation
    • Application Specific Rules
    • Rationalisation Rules
      • Rationalise to Higher Versions
      • Rationalise to Lower Versions
    • Acceptance Rules
      • Accept Apps Catch-All
    • Rejection Rules
      • Reject Apps Catch-All
• Device OS End of Life
  • Overview
  • Setup
    • Support Date Configuration
    • EoL Flag
• Application Link Deduplication
  • Overview
  • How It Works
  • Setup
    • Group Apps By
    • Reject Links
      • User‑App Links, Per Device
      • User‑App Links, Any Device
      • Device‑App Links, Per User
      • Device‑App Links, Any User
    • Scan Mode
    • Link to Retain
    • Rule Ordering
  • Testing a Rule
  • Max Links to Process
• Version Thresholds Reference
  • *.*.*.*
  • Major.*.*.*
  • Major.Minor.*.*
  • Major.Minor.Build.*

Refer to this article for the ACE Connector installation process.

ACE:AI Status

Run ACE Examination Now

Starts an ACE examination that will update the rationalisation and normalisation recommendations available from the Grid Context Menu. Also, will run any automatic actions that have been enabled in the ACE Engine. This can be scheduled if required.

Sync With MS ACE Server Now

This button with trigger an upload of a list of applications and their status to the ACE server, and download a list of recommendations.

Periodically Sync MS ACE Server

This option configures ManagementStudio to automatically refresh the application rationalisation recommendations around once per week. It requires access to https://services.managementstudio.cloud.

Automatically Normalise App Names

Normalisation is the process of cleaning up applications names and making them consistent across multiple products from the same vendor.

Note: Auto-normalisation occurs when the connector runs, and is only ever applied to the applications in the Pending Queue. Normalising applications in Accepted/Rejected/Rationalised is a manual process. Select the applications, then use the ACE Normalisation button in the ribbon or in the right-click menu.

ACE Based Rationalisation: Applications with an ACE recommendation vs Those Without

Applications which have been processed by other customers will have an ACE recommendation. Those which haven't won't. The figure below shows how these applications are handled and which settings & rules will be applied.

Applications with an ACE recommendation

There are two ways to rationalise applications which have an ACE recommendation: manual and automatic.

Manual Rationalisation

By selecting specific records in the Applications grid, it's possible to make manual rationalisation decisions with recommendations from the ACE:AI engine. The main setting which applies in this scenariois ACE UI Version Threshold.

The ACE UI Version Threshold controls the recommendations presented in the ACE:AI window. For example, the default setting of Major.*.*.* will recommend rationalising all 11.x records of this application to the highest 11.x version:

However, setting the ACE UI Version Threshold to *.*.*.* will rationalise ALL versions (11.x, 12.x, 13.x etc) to the single highest version of the application.

The ACE Rationalisation Group On setting controls how sets of the application vendors and names are matched. In most cases this should be set to Normalised App Name.

For usage instructions on manual rationalisation with ACE refer to this article.

Automatic Rationalisation

When the button Run ACE Examination Now is clicked, or is run on a schedule, the settings in this section will be used to automatically rationalise the applications. Note that this will only be performed on the Pending applications.

Accept/Rationalise to Higher Versions

Auto-accept/rationalise applications that are recommended as Accept in ACE, have at least X Users, and are Y days in Pending. The Higher Threshold is used to either rationalise these Apps to higher versions of existing applications in the Accepted queue or accept them as new applications if a higher version doesn't exist.

Rationalise to Lower Versions

Auto-rationalise applications that have a lower version in the Accepted queue, have at least X Users, and are Y days in Pending. The Lower Threshold is used to either rationalise these Apps to the highest of the lower Accepted versions or accept them as new applications. 

Reject

Auto-reject applications that are recommended as Reject by ACE, have at most X Users and are Y days in Pending

Applications without an ACE recommendation

If an application doesn't have an ACE recommendation (typically this mean no other customer has processed this application; it may be a rarely used app or in-house developed) they will be considered for processing by the rules in this section. 

Application Specific Rules

These rules provide a way of overriding the default rationalisation suggestions with explicit exceptions. 

For examples of Application Specific Rules see here: ACE:AI - Examples

Rationalisation Rules

Rationalise to Higher Versions

Where ACE does not have a recommendation for an application, this setting controls how the application will be auto-rationalised to higher versions. 

* It's assumed that the Pending App passes the Min. Num of Users and Days in Pending Queue filters

Rationalise to Lower Versions

Where ACE does not have a recommendation for an application, this setting controls how the application will be auto-rationalised to lower versions. 

* It's assumed that the Pending App passes the Min. Num of Users and Days in Pending Queue filters

Acceptance Rules

Accept Apps Catch-All

This setting controls how pending applications without an ACE recommendation are auto-accepted. Controls are available for the minimum number of users, the Version Threshold and the number of days the application has been in the Pending Queue. It is recommended to keep the Version Threshold at Major.*.*.* so that only new major versions of applications can get auto-accepted. In the screenshot above, only Pending applications that have over 10 Users, have been 28 days in Pending, and have no matching Major version will be auto-accepted.

Rejection Rules

Reject Apps Catch-All

This setting controls how pending applications without an ACE recommendation are rejected. Controls are available for the maximum number of users and the number of days the application has been in the Pending Queue. The recommended settings are shown in the screenshot above. These ensure that only applications with very few users which have been in the Pending Queue for at least 28 days will be auto-rejected. Note that applications which have been auto-rejected can be retrospectively accepted (or set to any other rationalisation status) manually if required. 

Device OS End of Life

Overview

The Device OS End of Life (EoL) feature helps you automatically identify devices in your environment that are running operating systems or builds that are no longer supported by Microsoft, Apple, or Google. This ensures you can proactively manage risk, plan upgrades, and maintain compliance.

When enabled, the system:

• Checks every device’s OS and build number
• Compares it against vendor lifecycle data
• Logs the results for review
• (Optionally) Sets an EoL flag on the device record for reporting or automation

Setup

When a tick is placed in Enabled Device OS End of Life Examination the Connector will automatically examine devices. Note that this depends on the OS build version detail being present.

Support Date Configuration

Under Base OS End of Life on Date, the lifecycle milestone the system should use can be chosen.

GA Support Date

• GA = General Availability
• Uses the standard support lifecycle
• Best for environments that follow mainstream support timelines

LTS Support Date

• LTS = Long-Term Support
• Uses extended support timelines
• Useful for organisations that rely on LTS releases

GA Security Date

• Uses the date when security updates stop for GA releases
• Good for security‑focused environments

LTS Security Date

• Uses the date when security updates stop for LTS releases
• Strictest option for long‑term deployments

Tip: Most organisations use GA Support Date unless they specifically deploy LTS builds.

EoL Flag

Set EoL Flag on Device

When enabled, any device identified as out‑of‑support will have a flag set on its device record.
This allows:

• Reporting
• Filtering
• Automated actions (e.g., alerts, remediation workflows)

If you only want to review the log without marking devices, leave this unchecked.

Application Link Deduplication

Overview

The Application Link Deduplication feature within the ACE connector is designed to prevent User Migration and Device records from becoming cluttered with duplicate application links, particularly for applications that update frequently such as web browsers. By intelligently analysing pending app links and retaining only the most relevant version (generally the most recently used) this feature helps reduce noise, and streamline application management.

When new versions of applications are released regularly, multiple versions of the same application can accumulate in a user’s or device’s linked Pending apps. Over time, this leads to:

• Redundant app links  
• Confusion over which version should be deployed  
• Increased processing time  
• Unnecessary clutter in User Migration and Device records

The Application Link Deduplication feature resolves this by automatically identifying duplicate app links and keeping only the most appropriate one.

How It Works

The system reviews each User Migration or Devices application links (Pending applications only). It then:

1. Groups multiple versions of applications together 
2. Identifies Pending applications with multiple versions linked to User Migrations or Devices
3. Rejects all but one of the links for each application - typically the highest version or most recently used version  

Only app links in the Pending queue are impacted. Links in other queues such as Accepted are assumed to have already undergone decision-making and are therefore not modified.

Setup

Each deduplication rule can be customised using the following fields:

Group Apps By

Determines the application matching rules:

• Ignore: Turns off the rule
• ACE Name: Uses the normalised vendor and application name for matching (recommended)
• App Name: uses the original application vendor and name for matching  

Reject Links

The Reject Link setting determines which types of application links the deduplication process should remove. Because ACE can manage links at both the user and device level, and because links can be associated in different scopes, this setting ensures administrators have precise control over what is eligible for rejection.

Each option defines where the link originates and how it is scoped. Understanding these distinctions is essential for safe and predictable deduplication.

User‑App Links, Per Device

• Targets User-App links
• Considers each device individually

If a user has been using different versions of the same application across multiple device, this deduplication rule will retain a single user-app link for every machine. This will result in the user record having multiple links to different version of the same application.

User‑App Links, Any Device

This is the recommended setting for most environments. 

• Targets User-App links
• Considers all devices during deduplication

If a user has been using different versions of the same application across multiple devices, this deduplication rule will only retain a single user-app link across all the machines. This will result in all but one of the application links from being rejected.

Device‑App Links, Per User

• Targets Device-App links
• Considers each user individually

If a device is linked to different versions of the same application from multiple users, this deduplication rule will retain a single device-app link for every user. This will result in the device record having multiple links to different version of the same application.

Device‑App Links, Any User

• Targets Device-App links
• Considers all users during deduplication

If a device is linked to different versions of the same application from multiple users, this deduplication rule will only retain a single device-app link across all the users. This will result in all but one of the application links from being rejected.

Scan Mode

Controls how the rule behaves during execution:

• Standard: The rule actively deduplicates links  
• Test: The rule simulates deduplication without making changes  

Only one rule can be in **Test** mode at a time.

Link to Retain

Defines which version of the app should be kept:

• Last Used Date: Retains the link with the most recent usage date
• Highest Version (ACE): Retains the link with the highest application version 

Rule Ordering

Rules can be reordered using the up/down arrows. The system processes rules from top to bottom.

Testing a Rule

Clicking Test a Rule allows administrators to validate a rule before enabling it in production. When a rule is set to Test mode:

• ACE runs the deduplication logic in a non-destructive manner  
• The ACE:AI Log window shows which links would have been rejected  
• Administrators can review the output to confirm the rule behaves as expected  

Important:

If any rule remains in Test mode, the entire Link Deduplication process will operate in test mode, even when triggered manually or via a scheduled run. All rules should be returned to Standard mode after testing.

Max Links to Process

The Max links to process at a time setting defines the upper limit of app links the system will evaluate in a single run. This prevents excessive processing loads in large environments. The default value is 50,000.

Version Thresholds Reference

Version Thresholds provide a way to control which versions of pending applications the ACE engine will operate on.

*.*.*.*

This setting is NOT recommended as ALL versions are matched to a single version. This is generally too "aggressive" when considering application rationalisation and other processes which use Version Thresholds.

Major.*.*.*

This setting is recommended for most scenarios as each minor version is rolled-up into the highest major version (the part in bold).

Major.Minor.*.*

Major.Minor.Build.*