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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Barathon [MS]
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD dans la doc de Microsoft, notamment là (en anglais): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le si "Sylvain" wrote in message news:%
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
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse
rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque
site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant
utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un
même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste
de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD
dans la doc de Microsoft, notamment là (en anglais):
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le
si
"Sylvain" <sylvain_milette@hotmail.com> wrote in message
news:%23FqBpzu0EHA.2316@TK2MSFTNGP15.phx.gbl...
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
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD dans la doc de Microsoft, notamment là (en anglais): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le si "Sylvain" wrote in message news:%
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
Claire
Bonjour jacques, A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle FSMO concerné, qui acquitte les ouvertures de sessions ? Si cela se fait alétoirement, on peut donc dire que dans un domaine/site avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un des 2 DC est (par exemple) hors Rzo ? Merci.
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD dans la doc de Microsoft, notamment là (en anglais): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le si "Sylvain" wrote in message news:%
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 jacques,
A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle
FSMO concerné, qui acquitte les ouvertures de sessions ?
Si cela se fait alétoirement, on peut donc dire que dans un domaine/site
avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un
des 2 DC est (par exemple) hors Rzo ?
Merci.
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse
rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque
site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant
utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un
même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste
de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD
dans la doc de Microsoft, notamment là (en anglais):
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le
si
"Sylvain" <sylvain_milette@hotmail.com> wrote in message
news:%23FqBpzu0EHA.2316@TK2MSFTNGP15.phx.gbl...
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
Bonjour jacques, A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle FSMO concerné, qui acquitte les ouvertures de sessions ? Si cela se fait alétoirement, on peut donc dire que dans un domaine/site avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un des 2 DC est (par exemple) hors Rzo ? Merci.
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD dans la doc de Microsoft, notamment là (en anglais): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le si "Sylvain" wrote in message news:%
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
Fabricem [MS]
Bonjour
Pour répondre
A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle
FSMO concerné, qui acquitte les ouvertures de sessions ?
Non, l'ensemble des contrôleurs d'un site participe à l'authentification des utilisateurs Encore fait-il bien configurer les sites au sens AD, en leur affectant des sous réseaux IP
Si cela se fait alétoirement, on peut donc dire que dans un domaine/site avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un des 2 DC est (par exemple) hors Rzo ? Oui, le client intérroge le DNS et recupère la liste des DC du site puis les
intérroge les uns apres les autres, si aucun ne repond, il prend ansuita la liste de tous les DC du domaine et commence à en chercher (sans se soucier s'il est proche ou à 10 000 Km :))
Cdlt
-- Fabrice Meillon Architecte Infrastructure Division Développeurs et Plate-Forme d'Entreprise Microsoft France
"Claire" a écrit dans le message de news:
Bonjour jacques, A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle FSMO concerné, qui acquitte les ouvertures de sessions ? Si cela se fait alétoirement, on peut donc dire que dans un domaine/site avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un des 2 DC est (par exemple) hors Rzo ? Merci.
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD dans la doc de Microsoft, notamment là (en anglais): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le si "Sylvain" wrote in message news:%
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
Pour répondre
A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle
FSMO concerné, qui acquitte les ouvertures de sessions ?
Non, l'ensemble des contrôleurs d'un site participe à l'authentification des
utilisateurs
Encore fait-il bien configurer les sites au sens AD, en leur affectant des
sous réseaux IP
Si cela se fait alétoirement, on peut donc dire que dans un domaine/site
avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un
des 2 DC est (par exemple) hors Rzo ?
Oui, le client intérroge le DNS et recupère la liste des DC du site puis les
intérroge les uns apres les autres, si aucun ne repond, il prend ansuita la
liste de tous les DC du domaine et commence à en chercher (sans se soucier
s'il est proche ou à 10 000 Km :))
Cdlt
--
Fabrice Meillon
Architecte Infrastructure
Division Développeurs et Plate-Forme d'Entreprise
Microsoft France
"Claire" <Claire@discussions.microsoft.com> a écrit dans le message de news:
35662115-5F90-4F64-A90F-34F8C57B5F14@microsoft.com...
Bonjour jacques,
A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle
FSMO concerné, qui acquitte les ouvertures de sessions ?
Si cela se fait alétoirement, on peut donc dire que dans un domaine/site
avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un
des 2 DC est (par exemple) hors Rzo ?
Merci.
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse
rapide ou pas mais elle est déterminée par le découpage en sites AD.
Chaque
site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant
utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur
d'un
même site les contrôleurs de domaine sont "attribués" à tel ou ou tel
poste
de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD
dans la doc de Microsoft, notamment là (en anglais):
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour
le
si
"Sylvain" <sylvain_milette@hotmail.com> wrote in message
news:%23FqBpzu0EHA.2316@TK2MSFTNGP15.phx.gbl...
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
A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle
FSMO concerné, qui acquitte les ouvertures de sessions ?
Non, l'ensemble des contrôleurs d'un site participe à l'authentification des utilisateurs Encore fait-il bien configurer les sites au sens AD, en leur affectant des sous réseaux IP
Si cela se fait alétoirement, on peut donc dire que dans un domaine/site avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un des 2 DC est (par exemple) hors Rzo ? Oui, le client intérroge le DNS et recupère la liste des DC du site puis les
intérroge les uns apres les autres, si aucun ne repond, il prend ansuita la liste de tous les DC du domaine et commence à en chercher (sans se soucier s'il est proche ou à 10 000 Km :))
Cdlt
-- Fabrice Meillon Architecte Infrastructure Division Développeurs et Plate-Forme d'Entreprise Microsoft France
"Claire" a écrit dans le message de news:
Bonjour jacques, A l'intérieur d'un même site, ce n'est donc pas le DC qui possède le rôle FSMO concerné, qui acquitte les ouvertures de sessions ? Si cela se fait alétoirement, on peut donc dire que dans un domaine/site avec 2 DCs, il n'y aura pas de pb. pour les ouvertures de sessions si l'un des 2 DC est (par exemple) hors Rzo ? Merci.
La notion de proximité d'un DC n'est pas jugée en fonction d'une réponse rapide ou pas mais elle est déterminée par le découpage en sites AD. Chaque site AD correspond classiquement à un LAN ou à un ensemble de LAN pouvant utiliser indifféremment les mêmes contrôleurs de domaine. A l'intérieur d'un même site les contrôleurs de domaine sont "attribués" à tel ou ou tel poste de manière aléatoire.
Tu trouveras plus d'infos sur la planification et la création de sites AD dans la doc de Microsoft, notamment là (en anglais): http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_qnmc.asp
Jacques
Il ne te reste donc plus qu'à créer deux sites AD spécifiques, l'un pour le si "Sylvain" wrote in message news:%
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
