Issues with Upgrading to AAD Connect 1.1.524.0

On 15 May 2017, the latest version of AAD Connect (1.1.524.0) was released.  If you were not aware, when AAD Connect is upgraded to this version, the sync cycle may get set to “False” AAD Connect will not sync to O365.

In the past week, I’ve upgraded AAD Connect from varying versions to version 1.1.524.0 in 4 separate environments and all have experienced the same issue.

Additionally, after re-enabling the sync cycle, the next scheduled sync may not run either.

Be sure to check the value for SyncCycleEnabled, after the upgrade.  If it is set to “false”, it needs to be corrected.

PS C:\Users\Administrator> Get-ADSyncScheduler

AllowedSyncCycleInterval            : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 00:30:00
CustomizedSyncCycleInterval         : 01:00:00
NextSyncCyclePolicyType             : Delta
NextSyncCycleStartTimeInUTC         : 5/26/2017 9:28:12 PM
PurgeRunHistoryInterval             : 7.00:00:00
SyncCycleEnabled                    : False
MaintenanceEnabled                  : True
StagingModeEnabled                  : False
SchedulerSuspended                  : False
SyncCycleInProgress                 : False

 

To address the sync cycle, you will need to run the following command to set back to a value of “true”…

PS C:\Users\Administrator> Set-ADSyncScheduler -SyncCycleEnabled $true

 

Confirm the value for SyncCycleEnabled is set to “true”.

PS C:\Users\Administrator> Get-ADSyncScheduler

AllowedSyncCycleInterval            : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 00:30:00
CustomizedSyncCycleInterval         : 01:00:00
NextSyncCyclePolicyType             : Delta
NextSyncCycleStartTimeInUTC         : 5/26/2017 9:28:12 PM
PurgeRunHistoryInterval             : 7.00:00:00
SyncCycleEnabled                    : True
MaintenanceEnabled                  : True
StagingModeEnabled                  : False
SchedulerSuspended                  : False
SyncCycleInProgress                 : False

 

Next, you will need to run this command to restart the automated scheduled syncs with O365.  Yes (eye-roll), a full re-sync of AD to O365…

PS C:\Users\Administrator> Start-ADSyncSyncCycle -PolicyType Initial

 

Lastly, check the status of auto upgrade too as it may have been set to “Suspended”.

PS C:\Users\Administrator> Get-ADSyncAutoUpgrade
Suspended

 

If it is not enabled, run this command to re-enable it…

PS C:\Users\Administrator> Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled
Enabled

 

Hope that helps.

 

Reference(s):

Advertisements

5 thoughts on “Issues with Upgrading to AAD Connect 1.1.524.0

  1. Hi Todd,

    Do you happen to either have (i) custom sync rules configured on your Azure AD Connect server or out-of-box sync rule which was modified (e.g., disabled or changed)?

    Thanks,
    Chun Yong

      • Thanks, Todd.

        The reason why I ask this is because Azure AD Connect has this “protection” behavior where, during AADConnect upgrade, if there is a sync rule change and Azure AD Connect detects that there are custom rules, it will disable the scheduler once upgrade completes. This is to allow customers to examine whether the sync rule updates have any material impact on the custom sync rules. There should be a message left in the wizard after upgrade completes which indicates this.

        Regarding the AutoUpgradeStatus being set to suspended, there is no need to manually set it back to active. Azure AD Connect will reattempt upgrade as long as the state is either active or suspended. The suspended state is just an indication to customers that Auto-Upgrade occurred previously but wasn’t successful.

        Hope this clarifies.

        Thanks,
        Chun Yong

      • Auto upgrade was working before the upgrade of AAD Connect. Don’t really know why that functionality would change.

        Regarding the “protection behavior”, why with this version and not any of the other versions. Especially a feature that appears to be undocumented. Please provide references to validate your theory.

      • During Auto-Upgrade, the installer makes some pre-req checks to determine whether the current deployment is “eligible” for Auto-Upgrade or not. Currently, this check is very strict. Unless you have a very vanilla setup (must be Express install, no OU, no remote SQL, no custom sync rule, etc). The pre-req checks may succeed in previous build. But if you have updated configuration since, the same pre-req checks may no longer succeed. Sometimes, If you are interested to find out which pre-req check is causing Auto-Upgrade to fail this time, you can try to search through the event logs to see what error was returned during the last Auto-Upgrade attempt.

        Unfortunately, there is no documentation on the ‘protection behavior’ today. I just learnt about this myself recently from the Engineering Team who wrote the code. I will be adding documentation for this behavior shortly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s