Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement :
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement :
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement :
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et _ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement :
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et _ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement :
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et _ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement :
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp (juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Merci infiniment
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic updates
of certain DNS records, use the Group Policy snap-in to edit the Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as follows:
.. For all branch office domain controllers, add all mnemonic entries that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting. Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic updates
of certain DNS records, use the Group Policy snap-in to edit the Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as follows:
.. For all branch office domain controllers, add all mnemonic entries that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting. Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: AF3F15AB-E326-46F8-890A-4A385B6CAF75@microsoft.com...
Merci infiniment
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic updates
of certain DNS records, use the Group Policy snap-in to edit the Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as follows:
.. For all branch office domain controllers, add all mnemonic entries that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting. Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic updates
of certain DNS records, use the Group Policy snap-in to edit the Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as follows:
.. For all branch office domain controllers, add all mnemonic entries that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting. Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic updates
of certain DNS records, use the Group Policy snap-in to edit the Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as follows:
.. For all branch office domain controllers, add all mnemonic entries that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting. Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: AF3F15AB-E326-46F8-890A-4A385B6CAF75@microsoft.com...
Merci infiniment
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic updates
of certain DNS records, use the Group Policy snap-in to edit the Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as follows:
.. For all branch office domain controllers, add all mnemonic entries that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting. Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites (agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc >_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux (et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos et
_ldap
correspondant aux DC sur lesquels les clients doivent s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO afin
qu'elles prennent en compte les connexions réseau lentes si vos liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que plusieurs
personnes devraient passer par ici pour ajouter des infos à mes dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux types :
- des agences : Serveur sous 2003 Server (contrôleurs de domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans problème
dans
les agences mais très rarement dans les bureaux (1 fois sur 20).
J'ai localisé le problème en effectuant un gpresult sur l'un des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock qui
empêche
les agences de communiquer entre elles (impossible de modfier) et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement _ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion "générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= >> > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic entries
that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans
le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que
les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux
(et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO
afin
qu'elles prennent en compte les connexions réseau lentes si vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock
qui
empêche
les agences de communiquer entre elles (impossible de modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement _ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion "générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?
Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= >> > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic entries
that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: AF3F15AB-E326-46F8-890A-4A385B6CAF75@microsoft.com...
Merci infiniment
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans
le
message de news:
8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc
_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que
les
posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux
(et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO
afin
qu'elles prennent en compte les connexions réseau lentes si vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit
dans le
message de news:
2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock
qui
empêche
les agences de communiquer entre elles (impossible de modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement _ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion "générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= >> > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic entries
that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans
le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que
les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux
(et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO
afin
qu'elles prennent en compte les connexions réseau lentes si vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock
qui
empêche
les agences de communiquer entre elles (impossible de modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
oui, le service netlogon sur les dc réenregistrent périodiquement leurs
enregistrements DNS.
Donc effectivement, les supprimer ne servira à rien, ils réapparaitront.
Il faut empêcher l'enregistrement dans la zone _MSDCS des dc qui ne sont pas
dans le site central comme mentionné dans le branch office deployment guide.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement _ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion "générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > >> > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic entries
that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans
le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que
les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux
(et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO
afin
qu'elles prennent en compte les connexions réseau lentes si vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock
qui
empêche
les agences de communiquer entre elles (impossible de modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
oui, le service netlogon sur les dc réenregistrent périodiquement leurs
enregistrements DNS.
Donc effectivement, les supprimer ne servira à rien, ils réapparaitront.
Il faut empêcher l'enregistrement dans la zone _MSDCS des dc qui ne sont pas
dans le site central comme mentionné dans le branch office deployment guide.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 7FCA92A7-CE2C-42AB-99B2-D0E6E4A88594@microsoft.com...
Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement _ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion "générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?
Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > >> > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic entries
that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: AF3F15AB-E326-46F8-890A-4A385B6CAF75@microsoft.com...
Merci infiniment
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans
le
message de news:
8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc
_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que
les
posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux
(et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO
afin
qu'elles prennent en compte les connexions réseau lentes si vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit
dans le
message de news:
2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock
qui
empêche
les agences de communiquer entre elles (impossible de modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
oui, le service netlogon sur les dc réenregistrent périodiquement leurs
enregistrements DNS.
Donc effectivement, les supprimer ne servira à rien, ils réapparaitront.
Il faut empêcher l'enregistrement dans la zone _MSDCS des dc qui ne sont pas
dans le site central comme mentionné dans le branch office deployment guide.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement _ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion "générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= > >> > - The bridgehead servers in the central site shoud register all the DNS
records.
- The branch office domain controlers should register only the "site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site, it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic entries
that do
not have "AtSite" as part of the mnemonic, except do not add DsaCname.
.. For data center domain controllers, do not edit the policy setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit dans
le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC que
les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée :
1- créez des sites (dans sites et services AD) pour les bureaux
(et
les
agence éventuellement) et les sous réseaux associés (important!).
2- dans le DNS, ajoutez les enregistrements SRV de type _kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site > _tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les GPO
afin
qu'elles prennent en compte les connexions réseau lentes si vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après "quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and Spock
qui
empêche
les agences de communiquer entre elles (impossible de modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
J'ai récupéré le branch office deployment guide, j'ai bien compris mon pb.
Mes clients sont correctement configurés ainsi que les GPO appliquées aux
DCs des sites centraux et ceux des sites non centraux.
Cependnat, je n'ai pas relevé d'informations concernant l'enregistrements
des DC dans la zone _msdcs.
Pouvez-vous m'en dire plus techniquement ou éventuellement m'indiquer le
chapitre concerné dans le guide ?
Merci d'avanceBonjour,
oui, le service netlogon sur les dc réenregistrent périodiquement leurs
enregistrements DNS.
Donc effectivement, les supprimer ne servira à rien, ils réapparaitront.
Il faut empêcher l'enregistrement dans la zone _MSDCS des dc qui ne sont
pas
dans le site central comme mentionné dans le branch office deployment
guide.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans
la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement
_ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD
pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion
"générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne
font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents
dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= >> >> > - The bridgehead servers in the central site shoud register all the
DNS
records.
- The branch office domain controlers should register only the
"site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site,
it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office
Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic
entries
that do
not have "AtSite" as part of the mnemonic, except do not add
DsaCname.
.. For data center domain controllers, do not edit the policy
setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans
le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation
de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout
devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans
le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant
à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC
que
les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée
:
1- créez des sites (dans sites et services AD) pour les
bureaux
(et
les
agence éventuellement) et les sous réseaux associés
(important!).
2- dans le DNS, ajoutez les enregistrements SRV de type
_kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site >
_tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les
GPO
afin
qu'elles prennent en compte les connexions réseau lentes si
vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à
mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server
qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après
"quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs
de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and
Spock
qui
empêche
les agences de communiquer entre elles (impossible de
modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
J'ai récupéré le branch office deployment guide, j'ai bien compris mon pb.
Mes clients sont correctement configurés ainsi que les GPO appliquées aux
DCs des sites centraux et ceux des sites non centraux.
Cependnat, je n'ai pas relevé d'informations concernant l'enregistrements
des DC dans la zone _msdcs.
Pouvez-vous m'en dire plus techniquement ou éventuellement m'indiquer le
chapitre concerné dans le guide ?
Merci d'avance
Bonjour,
oui, le service netlogon sur les dc réenregistrent périodiquement leurs
enregistrements DNS.
Donc effectivement, les supprimer ne servira à rien, ils réapparaitront.
Il faut empêcher l'enregistrement dans la zone _MSDCS des dc qui ne sont
pas
dans le site central comme mentionné dans le branch office deployment
guide.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans le
message de news: 7FCA92A7-CE2C-42AB-99B2-D0E6E4A88594@microsoft.com...
Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans
la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement
_ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD
pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion
"générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?
Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne
font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents
dans
_MSDCS / DC ... ?
Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= >> >> > - The bridgehead servers in the central site shoud register all the
DNS
records.
- The branch office domain controlers should register only the
"site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site,
it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office
Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic
entries
that do
not have "AtSite" as part of the mnemonic, except do not add
DsaCname.
.. For data center domain controllers, do not edit the policy
setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit dans
le
message de news:
AF3F15AB-E326-46F8-890A-4A385B6CAF75@microsoft.com...
Merci infiniment
C'est exactement ça.
Après suppression, le client effectue sa requete de localisation
de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout
devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit
dans
le
message de news:
8C31AFAA-3669-4216-8A36-9E85634FE3F0@microsoft.com...
Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc
_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant
à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC
que
les
posts
sont incapables de joindre.
Merci encore pour votre aide
Bonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée
:
1- créez des sites (dans sites et services AD) pour les
bureaux
(et
les
agence éventuellement) et les sous réseaux associés
(important!).
2- dans le DNS, ajoutez les enregistrements SRV de type
_kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site >
_tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les
GPO
afin
qu'elles prennent en compte les connexions réseau lentes si
vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à
mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" <SupportFlot@discussions.microsoft.com> a écrit
dans le
message de news:
2E565C34-FCF1-4E9D-950A-3110BA0FC331@microsoft.com...
Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server
qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après
"quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs
de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and
Spock
qui
empêche
les agences de communiquer entre elles (impossible de
modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance
Bonjour,
J'ai récupéré le branch office deployment guide, j'ai bien compris mon pb.
Mes clients sont correctement configurés ainsi que les GPO appliquées aux
DCs des sites centraux et ceux des sites non centraux.
Cependnat, je n'ai pas relevé d'informations concernant l'enregistrements
des DC dans la zone _msdcs.
Pouvez-vous m'en dire plus techniquement ou éventuellement m'indiquer le
chapitre concerné dans le guide ?
Merci d'avanceBonjour,
oui, le service netlogon sur les dc réenregistrent périodiquement leurs
enregistrements DNS.
Donc effectivement, les supprimer ne servira à rien, ils réapparaitront.
Il faut empêcher l'enregistrement dans la zone _MSDCS des dc qui ne sont
pas
dans le site central comme mentionné dans le branch office deployment
guide.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans le
message de news:Bonjour,
J'ai vu qu'il est impossible de supprimer les enregistrements NS dans
la
zone _MSDCS.
Voici ce que j'ai fait, suppression des DC hors sites centraux dans les
zones :
_msdcs > dc > _sites > messites > _tcp
societe.com > _sites > messites > _tcp
societe.com > DomainDnsZones > _sites > messites > _tcp (uniquement
_ldap)
Malgré la zone directe intégrée à l'AD, j'ai l'impression que les
enregisrtrements se recréent.
En sachat que j'ai exactement le même souci dans Sites et services AD
pour
mes contrôleurs de domaineJe retrouve sans arrêt des connexion
"générées
automatiquement".
Y'a-t-il une autre zone à "purger" ?Bonjour, celà signifie que dans la zone _MSDCS, pour les DC qui ne
font
pas
partie du site central, je supprime les enregistrements NS et CNAME ?
Faut-il que je supprimer également tous les enregistrements présents
dans
_MSDCS / DC ... ?Bonjour,
Dans votre cas, il faut que seuls les dc des sites centraux
s'enregistrent
dans la zone _MSDCS.
Ainsi, dans votre cas, le dc retourné sera toujours accessible.
Voici un extrait envoyé récemment à un de mes clients.
Il est recommandé dans un déploiement de type branch office de
configurer
les DCs afin que seuls les DC du site central s'enregistrent dans la
zone
_MSDCS.
En effet, lorsque la résolution de DC incluant la notion de sites ne
fonctionne pas, les dcs définis dans la zone _MSDCS sont retournés.
En enregistrant uniquement les dc du site central, vous conservez un
controle sur cette liste.
Extrait du branch office deployment guide:
============================= >> >> > - The bridgehead servers in the central site shoud register all the
DNS
records.
- The branch office domain controlers should register only the
"site"
records and should not register the forest wide records.
In this way, when a client makes a dns query without notion of site,
it
will
get a DC with which it can communicate (DC in central site ).
Chapter 4 : Planning a DNS Structure for the Branch Office
Environment
-------------------------------------------------------------------------
Group Policy Setting for the Domain Controllers:
To prevent Net Logon on a domain controller from attempting dynamic
updates
of certain DNS records, use the Group Policy snap-in to edit the
Default
Domain Controllers Policy
[...]
The recommended configuration in a branch office deployment is as
follows:
.. For all branch office domain controllers, add all mnemonic
entries
that do
not have "AtSite" as part of the mnemonic, except do not add
DsaCname.
.. For data center domain controllers, do not edit the policy
setting.
Allow
the domain controllers to register all records.
--
Cordialement,
Emmanuel Dreux
"Support Flot" a écrit dans
le
message de news:Merci infinimentC'est exactement ça.
Après suppression, le client effectue sa requete de localisation
de
services
et ne rapatrie que les DC que vous avez spécifiés donc tout
devrait
retourner dans l'ordre.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans
le
message de news:Merci pour votre réponse rapide.
La première étapes était déjà effectuée pour tous les sites
(agences +
bureaux)
En ce qui concerne la seconde, par exemple dans "_msdcs > dc_sites >
monbureau > _tcp" je retrouve des enregistrements correspondant
à
plusieurs DC
Si j'ai bien compris, c'est la liste des DC sur lesquels les
postes de
"monbureau" vont chercher les gpo.
Il me suffirait donc de supprimer les enregistrements des DC
que
les
posts
sont incapables de joindre.
Merci encore pour votre aideBonjour,
il va vous falloir plusieurs étapes pour arriver à votre idée
:
1- créez des sites (dans sites et services AD) pour les
bureaux
(et
les
agence éventuellement) et les sous réseaux associés
(important!).
2- dans le DNS, ajoutez les enregistrements SRV de type
_kerberos
et
_ldap
correspondant aux DC sur lesquels les clients doivent
s'authentifier
et
récupérer les GPO. Vous devrez modifier ceci dans :
_msdcs > dc >_sites > nom_du_site > _tcp
_sites > nom_du_site > _tcp
éventuellement aussi DomainDnsZones > _sites > nom_du_site >
_tcp
(juste
pour _ldap)
Outre ce facteur, il faudra éventuellement reparamétrer les
GPO
afin
qu'elles prennent en compte les connexions réseau lentes si
vos
liens
ne
sont pas rapide (type ADSL). Ce sera facile à vérifier
puisqu'elles
s'appliqueront ou non suivant le type de lien détecté.
N'hésitez pas à repasser si besoin. Je penses de plus que
plusieurs
personnes devraient passer par ici pour ajouter des infos à
mes
dires
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Support Flot" a écrit
dans le
message de news:Bonjour,
Nous avons actuellement une forêt sous Windows 2003 Server
qui
comprend
un
domaine societe.com.
Nos sites sont repartis sur toute la france et sont de deux
types :
- des agences : Serveur sous 2003 Server (contrôleurs de
domaine) +
clients XP
- des bureaux : clients XP
Nous avons mis en place plusieurs GPO qui s'appliquent sans
problème
dans
les agences mais très rarement dans les bureaux (1 fois sur
20).
J'ai localisé le problème en effectuant un gpresult sur l'un
des
postes
(bureaux) qui n'applique pas les GPO.
Dans mon log, je peux lire : "stratégie appliquée depuis :
brest.societe.com", et la fois d'après
"quimper.societe.com".
Comme ces postes n'ont pas de Serveur sur site (contrôleurs
de
domaine),
ils
vont en chercher un de manière aléatoire pour appliquer les
stratégies.
Mais au niveau réseau, nous avons une technologie Hub and
Spock
qui
empêche
les agences de communiquer entre elles (impossible de
modfier)
et
qui
passent
obligatoirement par un site central.
Quand je fais un gpupdate /force qui tombe le contrôleur du
site
central,
la
liaison est possible et je récupère la gpo. Mais si je tombe
sur un
serveur
d'un autre site, impossible d'y accéder. Le rsop.msc me dit
clairement
:
"le
nom réseau n'existe pas".
Pour un poste client, peut-on paramétrer le contrôleur de
domaine
depuis
lequel il applique les stratégies ? Si oui, comment ?
Merci d'avance