Ce qui suit concerne
Windows NT4, mais aussi, sauf précision contraire, Windows 2000, Windows XP
et Windows 2003.
Pour tout ce qui est spécifique à Windows 2000, prière de consulter le
chapitre
Windows 2000
Pour tout ce qui est spécifique à Windows XP et 2003, prière de consulter le
chapitre
Windows XP /2003
Variables d'environnement sous Windows 9x dans un script de connexion
Test de l'appartenance d'un compte utilisateur à un groupe donné
Utilisation de NTFS pour protéger facilement l'accès à un fichier ou un dossier
Impossibilité d'accéder à certains dossiers ou fichiers après réinstallation de Windows
A propos des branches HKLM\SYSTEM\ControlSetxxx et HKLM\SYSTEM\CurrentControlSet
Les partitions FAT16 et HPFS sont limitées à 2^32
octets (= 4 294 967 296 = 4 Goctets) soit le double de ce qu'on
observe (pour la FAT16) sous DOS et Windows 95. Cela est du au fait que NT accepte des
clusters de taille maximale égale à 65536 octets.
De plus, en ce qui concerne Windows NT 4 uniquement, pour lequel les
clusters peuvent atteindre la taille de 262144 octets, cette limite est
repoussée à 16 Goctets !
Les partitions NTFS sont limitées en théorie à 2^64 octets (= 18
446 744 073 709 551 616) soit 16 Exaoctets.
En réalité, en raison des limitations dues au BIOS (adressage des secteurs),
cette taille maximale est ramenée à 2 To et actuellement à
128 Go (Car seulement 28 bits sur 32 sont utilisés pour l'instant dans
l'adressage d'un secteur en mode LBA)
La partition
de boot (contenant NTLDR, boot.ini, etc.) DOIT
être entièrement dans la première zone de 7.9 Goctets du disque. Ceci
est dû à une utilisation restreinte par NTLDR de l'interruption 13H
du BIOS pour le disque dur système (IDE ou SCSI) . Cette interruption codant sur 24 bits
les positions de cylindres, têtes et secteurs d'un disque, dans le cas où la
défragmentation déplacerait des données au-delà de cette zone, le boot deviendrait
impossible.
On retrouve cette limitation à 8 Go dans la gestion des disques de taille supérieure à 8Go par Windows NT. Par défaut (jusqu'au Service Pack 3), NT4 ne sait pas gérer ces disques, et ne voit pas l'espace disque situé au-delà de 8Go. Cette carence est corrigée par la mise à jour du driver ATAPI.SYS, qui est inclus dans le SP4 et au delà.
Cf. l'article Q197667 de la Knowledge Base :
"Installing Windows NT Server on a Large IDE Hard Disk"
http://support.microsoft.com/support/kb/articles/q197/6/67.asp
Lors d'une première installation, on doit
utiliser séparément ce driver, en le
copiant sur une disquette, qui sera introduite au cours de l'installation
de Windows NT (lorsque le programme d'installation demande tout au début si on
a des périphériques particuliers) .
Ce driver se présente sous la forme d'un fichier auto extractible :
Le mode opératoire de l'installation de ce driver est décrit et commenté dans le chapitre consacré au multiboot (paragraphe "Suggestion..")
Il
existe une limitation supplémentaire, concernant la partition de boot de
NT. Elle ne dure toutefois que le temps de l'installation . En effet, même si
on a choisi d'installer NT sur une partition NTFS, elle va être créée
au départ en FAT16, et ce n'est qu'ensuite (à un redémarrage suivant)
qu'elle sera convertie en NTFS. Or une partition FAT16 sous Windows NT a
une taille limite de 4 Go!
Donc la partition de boot de NT, lors de son installation, est
limitée à 4Go.
Il est possible d'utiliser des partitions FAT32 sous Windows NT4 à l'aide d'un driver spécial, non Microsoft, disponible sur les sites suivants :
Version gratuite (Lecture seule) |
|
Version payante (Lecture et écriture) |
L'accès aux partitions FAT32 étant réalisé à l'aide d'un driver (FAT32.SYS), lequel est chargé au cours du démarrage de NT, il n'est donc pas possible d'avoir une partition de démarrage de NT4 en FAT32.
Windows 2000 sait par contre accéder pleinement aux partitions FAT32
(Ceci ne concerne que NT4, Windows 2000 sachant gérer nativement ce type de disques)
L’installation et le fonctionnement de NT sur des disques de taille > 8Go peut poser des problèmes.
En effet, l’accès aux secteurs situés au delà de 8 Go ne peut être réalisé qu’en utilisant les
extensions de l’interruption logicielle 13h (appelé aussi mode
LBA). Or par défaut (en absence de tout Service Pack) NT4 ignore ce mode. Si bien que l’installation de NT4 sur un disque physique de plus de 8Go risque de mal se passer (par exemple si on a
déjà partitionné le disque, en ayant créé des partitions étendue et/ou logique dépassant les 8 premiers Go).
Pour s'affranchir de cette contrainte, Microsoft préconise l'utilisation du fichier ATAPI.SYS au début de l'installation (ce fichier, qui fait partie du SP4 et au delà, va remplacer le fichier existant de NT).
Cela ne fonctionne pas si on a lancé
l'installation de NT
en démarrant directement depuis le CDROM.
Il faut donc OBLIGATOIREMENT utiliser les disquettes de NT!
Cf. article Q197667
de la Knowledge Base :
"Installing
Windows NT Server on a Large IDE Hard Disk"
Le fichier ATAPI.SYS est contenu dans un fichier
autoextractible disponible ici, qu'il faudra copier sur une disquette
formatée DOS (intitulée, p.ex., "Microsoft ATAPI Service Pack 4 IDE
Driver")
Exécuter ATAPI.EXE depuis cette
disquette.
L'installation de NT doit alors s'effectuer ainsi :
Démarrer l'ordinateur à l'aide des 3 disquettes de NT
Lorsque le programme d'installation demande s'il doit détecter les périphériques de mémoire de masse, appuyer sur S afin de sauter cette détection.
Le programme d'installation affiche alors une liste qui doit être vide, appuyer encore sur S et insérer la disquette Microsoft ATAPI Service Pack 4 IDE Driver et appuyer sur la touche Entrée 2 fois de suite.
La disquette est alors lue, "Microsoft ATAPI Service Pack 4 IDE driver" est affiché, appuyer sur Entrée pour valider ce choix.
Le programme d'installation déclare "Microsoft ATAPI Service Pack 4 IDE Driver" comme étant installé. Si d'autres périphériques de mémoire de masse doivent être ajoutés, appuyer sur S, sinon appuyer sur Entrée, puis continuer la procédure d'installation.
Le programme d'installation va redemander l'insertion de la disquette ATAPI lors de la phase de copie des fichiers de NT depuis le CDROM, après qu'une partition a été choisie et/ou formatée.
Le fichier boot.ini est lu au démarrage de NT par NTLDR (cf.
article consacré au démarrage de NT) .
Chaque ligne de la section [Operating system] a l'une des structures
suivantes :
1ère structure
Elle concerne Windows NT
Nom ARC ( Advanced RISC Computing)
Un nom ARC, qui sert à désigner le disque et la partition où se trouve NT, est
ainsi constitué suivant 2 syntaxes possibles :
SCSI(x)disk(y)rdisk(z)partition(w) (boot depuis
un disque SCSI)
ou
MULTI(x)disk(y)rdisk(z)partition(w) (boot
depuis un disque IDE /EIDE /ESDI)
La distinction de syntaxe SCSI ou MULTI est importante, car elle indique à NT comment procéder pour
accéder aux premiers fichiers dont il a besoin (en particulier le noyau NTOSKRNL.EXE)
:
- dans le cas de disque IDE, il va utiliser l'INT13h du BIOS,
- dans le cas de disque SCSI, il va utiliser un driver lié à la carte SCSI, ce driver
s'appelant NTBOOTDD.SYS (copie p.ex. de AIC78XX.SYS, AHA154X.SYS,
...).
La syntaxe MULTI peut être utilisée dans plusieurs cas :
Environnement |
Utilisation de MULTI |
Disques IDE uniquement |
fonctionne avec les 4 disques IDE (2 contrôleurs) |
Disques SCSI uniquement |
fonctionne avec les 2 premiers disques SCSI |
Disques IDE et SCSI (mixte) |
fonctionne seulement avec les 2 premiers disques IDE (premier contrôleur) |
Paramètre
Signification
Commentaires
x
N° de contrôleur matériel SCSI dans l'ordre d'initialisation (BIOS), tel qu'il est identifié par le driver NTBOOTDD.SYS
Toujours égal à 0 dans le cas de contrôleurs MULTI
( NB: Certains disques SCSI peuvent être gérés avec la syntaxe MULTI - cf. ci-dessus)y
ID du disque SCSI (syntaxe SCSI)
Toujours égal à 0 dans le cas de syntaxe MULTI
z
N° de disque pour la syntaxe MULTI
LUN (Logical Unit Number) pour la syntaxe SCSI)Compris entre 0 et 3 pour les disques IDE
Toujours égal à 0 pour les disques SCSIw
N° de la partition
NB : la numérotation commence à 1
Les partitions primaires sont décomptées en premier, suivies des partitions logiques.
Les partitions inutilisées (type 0) ou étendues (type 05 ou 0F) ne sont pas décomptées.
Exemples :
- Disque SCSI d' ID=3, avec 4 partitions, NT étant sur la 2ème, dans le répertoire \wnt4:
scsi(0)disk(3)rdisk(0)partition(2)\WNT4="......"
- Disque IDE "master" sur le 2ème connecteur IDE, 3 partitions, NT étant sur la 1ère, dans le répertoire \winnt :
multi(0)disk(0)rdisk(2)partition(1)\WINNT="...."
Chemin
Le nom du répertoire, dans la partition considérée, dans lequel se trouve NT proprement
dit.
Libellé
Chaîne alphanumérique quelconque qui apparaîtra à l'écran dans
le menu de choix d'OS
Commutateurs
Facultatifs. Ils permettent de préciser le type d'exécution de NT.
Commutateur
Signification
/3GB
Ordinairement, la mémoire virtuelle est partagée en 2 portions de 2 Go entre user et system (2Go pour User, 2Go pour System). Ce paramètre, disponible à partir du SP3 de NT4.0, permet de modifier ce partage en 3Go pour User et 1Go pour System.
A utiliser seulement dans le cas de très grosses applications (Bases de données), prévues pour ce fonctionnement 3Go et avec NT Entreprise Server./BASEVIDEO
Utilisation du driver standard d'affichage VGA.
A utiliser dans le cas de changement de carte graphique/BAUDRATE=nnnn
Spécifie la vitesse de transmission pour le debugging
Par défaut, 9600 avec un modem et 19200 avec un null-modem
Force le commutateur /DEBUG, même s'il n'a pas été précisé/BURNMEMORY=n
Indique que "n" Mo de RAM sont inutilisables.
P.ex. /BURNMEMORY=128 indique à NT que 128 Mo de la mémoire physique de la machine sont inutilisables./CRASHDEBUG
Charge le debugger, qui reste toutefois inactif
tant qu'il n'y a pas d'erreur du noyau/DEBUG
Charge le debugger, qui peut être activé à tout moment
par une autre machine de debugging connectée à l'ordinateur.
A utiliser en cas de problèmes répétitifs/DEBUGPORT=comx
Spécifie le n° de port à utiliser pour le debugging.
Force le commutateur /DEBUG, même s'il n'a pas été précisé/HAL=<hal>
Permet de spécifier une DLL relative au HAL -(Hardware Abstract Layer)
Sert à remplacer le fichier <winnt>\system32\hal.dll par un autre.
P.ex.: /HAL=HALCHK.DLL/KERNEL=<kernel>
Permet de spécifier un KERNEL.
Sert à remplacer le fichier <winnt>\system32\NTOSKRNL.EXE par un autre.
P.ex. : /KERNEL=NTOSKCHK.EXE/MAXMEM=n
Spécifie le maximum de mémoire RAM que NT peut utiliser.
A utiliser quand on suspecte une barrette RAM d'être défectueuse/NODEBUG
Aucune information de debugging utilisée
/NOSERIALMICE=[COMx | COMx,y,z,...]
Désactive la détection de souris sur le(s) port(s) série spécifié(s),
ou sur tous les ports série si on ne précise aucun port./NUMPROC=n
Fixe le nombre de processeurs à utiliser.
P.ex., /NUMPROC=2 sur un système quadriprocesseur fera en sorte que NT n'utilisera que 2 processeurs sur les 4./ONECPU
Fonctionnement en monoprocesseur sur une machine multiprocesseurs
/PCILOCK
Empêche NT d'assigner dynamiquement les interruptions (IRQ) pour les ressources
PCI et laisse cette tâche au BIOS./SOS
Affiche les noms de drivers au cours de chargement.
A utiliser quand on pense qu'un driver est manquant ou défecteuxCommutateurs disponibles sous Windows 2000/XP
/BOOTLOG
Création d'un fichier journal
/FASTDETECT
Paramètre standard pour la détection des périphériques principaux.
Si la souris n'est pas détectée (p.ex.), supprimer ce paramètre./NOGUIBOOT
Désactivation de l'interface graphique au démarrage
/SAFEBOOT:<type>
Démarrage en mode sans échec
<type> peut prendre les valeurs suivantes
MINIMAL
démarrage minimal
MINIMAL(ALTERNATESHELL)
mode ligne de commande
NETWORK
avec réseau
DSREPAIR
réparation de l'Active Directory (Contrôleurs de domaine uniquement)
2ème structure
Elle concerne DOS, Windows 95/98
Racine DOS
DOS et Windows 9x ne sachant pas démarrer depuis une unité autre que le premier
disque dur ou la disquette, les seules valeurs possibles sont C:\ ou A:\
Fichier_secteur_de_boot
S'il n'y a pas d'ambiguïté, ce nom est facultatif. C'est le
nom d'un fichier de 512 octets, qui est une image du secteur de boot de DOS ou de Windows
9x. Ce nom est généralement BOOTSECT.DOS, mais ce n'est pas
obligatoire. Tout autre nom peut convenir. Si DOS (ou Windows 9x) est choisi par
l'utilisateur, NTLDR lit ce fichier et le substitue (en mémoire, temporairement) au
secteur de boot de NT, ce qui a pour conséquence de lancer le 1er fichier de
l'OS
correspondant (IO.SYS en principe)
Libellé
Chaîne alphanumérique quelconque qui apparaîtra à
l'écran dans le menu de choix d'OS
Commutateur
S'il n'y a pas d'ambiguïté, ce commutateur est facultatif. On l'indiquera si
l'on désire un triple boot, à savoir NT, Windows
9x
et DOS. Dans ce cas, la racine du disque C: contient 2 fichiers images de secteur
de boot :
- BOOTSECT.DOS relatif à DOS (6.22 p.ex.)
- BOOTSECT.W95 relatif à Windows 9x
Les noms cités ici sont arbitraires. Suivant l'OS choisi (DOS ou Windows 9x), NTLDR
chargera le fichier image de secteur de boot correspondant. Le commutateur est à indiquer
seulement si l'on souhaite que NT émule le processus de multiboot de Windows
9x
(actionnées en appuyant sur F8 lors du démarrage de 9x). Dans ce cas, les valeurs qu'il
peut prendre sont :
- /win95dos associé à la ligne de commande de DOS
- /win95 associé à la ligne de commande de Windows 9x
Exemple :
Soit la configuration suivante :
Le fichier boot.ini sera constitué comme suit : |
[boot loader] |
Tout d'abord, il faut préciser qu'il est impossible de créer une
disquette bootable qui serait capable de contenir et charger tout le système
d'exploitation de Windows NT, en raison de la taille même des fichiers exécutables et
librairies, ainsi que celle de la base de registres.
Par contre, il est possible de commencer le démarrage depuis une disquette,
essentiellement dans le cas où l'un des fichiers de départ de NT est défectueux
ou manquant, à savoir :
NTLDR (le "loader" de NT)
BOOT.INI (le fichier texte indiquant les systèmes d'exploitation disponibles)
NTDETECT.COM (détermine le type de matériel installé)
BOOTSECT.DOS (image du secteur de boot d'un autre OS, tel que DOS)
NTBOOTDD.SYS (initialisation à partir d'un disque SCSI)
Formater une disquette avec le gestionnaire de fichiers NT
ou depuis la ligne de commande.
Ne pas utiliser de disquette pré formatée DOS, car cette dernière a
un secteur de boot prévu pour lancer IO.SYS et non pas NTLDR
Si on est sous DOS ou
Windows 9x, il suffit de copier la 1ère disquette d'installation de
NT sur une autre à l'aide de la commande diskcopy, et de supprimer
tous les fichiers qu'elle contient
Copier les fichiers (situés dans la racine de la partition de boot)
NTLDR
NTDETECT.COM
BOOT.INI
NTBOOTDD.SYS (seulement dans le cas de disque SCSI, et si le BIOS de la carte
SCSI a été
désactivé)
BOOTSECT.DOS (si l'on désire pouvoir redémarrer sous DOS)
Exécuter (sous Windows 9x/ME/NT/2000/XP) le programme
bootnt.exe. (281 ko)
Insérer une disquette vierge
Si la disquette n'est pas vide, un message s'affiche:
La disquette est alors écrite :
Elle contient les fichiers suivants (Windows XP,
utilisables avec NT4 et Windows 2000) :
28/09/2001 14:00 45 124 ntdetect.com |
Cette disquette est une disquette bootable de type NT, ce qui
veut dire qu'elle lance NTLDR et donc est capable de lancer NT.
Mais comme elle est formatée en FAT12, elle est modifiable
facilement sous DOS ou Windows toute version :
On peut remplacer les fichiers NTLDR et NTDETECT.COM par d'autres si nécessaire (par exemple fichiers Windows XP)
Le fichier boot.ini a été conçu de façon a permettre un choix assez
vaste (4 partitions possibles sur 2 disques IDE).
Mais on peut éditer ce fichier si nécessaire.
Si on boote le PC avec cette disquette, on obtient l'écran suivant :
pour information, ce fichier image a été réalisé à l'aide de WINIMAGE V6.0 (http://www.winimage.com)
Le secteur de boot lance le programme NTLDR
NTLDR recherche les fichiers suivants :
- BOOT.INI
- NTDETECT.COM
- NTBOODD.SYS (seulement dans le cas de disque SCSI, et si le BIOS de la carte SCSI a
été désactivé)
- BOOTSECT.DOS (éventuellement)
Il bascule le processeur en mode 386
Il lance un gestionnaire de fichiers très simple, basé sur l'INT13h (disque IDE) ou en utilisant NTBOODD.SYS (disque SCSI)
Il lit BOOT.INI, affiche les options correspondantes à l'écran et attend le choix de l'utilisateur
Si NT n'a pas été choisi, il charge le fichier BOOTSECT.DOS (ou un autre si le nom d'un fichier image de secteur de boot a été explicitement indiqué) à la place du secteur de boot initial, puis lui passe le contrôle
Si NT a été choisi, il lance NTDETECT.COM, caractérisé par l'affichage à l'écran
du message suivant (ou similaire, suivant la version de NT)
"NTDETECT Vxxx
checking Harware..."
NTDETECT.COM inspecte :
- le n° d'identification du PC
- la carte vidéo
- le type de clavier
- les ports séries et parallèles
- les lecteurs de disquettes
- la souris (si elle existe)
Ensuite il crée la partie du registre concernant le matériel.
Ces données, non permanentes, peuvent se retrouver dans la section HKEY_LOCAL_MACHINE\Hardware
Cette section est donc reconstruite à chaque démarrage de l'ordinateur
Puis intervient le lancement du noyau :
- Chargement du "HAL" (Hardware Abstract Layer), qui permet au
système d'être indépendant du matériel, et de NTOSKRNL, qui va lire
les données situées dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services,
afin de déterminer les drivers et services à charger possédant un statut de démarrage
"amorcé" (cf. Panneau de
configuration/Périphériques).
Cette phase est caractérisée par l'affichage à l'écran de "OS Loader
Vxxx ........", chaque point correspondant à un pilote.
Initialisation du noyau
L'écran devient bleu et passe en mode 50 lignes, avec affichage d'un message comme "
Microsoft Windows NT Version 4...."
Le noyau inspecte a nouveau la clef HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services,
pour les pilotes possédant un statut de démarrage "système".
Cette phase est caractérisée par l'affichage à l'écran d'une suite de points, chaque
point correspondant à un pilote. Un nouveau "CurrentControlSet" est
construit, mais non sauvegardé.
Chargement des services
Le gestionnaire de services (SMSS.EXE) est lancé, charge le sous-système Win32, et les
services possédant un statut de démarrage "automatique".
Un nouveau "CurrentControlSet" est construit
Lancement du sous-système Windows
Une copie de "CurrentControlSet" est copiée dans "Dernière bonne
configuration connue"., WINLOGON.EXE est lancé, lequel inspecte la clef HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
et recherche la valeur de l'entrée System, qui contient les noms des
sous-systèmes( p.ex. ISASS.EXE, gestionnaire de sécurité locale)
A ce moment apparaît (enfin!) la boite de dialogue invitant à appuyer sur CTRL-ALT-SUPP pour démarrer une session
Il peut être intéressant de transformer une application (que l'on a développée soi-même p.ex.) en service, de façon qu'elle soit démarrée conjointement au démarrage de NT, sans devoir attendre l'ouverture d'une session (ce qui ne se produit pas toujours, dans le cas d'un serveur)
Il suffit de récupérer dans le kit de ressources techniques NT les 2 outils prévus pour cela et qui s'appellent :
INSTSRV.EXE (37 888 octets)
SRVANY.EXE (13 312 octets)
Dans la réalité, ces outils ne "transforment" pas réellement une
application en service.
Ce qui est fait est UNIQUEMENT le lancement du service srvany, auquel est
indiqué en paramètre le nom de l'application que l'on veut voir lancée comme
service.
Étant donné qu'il peut y avoir plusieurs applications dans ce cas, plusieurs
instances de srvany seront alors exécutées.
Pour les distinguer, on leur attribue des noms différents arbitraires
à l'aide de l'outil instsrv.
Cette transformation s'effectue en 2 phases :
Dans une fenêtre de commande, en se plaçant dans le répertoire qui
contient les 2 outils, exécuter instsrv.exe avec en paramètres le nom
du service (arbitraire) suivi de srvany.exe :
ATTENTION : si le répertoire contenant srvany.exe
ne figure pas explicitement dans la variable d'environnement PATH, il faut
le préciser dans cette commande (sinon un message d'erreur sera généré par instsrv.exe),
ce qui est assez logique d'ailleurs, puisqu'au moment du démarrage de NT,
le système doit savoir trouver "srvany.exe"
Dans le panneau de configuration, lancer "Services"
:
- Sélectionner le service qui vient d'être créé, (avec, à ce moment
là, un état indéfini, et un démarrage "automatique").
- Dans le champ "Paramètres de démarrage", taper le nom
de l'exécutable, en veillant à doubler les backslashes
- Appuyer sur le bouton "Démarrer".
L'état du service va passer en "Démarré" et l'application va alors
démarrer (ici "Scanbin").
Par contre, les paramètres
de démarrage n'étant pas sauvegardés, l'application ne sera pas
lancée au prochain redémarrage de NT.
Pour que ces paramètres soient mémorisés, il faut intervenir dans
la Base de Registres à l'aide de Regedit ou Regedt32
(après avoir exécuté instsrv.exe) . La clef concernée
s'appelle
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\xxxxx
dans laquelle xxxxx
est le nom du service que l'on a choisi.
Il faut créer une sous-clef nommée Parameters, dans laquelle
on va créer de 1 à 3 entrées de type chaîne :
Nom de l'entrée |
Présence |
Valeur |
Application |
Obligatoire |
Chemin complet de l'application à lancer en tant que service |
AppParameters |
Optionnelle |
Paramètres à passer à l'application |
AppDirectory |
Optionnelle |
Répertoire de travail de l'application |
Exemple (cas "d'école"!):
Le service JCB1 est lancé à chaque démarrage de NT, ce service lançant à son tour Scanbin.exe, lequel va analyser Notepad.exe.Si l'application finale "transformée" en service est dotée d'une interface graphique (généralement, un service est une tâche de fond, sans interface, ou à la rigueur avec une fenêtre console), il faut autoriser l'affichage de cette interface (si on le désire, bien sûr).
Pour cela, dans les propriétés du type de démarrage, il faut cocher la case "Autoriser le service à interagir avec le bureau", ou encore, dans la BDR, mettre à 1 le bit 8 de l'entrée de type DWORD et de nom "Type" (cela revient à effectuer un "OR" avec le nombre hexadécimal 0x100) .
par exemple : Type = 0x00000010 est à remplacer par 0x00000110
Pour supprimer ce service, il suffit d'exécuter instsrv.exe
avec en paramètre le nom du service suivi de "remove"
:
Il existe un autre produit, qui permet de faire la
même chose : "FireDaemon"
La dernière version, à la date de rédaction de ce document, est la
V1.6 GA
Ce produit était autrefois gratuit. Désormais, seule une version "Lite" l'est encore, mais elle ne permet de lancer qu'un seul service. La version commerciale (non limitée en nombre de services) coûte 25 $ à ce jour.
Son installation est très simple, et sa mise en oeuvre s'effectue en lançant, dans une console, l'exécutable FireDaemon.exe
(Les captures d'écran ici présentées ont été réalisée avec une précédente version : 0.09C)
9 questions sont posées successivement :
|
|
On peut constater la présence du nouveau
service dans le |
|
Démarrage (manuel) du service : |
|
L'application concernée démarre : |
|
Arrêt (manuel) du service : |
|
Désinstallation du service par la
commande |
Fonctionnalités |
Workstation |
Server |
Nombre de connexions clients |
10 |
Illimité |
Nombre de connexions à d'autres réseaux |
Illimité |
Illimité |
Nombre de connexions distantes (RAS) |
1 |
255 |
Nombre de processeurs supportés (SMP) |
2 |
4 |
Réplication de répertoires |
Importation uniquement |
Importation et Exportation |
Services Macintosh |
Non |
Oui |
Validation de Login |
Non |
Oui |
Tolérance aux pannes de disques |
Non |
Oui |
Type de réseau |
Poste-à-poste |
Serveur |
Il a été prouvé (par Mark Russinovitch en particulier) que NT WS
et NT Server sont
composés au départ du même code.
La distinction est effectuée par NTOSKRNL.EXE, à l'aide de l'API MmIsThisAnNtAsSystem
(index 485), qui vient puiser ses informations dans la base de registres. Ainsi sont
concernées :
NT 3.51 : 1 seule clef
NT 4 (et au delà) 2 clefs
Version |
Sous-clefs de |
Entrée |
Type |
Valeur |
||
NT 3.51 |
NT 4 |
WS |
S |
|||
|
|
CurrentControlSet\Control\ProductOptions |
ProductType |
REG_SZ |
Winnt |
Servernt |
|
|
Setup |
SystemPrefix |
REG_BINARY |
0 |
1 |
Cette 2ème clef a été ajoutée par Microsoft, afin d'interdire
à l'utilisateur de modifier la licence du produit.
En effet, on ne peut pas modifier plus d'une seule clef à la fois, (même si on est
TRÈS rapide!), or 2 "threads" contrôlent en PERMANENCE la conformité des 2 clefs.
S'il y a discordance entre ce bit et le contenu de
"ProductType" :
- lors du boot : cela génère un "BSOD" (Blue Screen Of
Death")
- en marche : cela affiche le message suivant :
"Le système a détecté une tentative de changer le contenu de la clef
ProductType. Ceci est une violation de votre contrat de licence. Changer le contenu de
ProductType n'est pas permis."
Pour information, Mark Russinovitch a réalisé un outil ("NTTune")
qui arrive à "court-circuiter" les 2 threads en question.
: il ne l'a pas fait
dans un but illicite, mais seulement pour démontrer que NT WS et NT Server sont la même
chose au niveau code, contrairement à ce que prétendait Microsoft à l'époque !
Il est totalement inutile de rechercher "NTTune", outil devenu mythique et dont l'usage serait illégal!
Vu les mises à jour et la taille grandissante de ce paragraphe, un document complet lui est désormais consacré
Dans le cas d'un PC isolé fonctionnant sous Windows NT, on peut trouver fastidieux de
devoir taper à chaque démarrage la séquence CTRL-ALT-SUPP, puis de
saisir son nom d'utilisateur et son mot de passe.
Il y a moyen de contourner cette phase en modifiant la clef:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
et en ajoutant ou modifiant les entrées suivantes :
Nom |
Valeur |
AutoAdminLogon |
1 |
DefaultUserName |
votre nom d'utilisateur |
DefaultPassword |
votre mot de passe |
Attention : le mot de passe apparaît en clair dans la BDR ! Il n'y a donc plus aucune sécurité à ce niveau!
Cette opération peut également être effectuée dans l'interface graphique de l'outil "Tweak UI" des Powertoys :
|
Si le compte concerné n'a pas
les droits suffisants pour modifier la BDR, il devient impossible
alors, une fois qu'il a ouvert une session, de restaurer la configuration
initiale (puisque la boite de dialogue de connexion ne s'affiche plus, donc il
n'est plus possible d'ouvrir une session en tant qu'administrateur).
On peut
contourner cette difficulté en maintenant la touche "MAJ"
appuyée pendant le démarrage (ou pendant un CTRL-ALT-DEL). Cela a pour
conséquence d'afficher la boite de dialogue de connexion, même si on
est en autologon!
Sous Windows NT/W2K/XP, la BDR est composée de données dynamiques (construites à chaque démarrage du système) et d'informations stockées dans des fichiers appelés "ruches" ("hives"), situées dans différents répertoires.
Ces fichiers ne sont pas accessibles par l'utilisateur lorsque NT
fonctionne
(même par un administrateur).
Il est impossible d'effectuer un "dump" hexadécimal ou une simple copie!
Les noms des ruches sont placés dans la clef :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist
Le contenu de HKLM (HKEY_LOCAL_MACHINE) est réparti dans : |
|
HKLM\SAM |
\winnt\system32\config\Sam |
HKLM\SECURITY |
\winnt\system32\config\Security |
HKLM\SOFTWARE |
\winnt\system32\config\Software |
HKLM\SYSTEM |
\winnt\system32\config\System |
Le contenu de HKCC (HKEY_CURRENT_CONFIG) est réparti dans : |
|
HKCC |
\winnt\system32\config\System
(déja cité) |
Le contenu de HKU (HKEY_USERS) est réparti dans : |
|
HKU\.DEFAULT |
\winnt\system32\config\default |
Le contenu de HKCU (HKEY_CURRENT_USER) est réparti dans : |
|
HKCU |
\winnt\profiles\<user>\ntuser.dat |
Plusieurs branches de la BDR ne sont que des alias d'arborescences,
et n'ont pas d'existence physique réelle.
C'est le cas de :
HKEY_CLASSES_ROOT : alias de HKEY_LOCAL_MACHINE\SOFTWARE\Classes
HKEY_CURRENT_USER : alias de HKEY_USERS\xxxxxxxxx (xxxxxxxxx étant l'identifiant de l'utilisateur en cours)
HKEY_CURRENT_CONFIG : alias de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
(et aussi de HKEY_CURRENT_CONFIG\Software\Microsoft\windows\CurrentVersion\Internet
Settings)
Les fichiers .log contiennent les changements
apportés à une ruche (lorsqu'une rubrique de la BDR est modifiée). S'il y a eu un
plantage et que les modifications n'ont pas eu le temps d'êtres inscrites dans la ruche
correspondante, un indicateur dans le fichier .log le
signale, et le système effectue au redémarrage une fusion entre la ruche
(non modifiée) et le fichier .log
Les fichiers .sav sont des copies des
ruches effectuées à la fin de la phase en mode texte de l'installation
de Windows.
Ils ne servent qu'à restaurer l'installation au cas où il y
aurait un problème lors du passage en mode graphique.
Ces fichiers sav ne doivent donc pas être utilisés pour restaurer les
ruches en fonctionnement normal!
Le fichier system.alt est une copie de
sauvegarde de la ruche critique "system",
qui est utilisée après un plantage (fichier system corrompu).
Pour restaurer la ruche system à partir de ce fichier de
sauvegarde, on peut le faire, au choix, :
soit depuis une autre installation de Windows,
soit depuis la console de récupération (Windows 2000 et au delà)
soit depuis DOS (disquette bootable p.ex.) si la partition système est de type FAT
Il est toutefois possible d'accéder à ces fichiers et d'en lire (et modifier) le contenu sous les conditions suivantes :
Avoir effectué une autre installation de Windows NT (ou 2000,...) sur la même machine, et travailler avec cette version.
Utiliser l'outil REGEDT32 (REGEDIT sous XP/.NET), et ouvrir l'un de fichiers ruches de la version inactive de NT (initiale)
Ouverture de la clef locale |
|
Ouverture d'une "ruche" |
|
Sélection de la ruche "SAM" Pour que cette importation |
|
Cette nouvelle ruche est "greffée"
|
|
Développement de cette |
|
A la fin des opérations, |
ATTENTION
: Cette opération est facile à mettre en oeuvre, mais
ses
conséquences ultérieures peuvent être catastrophiques.
Elle
permet en effet d'accéder, en lecture et en écriture, à n'importe quelle clef de la Base
de Registres, y compris les clefs réservées au système ou
à la Sécurité!
Elle nécessite néanmoins d'opérer sous un compte utilisateur ayant les droits administrateur.
Certaines clefs sont inaccessibles (totalement ou en écriture) même
par un administrateur. Par exemple :
- HKEY_LOCAL_MACHINE\SAM (gestion de la sécurité du poste)
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root (gestion des
périphériques)
Cela est dû au fait que seul le SYSTÈME en est le propriétaire avec la
totalité des droits, un administrateur n'étant, dans le meilleur des cas, que
propriétaire avec droit de lecture seule.
Si l'on a un besoin impérieux de les consulter et/ou modifier, on peut y arriver
en modifiant ces droits, grâce à l'outil REGEDT32.EXE (REGEDIT.EXE
ne gère pas la sécurité de la BDR sous Windows NT4/2000, par contre il a
fusionné avec REGEDT32 sous Windows XP/.NET).
La méthode à suivre est la suivante :
Lancer REGEDT32.EXE puis sélectionner la branche en question
(p.ex. HKLM\System\CurrentControlset\Enum\Root) et ouvrir le menu "Sécurité" / "Autorisations"
Dans la boite de dialogue qui s'affiche,
au départ doivent figurer :
- SYSTEM : Autorisations "Lecture" et "Contrôle total"
- Tout le monde : Autorisations "Lecture"
Appuyer sur le bouton "Ajouter"
Dans la boite de dialogue qui s'affiche, sélectionner (p.ex.) "Administrateurs" (et/ou un nom d'utilisateur)Appuyer sur OK
Dans la précédente boite de dialogue, "Administrateurs" apparaît alors.
Le sélectionner, puis cocher la case "Autoriser" en face de "Contrôle total"Appuyer sur OK, .....
Désormais, le groupe "Administrateurs" aura droit "de vie et de mort" sur la clef en question.
Il est donc parfaitement possible d'accéder même en écriture à N'IMPORTE QUELLE clef de la BDR.
Mais ce genre d'opération est la porte ouverte à des "Blue Screen Of Death" de toute beauté!
A utiliser avec prudence!
Il suffit de modifier l'entrée chaine InitialKeyboardIndicators de la clef :
HKEY_CURRENT_USER\Control Panel\Keyboard pour la session de l'utilisateur en cours
HKEY_USERS\.DEFAULT\Control Panel\Keyboard au démarrage de NT, avant que toute session soit lancée
valeur "0" = clavier déverrouillé
valeur "2" = clavier verrouillé
Ce qui suit ne concerne que Windows NT4, cette fonctionnalité ayant été intégrée dans Windows 2000 ainsi que dans Windows XP/2000
Par défaut, sous Windows NT, le fonctionnement de la touche
"CAPS LOCK" (Verrouillage des majuscules) est différent de celui observé sous
DOS ou Windows 3.1x, 95, 98. En effet, elle agit comme un bistable : une
action sur cette touche bascule le clavier en majuscules, et une deuxième action le remet
en mode normal. Sous DOS (à la façon des anciennes machines à
écrire), il faut appuyer sur l'une des touches "MAJ" pour repasser en mode
normal. Certains utilisateurs préfèrent ce dernier mode.
Pour le mettre en oeuvre sous Windows NT, il faut opérer ainsi :
Installation (si ce n'est déjà fait) du Service Pack 3 (ou 4 ou 5)
Si seul le SP3 a été installé, et non pas le SP4 ou SP5, installation d'un patch
post-SP3 nommé ADMNFIXI.exe (ou ADMNFIXA pour les plates-formes
Alpha). La version française peut être trouvée à l'adresse suivante :
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/frn/nt40/hotfixes-postSP3/getadmin-fix/
Une fois le patch appliqué :
3.1.Editer la clef HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard
Layouts\0000040C
Il y a 2 clefs de
noms très voisins à ne pas confondre : ...\Keyboard Layouts
et ...\Keyboard Layout !
3.2.Ajouter une nouvelle valeur de type DWORD, de nom Attributes
et de valeur 00 01 00 00.
3.3.Redémarrer l'ordinateur
Editer la clef de la BDR :
HKEY_USERS\.DEFAULT\Control Panel\Desktop
Puis modifier la valeur chaine de nom "Wallpaper" en donnant le
nom complet du fichier bitmap à afficher.
Par défaut, cette valeur contient la chaine "(par défaut)",
qui a pour conséquence de charger l'un des fichiers suivants :
Sous NT WorkStation |
c:\winnt\winnt.bmp si moins de 256 couleurs |
Sous NT Server |
c:\winnt\lanmannt.bmp si moins de 256 couleurs |
On peut évidemment modifier ces fichiers, mais c'est moins "propre" que de modifier l'entrée dans la registry !
Par ailleurs, on peut ajouter un message d'accueil, en modifiant la
clef :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Introduire les valeurs chaines suivantes :
"LegalNoticeCaption" |
p.ex. "Bienvenue sous NT WorkStation !" |
"LegalNoticeText" |
p.ex. "Vous qui pénétrez ici, perdez toute espérance !" |
Après avoir actionné CTRL-ALT-DEL, une boite de dialogue va s'ouvrir avec :
Titre : le contenu de "LegalNoticeCaption"
Message : le contenu de "LegalNoticeText"
Quand on insère un CDROM dans un lecteur, le logiciel contenu dans ce CD peut être exécuté automatiquement ou non. Pour déterminer le comportement de Windows vis à vis de cette insertion, il faut agir dans la Base de registres (directement, ou à l'aide de "Tweak UI" des Powertoys, dont une version en français est disponible à l'adresse http://formatland.free.fr/tweakui.htm)
Il y a 2 moyens d'activer/désactiver cette fonction :
Soit GLOBALEMENT (pour TOUS les disques)
Modification de la clef :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CDRom
L'entrée "AutoRun" (type REG_DWORD) indique l'activation :
0x00000000
désactivée
0x00000001
activée
Soit PONCTUELLEMENT (pour un ou plusieurs disques donnés, qui
peuvent être autres que des lecteurs de CD)
Modification de la clef :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On peut de plus choisir la (dés)activation :
soit par lettre de disque
L'entrée "NoDriveAutoRun" (type REG_DWORD) indique quels sont les
lettres de disques à désactiver.
Le 1er bit (de poids faible) correspond au disque A:, le 2ème à B:, et ainsi de suite.
(vu que cette valeur a 32 bits, et qu'il y a 26 lettres au maximum, ça
tient !)
Par exemple, si le CD a la lettre X :
|
|
|
|
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0 | 0 | 8 | 0 | 0 | 0 | 0 | 0 |
0x00000001 | type inconnu |
0x00000004 |
disque amovible |
0x00000008 |
disque fixe |
0x00000010 |
disque réseau |
0x00000020 |
CDROM |
0x00000040 |
RAMDISK |
0x00000080 | type inconnu |
0x000000FF | tous les types |
Donc pour désactiver uniquement l'autorun des CD, il faut affecter la
valeur 0x00000020
Par défaut, cette valeur est égale à 0x00000095, qui correspond à
la combinaison de :
0x81 : types inconnus
0x04 : disques amovibles (disquettes)
0x10 : disques réseau
il faut fermer puis redémarrer l'explorateur pour que les modifications soient prises en compte.
En ce qui concerne les CD, je recommande d'utiliser Tweak UI
(ici version en français) :
le mot "complétion" est un néologisme, dérivé de son homologue anglais "completion". Si on devait le traduire strictement, il faudrait utiliser le mot "achèvement", qui n'est pas très parlant dans le présent contexte.
Ce terme désigne la fonctionnalité très pratique, bien connue dans les
environnements UNIX, qui consiste, dans une fenêtre de commandes, à taper
au clavier, à tout moment au cours de la frappe, le début du nom d'un
fichier ou répertoire, puis d'appuyer sur une touche de contrôle
(généralement la touche <TAB>).
Le système complète alors automatiquement la frappe par un nom de
fichier ou de répertoire existant dans le répertoire courant.
S'il existe plusieurs fichiers ou répertoires dont le nom commence par la même séquence de caractères, on peut afficher le suivant (dans l'ordre alphabétique) en appuyant à nouveau sur la touche de contrôle, et ainsi de suite.
Exemples :
Exécution directe d'une application dont on ne se souvient que des 2 premières lettres "ip"
1 (après la frappe on appuie sur <TAB>) |
2 (après la frappe on appuie sur <TAB>) |
3 (après la frappe on appuie sur <TAB>) |
4 Nom trouvé. |
Atteinte d'un répertoire de nom assez complexe, à partir de la
racine d'une partition :
On veut aller dans "H:\Program Files\Microsoft eMbedded Tools\Common"
1 (après la frappe on appuie sur <TAB>) |
2 (après affichage on appuie sur <Entrée>) |
3 (après la frappe on appuie sur <TAB>) |
4 (après la frappe on appuie sur <Entrée>) |
5 (vu sa simplicité, on tape à présent la commande complète) |
6 On est dans le répertoire voulu |
Pour une raison inconnue, cette fonctionnalité très utile n'est pas active
par défaut sous Windows NT et Windows 2000 (elle l'est par
contre sous Windows XP)
Son activation (ou désactivation) est réalisée de façon permanente par la modification d'une entrée de la Base de Registres :
HKEY_CURRENT_USER\Software\Microsoft\Command Processor
ou :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
Entrée CompletionChar de type REG_DWORD et de valeur :
0x0000000
fonction désactivée
0x00000xx
(xx <>00)fonction activée, "xx" désignant le code ASCII de le touche de contrôle
p.ex. 0x00000009 -> touche <TAB>
la clef HKEY_CURRENT_USER\... l'emporte sur HKEY_LOCAL_MACHINE\... en cas de différences entre les deux.
On peut créer un fichier completion.reg dont le contenu sera le suivant :
REGEDIT4
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"CompletionChar"=dword:00000009
Cette modification est effective immédiatement (sans redémarrage de l'ordinateur)
Si pour une raison quelconque on veut activer ou désactiver temporairement cette fonctionnalité (= le temps d'une session du processeur de commandes cmd.exe), il suffit de taper l'une de ces commandes :
cmd /f:on
active la complétion
Le caractère de contrôle est alors la séquence de touches :
<CTRL>F ou <CTRL>Dcmd /f:off
désactive la complétion
Lorsqu'une station de travail ouvre une session sur un serveur de domaine NT/W2k, généralement se déroule un script de connexion (situé dans le répertoire partagé NETLOGON du serveur), qui sert à définir certains partages de ressources (disques et imprimantes : commandes "NET USE ..."), exécution de programmes,..., et qui se déroule sur la machine cliente.
Il est souvent souhaitable de pouvoir particulariser cette procédure
en fonction du nom d'utilisateur qui se connecte, ou encore du serveur,
du domaine, ...
Or si cela est très facile à réaliser quand la station cliente est
de type "NT" (NT4 WorkStation, Windows 2000 Professionnel, XP
Professionnel) par utilisation des variables d'environnement %username%, %userdomain%,
..., lesquelles sont toujours présentes et automatiquement initialisées, par
contre, dans des environnements Windows 95,98,ME, cela n'est pas
possible de façon standard.
Par exemple la variable %username% n'existe pas de façon standard
sous ces systèmes d'exploitation.
Il est possible de remédier à cette déficience à l'aide de
l'utilitaire PUTINENV qui sait initialiser une variable d'environnement
depuis un script de connexion.
Ce logiciel (du domaine public) est du à MJ Winkler, et date de 1993
(du temps de LAN Manager, précurseur des serveurs Windows NT)!
Ainsi, la commande putinenv.exe L exécutée sur la machine cliente au
cours du script de connexion va initialiser les variables d'environnement
suivantes :
Nom de la variable Contenu %ROOT% Répertoire de login %COMPUTERNAME% Nom de la machine cliente %USERNAME% Nom d'utilisateur %LANGROUP% Nom de domaine par défaut %LOGONSERVER% Nom du serveur %MAJOR% Poids fort du n° de version %MINOR% Poids faible du n° de version
De plus, afin de rendre ces variables permanentes sur la machine cliente
(en dehors du script de connexion), on peut utiliser l'utilitaire WINSET,
fourni avec le CD de Windows 9x (p.ex. dans le répertoire \TOOLS\RESKIT\SCRPTING
du CD de Windows 98).
Exemple de script :
On aura au préalable copié le fichier putinenv.exe dans le partage Netlogon du serveur
@echo off
...
if "%OS%"=="Windows_NT" goto suite
REM Dans la ligne suivante remplacer "serveur" par le nom NetBIOS du serveur
if not exist %windir%\putinenv.exe copy \\serveur\NetLogon\putinenv.exe %windir%\*.*
%windir%\putinenv.exe L
REM Ce qui suit est facultatif
REM Cela permet de rendre permanentes les variables en dehors du script
%LogonServer%\NetLogon\Winset USERNAME=%USERNAME%
%LogonServer%\NetLogon\Winset COMPUTERNAME=%COMPUTERNAME%
%LogonServer%\NetLogon\Winset LOGONSERVER=%LOGONSERVER%
REM
:suite
...
Téléchargements :
Putinenv.exe (43 ko) Winset.exe (22 ko)
Il peut être souhaitable, par exemple dans un script de connexion (pour compléter l'article précédent), de tester l'appartenance d'un utilisateur à un groupe donné.
J'ai écrit "ismember.vbs", un script VBS qui opère ce test, affichant (ou non, avec le commutateur /s) le résultat, et positionne la variable d'environnement %ERRORLEVEL% , laquelle peut être récupérée dans un fichier de commandes (.bat ou .cmd)
Syntaxe :
ismember /c<compte> [/g<groupe>] [/m<machine>] [/s]
ismember -c<compte> [-g<groupe>] [-m<machine>] [-s]Description des paramètres:
<compte> le compte utilisateur à tester <groupe> le groupe éventuel
S'il est absent, il y a affichage de la liste des groupes auxquels
appartient le compte<machine> le nom NetBIOS de l'ordinateur concerné
S'il est absent, l'ordinateur local est retenu/s Si ce commutateur est présent, mode silencieux
(absence de messages)
Code de retour :
Ce code est stocké dans la variable %ERRORLEVEL%
Valeur Signification 0 le compte appartient au groupe indiqué 1 le compte n'appartient pas au groupe indiqué 2 le compte n'existe pas 3 le groupe n'existe pas
Exemples d'utilisation directe :
H:\WSH>ismember /cBELLAMY /gadministrateurs
Le compte "BELLAMY" de SPRINGFIELD appartient à "Administrateurs"
H:\WSH>ismember /cHOMER /gadministrateurs
Le compte "HOMER" de SPRINGFIELD n'appartient pas à administrateurs
H:\WSH>ismember /cSYSTEM /mcli20jc
Le compte "SYSTEM" de CLI20JC appartient à : "Debugger Users" "Utilisateurs du débogueur" H:\WSH>ismember /cMAGGY
Le compte "MAGGY" de SPRINGFIELD n'existe pas
H:\WSH>ismember /cHOMER /gtest
Le groupe "test" de SPRINGFIELD n'existe pas
Exemple d'utilisation dans un fichier batch (testuser.bat) :
@echo off
REM Exemple d'utilisation du script "ismember.vbs"
REM On lui passe en paramètres :
REM le nom d'utilisateur
REM le groupe
if %1.==. goto fin
if %2.==. goto fin
ismember /c%1 /g%2 /s
goto Label_%ERRORLEVEL%
:Label_0
echo %1 appartient a %2
goto fin
:Label_1
echo %1 n'appartient pas a %2
goto fin
:Label_2
echo %1 n'existe pas
goto fin
:Label_3
echo %2 n'existe pas
:finUtilisation de ce batch :
H:\WSH>testuser HOMER utilisateurs
HOMER appartient a utilisateurs
H:\WSH>testuser HOMER administrateurs
HOMER n'appartient pas a administrateurs
H:\WSH>testuser %username% administrateurs
BELLAMY appartient a administrateurs
Le script VBS et le fichier batch exemple sont disponibles ici
Les captures d'écran qui suivent ont été réalisées sous Windows XP, mais l'intégralité de l'article s'applique également à Windows NT4 et Windows 2000
NTFS (New Technology File System) est un système de fichiers apparu avec Windows NT, doté de très nombreux avantages par rapport au système FAT (voir étude comparative)
L'une des fonctionnalités les plus utiles dans un usage courant est la mise en place de contrôle d'accès aux dossiers et fichiers, protégeant ainsi leurs ouverture et/ou modification, en les limitant à un utilisateur ou groupe d'utilisateurs donné.
Toute tentative d'accès par un utilisateur non autorisé se soldera alors par un refus.
La seule condition pour bénéficier de cette fonction est que la
partition sur laquelle réside(nt) le(s) fichier(s) ou dossier(s) soit de
type NTFS.
Si ce n'est pas encore le cas (type FAT16 ou FAT32), il suffit de la
convertir en NTFS à l'aide de la commande CONVERT
Il suffit de sélectionner dans l'explorateur un (ou plusieurs) dossier
ou fichier, clic droit, menu contextuel "propriétés", puis afficher l'onglet "Sécurité".
Sous Windows XP, cet
onglet peut ne pas s'afficher. Consulter le
chapitre consacré à cette
fonctionnalité.
Exemple :
On décide de protéger l'accès au dossier e:\EmailsJCB , ainsi défini :
- contrôle total au compte BELLAMY
- accès en lecture seule au groupe des administrateurs
- aucun accès aux autres comptes
Une fois cela défini, si un compte non autorisé (ici "HOMER") essaye d'accéder à ce dossier,
un message d'erreur va s'afficher :
Après réinstallation de Windows (NT, 2000, XP,...), certains dossiers ou fichiers voient leur accès refusé même si l'utilisateur fait partie du groupe des administrateurs. Cela se manifeste aussi en cas de transfert d'un disque dur d'une machine vers une autre.
Ce problème ne survient que sur des partitions de type NTFS
Bien que surprenant au premier abord, ce dysfonctionnement
est en réalité parfaitement normal.
En effet, à chaque fichier ou dossier sont affectés des "permissions"
(accès en lecture, écriture, exécution,...). Ces permissions sont définies pour
des comptes donnés ("administrateur" a un contrôle total, "xxx" a des droits de
lecture,..).
Mais dans ces associations "compte/permissions", ce ne sont pas les
noms habituels (affichés) qui sont stockés, ("Administrateur", "Bellamy", "Homer",
...), mais les SID (Security IDentifiers), à savoir un n° UNIQUE
au monde pour chaque compte, créé lors de la création du compte, lequel SID est
dérivé du SID du système (créé lui-même lors de l'installation de Windows)
Un SID à l'allure suivante : S-1-5-21-164.......-......
On peut les voir à l'aide de REGEDIT dans les branches :
HKEY_LOCAL_MACHINE\SECURITY\Policy\Accounts HKEY_USERS
Le lien entre le nom de connexion (nom externe) et le SID est défini de la façon suivante :
Dans la branche HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names on trouve autant de sous-clefs qu'il y a de comptes, le nom de chaque sous-clef étant le nom de connexion.
Par exemple
HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names\BELLAMY
Cette clef ne contient qu'une valeur par défaut de longueur nulle, mais
caractérisée par un type très particulier (autre que les types habituels REG_SZ,
REG_DWORD, ...), représenté par sa valeur hexadécimale.
Dans cet exemple, elle est égale à 0x3EF (soit 1007 en décimal, nombre que l'on retrouve à la fin du SID)
On se reporte alors dans la clef
HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\00000xxx
"xxx" étant la valeur hexadécimale du type de l'entrée
précédente (dans l'exemple : 3EF)
L'entrée de type binaire et de nom V contient les informations sur le compte, et en particulier le SID :
On retrouve le SID du compte BELLAMY :
offset valeur
hexadécimalevaleur
décimale0x118 0x6204F4A1 1644491937 0x11C 0x22CDB7B4 583907252 0x120 0x28A68B82 682003330 0x124 0x000003EF 1007 offset valeur
UNICODEchaîne 0x174 42004500
4C004C0041004D00
5900BELLAMY
...1644491937-583907252-682003330-1007
Quand on réinstalle Windows (ou transporte un disque),
même si on crée un compte ayant le MÊME nom que précédemment, le SID associé
sera DIFFÉRENT! (l'algorithme qui le crée utilise des nombres aléatoires, la
date et l'heure, ...)
Par exemple le SID de "Administrateur" (Version 2 de
Windows) sera différent de celui
"Administrateur" (Version 1 de Windows)
Donc si le fichier est accessible uniquement à "Administrateur" (V1), il
sera refusé à "Administrateur" (V2), son SID n'étant plus le même.
Il faut changer le "propriétaire" du fichier ou dossier. |
C'est une notion différente de celle des permissions.
Le propriétaire est la personne (le compte) qui a le droit de modifier les
permissions.
ce n'est pas
forcément l'administrateur.
MAIS tout administrateur (indépendamment de son SID, du moment qu'il est
recensé comme appartenant au groupe des administrateurs, et qu'il a un mot de
passe
valide) a la possibilité de changer le propriétaire d'un fichier ou dossier!
Pour pouvoir accéder aux fichiers, le mode opératoire sera le suivant :
il peut survenir au cours de l'opération
un message d'erreur, du au fait que
très souvent les permissions sont "héritées" des permissions attribuées à
l'objet parent du fichier ou dossier (= dossier parent).
Il suffit alors de
décocher la case "Permettre aux autorisations pouvant
être héritées du parent d'être propagées à cet objet".
Cela va provoquer une réinitialisation des permissions pour le fichier ou dossier considéré.
(Dans le cas d'un dossier, suivant sa taille, cela peut prendre un certain
temps).
Les informations relatives aux services sont stockées dans la Base de Registres, à savoir l'arborescence :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Chaque service est associé à une sous-clef, par exemple HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp
(le client DHCP)
On trouve un certain nombre d'entrées (variable suivant le service concerné) :
Entrée Type Rôle Exemples et commentaires DependOnGroup REG_MULTI_SZ Liste des groupes de services dont dépend le service concerné SCSI Miniport DependOnService REG_MULTI_SZ Liste des services dont dépend le service concerné TCPIP Afd NetBT
RpcSs PlugPlay DmServerDescription REG_SZ Description du service Gère la configuration réseau en inscrivant et en mettant à jour les adresses IP et les noms DNS. DisplayName REG_SZ Nom abrégé du service Client DHCP ErrorControl REG_DWORD Définit la conduite à tenir en cas d'erreur 0x01 Valeur Rôle 0x00 L'erreur n'est pas prise en compte 0x01 Affiche un message d'avertissement 0x02 Si le démarrage fait appel à la dernière configuration valide, il se poursuit. Sinon il est demandé de sélectionner la dernière configuration valide 0x03 Enregistre l'échec, lance un diagnostic et redémarre l'ordinateur Group REG_SZ Nom du groupe auquel appartient le service TDI
SCSI Class
System Bus ExtenderImagePath REG_SZ Chemin de l'exécutable associé %SystemRoot%\System32\services.exe ObjectName REG_SZ Compte sous lequel le service est exécuté LocalSystem
.\NetShowServicesParameters REG_SZ Paramètres éventuels privés cf. Comment transformer une application en service Start REG_DWORD Défini le mode de démarrage du service 0x02 Valeur Rôle Commentaires 0x00 Boot Chargé par le loader (NTLDR) 0x01 System Chargé lors de l'initialisation du noyau 0x02 Auto (valeur la plus courante)
Chargé et démarré automatiquement lors du démarrage du système0x03 Manuel Démarré par l'utilisateur ou par un autre processus 0x04 Désactivé Jamais démarré.
Une exception : les drivers de système de fichiers sont
chargés même avec start=4Tag REG_DWORD Spécifie l'ordre dans lequel les services d'un même groupe sont lancés, par ordre croissant de la valeur de tag . Services du groupe "System Bus Extender"
Service Tag Pcmicia 0x01 fdc 0x02 PCIIde 0x03 IntelIde 0x04 PartMgr 0x05 mf 0x06 Mountmgr 0x08 ftdisk 0x09 diskperf 0x0a dmload 0x0c dmio 0x0d lbrtfdc 0x0e Type REG_DWORD Type du service 0x20 Valeur Rôle 0x01 Pilote de périphérique en mode noyau 0x02 Pilote de périphérique en mode noyau mettant en oeuvre des services du système de fichiers 0x04 Arguments utilisés par une carte réseau 0x10 Service Win32 à lancer comme un processus autonome 0x20 Service Win32 autorisé à partager l'espace d'adressage avec d'autres services du même type
L'ordre de démarrage des services est stocké dans la clef :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder
Entrée Type Exemple List REG_MULTI_SZ System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
port
Primary disk
SCSI class
SCSI CDROM class
filter
boot file system
...
Video
Video Save
file system
Event log
...
NetBIOSGroup
PlugPlay
...
Il est très facile de convertir une partition FAT (ou FAT32
sur Windows 2000, XP et 2003) en NTFS à l'aide de la commande CONVERT.
Cette conversion est motivée par la supériorité de NTFS sur FAT
en matière de sécurité, fonctionnalité et fiabilité (voir l'article
comparatif FAT vs NTFS)
La conversion conserve l'intégralité des données (fichiers et dossiers), et peut être effectuée à tout moment.
La seule condition requise est l'existence d'un espace libre minimal au
départ sur la partition FAT à convertir.
Voici la méthode pour déterminer cet espace libre (tirée de l'article
314875) :
Exemple :
s 8376205312 octets (Partition de 7.8 Go) d 4504 dossiers f 43781 fichiers slib 428270592 octets (408 Mo) s1 83762053 -> 4194304 retenu s2 14625443 smin 76626339 octets ( 73 Mo) smin < slib -> conversion possible
Le processus de conversion est très sécurisé.
Il comporte les étapes suivantes :
Donc si un incident survient n'importe quand, ce processus minimise les
risques de corruption du disque.
La conversion est déclenchée par la commande suivante :
convert volume /FS:NTFS [/V]
avec :
volume Obligatoire
Peut-être, au choix : Exemples lettre de la partition (suivie de deux-points) D: point de montage \\?\Volume{d522145c-2d6b-11d7-bd08-806d6172696f}\ le nom de volume (label de la partition) APPLIS /FS:NTFS commutateur obligatoire
Spécifie que le volume doit être converti en NTFS./V commutateur facultatif
Spécifie que CONVERT doit être exécuté en mode bavard.
(la liste de tous les fichiers et dossiers convertis apparaît)
Exemple d'exécution (les actions de l'utilisateur figurent en gras):
C:\Documents and Settings\BELLAMY>convert e: /FS:NTFS
Le type du système de fichiers est FAT32.
Entrez le nom de volume en cours pour le lecteur E: DOCUMENTSOn veut convertir en NTFS la partition E:, au départ en FAT32. Il y a confirmation de la demande en entrant le nom de volume (ici "DOCUMENTS") Convert n'a pas pu s'exécuter car le volume est utilisé par un autre
processus. Convert pourra s'exécuter après que ce volume soit démonté.
TOUS LES DESCRIPTEURS OUVERTS SUR CE VOLUME NE SERONT PLUS VALIDES.
Voulez-vous forcer le démontage de ce volume ? (O/N) oLa partition étant utilisée par ailleurs( p.ex. ouverte dans explorer), le système a besoin de démonter le volume temporairement. Cela supprime toutes les ouvertures en cours éventuelles de fichiers ou dossiers. Répondre par "o" (oui) Le volume est démonté. Tous les descripteurs ouverts dans ce volume ne sont plus
valides.
Volume DOCUMENTS a créé 09/05/2002 20:30
Le numéro de série du volume est B503-ACC1
Windows vérifie les fichiers et les dossiers...
Vérification des fichiers et des dossiers terminée.
Windows a vérifié le système de fichiers sans trouver de problème.
5 145 816 Ko d'espace disque au total.
1 328 Ko dans 11 fichiers cachés.
788 Ko dans 151 dossiers.
1 101 684 Ko dans 4 375 fichiers.
4 042 012 Ko sont disponibles.
4 096 octets dans chaque unité d'allocation.
1 286 454 unités d'allocation au total sur le disque.
1 010 503 unités d'allocation disponibles sur le disque.
Détermination de l'espace disque requis pour la conversion du système
de fichiers...
Espace disque total : 5155888 Ko
Espace libre sur le volume : 4042012 Ko
Espace requis pour la conversion : 40117 Ko
Conversion du système de fichiers
La conversion est terminéeLa conversion commence. Elle est généralement très rapide.
Ainsi, avec cette partition de 5 Go, cela a pris moins de 3 minutes (sur un portable équipé de Pentium III 1133 MHz)Dans le cas de la partition système, il n'est pas possible de la démonter.
La demande est alors mémorisée, et la conversion a lieu alors lors du prochain redémarrage.
C:\Documents and Settings\BELLAMY>convert D: /FS:NTFS
Le type du système de fichiers est FAT32.
Entrez le nom de volume en cours pour le lecteur D: APPLIS
Convert n'a pas pu s'exécuter car le volume est utilisé par un autre
processus. Convert pourra s'exécuter après que ce volume soit démonté.
TOUS LES DESCRIPTEURS OUVERTS SUR CE VOLUME NE SERONT PLUS VALIDES.
Voulez-vous forcer le démontage de ce volume ? (O/N) o
Le volume est démonté. Tous les descripteurs ouverts dans ce volume ne sont plus
valides.
CONVERT ne peut pas obtenir l'accès exclusif au lecteur D:
et il ne peut donc pas le convertir maintenant. Voudriez-vous
le programmer pour qu'il soit converti lors du prochain
redémarrage du système (O/N) ? o
La conversion prendra effet automatiquement lors du prochain
redémarrage du système.Ici, la conversion est différée car la partition que l'on veut convertir est en cours d'utilisation, et le démontage n'est pas possible. Elle aura lieu lors du redémarrage de l'ordinateur.
On peut être amené à devoir reformater la partition de boot et/ou système :
Cette opération est IMPOSSIBLE sous Windows, que ce soit avec la commande format ou à l'aide du gestionnaire de disques (WINDISK sous NT4 ou DISKMGMT.MSC sous 2000/XP/2003), pour la simple raison que Windows ne peut évidemment pas s'autodétruire :
Utilisation de FORMAT : C:\WINDOWS\system32>format c:
Le type du système de fichiers est NTFS.
Entrez le nom de volume en cours pour le lecteur C: XPPRO
Attention : toutes les données sur le lecteur de disque
non amovible C: seront perdues !
Continuer le formatage (O/N) ? o
Vérification de 2047 Mo
Format ne peut pas s'exécuter car le volume est utilisé par un autre
processus. Format pourra s'exécuter après que ce volume ait été démonté.
TOUS LES DESCRIPTEURS OUVERTS SUR CE VOLUME NE SERONT PLUS VALIDES.
Voulez-vous forcer le démontage de ce volume ? (O/N) o
Verrouillage du lecteur impossible. Le volume est encore utilisé.Utilisation de DISKMGMT.MSC : On constate que l'item Formater... est grisé, si bien qu'il est impossible de formater cette partition
Si on tient malgré tout à reformater cette partition, voici le mode opératoire, qui dépend de ce que l'on veut faire réellement :
Dans ce cas, il suffit tout simplement de démarrer l'ordinateur sur le CDROM de Windows, et de suivre les étapes suivantes :
Appuyer sur ENTRÉE | |
Appuyer sur ECHAP | |
Sélectionner la partition concernée et appuyer sur ENTRÉE | |
Appuyer sur C | |
Sélectionner le type de formatage (en principe celui qui est proposé par défaut) et appuyer sur ENTRÉE |
2 cas se présentent :
format c: |
(par exemple) |
2. La partition NTFS est une partition LOGIQUE
On
ne peut pas la supprimer à l'aide de FDISK ! |
On pourra ensuite recréer une partition à l'aide de FDISK,
puis la formater à l'aide de FORMAT.
La branche HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet de la Base de Registres contient comme son nom le suggère l'ensemble des paramètres système en cours (essentiellement les paramétrages des pilotes de périphériques et des services).
On trouve également en parallèle une ou plusieurs branches nommées :
HKEY_LOCAL_MACHINE\SYSTEM\ControlSetxxx
"xxx" étant un nombre de 3 chiffres supérieur ou égal à 1.
la
numérotation ne démarre pas forcément à 001 (mais peut commencer à 002 par
exemple)
Ces branches sont soit un alias, soit des copies multiples de la
configuration du système (donc de la branche HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet).
Juste après un démarrage correct de Windows, et avant toute
modification éventuelle des paramètres système de la BDR, une copie de
sauvegarde du jeu en cours est effectuée (et cette copie est "bonne", puisqu'on
a pu démarrer
correctement).
durant la
phase d'initialisation du noyau, cette copie s'appelle temporairement "Clone"
(dixit le MSDN, mais je n'ai jamais pu le voir!)
Il faut retenir qu'UN SEUL JEU est ACTIF à un instant
donné.
Ce jeu actif est appelé CurrentControlSet, et c'est un alias (et non
pas une copie) d'un ControlSetxxx
Je dis bien "alias", et non pas "copie" !
Par exemple, CurrentControlSet et ControlSet002 vont désigner
(actuellement) la même branche.
Pour le vérifier, il suffit de créer dans CurrentControlSet une entrée
quelconque.
Immédiatement, elle apparaît dans ControlSet002, et inversement.
De même si on la supprime dans l'une de ces 2 branches, elle disparaît de
l'autre.
Ce procédé d'alias se retrouve d'ailleurs avec d'autres branches de la
BDR :
Branche Alias de HKEY_CURRENT_USER HKEY_USERS\<id user en cours> HKEY_CLASSES_ROOT HKEY_LOCAL_MACHINE\SOFTWARE\Classes
Pour connaître le jeu actif, celui de sauvegarde, ..., on dispose de la clef HKEY_LOCAL_MACHINE\SYSTEM\Select, qui contient 4 entrées dont les valeurs respectives (de type REG_DWORD) sont les n° des différents jeux ControlSetxxx :
Entrée Signification Remarques Current Identifie le ControlSet en cours, c'est à dire le n° du CurrentControlSet actuellement utilisé par Windows Current et Default contiennent typiquement le même n° au démarrage.
(et ultérieurement si on n'a pas choisi un autre jeu)Default Identifie le n° du ControlSet qui sera utilisé par défaut lors du prochain redémarrage de Windows, sauf si on choisit (après avoir appuyé sur F8) :
Dernière bonne configuration connueFailed Identifie le ControlSet qui était pointé par défaut avant que l'utilisateur démarre l'ordinateur en choisissant :
Dernière bonne configuration connueContient la valeur 0 si il n'y a jamais eu un tel choix. LastKnownGood Identifie le ControlSet considéré comme "bonne" copie du dernier ControlSet utilisé. Après un démarrage réalisé avec succès, le ControlSet en cours est copié dans celui-là.
Exemple :
La BDR contient les 4 branches suivantes :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003
Par ailleurs, la clef HKEY_LOCAL_MACHINE\SYSTEM\Select contient les entrées suivantes :
Entrée Valeur Commentaires Current 0x00000002 Actuellement le système fonctionne avec ControlSet002
Donc cela signifie que CurrentControlSet n'est
rien d'autre qu'un alias de ControlSet002Default 0x00000002 Par défaut, si on redémarre Windows, c'est ControlSet002
qui sera chargé comme CurrentControlSetFailed 0x00000001 ControlSet001 fut un controlset utilisé avant un plantage du système
et/ou choix de la part de l'utilisateur d'une dernière bonne configuration connue
Son contenu est donc peut-être défectueux
(mais ce n'est pas systématique)LastKnownGood 0x00000003 ControlSet003 est la dernière bonne configuration connue.
C'est une copie (et non pas un alias) de CurrentControlSet
(en l'occurrence de ControlSet002), laquelle a été effectuée lors du tout dernier démarrage de Windows (réalisé avec succès), et avant toute modification éventuelle de la BDR effectuée après ce démarrage.Ainsi, si un "crash" survient par exemple à la suite d'une installation défectueuse d'un périphérique et/ou de modifications erronées de la BDR, lors du prochain redémarrage, on pourra choisir cette dernière bonne configuration connue, à savoir ControlSet003, lequel n'aura pas été modifié par les opérations précédentes à la différence de ControlSet002.
Après avoir effectué ce choix, l'entrée Failed contiendra alors 0x00000002 (ControlSet002 aurait du être normalement le controlset choisi, mais non retenu car défectueux)