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.

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 occurs when the connector runs, and is only ever applied to the applications in the Pending Queue. To normalise applications with any status, select the applications, then use the ACE Normalisation button in the ribbon.

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. The main setting which applies in this scenariois 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 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 same application are detected. 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

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 Vendors such as Google (where the major version of their products are incremented regularly) to be handled automatically. The Active column is generally set to Suggest which will allow the rationalisation suggestions to be shown in the Rationalisation UI rather than be automated in the background (the Active setting)

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