Windows Server 2008 R2

  • Article

Windows Server 2008 R2 : Introduction

William Stanek

Vue d'ensemble :

Éditions de Windows Server

La visite à 5 dollars

Windows PowerShell 2.0 et WinRM 2.0

Immobilisation de cœur

Feuille de route pour les changements d'Active Directory

Mise en cache de filiale

 

À ce jour, vous avez entendu parler, et peut-être même déjà installé, Windows Server 2008 R2, auquel je ferai désormais référence sous l'appellation de R2 dans cet article. Étant donné que R2 est une édition incrémentielle, vous pouvez y appliquer beaucoup de ce que vous savez déjà de Windows Server 2008 et Windows 7. Windows Server 2008 R2 s'appuie sur les améliorations apportées à Windows Server 2008 et partage un tronc commun avec Windows 7. En raison de ce tronc commun, R2 et Windows 7 partagent un certain nombre de fonctions et de composants, que vous pouvez gérer à peu près de la même manière, que vous utilisiez Windows 7 ou R2.

Comme Windows Server 2008, R2 utilise la modularisation pour l'indépendance des langues et la création d'image disque. Microsoft distribue Windows Server 2008 R2 sur support physique sous forme d'images disque WIM (Windows Imaging Format). Comme Windows 7, R2 utilise l'environnement de préinstallation Windows PE 3.0 pour procurer des services de préinstallation et de prédémarrage avec un gestionnaire de démarrage qui vous permet de choisir quelle application de démarrage exécuter pour charger le système d'exploitation. Sur les ordinateurs à systèmes d'exploitation multiples, vous pouvez accéder aux systèmes d'exploitation antérieurs à Windows Vista dans l'environnement de démarrage à l'aide de l'entrée de système d'exploitation héritée.

Le programme d'installation de Windows Server 2008 R2 installe également une partition d'environnement de récupération Windows (Windows RE) sur votre serveur. Windows RE vous permet d'accéder à une ligne de commande pour dépanner, réinstaller à partir d'une image système et effectuer des diagnostics de mémoire.

Contrairement à Windows 7, Windows Server 2008 R2 n'inclut pas les améliorations d'interface telles que Windows Aero (Aero Glass, Flip, 3D Flip et autres), Windows Sidebar ou Windows Gadgets. Vous pouvez toutefois installer la fonction Expérience utilisateur pour ajouter la fonctionnalité de Bureau Windows 7 à un serveur. Les fonctions Windows 7 ajoutées comprennent la Table des caractères, les thèmes de Bureau, le Nettoyage de disque, l'outil Capture, le Magnétophone, le Centre de synchronisation, Vidéo pour Windows (prise en charge du format AVI), le pare-feu Windows Defender et le Lecteur Windows Media. Si ces fonctions permettent à un serveur d'être utilisé comme un ordinateur de bureau, elles peuvent également nuire à ses performances globales.

Familiarisation avec les éditions de R2

Au-delà du tronc commun, Windows R2 diffère énormément de Windows 7. Pour commencer, R2 est le premier système d'exploitation Microsoft qui n'existe qu'en version 64 bits. Concrètement, R2 prend en charge les systèmes 64 bits conçus pour l'architecture x64. La prise en charge des processeurs Itanium 64 bits (IA-64) n'est plus standard dans les systèmes d'exploitation Windows. Microsoft a développé une édition distincte de R2 pour les ordinateurs avec système Itanium.

Figure 1- Utilisation du Centre de maintenance

 

La famille de systèmes d'exploitation R2 comprend les éditions suivantes :

  • Windows Server 2008 R2, Foundation Edition, offre une base économique pour les petites et moyennes entreprises. Cette édition ne prend pas en charge les services AD FS (Active Directory Federation Services) ou Hyper-V. Elle permet de déployer les autorités de certification, mais ne peut pas héberger d'autres services connexes. Cette édition prend en charge tous les autres rôles, avec certaines limites. Ne sont pas non plus prises en charge les fonctions de gestion DirectAccess et de clustering avec basculement. L'édition Foundation prend en charge jusqu'à 8 Go de RAM et un processeur enfiché sur socket discret.
  • Windows Server 2008 R2 Standard offre les services et les ressources essentielles aux autres systèmes d'un réseau. Cette édition prend en charge Hyper-V et impose certaines limites avec d'autres services, mais ne prend pas en charge les services AD FS (Active Directory Federation Services). Elle permet de déployer les autorités de certification, mais ne peut pas héberger d'autres services connexes. N'est pas non plus prise en charge la fonction de clustering avec basculement. L'édition Standard prend en charge jusqu'à 32 Go de RAM et jusqu'à quatre processeurs enfichés sur socket discret.
  • Windows Server 2008 R2 Entreprise procure la capacité d'évolution et la disponibilité nécessaires à une grande entreprise. Cette édition prend en charge tous les rôles de serveur, sans les limitations des éditions Foundation ou Standard, et prend également en charge des fonctions telles que le clustering avec basculement. L'édition Entreprise prend en charge jusqu'à 2 To de RAM et jusqu'à huit processeurs enfichés sur socket discret.
  • Windows Server 2008 R2, Datacenter Edition, procure une capacité d'évolution et une disponibilité de classe Centre de données global et offre des fonctions améliorées d'ajout et de remplacement à chaud de mémoire, ou d'ajout et de remplacement à chaud de processeur. L'édition Datacenter prend en charge jusqu'à 2 To de RAM et jusqu'à 64 processeurs enfichés sur socket discret.
  • Windows Server 2008 R2 pour les systèmes Itanium offre une plateforme d'entreprise pour l'hébergement d'applications critiques et l'implémentation de solutions de virtualisation de grande échelle. Cette édition n'est pas conçue pour fournir des services centraux, et ne prend en charge que les rôles Serveur d'application et Serveur Web (IIS), ainsi que la fonction de clustering avec basculement. Aucun autre rôle n'est pris en charge à la date de rédaction de cet article. Cette édition prend en charge jusqu'à 2 To de RAM et jusqu'à 64 processeurs enfichés sur socket discret.
  • Windows Web Server 2008 offre des services Web pour déployer des applications et des services Web. Cette édition comprend uniquement Microsoft .NET Framework, IIS, ASP.NET, les fonctions de serveur d'applications et d'équilibrage de charge, ainsi que les fonctions de serveur DNS, les services WSUS (Windows Server Update Services) et les services Windows Media. Cette édition prend en charge 32 Go de RAM et jusqu'à 4 processeurs enfichés sur socket discret.

Maintenant que les présentations sont faites, intéressons-nous au fonctionnement de R2 et à ses nouvelles fonctions. 

Figure 2 – Apporter des solutions aux problèmes

 

La visite à 5 dollars

Le Centre de maintenance, illustré en Figure 1, est le centre névralgique de tout ce qui a trait à la sécurité et à la maintenance. Si les diagnostics ont détecté des problèmes, le Centre de maintenance vous fournira des informations sur ces problèmes ainsi qu'une option pour obtenir des informations supplémentaires. Il n'est pas rare que des informations supplémentaires sur un problème procure une solution possible. Dans l'exemple illustré en Figure 1, le serveur rencontre un problème avec sa carte son et le périphérique Intel Active Management. Cliquer sur le bouton Afficher les détails du message permet d'afficher le message détaille et de fournir un lien permettant de télécharger le pilote mis à jour, comme illustré en Figure 2.

Les diagnostics intégrés ne trouveront pas toujours les problèmes et ne seront pas toujours en mesure de fournir des solutions, mais les processus en question ont été améliorés par rapports aux éditions précédentes. Dans le volet Maintenance, vous pouvez également cliquer sur le lien Rechercher des solutions pour rechercher des problèmes qui n'auraient pas été encore identifiés automatiquement.

Centre Réseau et partage, illustré en Figure 3, demeure le point central de la configuration de la mise en réseau. Avec Windows Server 2008 R2, les réseaux sont identifiés comme appartenant à l'une ou l'autre des catégories suivantes :

  • Réseau du domaine
  • Réseau de travail
  • Réseau public

Figure 3 – Utilisation du Centre Réseau et partage

Chaque catégorie de réseau est associée à un profil réseau. R2 enregistre les paramètres de découverte réseau, de partage et de pare-feu séparément pour chaque catégorie de réseau, ce qui permet à un serveur d'avoir différents paramètres de découverte et de partage pour chaque catégorie de réseau. Le Pare-feu Windows traite également les règles entrantes, les règles sortantes et les règles de sécurité séparément pour chaque profil réseau, et R2 peut disposer ainsi de plusieurs profils de pare-feu actifs, suivant les réseaux auxquels un serveur est connecté.

Comme Windows Server 2008, R2 prend en charge la fonction Déchargement TCP Chimney, qui permet au sous-système de gestion réseau de décharger du traitement d'une connexion TCP/IP les processeurs d'un serveur et de le confier à ses cartes réseau à condition que celles-ci prennent en charge le traitement du déchargement TCP/IP. Les connexions TCP/IPv4 et TCP/IPv6 peuvent être déchargées toutes les deux. Par défaut, les connexions TCP sont déchargées sur les cartes réseau 10 Gbits/s mais ne le sont pas sur les cartes réseau 1 Gbit/s. Vous pouvez ajuster les paramètres connexes à l'aide de Netsh.

Windows Server 2008 R2 ajoute la prise en charge des extensions de sécurité DNS (DNSSEC). Le client DNS pour Windows 7 et R2 peut envoyer des requêtes qui signalent la prise en charge de DNSSEC, traiter les enregistrements connexes et déterminer si un serveur DNS a validé des enregistrements pour son compte. La prise en charge de DNSSEC permet à vos serveurs DNS de signer des zones en sécurité et d'héberger des zones signées DNSSEC. Elle permet également aux serveurs DNS de traiter les enregistrements connexes et de valider et authentifier les enregistrements.

R2 remplace les services Terminal Server et tous les composants qui leur sont associés par une offre mise à jour et améliorée appelée services Bureau à distance. Les services Bureau à distance permettent aux utilisateurs d'accéder à des ordinateurs de bureau basés sur session, à des ordinateurs de bureau basés sur ordinateur virtuel et à des applications hébergées par des serveurs à distance. Dans R2, tous les rôles des services Bureau à distance ont été renommés, comme l'ont été aussi les outils de gestion qui leur sont associés. La figure 4 fournit l'ancien et le nouveau nom de chaque service de rôle. La figure 5 fournit l'ancien et le nouveau nom de chaque outil de gestion.

Ancien nom du service de rôle Nouveau nom du service de rôle
Services Terminal Server Services Bureau à distance
Terminal Server Hôte de session Bureau à distance
Gestionnaire de licences TS
Passerelle des services Terminal Server (Passerelle TS)
Service Broker pour les connexions Bureau à distance
(Accès Web TS) Accès Web aux services Bureau à distance

Figure 4 – Noms des services de rôle

 

Pour R2, les services de certificats Active Directory (AD CS) ajoutent plusieurs fonctions et services qui facilitent le déploiement d'une infrastructure de clé publique (PKI) et offrent une meilleure prise en charge de la protection d'accès réseau (NAP). Les services Web Inscription de certificats et Web Stratégie d'inscription de certificats permettent l'inscription via HTTP et sur plusieurs forêts. Cela permet de consolider l'autorité de certification (CA) dans les déploiements sur plusieurs forêts et de réduire les tailles des bases de données CA dans certains déploiements NAP.

Windows AppLocker remplace la fonction Stratégies de restriction logicielle. AppLocker aide les administrateurs à contrôler la manière avec laquelle les utilisateurs peuvent accéder à et utiliser des fichiers tels que les exécutables, les DLL, les scripts et les fichiers Windows Installer. AppLocker le fait en vous permettant de définir les règles qui spécifient les fichiers qui sont autorisés à s'exécuter. Les fichiers ne sont pas inclus dans les règles ne sont pas autoriser à s'exécuter.  

Ancien nom de l'outil Nouveau nom de l'outil
Gestionnaire des services Terminal Server Gestionnaire des services Bureau à distance
Configuration des services Terminal Server Configuration de l'hôte de session Bureau à distance
Gestionnaire de passerelle TS Gestionnaire de passerelle des services Bureau à distance
Gestionnaire de licences TS Gestionnaire de licences des services Bureau à distance
Gestionnaire RemoteApp TS Gestionnaire RemoteApp

Figure 5 – Noms des outils de gestion

 

R2 Enterprise Edition, Database Edition et l'édition pour les systèmes Itanium prennent en charge les clusters de basculement. Un cluster de basculement est un groupe de serveurs indépendants qui fonctionnent ensemble pour améliorer la disponibilité des applications et des services. Chaque serveur du cluster, qu'on appelle un nœud, peut être configuré pour reprendre en main les applications ou services en échec d'un autre serveur du cluster. R2 ajoute des applets de commande Windows PowerShell pour les clusters de basculement, améliore le processus de validation pour les clusters et la gestion des ordinateurs virtuels en cluster (pris en charge par Hyper-V), qui peuvent maintenant utiliser des volumes partagés en cluster.

En plus des services et des applications que vous pouviez précédemment configurer dans un cluster de basculement, vous pouvez maintenant configurer le service Broker pour les connexions Bureau à distance pour l'équilibrage de charge et la reconnexion de session dans une batterie de serveurs Bureau à distance à équilibrage de charge. Vous pouvez également configurer la réplication DFS pour garder les dossiers synchronisés entre serveurs via des connexions réseau à bande passante limitée. Vous pouvez mettre en cluster tout serveur membre dans le groupe de réplication.

À propos de clusters, R2 ajoute de nouvelles fonctions pour vos solutions de centre de données et solutions matérielles, y compris iSCSI Software Initiator et MPIO (Multipath I/O). Microsoft iSCSI Software Initiator vous permet de connecter un serveur Windows à un groupe de stockage iSCSI externe via une carte réseau Ethernet. Pour R2, l'interface utilisateur iSCSI Initiator a été reconçue de sorte de faciliter l'accès aux paramètres les plus communs, et plusieurs fonctions ont été ajoutées, y compris Connexion rapide, qui permet des connexions à un clic à des périphériques de stockage de base. Sont désormais pris en charge le démarrage iSCSI sur 32 chemins (au maximum) au moment du démarrage, l'en-tête de contrôle de redondance cyclique et le déchargement des résumés de données.

MPIO permet l'utilisation de plusieurs chemins de données pour le stockage et améliore la tolérance de panne des connexions de stockage. R2 propose désormais des rapports de configuration et des rapports d'intégrité MPIO améliorés. Ces deux nouveautés facilitent l'obtention des données de chemin. Vous pouvez également configurer des stratégies à équilibrage de charge à l'aide de l'utilitaire de ligne de commande MPClaim.

Figure 6 – Utilisation du Centre d'administration Active Directory

 

Hyper-V aussi a été considérablement amélioré. Parmi les améliorations apportées à Hyper-V, notons une nouvelle fonctionnalité de migration en direct, la prise en charge du stockage dynamique d'ordinateur virtuel, et des améliorations à la prise en charge de la mise en réseau et des processeurs.

Pour la dernière escale de notre visite éclair, je souhaite vous parler du Centre d'administration Active Directory, illustré en Figure 6. Ce nouvel outil offre une interface orientée tâche pour gérer Active Directory. Vous pouvez utiliser cet outil pour les tâches suivantes :

  • Se connecter à un ou plusieurs domaines
  • Créer et gérer des comptes utilisateur
  • Créer et gérer des groupes
  • Créer et gérer des unités d'organisation
  • Effectuer des recherches globales d'Active Directory

Le Centre d'administration Active Directory utilise Windows PowerShell pour effectuer des tâches d'administration et s'appuie sur l'infrastructure Microsoft .NET Framework 3.5.1. Pour cette raison, les deux fonctionnalités doivent être installées et configurées pour vous permettre d'utiliser le Centre d'administration Active Directory pour vos tâches d'administration. De plus, le Centre d'administration Active Directory fait usage des services Web fournis par ADWS (Active Directory Web Services). Dans chaque domaine Active Directory que vous voulez gérer, ADWS doit être installé et les services connexes exécutés sur au moins un contrôleur de domaine. Les connexions sont faites par défaut via le port TCP 9389, et les stratégies de pare-feu doivent autoriser une exception sur ce port pour ADWS.

Windows PowerShell 2.0 et WinRM 2.0

Vous vous demandez où vous procurer ces fort appétissantes applets de commande Windows PowerShell ? Windows PowerShell 2.0 est installé par défaut dans la plupart des configurations R2. Sur les installations de serveur complètes, la console Windows PowerShell est disponible sur la barre d'outils Lancement rapide et vous pouvez installer l'environnement de script graphique à l'aide de l'Assistant Ajout de fonctionnalités. Sur les installations de serveur centrales, vous avez maintenant la possibilité d'installer également Windows PowerShell.
Après le démarrage de Windows PowerShell, vous pouvez entrer le nom d'une applet de commande à l'invite qui fonctionnera à peu de chose près comme une commande de ligne de commande. Vous pouvez également exécuter les applets de commande à l'intérieur de scripts. Les applets de commande sont nommées à l'aide de couples verbe-nom. Le verbe indique la fonction générale de l'applet de commande. Le nom indique sur quoi agit spécifiquement l'applet de commande. Par exemple, l'applet de commande start-service démarre un service Windows, et l'applet de commande stop-service arrête un service Windows.
Les appétissantes applets de commande qui opèrent dans le Centre d'administration Active Directory sont également disponibles. Pour les utiliser, vous devez importer le module Active Directory en entrant la commande Import-Module ActiveDirectory à l'invite Windows PowerShell. Une fois le module importé, vous pouvez l'utiliser avec l'instance en cours d'exécution de Windows PowerShell. Au prochain démarrage de Windows PowerShell, vous devrez importer à nouveau le module pour utiliser ses fonctions. Autrement, vous pouvez sélectionner l'option Module Active Directory pour Windows PowerShell

dans le menu Outils d'administration, qui importe le module pour vous au démarrage de Windows PowerShell, comme illustré en Figure 7. 

Figure 7 – Utilisation du Module Active Directory pour Windows PowerShell

 

Vous pouvez également utiliser Windows PowerShell pour la gestion à distance. Les fonctions de gestion à distance sont prises en charge par le protocole WS-Management et le service Windows Remote Management (WinRM) qui implémente WS-Management dans Windows. R2 comprend WinRM 2.0. Windows 7 et Windows Server 2008 R2 offre la prise en charge intégrée de la gestion à distance à l'aide de WinRM. Dans les versions antérieures de Windows, vous pouvez réussir à installer Windows Management Framework, qui comprend Windows PowerShell 2.0 et WinRM 2.0.

Chaque fois que vous utilisez Windows PowerShell pour la gestion à distance, vous devez le démarrer en tant qu'administrateur. Vous devez également veiller à ce que WinRM soit configuré correctement à la fois sur votre ordinateur de gestion et sur le ou les serveurs cibles. Vous pouvez vérifier et mettre à jour la configuration WinRM à l'aide de la commande winrm quickconfig.

Vous pouvez utiliser Server Manager (et d'autres consoles MMC) pour effectuer certaines tâches de gestion sur des ordinateurs distants tant que ces ordinateurs se trouvent dans le même domaine ou que vous travaillez dans un groupe de travail et avez ajouté les ordinateurs distants dans un domaine en tant qu'hôtes approuvés. Vous pouvez vous connecter à des serveurs exécutant à la fois des installations de serveur complètes et centrales.

Une fois que vous avez activé la gestion à distance pour Server Manager, vous pouvez utiliser Server Manager pour effectuer des tâches de gestion à distance, telles que :

  • Afficher et gérer des rôles, des services de rôle et des fonctionnalités (mais pas ajouter ou supprimer)
  • Afficher et gérer les fonctionnalités avancées du Pare-feu Windows
  • Afficher et gérer les événements et les services Windows
  • Afficher et gérer l'analyse des performances
  • Afficher et gérer les tâches planifiées
  • Afficher et gérer les disques
  • Configurer la création de rapports d'erreurs et l'état de l'expérience client
  • Afficher l'état des mises à jour automatiques

La gestion à distance utilise Windows PowerShell et dépend de la configuration de WinRM. Sur les installations de serveur complètes et centrales, vous devez spécifiquement activer la gestion à distance via Server Manager.

Figure 8 – Utilisation de scripts Windows PowerShell dans la stratégie de groupe

 

Sur les installations de serveur complètes, vous pouvez utiliser l'option Configurer la gestion à distance du Gestionnaire de serveur lorsque vous êtes connecté localement, ou le script Configure-SMRemoting.ps1. Sur les installations de serveur centrales, vous pouvez utiliser l'utilitaire de configuration du serveur (Sconfig.exe).

R2 propose des applets de commande qui vous permettent de gérer aussi la stratégie de groupe à partir de Windows PowerShell. Il vous suffit d'importer le module Stratégie de groupe en entrant la commande Import-Module GroupPolicy à l'invite Windows PowerShell. Une fois le module importé, vous pouvez utiliser les applets de commande de Stratégie de groupe avec l'instance en cours d'exécution de Windows PowerShell.

Vous pouvez également exécuter les scripts Windows PowerShell au cours de l'ouverture ou de la fermeture de session ou du démarrage ou de l'arrêt du système. Comme illustré en Figure 8, vous pouvez configurer les scripts Windows PowerShell de sorte qu'ils s'exécutent avant d'autres types de scripts. Il est également possible d'exécuter les scripts Windows PowerShell après d'autres types de scripts. N'oubliez pas, dans vos scripts, de définir l'environnement de travail en important tous les modules requis.

Présentation de l'immobilisation de cœur

L'immobilisation de cœur est une fonction de R2 dont vous avez probablement entendu parler. Ce que vous ignorez peut-être est d'où vient cette fonction et comment elle fonctionne. L'immobilisation de cœur est conçue pour réduire la consommation d'énergie en limitant ou en rendant inactif des cœurs de processeur en fonction de la charge du serveur. La fonction est possible car Windows 7 et Windows Server 2008 R2 prennent en charge la spécification ACPI (Advanced Configuration and Power Interface) 4.0, qui a été finalisée en juin 2009. Puisqu'il est peu probable que vous vous plongiez jamais dans la lecture des plus de 700 pages qui décrivent la spécification officielle, je vais vous extraire les passages qui concernent la gestion de l'énergie.

Windows utilise ACPI pour contrôler les transitions d'état d'alimentation du système et des périphériques. Windows met les périphériques sous ou hors tension complète, dans des états de basse puissance ou de désactivation afin de réduire la consommation d'énergie. Un état de faible puissance, ou limité, implique de réduire la fréquence de fonctionnement du processus. Un état de désactivation, ou d'inactivité, implique de mettre le processeur dans un état de sommeil.
Les paramètres d'alimentation d'un serveur proviennent du mode de gestion de l'alimentation actif. Le mode de gestion de l'alimentation actif par défaut dans Windows Server 2008 R2 s'appelle Balanced, et il tire profit des améliorations apportées à la spécification ACPI pour réduire la consommation d'énergie. Si la spécification ACPI 3.0 définit des états minimum et maximum pour limiter la puissance des processeurs, elle s'applique à des processeurs enfichés sur socket discret, pas à des cœurs de processeur logiques. Une solution pour limiter et rendre inactif les cœurs de processeur logiques, c'est exactement ce qu'offre ACPI 4.0 (entre autres choses, moins essentielles).

Grâce à la spécification ACPI 4.0, lorsque vous spécifiez des limites maximales et minimales pour l'état du processeur dans une stratégie d'alimentation, Windows sait appliquer ces états aux cœurs de processeur logiques ainsi qu'aux processeurs enfichés sur socket discret. Les valeurs maximales et minimales définissent les limitent des états de performance autorisée. Par exemple, si la limite supérieure est 100 pour cent et la limite inférieure est 5 pour cent, Windows est capable de limiter les processeurs à cette plage, dans la mesure où la charge de travail le permet, afin de réduire la consommation d'énergie. Dans un ordinateur doté de plusieurs processeurs de 4 GHz, Windows fixerait la fréquence des processeurs entre 0,25 et 4 GHz.

La Figure 9 montre un exemple, à des fins d'illustration uniquement, de limitation et de mise en inactivité de processeur. Ici, l'ordinateur possède quatre processeurs enfichés sur socket discret, dotés chacun de quatre processeurs logiques. Les cœurs de processeur qui ne sont pas nécessaires pour traiter la charge de travail en cours sont mis en état d'inactivité, et les cœurs de processeur qui ne sont que partiellement sollicités sont limités. Par exemple, le cœur logique 1 du processeur 1 tourne à 90 pour cent tandis que ses cœurs logiques 2, 3 et 4 tournent à 80 pour cent. Dans un processeur à 4 GHz, cela signifierait que le cœur logique 1 tourne à 3,6 GHz tandis que les cœurs logiques 2, 3 et 4 tournent à 3,2 GHz. Vous constatez également que les processeurs 3 et 4 ont des cœurs qui sont entièrement « inactivés » et en état de sommeil. 

Figure 9 – Comprendre les états des processeurs

 

Pour forcer Windows à rester dans un état de performance spécifique, vous pouvez utiliser les mêmes valeurs maximales et minimales. Dans ce cas, Windows ne fixe pas la fréquence de fonctionnement du processeur. Il est important de souligner que le travail « affinitisé » du processeur réduit l'efficacité de cette fonction et nous vous invitons à bien réfléchir avant de configurer les paramètres d'affinité de traitement pour les applications.

Feuille de route pour les changements d'Active Directory

Les services ADFS (Active Directory Federation Services) de R2 possèdent de nombreuses fonctionnalités nouvelles. Lorsque vous utilisez R2 et que vous avez déployé le SE sur tous les contrôleurs de domaine de tous les domaines de votre forêt Active Directory, vos domaines peuvent opérer au niveau fonctionnel du domaine R2 et la forêt peut opérer au niveau fonctionnel de la forêt R2. Ces nouveaux niveaux opérationnels vous permettent de profiter des améliorations apportées à Active Directory en matière de gestion, de performance et de capacité de prise en charge.

L'une des améliorations les plus importantes est la Corbeille Active Directory. Cette fonction permet aux administrateurs d'annuler la suppression parfois malheureuse d'objets Active Directory. Lorsque vous activez la corbeille, tous les attributs à valeur de lien ou non d'un objet supprimé sont conservés, ce qui vous permet de restaurer l'objet dans l'état exact où il se trouvait avant sa suppression, sans avoir à initier de restauration faisant autorité. Cette approche diffère significativement des implémentations antérieures, où il fallait mettre en œuvre une restauration faisant autorité pour récupérer des objets supprimés. Précédemment, lorsque vous supprimiez un objet, la plupart de ses attributs non-à valeur de lien tous ses attributs à valeur de lien étaient supprimés, ce qui signifiait que même s'il était possible de récupérer un objet supprimé, celui-ci n'était pas restauré à son état antérieur.

Les comptes gérés constituent également un progrès. Les applications stratégiques utilisent souvent des comptes de service. Sur un ordinateur local, vous pouvez configurer les applications pour s'exécuter comme des comptes utilisateur intégrés, tels que Service local ou Système local. Toutefois, ces comptes sont partagés entre plusieurs applications et services et ne peuvent pas être gérés au niveau d'un domaine. Si vous configurez les applications pour utiliser des comptes de domaine, vous pouvez isoler les privilèges pour l'application, mais vous devez ensuite gérer manuellement les mots de passe du compte, ainsi que tous ses noms principaux de service (SPN) requis pour l'authentification Kerberos.

Pour réduire la charge de travail requise par la gestion des comptes de service, R2 prend en charge deux nouveaux types de comptes gérés :

  • Comptes de service gérés
  • Comptes virtuels gérés

Les comptes de service gérés sont un type particulier de compte d'utilisateur de domaine pour services gérés qui réduisent les interruptions et autres problèmes de service en faisant gérer le mot de passe et les SPN du compte par Windows. Les comptes virtuels gérés sont un type particulier de compte d'ordinateur local pour services gérés qui permettent d'accéder au réseau à l'aide d'une identité d'ordinateur dans un environnement de domaine.

Avec les comptes de service gérés, vous créez un vrai compte, qui est stocké par défaut dans l'UO Comptes de service gérés, dans Active Directory. Vous installez ensuite le compte de service géré sur un serveur local pour l'ajouter au compte en tant qu'utilisateur local. Enfin, vous configurez le service local pour qu'il utilise le compte.
Avec les comptes virtuels, vous configurez un service local pour accéder au réseau à l'aide d'une identité d'ordinateur dans un environnement de domaine. Étant donné que l'identité d'ordinateur est utilisée, aucun compte ne doit être créé et aucune gestion de mot de passe n'est requise.

R2 ne propose pas d'interface utilisateur pour créer et gérer ces comptes. Vous devrez utiliser le module Active Directory pour Windows PowerShell pour les gérer.
Avec R2, vous pouvez également tirer profit de nouveaux contrôles d'authentification. L'assurance du mécanisme d'authentification améliore le processus d'authentification en autorisant les administrateurs à contrôler l'accès aux ressources selon qu'un utilisateur se connecte à l'aide d'une méthode de connexion à base de certificat ou non. Un utilisateur peut recevoir un jeu d'autorisations d'accès lorsqu'il est connecté à l'aide d'une carte à puce, et un autre jeu lorsqu'il n'est pas connecté à l'aide d'une carte à puce.

Enfin, R2 rend possible d'effectuer des jonctions de domaine hors connexion, même si cette fonction ne requiert pas de hausser le niveau fonctionnel du domaine ou de la forêt. Avec une jonction de domaine hors connexion, les administrateurs peuvent préprovisionner des comptes d'ordinateur dans le domaine pour préparer les systèmes d'exploitation au déploiement. Les ordinateurs préprovisionnés peuvent ensuite joindre le domaine sans avoir à contacter un contrôleur de domaine. L'utilitaire de ligne de commande permettant de préprovisionner les comptes s'appelle Djoin.exe.

Présentation de la mise en cache de filiale

Windows BranchCache est une fonction de mise en cache de fichier qui fonctionne en collaboration avec le service de transfert intelligent d'arrière-plan (BITS). Dans un environnement de domaine où les ordinateurs de bureau exécutent Windows 7 et où les serveurs exécutent R2, les administrateurs peuvent activer la mise en cache de filiale pour permettre aux ordinateurs de bureau de récupérer des documents et d'autres types de fichiers du cache local plutôt que de serveurs à distance.
Étant donné que la mise en cache de filiale fonctionne avec des fichiers transférés avec HTTP et SMB (Server Message Block), les fichiers transitant par des serveurs Web intranet ou des serveurs de fichiers internes peuvent être mis en cache. À un niveau élémentaire, la mise en cache de filiale fonctionne de cette manière :

  1. Lorsque vous activez la mise en cache de filiale, la première fois qu'un fichier fait l'objet d'un accès depuis un site Web intranet ou un serveur de fichiers, Windows transfère le fichier depuis le serveur d'origine puis met le fichier dans un cache local, dans la filiale.
  2. Lorsque le même utilisateur ou qu'un autre utilisateur de la filiale accède ensuite au fichier, Windows recherche le fichier dans le cache local. S'il trouve le fichier, Windows interroge de serveur d'origine pour vérifier s'il a changé depuis sa mise en cache.
  3. Si le fichier n'a pas changé, Windows récupère le fichier dans le cache local, sans avoir à transférer le fichier à travers le réseau étendu. Si le fichier a changé, Windows le récupère dans le serveur d'origine et met à jour la copie du fichier dans le cache.

Vous pouvez configurer la mise en cache de filiale en mode distribué ou en mode hébergé. En mode distribué, les ordinateurs de bureau exécutant Windows 7 hébergent des caches de fichiers distribués. Un serveur de filiale n'est pas nécessaire car chaque ordinateur local met en cache et envoie des fichiers. En mode hébergé, un serveur exécutant R2, et situé dans les filiales, héberge le cache de fichier local. Le serveur met en cache les fichiers et les envoie aux clients. Comme vous pouvez vous y attendre, la mise en cache de filiale peuvent grandement améliorer les temps de réponse et réduire dans la même mesure les temps de transfert des documents, des pages Web et des contenus multimédia.

Synthèse

Et bien voilà. C'était ma présentation de Windows Server 2008 R2, des éditions existantes aux nouvelles fonctions et au-delà en passant par la visite à 5 dollars. J'espère que cette présentation vous aura intéressé et donné envie de découvrir mes prochains livres, « Windows PowerShell 2.0 Administrator's Pocket Consultant », « Windows 7 Administrator's Pocket Consultant » et « Windows Server 2008 Administrator's Pocket Consultant, 2nd Edition ».

 

William R. Stanek*(williamstanek.com) est un expert en technologie, un excellent formateur et un auteur reconnu et récompensé de plus de 100 ouvrages. Parmi ses livres actuels et à venir, citons les suivants : « Active Directory Administrator's Pocket Consultant », « Group Policy Administrator's Pocket Consultant », « Windows 7 Administrator's Pocket Consultant », « Windows PowerShell 2.0 Administrator's Pocket Consultant » et « Windows Server 2008 Inside Out ». Suivez Stanek sur Twitter à WilliamStanek.*