dans la base de registre on trouve en plus de KKCU et HKLM, pas de choses à
l'intérieur de HK_USERS ( en plus de .DEFAULT) avec des noms "exotiques"
...
Parmi tout ce fourbi (...) y-a-il qqchose qui correspond à "all users" ...
Si c'était le cas, je pourrais peut-être passer par là pour donner à tous
les utilisateurs un morceau de BdR que j'ai dans un *.reg ... et, sans
rentrer dans les détails, ça m'arrangerait :o)
On Wed, 17 Nov 2004 14:45:46 +0100, "Hubert" wrote:
Salut Hubert, Si tu me permet j'ai peut-être une piste pour toi. L'outil modifyprofile.exe te permet d'effectuer une fusion de fichier .reg dans une ruche autre que celle de l'utilisateur précisé dans runas.vbs
Peut-être pourrais-tu bricoler quelque chose avec ça ... et l'aide de Jean-Claude http://www.optimumx.com/download/#ModifyProfile
De toute façon, j'aimerais bien voir comment tu règlera ton problème.
Bonne Chance
Bonjour,
Je reprend, je détaille et m'excuse pour les "ellipses" :o)
Il s'agit d'un programme qui prétend fonctionner sous xp mais ne fonctionne que si l'utilisateur est administrateur du domaine et si l'on récupère la partie de HKCU générée lors de l'installation avec un profil d'administrateur de la station ... ( tip top quoi ... )
Quand on sait qu'il s'agit d'un programme de CFAO utilisé dans les collèges et que les utilisateurs sont des élèves de 4° ou 3°, on comprend que, pour des raisons de sécurité, on cherche à faire autrement ..
Or donc, j'ai bricolé un script "encodé" ( en "exécution seule" pour "tout le monde") qui
1 vérifie que la machine convient ( c'est OK) 2 fabrique une page html à la volée dans %TMP% ( j'ai étudié logusr , merci une fois !) et propose le choix entre les deux module ( CAO/FAO) ( c'est OK) 3 traitement de la BdR [ C'est là l'os] 4 lance avec " runas /noprofile /env /user:admindudomaine programmequiconvient.exe " et un coup de sendKey MpP & "~" dans la fenètre de cscript... ( C'est OK)( j(ai aussi étudié runas.vbs ; merci mille fois!!!)
Le point 3 pose plusieurs problèmes :
Pour que l'utilisateur Toto puisse sauvegarder son travail au bon endroit, ( P:TotoTravail ; P est mappé au login) il faut que son environnement personnel soit correctement vu par le prgm lancé ainsi ... Si l'on veut que le programme lancé n'utilise pas les chemins réseau de l'utilisateur précédent, ( SERVEURZAZA ) il faut que le programme utilise des données propres à l'utilisateur et pas celles de l'admin qui contiendrait, sinon, dans sa BdR, les données de la dernière session du dernier élève. Ces pb d'options et de paramètres perdus et mélangés présente pas mal d'autres inconvénients ( paramètres predus pour l'interface, paramètres perdus pour le pilote du robot...)
D'où l'option noprofile pour que ce soit les données de profil ( et donc le HKCU ?) de l'utilisateur qui servent. Mézalor, il faut que HKCU contienne ce qui est sera attendu, et cela risque de ne pas y être si c'est la première utilisation.
Il faut donc qu'à l'issu d'un test ( on error machin + RegRead) on charge dans le HKCU de l'utilisateur des données qui n'y sont pas.
Mais voilà, dans le cadre de la stratégie appliquée, Regedit.exe et Regedt32 sont interdits ... Or j'ai cru noté que [ runas .... regedit.exe -s machin.reg ] va affecter la branche HKCU de l'admin utilisé et pas celle de la personne logée même avec /noprofile ce qui semble curieux mais bon ...
En fait, les constatations faites avec l'option /noprofile sont , pour moi, "contrariantes" :
* Pour le programme qui accède à la "ruche" HKCU, cela impose ou non celle de la personne logée * Pour regedit, cela ne change rien ..., le HKCU est forcément celui de l'utilisateur qui "lance" regedit.
Ce n'est pas totalement absurde mais cela ne m'arrange pas ....
Compte tenu du nombre d'élèves dans un collège, je ne compte pas, à la main - donner les droit sur regedit, - charger truc.reg pour chaque élève puis annuler les droits ( à moins de fermer qq temps :o) )
Comme les clés à créer sont nombreuses, je ne peux pas sérieusement envisager de faire cela avec le fichier *.adm
et là je rêve d'une façon rapide et sûre de donner par avance à tout les users, des clés par défaut quand y'en a pas ... d'ou mes questions sur All Users ...
J'espère que c'est clair ( bien sûr c'est un peu long )
Merci d'avoir eu le courage de lire jusqu'ici,
Bien cordialement,
Hubert
On Wed, 17 Nov 2004 14:45:46 +0100, "Hubert" <toto@maison.fr> wrote:
Salut Hubert,
Si tu me permet j'ai peut-être une piste pour toi.
L'outil modifyprofile.exe te permet d'effectuer une fusion de fichier
.reg dans une ruche autre que celle de l'utilisateur précisé dans
runas.vbs
Peut-être pourrais-tu bricoler quelque chose avec ça ... et l'aide de
Jean-Claude
http://www.optimumx.com/download/#ModifyProfile
De toute façon, j'aimerais bien voir comment tu règlera ton problème.
Bonne Chance
Bonjour,
Je reprend, je détaille et m'excuse pour les "ellipses" :o)
Il s'agit d'un programme qui prétend fonctionner sous xp mais ne fonctionne
que
si l'utilisateur est administrateur du domaine
et si l'on récupère la partie de HKCU générée
lors de l'installation avec un profil d'administrateur de la station ...
( tip top quoi ... )
Quand on sait qu'il s'agit d'un programme de CFAO utilisé dans les collèges
et que les utilisateurs sont des élèves de 4° ou 3°, on comprend que,
pour des raisons de sécurité, on cherche à faire autrement ..
Or donc, j'ai bricolé un script "encodé"
( en "exécution seule" pour "tout le monde")
qui
1 vérifie que la machine convient ( c'est OK)
2 fabrique une page html à la volée dans %TMP%
( j'ai étudié logusr , merci une fois !)
et propose le choix entre les deux module ( CAO/FAO) ( c'est OK)
3 traitement de la BdR [ C'est là l'os]
4 lance avec " runas /noprofile /env /user:admindudomaine
programmequiconvient.exe "
et un coup de sendKey MpP & "~" dans la fenètre de cscript...
( C'est OK)( j(ai aussi étudié runas.vbs ; merci mille fois!!!)
Le point 3 pose plusieurs problèmes :
Pour que l'utilisateur Toto puisse sauvegarder son travail au bon endroit,
( P:TotoTravail ; P est mappé au login)
il faut que son environnement personnel soit correctement vu par le prgm
lancé ainsi ...
Si l'on veut que le programme lancé n'utilise pas les chemins réseau de
l'utilisateur précédent,
( \SERVEURZAZA ) il faut que le programme utilise des données propres à
l'utilisateur
et pas celles de l'admin qui contiendrait, sinon, dans sa BdR, les données
de la dernière session du dernier élève.
Ces pb d'options et de paramètres perdus et mélangés présente pas mal
d'autres inconvénients
( paramètres predus pour l'interface, paramètres perdus pour le pilote du
robot...)
D'où l'option noprofile pour que ce soit les données de profil ( et donc le
HKCU ?) de l'utilisateur qui servent.
Mézalor, il faut que HKCU contienne ce qui est sera attendu, et cela risque
de ne pas y être si c'est la première utilisation.
Il faut donc qu'à l'issu d'un test ( on error machin + RegRead)
on charge dans le HKCU de l'utilisateur des données qui n'y sont pas.
Mais voilà, dans le cadre de la stratégie appliquée, Regedit.exe et Regedt32
sont interdits ...
Or j'ai cru noté que [ runas .... regedit.exe -s machin.reg ]
va affecter la branche HKCU de l'admin utilisé et pas celle de la personne
logée
même avec /noprofile ce qui semble curieux mais bon ...
En fait, les constatations faites avec l'option /noprofile sont , pour moi,
"contrariantes" :
* Pour le programme qui accède à la "ruche" HKCU,
cela impose ou non celle de la personne logée
* Pour regedit, cela ne change rien ...,
le HKCU est forcément celui de l'utilisateur qui "lance" regedit.
Ce n'est pas totalement absurde mais cela ne m'arrange pas ....
Compte tenu du nombre d'élèves dans un collège, je ne compte pas, à la main
- donner les droit sur regedit,
- charger truc.reg
pour chaque élève puis annuler les droits
( à moins de fermer qq temps :o) )
Comme les clés à créer sont nombreuses, je ne peux pas sérieusement
envisager de faire cela avec le fichier *.adm
et là je rêve d'une façon rapide et sûre de donner par avance à tout les
users, des clés par défaut quand y'en a pas ... d'ou mes questions sur All
Users ...
J'espère que c'est clair ( bien sûr c'est un peu long )
On Wed, 17 Nov 2004 14:45:46 +0100, "Hubert" wrote:
Salut Hubert, Si tu me permet j'ai peut-être une piste pour toi. L'outil modifyprofile.exe te permet d'effectuer une fusion de fichier .reg dans une ruche autre que celle de l'utilisateur précisé dans runas.vbs
Peut-être pourrais-tu bricoler quelque chose avec ça ... et l'aide de Jean-Claude http://www.optimumx.com/download/#ModifyProfile
De toute façon, j'aimerais bien voir comment tu règlera ton problème.
Bonne Chance
Bonjour,
Je reprend, je détaille et m'excuse pour les "ellipses" :o)
Il s'agit d'un programme qui prétend fonctionner sous xp mais ne fonctionne que si l'utilisateur est administrateur du domaine et si l'on récupère la partie de HKCU générée lors de l'installation avec un profil d'administrateur de la station ... ( tip top quoi ... )
Quand on sait qu'il s'agit d'un programme de CFAO utilisé dans les collèges et que les utilisateurs sont des élèves de 4° ou 3°, on comprend que, pour des raisons de sécurité, on cherche à faire autrement ..
Or donc, j'ai bricolé un script "encodé" ( en "exécution seule" pour "tout le monde") qui
1 vérifie que la machine convient ( c'est OK) 2 fabrique une page html à la volée dans %TMP% ( j'ai étudié logusr , merci une fois !) et propose le choix entre les deux module ( CAO/FAO) ( c'est OK) 3 traitement de la BdR [ C'est là l'os] 4 lance avec " runas /noprofile /env /user:admindudomaine programmequiconvient.exe " et un coup de sendKey MpP & "~" dans la fenètre de cscript... ( C'est OK)( j(ai aussi étudié runas.vbs ; merci mille fois!!!)
Le point 3 pose plusieurs problèmes :
Pour que l'utilisateur Toto puisse sauvegarder son travail au bon endroit, ( P:TotoTravail ; P est mappé au login) il faut que son environnement personnel soit correctement vu par le prgm lancé ainsi ... Si l'on veut que le programme lancé n'utilise pas les chemins réseau de l'utilisateur précédent, ( SERVEURZAZA ) il faut que le programme utilise des données propres à l'utilisateur et pas celles de l'admin qui contiendrait, sinon, dans sa BdR, les données de la dernière session du dernier élève. Ces pb d'options et de paramètres perdus et mélangés présente pas mal d'autres inconvénients ( paramètres predus pour l'interface, paramètres perdus pour le pilote du robot...)
D'où l'option noprofile pour que ce soit les données de profil ( et donc le HKCU ?) de l'utilisateur qui servent. Mézalor, il faut que HKCU contienne ce qui est sera attendu, et cela risque de ne pas y être si c'est la première utilisation.
Il faut donc qu'à l'issu d'un test ( on error machin + RegRead) on charge dans le HKCU de l'utilisateur des données qui n'y sont pas.
Mais voilà, dans le cadre de la stratégie appliquée, Regedit.exe et Regedt32 sont interdits ... Or j'ai cru noté que [ runas .... regedit.exe -s machin.reg ] va affecter la branche HKCU de l'admin utilisé et pas celle de la personne logée même avec /noprofile ce qui semble curieux mais bon ...
En fait, les constatations faites avec l'option /noprofile sont , pour moi, "contrariantes" :
* Pour le programme qui accède à la "ruche" HKCU, cela impose ou non celle de la personne logée * Pour regedit, cela ne change rien ..., le HKCU est forcément celui de l'utilisateur qui "lance" regedit.
Ce n'est pas totalement absurde mais cela ne m'arrange pas ....
Compte tenu du nombre d'élèves dans un collège, je ne compte pas, à la main - donner les droit sur regedit, - charger truc.reg pour chaque élève puis annuler les droits ( à moins de fermer qq temps :o) )
Comme les clés à créer sont nombreuses, je ne peux pas sérieusement envisager de faire cela avec le fichier *.adm
et là je rêve d'une façon rapide et sûre de donner par avance à tout les users, des clés par défaut quand y'en a pas ... d'ou mes questions sur All Users ...
J'espère que c'est clair ( bien sûr c'est un peu long )
Merci d'avoir eu le courage de lire jusqu'ici,
Bien cordialement,
Hubert
Hubert
Le fait de pouvoir accéder directement au NtUser.dat est digne d'attention en général et en particulier, si je peux lancer ça avant le chargement du NtUser.dat ça pourrait peut-être "le faire".
Et là je retrouve un vieux pb :
Dans quel ordre se passent réellement les choses ( pour un "profil migrant" dans un domaine )
- sections "run" etc... de HKLM - script de connexion - chargement du *.dat - application de la stratégie - sections "Run" etc... de HKCU - application des paramètres de l'interface ( bureau, lecteurs visibles, etc...) - section %userprofile%/menu démarrer/programmes/démarrage/ sans parler des doubles présents chez "all users" qui doivent aussi intervenir (avant/après ?) les valeurs de %username%
- autres actions omises ... ( y'en a tellement ...)
Hubert.
Le fait de pouvoir accéder directement au NtUser.dat
est digne d'attention en général
et
en particulier,
si je peux lancer ça avant le chargement du NtUser.dat
ça pourrait peut-être "le faire".
Et là je retrouve un vieux pb :
Dans quel ordre se passent réellement les choses
( pour un "profil migrant" dans un domaine )
- sections "run" etc... de HKLM
- script de connexion
- chargement du *.dat
- application de la stratégie
- sections "Run" etc... de HKCU
- application des paramètres de l'interface ( bureau, lecteurs visibles,
etc...)
- section %userprofile%/menu démarrer/programmes/démarrage/
sans parler des doubles présents chez "all users" qui doivent aussi
intervenir
(avant/après ?) les valeurs de %username%
- autres actions omises ... ( y'en a tellement ...)
Le fait de pouvoir accéder directement au NtUser.dat est digne d'attention en général et en particulier, si je peux lancer ça avant le chargement du NtUser.dat ça pourrait peut-être "le faire".
Et là je retrouve un vieux pb :
Dans quel ordre se passent réellement les choses ( pour un "profil migrant" dans un domaine )
- sections "run" etc... de HKLM - script de connexion - chargement du *.dat - application de la stratégie - sections "Run" etc... de HKCU - application des paramètres de l'interface ( bureau, lecteurs visibles, etc...) - section %userprofile%/menu démarrer/programmes/démarrage/ sans parler des doubles présents chez "all users" qui doivent aussi intervenir (avant/après ?) les valeurs de %username%
- autres actions omises ... ( y'en a tellement ...)
