OVH Cloud OVH Cloud

Script netlogon inexistant sur réseau Wi-Fi / WinXP et serveur NT4

5 réponses
Avatar
RAF
Bonjour à tous,

* Description générale du problème :

Je ne trouve pas la solution permettant d'obtenir le lancement du script
d'ouverture de session (netlogon) sur le serveur NT4 à chaque connexion de
mes postes clients en WinXP Pro, lorsqu'ils se connectenr en wi-fi ou
losqu'ils connectent le cable RJ45 après avoir ouvert la session
utilisateur.

* Précisions :
- Serveur de Domaine NT4 SBS
- Postes clients Win XP Pro / portables toshiba
- Connexions possibles en RJ45 (réseau ethernet filaire classique TCP/IP)
- Connexions possibles en wi-fi si RJ45 absent
- Routeur wi-Fi D-linkAP900, DHCP activé

- Lors de l'ouverture de session, si le câble RJ45 est connecté, le script
d'ouverture de session est lancé automatiquement
- Si le câble RJ45 est connecté après l'ouverture de la session, le script
n'est pas lancé.
- Si le poste se trouve dans une zone de couverture wi-fi, il est connecté
très rapidement au réseau (pings OK), mais le script d'ouverture de session
ne se lance pas.

* Comment faire pour que le script se lance à chaque fois ???

D'avance Merci pour votre aide...

R.D.

5 réponses

Avatar
steph
Hello,
oulà, je ne suis pas sûr d'avoir tout saisi...
existe t'il une doc en ligne chez MS sur ce sujet ?
merci






"Stéphane [MS]" a écrit dans le message de
news:
Bonjour,

Pour les miracles, ce n'est pas à moi qu'il faut s'adresser :-)

Je pense qu'il est possible de demander aux utilisateur de sauvegarder une
pièce jointe qui contient un script de manière à modifier la clé de
registre

qui contrôle le niveau de détection des connexions lentes ou d'ignorer la
détection.

Si l'exécution de script dans la messagerie est interdite, cela complique
un

peu le problème. Il faut envoyer le script avec une extension différente
et

demander aux utilisateur de renommer la pièce jointe avant de l'exécuter.

La clé pour ignorer la détection est SlowLinkDetectEnabled dans :
HKLMSoftwarePoliciesMicrosoftWindowsSystem

La clé GroupPolicyMinTransferRate pour fixer le niveau (500 par défaut)
est

au même endroit.

Je vous conseille de régler par une GPO de domaine ces valeur à une valeur
inférieure de manière à toucher déjà quelques postes en LAN et à ne pas
écraser les valeurs fixées en base de registre.

La GPO est dans :
Configuration ordinateur / Paramètre du logiciel / Modèle d'administration
/

System / Stratégie de groupe

Attention aux effets de bord si vos utilisateurs se connectent également
via

des connexions RTC à faible débit.

Cdlt
Stéphane


"RAF" a écrit dans le message de news:
becr9a$up3$
Oui... Tous les postes ont une messagerie.
Quelle est la solution miracle ???

thks...

R.D.







Avatar
david
"Stéphane [MS]" a écrit dans le message de
news:
Bonjour,

Par défaut les scripts de connexion et stratégies de groupe ne
s'appliquent

pas sur des liaisons bas débit (inférieur à 500kbits/s).


Hum le wifi 811b a une bande passante supérieure... On dispose de 3 à 4 Mbps
utile, à partager entre tous les utilisateurs... Les premiers utilisateurs
connectés ne devraient donc pas avoir de soucis...

Avatar
Christophe DENIS
Donc en wi-fi ils ne sont surement pas authentifié par ton PDC (utilisation
du profil caché).
Je pencherais pour un problème de configuration IP sur les postes ou l'AP.

Tu ping bien ton pdc ?
Tu as bien mis les bonnes passerelles partout ?

"RAF" a écrit dans le message de news:
be56sa$hlh$
Bonjour à tous,

* Description générale du problème :

Je ne trouve pas la solution permettant d'obtenir le lancement du script
d'ouverture de session (netlogon) sur le serveur NT4 à chaque connexion de
mes postes clients en WinXP Pro, lorsqu'ils se connectenr en wi-fi ou
losqu'ils connectent le cable RJ45 après avoir ouvert la session
utilisateur.

* Précisions :
- Serveur de Domaine NT4 SBS
- Postes clients Win XP Pro / portables toshiba
- Connexions possibles en RJ45 (réseau ethernet filaire classique TCP/IP)
- Connexions possibles en wi-fi si RJ45 absent
- Routeur wi-Fi D-linkAP900, DHCP activé

- Lors de l'ouverture de session, si le câble RJ45 est connecté, le script
d'ouverture de session est lancé automatiquement
- Si le câble RJ45 est connecté après l'ouverture de la session, le script
n'est pas lancé.
- Si le poste se trouve dans une zone de couverture wi-fi, il est connecté
très rapidement au réseau (pings OK), mais le script d'ouverture de
session

ne se lance pas.

* Comment faire pour que le script se lance à chaque fois ???

D'avance Merci pour votre aide...

R.D.






Avatar
david
"Christophe DENIS" a écrit dans le message de
news:beofrp$pu6$
Donc en wi-fi ils ne sont surement pas authentifié par ton PDC
(utilisation

du profil caché).
Je pencherais pour un problème de configuration IP sur les postes ou l'AP.

Tu ping bien ton pdc ?
Tu as bien mis les bonnes passerelles partout ?


Je pense que mettre l'AP en DHCP est une erreur et qu'il vaut mieux que ce
soit le PC serveur qui le fasse compte tenu du script d'authenfication... Le
wifi a ce niveau ne diffère pas de l'éthernet traditionnel filaire...

Avatar
RAF
Petite précision sur le pb évoquée ci-dessous :

J'ai constaté que le script NetLogon était lancé uniquement lorsque le
portable toshiba (centrino) était alimenté sur secteur.
Dés que l'on passe en alimentation sur batterie, il est possible de se
connecter au point d'accès wifi, de pinguer le serveur exchange, le serveur
NT et l'ensemble du réseau, mais il est impossible d'ouvrir Outlook XP et il
n'y a pas de NetLogon à l'ouverture de session.

Explications ???

thks.
Raf.

"RAF" a écrit dans le message de news:
becr9a$up3$
Oui... Tous les postes ont une messagerie.
Quelle est la solution miracle ???

thks...

R.D.

"Stéphane [MS]" a écrit dans le message de
news:
Bonjour,

Par défaut les scripts de connexion et stratégies de groupe ne
s'appliquent

pas sur des liaisons bas débit (inférieur à 500kbits/s).
Il existe une stratégie pour modifier ce réglage, mais c'est un peu le
problème de l'oeuf et la poule : pour que ce réglage soit appliqué, il
faut

que le poste reçoive la stratégie qu'il ne reçoit pas parce qu'il est
sur


une liaison jugé faible.
Avez-vous la possibilité de passer un script sur tous les postes d'une
autre

manière (logiciel de télédistribution, messagerie, acte volontaire des
utilisateurs, etc.) pour changer ce réglage ?

Cdlt
Stéphane

"RAF" a écrit dans le message de news:
be9q1h$3tk$
Utilisateurs nombreux et indisciplinés... difficile à leur expliquer.
N'y a-t-il pas un astuce pour forcer ou attendre la connexion au
réseau



wi-fi avant l'ouverture de session windows ?



"Jean V" a écrit dans le
message



de
news: be8ngo$19lr$
un tel script ne s'execute que lorsque d une ouverture de session
windows


sur le reseau NT/2K
pas lors d une connexion au reseau wi-fi

dis à tes utilisateurs une fois qu'ils ont la connexion wi-fi de
fermer



et
d'ouvrir leur session windows ( en utilisant bien sur un compte
d'utilisateur sur le domaine),


"RAF" a écrit dans le message de
news:be56sa$hlh$
Bonjour à tous,

* Description générale du problème :

Je ne trouve pas la solution permettant d'obtenir le lancement du
script



d'ouverture de session (netlogon) sur le serveur NT4 à chaque
connexion



de
mes postes clients en WinXP Pro, lorsqu'ils se connectenr en wi-fi
ou




losqu'ils connectent le cable RJ45 après avoir ouvert la session
utilisateur.

* Précisions :
- Serveur de Domaine NT4 SBS
- Postes clients Win XP Pro / portables toshiba
- Connexions possibles en RJ45 (réseau ethernet filaire classique
TCP/IP)


- Connexions possibles en wi-fi si RJ45 absent
- Routeur wi-Fi D-linkAP900, DHCP activé

- Lors de l'ouverture de session, si le câble RJ45 est connecté,
le





script
d'ouverture de session est lancé automatiquement
- Si le câble RJ45 est connecté après l'ouverture de la session,
le





script
n'est pas lancé.
- Si le poste se trouve dans une zone de couverture wi-fi, il est
connecté


très rapidement au réseau (pings OK), mais le script d'ouverture
de





session
ne se lance pas.

* Comment faire pour que le script se lance à chaque fois ???

D'avance Merci pour votre aide...

R.D.