locked
Erreur Réplication Windows serveur 2008 r2 RRS feed

  • Question

  • Bonjour à tous,

    Je vous expose mon problème : nous avons deux serveurs reliés en VPN (Widnows Serveur 2008 R2 standard).

    Chaque serveur est contrôleur de domaine avec un serveur "Maître" qui possède les 5 rôles FSMO ou l'AD se réplique sur le second serveur distant.

    Un jour, ce serveur "maître" est tombé et la seul façon de le redémarrer a été la restauration système via DD.

    Depuis ce jour, la réplication de l'AD entre les deux sites ne se fait plus :

    PS : SERV1 est le serveur qui est tombé ayant les rôles FSMO, SERV2 le serveur distant, "domaine" le domaine du réseau

    -------------------------------------------------------------------------

    Diagnostic du serveur d'annuaire (depuis SERV1)

    Exécution de l'installation initiale :
       Tentative de recherche de serveur associé...
       Serveur associé : SERV1
       * Forêt AD identifiée.
       Collecte des informations initiales terminée.

    Exécution des tests initiaux nécessaires

       Test du serveur : Premier-Site-par-defaut\SERV1
          Démarrage du test : Connectivity
             ......................... Le test Connectivity
              de SERV1 a réussi

    Exécution des tests principaux

       Test du serveur : Premier-Site-par-defaut\SERV1
          Démarrage du test : Replications
             [Replications Check,SERV1] Une tentative de réplication récente a
             échoué :
                De SERV2 vers SERV1
                Contexte de nommage : DC=ForestDnsZones,DC=domaine
                La réplication a généré une erreur (1256) :
                Le système distant n'est pas disponible. Pour obtenir des informatio
    ns à propos du dépannage réseau, consulter l'Aide Windows.

                L'échec s'est produit à 2013-06-20 16:35:16.
                La dernière réussite s'est produite à 2013-04-24 14:45:25.
                1878 échecs se sont produits depuis la dernière réussite.
             [SERV2] DsBindWithSpnEx() a échoué avec l'erreur 1727,
             L'appel de procédure distante a échoué et ne s'est pas exécuté..
             [Replications Check,SERV1] Une tentative de réplication récente a
             échoué :
                De SERV2 vers SERV1
                Contexte de nommage : DC=DomainDnsZones,DC=domaine
                La réplication a généré une erreur (1256) :
                Le système distant n'est pas disponible. Pour obtenir des informatio
    ns à propos du dépannage réseau, consulter l'Aide Windows.

                L'échec s'est produit à 2013-06-20 16:35:16.
                La dernière réussite s'est produite à 2013-04-24 14:45:25.
                1876 échecs se sont produits depuis la dernière réussite.
             [Replications Check,SERV1] Une tentative de réplication récente a
             échoué :
                De SERV2 vers SERV1
                Contexte de nommage : CN=Schema,CN=Configuration,DC=domaine
                La réplication a généré une erreur (1727) :
                L'appel de procédure distante a échoué et ne s'est pas exécuté.
                L'échec s'est produit à 2013-06-20 16:35:54.
                La dernière réussite s'est produite à 2013-04-24 14:45:25.
                1876 échecs se sont produits depuis la dernière réussite.
             [Replications Check,SERV1] Une tentative de réplication récente a
             échoué :
                De SERV2 vers SERV1
                Contexte de nommage : CN=Configuration,DC=domaine
                La réplication a généré une erreur (1727) :
                L'appel de procédure distante a échoué et ne s'est pas exécuté.
                L'échec s'est produit à 2013-06-20 16:35:16.
                La dernière réussite s'est produite à 2013-04-24 14:45:24.
                1876 échecs se sont produits depuis la dernière réussite.
             [Replications Check,SERV1] Une tentative de réplication récente a
             échoué :
                De SERV2 vers SERV1
                Contexte de nommage : DC=domaine
                La réplication a généré une erreur (1727) :
                L'appel de procédure distante a échoué et ne s'est pas exécuté.
                L'échec s'est produit à 2013-06-20 16:36:32.
                La dernière réussite s'est produite à 2013-04-24 15:20:30.
                1878 échecs se sont produits depuis la dernière réussite.
             ......................... Le test Replications
              de SERV1 a échoué


       Exécution de tests de partitions sur ForestDnsZones

       Exécution de tests de partitions sur DomainDnsZones

       Exécution de tests de partitions sur Schema

       Exécution de tests de partitions sur Configuration

       Exécution de tests de partitions sur domaine

       Exécution de tests d'entreprise sur domaine

    -------------------------------------------------------------------

    PS : j'ai appris qu'il était à éviter la restauration d'un contrôleur de domaine !

    Pouvez-vous m'éclairer sur la résolution de ce problème ?

    Je vous remercie d'avance.

    Cordialement

    jeudi 20 juin 2013 15:31

Réponses

  • Au vue du DCdiag la dernière réplication correct date du 24/04/2013 donc un peu ancien.

    JE vous recommande la solution de Régis qui apparaît la plus propre.

    Il est à noter que la seul méthode de restauration reconnue et la restauration de l'état du système avec ntbackup (jusqu'à 2003) ou wbadmin (depuis 2008). J'ai déja eu des soucis avec des outils tierce pour restaurer un DC, dont l'erreur n'est pas visible de suite.

    Après une restauration on vérifie (le mieux c'est de le vérifier régulièrement) par dcdiag 24h après et repadmin /showrepl ou /replsummary + vérif des journaux d'événement.

    Faire un tour dans site et service AD et vérifier pour chaque DC qu'il a une nombre de partenaire de réplication suffisant. PAr exemple si je regarde dans site et service AD sur DC 1 il indique qu'il a comme partenaire DC 2, je vais ensuite sur DC2 et je regarde que la aussi DC 1 à DC2 comme partenaire sinon il y a une incohérence pouvant provoquer cette erreur. 

    Il est possible de lancer la vérification de la topologie ou d'ajouter un lien manquant. Aucun DC ne doit se trouver isolé.

    jeudi 20 juin 2013 20:51
  • Bonjour Florian,

    En effet dans bien des cas, la restauration d'un contrôleur de domaine s'avère plus complexe et moins efficace que de créer un nouveau contrôleur de domaine.

    Dans votre cas, il faudrait d'abord savoir ce que vous entendez par : "restauration système via DD". selon la méthode de restauration, il se peut que les deux contrôleurs de domaine se déclarent mutuellement comme non valides. Par conséquent, ils s'interdisent toute réplication. Ce cas peut être rencontré lorsque votre DC est une machine virtulles et que vous  réalisez la restauration à partir de snapshots de machines virtuelles.

    Pour vous permettre de repartir dans de bonnes conditions, je vous conseille la méthode suivante :

    1. Assurez-vous de la bonne connectivité entre les deux sites géographiques
    2. identifiez le contrôleur de domaine qui, selon vous, est le plus à jour. Ce serveur est identifié comme le serveur sain
    3. Si ce n'est pas déjà fait, basculez les rôles de maître d'opération (FSMO) sur le serveur sain à l'aide des consoles d'administration AD, powershell ou ntdsutil
    4. Après avoir arrêté le service antivirus, rétrogradez le contrôleur de domaine défaillant à l'aide de la commande DCPROMO.exe. Si la commande échoue relancez la  commande suivante dcpromo.exe /forceremoval
    5. Sur le contrôleur de domaine restant, retirez toute référence à l'ancien contrôleur de domaine, à savoir dans l'annuaire (dsa.msc), la topologie de sites (dssite.msc) ainsi que dans DNS (serveurs de noms pour la zone du domaine). Enfin, NTDSUTIL qu'auvérifiez à l'aide de la commande cune référence à l'ancien contrôleur de domaine n'est visible (http://technet.microsoft.com/fr-fr/library/cc816907(v=ws.10).aspx#bkmk_graphical)
    6. Relancez la promotion du serveur en tant que contrôleur de domaine supplémentaire pour le domaine existant.
    7. Enfin, vérifiez que les deux serveurs répliquent correctement à l'aide de la commande repadmin /replsum

    Pendant la durée de l'opération, les utilisateurs situés sur le même site que le DC qui sera recréé utiliseront le DC sain pour s'authentifier. Il y a donc de fortes chances pour que le lien WAN soit davantage utilisé. Pensez également aux services tiers qui dépendent d'Active Directory comme par exemple votre proxy. Cette opération peut couper l'accès à Internet si le proxy est configuré pour utiliser le DC à réinstaller.

    Cordialement,

    Régis



    jeudi 20 juin 2013 18:08

Toutes les réponses

  • Bonjour Florian,

    En effet dans bien des cas, la restauration d'un contrôleur de domaine s'avère plus complexe et moins efficace que de créer un nouveau contrôleur de domaine.

    Dans votre cas, il faudrait d'abord savoir ce que vous entendez par : "restauration système via DD". selon la méthode de restauration, il se peut que les deux contrôleurs de domaine se déclarent mutuellement comme non valides. Par conséquent, ils s'interdisent toute réplication. Ce cas peut être rencontré lorsque votre DC est une machine virtulles et que vous  réalisez la restauration à partir de snapshots de machines virtuelles.

    Pour vous permettre de repartir dans de bonnes conditions, je vous conseille la méthode suivante :

    1. Assurez-vous de la bonne connectivité entre les deux sites géographiques
    2. identifiez le contrôleur de domaine qui, selon vous, est le plus à jour. Ce serveur est identifié comme le serveur sain
    3. Si ce n'est pas déjà fait, basculez les rôles de maître d'opération (FSMO) sur le serveur sain à l'aide des consoles d'administration AD, powershell ou ntdsutil
    4. Après avoir arrêté le service antivirus, rétrogradez le contrôleur de domaine défaillant à l'aide de la commande DCPROMO.exe. Si la commande échoue relancez la  commande suivante dcpromo.exe /forceremoval
    5. Sur le contrôleur de domaine restant, retirez toute référence à l'ancien contrôleur de domaine, à savoir dans l'annuaire (dsa.msc), la topologie de sites (dssite.msc) ainsi que dans DNS (serveurs de noms pour la zone du domaine). Enfin, NTDSUTIL qu'auvérifiez à l'aide de la commande cune référence à l'ancien contrôleur de domaine n'est visible (http://technet.microsoft.com/fr-fr/library/cc816907(v=ws.10).aspx#bkmk_graphical)
    6. Relancez la promotion du serveur en tant que contrôleur de domaine supplémentaire pour le domaine existant.
    7. Enfin, vérifiez que les deux serveurs répliquent correctement à l'aide de la commande repadmin /replsum

    Pendant la durée de l'opération, les utilisateurs situés sur le même site que le DC qui sera recréé utiliseront le DC sain pour s'authentifier. Il y a donc de fortes chances pour que le lien WAN soit davantage utilisé. Pensez également aux services tiers qui dépendent d'Active Directory comme par exemple votre proxy. Cette opération peut couper l'accès à Internet si le proxy est configuré pour utiliser le DC à réinstaller.

    Cordialement,

    Régis



    jeudi 20 juin 2013 18:08
  • Au vue du DCdiag la dernière réplication correct date du 24/04/2013 donc un peu ancien.

    JE vous recommande la solution de Régis qui apparaît la plus propre.

    Il est à noter que la seul méthode de restauration reconnue et la restauration de l'état du système avec ntbackup (jusqu'à 2003) ou wbadmin (depuis 2008). J'ai déja eu des soucis avec des outils tierce pour restaurer un DC, dont l'erreur n'est pas visible de suite.

    Après une restauration on vérifie (le mieux c'est de le vérifier régulièrement) par dcdiag 24h après et repadmin /showrepl ou /replsummary + vérif des journaux d'événement.

    Faire un tour dans site et service AD et vérifier pour chaque DC qu'il a une nombre de partenaire de réplication suffisant. PAr exemple si je regarde dans site et service AD sur DC 1 il indique qu'il a comme partenaire DC 2, je vais ensuite sur DC2 et je regarde que la aussi DC 1 à DC2 comme partenaire sinon il y a une incohérence pouvant provoquer cette erreur. 

    Il est possible de lancer la vérification de la topologie ou d'ajouter un lien manquant. Aucun DC ne doit se trouver isolé.

    jeudi 20 juin 2013 20:51
  • Bonjour à tous,

    Merci beaucoup pour vos réponses. En effet, vous confirmez nos pensées sur les étapes à réaliser.

    Les serveurs ne sont pas des VM, et la restauration système c'est faites via le CD Windows Serveur 2008 avec des sauvegardes Windows sur disque dur externe (wbadmin).

    Je n'hésiterais pas à vous tenir au courant (si ce thread peux servir à quelqu'un d'autre ...).

    Encore merci et bon week-end à tous.

    Cordialement

    TULON Florian

    vendredi 21 juin 2013 13:11