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

Durant une migration ordinateur avec l'outil ADMT d'un domaine source vers un domaine cible, il est possible de rencontrer l’erreur ci-dessous :

ERR3:7075 Failed to change domain affiliation, hr=80070005 Access is denied

Cette erreur sera enregistrée dans le fichier log de migration ADMT sous c:\windows\admt\logs.

Lors de la migration des objets ordinateurs avec ADMT, l'outil demande de choisir les contrôleurs de domaine source et cible à utiliser. Le choix du DC cible est très important !

Il ne faut pas choisir n'importe quel DC cible, il faut plutôt utiliser le nom du DC où la configuration ci-dessous a été faite.

Resolution de l'erreur:

Cette erreur peut être résolue par deux méthodes :

1. Activer la stratégie de groupe (GPO) suivante sur tous les contrôleurs de domaine cible (Default domain policy) :

“Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options\NetWork Access: Named Pipes that can be accessed anonymously” avec au moins les services “netlogon,lsarpc” inclus.

2. Choisir un des contrôleurs de domaine cible (qui sera utilisé lors de la migration ordinateur) et créer la clé de registre suivante : "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes" avec les valeurs "netlogon,lsarpc"

Source : https://santhoshsivarajan.wordpress.com/2010/10/30/admt-err37075-failed-to-change-domain-affiliation-access-is-denied/

Explication de l’erreur:

ADMT agents sync the computer with the target domain using anonymous connections to the LSARPC and NETLOGON named pipes on the target domain's DC.

Source : https://social.technet.microsoft.com/Forums/ie/en-US/304f25a2-cb85-4570-b616-669a5a874ba0/admt-computer-migration-failures?forum=winserverMigration

Remarque :

Le fait d'installer l'outil ADMT PES (Paswword Export Server) sur un contrôleur de domaine, la clé de registre ci-dessus sera créée automatiquement.

Quand on a l'habitude d'utiliser la console Active Directory Administrative Center pour restaurer des objets AD et que l'on désire restaurer des objets AD sur un Active Directory sous Windows server 2008, on peut se sentir décontenancer.

Eh oui pas de console ADAC sur Windows Server 2008, bon alors on fait quoi ? Powershell !!!

Pour lister tous les objets de la corbeille :

# List All Deleted objects
$AllDeletedObjects = Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=*)" –IncludeDeletedObjects -Properties *

Ensuite libre à vous de filtrer sur les types d'objets, nom et autres propriétés.

# List All Deleted Groups
$DeletedGroups = $AllDeletedObjects | Where {$_.ObjectClass -eq "group"}

Et enfin restaurer ce qui vous intéresse dans l'OU de destination qui convient (ici le groupe "GS-Office-E3" restaurer dans l'OU "RestaurationPlace")

$ToRestore = $DeletedGroups | Where {$_.Name -like "GS-Office-E3"}
$DeletedGroups | Restore-ADObject -TargetPath "OU=RestorationPlace,DC=Demo,DC=corp"

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

Un environnement homogène avec des OS installé en Anglais, c'est la vision de notre éditeur préféré (je parle bien sur de Microsoft).

Dans la pratique on a pas toujours l'opportunité d'avoir tous les OS dans la même version et pire encore dans la même langue d'installation.

Quel impact ?

Même si pour certain, installer un OS en Français est plus "Confortable / facile d'administration", en terme de "recherche / résolution" d'incident on est quand même nettement moins bien aidé (entre les messages d'erreur qui ne veulent rien dire ou les commandes qui diffèrent, avoir un langage différent de l'anglais peut vous faire perdre quelques heures).

Des Exemples :

Prenons un exemple simple l'activation ou la désactivation du "SID Filtering" dans un "Trust" entre deux domaines.

OS Anglais :

Si les OS des serveurs contrôleur de domaine sont en Anglais les commandes sont simples :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:No  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Yes

 Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

OS Français :

Lorsque les OS sont en Français il y a une petite subtilité :

Pour désactiver le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Non  

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Pour activer le SID Filtering : 

Netdom trust **TrustingDomainName** /domain:**TrustedDomainName **/quarantine:Oui

Nb: Remplacez **TrustingDomainName** par le nom du domaine qui doit approuver l'autre et **TrustedDomainName ** par le nom de domaine qui doit être approuvé.

Vous l'avez ?

Et oui la commande est quasi identique puisqu'elle est en Anglais, mais les arguments eux sont en Français et le pire dans tout ça c'est que si vous passez la commande en Anglais avec les arguments en Anglais, l'OS vous dira que la commande s'est terminée avec succès même si ce n'est pas le cas; mais dans la pratique cette dernière aura échouée.

Alors de grâce ayez le réflex lors d'une installation serveur de sélectionner un Iso en Anglais et de l'installer en Anglais (rassurez vous pour le clavier et le fuseau horaire le Français est autorisé ^^ ).

Bonjour à tous,

Aujourd'hui nous abordons la partie 5 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à la dernière étape Eliminated.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Particularités

• En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL (cette copie étant devenue depuis l'étape Redirected celle utilisée par les services AD DS), la version répliquée par le mécanisme FRS est supprimée.
• En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL

• Tout retour arrière est impossible une fois cette etape éffectuée.
• Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant de supprimer la version répliquée par FRS. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
• Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC.

En pratique

Etat Redirected

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Redirected.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Eliminated.

Passage vers l'état Eliminated

Etat global (Domaine AD) : dfsrmig /setglobalstate 3

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Eliminated atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Eliminated. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

La console DFS Management pour le groupe de réplication Domain System Volume nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

Bonjour à tous,

Aujourd'hui nous abordons la partie 4 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Redirected.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Particularités

• En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL, toujours en parallèle de la version répliquée par le mécanisme FRS.
• En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL

• Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
• Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant d'effectuer la bascule vers celle-ci. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
• Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
• Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Prepared

Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Prepared.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Redirected.

Passage vers l'etat Redirected

Etat global (Domaine AD) : dfsrmig /setglobalstate 2

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Redirected atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Redirected. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la troisième étape, Eliminated.

Bonjour à tous,

Aujourd'hui nous abordons la partie 3 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Prepared.

En théorie

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Particularités

• En arrière-plan, le mécanisme de réplication DFS-R est mis en place pour répliquer une copie du dossier SYSVOL, en parallèle de la version répliquée par le mécanisme FRS.
• En façade, c'est toujours le dossier SYSVOL répliqué par le mécanisme FRS qui est présenté aux postes clients via les partages NETLOGON et SYSVOL

• Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
• Une copie du dossier SYSVOL actuel sera réalisée. Il convient de vérifier que le dossier SYSVOL est intègre avant de commencer les étapes de migration sinon vous vous retrouverez avec un dossier SYSVOL qui sera toujours corrompu en fin de migration.
• Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
• Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC

En pratique

Etat Start

Si aucune tentative de migration n'a été faite auparavant, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Start.

Etat global (Domaine AD) : dfsrmig /getglobalstate

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Prepared.

Passage vers l'etat Prepared

Etat global (Domaine AD) : dfsrmig /setglobalstate 1

• D'une réplication Active Directory lente
• D'un RODC ne voulant pas passer en état Prepared. Les RODCs ne pouvant pas modifier les objects Active Directory par eux mêmes (création des objets DFS-R leur correspondant), c'est le PDC qui est chargé de le faire à leur place. Toutefois, si malgré un certain délai, les RODCs ne passent pas en état Prepared, il faudra forcer la création des objets DFS-R correspondant avec la commande dfsrmig /CreateGlobalObjects (à éxécuter seulement une fois depuis le PDC)

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).

Etat Prepared atteint

Etat global (Domaine AD) : dfsrmig /getglobalstate

La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Prepared. Celui-ci reste donc inchangé.

Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate

La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est toujours celle répliquée par le mécanisme FRS.

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la deuxieme étape, Redirected.