Je souhaite ouvrir une session automatiquement sur un DC W2003 Standard.
Je sais, ce n'est pas conseillé, mais il y a un redémarrage automatique et
il faut
absolument qu'un programme soit lancé à l'ouverture de session.
Malheureusement, il m'est impossible de transformer ce programme en service.
C'est pour ça que j'ai besoin d'ouvrir automatiquement une session
administrateur lorsque le serveur redémarre.
Le serveur est dans un local fermé à clé, et il y a également une clé sur la
facade du serveur, donc aucun risque que quelqu'un vienne éteindre ou mettre
un CD dedans. De plus, il y a un mot de passe au bout de 3 minutes
d'inactivité (ecran de veille avec mot de passe). Je pense que tout cela est
suffisament sécurisé !
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
Jacques Barathon [MS]
Regarde cette fiche: http://support.microsoft.com/?id24737
Tant qu'à faire, tu pourrais également passer le délai d'inactivité de 3 à 1 minute, non?
Sinon, as-tu essayé de lancer le programme au démarrage du serveur, c'est-à-dire avant qu'une session soit ouverte? Il y a des limites à cette solution mais ça vaut le coup de regarder si ça peut t'éviter d'avoir à ouvrir une session automatiquement: http://support.microsoft.com/?id8642
Jacques
"RS" wrote in message news:
Bonjour,
Je souhaite ouvrir une session automatiquement sur un DC W2003 Standard.
Je sais, ce n'est pas conseillé, mais il y a un redémarrage automatique et il faut absolument qu'un programme soit lancé à l'ouverture de session.
Malheureusement, il m'est impossible de transformer ce programme en service. C'est pour ça que j'ai besoin d'ouvrir automatiquement une session administrateur lorsque le serveur redémarre.
Le serveur est dans un local fermé à clé, et il y a également une clé sur la facade du serveur, donc aucun risque que quelqu'un vienne éteindre ou mettre un CD dedans. De plus, il y a un mot de passe au bout de 3 minutes d'inactivité (ecran de veille avec mot de passe). Je pense que tout cela est suffisament sécurisé !
Est-ce possible ?
Cordialement.
Regarde cette fiche:
http://support.microsoft.com/?id24737
Tant qu'à faire, tu pourrais également passer le délai d'inactivité de 3 à 1
minute, non?
Sinon, as-tu essayé de lancer le programme au démarrage du serveur,
c'est-à-dire avant qu'une session soit ouverte? Il y a des limites à cette
solution mais ça vaut le coup de regarder si ça peut t'éviter d'avoir à
ouvrir une session automatiquement:
http://support.microsoft.com/?id8642
Jacques
"RS" <RS@discussions.microsoft.com> wrote in message
news:2C1C2050-E620-474F-BBF4-56C872048147@microsoft.com...
Bonjour,
Je souhaite ouvrir une session automatiquement sur un DC W2003 Standard.
Je sais, ce n'est pas conseillé, mais il y a un redémarrage automatique et
il faut
absolument qu'un programme soit lancé à l'ouverture de session.
Malheureusement, il m'est impossible de transformer ce programme en
service.
C'est pour ça que j'ai besoin d'ouvrir automatiquement une session
administrateur lorsque le serveur redémarre.
Le serveur est dans un local fermé à clé, et il y a également une clé sur
la
facade du serveur, donc aucun risque que quelqu'un vienne éteindre ou
mettre
un CD dedans. De plus, il y a un mot de passe au bout de 3 minutes
d'inactivité (ecran de veille avec mot de passe). Je pense que tout cela
est
suffisament sécurisé !
Regarde cette fiche: http://support.microsoft.com/?id24737
Tant qu'à faire, tu pourrais également passer le délai d'inactivité de 3 à 1 minute, non?
Sinon, as-tu essayé de lancer le programme au démarrage du serveur, c'est-à-dire avant qu'une session soit ouverte? Il y a des limites à cette solution mais ça vaut le coup de regarder si ça peut t'éviter d'avoir à ouvrir une session automatiquement: http://support.microsoft.com/?id8642
Jacques
"RS" wrote in message news:
Bonjour,
Je souhaite ouvrir une session automatiquement sur un DC W2003 Standard.
Je sais, ce n'est pas conseillé, mais il y a un redémarrage automatique et il faut absolument qu'un programme soit lancé à l'ouverture de session.
Malheureusement, il m'est impossible de transformer ce programme en service. C'est pour ça que j'ai besoin d'ouvrir automatiquement une session administrateur lorsque le serveur redémarre.
Le serveur est dans un local fermé à clé, et il y a également une clé sur la facade du serveur, donc aucun risque que quelqu'un vienne éteindre ou mettre un CD dedans. De plus, il y a un mot de passe au bout de 3 minutes d'inactivité (ecran de veille avec mot de passe). Je pense que tout cela est suffisament sécurisé !
Est-ce possible ?
Cordialement.
Jean-Claude BELLAMY
Dans le message news: , RS s'est ainsi exprimé:
Bonjour,
Je souhaite ouvrir une session automatiquement sur un DC W2003 Standard.
Je sais, ce n'est pas conseillé, mais il y a un redémarrage automatique et il faut absolument qu'un programme soit lancé à l'ouverture de session.
Malheureusement, il m'est impossible de transformer ce programme en service. As-tu essayé avec "SrvAny" ou "FireDaemon" ?
C'est pour ça que j'ai besoin d'ouvrir automatiquement une session administrateur lorsque le serveur redémarre.
Tu peux essayer une stratégie locale :
Lancer GPEDIT.MSC Sélectionner :
Configuration ordinateur Paramètres Windows Scripts (Démarrage/arrêter" Démarrage (Double-clic) Indiquer le chemin du(des) script(s) ou applis (ils peuvent être placés n'importe où)
Cela peut aussi se "bidouiller" dans la BDR. Il n'y a que l'interface qui change (mais c'est un peu plus complexe que GPEDIT!)
On y trouve 5 entrées de type REG_SZ: "DisplayName" valeur "Stratégie de groupe locale" "FileSysPath" valeur "C:WINDOWSSystem32GroupPolicyMachine" (chemin à adapter à sa config) "GPO-ID" valeur "LocalGPO" "GPOName" valeur "Stratégie de groupe locale" "SOM-ID" valeur "Local"
Ensuite, il y a autant de sous-clefs qu'il y a de scripts ou programmes à exécuter (car il peut y en avoir plusieurs, à la différence du script de login dans le cas d'un domaine) Le nom de chaque sous-clef est un nombre, exprimé en hexadécimal, commençant à 0 P.ex. HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup b HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup f HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup 11 ... Chaque sous-clef contient 3 entrées : "ExecTime" de type REG_QWORD (type assez rare, de 8 octets, mais que REGEDIT affiche de travers sur 16 octets ! J'ai remonté le bug à MS) valeur : 00 00 00 00 00 00 00 00 "Parameters" de type REG_SZ valeur : des paramètres éventuels transmis au script "Script" de type REG_SZ valeur : le nom du script. Son chemin complet est à indiquer s'il n'est pas dans %systemroot%System32GroupPolicyMachineScriptsStartup
De plus, il doit exister un fichier "script.ini" placé dans %systemroot%System32GroupPolicyMachineScripts Ce script a la structure suivante : [Startup] 0CmdLine=test.cmd 0Parameters 1CmdLine=machin.exe 1Parameters 2CmdLine=c:vbstruc.vbs 2Parameters ...
Pour chaque script on a 2 lignes : "Ncmdline=xxxx" qui donne le nom du script "NParameters=yyyyy" qui donne les paramètres éventuels N étant le n° d'ordre du script (0, 1, 2, ..., 11, 12...) en décimal ici
NB: ce fichier script.ini sert aussi pour les scripts à la fermeture de Windows. Dans ce cas, la section commence par "[Shutdown]"
Je me suis interrogé sur la raison de la présence de ces fichiers "script.ini", qui font apparement double-emploi avec les données de la BDR. Cela est du au fait qu'après application des stratégies dans GPEDIT.MSC, seul le compte en cours voit sa BDR modifée immédiatement. Pour que cela s'applique aux autres comptes, c'est le fichier REGISTRY.POL qui va provoquer ces modifs lors de chaque ouverture de session. Or j'ai constaté après examen approfondi (en hexadécimal!) de REGISTRY.POL qu'il n'indiquait qu'un seul script (le 1er, indice 0) et non pas les suivants. C'est donc le système qui va à ce moment là compléter éventuellement avec le contenu de "script.ini"... Ouf !!!
<Mode Bidouilleur accro BDR OFF>
Si sous W2K ou XP PRO on passe par GPEDIT, on n'a pas à se préoccuper de tout cela. C'est seulement si on est sous XP HOME (dans lequel GPEDIT.MSC n'existe pas) qu'il faudra en tenir compte.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org *
Dans le message news:2C1C2050-E620-474F-BBF4-56C872048147@microsoft.com ,
RS <RS@discussions.microsoft.com> s'est ainsi exprimé:
Bonjour,
Je souhaite ouvrir une session automatiquement sur un DC W2003
Standard.
Je sais, ce n'est pas conseillé, mais il y a un redémarrage
automatique et il faut
absolument qu'un programme soit lancé à l'ouverture de session.
Malheureusement, il m'est impossible de transformer ce programme en
service.
As-tu essayé avec "SrvAny" ou "FireDaemon" ?
C'est pour ça que j'ai besoin d'ouvrir automatiquement une
session administrateur lorsque le serveur redémarre.
Tu peux essayer une stratégie locale :
Lancer GPEDIT.MSC
Sélectionner :
Configuration ordinateur
Paramètres Windows
Scripts (Démarrage/arrêter"
Démarrage
(Double-clic)
Indiquer le chemin du(des) script(s) ou applis
(ils peuvent être placés n'importe où)
Cela peut aussi se "bidouiller" dans la BDR.
Il n'y a que l'interface qui change (mais c'est un peu plus complexe que
GPEDIT!)
On y trouve 5 entrées de type REG_SZ:
"DisplayName"
valeur "Stratégie de groupe locale"
"FileSysPath"
valeur "C:WINDOWSSystem32GroupPolicyMachine"
(chemin à adapter à sa config)
"GPO-ID"
valeur "LocalGPO"
"GPOName"
valeur "Stratégie de groupe locale"
"SOM-ID"
valeur "Local"
Ensuite, il y a autant de sous-clefs qu'il y a de scripts ou programmes à
exécuter
(car il peut y en avoir plusieurs, à la différence du script de login dans
le cas d'un domaine)
Le nom de chaque sous-clef est un nombre, exprimé en hexadécimal, commençant
à 0
P.ex.
HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup
HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup b
HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup f
HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup 11
...
Chaque sous-clef contient 3 entrées :
"ExecTime" de type REG_QWORD (type assez rare, de 8 octets, mais que REGEDIT
affiche de travers sur 16 octets ! J'ai remonté le bug à MS)
valeur : 00 00 00 00 00 00 00 00
"Parameters" de type REG_SZ
valeur : des paramètres éventuels transmis au script
"Script" de type REG_SZ
valeur : le nom du script.
Son chemin complet est à indiquer s'il n'est pas dans
%systemroot%System32GroupPolicyMachineScriptsStartup
De plus, il doit exister un fichier "script.ini" placé dans
%systemroot%System32GroupPolicyMachineScripts
Ce script a la structure suivante :
[Startup]
0CmdLine=test.cmd
0Parameters 1CmdLine=machin.exe
1Parameters 2CmdLine=c:vbstruc.vbs
2Parameters ...
Pour chaque script on a 2 lignes :
"Ncmdline=xxxx" qui donne le nom du script
"NParameters=yyyyy" qui donne les paramètres éventuels
N étant le n° d'ordre du script (0, 1, 2, ..., 11, 12...) en décimal ici
NB: ce fichier script.ini sert aussi pour les scripts à la fermeture de
Windows.
Dans ce cas, la section commence par "[Shutdown]"
Je me suis interrogé sur la raison de la présence de ces fichiers
"script.ini", qui font apparement double-emploi avec les données de la BDR.
Cela est du au fait qu'après application des stratégies dans GPEDIT.MSC,
seul le compte en cours voit sa BDR modifée immédiatement.
Pour que cela s'applique aux autres comptes, c'est le fichier REGISTRY.POL
qui va provoquer ces modifs lors de chaque ouverture de session.
Or j'ai constaté après examen approfondi (en hexadécimal!) de REGISTRY.POL
qu'il n'indiquait qu'un seul script (le 1er, indice 0) et non pas les
suivants.
C'est donc le système qui va à ce moment là compléter éventuellement avec le
contenu de "script.ini"...
Ouf !!!
<Mode Bidouilleur accro BDR OFF>
Si sous W2K ou XP PRO on passe par GPEDIT, on n'a pas à se préoccuper de
tout cela.
C'est seulement si on est sous XP HOME (dans lequel GPEDIT.MSC n'existe pas)
qu'il faudra en tenir compte.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Jean-Claude.Bellamy@wanadoo.fr * JC.Bellamy@free.fr
C'est pour ça que j'ai besoin d'ouvrir automatiquement une session administrateur lorsque le serveur redémarre.
Tu peux essayer une stratégie locale :
Lancer GPEDIT.MSC Sélectionner :
Configuration ordinateur Paramètres Windows Scripts (Démarrage/arrêter" Démarrage (Double-clic) Indiquer le chemin du(des) script(s) ou applis (ils peuvent être placés n'importe où)
Cela peut aussi se "bidouiller" dans la BDR. Il n'y a que l'interface qui change (mais c'est un peu plus complexe que GPEDIT!)
On y trouve 5 entrées de type REG_SZ: "DisplayName" valeur "Stratégie de groupe locale" "FileSysPath" valeur "C:WINDOWSSystem32GroupPolicyMachine" (chemin à adapter à sa config) "GPO-ID" valeur "LocalGPO" "GPOName" valeur "Stratégie de groupe locale" "SOM-ID" valeur "Local"
Ensuite, il y a autant de sous-clefs qu'il y a de scripts ou programmes à exécuter (car il peut y en avoir plusieurs, à la différence du script de login dans le cas d'un domaine) Le nom de chaque sous-clef est un nombre, exprimé en hexadécimal, commençant à 0 P.ex. HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup b HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup f HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystemScriptsStartup 11 ... Chaque sous-clef contient 3 entrées : "ExecTime" de type REG_QWORD (type assez rare, de 8 octets, mais que REGEDIT affiche de travers sur 16 octets ! J'ai remonté le bug à MS) valeur : 00 00 00 00 00 00 00 00 "Parameters" de type REG_SZ valeur : des paramètres éventuels transmis au script "Script" de type REG_SZ valeur : le nom du script. Son chemin complet est à indiquer s'il n'est pas dans %systemroot%System32GroupPolicyMachineScriptsStartup
De plus, il doit exister un fichier "script.ini" placé dans %systemroot%System32GroupPolicyMachineScripts Ce script a la structure suivante : [Startup] 0CmdLine=test.cmd 0Parameters 1CmdLine=machin.exe 1Parameters 2CmdLine=c:vbstruc.vbs 2Parameters ...
Pour chaque script on a 2 lignes : "Ncmdline=xxxx" qui donne le nom du script "NParameters=yyyyy" qui donne les paramètres éventuels N étant le n° d'ordre du script (0, 1, 2, ..., 11, 12...) en décimal ici
NB: ce fichier script.ini sert aussi pour les scripts à la fermeture de Windows. Dans ce cas, la section commence par "[Shutdown]"
Je me suis interrogé sur la raison de la présence de ces fichiers "script.ini", qui font apparement double-emploi avec les données de la BDR. Cela est du au fait qu'après application des stratégies dans GPEDIT.MSC, seul le compte en cours voit sa BDR modifée immédiatement. Pour que cela s'applique aux autres comptes, c'est le fichier REGISTRY.POL qui va provoquer ces modifs lors de chaque ouverture de session. Or j'ai constaté après examen approfondi (en hexadécimal!) de REGISTRY.POL qu'il n'indiquait qu'un seul script (le 1er, indice 0) et non pas les suivants. C'est donc le système qui va à ce moment là compléter éventuellement avec le contenu de "script.ini"... Ouf !!!
<Mode Bidouilleur accro BDR OFF>
Si sous W2K ou XP PRO on passe par GPEDIT, on n'a pas à se préoccuper de tout cela. C'est seulement si on est sous XP HOME (dans lequel GPEDIT.MSC n'existe pas) qu'il faudra en tenir compte.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org *
