Depuis quelques mois, je crée des packages MSI que je déploie via GPO. Cela
fonctionne à merveille mais après vérification j'ai remarqué que les GPO
n'étaient pas appliquées sur notre site secondaire.
Notre entreprise possède son propre réseau interne mais nous avons des
locaux qui se situent dans un autre bâtiment où le réseau ne nous appartient
pas. Les deux bâtiments sont relié en fibre optique mais passe par deux
firewall (le notre et celui du provider de l'autre bâtiment).
Sur les Vlan 10.12.1.0 + 10.12.2.0 (site A), la stratégie est appliquée
correctement
Sur les Vlan 10.12.7.0 + 10.12.8.0 (site B), la stratégie retourne une
erreur "Network Error"
Je pense qu'il y a un blocage au niveau du firewall mais je ne trouve pas de
solution. Ce n'est pas un problème de vitesse car le requête sont
interceptées à <1ms.
Avez-vous une idée d'où peux provenir ce problème ? Est-ce que l'application
de la stratégie s'effectue à partir d'un protocole spécifique pouvant être
bloqué par un firewall?
Sur les Pc du site secondaire, tout fonctionne correctement (excepté GPO).
Les PC se connectent sur le domaine et reçoivent un IP de notre DHCP server,
il y a aucun problème avec l'Exchange Server.
Normalement, nous avons un provider qui s'occupe de cette configuration mais
pour l'instant ils jouent au Ping-pong avec le provider du site secondaire
en spécifiant que le problème ne vient pas d'eux.
En vous remerciant d'avance pour vos idées.
Cordialement,
PS:
Le GPO est utilisé pour publié des packages MSI et créer une liste de
software disponible dans le Add/remove Program.
La désactivation de la détection de connexion lente ne change rien.
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Rosseels Olivier" wrote in message news:
Bonjour,
Je viens d'avoir les résultats aurjourd'hui. Il y avait un blocage dans notre firewall et cela est bien confirmé !
Pour corriger ce problème nous avons :
Dans SmartDefense les paquets "Null payload icmp" étaient bloqués. (Firewall Checkpoint) Après désactivation de cette règle, le GPO s'applique normalement.
Encore un grand merci de nous avoir aidée pour résoudre ce problème.
Olivier,
"Mathieu CHATEAU" wrote in message news:4a029792$0$3497$
Vérifiez que le firewall laisse passer les paquets icmp de type 3 code 4 (Fragmentation Needed and Don't Fragment was Set)
avez-vous désactiver la détection de trou noir sur vos postes de travail ?
How to Troubleshoot Black Hole Router Issues http://support.microsoft.com/?scid=kb%3Ben-us%3B314825&x=8&y
Changes in PMTU black hole router detection in Windows Server 2003 and in Windows Vista http://support.microsoft.com/?scid=kb%3Ben-us%3B925280&x&y
TCP/IP and NBT configuration parameters for Windows XP http://support.microsoft.com/?scid=kb%3Ben-us%3B314053&x#&y
Rosseels Olivier a écrit :
Bonjour,
Je viens de vérifier:
Pour le site A : MTU 1300 Pour le site B : MTU 1500
Cordialement,
"Mathieu CHATEAU" wrote in message news:4a027eb3$0$7183$
Bonjour,
comment avez-vous testé le ping de grande taille ? ping -l 2048 X.X.X.X ?
est-ce que la MTU sur votre wan est de 1500 ?
Rosseels Olivier a écrit :
Monsieur Lognoul,
Merci pour votre réponse. Le ping de grande taille fonctionne correctement vers le DC et le résultat de nltest semble correcte. J'ai demandé à mon provider IT d'activer une porte sur chaque switch (le long de tout le réseau) pour connecter un portable et vérifier ainsi a quel niveau cela bloque. Je pense également que le problème vient d'un des deux firewall. Dés que nous avons trouvés la solution, je place celle-ci sur ce newsgroup. Je pense que cela pourra être utile pour d'autre personnes.
Cordialement,
"Lognoul Marc [MVP]" wrote in message news:%
Bonjour,
C'est équivalent à un ping en effet. Il est probable que qq chose empêche le traffic ICMP (voire d'autres protocoles également): Firewall, composants réseau défaillant ou mal paramétré... Vérifez si à partir de la machine cliente vous pouvez pinger tous les DCs. Utilisez des pings de grande tailler (au moins 1024).
La fonction DSGetDCName ne fonctionne pas non plus correctement.
Vous pouvez également installer les Support Tools sur la machine cliente et éxécuter nltest /dsgetdc:NUMDNSDUDOMAINE
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Rosseels Olivier" wrote in message news:#
Monsieur Dreux, Monsieur Lognoul,
Avant tout merci de m'avoir répondut. J'ai suivis vos conseilles mais le résultat est plutôt étonnant. J'ai copié un aperçu du userenv.log d'une machine du site secondaire :
USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: Starting user Group Policy (Background) processing... USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: USERENV(1d8.d34) 07:28:37:397 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0 USERENV(1d8.d34) 07:28:37:397 EnterCriticalPolicySectionEx: User critical section has been claimed. Handle = 0x8a4 USERENV(1d8.d34) 07:28:37:413 EnterCriticalPolicySectionEx: Leaving successfully. USERENV(1d8.d34) 07:28:37:413 ProcessGPOs: Machine role is 2. USERENV(1d8.d34) 07:28:37:413 PingComputer: Adapter speed 100000000 bps USERENV(1d8.d34) 07:28:42:850 PingComputer: First send 0x97c235c1 failed with 11010 USERENV(1d8.d34) 07:28:48:350 PingComputer: First send 0x97c235c1 failed with 11010 USERENV(1d8.d34) 07:28:53:850 PingComputer: First send 0x97c235c1 failed with 11010 USERENV(1d8.d34) 07:28:53:850 PingComputer: No data available USERENV(1d8.d34) 07:28:53:959 PingComputer: Adapter speed 100000000 bps USERENV(1d8.d34) 07:28:59:350 PingComputer: First send 0x96c235c1 failed with 11010 USERENV(1d8.d34) 07:29:04:850 PingComputer: First send 0x96c235c1 failed with 11010 USERENV(1d8.d34) 07:29:10:350 PingComputer: First send 0x96c235c1 failed with 11010 USERENV(1d8.d34) 07:29:10:365 PingComputer: No data available USERENV(1d8.d34) 07:29:10:365 ProcessGPOs: DSGetDCName failed with 59. USERENV(1d8.d34) 07:29:10:365 ProcessGPOs: No WMI logging done in this policy cycle. USERENV(1d8.d34) 07:29:10:397 ProcessGPOs: Processing failed with error 59. USERENV(1d8.d34) 07:29:10:428 LeaveCriticalPolicySection: Critical section 0x8a4 has been released. USERENV(1d8.d34) 07:29:10:428 ProcessGPOs: User Group Policy has been applied. USERENV(1d8.d34) 07:29:10:428 ProcessGPOs: Leaving with 0.
Visiblement, le ping n'aboutit pas car il ne passe pas au second "send" ==> First send 0x97c235c1 failed with 11010
J'ai testé cela sur 4 autres machines mais le problème est le même. Est-ce une simple commande ping ? Avez-vous une idée d'où provient ce problème ?
Cordialement,
"Lognoul Marc [MVP]" wrote in message news:
Pour complémenter la réponse d'Emmanuel, activez cette option et cherchez les lignes suivantes dans le fichier de journalisation: USERENV(20c.210) 09:52:23:621 PingComputer: Adapter speed 10000000 bps USERENV(20c.210) 09:52:23:851 PingComputer: First time: 236 USERENV(20c.210) 09:52:24:097 PingComputer: Second time: 245 USERENV(20c.210) 09:52:24:328 PingComputer: First time: 240 USERENV(20c.210) 09:52:24:574 PingComputer: Second time: 247 USERENV(20c.210) 09:52:24:804 PingComputer: First time: 237 USERENV(20c.210) 09:52:25:050 PingComputer: Second time: 245 USERENV(20c.210) 09:52:25:050 PingComputer: Transfer rate: 4000 Kbps Loop count: 3
Pour activer l'option, voir l'article suivant: http://support.microsoft.com/kb/221833/fr. Mettez la valeur 10002 (en hexa). Une fois le problème résolu, retorunez à la valeur originale. Des explications additionelles sur la détection de slows links: http://support.microsoft.com/kb/227260/fr
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Edreux (ILINFO)" wrote in message news:
Bonjour,
en général, les problème de déploiement de MSI par GPO (entre parenthèse, c'est au mieux bien pour du dépannage à défaut d'autre solution) sont dus à des problèmes de "slow link detection".
Activez par exemple le diagnostic userenvdebug (cherchez Userenvdebuglevel sur Internet) et dans le log généré, regardez si vous avez "slow link detection" mentionné.
Cordialement, Emmanuel Dreux http://www.ilinfo.fr
"Rosseels Olivier" a écrit dans le message de news:%
Bonjour à tous,
Depuis quelques mois, je crée des packages MSI que je déploie via GPO. Cela fonctionne à merveille mais après vérification j'ai remarqué que les GPO n'étaient pas appliquées sur notre site secondaire.
Notre entreprise possède son propre réseau interne mais nous avons des locaux qui se situent dans un autre bâtiment où le réseau ne nous appartient pas. Les deux bâtiments sont relié en fibre optique mais passe par deux firewall (le notre et celui du provider de l'autre bâtiment).
Sur les Vlan 10.12.1.0 + 10.12.2.0 (site A), la stratégie est appliquée correctement
Sur les Vlan 10.12.7.0 + 10.12.8.0 (site B), la stratégie retourne une erreur "Network Error"
Bonjour,
Merci pour le feedback.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Rosseels Olivier" <olivier_rosseels@hotmail.com> wrote in message
news:eWt3xdu0JHA.1096@TK2MSFTNGP06.phx.gbl...
Bonjour,
Je viens d'avoir les résultats aurjourd'hui. Il y avait un blocage dans
notre firewall et cela est bien confirmé !
Pour corriger ce problème nous avons :
Dans SmartDefense les paquets "Null payload icmp" étaient bloqués.
(Firewall Checkpoint)
Après désactivation de cette règle, le GPO s'applique normalement.
Encore un grand merci de nous avoir aidée pour résoudre ce problème.
Olivier,
"Mathieu CHATEAU" <gollum123@free.fr> wrote in message
news:4a029792$0$3497$426a74cc@news.free.fr...
Vérifiez que le firewall laisse passer les paquets icmp de type 3 code 4
(Fragmentation Needed and Don't Fragment was Set)
avez-vous désactiver la détection de trou noir sur vos postes de travail
?
How to Troubleshoot Black Hole Router Issues
http://support.microsoft.com/?scid=kb%3Ben-us%3B314825&x=8&y
Changes in PMTU black hole router detection in Windows Server 2003 and in
Windows Vista
http://support.microsoft.com/?scid=kb%3Ben-us%3B925280&x&y
TCP/IP and NBT configuration parameters for Windows XP
http://support.microsoft.com/?scid=kb%3Ben-us%3B314053&x#&y
Rosseels Olivier a écrit :
Bonjour,
Je viens de vérifier:
Pour le site A : MTU 1300
Pour le site B : MTU 1500
Cordialement,
"Mathieu CHATEAU" <gollum123@free.fr> wrote in message
news:4a027eb3$0$7183$426a74cc@news.free.fr...
Bonjour,
comment avez-vous testé le ping de grande taille ? ping -l 2048 X.X.X.X
?
est-ce que la MTU sur votre wan est de 1500 ?
Rosseels Olivier a écrit :
Monsieur Lognoul,
Merci pour votre réponse. Le ping de grande taille fonctionne
correctement vers le DC et le résultat de nltest semble correcte.
J'ai demandé à mon provider IT d'activer une porte sur chaque switch
(le long de tout le réseau) pour connecter un portable et vérifier
ainsi a quel niveau cela bloque. Je pense également que le problème
vient d'un des deux firewall.
Dés que nous avons trouvés la solution, je place celle-ci sur ce
newsgroup. Je pense que cela pourra être utile pour d'autre personnes.
Cordialement,
"Lognoul Marc [MVP]" <lognoulm@hotmail.com> wrote in message
news:%23cDtzhhzJHA.4116@TK2MSFTNGP04.phx.gbl...
Bonjour,
C'est équivalent à un ping en effet. Il est probable que qq chose
empêche le traffic ICMP (voire d'autres protocoles également):
Firewall, composants réseau défaillant ou mal paramétré...
Vérifez si à partir de la machine cliente vous pouvez pinger tous les
DCs. Utilisez des pings de grande tailler (au moins 1024).
La fonction DSGetDCName ne fonctionne pas non plus correctement.
Vous pouvez également installer les Support Tools sur la machine
cliente et éxécuter nltest /dsgetdc:NUMDNSDUDOMAINE
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Rosseels Olivier" <olivier_rosseels@hotmail.com> wrote in message
news:#VV2c3gzJHA.3404@TK2MSFTNGP02.phx.gbl...
Monsieur Dreux, Monsieur Lognoul,
Avant tout merci de m'avoir répondut. J'ai suivis vos conseilles
mais le résultat est plutôt étonnant. J'ai copié un aperçu du
userenv.log d'une machine du site secondaire :
USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: Starting user Group
Policy (Background) processing...
USERENV(1d8.d34) 07:28:37:397 ProcessGPOs:
USERENV(1d8.d34) 07:28:37:397 ProcessGPOs:
USERENV(1d8.d34) 07:28:37:397 EnterCriticalPolicySectionEx: Entering
with timeout 600000 and flags 0x0
USERENV(1d8.d34) 07:28:37:397 EnterCriticalPolicySectionEx: User
critical section has been claimed. Handle = 0x8a4
USERENV(1d8.d34) 07:28:37:413 EnterCriticalPolicySectionEx: Leaving
successfully.
USERENV(1d8.d34) 07:28:37:413 ProcessGPOs: Machine role is 2.
USERENV(1d8.d34) 07:28:37:413 PingComputer: Adapter speed 100000000
bps
USERENV(1d8.d34) 07:28:42:850 PingComputer: First send 0x97c235c1
failed with 11010
USERENV(1d8.d34) 07:28:48:350 PingComputer: First send 0x97c235c1
failed with 11010
USERENV(1d8.d34) 07:28:53:850 PingComputer: First send 0x97c235c1
failed with 11010
USERENV(1d8.d34) 07:28:53:850 PingComputer: No data available
USERENV(1d8.d34) 07:28:53:959 PingComputer: Adapter speed 100000000
bps
USERENV(1d8.d34) 07:28:59:350 PingComputer: First send 0x96c235c1
failed with 11010
USERENV(1d8.d34) 07:29:04:850 PingComputer: First send 0x96c235c1
failed with 11010
USERENV(1d8.d34) 07:29:10:350 PingComputer: First send 0x96c235c1
failed with 11010
USERENV(1d8.d34) 07:29:10:365 PingComputer: No data available
USERENV(1d8.d34) 07:29:10:365 ProcessGPOs: DSGetDCName failed with
59.
USERENV(1d8.d34) 07:29:10:365 ProcessGPOs: No WMI logging done in
this policy cycle.
USERENV(1d8.d34) 07:29:10:397 ProcessGPOs: Processing failed with
error 59.
USERENV(1d8.d34) 07:29:10:428 LeaveCriticalPolicySection: Critical
section 0x8a4 has been released.
USERENV(1d8.d34) 07:29:10:428 ProcessGPOs: User Group Policy has
been applied.
USERENV(1d8.d34) 07:29:10:428 ProcessGPOs: Leaving with 0.
Visiblement, le ping n'aboutit pas car il ne passe pas au second
"send" ==> First send 0x97c235c1 failed with 11010
J'ai testé cela sur 4 autres machines mais le problème est le même.
Est-ce une simple commande ping ? Avez-vous une idée d'où provient
ce problème ?
Cordialement,
"Lognoul Marc [MVP]" <lognoulm@hotmail.com> wrote in message
news:eDHiNCbzJHA.1424@TK2MSFTNGP02.phx.gbl...
Pour complémenter la réponse d'Emmanuel, activez cette option et
cherchez les lignes suivantes dans le fichier de journalisation:
USERENV(20c.210) 09:52:23:621 PingComputer: Adapter speed 10000000
bps
USERENV(20c.210) 09:52:23:851 PingComputer: First time: 236
USERENV(20c.210) 09:52:24:097 PingComputer: Second time: 245
USERENV(20c.210) 09:52:24:328 PingComputer: First time: 240
USERENV(20c.210) 09:52:24:574 PingComputer: Second time: 247
USERENV(20c.210) 09:52:24:804 PingComputer: First time: 237
USERENV(20c.210) 09:52:25:050 PingComputer: Second time: 245
USERENV(20c.210) 09:52:25:050 PingComputer: Transfer rate: 4000
Kbps Loop count: 3
Pour activer l'option, voir l'article suivant:
http://support.microsoft.com/kb/221833/fr. Mettez la valeur 10002
(en hexa). Une fois le problème résolu, retorunez à la valeur
originale.
Des explications additionelles sur la détection de slows links:
http://support.microsoft.com/kb/227260/fr
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"Edreux (ILINFO)" <edreux@nospam.fr> wrote in message
news:ut4pujazJHA.4632@TK2MSFTNGP02.phx.gbl...
Bonjour,
en général, les problème de déploiement de MSI par GPO (entre
parenthèse, c'est au mieux bien pour du dépannage à défaut d'autre
solution) sont dus à des problèmes de "slow link detection".
Activez par exemple le diagnostic userenvdebug (cherchez
Userenvdebuglevel sur Internet) et dans le log généré, regardez si
vous avez "slow link detection" mentionné.
Cordialement,
Emmanuel Dreux
http://www.ilinfo.fr
"Rosseels Olivier" <olivier_rosseels@hotmail.com> a écrit dans le
message de news:%23zHoawWzJHA.4116@TK2MSFTNGP04.phx.gbl...
Bonjour à tous,
Depuis quelques mois, je crée des packages MSI que je déploie via
GPO. Cela fonctionne à merveille mais après vérification j'ai
remarqué que les GPO n'étaient pas appliquées sur notre site
secondaire.
Notre entreprise possède son propre réseau interne mais nous
avons des locaux qui se situent dans un autre bâtiment où le
réseau ne nous appartient pas. Les deux bâtiments sont relié en
fibre optique mais passe par deux firewall (le notre et celui du
provider de l'autre bâtiment).
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Rosseels Olivier" wrote in message news:
Bonjour,
Je viens d'avoir les résultats aurjourd'hui. Il y avait un blocage dans notre firewall et cela est bien confirmé !
Pour corriger ce problème nous avons :
Dans SmartDefense les paquets "Null payload icmp" étaient bloqués. (Firewall Checkpoint) Après désactivation de cette règle, le GPO s'applique normalement.
Encore un grand merci de nous avoir aidée pour résoudre ce problème.
Olivier,
"Mathieu CHATEAU" wrote in message news:4a029792$0$3497$
Vérifiez que le firewall laisse passer les paquets icmp de type 3 code 4 (Fragmentation Needed and Don't Fragment was Set)
avez-vous désactiver la détection de trou noir sur vos postes de travail ?
How to Troubleshoot Black Hole Router Issues http://support.microsoft.com/?scid=kb%3Ben-us%3B314825&x=8&y
Changes in PMTU black hole router detection in Windows Server 2003 and in Windows Vista http://support.microsoft.com/?scid=kb%3Ben-us%3B925280&x&y
TCP/IP and NBT configuration parameters for Windows XP http://support.microsoft.com/?scid=kb%3Ben-us%3B314053&x#&y
Rosseels Olivier a écrit :
Bonjour,
Je viens de vérifier:
Pour le site A : MTU 1300 Pour le site B : MTU 1500
Cordialement,
"Mathieu CHATEAU" wrote in message news:4a027eb3$0$7183$
Bonjour,
comment avez-vous testé le ping de grande taille ? ping -l 2048 X.X.X.X ?
est-ce que la MTU sur votre wan est de 1500 ?
Rosseels Olivier a écrit :
Monsieur Lognoul,
Merci pour votre réponse. Le ping de grande taille fonctionne correctement vers le DC et le résultat de nltest semble correcte. J'ai demandé à mon provider IT d'activer une porte sur chaque switch (le long de tout le réseau) pour connecter un portable et vérifier ainsi a quel niveau cela bloque. Je pense également que le problème vient d'un des deux firewall. Dés que nous avons trouvés la solution, je place celle-ci sur ce newsgroup. Je pense que cela pourra être utile pour d'autre personnes.
Cordialement,
"Lognoul Marc [MVP]" wrote in message news:%
Bonjour,
C'est équivalent à un ping en effet. Il est probable que qq chose empêche le traffic ICMP (voire d'autres protocoles également): Firewall, composants réseau défaillant ou mal paramétré... Vérifez si à partir de la machine cliente vous pouvez pinger tous les DCs. Utilisez des pings de grande tailler (au moins 1024).
La fonction DSGetDCName ne fonctionne pas non plus correctement.
Vous pouvez également installer les Support Tools sur la machine cliente et éxécuter nltest /dsgetdc:NUMDNSDUDOMAINE
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Rosseels Olivier" wrote in message news:#
Monsieur Dreux, Monsieur Lognoul,
Avant tout merci de m'avoir répondut. J'ai suivis vos conseilles mais le résultat est plutôt étonnant. J'ai copié un aperçu du userenv.log d'une machine du site secondaire :
USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: Starting user Group Policy (Background) processing... USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: USERENV(1d8.d34) 07:28:37:397 ProcessGPOs: USERENV(1d8.d34) 07:28:37:397 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0 USERENV(1d8.d34) 07:28:37:397 EnterCriticalPolicySectionEx: User critical section has been claimed. Handle = 0x8a4 USERENV(1d8.d34) 07:28:37:413 EnterCriticalPolicySectionEx: Leaving successfully. USERENV(1d8.d34) 07:28:37:413 ProcessGPOs: Machine role is 2. USERENV(1d8.d34) 07:28:37:413 PingComputer: Adapter speed 100000000 bps USERENV(1d8.d34) 07:28:42:850 PingComputer: First send 0x97c235c1 failed with 11010 USERENV(1d8.d34) 07:28:48:350 PingComputer: First send 0x97c235c1 failed with 11010 USERENV(1d8.d34) 07:28:53:850 PingComputer: First send 0x97c235c1 failed with 11010 USERENV(1d8.d34) 07:28:53:850 PingComputer: No data available USERENV(1d8.d34) 07:28:53:959 PingComputer: Adapter speed 100000000 bps USERENV(1d8.d34) 07:28:59:350 PingComputer: First send 0x96c235c1 failed with 11010 USERENV(1d8.d34) 07:29:04:850 PingComputer: First send 0x96c235c1 failed with 11010 USERENV(1d8.d34) 07:29:10:350 PingComputer: First send 0x96c235c1 failed with 11010 USERENV(1d8.d34) 07:29:10:365 PingComputer: No data available USERENV(1d8.d34) 07:29:10:365 ProcessGPOs: DSGetDCName failed with 59. USERENV(1d8.d34) 07:29:10:365 ProcessGPOs: No WMI logging done in this policy cycle. USERENV(1d8.d34) 07:29:10:397 ProcessGPOs: Processing failed with error 59. USERENV(1d8.d34) 07:29:10:428 LeaveCriticalPolicySection: Critical section 0x8a4 has been released. USERENV(1d8.d34) 07:29:10:428 ProcessGPOs: User Group Policy has been applied. USERENV(1d8.d34) 07:29:10:428 ProcessGPOs: Leaving with 0.
Visiblement, le ping n'aboutit pas car il ne passe pas au second "send" ==> First send 0x97c235c1 failed with 11010
J'ai testé cela sur 4 autres machines mais le problème est le même. Est-ce une simple commande ping ? Avez-vous une idée d'où provient ce problème ?
Cordialement,
"Lognoul Marc [MVP]" wrote in message news:
Pour complémenter la réponse d'Emmanuel, activez cette option et cherchez les lignes suivantes dans le fichier de journalisation: USERENV(20c.210) 09:52:23:621 PingComputer: Adapter speed 10000000 bps USERENV(20c.210) 09:52:23:851 PingComputer: First time: 236 USERENV(20c.210) 09:52:24:097 PingComputer: Second time: 245 USERENV(20c.210) 09:52:24:328 PingComputer: First time: 240 USERENV(20c.210) 09:52:24:574 PingComputer: Second time: 247 USERENV(20c.210) 09:52:24:804 PingComputer: First time: 237 USERENV(20c.210) 09:52:25:050 PingComputer: Second time: 245 USERENV(20c.210) 09:52:25:050 PingComputer: Transfer rate: 4000 Kbps Loop count: 3
Pour activer l'option, voir l'article suivant: http://support.microsoft.com/kb/221833/fr. Mettez la valeur 10002 (en hexa). Une fois le problème résolu, retorunez à la valeur originale. Des explications additionelles sur la détection de slows links: http://support.microsoft.com/kb/227260/fr
-- Marc [MCSE, MCTS, MVP] [Heureux celui qui a pu pénétrer les causes secrètes des choses] [Blog: http://www.marc-antho-etc.net/blog/]
"Edreux (ILINFO)" wrote in message news:
Bonjour,
en général, les problème de déploiement de MSI par GPO (entre parenthèse, c'est au mieux bien pour du dépannage à défaut d'autre solution) sont dus à des problèmes de "slow link detection".
Activez par exemple le diagnostic userenvdebug (cherchez Userenvdebuglevel sur Internet) et dans le log généré, regardez si vous avez "slow link detection" mentionné.
Cordialement, Emmanuel Dreux http://www.ilinfo.fr
"Rosseels Olivier" a écrit dans le message de news:%
Bonjour à tous,
Depuis quelques mois, je crée des packages MSI que je déploie via GPO. Cela fonctionne à merveille mais après vérification j'ai remarqué que les GPO n'étaient pas appliquées sur notre site secondaire.
Notre entreprise possède son propre réseau interne mais nous avons des locaux qui se situent dans un autre bâtiment où le réseau ne nous appartient pas. Les deux bâtiments sont relié en fibre optique mais passe par deux firewall (le notre et celui du provider de l'autre bâtiment).
