Unsupported changes detected in Sync Rule Change script

[dbird03]

I'm currently performing a swing migration to a newer version of AAD Connect. I have the latest version of AAD Connect installed and in staging mode on the new server at the moment. I used the AADConnectConfigDocumenter tool, and the report shows a lot of red changes and a few green changes between my Target/Pilot configuration on my current server and the Reference/Production configuration on the new server. Many of the red changes are in the Transformations/Target (MV) Attributes section of the built-in synchronization rules.

I downloaded the Sync Rule Changes script from the top of the report, and the script shows all of the synchronization rules with changes have a warning message that "unsupported changes have been detected". This warning message appears on inbound and outbound rules for both on-prem AD and Azure AD. I've included two of the rules below with our domains changed to contoso.com and contoso.onmicrosoft.com for security purposes.

My question is what could have caused these unsupported changes to be made to the out-of-box default rules, and is there any guidance for what to do in this scenario? Should I manually make the 200+ changes detected in the report to the Reference config since the Sync Rule Change script cannot make the changes, or should I leave the changes alone? Are the changes due to different versions of AAD Connect being compared?

#############################################################################################################################################
#### 'contoso.com' - 'Out to AD - User Exchange Hybrid'
#############################################################################################################################################

$connectorName = 'contoso.com'
$syncRuleName = 'Out to AD - User Exchange Hybrid'
Write-Warning("The sync rule '{0}' for the connector '{1}' has unsupported chanages detected." -f $syncRuleName, $connectorName)
Write-Warning ("Only supported change to an out-of-box default rule is to make it `"Disabled`".")
Write-Warning ("If only the precedence number is different for this out-of-box rule, this warning may be safely ignored.")

#############################################################################################################################################
#### 'contoso.onmicrosoft.com - AAD' - 'Out to AAD - User Join'
#############################################################################################################################################

$connectorName = 'contoso.onmicrosoft.com - AAD'
$syncRuleName = 'Out to AAD - User Join'
Write-Warning("The sync rule '{0}' for the connector '{1}' has unsupported chanages detected." -f $syncRuleName, $connectorName)
Write-Warning ("Only supported change to an out-of-box default rule is to make it `"Disabled`".")
Write-Warning ("If only the precedence number is different for this out-of-box rule, this warning may be safely ignored.")

[NileshGhodekar]

Hi @dbird03,

One reason is: Write-Warning ("If only the precedence number is different for this out-of-box rule, this warning may be safely ignored.") This category should cover 95% cases.

A small percentage of warnings are reported is when you are comparing against a newer version, the OOB rules may have been updated by the product itself instead of by the customer. Tool has no way of knowing this. If in your review of the report and if you determine that it's not you, then you can ignore them. If it's indeed you, then you need to create your own custom rules with higher precedence than modifying the OOB rules.

[dbird03]

Hi @NileshGhodekar, thank you for your reply. I figured the tool has no way of knowing these details, but thank you for confirming this.

The person who created the Target/Pilot config is unfortunately no longer with the company, so I have no way of knowing for sure if they modified the OOB rules or not. I would lead towards they did not modify them, only because the report identified three custom inbound rules existed in the Target/Pilot config. This leads me to believe the person was aware of the best practice of creating custom rules with a different precedence as you mentioned. I had no trouble exporting and importing these custom rules to the Reference/Production config.

Aside from a person modifying the OOB rules or an updated version of AAD Connect modifying the OOB rules, is there anything else that is capable of modifying the OOB rules which may explain the changes in my report? I did check the version release history for AAD Connect to see if any changes highlighted in my report were mentioned in the release notes since the version of AAD Connect on our old server, but I did not see anything. Have I exhausted all of my options at this point for trying to explain why these changes exist between the configs?

[NileshGhodekar]

If you have the option of setting up a throwaway server where you could install the same AADC version as that on the current old server, you can generate the report and doubly confirm that there are no changes to OOB rules and conclusively prove that any changes to the OOB rules are solely due to newer AADC version. You could also review the CSExportAnalyser output on the new server and confirm that there are no unexpected updates to the attributes.

[dbird03]

@NileshGhodekar Thank you for that suggestion. I had briefly looked in to CSExportAnalyser, but didn't get too deep in to it. I like the idea of spinning up a test server and installing the same version of AAD Connect as our current old server to have a baseline for comparing the OOB rules against. I hadn't considered that.

I've had an Azure support case open for this as well, but the support engineer was not able to provide assistance. Since my last reply to this GitHub issue, I was contacted by a more knowledgeable support engineer to review my report with me. He was able to assure me the changes were minor changes due to the version of AAD Connect and nothing to be concerned about, so I am going to close this issue. I appreciate your insight in to this. If I am ever in a similar situation again and don't feel confident about the configs, I will definitely consider spinning up a test server as you suggested.