Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Claude BELLAMY
Dans le message :443238be$0$29470$, David a pris la peine d'écrire ce qui suit :
Bonjour,
Je suis débutant en vbs, et j'ai besoin d'aide:
J'aimerais automatiser, à l'aide d'un script VBS, l'environnement Windows de mes utilisateurs, à savoir:
1) L'affichage en détail dans l'explorateur windows
J'ignore où cette info est stockée ! Ce n'est pas dans la BDR. J'ai lancé REGMON, et quand on clique sur le type d'afifchage, cela ne fait appel qu'à la clef HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist{5E6AB780-7743-11CF-A12B-00AA004AE837} qui concerne uniquement la barre d'outils (et non pas les options du menu déroulant d'un de ses boutons)
2) L'affichage des fichiers cachés 3) L'affichage des extensions de fichiers
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :443238be$0$29470$636a55ce@news.free.fr,
David <ddestruhaut@free.fr> a pris la peine d'écrire ce qui suit :
Bonjour,
Je suis débutant en vbs, et j'ai besoin d'aide:
J'aimerais automatiser, à l'aide d'un script VBS, l'environnement
Windows de mes utilisateurs, à savoir:
1) L'affichage en détail dans l'explorateur windows
J'ignore où cette info est stockée !
Ce n'est pas dans la BDR.
J'ai lancé REGMON, et quand on clique sur le type d'afifchage, cela ne fait
appel qu'à la clef
HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist{5E6AB780-7743-11CF-A12B-00AA004AE837}
qui concerne uniquement la barre d'outils (et non pas les options du menu
déroulant d'un de ses boutons)
2) L'affichage des fichiers cachés
3) L'affichage des extensions de fichiers
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :443238be$0$29470$, David a pris la peine d'écrire ce qui suit :
Bonjour,
Je suis débutant en vbs, et j'ai besoin d'aide:
J'aimerais automatiser, à l'aide d'un script VBS, l'environnement Windows de mes utilisateurs, à savoir:
1) L'affichage en détail dans l'explorateur windows
J'ignore où cette info est stockée ! Ce n'est pas dans la BDR. J'ai lancé REGMON, et quand on clique sur le type d'afifchage, cela ne fait appel qu'à la clef HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist{5E6AB780-7743-11CF-A12B-00AA004AE837} qui concerne uniquement la barre d'outils (et non pas les options du menu déroulant d'un de ses boutons)
2) L'affichage des fichiers cachés 3) L'affichage des extensions de fichiers
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] http://www.bellamyjc.org ou http://jc.bellamy.free.fr
bayosky
Dans le message 443238be$0$29470$,
Bonjour,
1) L'affichage en détail dans l'explorateur windows
Comme ce type d'information peut être propre à chaque chaque dossier
il faut d'abord trouver comment forcer l'affichage identique pour tout les dossiers. ( je crois que ça se trouve ...)
Ensuite on peut espérer localiser la clé qui stocke ces params généraux mais ...
J'ai eu à identifier la zone de la BdR qui convient pour que l'explorateur utilise toujours la même fenètre... ( c'était pour des postes w98) Je l'ai finalement trouvé dans 3 km d'hexa sur la valeur "settings" situé là : HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerCabinetState
Le param en question occupait une partie du onzième octet (si je me souvient bien )
----->>>certains trucs sont "vicieux" et difficile à localiser .
Ce param n'était appliqué qu'au logging suivant... Certains params s'ils sont modifiés après le chargement de explorer.exe, n'ont pas d'effet immédiat car l'info n'est lue qu'au lancement de la session. mais la bdr modifiée sera lue correctement la fois suivante :o) C'est la raison pour laquelle une stratégie bien construite qui intervient avant est toujours préférable à un script dont on ne sait pas trop quand il s'exécute... J'observais ce matin encore certaines stations anciennes et un peu lentes... Le script de connexion au réseau lance plusieurs petites choses et la dernière (mise à jour de l'anti-virus) n'était pas terminé quand le bureau descendait du serveur... bref ...
----->>>> La modif par script de HKCU ne doit être qu'une solution "de secours" Les stratégies sont faites pour ça.
Qui plus est, un profil qui descend du serveur ne pose pas de pb de droit... avec des stations XP, il faut y songer. Certaines clés HKCU sont en lecture seule pour un utilisateur s'il n'a pas "beaucoup de droits" :o)
En fait, au lieu de demander "comment fait-on ça" tu aurais peut-être dû préciser pourquoi, dans quel cadre, etc... Le script que tu désires faire n'est peut-être pas la bonne solution, tout simplement.
On a tous, un jour, rencontré ce type de situation..:
On commence à connaitre un outils alors on cherche à l'utiliser pour faire des choses qui sont faciles à faire avec un autre outil auquel on n'a pas pensé ou dont on ignore l'existence ...
A+
HB
Dans le message 443238be$0$29470$636a55ce@news.free.fr,
Bonjour,
1) L'affichage en détail dans l'explorateur windows
Comme ce type d'information
peut être propre à chaque chaque dossier
il faut d'abord trouver comment forcer
l'affichage identique pour tout les dossiers.
( je crois que ça se trouve ...)
Ensuite on peut espérer localiser la clé qui stocke ces params
généraux mais ...
J'ai eu à identifier la zone de la BdR qui convient
pour que l'explorateur utilise toujours la même fenètre...
( c'était pour des postes w98)
Je l'ai finalement trouvé dans 3 km d'hexa sur la valeur "settings"
situé là :
HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerCabinetState
Le param en question occupait une partie du onzième octet
(si je me souvient bien )
----->>>certains trucs sont "vicieux" et difficile à localiser .
Ce param n'était appliqué qu'au logging suivant...
Certains params s'ils sont modifiés après le chargement de
explorer.exe, n'ont pas d'effet immédiat car l'info n'est lue qu'au
lancement de la session. mais la bdr modifiée sera lue correctement la
fois suivante :o)
C'est la raison pour laquelle une stratégie bien construite qui
intervient avant est toujours préférable à un script dont on ne sait
pas trop quand il s'exécute...
J'observais ce matin encore certaines stations anciennes et un peu
lentes...
Le script de connexion au réseau lance plusieurs petites choses et la
dernière (mise à jour de l'anti-virus) n'était pas terminé quand le
bureau descendait du serveur... bref ...
----->>>> La modif par script de HKCU ne doit être qu'une solution "de
secours"
Les stratégies sont faites pour ça.
Qui plus est, un profil qui descend du serveur ne pose pas de pb de
droit... avec des stations XP, il faut y songer.
Certaines clés HKCU sont en lecture seule pour un utilisateur s'il n'a
pas "beaucoup de droits" :o)
En fait, au lieu de demander "comment fait-on ça"
tu aurais peut-être dû préciser pourquoi, dans quel cadre, etc...
Le script que tu désires faire n'est peut-être pas la bonne solution,
tout simplement.
On a tous, un jour, rencontré ce type de situation..:
On commence à connaitre un outils
alors on cherche à l'utiliser
pour faire des choses
qui sont faciles à faire avec un autre outil
auquel on n'a pas pensé
ou dont on ignore l'existence ...
1) L'affichage en détail dans l'explorateur windows
Comme ce type d'information peut être propre à chaque chaque dossier
il faut d'abord trouver comment forcer l'affichage identique pour tout les dossiers. ( je crois que ça se trouve ...)
Ensuite on peut espérer localiser la clé qui stocke ces params généraux mais ...
J'ai eu à identifier la zone de la BdR qui convient pour que l'explorateur utilise toujours la même fenètre... ( c'était pour des postes w98) Je l'ai finalement trouvé dans 3 km d'hexa sur la valeur "settings" situé là : HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerCabinetState
Le param en question occupait une partie du onzième octet (si je me souvient bien )
----->>>certains trucs sont "vicieux" et difficile à localiser .
Ce param n'était appliqué qu'au logging suivant... Certains params s'ils sont modifiés après le chargement de explorer.exe, n'ont pas d'effet immédiat car l'info n'est lue qu'au lancement de la session. mais la bdr modifiée sera lue correctement la fois suivante :o) C'est la raison pour laquelle une stratégie bien construite qui intervient avant est toujours préférable à un script dont on ne sait pas trop quand il s'exécute... J'observais ce matin encore certaines stations anciennes et un peu lentes... Le script de connexion au réseau lance plusieurs petites choses et la dernière (mise à jour de l'anti-virus) n'était pas terminé quand le bureau descendait du serveur... bref ...
----->>>> La modif par script de HKCU ne doit être qu'une solution "de secours" Les stratégies sont faites pour ça.
Qui plus est, un profil qui descend du serveur ne pose pas de pb de droit... avec des stations XP, il faut y songer. Certaines clés HKCU sont en lecture seule pour un utilisateur s'il n'a pas "beaucoup de droits" :o)
En fait, au lieu de demander "comment fait-on ça" tu aurais peut-être dû préciser pourquoi, dans quel cadre, etc... Le script que tu désires faire n'est peut-être pas la bonne solution, tout simplement.
On a tous, un jour, rencontré ce type de situation..:
On commence à connaitre un outils alors on cherche à l'utiliser pour faire des choses qui sont faciles à faire avec un autre outil auquel on n'a pas pensé ou dont on ignore l'existence ...
A+
HB
David
Bonjour,
Je vous remercie tous pour toutes vos réponses. C'est vrai que j'aurais pu vous préciser ce que je voulais faire:
J'ai un petit parc de production, de 100 machines environs, géré par trois contrôleurs de domaine sous Windows 2000 et 2003 server. Le parc comprend des machines sous 98, 2000 et XP. J'ai créé un petit script de logon en vbs, qui lance la connexion de lecteur réseau, copie (mise à jour) de fichiers, inventaire du parc... Le problème, c'est les utilisateurs changent souvent de place, donc souvent obligé de reconfigurer leur session (dont l'affichage en détail, les extensions, l'affichage des fichiers cachés). Peut-être que la solution ne se trouve pas dans les scripts de logon!? C'est vrai. Peut-être qu'il serait plus "simple" d'utiliser les profils et les stratégies!? Je ne sais pas trop comment faire.
Mais merci beaucoup, tout de même!!
David
Dans le message 443238be$0$29470$,
Bonjour,
1) L'affichage en détail dans l'explorateur windows
Comme ce type d'information peut être propre à chaque chaque dossier
il faut d'abord trouver comment forcer l'affichage identique pour tout les dossiers. ( je crois que ça se trouve ...)
Ensuite on peut espérer localiser la clé qui stocke ces params généraux mais ...
J'ai eu à identifier la zone de la BdR qui convient pour que l'explorateur utilise toujours la même fenètre... ( c'était pour des postes w98) Je l'ai finalement trouvé dans 3 km d'hexa sur la valeur "settings" situé là : HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerCabinetState
Le param en question occupait une partie du onzième octet (si je me souvient bien )
----->>>certains trucs sont "vicieux" et difficile à localiser .
Ce param n'était appliqué qu'au logging suivant... Certains params s'ils sont modifiés après le chargement de explorer.exe, n'ont pas d'effet immédiat car l'info n'est lue qu'au lancement de la session. mais la bdr modifiée sera lue correctement la fois suivante :o) C'est la raison pour laquelle une stratégie bien construite qui intervient avant est toujours préférable à un script dont on ne sait pas trop quand il s'exécute... J'observais ce matin encore certaines stations anciennes et un peu lentes... Le script de connexion au réseau lance plusieurs petites choses et la dernière (mise à jour de l'anti-virus) n'était pas terminé quand le bureau descendait du serveur... bref ...
----->>>> La modif par script de HKCU ne doit être qu'une solution "de secours" Les stratégies sont faites pour ça.
Qui plus est, un profil qui descend du serveur ne pose pas de pb de droit... avec des stations XP, il faut y songer. Certaines clés HKCU sont en lecture seule pour un utilisateur s'il n'a pas "beaucoup de droits" :o)
En fait, au lieu de demander "comment fait-on ça" tu aurais peut-être dû préciser pourquoi, dans quel cadre, etc... Le script que tu désires faire n'est peut-être pas la bonne solution, tout simplement.
On a tous, un jour, rencontré ce type de situation..:
On commence à connaitre un outils alors on cherche à l'utiliser pour faire des choses qui sont faciles à faire avec un autre outil auquel on n'a pas pensé ou dont on ignore l'existence ...
A+
HB
Bonjour,
Je vous remercie tous pour toutes vos réponses. C'est vrai que j'aurais
pu vous préciser ce que je voulais faire:
J'ai un petit parc de production, de 100 machines environs, géré par
trois contrôleurs de domaine sous Windows 2000 et 2003 server. Le parc
comprend des machines sous 98, 2000 et XP. J'ai créé un petit script de
logon en vbs, qui lance la connexion de lecteur réseau, copie (mise à
jour) de fichiers, inventaire du parc...
Le problème, c'est les utilisateurs changent souvent de place, donc
souvent obligé de reconfigurer leur session (dont l'affichage en détail,
les extensions, l'affichage des fichiers cachés).
Peut-être que la solution ne se trouve pas dans les scripts de logon!?
C'est vrai. Peut-être qu'il serait plus "simple" d'utiliser les profils
et les stratégies!? Je ne sais pas trop comment faire.
Mais merci beaucoup, tout de même!!
David
Dans le message 443238be$0$29470$636a55ce@news.free.fr,
Bonjour,
1) L'affichage en détail dans l'explorateur windows
Comme ce type d'information
peut être propre à chaque chaque dossier
il faut d'abord trouver comment forcer
l'affichage identique pour tout les dossiers.
( je crois que ça se trouve ...)
Ensuite on peut espérer localiser la clé qui stocke ces params généraux
mais ...
J'ai eu à identifier la zone de la BdR qui convient
pour que l'explorateur utilise toujours la même fenètre...
( c'était pour des postes w98)
Je l'ai finalement trouvé dans 3 km d'hexa sur la valeur "settings"
situé là :
HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerCabinetState
Le param en question occupait une partie du onzième octet
(si je me souvient bien )
----->>>certains trucs sont "vicieux" et difficile à localiser .
Ce param n'était appliqué qu'au logging suivant...
Certains params s'ils sont modifiés après le chargement de explorer.exe,
n'ont pas d'effet immédiat car l'info n'est lue qu'au lancement de la
session. mais la bdr modifiée sera lue correctement la fois suivante :o)
C'est la raison pour laquelle une stratégie bien construite qui
intervient avant est toujours préférable à un script dont on ne sait pas
trop quand il s'exécute...
J'observais ce matin encore certaines stations anciennes et un peu
lentes...
Le script de connexion au réseau lance plusieurs petites choses et la
dernière (mise à jour de l'anti-virus) n'était pas terminé quand le
bureau descendait du serveur... bref ...
----->>>> La modif par script de HKCU ne doit être qu'une solution "de
secours"
Les stratégies sont faites pour ça.
Qui plus est, un profil qui descend du serveur ne pose pas de pb de
droit... avec des stations XP, il faut y songer.
Certaines clés HKCU sont en lecture seule pour un utilisateur s'il n'a
pas "beaucoup de droits" :o)
En fait, au lieu de demander "comment fait-on ça"
tu aurais peut-être dû préciser pourquoi, dans quel cadre, etc...
Le script que tu désires faire n'est peut-être pas la bonne solution,
tout simplement.
On a tous, un jour, rencontré ce type de situation..:
On commence à connaitre un outils
alors on cherche à l'utiliser
pour faire des choses
qui sont faciles à faire avec un autre outil
auquel on n'a pas pensé
ou dont on ignore l'existence ...
Je vous remercie tous pour toutes vos réponses. C'est vrai que j'aurais pu vous préciser ce que je voulais faire:
J'ai un petit parc de production, de 100 machines environs, géré par trois contrôleurs de domaine sous Windows 2000 et 2003 server. Le parc comprend des machines sous 98, 2000 et XP. J'ai créé un petit script de logon en vbs, qui lance la connexion de lecteur réseau, copie (mise à jour) de fichiers, inventaire du parc... Le problème, c'est les utilisateurs changent souvent de place, donc souvent obligé de reconfigurer leur session (dont l'affichage en détail, les extensions, l'affichage des fichiers cachés). Peut-être que la solution ne se trouve pas dans les scripts de logon!? C'est vrai. Peut-être qu'il serait plus "simple" d'utiliser les profils et les stratégies!? Je ne sais pas trop comment faire.
Mais merci beaucoup, tout de même!!
David
Dans le message 443238be$0$29470$,
Bonjour,
1) L'affichage en détail dans l'explorateur windows
Comme ce type d'information peut être propre à chaque chaque dossier
il faut d'abord trouver comment forcer l'affichage identique pour tout les dossiers. ( je crois que ça se trouve ...)
Ensuite on peut espérer localiser la clé qui stocke ces params généraux mais ...
J'ai eu à identifier la zone de la BdR qui convient pour que l'explorateur utilise toujours la même fenètre... ( c'était pour des postes w98) Je l'ai finalement trouvé dans 3 km d'hexa sur la valeur "settings" situé là : HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerCabinetState
Le param en question occupait une partie du onzième octet (si je me souvient bien )
----->>>certains trucs sont "vicieux" et difficile à localiser .
Ce param n'était appliqué qu'au logging suivant... Certains params s'ils sont modifiés après le chargement de explorer.exe, n'ont pas d'effet immédiat car l'info n'est lue qu'au lancement de la session. mais la bdr modifiée sera lue correctement la fois suivante :o) C'est la raison pour laquelle une stratégie bien construite qui intervient avant est toujours préférable à un script dont on ne sait pas trop quand il s'exécute... J'observais ce matin encore certaines stations anciennes et un peu lentes... Le script de connexion au réseau lance plusieurs petites choses et la dernière (mise à jour de l'anti-virus) n'était pas terminé quand le bureau descendait du serveur... bref ...
----->>>> La modif par script de HKCU ne doit être qu'une solution "de secours" Les stratégies sont faites pour ça.
Qui plus est, un profil qui descend du serveur ne pose pas de pb de droit... avec des stations XP, il faut y songer. Certaines clés HKCU sont en lecture seule pour un utilisateur s'il n'a pas "beaucoup de droits" :o)
En fait, au lieu de demander "comment fait-on ça" tu aurais peut-être dû préciser pourquoi, dans quel cadre, etc... Le script que tu désires faire n'est peut-être pas la bonne solution, tout simplement.
On a tous, un jour, rencontré ce type de situation..:
On commence à connaitre un outils alors on cherche à l'utiliser pour faire des choses qui sont faciles à faire avec un autre outil auquel on n'a pas pensé ou dont on ignore l'existence ...
A+
HB
bayosky
Dans le message 44335c5c$0$12853$,
Bonjour, (...)
C'est vrai. Peut-être qu'il serait plus "simple" d'utiliser les profils et les stratégies!? Je ne sais pas trop comment faire.
pour les paramètres que tu cites et sous réserve que tu n'utilises pas de stratégie, il s'agit de params "per user" donc dès lors que le user.dat ( resp ntuser.dat) est sur le serveur et non pas local chacun peut avoir les siens et les modifier, et les retrouver au prochain login.
J'ai cru comprendre que cela suffirait...
Une fois les profils activés, normalement, la machine va chercher la ruche automatiquement dans l'espace perso de l'utilisateur...
Je ne suis pas certain que, dans cette perspective, 2000 et XP cohabitent sans risque. (pour 98 c'est différent...) Pour W98 ( qui se connecte à un domaine) la ruche est user.dat pour 2000 ( je crois) et XP ( qui s'intègrent à un domaine ) la ruche est ntuser.dat
HB
Dans le message 44335c5c$0$12853$626a54ce@news.free.fr,
Bonjour,
(...)
C'est vrai. Peut-être qu'il serait plus "simple" d'utiliser les
profils et les stratégies!? Je ne sais pas trop comment faire.
pour les paramètres que tu cites
et sous réserve que tu n'utilises pas de stratégie,
il s'agit de params "per user" donc
dès lors que le user.dat ( resp ntuser.dat)
est sur le serveur et non pas local
chacun peut avoir les siens
et les modifier,
et les retrouver au prochain login.
J'ai cru comprendre que cela suffirait...
Une fois les profils activés, normalement,
la machine va chercher la ruche automatiquement
dans l'espace perso de l'utilisateur...
Je ne suis pas certain que, dans cette perspective,
2000 et XP cohabitent sans risque.
(pour 98 c'est différent...)
Pour W98 ( qui se connecte à un domaine)
la ruche est user.dat
pour 2000 ( je crois) et XP ( qui s'intègrent à un domaine )
la ruche est ntuser.dat
C'est vrai. Peut-être qu'il serait plus "simple" d'utiliser les profils et les stratégies!? Je ne sais pas trop comment faire.
pour les paramètres que tu cites et sous réserve que tu n'utilises pas de stratégie, il s'agit de params "per user" donc dès lors que le user.dat ( resp ntuser.dat) est sur le serveur et non pas local chacun peut avoir les siens et les modifier, et les retrouver au prochain login.
J'ai cru comprendre que cela suffirait...
Une fois les profils activés, normalement, la machine va chercher la ruche automatiquement dans l'espace perso de l'utilisateur...
Je ne suis pas certain que, dans cette perspective, 2000 et XP cohabitent sans risque. (pour 98 c'est différent...) Pour W98 ( qui se connecte à un domaine) la ruche est user.dat pour 2000 ( je crois) et XP ( qui s'intègrent à un domaine ) la ruche est ntuser.dat
