Ce qui suit concerne Windows NT4, mais aussi, sauf précision contraire, Windows 2000, Windows XP, Windows 2003 et Windows VISTA.
Pour tout ce qui est spécifique à Windows VISTA, prière de consulter le chapitre Windows VISTA
Pour tout ce qui est spécifique à Windows XP et 2003, prière de consulter le chapitre Windows XP /2003
Pour tout ce qui est spécifique à Windows 2000, prière de consulter le chapitre Windows 2000

• Les tailles limites de partitions
• Cas des disques durs IDE ayant une taille supérieure à 8 Go
• Structure et paramètres du fichier "boot.ini"
• Création d'une disquette de boot partiel
• Les séquences du démarrage
• Comment transformer une application en service ?
• avec le NT Resource KIT
• avec FireDaemon
• Différences entre NT Server et NT WorkStation
• Schéma d'architecture générale de NT
• En cas de perte du mot de passe administrateur!
• Verrouillage du pavé numérique au démarrage
• Fonctionnement de la touche CAPS LOCK
• Configuration du clavier avant ouverture de session
• Comment modifier le logo de connexion
• Lancement automatique d'une session au démarrage (autologon) 
• Les fichiers contenant la base de registres 
• Accès à une clef verrouillée
• (Dés)activation de la notification d'insertion d'un CDROM
• Complétion automatique des noms de fichiers et dossiers dans une fenêtre de commandes

• 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

• Services et Base de Registres

• Conversion de partition FAT en NTFS

• Reformatage de la partition de démarrage (boot) ou système

• A propos des branches HKLM\SYSTEM\ControlSetxxx et HKLM\SYSTEM\CurrentControlSet

• Disparition des barres de menu et d'onglets dans le gestionnaire de tâches

• Définition de plages horaires d'ouverture de session sur un ordinateur autonome

• Différences entre Groupe de travail et Domaine

• Nombre maximal de connexions entrantes suivant la version de Windows

• Différences entre partages et permissions

Les tailles limites de partitions

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 :

• disponible sur le serveur FTP de Microsoft

• disponible ici

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 :

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

Cas des disques durs IDE ayant une taille supérieure à 8 Go

(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 :

1. Démarrer l'ordinateur à l'aide des 3 disquettes de NT

2. 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.

3. 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.

4. La disquette est alors lue, "Microsoft ATAPI Service Pack 4 IDE driver" est affiché, appuyer sur Entrée pour valider ce choix.

5. 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.

6. 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. 

Structure et paramètres du fichier "boot.ini" (Windows NT)

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. <Nom ARC><Chemin>=<Libellé><Commutateurs>

2. <Racine DOS>[<Fichier_secteur_de_boot>]=<Libellé>[<Commutateurs>]

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 SCSI
w	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éfecteux
Commutateurs 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 :

Création d'une disquette de boot partiel sous Windows NT

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)

Pour créer une telle disquette, opérer ainsi :

1. 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 

2. 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)

On peut aussi générer cette disquette à partir d'un fichier image auto extractible disponible ici
bootnt.exe

1. Exécuter (sous Windows 9x/ME/NT/2000/XP/2003) le programme bootnt.exe. (309 ko)
   

2. Insérer une disquette vierge
   Si la disquette n'est pas vide, un message s'affiche:
   

3. La disquette est alors écrite :
   

4. Elle contient les fichiers suivants (Windows 2003, utilisables avec NT4 , Windows 2000 et Windows XP) :  

   28/03/2003 13:00  45 548 ntdetect.com 28/03/2003 13:00 279 344 ntldr 28/03/2003 13:00   4 952 Bootfont.bin 15/07/2002 23:11     745 boot.ini

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 :

• Les fichiers NTLDR et NTDETECT.COM présents sur cette disquette sont ceux de Windows 2003 afin d'avoir la compatibilité ascendante la plus large possible avec tous les systèmes de la famille NT existant actuellement.
  Si de nouvelles versions de NT apparaissent, il suffit de remplacer ces deux fichiers par ceux de la nouvelle version, afin d'éviter des problèmes de démarrage. 

• 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)

Les séquences du démarrage de Windows NT

1. Le secteur de boot lance le programme NTLDR

2. 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)

3. Il bascule le processeur en mode 386

4. Il lance un gestionnaire de fichiers très simple, basé sur l'INT13h (disque IDE) ou en utilisant NTBOODD.SYS (disque SCSI)

5. Il lit BOOT.INI, affiche les options correspondantes à l'écran et attend le choix de l'utilisateur

6. 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

7. 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..."

8. 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)

9. 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

10. 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.

11. 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é.

12. 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

13. 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)

14. A ce moment apparaît (enfin!) la boite de dialogue invitant à appuyer sur CTRL-ALT-SUPP pour démarrer une session

Comment transformer une application en service

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)

1^ère méthode (NT Resource Kit)

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)

Le NT Resource Kit est un produit Microsoft payant, vendu séparément de Windows. Toutefois,  certains outils sont disponibles gratuitement sur le site de Microsoft. C'est le cas justement des deux exécutables cités ici (instsrv.exe et srvany.exe), que l'on trouve dans le fichier auto extractible rktools.exe (12049 ko). ATTENTION : cet ensemble ne peut être installé que sous Windows XP et Windows 2003. Mais cette restriction est due uniquement à la version du fichier .MSI inclus. Les fichiers contenus dedans peuvent très bien (pour la plupart) fonctionner sous Windows 2000 ou même Windows NT4. C'est le cas de instsrv.exe et srvany.exe. On peut donc commencer par installer rktools.exe sous Windows XP ou Windows W2003, puis recopier les fichiers obtenus  instsrv.exe et srvany.exe sur un ordinateur fonctionnant sous Windows 2000 ou Windows NT4. Afin d'éviter des manipulations fastidieuses, voici un fichier compressé contenant ces deux exécutables : instsrvany.zip (22 ko) extraits de rktools.exe

1. 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"
   

2. 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 

3. Pour supprimer ce service, il suffit d'exécuter instsrv.exe avec en paramètre le nom du service suivi de "remove" :
   

2^ème méthode (FireDaemon)

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)

Différences entre NT Server et NT WorkStation

A propos des différences de code entre NT WorkStation et NT 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

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!

Schéma d'architecture générale de NT

En cas de perte du mot de passe administrateur!

Vu les mises à jour et la taille grandissante de ce paragraphe, un document complet lui est désormais consacré

Lancement automatique d'une session au démarrage de Windows NT (autologon)

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 :

avec cette méthode manuelle, le mot de passe apparaît en clair dans la Base de Registres! Il n'y a donc plus aucune sécurité à ce niveau! A partir de Windows 2000, on lui préférera une autre méthode exposée plus bas.

Cette opération peut également être effectuée dans l'interface graphique de l'outil "Tweak UI" des Powertoys : onglet "Réseau" cocher la case "Ouverture de session automatique au démarrage" remplir les champs Nom d'utilisateur et Mot de passe
Une autre méthode consiste à utiliser la commande suivante :     Sous Windows 2000 control userpasswords   Sous Windows XP et au delà control userpasswords2 en ce qui concerne la commande control userpasswords, elle est devenue un simple raccourci vers l'applet "Comptes utilisateurs"
Cela provoque l'affichage d'une boite de dialogue (captures d'écran effectuées sous Windows XP)   Décocher la case : "Les utilisateurs doivent entrer un nom d'utilisateur et un mot de passe pour utiliser cet ordinateur"                 Puis appuyer sur le bouton Appliquer (ou OK)
Une boite de dialogue contenant un formulaire s'ouvre alors.     Remplir les 3 champs et appuyer sur OK
Avec cette méthode, l'entrée "DefaultPassword" n'apparait pas dans la base de registres, car le mot de passe est CRYPTÉ à l'aide de la fonction "LsaStorePrivateData" (de l'API "wincrypt") et stocké dans une zone protégée de la Base de Registres ("LsaSecrets"). Ce mot de passe est alors récupéré (lors de la procédure d'ouverture de session) par la fonction "LsaRetrievePrivateData".

Si le compte concerné n'a pas les droits suffisants pour modifier  la Base De Registres, 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!

Les fichiers contenant la base de registres de Windows NT

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

• 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 :

1. Avoir effectué une autre installation de Windows NT (ou 2000,...) sur la même machine, et travailler avec cette version.

2. Utiliser l'outil REGEDT32 (REGEDIT sous XP/.NET), et ouvrir l'un de fichiers ruches de la version inactive de NT (initiale)

Accès à une clef verrouillée (sous Windows NT/2000/XP)

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!

Verrouillage du pavé numérique au démarrage de Windows NT

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é

Fonctionnement de la touche CAPS LOCK sous Windows NT

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 :

1. Installation (si ce n'est déjà fait) du Service Pack 3 (ou 4 ou 5)

2. 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/

3. 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

Configuration du clavier avant ouverture de session

Il peut arriver que le code du clavier avant ouverture de session ne corresponde pas au type de clavier utilisé.
(par exemple "QWERTY" alors qu'on dispose d'un clavier "AZERTY")

Cela est alors très gênant lorsque l'on veut ouvrir une session, à la fois pour saisir le nom d'utilisateur et surtout le mot de passe dans la boite de dialogue de connexion.

Ce code clavier avant ouverture de session est défini dans la Base de Registres :

Clef	HKEY_USERS\.DEFAULT\Keyboard Layout\Preload\
Entrée	1
Type	REG_SZ  les valeurs ci-dessous sont des chaînes, et non pas des valeurs hexadécimales
Valeur	Code Clavier 0000040c Français (France) 00000409 USA 00000807 Allemand (Suisse) 0000080c Français (Belgique) 00000c0c Français traditionnel (Canada) 00001009 Français (Canada) 0000100c Français (Suisse) ...
la liste des codes est visible dans :	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout\DosKeybCodes

Comment modifier le logo de connexion de Windows NT

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 :

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 :

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"

(Dés)activation de la notification d'insertion d'un CDROM

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  Tweak UI v1.33 (jusqu'à Windows 2000) et Tweak UI v2.10.0.0  (à partir de Windows XP)

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 0 0	Z Y 0 0 0 0	X W V U 1 0 0 0	T S R Q 0 0 0 0	P O N M 0 0 0 0	L K J I 0 0 0 0	H G F E 0 0 0 0	D C B A 0 0 0 0
  0	0	8	0	0	0	0	0

  Donc pour désactiver uniquement l'autorun du disque X:, il faut affecter la valeur 0x00800000
  
  Généralement, cette entrée n'existe pas. Il faudra donc la créer si besoin est.
   

• soit par type de disque
  L'entrée "NoDriveTypeAutoRun" (type REG_DWORD) indique quels sont les types de disques à désactiver:

  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) :

Complétion automatique des noms de fichiers et dossiers dans une fenêtre de commandes

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 :

1. 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é.

    

2. 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>D
cmd /f:off	désactive la complétion

Variables d'environnement sous Windows 9x dans un script de connexion

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)

Test de l'appartenance d'un compte utilisateur à un groupe donné

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 :fin

Utilisation 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

Utilisation de NTFS pour protéger facilement  l'accès à un fichier ou un dossier

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 :

 

Impossibilité d'accéder à certains dossiers ou fichiers après réinstallation de Windows

Le problème

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

Explication

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