J'ai récemment fait l'expérience d'une suppression de comptes, puis
restauration depuis l'état système, puis restauration "autoritaire" d'une
arborescence via NTDSUTIL, dans un environnement Windosw 2003 SP1.
L'utilitaire génère un fichier texte qui liste les objets restaurés, et un
fichier LDF qui contient les informations d'appartenance aux groupes.
ça me paraît gros d'être passé à côté de cela, mais le fichier LDF n'est pas
exploitable lorsque des accentués sont présents dans les DN des objets. Par
exemple, "Aurélie" deviendra "Aur,lie" dans le fichier LDF. L'import via
ldifde écoue logiquement, invoquant l'inexistence des objets. Quant à
convertir le fichier généré en unicode... le mal est déjà fait, donc je ne
retrouve pas d'accentués. Est ce que c'est un problème bien connu? Est ce
qu'on peut modifier le comportement de NTDSUTIL? Est ce que finalement,
adossé à toute sauvegarde AD, on a intérêt à adjoindre un export LDIF?
j'ai republié le doc mis à jour, inclus 3 lignes sur les réanimations et l'astuce de Gille pour l'unicode. J'ai également publié au même endroit un document de recettage de PRA. Une fois réalisé tous les tests, vous pourrez dire que vous êtes au point sur le PRA AD :-)
Au sujet du lag site, je suis mitigé. ( c'est couvert cependant dans le doc). Je l'ai souvent fait mettre en place jusqu'à ce que ça pose un problème chez un des mes clients. Il n'ont pas sû le diagnostiquerni même m'expliquer correctement ce qu'ils avaient rencontré.
Cependant, à priori, lors d'un test DRP, ils ont arrêté un site, basculé les rôles et le KCC s'est emmêlé les pinceaux lors de la reconstruction de la topologie. Les services Netlogon et KDC sur les Lagsites etaient arrêtés pour empêcher l'authentification sur ces DC. Les partenaires de réplication des DC restants étaient injoignables (site arrêté, mais il s'agissait d'un site physique dans un même site AD, donc topologie intrasite), et les DC du lagsite (topologie intersite) ne répondaient pas aux requêtes KDC et netlogon. La topologie ne s'est jamais stabilisée, la réplication entre les DC restant n'a donc jamais eu lieu, les rôles n'ont pas été pris en compte, la reconstruction de GC n'a pas pû avoir lieu etc... En rouvrant la réplication, et en redémarrant les service d'authentification, la situation est revenue à la normale (donc "arrêt" du lagsite).
La solution lagsite est aujourd'hui abandonnée chez eux et ils ont investi dans les produits netpro rachetés par Quest... et bientôt "discontinued" :-(. N'ayant pas personnellement diagnostiqué le pb, je suis maintenant prudent avant de proposer une telle solution.
Avoir un site virtualisé reste cependant intéressant. Dans le cas d'un désastre complet, c'est très facile de restaurer un DC en VM car il n'y a pas la contrainte d'avoir à retrouver un matériel identique ou de batailler 2 jours pour restaurer sur du matériel différent.
L'ancien lagsite ne sert plus qu'à cette fonction et également à pouvoir rebooter un DC en restore mode sans impacter personne pour un authoritative restore par exemple. Ca permet de pouvoir restaurer un service minimum d'authentification (un DC par domaine) dans un cas de restauration de forêt dans un minimum de temps, et bien plus vite qu'un outil comme Forest recovery de Quest qui pourrait avoir un interêt éventuel qu'une fois la forêt "minimale" reconstruite, afin de remonter les DC restants. Par contre, ce produit n'a aucune utilité en période de crise pour restaurer "le service", voir même pourrait se révéler contre productif (c'est vendu comme un produit miracle à grand renfort d'invitations à des présentations tous les 3 mois etc...).
A ce propos, je viens d'être confronté à un scénario intéressant et viens de me rendre compte que le 1er DC de la forêt à restaurer est celui qui possède le rôle Schema Master (quand on a l'embarras du choix des bandes à restaurer!!!). Sans lui , impossible de promoter un GC, donc authentification et logon en mode natif impossible (sauf si IgnoreGCFailure). Pour seizer ce rôle, il faut être dans le groupe schema admin... et chez mon client, il ont retiré administrator de ce groupe. D'ou blocage !!! Ce qu'il a fallu faire, dans le contexte systeme de la machine, lancer adsiedit et dans la partition schema, changer manuellement le nom du DC possédant ce rôle, ensuite modifier la clé de registre Global Catalog Partition Occupancy pour permettre de créer un GC "vide" car encore aucun partenaire de réplication disponible. A ce stade, vous avez un premier GC dans le domaine racine (bien que vide, mais ça restaure le service de logon), il est ensuite possible de restaurer un DC de chaque domaine ... et votre forêt est alors reconstruite.
Je n'ai pas cherché si c'était documenté quelque part mais je ne vois pas comment un produit comme Forest Recovery de Quest saurait traiter un tel scénario... Je blogerais à l'occasion ce scénario de reconstruction de forêt plus précisémment (ne pas oublier le DNS ) , car sans y être préparé, vous pouvez rester planté plusieurs jours avant de parvenir à redémarrer... puis vous achetez un produit... qui ne vous rend pas un meilleur service.
Seul conseil, testez les pires scénarios, testez régulièrement, soyez préparé, prenez des scénario au hasard et déterminez quand plusieurs solutions s'offrent à vous laquelle est la plus rapide dans votre environnement.
Bonne soirée.
Emmanuel.
"Lognoul Marc [MVP]" a écrit dans le message de news:%238S%23AB%
Emmanuel,
Au sujet des objets tombstonés... je suis plutôt contre ce genre de pratique de réanimer des objets vidés de leurs attributs. Il vaut mieux toujours
Dans les cas qui le permettent, je configure le schéma pour le PAS effacer les attributs des objets tombstonés, cela permet une récupération plus rapide.
privilégier une authoritative restore, bien sûr il faut avoir un backup récent, mais c'est le cas pour tout le monde non? :-)
Mais bien sur!
... ça n'empêche pas effectivement d'y rajouter un petit paragraphe dans le doc de DRP, d'ailleurs Marc Russinovich a crée à ce sujet un petit outil, adrestore.
Et que penses-tu, en résumé, de la réplication différée vers un site de "récupération?
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Voilà,
j'ai republié le doc mis à jour, inclus 3 lignes sur les réanimations et
l'astuce de Gille pour l'unicode.
J'ai également publié au même endroit un document de recettage de PRA.
Une fois réalisé tous les tests, vous pourrez dire que vous êtes au point
sur le PRA AD :-)
Au sujet du lag site, je suis mitigé. ( c'est couvert cependant dans le
doc).
Je l'ai souvent fait mettre en place jusqu'à ce que ça pose un problème chez
un des mes clients.
Il n'ont pas sû le diagnostiquerni même m'expliquer correctement ce qu'ils
avaient rencontré.
Cependant, à priori, lors d'un test DRP, ils ont arrêté un site, basculé les
rôles et le KCC s'est emmêlé les pinceaux lors de la reconstruction de la
topologie. Les services Netlogon et KDC sur les Lagsites etaient arrêtés
pour empêcher l'authentification sur ces DC.
Les partenaires de réplication des DC restants étaient injoignables (site
arrêté, mais il s'agissait d'un site physique dans un même site AD, donc
topologie intrasite), et les DC du lagsite (topologie intersite) ne
répondaient pas aux requêtes KDC et netlogon.
La topologie ne s'est jamais stabilisée, la réplication entre les DC restant
n'a donc jamais eu lieu, les rôles n'ont pas été pris en compte, la
reconstruction de GC n'a pas pû avoir lieu etc...
En rouvrant la réplication, et en redémarrant les service
d'authentification, la situation est revenue à la normale (donc "arrêt" du
lagsite).
La solution lagsite est aujourd'hui abandonnée chez eux et ils ont investi
dans les produits netpro rachetés par Quest... et bientôt "discontinued"
:-(.
N'ayant pas personnellement diagnostiqué le pb, je suis maintenant prudent
avant de proposer une telle solution.
Avoir un site virtualisé reste cependant intéressant. Dans le cas d'un
désastre complet, c'est très facile de restaurer un DC en VM car il n'y a
pas la contrainte d'avoir à retrouver un matériel identique ou de batailler
2 jours pour restaurer sur du matériel différent.
L'ancien lagsite ne sert plus qu'à cette fonction et également à pouvoir
rebooter un DC en restore mode sans impacter personne pour un authoritative
restore par exemple.
Ca permet de pouvoir restaurer un service minimum d'authentification (un DC
par domaine) dans un cas de restauration de forêt dans un minimum de temps,
et bien plus vite qu'un outil comme Forest recovery de Quest qui pourrait
avoir un interêt éventuel qu'une fois la forêt "minimale" reconstruite, afin
de remonter les DC restants. Par contre, ce produit n'a aucune utilité en
période de crise pour restaurer "le service", voir même pourrait se révéler
contre productif (c'est vendu comme un produit miracle à grand renfort
d'invitations à des présentations tous les 3 mois etc...).
A ce propos, je viens d'être confronté à un scénario intéressant et viens de
me rendre compte que le 1er DC de la forêt à restaurer est celui qui possède
le rôle Schema Master (quand on a l'embarras du choix des bandes à
restaurer!!!).
Sans lui , impossible de promoter un GC, donc authentification et logon en
mode natif impossible (sauf si IgnoreGCFailure).
Pour seizer ce rôle, il faut être dans le groupe schema admin... et chez mon
client, il ont retiré administrator de ce groupe.
D'ou blocage !!!
Ce qu'il a fallu faire, dans le contexte systeme de la machine, lancer
adsiedit et dans la partition schema, changer manuellement le nom du DC
possédant ce rôle, ensuite modifier la clé de registre Global Catalog
Partition Occupancy pour permettre de créer un GC "vide" car encore aucun
partenaire de réplication disponible.
A ce stade, vous avez un premier GC dans le domaine racine (bien que vide,
mais ça restaure le service de logon), il est ensuite possible de restaurer
un DC de chaque domaine ... et votre forêt est alors reconstruite.
Je n'ai pas cherché si c'était documenté quelque part mais je ne vois pas
comment un produit comme Forest Recovery de Quest saurait traiter un tel
scénario...
Je blogerais à l'occasion ce scénario de reconstruction de forêt plus
précisémment (ne pas oublier le DNS ) , car sans y être préparé, vous pouvez
rester planté plusieurs jours avant de parvenir à redémarrer... puis vous
achetez un produit... qui ne vous rend pas un meilleur service.
Seul conseil, testez les pires scénarios, testez régulièrement, soyez
préparé, prenez des scénario au hasard et déterminez quand plusieurs
solutions s'offrent à vous laquelle est la plus rapide dans votre
environnement.
Bonne soirée.
Emmanuel.
"Lognoul Marc [MVP]" <lognoulm@hotmail.com> a écrit dans le message de
news:%238S%23AB%230JHA.6132@TK2MSFTNGP04.phx.gbl...
Emmanuel,
Au sujet des objets tombstonés... je suis plutôt contre ce genre de
pratique
de réanimer des objets vidés de leurs attributs. Il vaut mieux toujours
Dans les cas qui le permettent, je configure le schéma pour le PAS effacer
les attributs des objets tombstonés, cela permet une récupération plus
rapide.
privilégier une authoritative restore, bien sûr il faut avoir un backup
récent, mais c'est le cas pour tout le monde non? :-)
Mais bien sur!
... ça n'empêche pas effectivement d'y rajouter un petit paragraphe dans
le
doc de DRP, d'ailleurs Marc Russinovich a crée à ce sujet un petit outil,
adrestore.
Et que penses-tu, en résumé, de la réplication différée vers un site de
"récupération?
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
j'ai republié le doc mis à jour, inclus 3 lignes sur les réanimations et l'astuce de Gille pour l'unicode. J'ai également publié au même endroit un document de recettage de PRA. Une fois réalisé tous les tests, vous pourrez dire que vous êtes au point sur le PRA AD :-)
Au sujet du lag site, je suis mitigé. ( c'est couvert cependant dans le doc). Je l'ai souvent fait mettre en place jusqu'à ce que ça pose un problème chez un des mes clients. Il n'ont pas sû le diagnostiquerni même m'expliquer correctement ce qu'ils avaient rencontré.
Cependant, à priori, lors d'un test DRP, ils ont arrêté un site, basculé les rôles et le KCC s'est emmêlé les pinceaux lors de la reconstruction de la topologie. Les services Netlogon et KDC sur les Lagsites etaient arrêtés pour empêcher l'authentification sur ces DC. Les partenaires de réplication des DC restants étaient injoignables (site arrêté, mais il s'agissait d'un site physique dans un même site AD, donc topologie intrasite), et les DC du lagsite (topologie intersite) ne répondaient pas aux requêtes KDC et netlogon. La topologie ne s'est jamais stabilisée, la réplication entre les DC restant n'a donc jamais eu lieu, les rôles n'ont pas été pris en compte, la reconstruction de GC n'a pas pû avoir lieu etc... En rouvrant la réplication, et en redémarrant les service d'authentification, la situation est revenue à la normale (donc "arrêt" du lagsite).
La solution lagsite est aujourd'hui abandonnée chez eux et ils ont investi dans les produits netpro rachetés par Quest... et bientôt "discontinued" :-(. N'ayant pas personnellement diagnostiqué le pb, je suis maintenant prudent avant de proposer une telle solution.
Avoir un site virtualisé reste cependant intéressant. Dans le cas d'un désastre complet, c'est très facile de restaurer un DC en VM car il n'y a pas la contrainte d'avoir à retrouver un matériel identique ou de batailler 2 jours pour restaurer sur du matériel différent.
L'ancien lagsite ne sert plus qu'à cette fonction et également à pouvoir rebooter un DC en restore mode sans impacter personne pour un authoritative restore par exemple. Ca permet de pouvoir restaurer un service minimum d'authentification (un DC par domaine) dans un cas de restauration de forêt dans un minimum de temps, et bien plus vite qu'un outil comme Forest recovery de Quest qui pourrait avoir un interêt éventuel qu'une fois la forêt "minimale" reconstruite, afin de remonter les DC restants. Par contre, ce produit n'a aucune utilité en période de crise pour restaurer "le service", voir même pourrait se révéler contre productif (c'est vendu comme un produit miracle à grand renfort d'invitations à des présentations tous les 3 mois etc...).
A ce propos, je viens d'être confronté à un scénario intéressant et viens de me rendre compte que le 1er DC de la forêt à restaurer est celui qui possède le rôle Schema Master (quand on a l'embarras du choix des bandes à restaurer!!!). Sans lui , impossible de promoter un GC, donc authentification et logon en mode natif impossible (sauf si IgnoreGCFailure). Pour seizer ce rôle, il faut être dans le groupe schema admin... et chez mon client, il ont retiré administrator de ce groupe. D'ou blocage !!! Ce qu'il a fallu faire, dans le contexte systeme de la machine, lancer adsiedit et dans la partition schema, changer manuellement le nom du DC possédant ce rôle, ensuite modifier la clé de registre Global Catalog Partition Occupancy pour permettre de créer un GC "vide" car encore aucun partenaire de réplication disponible. A ce stade, vous avez un premier GC dans le domaine racine (bien que vide, mais ça restaure le service de logon), il est ensuite possible de restaurer un DC de chaque domaine ... et votre forêt est alors reconstruite.
Je n'ai pas cherché si c'était documenté quelque part mais je ne vois pas comment un produit comme Forest Recovery de Quest saurait traiter un tel scénario... Je blogerais à l'occasion ce scénario de reconstruction de forêt plus précisémment (ne pas oublier le DNS ) , car sans y être préparé, vous pouvez rester planté plusieurs jours avant de parvenir à redémarrer... puis vous achetez un produit... qui ne vous rend pas un meilleur service.
Seul conseil, testez les pires scénarios, testez régulièrement, soyez préparé, prenez des scénario au hasard et déterminez quand plusieurs solutions s'offrent à vous laquelle est la plus rapide dans votre environnement.
Bonne soirée.
Emmanuel.
"Lognoul Marc [MVP]" a écrit dans le message de news:%238S%23AB%
Emmanuel,
Au sujet des objets tombstonés... je suis plutôt contre ce genre de pratique de réanimer des objets vidés de leurs attributs. Il vaut mieux toujours
Dans les cas qui le permettent, je configure le schéma pour le PAS effacer les attributs des objets tombstonés, cela permet une récupération plus rapide.
privilégier une authoritative restore, bien sûr il faut avoir un backup récent, mais c'est le cas pour tout le monde non? :-)
Mais bien sur!
... ça n'empêche pas effectivement d'y rajouter un petit paragraphe dans le doc de DRP, d'ailleurs Marc Russinovich a crée à ce sujet un petit outil, adrestore.
Et que penses-tu, en résumé, de la réplication différée vers un site de "récupération?
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
Gilles LAURENT [MVP]
"Edreux (ILINFO)" a écrit dans le message de news:u8%
Bonsoir Emmanuel,
| j'ai republié le doc mis à jour, inclus 3 lignes sur les réanimations | et l'astuce de Gilles pour l'unicode. [...]
Tout d'abord merci pour la publication de ces précieux documents. Et également merci pour la citation sur la conversion Unicode ;-)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Edreux (ILINFO)" <edreux@nospam.fr> a écrit dans le message de
news:u8%23hejA1JHA.4468@TK2MSFTNGP05.phx.gbl
Bonsoir Emmanuel,
| j'ai republié le doc mis à jour, inclus 3 lignes sur les réanimations
| et l'astuce de Gilles pour l'unicode.
[...]
Tout d'abord merci pour la publication de ces précieux documents.
Et également merci pour la citation sur la conversion Unicode ;-)
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
