Dans un groupe de disponibilité de base de données (DAG) avec Exchange Server 2019, il peut arriver qu’un des nœuds de serveur affiche le statut “non opérationnel”. Bien que le problème ne soit pas si critique, vous devez garder à l’esprit que si un ou plusieurs autres serveurs tombent en panne, le cluster tombera en panne car le nœud (vers lequel le basculement devrait avoir lieu) n’est pas opérationnel. Vous devez également garder à l’esprit que la réplication des données n’aura pas lieu. Dans ce cas, les données seront incohérentes lors d’un basculement. Dans ce qui suit, nous examinerons en détail le problème du serveur membre du DAG qui n’est pas opérationnel et nous montrerons les solutions possibles pour résoudre le problème.
Que se passe-t-il si le serveur membre DAG n’est pas opérationnel ?
Étant donné que le service de cluster de Windows fonctionne avec le groupe de disponibilité des bases de données (DAG), vous remarquerez également que le service de cluster ne démarre pas, même s’il est réglé sur automatique. Bien que le cluster soit toujours opérationnel parce que le serveur Exchange fonctionne sur un autre nœud, vous devez tenir compte des bases de données qui se trouvent sur le serveur non opérationnel. Ces bases de données ne fonctionneront plus. Si la copie de la base de données n’est pas OK, elle ne sera pas montée. Vous devez également tenir compte du fait que si le serveur opérationnel tombe en panne, il n’y aura pas de majorité de vote dans le cluster car il n’y aura pas assez de nœuds et le cluster arrêtera les services pour protéger l’intégrité.
Voici quelques solutions possibles pour résoudre le problème “Aucune prise en charge de cette opération » sur un serveur membre du DAG Exchange”.
1. Redémarrez le serveur membre du DAG.
Parfois, un simple redémarrage du serveur Exchange peut résoudre le problème du membre qui s’affiche comme n’étant pas opérationnel. Essayez donc de redémarrer le serveur concerné et voyez si le problème est résolu. Vous pouvez également essayer de réinstaller la fonction de regroupement regroupement de basculement sur le serveur concerné et de redémarrer le serveur.
2. vérifier les changements
Il se peut que des changements récents soient à l’origine du problème. Vous pouvez consulter votre équipe d’administration informatique et votre équipe réseau pour vous assurer que rien n’a changé. Vous pouvez également vérifier le processus de gestion des changements de l’organisation pour voir si des changements ont été enregistrés. Cela vous donnera une indication de l’origine du problème et de ses causes.
3. vérifiez et démarrez le service Windows Cluster
Le groupe de disponibilité de la base de données dépend du service Windows Server Cluster. Il n’est pas fonctionnel sans ce service. Le service est normalement configuré pour démarrer automatiquement. Dans le cas présent, cependant, vous remarquerez que le service n’est pas en cours d’exécution. Vous pouvez essayer de le démarrer.
4. vérifier les autorisations
Lors du démarrage du service de cluster, le message d’erreur “Windows n’a pas pu démarrer le service de cluster sur l’ordinateur local” peut apparaître. Si vous avez configuré le service de cluster pour qu’il s’exécute sous un utilisateur spécifique, vous devez vérifier que l’utilisateur ne présente pas de problèmes, par exemple que le mot de passe a expiré, qu’un mot de passe incorrect a été configuré ou que le compte est verrouillé. Vous devez également vérifier que l’utilisateur du domaine (utilisé pour démarrer le service de cluster) dispose des droits d’administrateur local requis sur l’ordinateur Exchange Server. Pour ce faire, allez dans Gestion de l’ordinateur > Utilisateurs et groupes locaux > Groupes et vérifiez si l’utilisateur fait partie du groupe Administrateurs.
Vous pouvez également vérifier les autorisations de l’utilisateur dans le gestionnaire de regroupement regroupement de basculement. Pour ce faire, procédez comme suit
- Ouvrez le gestionnaire de regroupement de basculement.
- Cliquez avec le bouton droit de la souris sur le nom du cluster et cliquez sur Propriétés.
- Allez dans l’onglet Sécurité et assurez-vous que l’utilisateur du domaine est listé avec les permissions correctes.
Ensuite, vérifiez les autorisations dans le serveur Exchange en exécutant la commande suivante dans le Exchange Management Shell (EMS).
Add-ADPermission -Identity "<DAG Name>" -User "<Account>" -AccessRights GenericRead, GenericWrite -ExtendedRights
La commande ci-dessus exécute le processus d’octroi des droits à l’utilisateur du domaine. Si une attention s’affiche, cela signifie que l’utilisateur dispose déjà des autorisations.
L’utilisateur doit également disposer de toutes les autorisations pour l’unité organisationnelle (OU) de l’Active Directory. Pour le vérifier,
- Ouvrez Active Directory Users and Computers.
- Recherchez l’unité organisationnelle (OU) dans laquelle se trouvent les serveurs et les ressources DAG.
- Cliquez avec le bouton droit de la souris sur l’objet serveur et cliquez sur Propriétés.
- Dans l’onglet Certitude, assurez-vous que le compte dispose d’un contrôle total sur les objets.
5. vérifier l’affichage de l’événement
Vous pouvez consulter l’observateur d’événements pour voir s’il y a des indications du problème. Vous pouvez rechercher les entrées suivantes pour le serveur concerné dans les journaux d’événements :
- ID d’événement 1069 – Ceci indique l’échec d’un cluster de basculement pour une ressource.
- ID d’événement 1254 – Ceci indique que le service de cluster n’a pas réussi à livrer le rôle de cluster en ligne.
- ID d’événement 4113 – Ceci indique un problème avec une copie de base de données dans le cluster.
Dans le cas de l’événement ID 4113, vous pouvez exécuter la commande Get-MailboxDatabaseCopyStatus pour déterminer les problèmes.
À la fin
Nous avons évoqué ci-dessus les différentes manières de résoudre le problème “Le serveur membre du DAG n’est pas opérationnel”. Si le problème persiste, vous devez considérer que les bases de données sur le serveur peuvent être corrompues ou endommagées. Pour récupérer les données des bases de données corrompues en un temps d’arrêt minimal, vous pouvez faire appel à des outils de récupération Exchange spécialisés tels que Stellar® Récupération de Données. Il peut vous aider à récupérer les données des bases de données corrompues aussi rapidement que possible sans aucune perte de données. Avec cet outil, vous pouvez ouvrir n’importe quelle base de données Exchange Server dans n’importe quel état et de n’importe quelle taille. Vous pouvez ensuite parcourir les magasins de données sans qu’un serveur Exchange ne soit en cours d’exécution. Vous pouvez exporter les boîtes aux lettres et autres données EDB de manière granulaire vers PST et d’autres formats de fichiers ou vers un serveur Exchange actif avec synchronisation automatique des boîtes aux lettres. L’outil peut également être utilisé pour migrer les données EDB vers un locataire Microsoft 365.
Was this article helpful?
