[Windows CLI – Tip of the Week] Vider la Corbeille (CleanUp) depuis l’Invite de commande Windows (CMD.exe)

 

J’ai récemment réalisé un audit de plusieurs infrastructures Windows Server « Core ».

J’ai constaté que la Corbeille ($RecycleBin) de plusieurs dizaines de serveurs Windows Server Core (de 2008 à 2016) occupait + de 5 GB d’espace disque.

Il s’agit ici de Disque physique : matériel non supporté > pas d’extension de volume possible !

Pour vider la corbeille et libérer cet espace disque, il fallait exécuter la commande suivante :

Note importante : La commande suivante doit être exécutée depuis une CMD.exe lancée en tant qu’Admin, si vous établissez une connexion Remote Shell Windows (WinRS), vérifiez que le compte utilisé est bien local Admin sur les machines distantes.

rmdir /s %systemdrive%\$Recycle.bin

Confirmez la suppression en cliquant sur Y(es) et voilà le tour est joué :).

J’espère que cette p’tite commande pourra vous être utile ^_^.

A bientôt

#HK

 

[Windows Server 2008(R2) /2012 (R2) /2016] Performance Tuning Guidelines

Hello Windows Guys,

Aujourd’hui, je vais vous parler d’un sujet souvent oublié et pourtant primordial pour la réussite de tout projet de déploiement Windows Server : Performance Tuning 

Microsoft fournie plusieurs Guidelines /White papers (Web /Docx /Pdf) décrivant les instructions à suivre pour bien tuner son infrastructure Windows Server, 2008, 2008 R2, 2012, 2012 R2 ou encore 2016.

Ces ressources étant réparties sur plusieurs sites /plateformes, j’ai donc décidé de vous regrouper dans le tableau ci-dessous tous les liens et documentations dont vous aurez besoin pour réaliser votre phase « Performance Tuning » avec succès.

OS	Documents & Liens
Windows 2016	Performance Tuning Guidelines pour Windows Server 2016 https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/
Windows 2012 R2	Performance Tuning Guidelines pour Windows Server 2012 R2 https://www.microsoft.com/en-us/download/details.aspx?id=51960https://msdn.microsoft.com/en-us/library/windows/hardware/dn529133
Windows 2012	Performance Tuning Guidelines pour Windows Server 2012 http://download.microsoft.com/download/0/0/B/00BE76AF-D340-4759-8ECD-C80BC53B6231/performance-tuning-guidelines-windows-server-2012.docx
Windows 2008 R2	Performance Tuning Guidelines pour Windows Server 2008 R2 http://download.microsoft.com/download/6/B/2/6B2EBD3A-302E-4553-AC00-9885BBF31E21/Perf-tun-srv-R2.docx
Windows 2008	Performance Tuning Guidelines pour Windows Server 2008 http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Perf-tun-srv.docx

 

Comme discuté précédemment, la phase « Tuning Performance » est vraiment importante dans tout projet de déploiement (Windows Server ou autre d’ailleurs) car cela vous permettra d’utiliser vos ressources de la manière la plus efficiente et surtout vous aidera à atteindre un niveau de disponibilité de service (SLA /Service Level Availability) élevé.

Un conseil from #HK

Prenez le temps de lire ces documents, certains pages vous redirigent vers d’autres liens/pages, prenez donc le temps de bien lire et comprendre et d’associer les éléments de Tuning en fonction de chaque rôle /composant de la plateforme Windows Server.

Si vous avez des questions, n’hésitez pas à me laisser un commentaire.

A bientôt

#HK

[Windows – Tip of the Week] HowTo : Déplacez votre fichier Pagefile.sys vers un nouvel emplacement via WMIC.exe

 

Les questions suivantes m’ont récemment été posées par l’équipe « Ingés Systèmes MS » chez un de mes clients ?

Est-il possible de déplacer le fichier pagefile.sys vers un nouvel emplacement (nouveau Disk) via l’interface CLI Windows (via un outil en ligne de commande Windows) ?

Y’a-t-il un risque /impact post-déplacement de ce fichier ?

 

Mes réponses étaient :

Oui, le fichier Pagefile.sys peut être déplacé vers un nouvel emplacement (au niveau de la même partition/disque ou vers un nouveau disque).

Non, aucun risque/impact, si bien évidemment l’opération de déplacement se fait correctement :).

 

Suis-je obliger de déplacer mon fichier pagefile.sys ? Quels « Cases » ?

Avant d’envisager un déplacement du fichier pagefile.sys, commencez d’abord par vérifier que c’est bien ce fichier qui occupe le plus d’espace disque sur votre serveur.

Notez que par défaut, le fichier pagefile.sys est placé dans la partition système C:\ > C:\pagefile.sys

Dans l’exemple suivant, nous exécutions l’outil TreeSize pour connaître les dossiers et fichiers occupant le plus d’espace sur le disque C: de mon DC (il s’agit ici d’un DC physique).

Comme illustré dans la console TreeSize ci-dessous, le fichier pagefile.sys de mon D(omain) C(ontroller) occupe lui seul 25GB de la partition système (C:).

 

Dans le cas de mon client, toutes les partitions C: (de 70GB) n’avaient quasiment plus d’espace disque libre, voir l’exemple suivant avec 9MB d’espace libre :S

Dans ce cas de figure, avec un pagefile.sys à 25GB (~40% de la taille globale de C:), il FAUT obligatoirement le déplacer pour libérer de l’espace disque dans l’immédiat car avec une telle configuration votre DC finira par crasher, rapidement !

 

Requirements

Vous devez bien évidemment avoir un autre disque connecté sur votre serveur « Physique » ou ajoutez un nouveau vDisk à votre serveur Virtuel. Notez que ce dernier doit avoir suffisamment d’espace disque libre pour accueillir votre nouveau fichier pagefile.sys

Important : la configuration d’un nouvel emplacement du fichier pagefile.sys nécessite le Reboot de votre serveur pour que cette modification soit prise en compte.

Déplacer le fichier pagefile.sys vers une nouveau Disque

Exécutez les commandes suivantes pour :

Créer un nouveau fichier Pagefile.sys et le placer dans disque dédié (Lettre D:)

wmic pagefileset create name=D:\pagefile.sys

Définir sa taille (Maximale) à 8192 MB (8GB)

wmic pagefileset where name=D:\pagefile.sys set InitialSize=2048,MaximumSize=8192

Supprimer l’ancien fichier Pagefile.sys (placé dans C:\ dans notre cas)

wmic pagefileset where name=C:\pagefile.sys delete

 

Vérifier que le nouveau fichier pagefile.sys a bien été créé et déplacé

Pour visualiser l’emplacement du nouveau fichier Pagefile.sys, saisissez la commande wmic pagefileset list ou wmic pagefileset list /format:list pour avoir un output au format « Liste ».

A bientôt pour de nouvelles Tips & Tricks Windows, stay connected :).

#HK | Just Another IT Guy

[Windows Tips & Tricks] HowTo : Exporter/Importer toutes vos Tâches planifiées

 

Le planificateur de tâches Windows vous permet de créer et gérer des tâches planifiées afin d’automatiser les tâches fastidieuses d’administration Windows (periodic check, lancement de scripts pour déploiement, configuration, …Etc)

Certaines applications crééent de manière automatique des tâches planifiées pour un « Automatic Update » ou simplement réaliser certaines opérations liées à l’application de manière périodique.

Le planificateur de tâches Windows correspond à l’outil/snap-in MMC Taskschd.msc

Pour le lancer, saisissez simplement Taskchd.msc depuis le Menu Exécuter ou Menu Démarré

Dans l’exemple suivant, mon planificateur de tâches contient des tâches « auto-générées » par une Application présente sur mon OS Server (Optimize Start ****), mais aussi deux autres créées « manuellement » : reboot & Update check

Si vous souhaitez migrer votre plateforme Windows Server (2008 R2 ou ultérieur) vers un nouveau matériel (New Hardware) ou nouvelle VM, le planificateur de tâches vous offre la possibilité de migrer (exporter) vos tâches planifiées une par une, si vous en avez 100 ou 200 tâches planifiées … vous devriez donc les exporter à la main, une par un … 😦

HowTo : migrer toutes vos tâches planifiées en une seule opération 🙂

La migration des tâches planifiées d’un serveur à un autre est assez simple.

Il faut savoir que « par défaut », toute tâche planifiée créée est automatiquement placée dans le dossier suivant :

C:\Windows\System32\Tasks

Si je reprends l’exemple précédent, mes tâches planifiées « Optimize Start… » ainsi que « Reboot & Update check » sont donc bien présentes dans C:\Windows\System32\Tasks, voir Screenshot ci-dessous :

Pour les migrer vers un nouveau serveur (Physique ou Virtuel), il suffit de copier le dossier C:\Windows\System32\Tasks et copier son contenu et le coller dans le même dossier du nouveau Serveur.
Et voilà le tour est joué :).

[IIS – Security & Hardening] HowTo #N° 1 : Définir le Default Path d’AppCmd.exe

 

Introduction à l’outil CLI « APPCMD.exe »

AppCmd.exe est un Outil en ligne de commande (CLI) fourni avec le rôle Windows Server « IIS ».

C’est un outil d’administration très puissant qui vous permet (entre autres) de :

Créer, configurer et gérer des Sites IIS

Créer, configurer et gérer des Applis et Pools d’Applications IIS

Créer, configurer et gérer des Virtual Directories (Répertoire virtuels IIS)

Démarrer, arrête et recycler les Pools d’application

Afficher/Visualiser des informations sur les Worker Process

…Etc

Pour finir, AppCmd.exe vous permet non seulement de réaliser toutes les tâches d’administration classiques que vous pouvez effectuer depuis l’outil graphique IIS Manager (InetMgr.exe) mais aussi d’industrialiser /d’automatiser à l’aide de scripts Bat(ch) toute tâche d’administration /configuration fastidieuse et répétitive.

 

Définir le chemin par défaut d’AppCmd.exe

Les Best Practices IIS consistent à définir (forcer) le chemin by default de l’outil AppCmd.exe au niveau de la %var% d’environnement %PATH%, cette opération vous faciltera l’utilisation de l’outil car vous pourrez l’appeler depuis n’importe quel CMD Folder et vous n’aurez donc plus à faire du CD (Change Directory) à chaque fois que vous souhaitez appeler /lancer AppCmd.exe

Pour ce faire, la commande ci-dessous est à exécuter sur tous les serveurs IIS Server faisant parti de votre infrastructure système MS (Windows Server 2008 et ultérieur).

SETX PATH « %PATH%;%WINDIR%\System32\inetsrv » /M

Saisissez ensuite la commande suivante pour vérifier que la valeur de la variable %PATH% a bien été Updatée :

Echo %PATH%

Vous pouvez également vérifier le contenu de la variable %PATH% depuis les propriétés systèmes du serveur IIS > Variables d’environnement

Et voilà le tour est joué :).

Stay Connected, plusieurs HowTo IIS sont en cours de préparation.

N’hésitez pas à vous abonner à mon Blog pour rester informé de toute nouvelle publication ^^

See you soon.

#HK

[Internet Information Services Tip] HowTo : Rediriger le HTTP vers HTTPS

 

S’applique à : IIS Windows Server {2008 /2008 R2 /2012 /2012 R2 /2016}

J’ai récemment réalisé un audit de sécurité sur une infrastructure système Microsoft comprenant plusieurs serveurs Web IIS exécutant Windows Server 2008 R2, 2012 R2 et 2016, après réalisation de quelques tests fonctionnels et analyse des output files, j’ai détecté une faille de sécurité sur une Application Web (d’un éditeur tiers) permettant de récupérer les credentials (login/password) sur certaines pages.

Après étude de la vulnérable, il a été constaté que malgré la configuration du certificat SSL (WebApp accessible en HTTPS Only), certaines pages étaient toujours accessibles en HTTP.

Pour remédier à ce problème de sécurité, la solution suivante a été proposée au client :

Forcer la redirection du trafic HTTP vers le HTTPS sur toutes les pages du WebSite IIS.

Comment ça marche ?

La réponse est le Wonderful module /extension IIS : URL Rewrite.

URL Rewrite Module, qu’est ce que c’est ?

Je vous invite à consulter la vidéo ci-après pour en savoir plus :

En quelque mots : URL Rewrite est un module IIS qui vous permet de créer de Powerful Rules pour optimiser l’expérience utilisateur IIS.

En effet, à l’aide cette extension, vous avez la possibilité d’implémenter des règles pour utiliser des URLs simples et faciles à retenir.

Cela comprend la redirection d’URL /pages mais aussi le type de trafic (e.g : HTTP vers HTTPS).

La dernière version disponible au moment de l’écriture du présent post est la 2.1

Celle-ci prend désormais en charge IIS Windows Server 2016, elle est disponible en téléchargement gratuit ici.

Téléchargez et installez l’extension URL Rewrite sur tous vos serveurs IIS hébergeant la ou les WebApp(s) pour la(les)quelle(s) la redirection vers le HTTPS sera configurée.

Installer URL Rewrite 2.1

Une fois téléchargé, double-cliquez sur le fichier (.exe) pour lancer l’installation du module Rewrite URL.

L’assistant d’installation suivant apparaît :

Cliquez sur « Install » pour démarrer l’installation :

L’installation démarre …

Une fois déployé, l’assistant retourne le message suivant :

 

HowTo : Rediriger le HTTP vers le HTTPS sur une WebApp IIS

Commencez par lancer le Gestionnaire IIS (IIS Manager) en exécutant l’outil InetMgr.exe depuis le Menu « Exécuter » ou « Démarrer »

Sélectionnez le Site Web IIS pour lequel vous voulez rediriger le traffic HTTP vers HTTPS.

Dans l’exemple suivant, la WebApp « XXXXX » sera sélectionnée. Depuis le volet droit, localisez et double-cliquez sur « URL Rewrite »

Depuis le menu « Actions », cliquez sur « Add Rule(s)… »

L’assistant de création de règles suivant apparaît, sélectionnez « Blank rule » et cliquez sur « Ok »

Remplissez les champs ci-dessous de la manière suivante :

Name : HTTP to HTTPS

Pattern : (.*)

Sous « Conditions« , cliquez sur « Add… » pour ajouter une nouvelle condition

Créer /ajouter la condition suivante :

Condition input : {HTTPS}

Check if input string : Matches the Pattern

Pattern : ^OFF$

Sous « Action« , configurer l’action de la manière suivante :

Action type : Redirect

Redirect URL : https://{HTTP_HOST}/{R:1}

Redirect type : See Other (303)

Enfin, cliquez sur « Apply » pour appliquer votre règle URL Rewrite

Une fois créée, la règle URL Rewrite apparaît dans la liste :

 

Faites un test en saisissant simplement http://suivi_de_URL_de_Votre_WebApp et constatez la redirection vers https://suivi_de_URL_de_Votre_WebApp

La console « Services.msc » est vide !

 

Ping everyone,

Petit retour d’expérience !

J’ai été sollicité par l’équipe d’Ingés RUN aujourd’hui chez le client chez lequel je suis en mission pour un problème sur la vue « Etendu » du snap-in « Services.msc », qui apparemment est vide !!

Ce problème a été constaté sur des postes de travail « physiques » Windows XP SP3 /Windows 7 mais aussi sur des serveurs « Virtuels » Windows Server 2003 /2008 ou encore 2008 R2.

Sous un Windows XP, le contenu de la vue « Etendu » ressemble à ça:

Il peut être lié à plusieurs choses mais généralement il parvient suite à un crash d’IE (récupération d’un mauvais correctif, mauvais upgrade d’IE …) mais aussi parce que certaines bibliothèque de liens dynamiques (DLL) soient endommagées.

La problème a été résolu en ré enregistrant certaines DLL, voir procédure ci-après :

Pour Windows XP /Windows Server 2003 (quelque soit le Service Pack)

Lancez l’invite de commande (cmd.exe) et saisissez les commandes suivantes (l’une après l’autre):

 regsvr32 jscript.dll 

 regsvr32.exe  mmcndmgr.dll

 regsvr32.exe vbscript.dll

Après l’exécution de chaque commande, un message s’affiche vous indiquant que la DDL spécifiée est bien enregistrée.

Par exemple, après l’exécution de la commande regsvr32 jscript.dll, le message suivant est affiché :

Si toutefois le problème persiste, c’est que d’autres DDL à part jscript, mmcndmgr et vbscript soient endommagées, dans ce cas là, je vous invite à télécharger et appliquer le Fix suivant que (heureusement :D) MS nous propose encore :

http://www.microsoft.com/fr-FR/download/details.aspx?id=44664

Note : ce Fix est appliquable uniquement à Windows XP & Windows Server 2003. N’oubliez pas de le télécharger dans la langue de votre OS sinon l’installation échouera.

Pour Windows 7 /2008 ou 2008 R2

Lancez l’invite de commande (cmd.exe) en tant qu’Administrateur et saisissez les commande suivantes (l’une après l’autre)

 regsvr32 jscript.dll 

 regsvr32.exe  mmcndmgr.dll

 regsvr32.exe vbscript.dll

Après l’exécution de chaque commande, un message s’affiche vous indiquant que la DDL spécifiée est bien enregistrée.

Par exemple, après l’exécution de la commande regsvr32 jscript.dll, le message suivant est affiché :

Si toutefois le problème persiste, c’est que d’autres DDL à part jscript, mmcndmgr et vbscript soient endommagées, dans ce cas là, je vous invite à télécharger et appliquer le Fix suivant :

http://www.microsoft.com/fr-FR/download/details.aspx?id=44621

Note : ce Fix est appliquable uniquement à Windows 7 SP1 & Windows Server 2008 R2. N’oubliez pas de le télécharger dans la langue de votre OS sinon l’installation échouera.

Enfin, notez que cette procédure (réenregistrement de DDL) a fonctionné dans 95% des cas, le problème a été résolu sur « uniquement » un des postes de travail posant problème (sous Windows 7 Pro) en désinstallant et réinstallant IE 9.

Migration des utilisateurs et groupes locaux depuis Windows Server 2003 vers Windows Server 2008 R2

 

Note : cette procédure s’applique aussi à des serveurs faisant parti d’un domaine Active Directory

Dans un « Groupe de travail », aucune gestion centralisée des comptes utilisateurs et des groupes n’est possible.

En effet, ces derniers sont créés et stockés localement sur chaque serveur et gérés depuis l’outil « Utilisateurs et groupes locaux » : lusrmgr.msc

Dans un groupe de travail et dans le cas d’une migration d’un ou plusieurs serveurs exécutant Windows Server 2003 vers Windows Server 2008 R2, la migration des comptes utilisateurs et groupes locaux est un élément à prendre en compte afin que les utilisateurs locaux puissent continuer à avoir accès au(x) serveur(s) après l’upgrade en Windows Server 2008 R2.

Je vous présente à travers cet article la procédure de migration des utilisateurs et groupes locaux depuis Windows Server 2003 vers Windows Server 2008 R2 en utilisant la fonctionnalité Windows « Outils de migration de Windows Server » fournit avec Windows Server 2008 R2.

Important : Framework .Net v2.0 & PowerShell v1.0 (ou toutes versions ultérieurs) sont des pré requis pour cette migration, à vérifier ou à installer éventuellement sur le serveur source exécutant Windows Server 2003. De plus, notez que Windows Server 2003 doit avoir au moins le SP1 pour supporter Windows PowerShell v1.0. Donc commencez par installer le SP1 de Windows Server 2003 si ce n’est pas déjà fait.

Nous allons effectuer cette migration depuis un serveur source nommé « SRV2003 » exécutant Windows Server 2003 SP1 vers un serveur de destination nommé « SRV2008R2 » exécutant Windows Server 2008 R2.

Les deux serveurs sont dans un Groupe de travail.

Sur mon serveur source « SRV2003« , j’ai les comptes utilisateurs et groupes locaux suivants :

Le serveur de destination « SRV2008R2 » est fraîchement installé, aucun compte utilisateur ni groupe local n’est présent pour l’instant :

Etapes de migration

1. Depuis le serveur de destination « SRV2008R2 », ouvrez l’Invite de commande en tant qu’Administrateur et saisissez la commande suivante pour installer la fonctionnalité « Outils de migration de Windows Server »:

Servermanagercmd -i Migration

Note : vous pouvez aussi utiliser le Gestionnaire de serveur pour ajouter /installer cette fonctionnalité Windows 

Dès que l’installation est terminée, cliquez sur Démarrer, ensuite Outils d’Administration et vérifiez que le dossier Outils de migration de Windows Server est ajouté :

1. Maintenant, nous allons utiliser l’outil SmigDeploy.exe (outil fournit avec la fonctionnalité qu’on vienne d’installer) pour créer /générer un dossier de déploiement pour le serveur source, ce dossier contiendra les outils nécessaires qui vont nous permettre d’effectuer la migration des comptes utilisateurs et groupes locaux vers le serveur de destination.

Pour ce faire, commencez par créer et partager un dossier depuis le serveur source :

-> Ouvrez l’invite de commande depuis SRV2003 et saisissez les commandes suivantes pour créer et partager le dossier de déploiement « Migration » :

Mkdir C:\Migration

Net Share Migration=C:\Migration

-> Saisissez ensuite (depuis la même invite de commande) : Start /w C: 

Pour accéder à la partition C: hébergeant le dossier de déploiement que vous venez de créer et partager.

-> Faites un clic droit sur le dossier Migration ensuite sélectionnez Propriétés et enfin cliquez sur l’onglet Partage

-> Cliquez sur Autorisations et cochez l’autorisation « Modifier » pour Tout le monde, cliquez ensuite sur Appliquer ensuite OK.

Lancez cette fois ci l’Invite de commande depuis le serveur de destination SRV2008R2 et saisissez les commandes suivantes :

-> Pour accéder au dossier contenant l’outil de migration SmigDeploy.exe

cd %windir%\System32\ServerMigrationTools

-> Pour générer le dossier de déploiement pour le serveur source.

Note : mon serveur source SRV2003 (Windows Server 2003 SP1) est en version x32 donc je vais utiliser la valeur X86 avec le paramètre Architecture :

SmigDeploy.exe /package /architecture X86 /os WS03 /path \ \SRV2003\Migration

 Si votre OS Windows Server 2003 est en version x64, remplacez la valeur X86 par X64.

-> Enfin, vous pouvez constater que le dossier \ \SRV2003\Migration contient désormais un dossier nommé « SMT_ws03_x86 »

3. Nous devons maintenant terminer la configuration du dossier de déploiement sur le serveur source en inscrivant certaines Cmdlettes PowerShell, lancez l’invite de commande depuis SRV2003 saisissez :

cd C:\Migration\SMT_ws03_x86

SmigDeploy.exe

Après l’exécution de SmigDeploy.exe, une fenêtre de Windows PowerShell s’ouvre automatiquement :

Si par erreur vous avez fermé la fenêtre PowerShell, lancez Le module PowerShell des outils de migration de Windows Server :           ->Cliquez sur le menu Démarrer, ensuite Outils d’administration et enfin Outils de migration de Windows Server et cliquez sur Outils de migration 

Nous allons utiliser le paramètre Export-SmigServerSetting pour exporter tous les comptes utilisateurs et groupes locaux.

J’ai créé le dossier suivant C:\Migration\Export, ce dernier recevra le fichier exporté (.mig).

-> Depuis la fenêtre PowerShell ouverte, saisissez la commande suivante :

Export-SmigServerSetting -User All -Group -Path \SRV2003\Migration\Export -Verbose

Vous êtes invité à renseigner un mot de passe pour encrypter le fichier de migration qui sera généré :

Après avoir renseigné le mot de passe, une phase de collection des données démarre

Quand l’export est effectué, le résultat suivant apparaît :

Après l’export, un fichier nommé « srvmig.mig » est généré dans C:\Migration\Export

1. Nous arrivons à la dernière étape qui consiste tout simplement à importer le fichier de migration généré précédemment « srvmig.mig » contenant tous les comptes utilisateurs et groupes locaux du serveur source dans le serveur de destination (Windows Server 2008R2)

-> Depuis SRV2008R2, Cliquez sur le menu Démarrer, ensuite Outils d’administration et enfin Outils de migration de Windows Server et lancez Outils de migration de Windows Server en tant qu’Administrateur

-> Saisissez la commande suivante :

Import-SmigServerSetting -User Enabled -Group -Path \SRV2003\Migration\Export -Verbose

Vous êtes invité à renseigner le même mot de passe spécifié au moment de l’export

Après avoir renseigné le mot de passe, une phase de collection des données démarre

Après l’import, le résultat suivant apparaît :

Notez que si des comptes utilisateurs ou de groupes présents sur le serveur de destination portent le même nom que les comptes utilisateurs ou groupes exportés depuis le serveur source, ces derniers ne seront pas migrés, c’est le cas pour le compte Administrateur.

Enfin, cliquez sur Démarrer ensuite Exécuter et saisissez Lusrmgr.msc, vérifiez que vos comptes utilisateurs et groupes locaux sont bien migrés :

 

Vérifiez aussi les appartenances des comptes utilisateurs aux groupes :

Important : Les comptes utilisateurs locaux migrés ont « par défaut » les propriétés suivantes :

==> L’utilisateur doit changer le mot de passe à la prochaine ouverture de session

==> Le compte est désactivé

Donc n’oubliez pas de réactiver les comptes utilisateurs après la migration.

J’espère que cet article pourra vous être utile.

Comment verrouiller une session Windows lors du retrait de la carte à puce ?

Aujourd’hui, les entreprises et organisations nécessitant un niveau de sécurité élevé, exigent une infrastructure à clés publiques (Infrastructure PKI « Public Key Infrastructure ») au sein de leur S.I.

La carte à puce fait parti des composants physiques d’une infrastructure PKI et permet d’augmenter le niveau de sécurité en matière d’authentification des utilisateurs sur un réseau d’entreprise.

Ce matin, le client chez lequel je suis en mission me demande si nous pourrions configurer une action lorsqu’un utilisateur retire sa carte à puce du lecteur, par exemple : verrouiller sa session Windows automatiquement après le retrait de sa carte à puce.

Eh bien, c’ela est possible, et ce, a l’aide d’un paramètre de stratégie de groupe.

Comment ça marche ?

La configuration se fait en deux étapes :

1. Depuis la console de gestion des stratégies de groupe (GPMC.MSC), créez une GPO au niveau de l’OU contenant les ordinateurs du domaine sur lesquels vous voulez appliquer ce paramètre, faites ensuite un clic droit dessus et sélectionnez Editer.

=> Naviguez jusqu’au Configuration ordinateur \ Paramètre Windows \ Paramètres de sécurité \ Stratégies locales \ Options de sécurité.

=> Localisez le paramètre de stratégie de groupe Ouverture de session interactive : comportement lorsque la carte à puce est retirée, comme montré ci-après :

 

 

=> Double-cliquez dessus et choisissez Verrouiller la station de travail comme action, voir image ci-après:

 

2. Deuxième étape consiste tout simplement à configurer le type de démarrage du service Stratégie de retrait de la carte à puce en Automatique ou Automatique (début différé) sur les postes de travail. Je vous recommande le type Automatique (début différé) pour éviter tout verrouillage automatique de l’ordinateur avant même le chargement complet du programme /driver de la carte à puce et donc avant même le retrait de la carte à puce par l’utilisateur.

Note : vous pouvez utiliser la commande suivante pour configurer le service Stratégie de retrait de la carte à puce en Automatique (début différé) au lieu de passer par la console « Services »

! : la commande est à lancer depuis une Invite de commande en Mode Administrateur

sc config « SCPolicySvc » start= delayed-auto

Enfin, redémarrez vos postes de travail pour que les modifications soient prises en compte (application GPO & Configuration du service).

J’espère que cette article pourra vous être utilise.

Changer le répertoire par défaut de l’Invite de Commande – Server Core

Cette procédure s’applique à : Windows Server Core 2008, 2008 R2, 2012 et 2012 R2

Après le déploiement d’une installation minimale de Windows Server Core 2008, 2008 R2, 2012 ou 2012 Server, vous vous retrouvez qu’avec une simple invite de commande, il s’agit de la seule et unique Interface Utilisateur « UI – User Interface » depuis laquelle vous devez configurer et gérer votre Server Core.

Par défaut, vous êtes positionné dans le répertoire C:\Users\VotreProfilUtilisateur si votre serveur fait parti d’un groupe de travail (exemple : C:\Users\Hicham) ou C:\Users\VotreProfilUtilisateur.Domaine si votre serveur fait parti d’un domaine Active Directory (exemple C:\Users\Hicham.masociete.local), voir image ci-après :

Généralement, vous pouvez être amenés à exécuter des scripts, des outils en lignes de commande ou des programmes qui sont souvent stockés dans %windir%\System32, %ProgramFiles% ou tout simplement dans un dossier spécifique sur une de vos partitions /disques et vous préférez arriver directement dessus au lieu d’arriver sur C:\Users\VotreProfilUtilisateur.

Vous pouvez changer le répertoire par défaut de l’invite de commande soit :

=> Au niveau l’Utilisateur

=> Au niveau de l’Ordinateur

1. Changer le répertoire par défaut au niveau l’Utilisateur La procédure suivante vous permettra de changer le répertoire par défaut uniquement pour l’utilisateur avec lequel vous effectuez cette procédure:

* Depuis l’invite de commande, saisissez REGEDIT 

* L’éditeur de Registre s’ouvre, naviguez jusqu’au :

* Faites un clic droit sur « Command Processor », sélectionnez « Nouveau » et ensuite « Valeur de chaîne » (voir image ci-après)

* Saisissez Autorun comme nom de la valeur, validez en cliquant sur OK, ensuite double-cliquez la valeur Autorun

* Supposant, vous voulez arriver directement sur le répertoire « MesOutilsAdmin » placé dans la partition D:, parce que ce dernier est par exemple votre boite à outils qui contient l’ensemble des programmes & outils en ligne d’administration. eh bien, il suffit de saisir la commande CD /D D:\MesOutilsAdmin dans le champs « Donnée de la valeur » et validez en cliquant sur le bouton OK.

* Fermez l’éditeur de Registre.

* Depuis l’invite de commande, saisissez Logoff pour déconnecter votre session Windows.

* Reconnectez-vous en utilisant votre login et mot de passe Windows, l’Invite de commande vous affiche désormais par défaut  le chemin : D:\MesOutilsAdmin

 

2. Changer le répertoire par défaut au niveau de l’Ordinateur

* Depuis l’invite de commande, saisissez REGEDIT

* L’éditeur de Registre s’ouvre, naviguez jusqu’au : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

* Localisez la valeur « Shell » et double cliquez dessus

* Renseigner la commande suivante comme valeur de la clé Shell :

cmd.exe /c « cd /d « CHEMIN_SOUHAITE » & start cmd.exe /k runonce.exe /
AlternateShellStartup »

 

Ou « CHEMIN_SOUHAITE » est le répertoire /chemin vers lequel vous voulez arrivez directement.

Exemple :

cmd.exe /c « cd /d « %USERPROFILE% » & start cmd.exe /k runonce.exe /
AlternateShellStartup »

Ou pour reprendre l’exemple précédent :

cmd.exe /c « cd /d « D:\MesOutilsAdmin » & start cmd.exe /k runonce.exe /
AlternateShellStartup »