Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs d'ouverture de
session. En principe, ce devrait être le DC le plus près de l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs d'ouverture de
session. En principe, ce devrait être le DC le plus près de l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs d'ouverture de
session. En principe, ce devrait être le DC le plus près de l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs d'ouverture de
session. En principe, ce devrait être le DC le plus près de l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs d'ouverture de
session. En principe, ce devrait être le DC le plus près de l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs d'ouverture de
session. En principe, ce devrait être le DC le plus près de l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.
Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour Benoît,
Oh la la: Tes réponses nous permettent d'avancer dans la compréhension. Mais
en même temps nous conduisent à d'autres intérogations (c'est sans doute bon
signe ...).
Aussi, tu as bien compris que, concernant les rôles FSMO, notre besoin est
d'assurer le plus de tolétance de panne possible tout en faisant que c'est le
2k3 qui valide les sessions utilisateurs.
Alors quel "répartition" de ces rôles, entre les 2 DC, semble la plus
judicieuse pour répondre à ces 2 besoins ? Car inévitablement, par
"tolérance" cela sous entend que l'on duplique certains rôles non ? Et pour
les autres (ceux qui ne peuvent être que sur un DC dans le domaine) ? La
tolérance
n'est plus assurée en cas de panne de ce même DC !!!
Merci pour tes conseils.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour Benoît,
Oh la la: Tes réponses nous permettent d'avancer dans la compréhension. Mais
en même temps nous conduisent à d'autres intérogations (c'est sans doute bon
signe ...).
Aussi, tu as bien compris que, concernant les rôles FSMO, notre besoin est
d'assurer le plus de tolétance de panne possible tout en faisant que c'est le
2k3 qui valide les sessions utilisateurs.
Alors quel "répartition" de ces rôles, entre les 2 DC, semble la plus
judicieuse pour répondre à ces 2 besoins ? Car inévitablement, par
"tolérance" cela sous entend que l'on duplique certains rôles non ? Et pour
les autres (ceux qui ne peuvent être que sur un DC dans le domaine) ? La
tolérance
n'est plus assurée en cas de panne de ce même DC !!!
Merci pour tes conseils.
"Benoît LANLARD [MVP]" wrote:
Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.
Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour Benoît,
Oh la la: Tes réponses nous permettent d'avancer dans la compréhension. Mais
en même temps nous conduisent à d'autres intérogations (c'est sans doute bon
signe ...).
Aussi, tu as bien compris que, concernant les rôles FSMO, notre besoin est
d'assurer le plus de tolétance de panne possible tout en faisant que c'est le
2k3 qui valide les sessions utilisateurs.
Alors quel "répartition" de ces rôles, entre les 2 DC, semble la plus
judicieuse pour répondre à ces 2 besoins ? Car inévitablement, par
"tolérance" cela sous entend que l'on duplique certains rôles non ? Et pour
les autres (ceux qui ne peuvent être que sur un DC dans le domaine) ? La
tolérance
n'est plus assurée en cas de panne de ce même DC !!!
Merci pour tes conseils.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Alors, déjà tous les rôles FSMO ne peuvent être gérés que par une seul DC
dans le domaine (ECPD, RID, Infra) ou la forêt (Schéma, Dénomination). Donc
vous ne pouvez pas assurer une tolérance de panne pour ces rôles. Par contre
si vous avez qu'un seul domaine vous pouvez les centraliser sur une seule
machine qui serait la plus puissante donc je suppose le 2003.
Autrement, pour les rôles FSMO en cas de panne du serveur qui les héberges,
pas de panique cela n'empêche pas les authentifications et ne perturbe que
moyennement le fonctionnement de l'AD. Si le serveur en panne doit être
réinstallé, il peut y avoir dans ce cas un transfert de rôle forcé vers le
second.
En espérant avoir répondu a vos attentes.
Si vous en avez d'autre n'hésitez pas.Bonjour Benoît,
Oh la la: Tes réponses nous permettent d'avancer dans la compréhension. Mais
en même temps nous conduisent à d'autres intérogations (c'est sans doute bon
signe ...).
Aussi, tu as bien compris que, concernant les rôles FSMO, notre besoin est
d'assurer le plus de tolétance de panne possible tout en faisant que c'est le
2k3 qui valide les sessions utilisateurs.
Alors quel "répartition" de ces rôles, entre les 2 DC, semble la plus
judicieuse pour répondre à ces 2 besoins ? Car inévitablement, par
"tolérance" cela sous entend que l'on duplique certains rôles non ? Et pour
les autres (ceux qui ne peuvent être que sur un DC dans le domaine) ? La
tolérance
n'est plus assurée en cas de panne de ce même DC !!!
Merci pour tes conseils.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Alors, déjà tous les rôles FSMO ne peuvent être gérés que par une seul DC
dans le domaine (ECPD, RID, Infra) ou la forêt (Schéma, Dénomination). Donc
vous ne pouvez pas assurer une tolérance de panne pour ces rôles. Par contre
si vous avez qu'un seul domaine vous pouvez les centraliser sur une seule
machine qui serait la plus puissante donc je suppose le 2003.
Autrement, pour les rôles FSMO en cas de panne du serveur qui les héberges,
pas de panique cela n'empêche pas les authentifications et ne perturbe que
moyennement le fonctionnement de l'AD. Si le serveur en panne doit être
réinstallé, il peut y avoir dans ce cas un transfert de rôle forcé vers le
second.
En espérant avoir répondu a vos attentes.
Si vous en avez d'autre n'hésitez pas.
Bonjour Benoît,
Oh la la: Tes réponses nous permettent d'avancer dans la compréhension. Mais
en même temps nous conduisent à d'autres intérogations (c'est sans doute bon
signe ...).
Aussi, tu as bien compris que, concernant les rôles FSMO, notre besoin est
d'assurer le plus de tolétance de panne possible tout en faisant que c'est le
2k3 qui valide les sessions utilisateurs.
Alors quel "répartition" de ces rôles, entre les 2 DC, semble la plus
judicieuse pour répondre à ces 2 besoins ? Car inévitablement, par
"tolérance" cela sous entend que l'on duplique certains rôles non ? Et pour
les autres (ceux qui ne peuvent être que sur un DC dans le domaine) ? La
tolérance
n'est plus assurée en cas de panne de ce même DC !!!
Merci pour tes conseils.
"Benoît LANLARD [MVP]" wrote:
Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.
Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:
Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.
Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.
Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
EDFEFF6A-0220-45D1-A87C-06CBE815B612@microsoft.com...
Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.
Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.
Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
Bonjour,
Alors, déjà tous les rôles FSMO ne peuvent être gérés que par une seul DC
dans le domaine (ECPD, RID, Infra) ou la forêt (Schéma, Dénomination). Donc
vous ne pouvez pas assurer une tolérance de panne pour ces rôles. Par contre
si vous avez qu'un seul domaine vous pouvez les centraliser sur une seule
machine qui serait la plus puissante donc je suppose le 2003.
Autrement, pour les rôles FSMO en cas de panne du serveur qui les héberges,
pas de panique cela n'empêche pas les authentifications et ne perturbe que
moyennement le fonctionnement de l'AD. Si le serveur en panne doit être
réinstallé, il peut y avoir dans ce cas un transfert de rôle forcé vers le
second.
En espérant avoir répondu a vos attentes.
Si vous en avez d'autre n'hésitez pas.Bonjour Benoît,
Oh la la: Tes réponses nous permettent d'avancer dans la compréhension. Mais
en même temps nous conduisent à d'autres intérogations (c'est sans doute bon
signe ...).
Aussi, tu as bien compris que, concernant les rôles FSMO, notre besoin est
d'assurer le plus de tolétance de panne possible tout en faisant que c'est le
2k3 qui valide les sessions utilisateurs.
Alors quel "répartition" de ces rôles, entre les 2 DC, semble la plus
judicieuse pour répondre à ces 2 besoins ? Car inévitablement, par
"tolérance" cela sous entend que l'on duplique certains rôles non ? Et pour
les autres (ceux qui ne peuvent être que sur un DC dans le domaine) ? La
tolérance
n'est plus assurée en cas de panne de ce même DC !!!
Merci pour tes conseils.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Bonne approche, il vous reste donc à transférer les rôles du 2K vers le 2K3,
il n'y a pas d'ordre particulier. Par contre, vous devez le faire à partir du
2K3.
Depuis les consoles :
Utilisateurs et ordinateurs active directory pour les ECPD, RID, Infra
Domaine et approbation Ad pour le FSMO dénominsation nom de domaine
Schéma active Directory pour schema master
Attention la console schéma n'est pas active par défaut soit vous installez
toutes les consoles via l'adminpak.msi soit vous tapez en invite regsvr32
schmmgmt.dll
Par contre après le 2K reste DC sans aucun rôle pour assurer une tolérance
de panne.
Bon courage.Merci pour ce complément qui est bien utile !
Concernant le transfert des rôles du 2k vers le 2k3, il n'est pas motivé par
le retrait du 2k du domaine. Mais parcequ'il arrive en fin de garantie, que
nous voudrions d'avantage faire assurer les services aux utilisateurs par le
2k3 (notamment TSE 2003), ...
D'ailleurs, nous souhaiterions garder le 2k comme DC de secours dans ce
domaine.
Alors y a t'il une mauvaise approche de notre part ?
Car nous ne pensions pas qu'un transfert des rôles nécessitait un retrait du
DC source !
Enfin, dans l'opération même de transfert, y a t'il un ordre particulier à
respecter ?
Salutations et remerciements.
"Benoît LANLARD [MVP]" wrote:Bonjour,
Effectivement, et c'est l'interêt d'avoir plusieurs DC, ils peuvent tous
réaliser des authentifications. C'est pour ça qu'avec une architecture avec
plusieurs sites il est important de définir proprement ses sites et sous
réseau.
Concernant le transfert des rôles, il est nécessaire uniquement si vous
savez que le serveur propriétaire des rôles ne sera pas remis en service
avant longtemps.
Si vous souhaitez d'avantage d'info n'hésitez pas.Bonjour,
puis-je retenir que si dans mon domaine (avec un seul site) il y a 2 DC (Un
2k et un 2K3 ajouté au domaine 2K sans aucun transfert des rôles FSMO) le 2k3
peut répondre aux demandes d'ouvertures de session (la synchro d'AD se fait
bien), et ceci, notamment si le 2k est hors Rzo, en train de rebooter, ... ?
Enfin, et par extension : Pouvons transférer tous ces rôles du 2k sur le 2k3 ?
Quelles précautions à prendre ?
Merci.Bonjour,
Les rôles FSMO ne concernent pas directement l'authentification.
Schema master gère les modifications du schéma
Domain naming évite les noms de domaines duppliqués dans la forêt
Infrastructure Master gère les enregistrement fantomes de la base Active
Directory (1 par domaine)
RID Master gère la distribution des pools de rid aux DC pour la création de
nouveaux objets (1 par domaine)
et enfin PDC emulator qui est le fsmo à tout faire : Dupplication des
comptes de l'AD vers las bases SAM des BDC NT4, source de temps du domaine,
émulation du PDC pour le changement de mot de passe depuis un client
antérieur à Windows 2000, protection des conflits de modification des GPO.(1
par domaine)
Cordialement,
--
YANN GAINCHE
Technical Account Manager
MCT - MCSE2003:Security
Transcript: http://www.microsoft.com/learning/mcp/transcripts (ID: 672181
Access code: tscript2004)
"Claire" a écrit dans le message de news:Bonjour Benoit,
Ta réponse est intéréssante.
En même temps elle me donne l'envie de te poser la question suivante:
Dans un même domaine, n'y a t'il donc pas qu'un DC pouvant acquitter les
authentifications utilisateurs (celui qui est propriétaire du rôle FSMO
concerné).
Si non, quels sont les rôles FSMO que ces DC doivent détenir pour pouvoir
le
faire.
Merci pour tes précisions.Bonjour,
Est-ce que vous avez créé 2 sites Active Directory ?
Il faut créer 2 sites dans la console Site et service Active Directory,
Déplacer un des 2 serveurs dans un des sites. (Chacun son site)
Et surtout créer des subnets et les associer au bons sites suivant votre
plan d'adressage IP réseau de vos sites.Bonjour,
Un domaine Windows 2003 réparti dans quelques établissements reliés
par
liens 256 k. Dans le but d'améliorer les choses nous avons installé un
DC
avec dns dans un établissement éloigné.
Problème: Les utilisateurs de cet établissement ont la plupart du temps
leur
ouverture de session validée par ce nouveau DC, mais il arrive parfois
que
ce soit par un des DC centraux (éloignés). Également, les gens qui ont,
habituellement leur ouverture de session validée par les DC centraux le
sont
parfois par ce nouveau DC éloigné, ce qui cause des lenteurs
d'ouverture de
session. En principe, ce devrait être le DC le plus près de
l'utilisateur
qui valide l'ouverture de session. Non???
Que peut-on faire pour empêcher ces ouvertures de sessions sur des DC
éloignés?
Merci
Sylvain
