Archives de la catégorie ‘Windows Sever’

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

A propos de cet eBook

Cet eBook présente la solution Microsoft ATA « Microsoft Advanced Threat Analytics”, à travers cet eBook vous apprendrez à concevoir, déployer, administrer et dépanner la solution Microsoft ATA.

De plus, l’auteur décrit et présente la solution en détails et de manière pragmatique, il s’appuie sur ses retours d’expérience terrain suite à la réalisation de différents projets ATA réalisés pour des clients grands compte.
L’auteur est un véritable expert de la solution, il travaille sur celle-ci depuis sa première version et a suivi toutes ses évolutions dans le temps, ce qui lui permet de vous faire un retour concret à travers cet eBook.

Enfin, plusieurs ressources sont fournies avec le présent eBook, notamment les Schémas Visio utilisés dans les différents chapitres.

 

Publics concernés par cet eBook

Cet eBook peut intéresser plusieurs populations IT :

RSSI
Architecte Infrastructure
Architecte sécurité
Architecte Réseau
Consultant Infrastructure /Sécurité
Ingénieur Systèmes /Infrastructure /Sécurité
Toute personne désirant apprendre « in-depth » Microsoft ATA

 

Sommaire 

L’eBook est organisé en 6 chapitres, voir sommaire ci-dessous :

Très bon eBook écrit par mon Bro Seyfallah TAGREROUTMVP Cloud & Datacenter Management

L’eBook est disponible sur BecomeITexpert.com, cliquez sur l’image ci-après pour en savoir plus :

Read & Enjoy :).

Le Remote Desktop est une technologie utilisée aujourd’hui par la quasi-totalité des entreprises, que ce soit pour du support technique (Session Shadowing pour les end-users) ou pour permettre aux téléworkers d’accéder aux applications d’entreprise.

Microsoft propose depuis plusieurs années déjà, une application « Lourde » nommée Microsoft Remote Desktop pour différentes plateformes (Cross-Platform Remote Desktop Client) :

Mac OS

Télécharger Microsoft Remote Desktop pour MacOS X

Android

Télécharger Microsoft Remote Desktop pour Android

iOS

Télécharger Microsoft Remote Desktop pour iOS

Avec l’arrivé du Cloud, la vision (à court terme) de plusieurs décideurs informatique, est de proposer à leur End-users un environnement « Full Cloudisé » et uniquement un client léger (e.g : Chrome Book) pour l’accès aux applications hébergées dans le Cloud (SaaS Apps : Software-as-a-Service Applications).

Avec cette vision, aucun client « Lourd » ou application locale ne doit être installée sur le poste client (Thin Client). L’accès se fait principalement depuis un Web Browser.

Pour répondre à ce type de besoin (ou d’architecture), Microsoft a introduit le nouveau Remote Desktop Web nommé « RD Web Client ». Ce client Web est basé sur HTML5 et prend en charge la plupart des navigateurs Web (Edge, IE, Chrome, Firefox, etc.).

Selon les informations communiquées par l’équipe Remote Desktop Services Corp, RD Web Client ne prend malheureusement pas en charge les Clients « Mobile ».

RD Web Client est disponible (au moment de la rédaction du présent post) en Preview et supporte déjà les fonctionnalités classiques de l’outil RDC (Remote Desktop Connection : MSTSC.exe) telles que :

Clipboard (Copier/Coller)

Redirection d’imprimante

Remote Audio

 

Prerequis à prendre en considération 

Pour pouvoir déployer le Client Web Remote Desktop, votre infrastructure RDS cible doit remplir les conditions suivantes :

Tous les serveurs RDS du déploiement (RDCB, RDSH, RDWA et RDG) doivent exécuter Windows Server 2016.

Votre déploiement RDS ne doit pas être configuré avec des CAL RDS « Per-Device /Par-Périphérique »

La  KB4025334 doit être installée sur votre serveur RDG (Remote Desktop Gateway).

Les serveurs RD Web Access et Gateway doivent utiliser des certificats SSL signés par une CA (Certification Authority) Publique.

Enfin, côté client, il faut bien évidemment utiliser des Web Browsers prenant en charge de la HTML5. IE11, Edge, Chrome, Firefox et Safari le sont, donc all is Ok :).

 

Installation du RD Web Client

Je détaillerai l’installation du Client Web Remote Desktop lors d’un prochain post, comme expliqué précédemment, il est aujourd’hui en « Preview Version ». Je publierai un HowTo détaillé directement sur la Finale Preview ^_^.

Ce que vous devez savoir, c’est que le RD Web Client est simplement une Extension à ajouter au niveau du service de rôle « RD Web Access ».

L’équipe RDS Corp travaillent sur une nouvelle Cmd-let qui permettra de faciliter le déploiement de ce client : Install-RDWebClientPackage

L’affichage des ressources RDS déportées directement sur le RD Web Client ressemble à l’image ci-dessous :

Je vous en dirais pas plus :),

Keep in touch

#HK

 

Certains clients disposant d’une zone démilitarisée (ou DMZ pour Demilitarized Zone) et désirant déployer une infrastructure RDS avec une ou plusieurs Passerelles RDS (RDG : Remote Desktop Gateway) et serveurs RDWA (Remote Desktop Web Access) se posent souvent la question suivante :

Quels sont les (ports) requis à ouvrir pour permettre à tous les services de rôles RDS de communiquer correctement ?

Cette communication concerne principalement les serveurs RDG et RDWA placés en DMZ avec les autres services de rôles RDS en back-end, placés généralement sur le réseau interne de l’entreprise et se trouvant derrière un ou plusieurs Firewalls, notamment les serveurs Hôtes de Session (RDSH : Remote Desktop Session Host) et serveurs Broker (RDCB : Remote Desktop Connection Broker).

Vu que le serveur de Passerelle RDS doit être membre du domaine AD (Workgroup non supporté !), les flux avec les Contrôleurs de domaine AD (DC : Domain Controllers) sont nécessaires, et ce pour authentifier les utilisateurs distants (externes) et les autoriser à accéder aux ressources RDS internes.

Dans ce type d’architecture (scénario de déploiement), plusieurs ports sont à ouvrir pour permettre à la Passerelle RDS de remplir les fonctions suivantes:

  • Authentifier les utilisateurs distants/externes RDS
  • Autoriser les utilisateurs distants/externes RDS à accéder aux ressources internes publiées
  • Résoudre les noms DNS des ressources RDS internes
  • Forwarder (au Broker) les packets RDP envoyés par les clients distants.
  • Obtenir la liste des Révocations de Certificats SSL
  • Envoyer des requêtes RADIOS (si vous déployez un serveur NPS central)

 

Pour simplifier la compréhension de la matrice de flux « global », j’ai décidé de créer deux catégories de Flux, à savoir :

Flux entre « External Network » et la Passerelle RDS placée en DMZ : config au niveau du Firewall Externe

Flux entre la « Passerelle RDS » et les ressources internes (RDSH, RDCB, DC…) : config au niveau du Firewall Interne

Le diagramme Visio ci-dessous représente une architecture RDS classique avec RDG/RDWA en DMZ et le reste des services de rôles en interne

Flux entre « External Network » et la Passerelle RDS placée en DMZ : Pare-feu Externe

Déployer une Passerelle RDS vous évite d’exposer directement vos ressources RDS à Internet et les protéger contre plusieurs types attaques informatique (e.g DoS/DDoS Attack !).

La Passerelle RDS a besoin du serveur Web IIS (Internet Information Services) pour fonctionner.

Le WebSite RDG hébergé sur IIS nécessite une liaison « HTTPS », par conséquent le port de communication (d’écoute) utilisé par la RDG est le 443.

Vous aurez compris, pour autoriser le trafic HTTPS entrant et permettre une communication entre les clients externes et la Passerelle RDS placée en DMZ (derrière un Firewall Externe/Public), la règle suivant doit être créée/configurée :

Nom de la règle : External_to_RDG (nom de règle donné à titre d’exemple)

Port : 443/TCP

Protocol : HTTPS

Source : Internet

Destination : @IP de la Passerelle RDS placée en DMZ

 

Flux entre la « Passerelle RDS » placée en DMZ et les ressources internes (RDSH,RDCB,DC…) : Pare-feu Interne

Le Pare-feu Interne doit être configuré pour autoriser plusieurs types de communications (trafics) entre le ou les serveurs RDG placés en DMZ et vos ressources internes tels que les Domain Controller (pour authentification/autorisation), Serveurs Broker (redirection aux ressources RDS), Serveurs RDSH (accès aux ressources publiées).

Trafic lié à l’authentification  & autorisation via la Passerelle RDS
#Kerberos

La règle à mettre en place pour autoriser le trafic (Kerberos) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’authentifier les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 88/TCP

Protocol : Kerberos

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#Service RPC NT Directory Service (NTDS) 

Le serveur RDG a également besoin de communiquer avec le service RPC NTDS (NT Directory Services) lié à l’AD, ce dernier écoute généralement sur un numéro de port non utilisé et pris d’une plage de ports haute. Le serveur RDG n’ayant pas la capacité de connaitre ce numéro de port (dynamic port) utilisé par le service RPC NTDS, il contacte le Mappeur de point de terminaison RPC (RPC Endpoint Mapper) en utilisant le port 135, l’Endpoint Mapper indique ensuite au serveur RDG le port d’écoute pour le service demandé qu’est le RPC NTDS. Comme indiqué précédemment, ces numéros de ports sont attribués de manière dynamique (généralement compris entre 1024 et 65 535), notez qu’à l’aide d’une clé de Registre, vous pouvez configurer un port « Statique » pour le RPC NTDS si nécessaire. Je vous laisse consultez cet article pour en savoir plus.

Nom de la règle : RDG_to_RPCMapper (nom de règle donné à titre d’exemple)

Port : 135/TCP + Port d’écoute configuré pour le service RPC NTDS

Protocol :RPC Endpoint Mapper + RPC NTDS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#LDAP

La règle à mettre en place pour autoriser le trafic (LDAP) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’autoriser les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 389/TCP et 389/UDP

Protocol : LDAP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#DNS

La règle à mettre en place pour autoriser le trafic DNS entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne et permettre la résoudre des noms DNS des ressources internes :

Nom de la règle : RDG_to_DNS (nom de règle donné à titre d’exemple)

Port : 53/TCP et 53/UDP

Protocol : DNS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs_ou un des serveurs DNS du réseau

 

#RDP

La règle à mettre en place pour autoriser le trafic RDP entre la Passerelle RDS placée en DMZ et les serveurs RDS internes pour forwarder les packets RDP reçus par les clients distants :

Nom de la règle : RDG_to_RDSHCB (nom de règle donné à titre d’exemple)

Port : 3389/TCP

Protocol : RDP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP des serveurs RDSH ainsi que RDCB

 

Note importante : si le port RDP par défaut, a été personnalisé/changé sur le déploiement RDS (e.g 33381 au lieu de 3389), le port 33381 doit être spécifié dans la règle ci-dessus.

Trafic entre le serveur RD Web Access et les serveurs RDSH internes

Si vous avez décidé de placer votre ou vos serveurs RD Web Access en DMZ (chose que je vous recommande d’ailleurs :)), notez qu’un seul flux est à ouvrir :

Nom de la règle : RDWA_to_RDCB (nom de règle donné à titre d’exemple)

Port : 5504/TCP

Protocol : RPC

Source :@IP du ou des serveurs RDWA placés en DMZ

Destination : @IP du(es) serveurs RDCB

 

J’espère que cet article pourra vous être utile lors du Design de votre infra RDS et/ou rédaction de votre document d’architecture technique/DAT/TAD (RDS Network Considerations Section).

Notez que des ports supplémentaires peuvent être requis si vous disposez d’une plateforme RADIUS, ou utilisez par exemple des solutions « Third-party » pour l’authentification/autorisation (dans ce cas, referez-vous à la documentation technique fournie par l’éditeur de solution pour en savoir plus).

Keep in touch,

A bientôt

#HK

 

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