Archives de la catégorie ‘Windows Server 2008 (R2)’

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

Publicités

 

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

 

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

 

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

 

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

 

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:

MMCEXView

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

Jscript Reussi

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

Jscript Reussi_W7

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.

 

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 :

IMG28

IMG29

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

IMG30

IMG31

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

IMG33

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

IMG32

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

IMG34

  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

IMG35

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

IMG36

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

IMG37

 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 »

IMG38

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 :

IMG39

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

IMG40

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

IMG41

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

IMG42

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

IMG43

  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

IMG34

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

IMG44

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

IMG45

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

IMG46

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 :

IMG47

 

IMG49

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

IMG50

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é

IMG48

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

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