je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate /force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème, lancer
un gpupdate /force dessus et analyser les trames, histoire de voir la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eqXsCzpVIHA.2000@TK2MSFTNGP05.phx.gbl...
Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" <sylvaincortes@hotmail.com> a écrit dans le message de
news: DC1A004B-609C-4566-A70E-CD8313E5E3D3@microsoft.com...
bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:%23mkz0BrUIHA.3908@TK2MSFTNGP04.phx.gbl...
Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate /force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" <jonath.b@free.fr> a écrit dans le message de news:
eWO5ZrpUIHA.5404@TK2MSFTNGP06.phx.gbl...
Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème, lancer
un gpupdate /force dessus et analyser les trames, histoire de voir la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
OZcS7QpUIHA.3916@TK2MSFTNGP02.phx.gbl...
Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" <mthibaut@-enlever-hotmail.fr> a écrit dans le
message de news: 57E60228-2783-4C9D-AFAE-3865EDAFDF66@microsoft.com...
Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:emJeiehUIHA.1204@TK2MSFTNGP03.phx.gbl...
Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate /force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème, lancer
un gpupdate /force dessus et analyser les trames, histoire de voir la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent
le
problème car ils sont tous les deux en SDSL, les 6 autres sites qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.
je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eqXsCzpVIHA.2000@TK2MSFTNGP05.phx.gbl...
Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" <sylvaincortes@hotmail.com> a écrit dans le message de
news: DC1A004B-609C-4566-A70E-CD8313E5E3D3@microsoft.com...
bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:%23mkz0BrUIHA.3908@TK2MSFTNGP04.phx.gbl...
Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" <jonath.b@free.fr> a écrit dans le message de
news:
eWO5ZrpUIHA.5404@TK2MSFTNGP06.phx.gbl...
Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
OZcS7QpUIHA.3916@TK2MSFTNGP02.phx.gbl...
Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent
le
problème car ils sont tous les deux en SDSL, les 6 autres sites qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" <mthibaut@-enlever-hotmail.fr> a écrit dans le
message de news:
57E60228-2783-4C9D-AFAE-3865EDAFDF66@microsoft.com...
Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:emJeiehUIHA.1204@TK2MSFTNGP03.phx.gbl...
Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent
le
problème car ils sont tous les deux en SDSL, les 6 autres sites qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" a écrit dans le message de news:
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message
de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent
le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" <RS@discussions.microsoft.com> a écrit dans le message de news:
C790D308-E388-4BBF-B19A-14A8A6A9098F@microsoft.com...
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.
je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eqXsCzpVIHA.2000@TK2MSFTNGP05.phx.gbl...
Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" <sylvaincortes@hotmail.com> a écrit dans le message
de
news: DC1A004B-609C-4566-A70E-CD8313E5E3D3@microsoft.com...
bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:%23mkz0BrUIHA.3908@TK2MSFTNGP04.phx.gbl...
Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" <jonath.b@free.fr> a écrit dans le message de
news:
eWO5ZrpUIHA.5404@TK2MSFTNGP06.phx.gbl...
Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
OZcS7QpUIHA.3916@TK2MSFTNGP02.phx.gbl...
Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent
le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" <mthibaut@-enlever-hotmail.fr> a écrit dans le
message de news:
57E60228-2783-4C9D-AFAE-3865EDAFDF66@microsoft.com...
Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:emJeiehUIHA.1204@TK2MSFTNGP03.phx.gbl...
Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" a écrit dans le message de news:
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message
de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites, je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui connaissent
le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
J'ai lu qu'il fallait voir si les paquets ICMP de 2048 bits sont rejetés
par les équipements réseau ou non.
j'ai lu également sur un forum qu'un cas similaire au mien avait été réglé
par une mise à jour de firmware. Or, mon problème est que je n'ai pas la
main sur les routeurs du VPN oleane.
Comment faire entendre à FT qu'ils regardent du côté de leurs routeurs (je
rappelle que cela ne concerne que deux sites distants chez nous, ceux en
SDSL, les ADSL fonctionnent !)
Et, tous les sites distants appartiennent à la même OU.
J'ai bien sûr déjà appelé FT, ils ont répondu que les trames passent et
qu'ils fournissent juste un tuyau dans lequel les trames passent ou pas...
un peu facile me semble t il.
A suivre.
"phil" a écrit dans le message de news:Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" a écrit dans le message de news:
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs
continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message
de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites,
je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui
connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos
DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine
pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
J'ai lu qu'il fallait voir si les paquets ICMP de 2048 bits sont rejetés
par les équipements réseau ou non.
j'ai lu également sur un forum qu'un cas similaire au mien avait été réglé
par une mise à jour de firmware. Or, mon problème est que je n'ai pas la
main sur les routeurs du VPN oleane.
Comment faire entendre à FT qu'ils regardent du côté de leurs routeurs (je
rappelle que cela ne concerne que deux sites distants chez nous, ceux en
SDSL, les ADSL fonctionnent !)
Et, tous les sites distants appartiennent à la même OU.
J'ai bien sûr déjà appelé FT, ils ont répondu que les trames passent et
qu'ils fournissent juste un tuyau dans lequel les trames passent ou pas...
un peu facile me semble t il.
A suivre.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eRc4OFQWIHA.5208@TK2MSFTNGP04.phx.gbl...
Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" <RS@discussions.microsoft.com> a écrit dans le message de news:
C790D308-E388-4BBF-B19A-14A8A6A9098F@microsoft.com...
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.
je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs
continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eqXsCzpVIHA.2000@TK2MSFTNGP05.phx.gbl...
Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" <sylvaincortes@hotmail.com> a écrit dans le message
de
news: DC1A004B-609C-4566-A70E-CD8313E5E3D3@microsoft.com...
bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:%23mkz0BrUIHA.3908@TK2MSFTNGP04.phx.gbl...
Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" <jonath.b@free.fr> a écrit dans le message de
news:
eWO5ZrpUIHA.5404@TK2MSFTNGP06.phx.gbl...
Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites,
je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
OZcS7QpUIHA.3916@TK2MSFTNGP02.phx.gbl...
Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui
connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" <mthibaut@-enlever-hotmail.fr> a écrit dans le
message de news:
57E60228-2783-4C9D-AFAE-3865EDAFDF66@microsoft.com...
Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos
DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:emJeiehUIHA.1204@TK2MSFTNGP03.phx.gbl...
Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine
pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
J'ai lu qu'il fallait voir si les paquets ICMP de 2048 bits sont rejetés
par les équipements réseau ou non.
j'ai lu également sur un forum qu'un cas similaire au mien avait été réglé
par une mise à jour de firmware. Or, mon problème est que je n'ai pas la
main sur les routeurs du VPN oleane.
Comment faire entendre à FT qu'ils regardent du côté de leurs routeurs (je
rappelle que cela ne concerne que deux sites distants chez nous, ceux en
SDSL, les ADSL fonctionnent !)
Et, tous les sites distants appartiennent à la même OU.
J'ai bien sûr déjà appelé FT, ils ont répondu que les trames passent et
qu'ils fournissent juste un tuyau dans lequel les trames passent ou pas...
un peu facile me semble t il.
A suivre.
"phil" a écrit dans le message de news:Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" a écrit dans le message de news:
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les remets
dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs
continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message
de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne fonctionnent
pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by "TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites,
je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de voir
la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui
connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos
DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine
pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session sur
le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
Les recherches et les réponses données m'ont permis d'étayer ma demande
auprès de France Télécom.
Résultat, ils ont changé le routeur du site siège vendredi en fin de
journée. L'intervention sur notre site a été rendue obligatoire car le
routeur est tombé en panne suite à une mise à jour du firmware par leurs
soins.
Donc, nous avons un nouveau routeur bintec x2404 (qui est plus ancien que
celui que nous avions.
Depuis, les GPOs fonctionnent de nouveau normalement sur les 2 sites
concernés. Pour les 6 autres sites, c'est toujours OK aussi.
En effet, je n'ai plus d'erreur 1054, et le ping -l 2048 @ip passe dans
tous les sens.
Un grand merci à tous.
"phil" a écrit dans le message de news:
J'ai lu qu'il fallait voir si les paquets ICMP de 2048 bits sont rejetés
par les équipements réseau ou non.
j'ai lu également sur un forum qu'un cas similaire au mien avait été
réglé par une mise à jour de firmware. Or, mon problème est que je n'ai
pas la main sur les routeurs du VPN oleane.
Comment faire entendre à FT qu'ils regardent du côté de leurs routeurs
(je rappelle que cela ne concerne que deux sites distants chez nous, ceux
en SDSL, les ADSL fonctionnent !)
Et, tous les sites distants appartiennent à la même OU.
J'ai bien sûr déjà appelé FT, ils ont répondu que les trames passent et
qu'ils fournissent juste un tuyau dans lequel les trames passent ou
pas... un peu facile me semble t il.
A suivre.
"phil" a écrit dans le message de news:Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" a écrit dans le message de news:
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les
remets dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs
continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message
de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne
fonctionnent pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien
interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by
"TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites,
je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de
voir la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui
connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos
DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un
VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine
pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de
la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session
sur le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le
même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le
driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
Les recherches et les réponses données m'ont permis d'étayer ma demande
auprès de France Télécom.
Résultat, ils ont changé le routeur du site siège vendredi en fin de
journée. L'intervention sur notre site a été rendue obligatoire car le
routeur est tombé en panne suite à une mise à jour du firmware par leurs
soins.
Donc, nous avons un nouveau routeur bintec x2404 (qui est plus ancien que
celui que nous avions.
Depuis, les GPOs fonctionnent de nouveau normalement sur les 2 sites
concernés. Pour les 6 autres sites, c'est toujours OK aussi.
En effet, je n'ai plus d'erreur 1054, et le ping -l 2048 @ip passe dans
tous les sens.
Un grand merci à tous.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
egZEXsRWIHA.2268@TK2MSFTNGP02.phx.gbl...
J'ai lu qu'il fallait voir si les paquets ICMP de 2048 bits sont rejetés
par les équipements réseau ou non.
j'ai lu également sur un forum qu'un cas similaire au mien avait été
réglé par une mise à jour de firmware. Or, mon problème est que je n'ai
pas la main sur les routeurs du VPN oleane.
Comment faire entendre à FT qu'ils regardent du côté de leurs routeurs
(je rappelle que cela ne concerne que deux sites distants chez nous, ceux
en SDSL, les ADSL fonctionnent !)
Et, tous les sites distants appartiennent à la même OU.
J'ai bien sûr déjà appelé FT, ils ont répondu que les trames passent et
qu'ils fournissent juste un tuyau dans lequel les trames passent ou
pas... un peu facile me semble t il.
A suivre.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eRc4OFQWIHA.5208@TK2MSFTNGP04.phx.gbl...
Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" <RS@discussions.microsoft.com> a écrit dans le message de news:
C790D308-E388-4BBF-B19A-14A8A6A9098F@microsoft.com...
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.
je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les
remets dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs
continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
eqXsCzpVIHA.2000@TK2MSFTNGP05.phx.gbl...
Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" <sylvaincortes@hotmail.com> a écrit dans le message
de
news: DC1A004B-609C-4566-A70E-CD8313E5E3D3@microsoft.com...
bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne
fonctionnent pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:%23mkz0BrUIHA.3908@TK2MSFTNGP04.phx.gbl...
Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien
interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by
"TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" <jonath.b@free.fr> a écrit dans le message de
news:
eWO5ZrpUIHA.5404@TK2MSFTNGP06.phx.gbl...
Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites,
je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de
voir la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" <phc@nospam_fra.net> a écrit dans le message de news:
OZcS7QpUIHA.3916@TK2MSFTNGP02.phx.gbl...
Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui
connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" <mthibaut@-enlever-hotmail.fr> a écrit dans le
message de news:
57E60228-2783-4C9D-AFAE-3865EDAFDF66@microsoft.com...
Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos
DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" <phc@nospam_fra.net> a écrit dans le message de
news:emJeiehUIHA.1204@TK2MSFTNGP03.phx.gbl...
Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un
VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine
pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de
la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session
sur le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le
même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le
driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.
Bonjour,
Les recherches et les réponses données m'ont permis d'étayer ma demande
auprès de France Télécom.
Résultat, ils ont changé le routeur du site siège vendredi en fin de
journée. L'intervention sur notre site a été rendue obligatoire car le
routeur est tombé en panne suite à une mise à jour du firmware par leurs
soins.
Donc, nous avons un nouveau routeur bintec x2404 (qui est plus ancien que
celui que nous avions.
Depuis, les GPOs fonctionnent de nouveau normalement sur les 2 sites
concernés. Pour les 6 autres sites, c'est toujours OK aussi.
En effet, je n'ai plus d'erreur 1054, et le ping -l 2048 @ip passe dans
tous les sens.
Un grand merci à tous.
"phil" a écrit dans le message de news:
J'ai lu qu'il fallait voir si les paquets ICMP de 2048 bits sont rejetés
par les équipements réseau ou non.
j'ai lu également sur un forum qu'un cas similaire au mien avait été
réglé par une mise à jour de firmware. Or, mon problème est que je n'ai
pas la main sur les routeurs du VPN oleane.
Comment faire entendre à FT qu'ils regardent du côté de leurs routeurs
(je rappelle que cela ne concerne que deux sites distants chez nous, ceux
en SDSL, les ADSL fonctionnent !)
Et, tous les sites distants appartiennent à la même OU.
J'ai bien sûr déjà appelé FT, ils ont répondu que les trames passent et
qu'ils fournissent juste un tuyau dans lequel les trames passent ou
pas... un peu facile me semble t il.
A suivre.
"phil" a écrit dans le message de news:Bonjour,
merci pour l'idée.
le kb 910206 a été parcouru aussi afin de poursuivre les essais.
pour le moment, je n'ai rien trouvé...
c'est galère.
A suivre.
"RS" a écrit dans le message de news:
Bonjour,
je ne suis pas sur, mais je pense qu'il y a une GPO qui controle la
vitesse
de transfert entre le client et le serveur, a verifier sur le D.C. ...
Cordialement.je viens de faire les essais.
pour cela , j'ai utilisé deux comptes utilisateurs avec une machine à
l'image toute fraîche.
on sort les utilisateurs des OUs concernées par les GPOs, on les
remets dans
les OUs ensuite (il s'agit de GPOs utilisateurs).
sur les sites ADSL et LL, tout se déroule normalement.
Sur les sites SDSL, les GPOs s'exécutent une fois.
Ensuite, en sortant les comptes de leur OU respective, les GPOs sont
toujours exécutées.
En supprimant le profil local qui vient de se créer, les GPOs
continuent
d'être appliquées à l'ouverture de session.
Pas moyen de mettre à jour sur ces sites en SDSL.
L'opérateur me répond qu'il ne fournit qu'un tuyau, que les trames
passent...
Je pense qu'il y a quand même autre chose...
A suivre et merci pour votre aide.
"phil" a écrit dans le message de news:Bonjour,
Merci pour la réponse.
L ping fonctionne parfaitement.
Je vais prendre un pc avec une image "fraîche" pour tester sur des
sites
distants peu éloignés géographiquement. (1 en LL, A, en SDSL, 2 en
ADSL).
Je vous tiens au courant.
Bonne journée.
"Sylvain Cortes" a écrit dans le message
de
news:bonjour,
vérifies aussi qu'ICMP ne soit pas bloqué (le "ping") - en effet,
certains operateur bloque ce "port" - ce qui peut tres fortement
perturber les DCs ou la détermination d'un lien lent par le process
de
GPOs.
Effetivement le fait que seul les deux sites en SDSL ne
fonctionnent pas
semble pousser pour investiguer coté operateur...
--
Sylvain Cortes
MVP GPOs - http://www.gpomasters.com
Rejoignez la communauté Active Directory et Identity Management !!!
http://www.cadim.org
"phil" a écrit dans le message de
news:%Bonjour,
pour les ports, je n'en sais rien. comment le savoir ?
le wireshark, je l'ai installé, mais je ne sais rien
interpréter...
toutefois, je l'ai exécuté en parallèle de la commande gpupdate
/force.
j'ai relevé ceci (lignes surlignées en rouge) :
Transmission Control Protocol, Src Port: 6129 (6129), Dst Port:
netop-school (1971), Seq: 1, Ack: 1, Len: 16
Checksum: 0xbf59 [incorrect, should be 0x17bc (maybe caused by
"TCP
checksum offload"?)]
Bad Checksum: True
Ceci dit, j'ai fait le même test sur un pc d'un site distant qui
fonctionne correctement et j'ai les mêmes lignes rouges...
Merci.
"Jonathan BISMUTH" a écrit dans le message de
news:Bonjour phil,
Aucun port n'est fermé en inter-site sur le ssites connectés en
SDSL?
Dans la mesure ou tu ne dispose pas de DC locaux sur ces sites,
je
serais tenté d'installer un wireshark sur un poste à problème,
lancer
un gpupdate /force dessus et analyser les trames, histoire de
voir la
tête de ce qui passe vers le DC et où ça bloque. Il sera ensuite
relativement plus simple d'argumenter avec ton opérateur.
Cordialement,
--
Jonathan BISMUTH
MVP Windows Server - Directory Services
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
"phil" a écrit dans le message de news:Bonjour, et merci pour vos réponses.
Les configurations sont ok et les mêmes pour chacun des sites
distants.
D'ailleurs, cela a fonctionné pendant plus de 3 ans et nous
n'avons
rien changé.
Nous avons une différence visible avec les 2 sites qui
connaissent le
problème car ils sont tous les deux en SDSL, les 6 autres sites
qui
fonctionnent sont en ADSL.
Ce qui semble paradoxal, les moins bien lotis fonctionnent mieux
sur
ce plan là.
Notre opérateur aurait il pu changer quelque chose ?
Faut il chercher en ce sens ?
Auquel cas, quels arguments tenir avec l'opérateur... :-)
Merci pour votre aide.
"Michaël THIBAUT" a écrit dans le
message de news:Bonjour,
Vous êtes vous assuré que la résolution DNS fonctionne
correctement
sur vos sites distants?
Utilisez pour cela NSLOOKUP et LDP.EXE
Comment sont configurés les paramêtres réseaux et DNS de vos
DCs?
--
Cordialement,
Michaël
MCTS Business Desktop Deployment Solution Accelerator 2.0
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging
"phil" a écrit dans le message de
news:Bonjour à tous.
Le contexte :
Un domaine windows 2003 avec 2 contrôleurs sur le site siège.
8 sites distants appartenant au même domaine reliés via un
VPN.
Des gpo utilisateurs positionnées sur des OU sont appliquées.
J'ai recencé deux sites pour lesquels les ordinateurs ont des
erreurs répertoriées dans les journaux.
l'erreur est :
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1054
Date: 08/01/2008
Time: 16:08:40
User: ADM
Computer: ORDI1
Description:
Windows ne peut pas obtenir le nom du contrôleur de domaine
pour
votre réseau. (Erreur réseau inattendue. ). Le traitement de
la
stratégie de groupe est interrompu.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Et pour ces deux sites, les gpo ne s'appliquent plus depuis
quelques
temps.
Les six autres sites fonctionnent normalement.
Cela fonctionnait bien auparavant.
Les utilisateurs dont les profils existent déjà sur les
ordinateurs
concernés se retrouvent avec les gpo appliquées.
un nouvel utilisateur dans la même OU qui ouvre une session
sur le
même ordinateur se retrouve sans gpo.
Evidement, si on supprime un profil d'utilisateur existant sur
l'ordinateur et qu'on ouvre de nouveau une session avec le
même
compte, on n'aura pas non plus de gpo appliquée.
Je pensais un problème lié au réseau (j'ai mis à jour le
driver
réseau sur un des ordinateurs atteint)
L'opérateur nous fournissant le VPN peut il avoir modifié
quelque
chose qui irait dans ce sens ?
Avez-vous des idées ?
Merci pour vos réponses.