Refer to this article for the ACE Connector installation process. 

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

Normalise App Names

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

Note: Auto-normalisation is only run on applications in the Pending Queue. To run this on applications in any queue, use the ACE Recommendations button in the Applications grid.

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 will be applied.

There are two ways to rationalise applications using ACE: 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 engine. There is one setting which applies in this scenario: ACE UI Version Threshold.

The ACE UI Version Threshold controls the recommendations presented in the ACE window. For example, the default setting of Major.*.*.* will recommend the following rationalisation:

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

Application Specific Rules

Where an application's versioning system doesn't match the criteria set in the Higher Threshold and Lower Threshold versions above, additional rulesets can be added. This allows applications such as Chrome and Edge (where the major version is incremented regularly) to be handled automatically in the background. Note that the settings here only apply when the automatic rationalisation process runs; they are used when applications are manually rationalised in the ACE UI.

Rules Where the Application Does Not Match Any of the ACE Criteria

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. 

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. 

Version Thresholds 

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