PI Services

Le blog des collaborateurs de PI Services

Exchange 2010 - Erreur de synchronisation des bases après la migration d'un serveur Mailbox virtualisé

Contexte

Après la migration d'un serveur Mailbox virtualisé vers un nouvel hoster, la réplication des bases Exchange ne fonctionne plus et le message d'erreur suivant est présent lorsque la commande Test-ReplicationHealth est utilisée :

The log copier was unable to continue processing for database DAG\MBX because an error occured on the target server: Continuous replication - block mode has been terminated. Error : the log file sector size does not match the current volume's sector size (-546)

Problèmatique

Ce problème est causé par un changement de la taille de secteur physique des disques sur lesquels les bases sont. Le problème intervient lorsque le nouvel hoster est plus récent que l'ancien et qu'il ne possède pas le même firmware pour le stockage. Exchange n'est pas en capacité de supporter automatiquement le changement d'un disque avec des secteurs de 512 bytes vers un disque avec des secteurs de 4096 bytes.

Pour vérifier cela, lancer la commande suivante : fsutil fsinfo ntfsinfo <Disk>

On remarque que le paramètre Bytes Per Physical Sector n'est pas supporté.

Solution

La solution pour reprendre la synchronisation des bases est de désactiver la réplication granulaire dans un premier temps. Pour cela, créer la clé de registre DWORD suivante avec la valeur 1 :

HKLM\Software\Microsoft\ExchangeServer\v14\Replay\Parameters\DisableGranularReplication

Après avoir redémarré le serveur, si on relance la commande fsutil fsinfo ntfsinfo <Disk> le paramètre Bytes Per Physical Sector accepte désormais les secteurs en 4096 bytes.

A la suite de ce changement, la réplication fonctionne de nouveau correctement.

Remarque : Attention, Microsoft ne supporte pas que la méthode de réplication ne soit pas la même sur l'ensemble des noeuds d'un DAG. Il est donc nécessaire de revenir en arrière une fois le changement effectué ou de désactiver la réplication granulaire sur l'ensemble des noeuds.

L'ensemble de ce problème est expliqué plus en détails sur le lien TechNet : https://blogs.technet.microsoft.com/exchange/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes/

Active Directory : Migration SYSVOL de FRS vers DFS-R - Etape Redirected (Partie 4)

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 :

Etat  Actions  Dossier SYSVOL Dossier SYSVOL_DFSR Dossier utilisé par les services AD DS
 Start (Etat 0)  Etat par défaut, FRS réplique le dossier SYSVOL. Présent Non présent SYSVOL
 Prepared (Etat 1)
 FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
 Présent Créé SYSVOL
 Redirected (Etat 2)
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
 Présent  Présent SYSVOL_DFSR
 Eliminated (Etat 3)
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
 Supprimé  Présent SYSVOL_DFSR
 

Particularités

Comme vous pouvez le voir ci-dessus, l'état 2 (Redirected) est le plus impactant :
  • 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
Il faut souligner les points suivants :
  • 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

On remarque que la bascule vers la version du dossier SYSVOL répliquée par le mécanisme DFS-R est bien indiquée.

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

Le message est explicite, tous les contrôleurs de domaine sont dans l'état Redirected, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
 
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8017 dans le journal d'évènements Applications and Servicies logs -> DFS Replication

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.