[EDIT]: Latest Azure AD Connect updater tries to add service account to builtin\admins and fails?

Copper Contributor


Update, since nobody has replied yet. See my original post and findings below.


Like the title now reflects, I've come to the conclusion that the updater fails to recognize that it is working on a domain controller, and tries to add the NT SERVICE\ADSync account to the BUILTIN\Administrators group, which fails. My two PowerShell tests suggest that this is not possible.


Trying to treat Administrators as an AD group:


PS C:\Users\adminuser> Add-ADGroupMember -Identity 'S-1-5-32-544' -Members 'S-1-5-80-3245704983-3664226991-764670653-2504430226-901976451'
Add-ADGroupMember: Cannot find an object with identity: 'S-1-5-80-3245704983-3664226991-764670653-2504430226-901976451' under: 'DC=[redacted],DC=[redacted]'.


Trying to tread Administrators as a local group:


PS C:\Users\radioadmin> Add-LocalGroupMember -Group 'S-1-5-32-544' -Member 'S-1-5-80-3245704983-3664226991-764670653-2504430226-901976451'
Add-LocalGroupMember: Group S-1-5-32-544 was not found.


Adding a regular AD account to Builtin\Administrators works well with this method.




Original post:


We recently (? actually hard to tell because AD connect litters the event log so badly that there is no chance to catch log entries older than a few days, but I digress).


Anyway, I at least caught a few errors from AD Connect updater recently, stating:


ValidateGroupsExist: CheckSecurityGroupsExist failed: Group with name ADSyncAdmins was not found in the Machine context.


Running Active Directory Connect manually asked me to update (seems it was stuck in a semi-updated state) but also listed the same error.

Odd, I though, I found a blog post that mentioned just adding this (and three more needed groups) to the domain (this is a DC) would work. And it sort of did, now the update process instead stuck with the following event log message:


Error during sync engine upgrade. System.Exception: Unable to upgrade the Synchronization Service. Exception has been thrown by the target of an invocation. | The parameter is incorrect.


So I thought, maybe because the update process had not completed successfully, I would try to run the full installer instead. This completely BROKE THE SERVICE, and my syncing stopped since midday. Luckily we are a small company and there are not that frequent changes to the AD user data.


Poking around further I think I finally found the culprit, the SyncEngine log lists:


AzureActiveDirectorySyncEngine Verbose: 903 : Executing: C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\SqlCmd.exe -S (localdb)\.\ADSync2019 -Q "exec sp_addsrvrolemember N'BUILTIN\Administratörer', sysadmin"
AzureActiveDirectorySyncEngine Verbose: 903 : Process Output: Msg 15007, Level 16, State 1, Server Radio1\LOCALDB#SH854732, Procedure sp_addsrvrolemember, Line 33
'BUILTIN\Administrat”rer' is not a valid login or you do not have permission.

and later:


AzureActiveDirectorySyncEngine Verbose: 903 : Failed to 'Add' member 'WinNT://NT SERVICE/ADSync' to the group 'WinNT://SERVER/Administratörer,group'.
AzureActiveDirectorySyncEngine Error: 906 : SynchronizationServiceSetupTask:UpgradeCore - Caught unexpected exception. Details System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: The parameter is incorrect.


I think the current sync engine upgrader cannot handle localized AD object names, and the server originally creating this domain was installed with language set to Swedish.


Please someone, make sure that this information gets to whoever needs to know. I will try to perform these steps manually in the mean time to see if the updater accepts it.


Best regards


1 Reply
Oh, I think I got it!

This machine was not a domain controller when ADSync was first installed, it was promoted later! So there exists a VSA on it even though it would now need a domain account.

I assume there is no supported way of doing this through the available tools, I need to migrate the database and install from scratch. Preferably on a separate server.