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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pour faire simple, voici un petit schéma
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
>>>>>> provider<==>10.12.7.0 + 10.12.8.0 (site B)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>
>
>
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).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pour faire simple, voici un petit schéma
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
>>>>>> provider<==>10.12.7.0 + 10.12.8.0 (site B)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>
>
>
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).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pour faire simple, voici un petit schéma
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
>>>>>> provider<==>10.12.7.0 + 10.12.8.0 (site B)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>
>
>
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.
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).
Pour faire simple, voici un petit schéma
10.12.1.0 + 10.12.2.0 (site A)<==>Notre firewall <==> Firewall
provider<==>10.12.7.0 + 10.12.8.0 (site B)
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.