Pour changer automatiquement le mot de passe de "admin-local" sur
toutes les stations XP-pro d'un domaine W2003,
je me propose de faire un script de connexion qui
1. vérifie que la machine est XP-pro ( car on a aussi de vieux 98)
2. Si Xp : lance avec un privilège suffisant ( admin du domaine)
le script Change.vbs ci-dessous
Le but est de forcer le mot de passe
et de ne pas le refaire si c'est déjà fait.
Des fichiers nom-de-station.txt sont rangés dans un répertoire nommé
"Machines" situé à côté du script .
Chaque fichier contient
' - soit une première ligne avec le nouveau mot de passe
' puis (seconde ligne) une phrase confirmant la réussite
' - soit l'annonce de l'échec avec des infos sur l'erreur
' (infos sur 4 lignes)
Le "truc" des petits fichiers ( un par machine) m'est venu en songeant
qu'un unique fichier avec une liste serait source de pb ...( connexion
"simultanées", plantus ??? )
La trace laissée dans le répertoire "Machines" me permet de passer à
un autre mot de passe en changeant celui cité au début du script... et
sans toucher aux fichiers nom-de-station.txt
Ma question est donc multiple :
- La "stratégie" vous semble-t-elle bonne ?
- comment réaliser les point 1 et 2 ci-dessus ?
- Le script Change.vbs ci-dessous est-il bon ?
( compte tenu du résultat attendu )
Merci d'avance aux experts compatissants
et en particulier à JCB
dont j'ai sagement étudié et pillé les scripts
pour faire celui-ci...
If FSO.FileExists(CheminBecane) then
Set Fichier = FSO.OpenTextFile(CheminBecane, 1, False)
Resultat = Fichier.ReadLine
Fichier.close
Set Fichier = Nothing
If Résultat = MotDePasse then
Flag = False
end if
end if
If Flag = True
Set Fichier = FSO.OpenTextFile(CheminBecane, 2, True)
on error resume next
Set O_User = GetObject("WinNT://" & BECANE & "/" & KISSA &
",User")
If Err.Number<>0 Then
Erreur "GetObject"
else
O_User.SetPassword MotDePasse
If Err.Number<>0 Then
Erreur "SetPassword"
else
Fichier.Writeline MotDePasse
Fichier.Writeline "est le nouveau mot de passe de " &
BECANE & "."
end if
Sub Erreur(Ap)
H = Hex(Err.Number)
D = Err.Description
Texte = "Echec de la définition du mot de passe de " & KISSA & "
sur " & BECANE & VBCRLF
Texte = Texte & "Appel : " & Ap & VBCRLF & "Code : " & H & VBCRLF
Texte = Texte & "Description : " & D
Fichier.WriteLine Texte
End Sub
' =============================================
' =============================================
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
Gilles LAURENT
"moi" a écrit dans le message de news:45881757$0$27369$ | Bonjour,
Bonjour,
| Pour changer automatiquement le mot de passe de "admin-local" sur | toutes les stations XP-pro d'un domaine W2003, | je me propose de faire un script de connexion qui | 1. vérifie que la machine est XP-pro ( car on a aussi de vieux 98) | 2. Si Xp : lance avec un privilège suffisant ( admin du domaine) | le script Change.vbs ci-dessous [...]
Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités de votre domaine Windows 2003 à savoir les stratégies de groupe (scripts de démarrage) et les filtres WMI ? Dans ce cas, pour changer le mot de passe de l'administrateur local des postes de travail (Fr) via un script de démarrage : net user administrateur <password>
Pour appliquer la stratégie uniquement sur les postes XP et donc ignorer les systèmes Windows 2000/2003, il suffirait d'appliquer le filtre suivant sur la GPO : select * from Win32_OperatingSystem where caption like '%xp%'
Note : Les systèmes Windows 98 ne seront de toute façon pas impactés car non réceptifs aux GPO
Cette solution est robuste. Rien ne vous interdit ensuite de mettre en place un système de log pour contrôler le résultats des opérations ...
"moi" <moi@pas.la.ici> a écrit dans le message de
news:45881757$0$27369$ba4acef3@news.orange.fr
| Bonjour,
Bonjour,
| Pour changer automatiquement le mot de passe de "admin-local" sur
| toutes les stations XP-pro d'un domaine W2003,
| je me propose de faire un script de connexion qui
| 1. vérifie que la machine est XP-pro ( car on a aussi de vieux 98)
| 2. Si Xp : lance avec un privilège suffisant ( admin du domaine)
| le script Change.vbs ci-dessous
[...]
Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités de
votre domaine Windows 2003 à savoir les stratégies de groupe (scripts de
démarrage) et les filtres WMI ? Dans ce cas, pour changer le mot de
passe de l'administrateur local des postes de travail (Fr) via un script
de démarrage :
net user administrateur <password>
Pour appliquer la stratégie uniquement sur les postes XP et donc ignorer
les systèmes Windows 2000/2003, il suffirait d'appliquer le filtre
suivant sur la GPO :
select * from Win32_OperatingSystem where caption like '%xp%'
Note : Les systèmes Windows 98 ne seront de toute façon pas impactés car
non réceptifs aux GPO
Cette solution est robuste. Rien ne vous interdit ensuite de mettre en
place un système de log pour contrôler le résultats des opérations ...
"moi" a écrit dans le message de news:45881757$0$27369$ | Bonjour,
Bonjour,
| Pour changer automatiquement le mot de passe de "admin-local" sur | toutes les stations XP-pro d'un domaine W2003, | je me propose de faire un script de connexion qui | 1. vérifie que la machine est XP-pro ( car on a aussi de vieux 98) | 2. Si Xp : lance avec un privilège suffisant ( admin du domaine) | le script Change.vbs ci-dessous [...]
Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités de votre domaine Windows 2003 à savoir les stratégies de groupe (scripts de démarrage) et les filtres WMI ? Dans ce cas, pour changer le mot de passe de l'administrateur local des postes de travail (Fr) via un script de démarrage : net user administrateur <password>
Pour appliquer la stratégie uniquement sur les postes XP et donc ignorer les systèmes Windows 2000/2003, il suffirait d'appliquer le filtre suivant sur la GPO : select * from Win32_OperatingSystem where caption like '%xp%'
Note : Les systèmes Windows 98 ne seront de toute façon pas impactés car non réceptifs aux GPO
Cette solution est robuste. Rien ne vous interdit ensuite de mettre en place un système de log pour contrôler le résultats des opérations ...
Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités de votre domaine Windows 2003 à savoir les stratégies de groupe (scripts de démarrage) et les filtres WMI ? Dans ce cas, pour changer le mot de passe de l'administrateur local des postes de travail (Fr) via un script de démarrage : net user administrateur <password>
Ah mais j'ignorais cette possibilité de "net" dans un script ... Mon ignorance est sans borne... :o(
Ainsi, si j'ai bien compris , dans un truc.bat :
net user <nomlogin> <motdepasse> force le mot de passe d'un utilisateur local.
Comment faire, alors pour récupérer une éventuelle erreur ( j'aimerais disposer d'un suivi de cette affaire )
Pour appliquer la stratégie uniquement sur les postes XP et donc ignorer les systèmes Windows 2000/2003, il suffirait d'appliquer le filtre suivant sur la GPO : select * from Win32_OperatingSystem where caption like '%xp%'
en fait, ce ne sera pas nécessaire, y'a rien entre w98 et xp
Note : Les systèmes Windows 98 ne seront de toute façon pas impactés car non réceptifs aux GPO
Cette solution est robuste.
et simple :o)
Rien ne vous interdit ensuite de mettre en place un système de log pour contrôler le résultats des opérations ...
ça me serait bien utile, certaines machines ne fonctionnent pas chaque jour et donc j'aimerais pouvoir trouver simplement la liste des stations traitées ( et non traitées ).
Merci,
HB
Notre ami Gilles LAURENT tapota :
Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités
de votre domaine Windows 2003 à savoir les stratégies de groupe
(scripts de démarrage) et les filtres WMI ? Dans ce cas, pour
changer
le mot de passe de l'administrateur local des postes de travail (Fr)
via un script de démarrage :
net user administrateur <password>
Ah mais j'ignorais cette possibilité de "net" dans un script ...
Mon ignorance est sans borne... :o(
Ainsi, si j'ai bien compris , dans un truc.bat :
net user <nomlogin> <motdepasse>
force le mot de passe d'un utilisateur local.
Comment faire, alors pour récupérer une éventuelle erreur
( j'aimerais disposer d'un suivi de cette affaire )
Pour appliquer la stratégie uniquement sur les postes XP et donc
ignorer les systèmes Windows 2000/2003, il suffirait d'appliquer le
filtre suivant sur la GPO :
select * from Win32_OperatingSystem where caption like '%xp%'
en fait, ce ne sera pas nécessaire, y'a rien entre w98 et xp
Note : Les systèmes Windows 98 ne seront de toute façon pas impactés
car non réceptifs aux GPO
Cette solution est robuste.
et simple :o)
Rien ne vous interdit ensuite de mettre en
place un système de log pour contrôler le résultats des opérations
...
ça me serait bien utile, certaines machines ne fonctionnent pas chaque
jour et donc j'aimerais pouvoir trouver simplement la liste des
stations traitées ( et non traitées ).
Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités de votre domaine Windows 2003 à savoir les stratégies de groupe (scripts de démarrage) et les filtres WMI ? Dans ce cas, pour changer le mot de passe de l'administrateur local des postes de travail (Fr) via un script de démarrage : net user administrateur <password>
Ah mais j'ignorais cette possibilité de "net" dans un script ... Mon ignorance est sans borne... :o(
Ainsi, si j'ai bien compris , dans un truc.bat :
net user <nomlogin> <motdepasse> force le mot de passe d'un utilisateur local.
Comment faire, alors pour récupérer une éventuelle erreur ( j'aimerais disposer d'un suivi de cette affaire )
Pour appliquer la stratégie uniquement sur les postes XP et donc ignorer les systèmes Windows 2000/2003, il suffirait d'appliquer le filtre suivant sur la GPO : select * from Win32_OperatingSystem where caption like '%xp%'
en fait, ce ne sera pas nécessaire, y'a rien entre w98 et xp
Note : Les systèmes Windows 98 ne seront de toute façon pas impactés car non réceptifs aux GPO
Cette solution est robuste.
et simple :o)
Rien ne vous interdit ensuite de mettre en place un système de log pour contrôler le résultats des opérations ...
ça me serait bien utile, certaines machines ne fonctionnent pas chaque jour et donc j'aimerais pouvoir trouver simplement la liste des stations traitées ( et non traitées ).
Merci,
HB
Gilles LAURENT
"moi" a écrit dans le message de news:4589871f$0$5076$
[...] | Ainsi, si j'ai bien compris , dans un truc.bat : | | net user <nomlogin> <motdepasse> | force le mot de passe d'un utilisateur local.
Oui
| Comment faire, alors pour récupérer une éventuelle erreur | ( j'aimerais disposer d'un suivi de cette affaire )
Par exemple générer un évènement dans le journal Application du serveur Windows 2003 en utilisant le code de sortie de la commande net user. Vous serez ensuite en mesure d'extraire et d'analyser les évènements à partir d'un point central.
net user administrateur <password> eventcreate /s <server> /id %errorlevel% /t information /d [%errorlevel%]
Pour extraire les informations de réussite de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier=0" get computername,eventidentifier,timegenerated
Pour extraire les évènements d'échec de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier<>0" get computername,eventidentifier,timegenerated
Note : Vous pouvez adapter la source, créer un journal spécifique, ...
"moi" <moi@pas.la.ici> a écrit dans le message de
news:4589871f$0$5076$ba4acef3@news.orange.fr
[...]
| Ainsi, si j'ai bien compris , dans un truc.bat :
|
| net user <nomlogin> <motdepasse>
| force le mot de passe d'un utilisateur local.
Oui
| Comment faire, alors pour récupérer une éventuelle erreur
| ( j'aimerais disposer d'un suivi de cette affaire )
Par exemple générer un évènement dans le journal Application du serveur
Windows 2003 en utilisant le code de sortie de la commande net user.
Vous serez ensuite en mesure d'extraire et d'analyser les évènements à
partir d'un point central.
net user administrateur <password>
eventcreate /s <server> /id %errorlevel% /t information /d
[%errorlevel%]
Pour extraire les informations de réussite de traitement :
=> sur une seule ligne :
>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier=0"
get computername,eventidentifier,timegenerated
Pour extraire les évènements d'échec de traitement :
=> sur une seule ligne :
>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier<>0"
get computername,eventidentifier,timegenerated
Note : Vous pouvez adapter la source, créer un journal spécifique, ...
"moi" a écrit dans le message de news:4589871f$0$5076$
[...] | Ainsi, si j'ai bien compris , dans un truc.bat : | | net user <nomlogin> <motdepasse> | force le mot de passe d'un utilisateur local.
Oui
| Comment faire, alors pour récupérer une éventuelle erreur | ( j'aimerais disposer d'un suivi de cette affaire )
Par exemple générer un évènement dans le journal Application du serveur Windows 2003 en utilisant le code de sortie de la commande net user. Vous serez ensuite en mesure d'extraire et d'analyser les évènements à partir d'un point central.
net user administrateur <password> eventcreate /s <server> /id %errorlevel% /t information /d [%errorlevel%]
Pour extraire les informations de réussite de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier=0" get computername,eventidentifier,timegenerated
Pour extraire les évènements d'échec de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier<>0" get computername,eventidentifier,timegenerated
Note : Vous pouvez adapter la source, créer un journal spécifique, ...
Merci beaucoup pour ces précisions. Je vais tenter d'être moins ignorant :o( j'avoue humblement que la récupération d'évenements dans le journal du même nom ne m'avais pas éfleuré. La commande ">wmic ntevent <paramètres divers...>" m'était jusqu'à ce jour inconnue ... Je vais me renseigner.
J'ose donc une question peut-être sotte : Peut-on, pour retrouver plus facilement les choses, créer une rublique de plus dans le journal car la rubrique "application" existe déjà et contient sans doute "nativement" pas mal de choses, non ? J'ai noté que certains prgm ajoutent une rubrique rien-que-pour-eux... alors... ( comme mon anti-virus )
A+
HB
net user <nomlogin> <motdepasse> force le mot de passe d'un utilisateur local.
Oui
Comment faire, alors pour récupérer une éventuelle erreur ( j'aimerais disposer d'un suivi de cette affaire )
Par exemple générer un évènement dans le journal Application du serveur Windows 2003 en utilisant le code de sortie de la commande net user. Vous serez ensuite en mesure d'extraire et d'analyser les évènements à partir d'un point central.
net user administrateur <password> eventcreate /s <server> /id %errorlevel% /t information /d [%errorlevel%]
Pour extraire les informations de réussite de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier=0" get computername,eventidentifier,timegenerated
Pour extraire les évènements d'échec de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier<>0" get computername,eventidentifier,timegenerated
Note : Vous pouvez adapter la source, créer un journal spécifique, ...
Notre ami Gilles LAURENT tapota :
salut,
Merci beaucoup pour ces précisions. Je vais tenter d'être moins
ignorant :o(
j'avoue humblement que la récupération d'évenements dans le journal du
même nom ne m'avais pas éfleuré.
La commande
">wmic ntevent <paramètres divers...>"
m'était jusqu'à ce jour inconnue ...
Je vais me renseigner.
J'ose donc une question peut-être sotte :
Peut-on, pour retrouver plus facilement les choses, créer une rublique
de plus dans le journal
car la rubrique "application" existe déjà et contient sans doute
"nativement" pas mal de choses, non ?
J'ai noté que certains prgm ajoutent une rubrique rien-que-pour-eux...
alors...
( comme mon anti-virus )
A+
HB
net user <nomlogin> <motdepasse>
force le mot de passe d'un utilisateur local.
Oui
Comment faire, alors pour récupérer une éventuelle erreur
( j'aimerais disposer d'un suivi de cette affaire )
Par exemple générer un évènement dans le journal Application du
serveur Windows 2003 en utilisant le code de sortie de la commande
net user. Vous serez ensuite en mesure d'extraire et d'analyser les
évènements à partir d'un point central.
net user administrateur <password>
eventcreate /s <server> /id %errorlevel% /t information /d
[%errorlevel%]
Pour extraire les informations de réussite de traitement :
=> sur une seule ligne :
>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier=0"
get computername,eventidentifier,timegenerated
Pour extraire les évènements d'échec de traitement :
=> sur une seule ligne :
>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier<>0"
get computername,eventidentifier,timegenerated
Note : Vous pouvez adapter la source, créer un journal spécifique,
...
Merci beaucoup pour ces précisions. Je vais tenter d'être moins ignorant :o( j'avoue humblement que la récupération d'évenements dans le journal du même nom ne m'avais pas éfleuré. La commande ">wmic ntevent <paramètres divers...>" m'était jusqu'à ce jour inconnue ... Je vais me renseigner.
J'ose donc une question peut-être sotte : Peut-on, pour retrouver plus facilement les choses, créer une rublique de plus dans le journal car la rubrique "application" existe déjà et contient sans doute "nativement" pas mal de choses, non ? J'ai noté que certains prgm ajoutent une rubrique rien-que-pour-eux... alors... ( comme mon anti-virus )
A+
HB
net user <nomlogin> <motdepasse> force le mot de passe d'un utilisateur local.
Oui
Comment faire, alors pour récupérer une éventuelle erreur ( j'aimerais disposer d'un suivi de cette affaire )
Par exemple générer un évènement dans le journal Application du serveur Windows 2003 en utilisant le code de sortie de la commande net user. Vous serez ensuite en mesure d'extraire et d'analyser les évènements à partir d'un point central.
net user administrateur <password> eventcreate /s <server> /id %errorlevel% /t information /d [%errorlevel%]
Pour extraire les informations de réussite de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier=0" get computername,eventidentifier,timegenerated
Pour extraire les évènements d'échec de traitement : => sur une seule ligne :
>wmic ntevent where "logfile='application' and sourcename='eventcreate' and eventidentifier<>0" get computername,eventidentifier,timegenerated
Note : Vous pouvez adapter la source, créer un journal spécifique, ...
Gilles LAURENT
"moi" a écrit dans le message de news:458ac873$0$27399$ | salut,
Bonsoir,
[...] | Peut-on, pour retrouver plus facilement les choses, créer une rublique | de plus dans le journal | car la rubrique "application" existe déjà et contient sans doute | "nativement" pas mal de choses, non ?
Oui, il est possible de créer un journal spécifique et c'est même recommandé. Pour cela, il suffit de créer une nouvelle clé de registre sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de cette nouvelle clé correspondra au nom du nouveau journal. Cette modification sera prise en compte par l'observateur d'événements sans nécessiter de rédémarrage (il sera toutefois nécessaire de relancer la console eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau journal héritera des propriétés par défaut (taille, rétention, ...). Le fichier journal (<journal>.evt) sera automatiquement créé dans le dossier %systemroot%system32config<journal>.evt
Après ces modifications, il sera donc nécessaire de spécifier dans la ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L <journal>'. L'opération d'extraction et d'analyse des logs se fera à partir d'un poste d'administration Windows XP.
"moi" <moi@pas.la.ici> a écrit dans le message de
news:458ac873$0$27399$ba4acef3@news.orange.fr
| salut,
Bonsoir,
[...]
| Peut-on, pour retrouver plus facilement les choses, créer une rublique
| de plus dans le journal
| car la rubrique "application" existe déjà et contient sans doute
| "nativement" pas mal de choses, non ?
Oui, il est possible de créer un journal spécifique et c'est même
recommandé. Pour cela, il suffit de créer une nouvelle clé de registre
sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de cette
nouvelle clé correspondra au nom du nouveau journal. Cette modification
sera prise en compte par l'observateur d'événements sans nécessiter de
rédémarrage (il sera toutefois nécessaire de relancer la console
eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau journal
héritera des propriétés par défaut (taille, rétention, ...). Le fichier
journal (<journal>.evt) sera automatiquement créé dans le dossier
%systemroot%system32config<journal>.evt
Après ces modifications, il sera donc nécessaire de spécifier dans la
ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L
<journal>'. L'opération d'extraction et d'analyse des logs se fera à
partir d'un poste d'administration Windows XP.
Note : Sur votre poste d'administration sera également installé Windows
PowerShell pour vous aider dans vos tâches d'administration courante. Je
vous invite à découvrir le nouveau shell Microsoft Windows PowerShell
consultable à cette adresse :
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
Ainsi que le blog de Jacques Barathon [MS] sur Windows PowerShell :
http://janel.spaces.msn.com/blog
"moi" a écrit dans le message de news:458ac873$0$27399$ | salut,
Bonsoir,
[...] | Peut-on, pour retrouver plus facilement les choses, créer une rublique | de plus dans le journal | car la rubrique "application" existe déjà et contient sans doute | "nativement" pas mal de choses, non ?
Oui, il est possible de créer un journal spécifique et c'est même recommandé. Pour cela, il suffit de créer une nouvelle clé de registre sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de cette nouvelle clé correspondra au nom du nouveau journal. Cette modification sera prise en compte par l'observateur d'événements sans nécessiter de rédémarrage (il sera toutefois nécessaire de relancer la console eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau journal héritera des propriétés par défaut (taille, rétention, ...). Le fichier journal (<journal>.evt) sera automatiquement créé dans le dossier %systemroot%system32config<journal>.evt
Après ces modifications, il sera donc nécessaire de spécifier dans la ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L <journal>'. L'opération d'extraction et d'analyse des logs se fera à partir d'un poste d'administration Windows XP.
Avec tout ça je devrais pouvoir m'en sortir "comme un chef" :o)
bien amicalement,
HB
Bonsoir,
[...]
Peut-on, pour retrouver plus facilement les choses, créer une rublique de plus dans le journal car la rubrique "application" existe déjà et contient sans doute "nativement" pas mal de choses, non ?
Oui, il est possible de créer un journal spécifique et c'est même recommandé. Pour cela, il suffit de créer une nouvelle clé de registre sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de cette nouvelle clé correspondra au nom du nouveau journal. Cette modification sera prise en compte par l'observateur d'événements sans nécessiter de rédémarrage (il sera toutefois nécessaire de relancer la console eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau journal héritera des propriétés par défaut (taille, rétention, ...). Le fichier journal (<journal>.evt) sera automatiquement créé dans le dossier %systemroot%system32config<journal>.evt
Après ces modifications, il sera donc nécessaire de spécifier dans la ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L <journal>'. L'opération d'extraction et d'analyse des logs se fera à partir d'un poste d'administration Windows XP.
Avec tout ça je devrais pouvoir m'en sortir
"comme un chef" :o)
bien amicalement,
HB
Bonsoir,
[...]
Peut-on, pour retrouver plus facilement les choses, créer une
rublique de plus dans le journal
car la rubrique "application" existe déjà et contient sans doute
"nativement" pas mal de choses, non ?
Oui, il est possible de créer un journal spécifique et c'est même
recommandé. Pour cela, il suffit de créer une nouvelle clé de
registre
sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de
cette
nouvelle clé correspondra au nom du nouveau journal. Cette
modification sera prise en compte par l'observateur d'événements
sans
nécessiter de rédémarrage (il sera toutefois nécessaire de relancer
la console eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau
journal héritera des propriétés par défaut (taille, rétention, ...).
Le fichier journal (<journal>.evt) sera automatiquement créé dans le
dossier %systemroot%system32config<journal>.evt
Après ces modifications, il sera donc nécessaire de spécifier dans
la
ligne de commandes 'wmic' le nom du journal spécifique via l'option
'/L <journal>'. L'opération d'extraction et d'analyse des logs se
fera à partir d'un poste d'administration Windows XP.
Note : Sur votre poste d'administration sera également installé
Windows PowerShell pour vous aider dans vos tâches d'administration
courante. Je vous invite à découvrir le nouveau shell Microsoft
Windows PowerShell consultable à cette adresse :
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
Ainsi que le blog de Jacques Barathon [MS] sur Windows PowerShell :
http://janel.spaces.msn.com/blog
Avec tout ça je devrais pouvoir m'en sortir "comme un chef" :o)
bien amicalement,
HB
Bonsoir,
[...]
Peut-on, pour retrouver plus facilement les choses, créer une rublique de plus dans le journal car la rubrique "application" existe déjà et contient sans doute "nativement" pas mal de choses, non ?
Oui, il est possible de créer un journal spécifique et c'est même recommandé. Pour cela, il suffit de créer une nouvelle clé de registre sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de cette nouvelle clé correspondra au nom du nouveau journal. Cette modification sera prise en compte par l'observateur d'événements sans nécessiter de rédémarrage (il sera toutefois nécessaire de relancer la console eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau journal héritera des propriétés par défaut (taille, rétention, ...). Le fichier journal (<journal>.evt) sera automatiquement créé dans le dossier %systemroot%system32config<journal>.evt
Après ces modifications, il sera donc nécessaire de spécifier dans la ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L <journal>'. L'opération d'extraction et d'analyse des logs se fera à partir d'un poste d'administration Windows XP.
Après ces modifications, il sera donc nécessaire de spécifier dans la ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L <journal>'.
Euh alors là je ne comprend plus ... :o( C'est pas dans "eventcreate" qui devient (( Sur Une Ligne) eventcreate /s MonServeur /id %errorlevel% /t information /d [%errorlevel%] /L MonJournal
[...]
L'opération d'extraction et d'analyse des logs se fera à partir d'un poste d'administration Windows XP.
Ne puis-je l'automatiser en tâche planifiée sur le serveur avec, pour les échecs un truc.bat contenant , par exemple : ( Sur Une Ligne) _________________________________________ wmic ntevent where "logfile='MonJournal' and sourcename='eventcreate' and eventidentifier<>0" get computername,eventidentifier,timegenerated /format:htable >D:Outilsmonjournalechecs.htm _________________________________________
et tant que j'y suis ... peut effcer des évènements avec une ligne qui va bien genre ( Sur Une Ligne)
wmic ntevent where "logfile='MonJournal' and sourcename='eventcreate' and eventidentifier<>0" delete [...]
bon ... Promis, quand je serais grand, je passe à PowerShell :o)
HB
Notre ami Gilles LAURENT tapota :
[...]
Après ces modifications, il sera donc nécessaire de spécifier dans
la
ligne de commandes 'wmic' le nom du journal spécifique via l'option
'/L <journal>'.
Euh alors là je ne comprend plus ... :o(
C'est pas dans "eventcreate" qui devient
(( Sur Une Ligne)
eventcreate /s MonServeur /id %errorlevel%
/t information /d [%errorlevel%] /L MonJournal
[...]
L'opération d'extraction et d'analyse des logs se
fera à partir d'un poste d'administration Windows XP.
Ne puis-je l'automatiser en tâche planifiée sur le serveur
avec, pour les échecs un truc.bat contenant , par exemple :
( Sur Une Ligne)
_________________________________________
wmic ntevent
where "logfile='MonJournal'
and sourcename='eventcreate' and eventidentifier<>0"
get computername,eventidentifier,timegenerated
/format:htable >D:Outilsmonjournalechecs.htm
_________________________________________
et tant que j'y suis ... peut effcer des évènements avec une ligne qui
va bien
genre
( Sur Une Ligne)
wmic ntevent
where "logfile='MonJournal'
and sourcename='eventcreate' and eventidentifier<>0"
delete
[...]
bon ...
Promis, quand je serais grand, je passe à PowerShell :o)
Après ces modifications, il sera donc nécessaire de spécifier dans la ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L <journal>'.
Euh alors là je ne comprend plus ... :o( C'est pas dans "eventcreate" qui devient (( Sur Une Ligne) eventcreate /s MonServeur /id %errorlevel% /t information /d [%errorlevel%] /L MonJournal
[...]
L'opération d'extraction et d'analyse des logs se fera à partir d'un poste d'administration Windows XP.
Ne puis-je l'automatiser en tâche planifiée sur le serveur avec, pour les échecs un truc.bat contenant , par exemple : ( Sur Une Ligne) _________________________________________ wmic ntevent where "logfile='MonJournal' and sourcename='eventcreate' and eventidentifier<>0" get computername,eventidentifier,timegenerated /format:htable >D:Outilsmonjournalechecs.htm _________________________________________
et tant que j'y suis ... peut effcer des évènements avec une ligne qui va bien genre ( Sur Une Ligne)
wmic ntevent where "logfile='MonJournal' and sourcename='eventcreate' and eventidentifier<>0" delete [...]
bon ... Promis, quand je serais grand, je passe à PowerShell :o)
HB
Gilles LAURENT
"moi" a écrit dans le message de news:458b06c0$0$25954$
Bonjour,
| Ne puis-je l'automatiser en tâche planifiée sur le serveur | avec, pour les échecs un truc.bat contenant , par exemple : | ( Sur Une Ligne) | wmic ntevent | where "logfile='MonJournal' | and sourcename='eventcreate' and eventidentifier<>0" | get computername,eventidentifier,timegenerated | /format:htable >D:Outilsmonjournalechecs.htm
Oui, bien sûr, libre cours à votre imagination ;-)
| et tant que j'y suis ... peut effcer des évènements avec une ligne qui | va bien | genre | ( Sur Une Ligne) | wmic ntevent | where "logfile='MonJournal' | and sourcename='eventcreate' and eventidentifier<>0" | delete
Non, il n'est pas possible de supprimer de manière sélective des événements. Par contre, vous pouvez vider le journal (i.e supprimer tous les enregistrements) via la classe wmi Win32_NTEventlogFile (alias nteventlog sous la console wmic). Cela donne donc : >wmic nteventlog where logfilename='<journal>' call cleareventlog
| Promis, quand je serais grand, je passe à PowerShell :o)
"moi" <moi@pas.la.ici> a écrit dans le message de
news:458b06c0$0$25954$ba4acef3@news.orange.fr
Bonjour,
| Ne puis-je l'automatiser en tâche planifiée sur le serveur
| avec, pour les échecs un truc.bat contenant , par exemple :
| ( Sur Une Ligne)
| wmic ntevent
| where "logfile='MonJournal'
| and sourcename='eventcreate' and eventidentifier<>0"
| get computername,eventidentifier,timegenerated
| /format:htable >D:Outilsmonjournalechecs.htm
Oui, bien sûr, libre cours à votre imagination ;-)
| et tant que j'y suis ... peut effcer des évènements avec une ligne qui
| va bien
| genre
| ( Sur Une Ligne)
| wmic ntevent
| where "logfile='MonJournal'
| and sourcename='eventcreate' and eventidentifier<>0"
| delete
Non, il n'est pas possible de supprimer de manière sélective des
événements. Par contre, vous pouvez vider le journal (i.e supprimer tous
les enregistrements) via la classe wmi Win32_NTEventlogFile (alias
nteventlog sous la console wmic). Cela donne donc :
>wmic nteventlog where logfilename='<journal>' call cleareventlog
| Promis, quand je serais grand, je passe à PowerShell :o)
"moi" a écrit dans le message de news:458b06c0$0$25954$
Bonjour,
| Ne puis-je l'automatiser en tâche planifiée sur le serveur | avec, pour les échecs un truc.bat contenant , par exemple : | ( Sur Une Ligne) | wmic ntevent | where "logfile='MonJournal' | and sourcename='eventcreate' and eventidentifier<>0" | get computername,eventidentifier,timegenerated | /format:htable >D:Outilsmonjournalechecs.htm
Oui, bien sûr, libre cours à votre imagination ;-)
| et tant que j'y suis ... peut effcer des évènements avec une ligne qui | va bien | genre | ( Sur Une Ligne) | wmic ntevent | where "logfile='MonJournal' | and sourcename='eventcreate' and eventidentifier<>0" | delete
Non, il n'est pas possible de supprimer de manière sélective des événements. Par contre, vous pouvez vider le journal (i.e supprimer tous les enregistrements) via la classe wmi Win32_NTEventlogFile (alias nteventlog sous la console wmic). Cela donne donc : >wmic nteventlog where logfilename='<journal>' call cleareventlog
| Promis, quand je serais grand, je passe à PowerShell :o)
Oui, bien sûr, libre cours à votre imagination ;-)
et tant que j'y suis ... peut effcer des évènements avec une ligne qui va bien genre ( Sur Une Ligne) wmic ntevent where "logfile='MonJournal' and sourcename='eventcreate' and eventidentifier<>0" delete
Non, il n'est pas possible de supprimer de manière sélective des événements. Par contre, vous pouvez vider le journal (i.e supprimer tous les enregistrements) via la classe wmi Win32_NTEventlogFile (alias nteventlog sous la console wmic). Cela donne donc : >wmic nteventlog where logfilename='<journal>' call cleareventlog
nickel , cela devrait me suffire... en récupérant plutôt du *.txt pour
les réussites, je devrais pouvoir ajouter au fichier des réussites (
au lieu de > ) avant de vider le journal puisque le fichier des échecs, lui, repart logiquement sur du neuf à chaque fois ...
Je passerais à la phase "expérimentation avant la mise en oeuvre globale" en me limitant à une petite "sous-OU" contenant peu de postes ...
Merci encore pour ces lumineuses infos ... je crois avoir compris l'essentiel .
C'est toujours un plaisir de se renseigner sur ce NG !
Bien amicalement,
HB
Notre ami Gilles LAURENT tapota :
(...)
Oui, bien sûr, libre cours à votre imagination ;-)
et tant que j'y suis ... peut effcer des évènements avec une ligne
qui va bien
genre
( Sur Une Ligne)
wmic ntevent
where "logfile='MonJournal'
and sourcename='eventcreate' and eventidentifier<>0"
delete
Non, il n'est pas possible de supprimer de manière sélective des
événements. Par contre, vous pouvez vider le journal (i.e supprimer
tous les enregistrements) via la classe wmi Win32_NTEventlogFile
(alias nteventlog sous la console wmic). Cela donne donc :
>wmic nteventlog where logfilename='<journal>' call cleareventlog
nickel , cela devrait me suffire... en récupérant plutôt du *.txt pour
les réussites, je devrais pouvoir ajouter au fichier des réussites (
au lieu de > ) avant de vider le journal puisque le fichier des
échecs, lui, repart logiquement sur du neuf à chaque fois ...
Je passerais à la phase "expérimentation avant la mise en oeuvre
globale" en me limitant à une petite "sous-OU" contenant peu de postes
...
Merci encore pour ces lumineuses infos ...
je crois avoir compris l'essentiel .
C'est toujours un plaisir de se renseigner sur ce NG !
Oui, bien sûr, libre cours à votre imagination ;-)
et tant que j'y suis ... peut effcer des évènements avec une ligne qui va bien genre ( Sur Une Ligne) wmic ntevent where "logfile='MonJournal' and sourcename='eventcreate' and eventidentifier<>0" delete
Non, il n'est pas possible de supprimer de manière sélective des événements. Par contre, vous pouvez vider le journal (i.e supprimer tous les enregistrements) via la classe wmi Win32_NTEventlogFile (alias nteventlog sous la console wmic). Cela donne donc : >wmic nteventlog where logfilename='<journal>' call cleareventlog
nickel , cela devrait me suffire... en récupérant plutôt du *.txt pour
les réussites, je devrais pouvoir ajouter au fichier des réussites (
au lieu de > ) avant de vider le journal puisque le fichier des échecs, lui, repart logiquement sur du neuf à chaque fois ...
Je passerais à la phase "expérimentation avant la mise en oeuvre globale" en me limitant à une petite "sous-OU" contenant peu de postes ...
Merci encore pour ces lumineuses infos ... je crois avoir compris l'essentiel .
C'est toujours un plaisir de se renseigner sur ce NG !
