Contexte

Après un reboot du serveur AD Connect, le service "ADSync" reste en "Starting" ("démarrage" pour les OS en FR), et après quelque temps une Alerte Azure devrait remonter avec le message suivant :

En allant jeter un oeil dans les journaux d'événements, dans le journal "Application" vous devriez trouver l'erreur suivante :

Event Id 528

"Windows API call WaitForMultipleObjects returned error code: 575. Windows system error message is: {Application Error}

The application was unable to start correctly (0x%lx). Click OK to close the application.

Reported at line: 3714."

Bon a ce stade je vais être honnête, ça sent pas bon, la base de données locale d'AD Connect est dans un mauvais état (les fichiers sont corrompus) et nous devrions normalement réinstaller le serveur mais, avant cela on va d'abord essayer un petit "tricks".

Solution

1-Arrêter le service "ADSync"

Nous allons dans un premier temps "Désactiver" le service "ADSync" et redémarrer le serveur.

Ouvrez la console des services "Services.msc", sélectionnez le service "ADSync", faites un clic droit "Properties" et changez le "Startup Type" en sélectionnant "Disabled".

Enfin redémarrez le serveur.

2-Remplacer les fichiers corrompus

Après le redémarrage du serveur, connectez vous et ouvrez un explorateur jusqu'ici (Attention : Remplacez "XXXXXXXXXXXXX" par le nom du compte que vous utilisez) :

“C:\Users\XXXXXXXXXXXXX\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\ADSync2019” (C'est ici que se trouve les  fichiers corrompus).

Ouvrez un second explorateur jusqu'ici :

“C:\Program Files\Microsoft SQL Server\150\LocalDB\Binn\Templates”

Dans ce second explorateur copiez les fichiers suivants

• Model.mdf
• Modellog.ldf

Enfin collez les dans le premier explorateur (“C:\Users\XXXXXXXXXXXXX\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\ADSync2019”) :

Confirmez le remplacement des fichiers

3-Remmettre le service ADSync en état.

Ouvrez la console des services "Services.msc", sélectionnez le service "ADSync", faites un clic droit "Properties" et changez le "Startup Type" en sélectionnant "Automatic".

4-Redémarrer le service.

Démarrez le service, ouvrez la console des services "Services.msc", sélectionnez le service "ADSync", faites un clic droit et sélectionnez "Start"

Si vous êtes dans un jour de chance le service démarre et la synchronisation commence.

Conclusion

En conclusion, nous ne parvenons pas à expliquer ce qui a causé la corruption des fichiers lors du dernier redémarrage mais avec ce petit "tricks" on a pu éviter la réinstallation du serveur AD Connect.

Lorsque vous synchronisez vos utilisateurs via "Azure AD Connect", que vos utilisateurs sont dans différents pays et que vous utilisez l'audioconférence dans Teams, il semblerait logique que vos utilisateurs se voient attribuer un numéro "locale", plutôt qu'un numéro "Français".

Pour ce faire il est important de définir le lieu d'utilisation (Usage Location) dans Azure Active Directory, il est donc important de remplir l'attribut "Country" dans votre Active Directory OnPremise.

La construction est basé sur deux lettres, vous pourrez trouver la correspondance des pays et des lettres dans le lien ci-dessous:

Attention : Vous devrez utiliser les deux lettres en majuscule de la colonne "Language Culture Name"

https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee825488(v=cs.20)?redirectedfrom=MSDN

Vous pouvez fixer cet attribut à l'aide de Powershell via la commande ci-dessous (en prenant soin de remplacer "Mathieu" par le nom de votre utilisateur) :

Get-ADUser Mathieu | Set-ADUser -Replace @{‘Country’=”US”}

Ou alors en important un fichier csv pour une modification en masse, exemple de code ci-dessous.

# Import Csv and Set PreferredLanguage Attribute for each user
Import-csv C:\Temp\ToFixed.csv | foreach {
    $SamAccountName = $_.SamAccountName
    $Attribute = $_.Attribute
    Try {
        # Modifying PreferredLanguage Attribute
        Set-ADUser -Identity $SamAccountName -Replace @{‘Country’=$Attribute} -ErrorAction Stop 
        }
    Catch {
        $SamAccountName | Add-Content C:\temp\ErrorUsageLocation.txt
        }
    # Release
    $SamAccountName = $null
    $Attribute = $null
    }

Lorsque vous synchronisez vos utilisateurs via "Azure Ad Connect" et, que vous avez des utilisateurs dans différents pays, la langue par défaut pour chacun des utilisateurs dépend d'un attribut de votre Active Directory OnPremise, cet attribut est le "preferredLanguage".

Il devra être construit en suivant la nomenclature "Language Culture Name" du lien ci-dessous :

https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee825488(v=cs.20)?redirectedfrom=MSDN

Vous pouvez fixer cet attribut à l'aide de Powershell via la commande ci-dessous (en prenant soin de remplacer "Mathieu" par le nom de votre utilisateur) :

Get-ADUser Mathieu | Set-ADUser -Replace @{‘preferredLanguage’=”en-US”}

Ou alors en important un fichier csv pour une modification en masse, exemple de code ci-dessous.

# Import Csv and Set PreferredLanguage Attribute for each user
Import-csv C:\Temp\ToFixed.csv | foreach {
    $SamAccountName = $_.SamAccountName
    $Attribute = $_.Attribute
    Try {
        # Modifying PreferredLanguage Attribute
        Set-ADUser -Identity $SamAccountName -Replace @{‘preferredLanguage’=$Attribute} -ErrorAction Stop 
        }
    Catch {
        $SamAccountName | Add-Content C:\temp\ErrorPreferredLanguage.txt
        }
    # Release
    $SamAccountName = $null
    $Attribute = $null
    }

Comme expliqué dans l'article précédent "O365 : Soft Match (SMTP) et Hard Match (ImmutableID)" le Hard Match intervient lorsque le Soft Match n'a pas fonctionné.

Les étapes à suivre sont les suivantes:

1. Récupérer le GUID du compte dans l'Active Direcotry
2. Convertir ce dernier en ImmutableID
3. Appliqué cet ImmutableID au compte Azure Active Directory
4. Relancer une synchronisation via Ad connect 

Voici donc les commandes pour cela.

# Get GUID for User
$User = Get-ADUser jdupont | select ObjectGUID,UserPrincipalName
$Upn = $User.UserPrincipalName
$Guid = $User.ObjectGUID.Guid

# Convert GUID to ImmutableID
$ImmutableId = [System.Convert]::ToBase64String(([GUID]($User.ObjectGUID)).tobytearray())

# Connect MsolService
Connect-Msolservice

# Set ImmutableID to msoluser
Set-MsolUser -UserPrincipalName $Upn -ImmutableId $ImmutableId

Et voila, vous n'avez plus qu'a relancer une Synchor AD Connect via la commande suivante.

Start-ADSyncSyncCycle -PolicyType Delta

Lorsque l'on utilise Active Direcotry et Azure Active Directory, il se peut que l'on soit confronter à des conflits car l'utilisateur existe déjà dans les deux environnements (selon divers scénarios).

Quand il s'agit bien du même utilisateur (et non pas un homonyme) il est important  de créer un "matching" entre les deux comptes pour que l'AD Connect puisse les voir comme un seul et même compte et les synchroniser.

Pour ce faire il existe deux méthodes:

1. Le Soft Match appelé aussi SMTP Matching
2. Et le Hard Match (basé sur l'ImmutableID)

Le Soft Match

Le soft match appelé aussi "smpt matching" consiste à s'appuyer sur l'adresse SMTP de l'utilisateur pour faire l'association entre les deux comptes.

Ce dernier est censé fonctionner dans la plupart des cas, mais pour cela il y a quelques conditions à respecter. 

1. L'utilisateur doit posseder une adresse email sur Microsoft Exchange Online.
   1. s'il s'agit d'un contact ou d'un groupe à extension de messagerie le soft match sera basé sur l'attribt "proxyaddresses"
2. Vous ne devrez pas modifier l'adresse SMTP principale de l'utilisateur durant l'opération.
3. Les adresses SMTP sont considérées comme unique assurez vous que seul cet utilisateur possède cette adresse.

Le Hard Match

Le hard match entre en action lorsque le soft match n'a pas réussi, ce dernier consiste à récupérer le GUID du compte Active Directory pour le transformer en ImmutableID et enfin l'appliquer au compte Azure Active Directory.

Cette opération permettera de faire la liaison entre les deux comptes pour n'en faire qu'un synchronisé.

Dans certains cas de figure nous avons besoin de mettre en pause les synchronisations entre Active Directory et son Azure AD (par exemple: une montée de version du client AD Connect, une modification des droits d'accès du compte de synchro, modification des règles de synchronisation...).

Dans l'ensemble rien de bien compliqué mais dans les faits... L'utilisation de la mauvaise cmdlet Powershell peut vous mettre dans l'embarras si ce n'est plus.

En effet pour stopper les cycles de synchronisation entre l'Active Directory et Azure AD plusieurs commandes sont possibles.

La commande A NE PAS UTILISER

Set-MsolDirSyncEnabled -EnableDirSync $false

Cette commande ne doit pas être utilisée, en cas d'utilisation vous devrez attendre 72 heures avant de pouvoir rétablir le service!!!!

La commande utilisable

Set-ADSyncScheduler -SyncCycleEnabled $false

Une fois votre opération réalisée, vous pourrez réactiver les synchronisations en utilisant la commande ci-dessous.

Set-ADSyncScheduler -SyncCycleEnabled $true

Bonne modification sur vos configurations.

L'utilisateur apparait comme un compte cloud

Après un Hard link, il est normal que le compte reste affiché comme un compte cloud dans O365, même si le compte O365 est bien rattaché au compte Active Directory, ce dernier ne change pas d'état. 

Afin de corriger cela il vous suffit de faire une modification sur l'un des attributs du compte pour qu'il soit de nouveau synchronisé avec AD Connect et enfin réapparaître comme un objet synchronisé avec Active Directory.

Dans certain cas de figure (mariage, divorce...) les utilisateurs de l'AD change de nom, ceux qui a pour impact un renommage du compte Active Directory, jusque la pas de problème mais (parce qu'il en faut un) lorsque vous utilisez "AD Connect" pour synchroniser vos utilisateurs locaux (votre Active Directory) avec Office 365 (Azure Active Directory), certains paramètres ne sont pas synchronisés.

Parmi ces paramètres le UserPrincipalName, plus communément appelé UPN ne peut être modifié depuis l'AD et répliqué vers O365.

Pour modifier l'UPN côté O365 vous devrez utiliser la commande Powershell suivante:

Set-MsolUserPrincipalName -UserPrincipalName AncienUPN@mondomaine.com -NewUserPrincipalName NouvelUPN@mondomaine.com

Contexte

La synchronisation entre l’Active Directory et Office 365 est un sujet extrêmement sensible dans un environnement de production. Une mauvaise configuration peut entrainer la suppression de nombreux objets dans le cloud (comptes, groupes…).

Le domaine enfant de mon domaine Active Directory a été décoché dans la configuration de mon connecteur dans la console Synchronization Service Manager.

Figure 1 – Propriétés du connecteur

Lorsque l’on coche à nouveau le domaine enfant et que l’on relance une synchronisation, le domaine enfant n’est pas resynchronisé.

Solution

Lors de la suppression du domaine enfant, les étapes de synchronisation associées sont supprimées.

On remarque en allant dans Configure Run Profiles… sur le connecteur qu’il n’y a qu’une seule étape qui correspond au domaine parent.

Figure 2 – Profil du connecteur pour le Full Import avec une seule étape (domaine parent)

Il est donc nécessaire de recréer les étapes pour le domaine enfant. Pour cela il est recommandé de lancer l’outil de configuration d’Azure AD Connect.

Une fois l’outil de configuration terminée, les étapes pour le domaine enfant sont de nouveaux en place.

Figure 3 – Profil du connecteur pour le Full Import avec deux étapes (domaine parent et domaine enfant)

Il est ensuite nécessaire de relancer dans l’ordre :

• Full Import – Connecteur Active Directory
• Full Synchronisation – Connecteur Active Directory
• Export – Connecteur Active Directory
• Delta Import – Connecteur Office 365 (domaine.onmicrosoft.com)
• Delta Synchronisation – Connecteur Office 365 (domaine.onmicrosoft.com)
• Export – Connecteur Office 365 (domaine.onmicrosoft.com)