Symptômes
Considérez le scénario suivant :
-
Vous activez une copie passive d’une base de données Microsoft Exchange Server 2010 Service Pack 3 (SP3) à l’aide de Windows PowerShell ou la console de gestion Exchange.
-
La base de données montée démonte sans problème, et la copie passive monte.
-
Le statut de la copie de base de données passe à l’état Échec lors de l’étape lors de l’initialisation de la copie qui est à présent passive. En outre, le message d’état de la copie de la base de données montre a échoué.
Lorsque ce problème se produit, vous recevez un message d’erreur semblable au suivant lorsque vous exécutez le Get-MailboxDatabaseCopyStatus | identité de fl, errormessage cmdlet dans Exchange Management Shell (EMC) ;
Le service de réplication de Microsoft Exchange a rencontré une erreur lors de l’inspection des journaux et base de données pour DB\Server au démarrage. Erreur : Échouée de la vérification du fichier : fichier journal «chemin\Exx.log » est la génération nombre1; Toutefois, la génération attendue est number2.
Par exemple, vous pouvez recevoir le message d’erreur suivant :
Le service de réplication de Microsoft Exchange a rencontré une erreur lors de l’inspection des journaux et base de données pour DB\Server au démarrage. Erreur : Échouée de la vérification du fichier : Logfile « f:\logs\DB\Enn.log » est la génération 2024 ; Toutefois, la génération attendue est 2004.
Cause
Si la création de noms 8DOT3 est activée sur les volumes qui contiennent des fichiers journaux dans Exchange Server 2010 SP3, cela peut entraîner des journaux de transactions non valide retourné dans le cadre d’une requête findfile au cours du processus d’activation de bases de données. Ainsi, les bases de données à envoyer à un état d’échec en raison d’une séquence non valide dans les numéros de génération du journal des transactions.
Aucune perte de données se produit en raison de cet échec.
Résolution
Pour résoudre ce problème, installez le correctif cumulatif suivant :
Description de du correctif cumulatif 2 pour Exchange Server 2010 Service Pack 3
Solution de contournement
Étape 1 : Déterminer la configuration de la création de noms 8DOT3
Pour déterminer si la création de noms 8DOT3 est activée, exécutez la commande suivante à partir d’une invite de commandes avec élévation de privilèges. (Ici, nous supposons que les fichiers du journal des transactions se trouvent sur le lecteur C.)
fsutil 8dot3name query c:
Si la sortie attendue renvoie autre chose que la suivante, la création de noms 8DOT3 du resemblbes est activé :
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2(Per volume setting-the default).
Based on the above two settings, 8dot3 name creation is enabled on C:
Ou bien, la production prévue peut renvoyer quelque chose de semblable à la suivante :
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 0 (Per volume setting - the default).
Based on the above two settings, 8dot3 name creation is enabled on C:
Cela indique que le lecteur que c a la création de noms 8DOT3 activée.
Assurez-vous que vous exécutez cette commande sur le volume qui contient les journaux de transactions. Vous pouvez également utiliser ce qui suit si vous utilisez des points de montage :
fsutil 8dot3name query Volume{928842df-5a01-11de-a85c-806e6f6e6963} Vous devrez remplacer le GUID correspondant à GUID du votre volume du volume. Pour déterminer le volume et le GUID pour un lecteur spécifique, exécutez la commande suivante :
mountvol [Drive:]Path /L
Selon vos besoins, vous pouvez définir la création de noms 8DOT3 soit désactivé pour tous les volumes ou sur une base par volume de volume, comme est indiqué à l’étape 3. Il est très important de vous assurer que le volume qui contient les journaux de transactions est désactivé pour la création de noms 8DOT3.
Étape 2 : Stratégie de groupe de vérification pour désactiver la création de noms 8DOT3
Avant d’essayer de désactiver la création de noms 8DOT3, sachez que ce paramètre peut être contrôlé via la stratégie de groupe. Veuillez vérifier pour déterminer si la stratégie de groupe est configuré pour modifier la clé de Registre suivante sur les serveurs Exchange :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation"=dword:00000002
Si ce paramètre est contrôlé via la stratégie de groupe, supprimer ce paramètre dans les paramètres de stratégie de groupe pour les serveurs Exchange et la valeur DWORD NtfsDisable8dot3NameCreation la valeur 2. Ainsi, les modifications de chaque volume.
Remarque Si la valeur 0 est utilisée, vous ne pouvez pas modifier la configuration du volume.
Pour plus d’informations sur la commande Fsutil 8dot3name , consultez le site Web Microsoft TechNet suivant :
Étape 3 : Modifier la création de noms 8DOT3
Pour désactiver la création de noms 8DOT3 pour tous les volumes, exécutez la commande suivante :
fsutil 8DOT3name set
Si vous préférez désactiver uniquement sur des volumes qui contiennent les journaux de transactions, exécutez la commande suivante :
fsutil 8DOT3name set c: 1
Remarque Dans cette commande, c est la lettre du lecteur contenant les journaux de transactions.
Ou bien, vous pouvez exécuter sur un volume spécifique. Pour ce faire, exécutez la commande suivante :
fsutil 8dot3name query Volume{928842df-5a01-11de-a85c-806e6f6e6963} Après avoir modifié la configuration du volume pour désactiver la création de noms 8DOT3, vous pouvez vérifier que le paramètre est désactivé. Pour ce faire, exécutez de nouveau la commande suivante :
fsutil 8DOT3name query c:
Ainsi, tous les nouveaux fichiers créés ou copiés sur ce volume ne pas pour générer un nom de modèle 8.3 pour le nom de fichier. Toutefois, tous les fichiers existants contiennent toujours le nom de modèle 8.3. Par conséquent, vous devez résoudre ce problème.
Étape 4 : Supprimer 8point3 pour les journaux de transactions
Option 1
L’option par défaut est d’exécuter une sauvegarde complète des bases de données Exchange. Cela provoque des journaux des transactions est tronqué et supprime les journaux existants qui ont des noms 8DOT3. Une fois que tous les journaux de transactions qui contiennent des noms 8DOT3 sont tronqués, des déplacements de base de données n’échouera pas.
Option 2
Si l’option de sauvegarde n’est pas disponible, vous devez manipuler la copie de tous les journaux des transactions afin de vous assurer que les noms 8DOT3 sont supprimés à partir des fichiers. Pour ce faire, procédez comme suit :
-
Sur un serveur qui contient la copie passive de la base de données, arrêtez le service de réplication de Microsoft Exchange.
-
Dans Windows PowerShell, exécutez la commande suivante :
stop-service msexchangerepl
-
Dans l’Explorateur Windows, recherchez le dossier dans lequel vous stockez les journaux de transactions.
-
Sélectionnez tous les journaux de transaction de type Enn*.log et les déplacer vers un dossier temporaire. Assurez-vous que vous déplacez uniquement les journaux des transactions de type Enn*.log. Vous ne devez déplacer aucun autre type de fichier.
-
Déplacez tous les journaux de transaction vers leur emplacement d’origine. Dans ce processus de déplacement, les noms 8DOT3 sont supprimés.
-
Répétez cette procédure pour tous les journaux de transactions pour toutes les bases de données passifs.
-
Redémarrez le service de réplication de Microsoft Exchange :
start-service msexchangerepl
Remarque Cette étape doit être effectuée tout d’abord toutes les copies passives de bases de données.
-
Déplacer la copie montée (active) de la base de données à une copie, sur lequel les journaux de transactions sont manipulées :
Move-ActiveMailboxDatabase DB2 -ActivateOnServer MBX1 -MountDialOverride:None
-
Arrêtez le service de réplication de Microsoft Exchange, puis déplacer les journaux de transactions dans un emplacement temporaire et puis vers leur emplacement d’origine.
-
Démarrez le service de réplication de Microsoft Exchange. Maintenant, Échec de la base de données lors d’une action de déplacement-activemailboxdatabase ne doit pas se produire.
Plus d'informations
Autres problèmes courants qui se produisent sont dans le journal d’Application et dans le journal des opérations de l’ExchangeHighAvailability. Les événements apparaissent semblables aux suivants :
Pour déterminer si vous disposez toujours 8point3 sur les journaux de transactions, vous pouvez exécuter la commande suivante à une invite de commandes dans l’emplacement du journal des transactions :dir /x Si les journaux des transactions contiennent encore 8point3, vous voyez quelque chose de semblable à la suivante :
04/10/2013 04:16 PM 1,048,576 E0C749~1.LOG E0000000118.log 04/10/2013 04:16 PM 1,048,576 E01D7D~1.LOG E0000000119.log 04/10/2013 04:16 PM 1,048,576 E00834~1.LOG E000000011A.log 04/10/2013 04:16 PM 1,048,576 E05DFF~1.LOG E000000011B.log 04/10/2013 04:16 PM 1,048,576 E06DCB~1.LOG E000000011C.log 04/10/2013 04:16 PM 1,048,576 E0F768~1.LOG E000000011D.log
Remarque Si vous voyez le nom de E0F768~1.log figure dans la colonne suivant la dernière, vous avez toujours des journaux des transactions qui ont des noms 8DOT3. Par conséquent, vous aurez toujours les problèmes lorsque vous essayez de déplacer les bases de données actives.
