Services-RDS de Windows SERVER 2008 R2

Table des matières 1
S e r v i ce s R DS
Chapitre 1
Les architectures TSE en entreprise
1. Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Le concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Approche contextuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Une solution : les clients légers . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2. Principes technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Une communication simplifiée . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Une architecture centralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 La technologie MultiWin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Une logique de diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Le poste de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3. Bénéfices pour l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Fédérer la diversité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Réduction de la bande passante. . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Les sécurités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4. Champs d'application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Postes de travail bureautiques banalisés . . . . . . . . . . . . . . . . . . . 39
4.2 (Non) Renouvellement de parcs obsolètes . . . . . . . . . . . . . . . . . 40
4.3 Diffusion d'applications temps réel et sécurisées . . . . . . . . . . . . 42
4.4 Diffusion d'applications via le Web . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Interconnexion de sites distants . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6 Informatique en milieux hostiles. . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7 Postes nomades en 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5. Les principaux acteurs du marché . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Les éditeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Les constructeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Un peu d'histoire... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2 Services RDS
de Windows Server 2008 R2
6. Quelques idées reçues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.1 Un concept nouveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2 Un projet global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Un projet simpliste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Un projet centralisé, donc risqué. . . . . . . . . . . . . . . . . . . . . . . . . 59
6.5 Des serveurs centraux imposants . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapitre 2
Tour d'horizon de Windows 2008 R2
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.1 Amélioration du contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.2 Amélioration de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.3 Amélioration de la flexibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.4 Améliorations apportées par le Service Pack 1 . . . . . . . . . . . . . . 63
2. Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.2 Les différentes technologies de virtualisation. . . . . . . . . . . . . . . 65
2.3 Liste des fonctionnalités d'Hyper-V . . . . . . . . . . . . . . . . . . . . . . 72
2.3.1 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.3.2 Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.3.3 Performances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.3.4 Gestion simplifiée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.4 Allocation dynamique de la mémoire physique . . . . . . . . . . . . . 75
2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2.4.2 Pré-requis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.4.3 Principaux paramètres du gestionnaire Hyper-V . . . . . . . 79
2.4.4 Principaux paramètres de configuration des VM . . . . . . . 80
2.4.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.4.6 Recommandations pour les applications
Microsoft usuelles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.4.7 Réservation mémoire pour la partition parente . . . . . . . . 98
2.5 System Center Virtual Machine Manager (SCVMM) . . . . . . . . 99
3. Plate-forme d'application Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3.1 Outils de gestion améliorés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.2 Installation modulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.3 Modèle de configuration distribuée. . . . . . . . . . . . . . . . . . . . . . 104
3.4 Dépannage et diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.5 Déploiement simplifié des applications . . . . . . . . . . . . . . . . . . 105
4. Gestion des serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.1 Assistant de configuration Initial
(Initial Configuration Task ICT) . . . . . . . . . . . . . . . . . . . . . . . 106
4.2 Console d'administration du serveur (Server Manager). . . . . . 111
4.3 Administration du serveur en ligne de commande. . . . . . . . . . 112
4.4 Administration à distance Windows. . . . . . . . . . . . . . . . . . . . . 112
4.5 Windows PowerShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.6 Windows Server Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.7 Gestion de l'impression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5. Application de la stratégie et de la sécurité. . . . . . . . . . . . . . . . . . . . 118
5.1 Protection NAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.2 Fonctionnalités de sécurité avancée du pare-feu Windows . . . 124
5.3 Chiffrement de lecteur BitLocker . . . . . . . . . . . . . . . . . . . . . . . 125
5.4 Infrastructure à clefs publique (PKI) . . . . . . . . . . . . . . . . . . . . . 125
5.5 Cryptographie nouvelle génération (CNG) . . . . . . . . . . . . . . . 126
5.6 Contrôleurs de domaine en lecture seule . . . . . . . . . . . . . . . . . 126
5.7 Isolation de serveur et de domaine . . . . . . . . . . . . . . . . . . . . . . 127
6. Accès centralisé aux applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7. Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.1 Clusters de basculement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.2 Équilibrage de la charge réseau . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.3 Sauvegarde de Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8. Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.1 Nouvel assistant d'installation (Dcpromo) . . . . . . . . . . . . . . . . 135
8.2 Active Directory Domain Services (Service de domaine AD) . 141
4 Services RDS
9. Autres nouveautés ou améliorations. . . . . . . . . . . . . . . . . . . . . . . . . 160

9.1 Services de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
9.2 Explorateur de stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9.3 SMB 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
9.4 MPIO (Multi-Path Input Output) . . . . . . . . . . . . . . . . . . . . . . 168
9.5 iSCSI Initiator et iSNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . 170
9.6 Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
9.7 DirectAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
10.RDS 2008 R2 simple mise à jour ou véritable révolution . . . . . . . . 173
Chapitre 3
Services Bureau à distance 2008 R2
1. Client d'accès à distance version 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . 175
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
1.2 Nouvelles résolutions d'écran . . . . . . . . . . . . . . . . . . . . . . . . . . 176
1.3 Utilisation de plusieurs moniteurs (Multimon) . . . . . . . . . . . . 176
1.4 Support des polices ClearType . . . . . . . . . . . . . . . . . . . . . . . . . 178
1.5 Utilisation du client RDC 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 182
2. Expérience utilisateur enrichie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
2.1 Nouvel environnement visuel . . . . . . . . . . . . . . . . . . . . . . . . . . 189
2.2 Lecture audio/vidéo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
2.3 Flux audio bidirectionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
3. Authentification unique (Single Sign On) . . . . . . . . . . . . . . . . . . . . 199
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
3.2 Paramétrage du SSO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
4. Distribution d'applications transparentes (RemoteApp). . . . . . . . . 202
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
4.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5. Avancées technologiques du portail web (RD Web Access) . . . . . . 222
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.3 Utilisation du portail par les clients . . . . . . . . . . . . . . . . . . . . . 225

6. Impressions simplifiées (RD Easy Print) . . . . . . . . . . . . . . . . . . . . . . 226
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
6.2 Présentation de RD Easy Print. . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.3 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.4 Nouvelles stratégies de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . 230
7. Passerelle RDS 2008 R2 (RD Gateway). . . . . . . . . . . . . . . . . . . . . . . 232
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
7.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
7.3 Console de gestion de la passerelle RDS . . . . . . . . . . . . . . . . . . 238
8. Le nouveau Connection Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.2 Fonctionnalités disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
8.3 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
9. Virtualisation IP des services Bureau à distance
(RD IP Virtualization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
9.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
9.3 Configuration avancée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
10.Gestion des licences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
10.1 Rappel : la gestion de licences TSE 2003 . . . . . . . . . . . . . . . . . . 253
10.1.1 Gestion du type de CAL TSE . . . . . . . . . . . . . . . . . . . . . 260
10.1.2 Les périodes de fonctionnement global . . . . . . . . . . . . . 261
10.1.3 Gestion des CAL 2003 TSE par Utilisateur . . . . . . . . . . 262
10.1.4 Gestion des CAL 2003 TSE par périphérique/dispositif 263
10.2 Mise en œuvre dans le système d'information . . . . . . . . . . . . . 268
10.3 Gestionnaire de licences RDS 2008 R2 . . . . . . . . . . . . . . . . . . . 280
11.RemoteFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
11.1.1 Qu’est-ce que RemoteFX ? . . . . . . . . . . . . . . . . . . . . . . . 284
11.1.2 Qui est concerné par cette fonctionnalité ? . . . . . . . . . . 285
11.1.3 RemoteFX dans RDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
6 Services RDS
11.1.4 Quelles fonctionnalités RemoteFX fournit-il ? . . . . . . . 287

11.1.5 Quels paramètres ont été ajoutés ou modifiés ? . . . . . . 288
11.1.6 Éditions supportant RemoteFX ? . . . . . . . . . . . . . . . . . . 289
11.1.7 Comparaison des fonctionnalités disponibles
en mode RDVH/VDI et RDSH . . . . . . . . . . . . . . . . . . . 290
11.2 Installation de RemoteFX sur un serveur RDSH . . . . . . . . . . . 290
11.2.1 Pré-requis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
11.2.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Chapitre 4
Concepts avancés
1. Composants de Terminal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
1.1 Améliorations apportées au noyau . . . . . . . . . . . . . . . . . . . . . . 295
1.2 Isolation de la session 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
1.2.1 Les différents états des sessions. . . . . . . . . . . . . . . . . . . . 298
1.2.2 Terminal local ou distant. . . . . . . . . . . . . . . . . . . . . . . . . 299
1.2.3 Reconnexion de session . . . . . . . . . . . . . . . . . . . . . . . . . . 299
1.2.4 Option /console du client RDC. . . . . . . . . . . . . . . . . . . . 300
1.3 Support des polices ClearType . . . . . . . . . . . . . . . . . . . . . . . . . 301
1.4 Prioritisation de l'affichage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
1.5 Installation automatisée des services RDS . . . . . . . . . . . . . . . . 302
1.6 Certificats de passerelle RDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
1.6.1 Pré-requis pour les certificats de passerelle . . . . . . . . . . . 304
1.6.2 Comment obtenir un certificat pour sa passerelle SSL . 305
1.7 Partage de Session sous 2008 R2 (Session Sharing) . . . . . . . . . 305
1.8 Création de session en parallèle (Parallel Session Creation) . . 307
1.9 RDS ET WSRM (Windows System Resource Manager) . . . . . 308
2. Architecture réseau et haute disponibilité . . . . . . . . . . . . . . . . . . . . 309
2.1 Haute disponibilité basée sur le DNS . . . . . . . . . . . . . . . . . . . . 310
2.2 Haute disponibilité basée sur le DNS avec redirecteur dédié. . 312
2.3 Haute disponibilité avec redirecteurs dédiés et NLB . . . . . . . . 314

2.3.1 Pré-requis nécessaires pour l'utilisation
de Network Load Balancing . . . . . . . . . . . . . . . . . . . . . . . 316
2.3.2 Installation du NLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
2.3.3 Configuration du NLB . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
2.4 Haute disponibilité avec redirecteurs dédiés,
NLB et Connection Broker en cluster . . . . . . . . . . . . . . . . . . . . 317
3. Service d'annuaire et stratégies de groupes . . . . . . . . . . . . . . . . . . . . 319
3.1 Nouvelle infrastructure des GPO. . . . . . . . . . . . . . . . . . . . . . . . 319
3.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
3.1.2 Amélioration de la détection réseau . . . . . . . . . . . . . . . . 320
3.1.3 GPO locales multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
3.1.4 ADM vs ADMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
3.2 Console de gestion des stratégies de groupe . . . . . . . . . . . . . . . 326
3.3 Stratégies de groupe Windows 2008 R2 . . . . . . . . . . . . . . . . . . 327
4. Stratégies d'accès et sécurité du système . . . . . . . . . . . . . . . . . . . . . 354
4.1 Nouvelle version du noyau NT . . . . . . . . . . . . . . . . . . . . . . . . . 355
4.2 Restriction des comptes de services. . . . . . . . . . . . . . . . . . . . . . 355
4.3 Environnement d'exécution des programmes. . . . . . . . . . . . . . 356
4.4 Authentifications IPsec et support de NAP . . . . . . . . . . . . . . . 356
5. Gestion des impressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
6. Gestion des applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
7. PowerShell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
7.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
7.3 Règle de nommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
7.4 Exécution de Scripts Powershell . . . . . . . . . . . . . . . . . . . . . . . . 368
7.5 PowerShell et WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
8 Services RDS
Chapitre 5
Implémenter une architecture RDS 2008 R2
1. Méthodologie globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
1.1 Phases du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
1.2 Détail des phases clés du projet . . . . . . . . . . . . . . . . . . . . . . . . . 379
2. Méthodologie spécifique à RDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
2.1 Spécificités au niveau des phases du projet . . . . . . . . . . . . . . . 384
2.2 Conduite du changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
3. Le choix de l'architecture réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
3.1 Le couple RDS/RDP et les performances réseaux. . . . . . . . . . . 388
3.1.1 Les composantes de la performance réseau
selon RDS/RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
3.1.2 Consommation RDS/RDP de la bande passante . . . . . . 393
3.1.3 Consommation RDP avec RemoteFX . . . . . . . . . . . . . . . 396
3.2 Évaluation du besoin en bande passante. . . . . . . . . . . . . . . . . . 401
3.2.1 En fonction des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 401
3.2.2 En fonction du positionnement des serveurs . . . . . . . . . 403
3.3 Besoin en bande passante et besoin de sécurisation. . . . . . . . . 414
4. Le calibrage des serveurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
4.1 Considérations d'ensemble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
4.1.1 Impact des applications . . . . . . . . . . . . . . . . . . . . . . . . . . 418
4.1.2 Impact des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
4.1.3 Un gros serveur ou plusieurs petits ? . . . . . . . . . . . . . . . 423
4.2 Le choix des composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
4.2.1 Le(s) processeur(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
4.2.2 La mémoire RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
4.2.3 Le(s) disque(s) dur(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
4.3 Les redondances possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
4.3.1 Le sous-système disque . . . . . . . . . . . . . . . . . . . . . . . . . . 431
4.3.2 L'alimentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
4.3.3 Les cartes réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
4.4 Les architectures alternatives. . . . . . . . . . . . . . . . . . . . . . . . . . . 434

4.4.1 Les serveurs lames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
4.4.2 Les architectures virtuelles. . . . . . . . . . . . . . . . . . . . . . . . 435
4.4.3 Les architectures 64 bits . . . . . . . . . . . . . . . . . . . . . . . . . . 435
4.5 Le plan de montée en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
5. Aller plus loin avec le VDI (RD Virtualization Host) . . . . . . . . . . . 439
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
5.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
5.3 Paramètres avancés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
5.4 Mise en œuvre de RemoteFX sur un serveur RDVH . . . . . . . . 465
5.4.1 Pré-requis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
5.4.2 Paramétrage de l’hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
5.4.3 Ajouter une carte vidéo 3D RemoteFX
à une machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . 468
5.4.4 Prise en charge de RemoteFX depuis un poste client . . . 477
5.5 Installation et paramétrages de la redirection USB
avec RemoteFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
5.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
5.5.2 Périphériques supportés . . . . . . . . . . . . . . . . . . . . . . . . . . 485
5.5.3 Comparaison entre USB RemoteFX et High-Level RDP 486
5.5.4 Schéma de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . 486
5.5.5 Configuration côté « client » . . . . . . . . . . . . . . . . . . . . . . 487
5.5.6 Validation du fonctionnement
pour différents périphériques. . . . . . . . . . . . . . . . . . . . . . 489
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Services RDS de Windows Server 2008
R2
Architecture et implémentation [2ième édition]
Hervann ALLEGRE Yann BOUVIER Cédric Ortega
Résumé
Ce livre sur les services RDS (Remote Desktop Services) de Windows Server 2008 R2 s’adresse à des responsables informatiques sur le point
de s’engager dans la mise en œuvre d’une solution clients légers, aussi bien qu’à des informaticiens confrontés à l’installation et à
l’administration de cette architecture en entreprise.
Désormais appelés Remote Desktop Services, les Terminal Services de Windows Server 2008 R2 font partie intégrante de toutes les nouvelles
architectures des systèmes d’informations des entreprises, de la simple PME aux plus grands groupes. Les auteurs ont réussi à synthétiser les
possibilités apportées dès l'origine par les architectures TSE/RDS, afin que le lecteur puisse s’engager dans ce type de projet en toute
connaissance de cause et maîtriser son intégration.
Les premiers chapitres détaillent les architectures clients légers en entreprise (concept, principes technologiques, bénéfices pour
l’entreprise...) ainsi que les particularités de la solution RDS (composants de la solution, système de licences...). Les chapitres suivants
décrivent les fonctionnalités globales offertes par Windows Server 2008 R2, les spécificités applicables aux services RDS et VDI ainsi qu’une
méthodologie d’implémentation (choix de l’architecture réseau, calibrage des serveurs...) permettant aux lecteurs d'entamer sereinement leurs
projets.
Cette nouvelle édition du livre présente également les nouveautés offertes par le Service Pack 1 de Windows Server 2008 R2, telles la mémoire
dynamique ou encore RemoteFX. L’ensemble de ces nouveautés contribuera à améliorer encore l’expérience utilisateur et ouvrira, à n’en pas
douter, de nouvelles perspectives dans la mise en œuvre d’infrastructures VDI.
Les chapitres du livre :

Avant-propos - Les architectures TSE en entreprise – Tour d’horizon de Windows 2008 R2 – Services Bureau à distance 2008 R2 – Concepts
avancés – Implémenter une architecture RDS 2008 R2
L'auteur
Professionnel de l’informatique depuis 10 ans, Hervann ALLEGRE a successivement exercé comme responsable informatique dans une
PME puis en tant qu’ingénieur système spécialisé dans les architectures Active Directory et Clients Légers pour des grands comptes. Sa forte
expérience terrain apporte un éclairage technique très pertinent sur les principes d'architectures présentés dans ce livre. Certifié Windows
Server 2003 et MCITP Entreprise and Server Administrator sur Windows Server 2008, il exerce aujourd'hui en tant que directeur technique
spécialiste des solutions Microsoft.
Ingénieur Système spécialisé en environnements Microsoft, Yann BOUVIER assure la gestion et le suivi de projets d’intégration de solutions
complètes et complexes autour des technologies Microsoft. Ses interventions le placent au plus près des clients et de leurs besoins et lui
permettent d’apporter au livre des retours d’expérience significatifs.
Professionnel de l'informatique depuis plus de 15 ans, Cédric ORTEGA est consultant en Architectures Microsoft avec spécialisation clients
légers (environ 250 projets gérés de 20 à 9.500 postes). Enseignant en Organisation des Systèmes d'Informations, il rassemble dans cet
ouvrage toute son expérience autant technique que pédagogique sur les architectures clients légers et comble ainsi le manque
d'informations sur ce sujet et particulièrement sur la solution TSE/RDS.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI
Ce livre numérique intègre plusieurs mesures de protection dont un marquage lié à votre identifiant visible sur les principales images.
© ENI Editions - All rights reserved - adamo diarra - 1-

Avantpropos
Les systèmes d’information d’aujourd’hui sont en perpétuel mouvement. Leur évolution constante, de l’éclatement
des services à la mutualisation de ceuxci, conduit à une tendance que tous les acteurs du marché s’entendent à
suivre : la consolidation.
Les outils se multiplient : de la simple cohabitation des rôles au complexe et évolué Cloud Computing, il devient
vite compliqué pour les responsables informatiques de définir une stratégie claire, de la mener à bien et de s’y
tenir jusqu’au bout.
Cet ouvrage a pour objectif de mettre en avant les possibilités offertes par les services Bureau à distance de
Microsoft, appelés Terminal Services (TSE) jusqu’à la version Windows Server 2008 puis Remote Desktop Services
(RDS) depuis la version 2008 R2 de Windows Server.
Au terme de sa lecture, vous aurez toutes les cartes en main pour décider si ces solutions sont en corrélation avec
votre stratégie d’évolution, et il vous fournit également tous les outils dont vous aurez besoin en vue de
l’intégration de ces services
L’écriture de cet ouvrage a été réalisée en collaboration avec plusieurs auteurs, ayant chacun des aptitudes et
compétences dans leur domaine respectif. Cédric ORTEGA apportera les réponses aux attentes d’un responsable
de service informatique. Hervann ALLEGRE et Yann BOUVIER sauront orienter et conseiller au mieux l’architecte
responsable du design et de la définition de la solution, mais aussi apporter toute leur expérience, acquise au fil
de l’intégration d’infrastructures complexes, aux administrateurs et intégrateurs.
Le livre peut être lu afin d’acquérir de bonnes connaissances théoriques sur les technologies RDS. Cependant, afin
d’en tirer le meilleur profit, nous ne saurions trop vous recommander l’utilisation d’un laboratoire intégrant un
domaine Active Directory fictif afin de procéder à la mise en œ uvre des différentes fonctionnalités décrites tout au
long de ces pages. La virtualisation de serveurs vous sera d’une aide certaine, notamment avec ses possibilités de
sauvegarde et restauration d’états antérieurs afin de simuler plusieurs scénarios ou réparer toute erreur de
manipulation.
Pour les lecteurs aguerris sur les technologies RDS, l’index du livre permet de trouver et d’accéder rapidement à
l’information souhaitée ou aux chapitres correspondant aux nouveautés apportées par le Service Pack 1. Pour les
autres, l’ouvrage doit être lu dans son intégralité, la difficulté allant crescendo : généralités sur les technologies
Terminal Services en entreprise, services apportés par Microsoft Windows 2008 R2, les services RDS (Bureau à
distance) en particulier, puis les concepts et modes de fonctionnement avancés, pour enfin implémenter son
infrastructure et aller plus loin avec VDI (Virtual Desktop Infrastructure).

Présentation
1. Le concept
Quand Terminal Server, communément appelé "TSE", et désormais appelé « RDS » pour Remote Desktop Services
est activé sur un serveur Windows 2008 R2, les utilisateurs autorisés peuvent se connecter à un véritable
"bureau virtuel". Les applications de l’utilisateur sont alors exécutées à 100 % sur le serveur au lieu de l’être
habituellement sur le poste local, et seul l’écran (comprendre l’image) du bureau virtuel de l’utilisateur est
transmis via le réseau. Conceptuellement, on peut assimiler le résultat visuel obtenu à des applications de prise
de contrôle à distance comme PCAnywhere à son époque ou VNC (ces produits ne sont toutefois pas du tout
équivalents à la solution TSE, et ne délivrent pas du tout les mêmes services aux utilisateurs).
Le composant RDS de Windows Server 2008 R2 autorise l’accès de clients distants aux applications et au bureau
complet du serveur. Ces clients distants peuvent fonctionner sous Windows, Mac OS, certains Unix ou Linux, et
peuvent être aussi bien des postes type PC, MAC, portables, PDA, tablettes tactiles que des terminaux passifs.
Ils accèdent au serveur via une connexion TCP/IP s’appuyant sur un LAN (Local Area Network), un WAN (Wide Area
Network) ou même Internet.
Dans ce mode de fonctionnement, Windows Server 2008 R2 utilise un noyau système (kernel) spécifiquement
modifié pour autoriser de multiples utilisateurs à se connecter simultanément au même serveur, et à utiliser les
mêmes applications, chacun d’eux utilisant son propre et unique bureau virtuel. Un même serveur peut alors
supporter des dizaines, voire des centaines d’utilisateurs simultanés. Les techniques d’équilibrage de charge
permettent à différents serveurs de se répartir le nombre d’utilisateurs, et ainsi d’accepter des centaines voire
des milliers d’utilisateurs.
Les applications distantes qui tournent au sein d’un bureau virtuel RDS Windows Server 2008 R2 ont la capacité
d’accéder et/ou d’interagir avec les applications installées localement sur le poste de l’utilisateur. Ces
applications locales et distantes peuvent partager des espaces disques, des lecteurs, des ports (série, parallèle,
audio, USB, etc.) ou encore le Pressepapiers (fonction copiercoller).
Il est courant de voir les administrateurs paramétrer des postes de travail pour accéder en partie à des
applications installées localement sur le système d’exploitation du poste, et pour autre partie à des applications
distantes, c’estàdire hébergées sur un serveur RDS. Ces dernières peuvent être diffusées auprès de
l’utilisateur soit via un bureau virtuel complet, soit directement sans le bureau Windows (approche mono
applicative, souvent appelée "application transparente" ou "seamless" en anglais).
2. Approche contextuelle
Bien avant que ne soient connues et répandues les solutions clients légers et Terminal Server, il y eut une
période riche en apprentissages de toutes sortes, techniques ou stratégiques, qui préfigura beaucoup de ce que
nous pouvons constater désormais.
Il faut, tout d’abord, remonter dans les années 19601970, pour constater que l’informatique en entreprise à
cette époque était, certes, balbutiante dans beaucoup de PMEPMI et souvent réservée à une élite ou à
quelques services restreints de l’entreprise, mais surtout qu’elle répondait à une logique centralisée, basée sur
des mainframes associés à des terminaux passifs (souvent appelés "postes de saisie" et manipulés par des
"opérateurs de saisie").
Cette ère connut son heure de gloire, et à juste titre si l’on considère que cette informatique centralisée à
tendance fortement propriétaire était certes coûteuse, mais fiable, administrée efficacement par des services
informatiques toutpuissants et, au final, rendait de bons et loyaux services à l’entreprise pour un retour sur
investissement facilement identifiable. Il n’est pas rare de croiser encore aujourd’hui certaines entreprises ou
administrations maintenant avec succès de tels systèmes ! En moyenne, ces architectures avaient une durée de
vie moyenne oscillant entre 8 et plus de 20 ans !
Puis ce fut l’avènement du poste puissant, type MAC ou PC, qui améliora de façon dantesque l’ergonomie de
l’interface hommemachine et se coupla avec une logique de décentralisation des applications et du traitement.
L’évolution des réseaux et d’Internet consacra en fin de siècle l’hétérogénéité des systèmes d’informations de
l’entreprise.

Dès lors, le responsable informatique ou le directeur des systèmes d’informations fut confronté à une
problématique qui s’apparente plus à la quadrature du cercle qu’à une approche binaire bien connue : concilier
budgets, fonctionnalités, disponibilité et performances.
La problématique de l’entreprise
Il n’est nul besoin de considérer une multinationale pour rencontrer cette problématique informatique, que l’on
peut qualifier de générique : il suffit de la pondérer légèrement d’une entreprise à l’autre pour se reconnaître
rapidement.
D’une manière globale, il est demandé à l’informatique et à son service :
● De mettre en œ uvre des solutions techniques modernes et efficaces.
■ Respectant les contraintes fonctionnelles et métiers de l’entreprise.
■ De plus en plus ouvertes, accessibles et souvent orientées web.
■ Répondant à des besoins en nomadisme toujours croissants.
● D’en assurer l’exploitation quotidienne.
■ Malgré les contraintes liées à la diversité des applications (versions, langages, prérequis...), des
postes de travail (PC, MAC, stations Unix, portables, PDA, téléphones...), et de l’entreprise elle
même (sites distants, filiales sous ou hors contrôle, groupes, personnels itinérants,
télétravailleurs...).
■ Malgré les contraintes liées à certaines tâches d’administration (gestion des déploiements et des
mises à jour, suivi des versions, dépannages matériels et systèmes, migrations...).
● D’en assurer la sécurité.
■ Classique par des solutions de sauvegarde adaptées.
■ Face aux menaces extérieures : virus, vers, piratage...
■ Face à la duplication ou fuite des données : postes itinérants, BDD synchronisées...
■ Face aux "menaces" internes : fausses manipulations, installations et paramétrages "sauvages"...
● De fournir des solutions toujours plus performantes ou, a minima, pas moins.
■ Malgré des réseaux WAN à faible bande passante.
■ Malgré une augmentation régulière du trafic réseau et des connexions distantes en plus grand
nombre.
■ Malgré des applications de plus en plus gourmandes.
Le tout, en réduisant au maximum les coûts.
Le TCO
TCO signifie Total Cost of Ownership, dont la traduction française peut être "Coût Total de Possession" du
système d’informations. Comme un logiciel n’est pas réellement possédé, mais plutôt son usage autorisé sous
licence, le « Coût Total d’Utilisation » est souvent considéré comme un terme plus approprié.
L’objectif est de savoir combien coûte réellement le système d’informations à l’entreprise, dans sa globalité. En
effet, bien des responsables informatiques n’ont pas une idée précise de ce que coûte l’informatique à leur
entreprise. De nombreux cabinets de consulting proposent des services d’évaluation du TCO informatique pour
- 2- © ENI Editions - All rights reserved - adamo diarra

une entreprise mais, bien qu’elle reste difficile, prise dans sa globalité (moyenne d’entreprises très significatives),
une évaluation générique du TCO reste possible.
Reprenons ici une source externe d’évaluation (IDC/Interpose), que nous commenterons par la suite afin de
mieux cerner les composantes budgétaires et donc les centres de coûts informatiques en entreprise, sur lesquels
les solutions clients légers doivent apporter des leviers. L’étude considérée date de 2001 et porte sur les 500
plus grandes entreprises américaines, sur cinq ans mais rapportée à un an. Elle est certes ancienne, mais son
analyse reste d’actualité.
TCO en 2001 des 500 premières entreprises aux USA
Le TCO se décompose en deux catégories distinctes :
● Les coûts directs : généralement bien appréhendés car facilement identifiables en entreprise.
● Les coûts indirects ou cachés : plus difficiles à identifier car moins sensitifs, ces coûts pourtant
significatifs sont généralement purement et simplement oubliés.
Commentaires sur les coûts directs
Poste "Matériels & Logiciels"
Ce poste correspond simplement aux achats de matériels ou logiciels. Il est intéressant de
considérer que les achats ne représentent qu’un dixième du TCO ! Par exemple, lorsque l’entreprise
achète pour 11.000 euros de matériels et logiciels, elle engage en fait 100 000 euros de dépenses !
Poste "Administration"
Nous trouvons ici la masse salariale du service informatique (hors équipes de développement), ainsi
que le montant des prestations externes (SSII...) liées à l’intégration des matériels et logiciels
achetés et à l’administration courante des infrastructures (serveurs, réseaux...). Ce poste est bien
souvent ignoré par la DSI, car s’il est non négligeable, toute réduction se traduit souvent par une
baisse des effectifs, non souhaitée par la DSI comme par le(s) intéressé(s) !
Poste "Développement"

Ce poste varie fortement d’une entreprise à l’autre. En effet, si l’entreprise utilise des logiciels du
marché, on ne trouve ici que le montant des prestations de développement complémentaires, les
licences comptant dans "matériels & logiciels" et l’intégration dans "administration". Si, au contraire,
elle développe des spécifiques en interne ou via prestataire, on trouve alors, soit la masse salariale
des équipes de développement, soit le montant des prestations. Le pourcentage moyen de 6 % est
donc à utiliser précautionneusement.
Poste "Support"
On y trouve pêlemêle les contrats de maintenance, les extensions de garantie, la masse salariale
ou le montant des prestations des équipes de HelpDesk (assistance utilisateurs) et de SAV, ainsi
que l’intégralité des formations informatiques (pour le service informatique comme pour les
utilisateurs). On comprend dès lors le poids de près d’un quart du TCO de ce poste. Concernant la
considération de la masse salariale dans ce poste, ma remarque est la même que pour le poste «
administration » : elle est souvent passée sous silence...
Poste "Communication"
De modique, ce poste est passé à significatif avec l’essor des technologies Internet et des
connexions intersites distants, sans toutefois dépasser les 5 à 8 % selon les entreprises. Il tend à
revenir sous la barre des 5 % avec l’avènement des technologies xDSL forfaitaires et moins
coûteuses. Il reste à pondérer selon les entreprises.
Commentaires sur les coûts indirects ou cachés
Poste "Temps Utilisateurs"
C’est l’archétype de la publicité IBM "Ça imprime pas !". Un problème informatique et c’est un
utilisateur qui ne travaille plus ou mal, qui en dérange un autre pour se faire aider et puis
finalement, c’est tout un service... Le temps utilisateur est difficile à évaluer mais bien réel. Plus les
utilisateurs perdent du temps à gérer leur informatique locale, plus l’entreprise perd de l’argent. Un
poste "Temps Utilisateurs" faible est souvent synonyme d’un poste "Support" important. Une bonne
formation et un service HelpDesk œ uvrent en ce sens mais sont également coûteux : il ne s’agit
dès lors que d’un déplacement de centre de coût... Bien sûr, cette orientation reste toutefois
avantageuse sur le moyen, voire long terme !
Poste "Indisponibilité"
Très rare mais très coûteux en cas de survenance, l’indisponibilité touche un organe vital du
système d’informations : un serveur, le réseau, une application métier... Considérer ce poste à 0 %
simplement parce qu’il n’y a pas eu de problèmes depuis longtemps est une grossière erreur : cela
ne met pas à l’abri pour l’année à venir. Afin d’anticiper ou d’éviter une telle situation, ce sont les
postes "matériels & logiciels" et les postes "administration" qui voient leurs proportions augmenter.
Globalement, il faut considérer le TCO comme une réalité perceptible, certes chiffrable, mais dont la simple (re)
connaissance peut permettre de ne pas s’engager sur des solutions techniques inadaptées du point de vue
financier et à long terme pour l’entreprise.
Nous laissons à votre appréciation le résultat d’études TCO combinées de grands cabinets, qui pour une fois,
semblent d’accord...

3. Une solution : les clients légers
Sans affirmer qu’il s’agit de la solution miracle, il reste assez évident que les architectures clients légers, et
particulièrement celles basées sur RDS, apportent beaucoup d’avantages à l’entreprise, tant en termes
techniques que financiers.
Du point de vue du TCO, les architectures clients légers agissent directement et principalement sur les postes
suivants :
Le simple principe architectural permet de comprendre pourquoi le TCO est directement et positivement impacté

par les solutions RDS. En effet, si l’on considère une architecture centralisée et homogène, on facilite grandement
l’administration et toutes les tâches de support, tout en augmentant l’efficacité des utilisateurs.
L’impact sur le poste achat "matériels & logiciels" est moindre, mais existe néanmoins malgré la baisse
significative du coût d’un poste type PC. Elle s’exprime essentiellement par la nonobsolescence sous 5 ans de
postes de type terminaux, et donc la nonnécessité de réinvestir à terme dans les postes de travail.
Enfin, les autres postes peuvent aussi être améliorés au cas par cas, ce que vous pourrez découvrir via les
champs d’applications des solutions clients légers (cette partie sera développée ultérieurement dans le chapitre).
L’indisponibilité n’est pas accrue, mais le risque oui : c’est une conséquence logique de la centralisation et bien
des solutions, souvent connues et maîtrisées par le service informatique, sont disponibles pour contenir ce risque
puis le réduire.
En résumé, on peut considérer que les architectures clients légers vont permettre à l’entreprise de revenir d’une
informatique hétérogène, complexe et coûteuse, à une informatique centralisée, banalisée et pérenne, tout en :
● respectant les contraintes liées aux applications modernes (NTIC, bureautique avancée, PGI/ERP,
émulations texte...) ;
● facilitant l’administration du parc ;
● augmentant la disponibilité des outils ;
● réduisant les coûts par simple homogénéisation ;
● pérennisant les investissements passés et futurs.

Principes technologiques
1. Une communication simplifiée
Le principe technologique est très simple et loin d’être novateur. Le serveur génère l’image de l’interface
utilisateur, compresse cette image et l’envoie au poste de travail qui la décompresse et l’affiche à l’écran. Dans
l’autre sens, l’utilisateur interagit et les frappes clavier ou mouvements de la souris sont retournés au serveur.
Pour être plus précis, la communication du serveur vers le poste de travail se résume au seul rafraîchissement de
l’image compressée. En clair : si l’utilisateur ne fait que lire un document statique (par exemple un document
Word), alors rien ne change visuellement, donc rien n’est échangé entre le serveur et le client (hormis quelques
trames de contrôle de connexion). Si, par contre, l’utilisateur bouge la souris, alors n’est rafraîchie que la portion
d’image qui correspond au mouvement de la souris, soit un trait plus ou moins conséquent, mais qui reste très
modique par rapport à la proportion de l’écran qui n’a pas changé.
On perçoit immédiatement que la communication maximale entre un serveur RDS et un poste de travail
correspond, en fait, au rafraîchissement de l’intégralité de la surface de l’écran visible, par exemple, lors d’une
bascule entre deux applications (par le raccourci [Alt][Tab] par exemple). On ressent aussi que la limite du
système est atteinte dès que l’on cherche à visualiser une vidéo en mode plein écran : à 24 images par seconde,
le rafraîchissement est intégral et très fréquent (il serait plus judicieux de dire trop). Et pourtant, les nouvelles
avancées protocolaires (RDP version 7) tendent à effacer quasi complètement ces contraintes !
A contrario, le poste de travail se contente de remonter les événements clavier et souris au serveur afin que
celuici puisse tenir compte des requêtes de l’utilisateur, générer l’image associée et l’envoyer à l’utilisateur afin
qu’il la visualise. Cet allerretour est parfois ressenti par l’utilisateur sous forme de saccades et/ou de décalages
à l’affichage, dans des configurations souscalibrées ou des réseaux à trop faible bande passante.
Cette communication entre le serveur RDS et le poste de travail est prise en charge par un protocole que l’on
peut grossièrement qualifier de "graphique" plutôt que "réseau". Il existe essentiellement trois protocoles
concurrents : le protocole ICA de l’éditeur CITRIX, le protocole AIP de l’éditeur SUN et le protocole RDP de
l’éditeur MICROSOFT, objet particulier de ce livre.
RDP signifie Remote Desktop Protocol. Il est souvent confondu avec RDS, qui signifie Remote Desktop Services, ce
qui ne peut et surtout ne doit pourtant pas être un synonyme, même abusif, comme il sera expliqué plus loin
dans le chapitre.
D’autres protocoles similaires, mais non directement concurrents car ne portant pas sur des environnements
serveurs Microsoft Windows, peuvent être identifiés. C’est notamment le cas du protocole X11 dans le monde
Unix et Linux, historiquement précurseur mais très gourmand en ressources (bande passante notamment). Cette
remarque pour souligner que l’approche technologique protocolaire n’est pas nouvelle, mais correspond plus à
un retour aux sources amélioré.

2. Une architecture centralisée
Compte tenu du principe technologique, les applications sont installées et exécutées directement sur et depuis le
serveur : seule l’image est transmise et affichée sur le poste utilisateur.
La centralisation est donc réelle et il convient de qualifier le poste de l’utilisateur de simple poste de travail. Le
terme "terminal passif" répond mieux à la réalité puisqu’il ne fait rien d’autre qu’afficher et renvoyer les
évènements du clavier et de la souris. Il ne faut pas considérer le qualificatif "passif" comme péjoratif.
En fait, il faut réaliser que le concept est resté le même qu’avant, mais que c’est simplement le protocole de
communication graphique qui a changé, et surtout le serveur et ses capacités fonctionnelles. Même si le poste de
travail est un réel poste puissant type PC, il devient, dès qu’il utilise les protocoles ICA ou RDP, un simple
terminal passif.
Il est évident que, du point de vue de l’entreprise, la solution globalement centralisée ne sera effective qu’à la
condition expresse que plusieurs postes puissent utiliser le même serveur.
3. La technologie MultiWin
Les serveurs de type Windows RDS ont les caractéristiques suivantes :
● Ils sont multisessions : ils permettent d’ouvrir plusieurs sessions simultanément. Bien qu’ils aient
toujours eu la capacité de partager des ressources (fichiers, imprimantes, services...), seul un
administrateur à la fois pouvait se connecter à un serveur Windows en mode console (directement sur le

clavier du serveur). La capacité du système à être multisessions permet désormais de connecter
différentes occurrences de bureaux Windows sans nécessairement en être administrateur. La
particularité de la version Windows 2008 R2 RDS est qu’un administrateur n’utilise désormais plus de
session « console », mais une session banale comme les autres utilisateurs.
● Ils sont multiutilisateurs : ils permettent de connecter et gérer simultanément plusieurs utilisateurs aux
différentes sessions ouvertes. En clair, l’utilisateur 1 peut se connecter à la session 1 pour travailler avec
l’application 1, en même temps que l’utilisateur 2 peut se connecter à la session 2 pour utiliser
l’application 2, voire la 1 aussi et en même temps.
Ces deux capacités (multisessions et multiutilisateurs) forment ce que l’on appelle la technologie MultiWin, dont
toute architecture client léger a besoin pour fonctionner, et qui rassemble 80 % des fonctionnalités inhérentes à
ce type de solution.
Globalement, cela permet de mettre à disposition une seule occurrence d’une application installée sur un seul
serveur à x personnes qui vont pouvoir travailler en simultané.
D’autres systèmes furent ou sont multisessions et multiutilisateurs, à commencer par l’ensemble des Unix, mais
aussi en son temps Prolog ou d’autres. La différence essentielle tient dans la mise à disposition d’un protocole
graphique performant et peu gourmand en vue de déploiements de masse.
4. Une logique de diffusion
Bien que le client initie la demande de connexion au serveur RDS, il est philosophiquement plus juste de
considérer la logique de diffusion des images depuis le serveur vers les postes clients.
Le serveur RDS est alors positionné comme un "Frontal de diffusion", qui met à disposition de tout type de
postes clients, via tout réseau TCP/IP, l’ensemble des applications ou services serveurs de l’entreprise qui sont
alors "diffusés" sous forme de rafraîchissement d’image compressée voire cryptée.
Les applications considérées peuvent être de tout type, et pas nécessairement basées sur Windows ou I386. En
effet, sur le serveur RDS frontal de diffusion, il ne peut y avoir que des applications basées Windows 32 ou 64
bits, mais les serveurs de backoffice ou applicatifs peuvent fonctionner sous tout système : AS400/OS400, Unix,
systèmes propriétaires, etc. En effet, c’est la partie cliente de ces serveurs applicatifs qui sera installée sur le

serveur RDS, en l’occurrence et le plus souvent une émulation au format Windows 32 bits (par exemple, une
émulation cliente 5250 type Client Access pour Windows afin d’accéder au serveur AS400). Il peut en être de
même pour un navigateur Internet.
La communication protocolaire ICA ou RDP s’appuie sur TCP/IP, ce qui ouvre un panel de possibilités de plus en
plus étendu en ce qui concerne les réseaux supportés. La combinaison avec des technologies de réseau privé
virtuel ou VPN est possible voire conseillée : les protocoles ICA ou RDP sont alors encapsulés dans le tunnel. Bien
que les solutions à faible bande passante soient supportées, attention toutefois aux connexions type GSM, le
GPRS ou mieux la 3G restant vivement conseillés.
Il est possible de diffuser en RDP (via RDS) :
● Soit un "bureau Windows virtuel complet", c’estàdire que l’utilisateur dispose d’un environnement
Windows classique et complet, comportant tous les accessoires et applicatifs installés sur le serveur
(sous réserve de droits d’exécution appropriés pour les applications).
● Soit une "monoapplication", c’estàdire qu’au sein d’un poste de travail classique de type PC ou autre,
une icône pointe vers une application non pas locale, mais diffusée en RDP ou ICA depuis un serveur
RDS. Cette diffusion est aussi appelée application transparente ou seamless.
Le poste client qui permettra d’interpréter les protocoles ICA ou RDP, et donc d’afficher les images et d’échanger
avec le serveur, est quant à lui quasi universel.
5. Le poste de travail
Les postes de travail "puissants"
De type PC, MAC ou autre, le poste de travail dit "puissant" est réduit à sa plus simple expression dès qu’il
fonctionne en mode client léger, c’estàdire connecté à un serveur RDS. Son intérêt demeure toutefois,
notamment si l’on souhaite tirer la quintessence des technologies apportées par RDS et RDP v7 sur plateforme
Windows 2008 R2.
Le client protocolaire se présente comme un très petit logiciel qui s’installe localement sur le poste de travail et
qui permet d’établir la communication avec le serveur RDS. Il existe sous de nombreuses formes qui lui
permettent de fonctionner sous différents systèmes d’exploitation ou navigateurs :
● Logiciel : Remote Desktop Connection , Rdesktop , ApplidisSeamless client ICA
● Plugin : contrôle ActiveX RDS, plugin Java HobJWT
L’usage de postes puissants en tant que clients d’une architecture clients légers s’avère fréquent dans les cas
suivants :
● Les utilisateurs ont besoin d’utiliser des applications locales, spécifiques, gourmandes en ressources ou
dangereuses si centralisées (par exemple des applications de développement ou des applications de
CAO/DAO), mais aussi quelques applications centralisées hébergées sur des serveurs RDS. C’est un
mode de fonctionnement mixte assez courant. Toutefois, ces postes spécifiques tendent à s’orienter
vers un nouveau type d’architecture virtuelle basée sur les protocoles client légers : le VDI, présenté
dans le chapitre Implémenter une architecture RDS 2008 R2 Aller plus loin avec VDI (RD Virtualization
Host).
● Les utilisateurs travaillent sur un environnement Unix ou Mac, par exemple, mais doivent accéder en
parallèle à des applications Windows. Cela permet d’éviter d’avoir 2 ou 3 ordinateurs sur le même
bureau.
● L’entreprise est propriétaire de son parc de postes de travail. Ce dernier, vieillissant ou pas, n’est plus
suffisamment performant pour répondre aux besoins/contraintes de nouveaux usages ou de nouvelles
applications. Il est cependant financièrement très intéressant de conserver ces postes et de les
transformer en simples postes clients RDS : ils trouveront une seconde jeunesse (sur le plan des
performances ce sont celles du serveur qui seront désormais ressenties par les utilisateurs), voire une

seconde vie (n’étant plus que très faiblement sollicités, la probabilité de panne baisse de façon
importante).
Les terminaux passifs
Les terminaux passifs constituent le poste client léger par excellence mais ne sont pas une nécessité technique.
Ils se présentent sous différentes formes : terminal indépendant à associer avec un écran traditionnel, écran plat
avec terminal intégré directement dans le socle de l’écran, tablette tactile, etc.
Un terminal est dit passif car son rôle est réduit au strict minimum dans une architecture RDS : il se contente de
gérer la communication protocolaire avec le serveur et n’exécute pas les applications manipulées par l’utilisateur.
C’est un poste de travail simplifié au maximum qui comporte un système d’exploitation relativement fermé, voire
propriétaire, installé sur une mémoire permanente du poste. Il n’est pas possible de l’utiliser en tant que tel, ni
de le modifier (hormis quelques paramètres laissés à la discrétion de l’administrateur), il est uniquement possible
se connecter à un (ou plusieurs) serveur(s) RDS (ou autres).
Ce type de postes remplace avantageusement les postes dits puissants car il finalise la démarche de
centralisation du système d’informations en banalisant le poste de l’utilisateur.
Leur simplicité les rend fiables sur le long terme (8 à 10 ans), la quantité de protocoles de communication
intégrés et gérés les rendant plus ou moins universels.
Attention aux postes « hybrides », dont l’aspect terminal est avéré (présentation ergonomique du capot), mais
dont le contenu cache un système d’exploitation puissant, embarqué le plus souvent en mémoire flash, donc
personnalisable dans les limites de cette même mémoire. S’ils ont la couleur et l’aspect du terminal passif, ils ne
le sont pas du tout : ils sont clairement actifs, et donc, à gérer en tant que tels. Malheureusement, le plus
souvent, nos outils habituels de gestion de parc PC ne savent que peu ou pas s’accommoder de ces systèmes
d’exploitation embarqués « à la marge ».
À l’autre extrême existent des terminaux « ultralégers », qui n’intègrent (quasiment) pas de système
d’exploitation et téléchargent ce dernier à la demande (donc quand ils démarrent) via le réseau. Ces terminaux
sont alors d’une robustesse absolue.
Les autres types de postes
En fait, il suffit de pouvoir installer un quelconque client protocolaire, ICA ou RDP sur un ordinateur équipé d’une
connexion réseau gérant TCP/IP pour le transformer en poste de travail client léger.
C’est donc de plus en plus fréquemment le cas pour les mobiles type PDA ou pour les tablettes à écran tactile. Il
existe aussi des cartes additionnelles à insérer dans les ordinateurs pour les transformer en terminaux.
Le principe souvent recherché reste de ne pas avoir à installer le logiciel client en question, mais plutôt
d’automatiser son déploiement par téléchargement lors d’une première connexion à un serveur spécifique.

Bénéfices pour l’entreprise
1. Fédérer la diversité
Nous l’avons dit, une architecture clients légers est avant tout une architecture centralisée et homogène
puisqu’elle banalise le poste de travail client et s’accommode de tout type de réseaux IP.
Du point de vue de l’entreprise, cette simple approche permet de réduire de façon drastique les coûts liés à la
gestion des infrastructures hétérogènes.
Impact sur le TCO
Poste Administration : qui dit architecture centralisée dit à portée de main et réduite à quelques serveurs au
lieu de centaines de machines. Il est évident qu’il est plus simple, plus efficace et donc moins coûteux pour
l’entreprise, de gérer des serveurs RDS plutôt que les postes utilisateurs et chacune de leurs spécificités. Les
actions de type mises à jour systèmes ou applicatives sont facilement réalisables car localisées, réduites à
quelques serveurs et immédiatement applicables pour l’ensemble des utilisateurs. Si l’entreprise a des sites
distants, nul besoin de prévoir des déplacements coûteux et contraignants. Si un problème générique survient, il
est résolu beaucoup plus rapidement et pour l’ensemble des utilisateurs.
Poste Support : l’assistance est simplifiée car tous les utilisateurs disposent des mêmes versions applicatives et
surtout d’un seul et même système d’exploitation, dont la surveillance par voie d’administration est bien plus
efficace (nous pourrions dire réelle car combien d’entreprises peuvent se payer le luxe d’administrer les postes
de travail ?). Les problèmes sont donc limités et en cas de survenance, résolus directement à partir du serveur.
En effet, les protocoles RDP ou ICA autorisent la prise en main à distance des sessions utilisateurs par le service
informatique, augmentant ainsi la réactivité et l’efficacité du service d’assistance. Du point de vue de la formation,
l’impact est indirect mais s’exprime par le simple fait que le personnel est formé sur des versions homogènes et
disposera de ladite version dès son retour de formation, étant donné que le temps de migration d’une version ou
d’une application à une autre se réduit à quelques heures voire minutes.
Poste Temps Utilisateurs : un système unique, des applications homogènes et identiquement paramétrées
réduisent les difficultés rencontrées par les utilisateurs dans leur usage quotidien du système d’informations de

l’entreprise. L’assistance interutilisateurs, bien que coûteuse et à éviter, se réduit aussi car elle devient plus
efficace et moins systématique. Enfin, l’utilisateur travaillant sur un système centralisé, dont il n’est plus "maître",
limite les fausses manipulations et les utilisations divergentes, sources fréquentes de problèmes notoires.
2. Réduction de la bande passante
Le principe technologique des protocoles ICA ou RDP (communication graphique compressée limitée au
rafraîchissement d’écran dans un sens, et évènements clavier/souris dans l’autre) induit une faible consommation
de bande passante.
A minima, lorsque l’utilisateur ne manipule pas clavier ou souris et que rien ne bouge à l’écran (lecture d’un
document par exemple), seules quelques trames de contrôle de connexion transitent sur le réseau (afin de
vérifier que le poste est toujours connecté au serveur). Il y a à cet instant une consommation de bande passante
quasi nulle.
A maxima, lorsque l’utilisateur rafraîchit l’intégralité de la surface de l’écran, par exemple lorsqu’il va basculer
d’une application à une autre par le raccourci [Alt][Tab] sous Windows, la consommation de bande passante est
de l’ordre de 15 à 16 KBps.
En moyenne, c’estàdire en utilisation courante d’un utilisateur actif mais pas forcené du [Alt][Tab], on constate
que la bande passante consommée oscille entre 8 et 10 KBps.
Nous avons volontairement, ici, repris les chiffres de constructeurs, éditeurs et autres acteurs du marché des
clients légers pour attirer l’attention sur l’unité de mesure : les KBps (Kilo Byte par seconde), à ne pas confondre
avec les Kbps (Kilo bits par seconde). Il y a un rapport de 1 à 8 entre les deux unités ! Cette astuce commercialo
marketing tend à faire croire que les protocoles clients légers ne consomment quasiment rien. Mais s’ils
consomment peu, il convient quand même de rétablir les valeurs cidessus annoncées sur la base d’une unité
commune à celle utilisée pour déterminer la puissance des lignes télécom et réseaux : le Kbps.
On obtient donc une consommation de bande passante oscillant entre quasi 0 Kpbs et 128 Kbps, avec une
moyenne normalisée oscillant entre 0 et 80 Kbps par poste connecté.
La sensation de réduction de bande passante vous apparaît moins évidente ? Il faut alors intégrer deux
dimensions supplémentaires : la simultanéité et la réalité de l’entreprise.
Considérons une dizaine d’utilisateurs qui travaillent en mode client léger (c’estàdire connectés via RDP à un
serveur RDS). Le protocole ne consommant que l’équivalent de la somme des rafraîchissements de l’ensemble
des écrans des utilisateurs, combien d’écrans complets cela peutil représenter à l’instant t ? Car à l’instant t+1,
si les utilisateurs ne poursuivent pas leurs actions, la consommation tend à nouveau vers zéro. On constate
généralement que l’on peut diviser le nombre d’utilisateurs par deux pour avoir la réponse, et multiplier par 64
Kbps par utilisateur pour obtenir un ordre de grandeur de la bande passante utilisée (ou nécessaire). Dans cet
exemple : (10 / 2) x 64 Kbps = 320 Kbps pour dix utilisateurs actifs.
Dans la réalité de l’entreprise, un salarié ne passe pas tout son temps à manipuler son ordinateur (sauf
quelques activités ou postes spécifiques) : il téléphone, manipule du papier, participe à des réunions, etc. Cela
reste donc difficile à évaluer, mais l’on peut considérer dans notre exemple précédent de 10 utilisateurs
simultanés qu’ils représentent en fait une population moyenne de 15 à 20 salariés. La qualité du projet pilote
sera déterminante pour bien connaître le profil de travail des utilisateurs dans l’entreprise et donc bien calibrer
ses lignes.
Quoi qu’il en soit, nous arrivons à un ordre de grandeur de 15 à 20 utilisateurs pour 320 Kbps de ligne télécom,
par exemple, s’il s’agit de relier une agence au siège central. Si nous devions déployer le PGI (Progiciel de
Gestion Intégré (ERP en anglais)) de l’entreprise sur une agence en mode classique (client/serveur ou web
enrichi), la bande passante nécessaire serait de l’ordre de la centaine de Kbps par utilisateur, il est donc évident
que nos 15 à 20 utilisateurs ne pourraient se contenter d’un lien à 320 Kbps. À tel point que les entreprises ont
souvent résolu le problème en installant soit un petit serveur sur le site distant (avec tout l’impact indirect sur les
coûts d’administration), soit une ligne télécom calibrée mais exorbitante et souvent saturée quand même, soit en
ne déployant pas le PGI en question.
On voit que l’architecture client léger va permettre à l’entreprise :

● Soit de ne pas avoir à changer ses lignes réseaux pour supporter de nouveaux systèmes ou
applications, ou plus d’utilisateurs.
● Soit d’augmenter le niveau de performance réel ressenti par l’utilisateur au bout de la ligne.
● Soit de déployer des applications à destination de sites distants à très faible bande passante :
connexions modems RTC ou 3G pour des itinérants, connexions RNIS, ADSL ou LS sur des sites très
isolés, etc.
Impact sur le TCO
La réduction de bande passante n’a pas de gros impact sur le TCO de l’entreprise : elle permet surtout
d’apporter des solutions efficaces à des problèmes qui parfois n’avaient pas pu être résolus.
Selon le profil de l’entreprise, l’impact sur le poste Communication peut toutefois être notable : lignes
internationales, grand nombre de lignes souscalibrées, etc.
Un cas particulier s’avère aussi financièrement très avantageux : si l’entreprise dispose d’un câblage
informatique ne permettant pas de passer à des débits modernes de type 100 Mbps ou Gigabits (imaginez une
administration de 500 postes de travail dans un bâtiment historique classé, avec un câblage obsolète).
L’architecture clients légers permet alors de conserver le câblage existant car elle se contente de faibles débits.
Enfin, le poste Indisponibilité est positivement impacté : une saturation de bande passante aboutit à
l’impossibilité de poursuivre son travail, voire à des plantages applicatifs ou serveurs qui auront des
répercussions immédiates sur l’ensemble des utilisateurs, locaux ou distants... L’architecture clients légers
n’aboutit pas à ce type de problèmes, comme nous pouvons le comprendre dans le bénéfice suivant.
3. Les sécurités
Pas LA sécurité, mais bien LES sécurités ! En effet, l’architecture client léger apporte, par essence même, un lot
de bénéfices en terme de sécurité.
Virus Vers Attaques

Deux cas distincts sont à envisager :
● Le poste de travail client est de type poste puissant (genre PC).
Dans ce cas, et bien que l’on puisse cantonner le poste client à n’être que l’équivalent d’un terminal
connecté au serveur RDS, on dispose d’une machine dotée d’un système d’exploitation plus ou moins
vulnérable, mais en tout cas, à gérer comme habituellement (antivirus, antispyware, patchs de
sécurité...). Bien souvent en pareil cas, il est judicieux de normaliser le poste avec un système
d’exploitation relativement fermé et/ou très sécurisé (Linux est souvent utilisé en ce sens), qui ne
servira qu’à démarrer et lancer le client protocolaire retenu. Malgré tout, l’environnement applicatif de
l’utilisateur diffusé depuis le serveur RDS ne pourra être mis à mal par une attaque sur la machine
locale : un virus ne peut passer d’un système local à un serveur RDS par le seul biais d’un protocole
graphique. Ceci est particulièrement vrai pour les postes itinérants type ordinateurs portables. Ils sont
souvent dotés d’une connexion Internet libre, c’estàdire utilisable pour se connecter, certes, à
l’entreprise, mais aussi depuis n’importe où pour surfer librement. Ces postes sont difficiles à gérer en
terme de sécurité et par conséquent subissent fréquemment des attaques. Si la connexion à l’entreprise
se fait via les protocoles ICA ou RDP, l’entreprise est protégée (du moins tant que le portable ne revient
pas se connecter sur le réseau interne de l’entreprise). Dans le pire des cas, l’utilisateur ne pourra plus
se connecter, mais les serveurs eux n’auront subi aucun assaut.

● Le poste de travail client est de type terminal passif.
Le plus souvent il ne dispose ni de lecteur CD, ni de lecteur disquette ou encore de disque dur. Il est
alors impossible d’introduire un virus ou une vulnérabilité dans le système d’informations de l’entreprise
à partir du poste de travail. Certes, 90 % des problématiques proviennent désormais de l’extérieur, mais
dans une architecture centralisée, les points de passage sont très limités et donc plus facilement
contrôlables et gérables (patchs de sécurité, version des navigateurs...).
Installations "sauvages"
Dans le cas du terminal passif et du fait de sa conception matérielle et système, il n’est pas possible d’installer
localement quelque application que ce soit.
Et dans le cas du serveur RDS, un utilisateur ne dispose pas des droits nécessaires ou suffisants pour ajouter
des composants systèmes, des logiciels ou des périphériques à volonté : c’est le rôle et la capacité unique du
service informatique.
Le système de l’utilisateur reste propre, ce qui limite autant les problèmes de toutes sortes que les utilisations
divergentes ou les vulnérabilités.
Vol de données
Bien qu’il ne soit pas impossible de le faire (il s’agirait dans ce cas d’un paramétrage volontaire de
l’administrateur), le principe de l’architecture clients légers tend à interdire les échanges de données entre le
serveur RDS et le poste local d’un utilisateur et l’ensemble de ses périphériques de stockage (disques durs,
disquettes, graveurs de CD, clés USB...).
Dans le cas d’un utilisateur itinérant, celuici peut travailler avec l’ensemble des applications et des données de
l’entreprise auxquelles il a droit, mais ne pourra pas copier (sauf paramétrage) les données localement sur son
poste. L’entreprise ne craint, dès lors, plus le vol ou la casse de l’ordinateur et la perte ou la divulgation des
données qui s’en suit, de même que les salariés malhonnêtes ou en phase de départ.
Les postes fréquemment sources (ou plutôt cibles) de problèmes sont souvent ceux de la direction de
l’entreprise, avec généralement son lot de données stratégiques.
Il faut aussi considérer le piratage direct d’une personne malveillante qui espionnerait ("sniffer" ou autre) le
réseau de l’entreprise : dans une architecture centralisée type RDS, il aurait le plaisir de capturer des fragments
d’images qu’il ne pourrait coller bout à bout avec facilité et dont au final il ne pourrait faire qu’un peu de retouche
graphique... En architecture RDS, seules les extrémités sont à protéger : les flux sont, par essence,
inintéressants.

Coupures de connexions et autres plantages
Du principe technologique même découle des avantages fonctionnels certains :
En cas de coupure du réseau (fréquent sur les WAN ou les accès distants), seule l’image ne peut plus s’afficher
sur le poste de travail (et seul l’utilisateur ne peut plus travailler). Par contre, son application est toujours active
sur le serveur, qui bascule en mode déconnecté en attendant patiemment que l’utilisateur revienne se connecter.
S’il s’agit de bases de données facilement corruptibles, ou de documents non encore enregistrés, rien n’est
perdu ! Il n’est plus besoin de se lancer dans des réindexations interminables ou de recommencer son travail.
C’est d’autant plus intéressant pour les systèmes sensibles, que pour les utilisateurs distants. Ces derniers (et
surtout l’entreprise) bénéficient de la logique "temps réel" sans effort particulier : plus besoin de synchroniser
des bases de données délocalisées et donc vulnérables, et tout travail entamé par l’utilisateur est préservé quoi
qu’il arrive.
Impact sur le TCO
On l’anticipe facilement : l’impact sur le TCO est quasi complet.
Globalement, et cela pourrait constituer un avantage à part entière, les architectures clients légers réduisent le
TCO de façon drastique.
Une étude Zona Research montre que le coût total de possession de 15 postes informatiques sur 5 ans en
entreprise coûte 100 (base indiciaire) pour une solution PC classique, et ne coûte que 43 pour une solution
clients légers. On peut retenir un ordre d’idée de 2 fois moins coûteux sur 5 ans.
Et sur 5 ans seulement... Car il est difficile de faire vivre une architecture PC classique plus de 5 ans ; alors que si
elle est basée sur des terminaux, l’architecture clients légers tiendra plus longtemps. En fait, il faudra renouveler
les serveurs et les postes de travail pour la solution PC classique, alors qu’il ne faudra renouveler que les
serveurs pour la solution clients légers. L’étude comparée reste donc possible mais accentue encore l’intérêt
pour les solutions clients légers !

Champs d’application
Aussi nombreux que variés, nous ne présentons ici que quelquesuns des champs d’application possibles et
courants en entreprise. Notez qu’aucun ne peut couvrir 100 % du parc informatique de l’entreprise et qu’il convient
de mettre en œ uvre ce type d’architecture de façon judicieuse, de les combiner pour en tirer la quintessence.
1. Postes de travail bureautiques banalisés
Voici ce que peut être une installation type (ultra simplifiée et pas modèle !) en entreprise d’une architecture
clients légers :
Les postes terminaux sont réservés à des utilisateurs dont le profil d’utilisation est relativement standardisé. Il
faut bien comprendre que cela ne signifie aucunement qu’il faut se contenter de deux applications standards
pour pouvoir correspondre au profil : il peut y avoir des applications métiers plus ou moins spécifiques
gourmandes en ressources, des émulations sur d’autres systèmes serveurs, etc. L’essentiel reste de pouvoir
déterminer des populations d’utilisateurs dont le nombre et/ou le type d’applications sont similaires, donc qui
sauront cohabiter sur un seul et même serveur : une application utilisée par seulement un ou deux utilisateurs
n’a pas grand intérêt à être sur un serveur RDS, mais serait mieux servie par une architecture VDI.
Cette architecture classique permettra à l’entreprise de tirer les bénéfices évoqués et ainsi contrôler au mieux
son TCO.
Du point de vue de l’utilisateur, outre le confort d’utilisation amené par un poste stable qui fonctionne tous les
jours de la même manière, c’est la souplesse qui reste le grand intérêt de la solution. En effet, le mode
déconnecté du serveur RDS permet de conserver sa session active sur le serveur : c’est simplement l’interaction
image/clavier/souris qui ne s’opère plus du poste devant lequel l’utilisateur était connecté, le serveur attendant

patiemment que la connexion se rétablisse, du même endroit ou... d’ailleurs ! Ce qui permet à l’utilisateur de
disposer de son travail en tout point du réseau de l’entreprise : en salle de réunion, dans le bureau d’un
collègue, etc. De même, et si par hasard son poste venait à tomber en panne, il lui suffirait de trouver un poste
quelconque libre (collègue en congé, poste libre service...), de se connecter avec ses identifiants (nom
d’utilisateur et mot de passe associé), pour pouvoir retravailler normalement.
2. (Non) Renouvellement de parcs obsolètes
Déclinaison du champ d’application précédent, il est à l’origine de nombreux projets client léger en entreprise.
En effet, on peut s’accorder à considérer qu’un parc de postes type PC doit être renouvelé régulièrement, entre
trois ans et cinq ans selon les cas. Ceci signifie une "boucle TCO" complète à chaque échéance anniversaire,
c’estàdire qu’il va falloir investir dans des matériels et des logiciels, qu’il va falloir mettre en place tout cela (gros
effort physique voire technique), former les utilisateurs, etc.
Plus vicieux encore est le cas de parcs en location avec renouvellement imposé en fin de période, généralement
trois ans, car il peut imposer un renouvellement alors que les systèmes en place auraient pu tenir un ou deux
ans de plus. La solution est d’ailleurs souvent de prolonger les contrats de location, voire de se porter acquéreur
de son parc. Ces deux solutions sont très coûteuses, elles n’apportent aucun bénéfice fonctionnel.
L’architecture clients légers basée sur des terminaux passifs évite ces écueils. Elle est pérenne du point de vue
du poste client et donc limite et simplifie toute opération de changement de système ou de migration applicative.
Quand l’entreprise se trouve face à une problématique de renouvellement d’un parc PC (obsolète ou non), il est
financièrement plus intéressant d’initier un projet clients légers, de mettre en œ uvre des serveurs RDS et ainsi
d’avoir le choix :
● Soit de conserver (si possible) ses postes existants en leur faisant jouer le rôle de simples terminaux.
Cela permet de ne pas avoir à réinvestir dans des postes de travail, d’assurer leur mise en œ uvre, etc.
et au passage de trouver un retour sur investissement nouveau sur les investissements passés. Au fur
et à mesure des pannes des postes (moins fréquentes car ils sont moins sollicités), il est alors
intéressant de basculer progressivement vers de vrais terminaux passifs pour l’ensemble des raisons
évoquées dans les pages précédentes.
● Soit de remplacer immédiatement le parc PC par un parc de terminaux (pour les populations
correspondant aux critères suscités).
Il est à ce titre plus intéressant de se porter acquéreur de son parc de terminaux passifs, quitte à le faire
financer sur un plan purement bancaire, que de le louer auprès de sociétés spécialisées : il ne sera pas obsolète
en 3 ans et donc rien ne sert de forcer son renouvellement par simple aspect contractuel et financier (à moins de
pouvoir louer son parc avec renouvellement par masse financière plutôt que par nombre de postes).
Si vous envisagez de conserver les postes existants, n’oubliez pas de considérer nécessaire la conduite du
changement auprès des utilisateurs : il serait regrettable que ces derniers rejettent la nouvelle infrastructure
sous prétexte qu’ils ont gardé "leur vieux poste". Il suffit de les impliquer fortement lors du pilote du projet, par
exemple en leur démontrant que leur vieux poste connecté à la nouvelle infrastructure est plus rapide que le
poste récent de leur voisin, ou encore en mettant en avant les nouveaux aspects fonctionnels apportés par la
solution.
3. Diffusion d’applications temps réel et sécurisées
Pour illustrer ce champ d’application, nous allons prendre deux exemples concrets.
Soit une entreprise dotée d’une force commerciale imposante, itinérante et particulièrement éparpillée. La mise
en place d’un projet de gestion de la relation client ou CRM va s’accompagner d’un lot de problématiques
techniques et stratégiques. Audelà des aspects télécom, les utilisateurs vont vraisemblablement travailler en
mode synchronisation en disposant sur leur portable ou leur PDA d’une partie de la base de données
commerciale. Ils auront du mal à accéder aux documentations techniques ou commerciales, aux informations liées
à la production, aux niveaux de stock... Si leur poste tombe en panne, ce ne sera peut être que le travail de la

journée qui sera perdu (dans l’hypothèse d’une synchronisation journalière), mais s’ils se font voler leur portable
ou PDA, c’est la base de données de l’entreprise qui part dans la nature. Et si l’un des commerciaux décide de
partir au profit d’un concurrent ? Ou simplement reste en mauvais terme avec son employeur actuel ?
Soit une autre entreprise (ou la même), dont les équipes techniques procèdent à des relevés sur le terrain toute
la journée sur leur portable ou PDA (données importantes car déclenchant soit des alertes, soit des interventions
facturées ou des commandes de fournitures), ou font partie d’un service préventif ou de la préparation d’une
action curative. Ces équipes envoient en fin de journée ou fin de semaine le bilan de leur travail, nerf de la
guerre pour l’entreprise. Que se passetil si le poste tombe et se casse, ce qui reste fréquent pour du personnel
technique qui travaille dans des conditions physiques souvent délicates ?
Nous vous laissons imaginer, dans ces deux hypothèses, les conséquences de faits bénins et fréquents en
entreprise. L’architecture centralisée RDS permet de s’affranchir de cette problématique globale par son simple
principe technologique de transfert d’image et de noninterruption du travail entamé par simple déconnexion
entre le poste client et son serveur.
Premièrement, le poste cassé, en panne ou volé est un simple poste d’accès à l’ensemble des données et
applications de l’entreprise, qui ne comporte alors aucune donnée locale : tout travail effectué est sécurisé (c’est
àdire pérennisé et protégé).
Deuxièmement, le travail effectué n’est pas synchronisé ou à synchroniser, il est en temps réel, ce qui signifie
aussi que les informations mises à disposition de tout le personnel sont à jour (par exemple le planning des
tournées de RDV ou les états de stock).
Enfin, en cas de problème du poste de travail de l’utilisateur, il n’est pas toujours nécessaire de le faire revenir
dans l’entreprise (ou d’attendre son retour) pour qu’il puisse disposer d’un outil à nouveau fonctionnel : il suffit
qu’il trouve sur son chemin un poste connecté ou connectable sur Internet pour pouvoir à nouveau accéder à son
travail, le plus souvent là où il en était resté !
4. Diffusion d’applications via le Web
Il y a deux façons d’interpréter le terme "via le Web" : soit le poste client se connecte à travers le Web sur son
serveur RDS traditionnel, soit le poste client accède dans son navigateur Web à des applications diffusées par un
serveur RDS.
Dans le premier cas, il s’agit simplement du mode de connexion utilisé entre le serveur RDS et le poste client : le
réseau Internet en TCP/IP en l’occurrence. Ceci est très pratique pour le personnel itinérant (direction,
commerciaux...) dont on ne peut prévoir systématiquement d’où il se connectera exactement. Sous réserve de
routage et firewall consentants, ils trouvent leur chemin IP vers le serveur RDS qui les attend patiemment.
Nous verrons d’ailleurs plus loin que les contraintes de filtrage sont désormais moindres du fait de
l’encapsulation HTTPS de RDP 7.

Sur le schéma précédent, et pour illustrer cette approche, nous voyons que le directeur M. Patron va pouvoir
accéder depuis son hôtel à l’intégralité de son système d’informations grâce à une simple connexion 3G associée
à son portable, doublée d’une sécurisation classique VPN.
Dans le cas du poste client qui accède dans son navigateur Web à des applications diffusées par un serveur RDS,
il n’est pas sousentendu que l’utilisateur soit à l’extérieur de l’entreprise : ce peut être un usage normal pour
certaines applications/populations, par exemple, si l’entreprise a normalisé le navigateur Internet comme
interface client par défaut (plutôt que le bureau Windows complet). Il s’agit, comme le montre l’écran suivant, de
diffuser via le protocole ICA ou RDP une (ou plusieurs) application(s) dans un navigateur (pas nécessairement
Microsoft d’ailleurs).

L’application peut être diffusée telle quelle, ou bien intégrée au sein d’un portail d’entreprise avec logos,
informations complémentaires, etc.
Le champ d’application particulièrement intéressant en la matière est la diffusion d’applications plus ou moins
spécifiques dont il n’existe pas de version Web, c’estàdire basée sur HTML, ou dont le portage
(redéveloppement) serait trop long ou trop complexe et/ou coûteux. C’est le cas de l’exemple cidessus :
l’application de CRM Sage Contact n’existe pas en version Web, mais il est toutefois possible de la diffuser dans
un navigateur grâce à RDS.
Enfin, comme le site web propose l’installation automatique du client RDP, il ne sera pas nécessaire d’anticiper
son déploiement. Une bascule à "l’instant T" d’un système vers un autre est donc envisageable.
5. Interconnexion de sites distants
Ce champ d’application assez fréquent en entreprise se décline selon le contexte de l’entreprise ellemême.
L’entreprise peut, par exemple, disposer de différents sites géographiques plus ou moins distants et plus ou
moins nombreux. La diffusion, via RDS, d’applications centralisées ou sensibles permettra de bénéficier des
avantages techniques et financiers vus dans les pages précédentes. Elle permettra surtout la réduction de la
bande passante dans les liens télécom existants et peutêtre la conservation des infrastructures existantes. Elle
évitera, enfin, aux équipes techniques et de support de toujours prévoir des déplacements pour toute
intervention technique.
Dans le monde économique actuel, il est fréquent de voir les sociétés fusionner, se racheter... Il convient alors
d’homogénéiser, le plus souvent très rapidement, les systèmes d’informations des deux ou x sociétés, chacune
d’elles pouvant avoir n sites distants et surtout être basée sur des systèmes et des applications foncièrement
différentes. L’intérêt du déploiement d’une solution clients légers vient dans sa capacité à mettre en œ uvre
l’informatique d’une société (ou d’un site) dans l’autre sans être intrusive : le client protocolaire est déployé en
perruque (comprendre "pardessus" l’installation existante) et permet ainsi l’accès à tout ou partie du système
d’informations destiné à devenir le système référent, sans désinstaller et/ou détruire le système cible dans un
premier temps. Sur le plan fonctionnel et applicatif, le système d’informations du nouveau "groupe"
s’homogénéise donc très rapidement et le toilettage technique complémentaire pourra se faire en fort décalage
temporel. Cette approche autorise aussi de faire machine arrière.
6. Informatique en milieux hostiles
Les milieux dits hostiles peuvent l’être du fait du contexte ou du fait des utilisateurs.
Considérons une informatique située en entrepôts ou en chaînes de production, avec les particularités
suivantes : environnement fortement poussiéreux ou sale, conditions climatiques aléatoires (entrepôts ouverts),
mouvements de machines, véhicules ou pièces hasardeux... L’architecture client léger va permettre de
positionner en ces lieux des postes de type terminaux passifs, dont le capot sera dépourvu de ventilateur ou
autre ouverture inutile, dont les pièces d’usure (disque dur par exemple) sont absentes et l’électronique réduite
au minimum, donc globalement dont la résistance sera bien plus grande qu’un poste type PC.
Elle va permettre aussi de travailler en mode centralisé et/ou temps réel, donc toute coupure ne sera pas
problématique pour le système d’informations : coupure réseau due à des champs magnétiques forts lors de
démarrage de machines outils par exemple, coupures et/ou pannes de postes dues à des maltraitances diverses
du poste luimême, etc.
Un milieu hostile humain peut être représenté par une population d’utilisateurs non nécessairement mal
intentionnés, mais surtout dont le comportement visàvis du poste de travail est très irrespectueux des
quelques règles de bons sens et des usages standardisés qui permettraient au poste de travail de fonctionner
tous les jours normalement. C’est par exemple le cas de l’informatique dans les établissements éducatifs :
chaque enfant et/ou étudiant découvre et apprend, donc manipule mal, un poste de travail qui d’heure en heure
et jour après jour n’est jamais le même (ce n’est pas son poste, c’est seulement un poste parmi les postes).
L’approche clients légers va permettre de banaliser à l’extrême le poste de travail de l’utilisateur ainsi que de
restreindre son utilisation au strict nécessaire et ainsi protéger le système malgré lui (l’utilisateur).

Les salles de formation peuvent être assimilées à des postes en libreservice, qui peuvent être indifféremment
utilisés, voire pointés vers des serveurs RDS différents en fonction du profil applicatif ou système nécessaire à
l’apprentissage du jour ou du groupe d’étudiants présent face aux écrans.
Les postes de type libreservice existent aussi en entreprise : postes dans les halls d’accueil, en salle de
réunion, dans les parties communes, etc.
7. Postes nomades en 3G
L’objectif est de permettre l’accès temps réel à des applications centralisées à des postes itinérants de type
portables ou PDA sous connexions 3G (mais aussi des connexions de moins bonne qualité).
Un serveur frontal RDS est alors positionné en DMZ (Zone démilitarisée : partie du réseau isolée du LAN par un
parefeu) : il accueille l’interface client de l’applicatif à diffuser et répond aux requêtes ICA ou RDP en provenance
de l’extérieur. La logique de diffusion est généralement monoapplicative, la surface de l’écran des postes type
PDA étant trop réduite pour accueillir un bureau Windows complet.
Il convient le plus souvent d’adapter les interfaces clientes à la surface de l’écran du PDA cible ; mais plutôt que
de développer des applicatifs clients à installer sur le système d’exploitation du PDA, dont les variétés et les
versions sont pléthores et dont l’entreprise sera dépendante, il est plus simple de redimensionner des interfaces
Windows 32 ou 64 bits traditionnelles pour les "mettre à l’échelle" correspondante et les diffuser sans se soucier
du système du poste client.

Les principaux acteurs du marché
Nous précisons que les informations cidessous ne peuvent être exhaustives et sont sujettes à de forts
changements au fil du temps.
1. Les éditeurs
Citrix
http://www.citrix.fr
L’éditeur Citrix est à l’origine des architectures clients légers telles que nous les connaissons aujourd’hui.
L’architecture Citrix est désormais un presque synonyme d’architecture Clients Légers, ce qui à mon sens est
devenu fortement réducteur, mais toujours tellement vrai dans les esprits.
Citrix a développé et promu la technologie MultiWin (serveurs multisessions et multiutilisateurs), source de 80 %
des fonctionnalités d’une architecture clients légers, dès le produit WinFrame, basé à l’époque sur un noyau
Windows NT 3.51 à interface Windows 3.x. Ce produit WinFrame a été décliné en diverses versions par des tiers
éditeurs, aujourd’hui quasi totalement disparus. WinFrame était déjà basé sur le protocole maison ICA : c’est
donc une solution clients légers globale que l’on peut qualifier abusivement de 100 % Citrix.
Avec l’arrivée de Windows NT4 Server version TSE, c’est le produit MetaFrame qui voit le jour, toujours appuyé
sur le client/serveur protocolaire ICA, et qui perdure avec quelques évolutions de versions depuis Windows
Server 2000. C’est surtout dans ces versions une tierce solution, la technologie MultiWin étant passée dans les
mains de Microsoft (cf. dans ce chapitre et cette section Un peu d’histoire...).
Citrix propose désormais de nombreuses fonctionnalités architecturées autour de Presentation Server & Access
Suite, dernières évolutions de l’historique MetaFrame, suivant ainsi une stratégie cohérente de différenciation
forte avec l’orientation client léger simple. Citrix cherche ainsi à éviter tout positionnement concurrentiel
simplement basé sur les protocoles ICA contre RDP, dont les évolutions et fonctionnalités 2008 R2 s’avèrent
importantes.
Microsoft
http://www.microsoft.com/france/
Éditeur bien connu de Windows Server, il est passé de simple fournisseur de noyau système à l’époque de
Windows NT Server 3.51, au statut de fondation de toute architecture clients légers.
C’est en effet avec l’avènement de Windows NT4 Server version TSE (Terminal Server Edition, d’où le nom abrégé
encore utilisé abondamment aujourd’hui bien qu’il n’y ait plus de version TSE spécifique dans la gamme Windows
Server) que Microsoft présente son client/serveur protocolaire RDP, concurrent de celui de Citrix, ICA et propose
donc une solution complète (Microsoft dispose à cette date de la technologie MultiWin).
Avec Windows Server 2000, les fonctionnalités TSE sont intégrées dans la version standard et donc découvertes
et accessibles par l’ensemble des acquéreurs d’une licence de cet OS.
Dans la version suivante, Windows Server 2003, Microsoft met l’accent sur ces technologies et propose une
solution complète aussi standard que performante, dont les produits de Citrix ont nécessairement besoin pour
fonctionner.
Enfin, avec Windows Server 2008 et surtout 2008 R2, Microsoft comble les derniers écarts fonctionnels qui lui
étaient souvent reprochés, mettant à mal l’ensemble de ses concurrents, notamment les fournisseurs de
solutions tierces cidessous présentés.
Sun

http://fr.sun.com/
Célèbre constructeur racheté par Oracle, Sun est aussi éditeur depuis longtemps d’une solution concurrente à
Microsoft TSE/RDS, qui est restée très marginale car peu orientée vers les environnements Microsoft jusqu’à
encore peu.
La solution d’architecture clients légers Secure Global Desktop devient surtout intéressante couplée à la solution
VDI de l’éditeur, d’une qualité et d’un positionnement très intéressant.
Sun s’appuie sur un protocole de communication propriétaire et concurrent de RDP : AIP. Ce dernier a l’avantage
de ne pas être sensible aux variations de latence des lignes réseaux (se référer au chapitre Implémenter une
architecture RDS 2008 R2 Le choix de l’architecture réseau pour en mesurer l’intérêt), et peut aussi encapsuler
RDP, lui faisant ainsi bénéficier de cet apport.
En résumé, il peut être intéressant d’étudier les solutions apportées par Sun en complément d’une architecture
RDS Windows 2008 R2.
Les tierces solutions
Systancia : la suite logicielle Applidis propose un package d’outils de management et quelques fonctionnalités

améliorées des solutions TSE basées sur le protocole RDP (notamment une intéressante interface
d’administration). C’est une surcouche non assimilable à la suite Citrix MetaFrame, car complémentaire à l’offre
standard Microsoft TSE/RDP. Malheureusement, cette suite perd beaucoup de son intérêt initial avec l’avènement
de RDS 2008 R2. Comme Citrix, l’éditeur français (ce qui reste notable/appréciable) cherche à se diversifier, et
propose avec Applidis Fusion 4 une première approche du VDI (http://www.systancia.fr).
2X : les produits de la société 2X méritent aussi d’être cités. Moins connues et/ou matures que les solutions
Systancia, les applications 2X viennent elles aussi enrichir les architectures TSE, essentiellement 2003, car avec
l’avènement de TSE 2008, elles se justifient nettement moins... (http://www.2x.com).
NoMachine : est un éditeur issu du monde OpenSource, basant ces solutions sur le protocole NX
(htttp://www.nomachine.com). En effet, couplé à CrossOver, il permet la diffusion d’applications Windows 32 bits
à partir d’un serveur Linux.
2. Les constructeurs
HP NEOWARE
Neoware et HP partageaient le leadership avec Wyse : depuis que HP a racheté Neoware fin 2007, le « couple »

est désormais leader des constructeurs de terminaux Windows. Outre la qualité de ses suites logicielles,
Neoware apporte à HP une gamme de terminaux Linux et étoffe en parallèle la gamme des terminaux Windows
CE ou Xpe existante.
Le positionnement important d’HP auprès de nombreux grands comptes, mais aussi de sociétés de moindre
importance, aura pour principal effet la généralisation des terminaux Windows et peutêtre une incidence
favorable sur les coûts d’acquisition, pourtant déjà très bas.
WYSE
http://fr.wyse.com/
Leader historique du marché des clients légers, Wyse élargit son offre et tisse des partenariats importants,
notamment avec VMWare sur les solutions de virtualisation, pour promouvoir des architectures de virtualisation
d’application, ou de VDI, plutôt que des matériels (à l’image de la suite logicielle Wyse TCX).
IMPACT

http://www.itechno.com/
Constructeur français proposant la gamme de terminaux Itium, il peine à s’imposer malgré des produits de très
bonne qualité, à ne pas négliger, notamment un intéressant Itium Screen (terminal intégré à un écran plat 17").
AXEL
http://www.axel.com/
Constructeur français qui aime à parler de platines plutôt que de terminaux. Grand spécialiste des terminaux
point de vente, à la robustesse éprouvée, il propose des terminaux Windows souvent basés sur des
développements propriétaires.
SUN
http://fr.sun.com/
Sun est aussi constructeur de terminaux, la gamme Sun Ray, dont les tarifs comme la qualité (avec lecteur de
carte intégré et réellement fonctionnel) sont très intéressants aussi, avec notamment un modèle intégré du plus
bel effet.
3. Un peu d’histoire...
Il est important de connaître un peu l’histoire ancienne et l’évolution du marché des clients légers,
particulièrement du point de vue des deux éditeurs majeurs Microsoft et Citrix, afin de mieux comprendre le
contexte actuel, et par làmême, le pourquoi de ce livre.

La grande épopée des solutions clients légers a réellement commencé avec la sortie de Windows NT4 Server
version TSE.
À cette époque, nous avons entendu dire que Microsoft avait racheté Citrix, ce qui était abusif dans les termes si
l’on considère les faits (encore aujourd’hui relativement hermétiques).
Microsoft a racheté la technologie multiutilisateur et multisession ultiWin développée et maintenue par Citrix,
avec vraisemblablement une partie des équipes techniques associées, pour disposer d’un système réellement
équivalent aux systèmes Unix, de ce point de vue.
En contrepartie, Citrix a licencié Microsoft pour le produit Windows pour une durée déterminée ; c’estàdire qu’à
chaque produit Windows Server avec TSE vendu, Citrix touche des royalties.
On peut dès lors clairement se poser la question de savoir qui fut le réel gagnant de la transaction : Microsoft,
qui s’ouvrait des portes technologiques nouvelles grâce à MultiWin ou Citrix qui toucha des royalties très
conséquentes dans les années qui suivirent.
Quoi qu’il en soit, force est de constater que cette opération a permis à Microsoft de sortir le produit NT4 version
TSE, associé à la toute première version 4 du client/serveur protocolaire RDP. Il s’agissait donc d’un produit
spécifique, c’estàdire différent de Windows NT4 Server simple, avec son versionning, ses problèmes et son
support spécifiques.
Une entreprise qui se portait acquéreur d’une version Windows NT4 Server TSE, et donc payait au passage ses
licences d’accès client TSE (les fameuses CAL TSE), achetait donc une solution clients légers complète et, sur le
papier, fonctionnelle. Sur le papier seulement, car objectivement, la couche MultiWin d’origine Citrix fut un peu
parachutée sur le noyau Windows NT et le client/serveur protocolaire RDP en était à ses balbutiements.
En parallèle, le produit Citrix MetaFrame, exploitant au mieux un noyau MultiWin fort bien connu, et disposant
d’une avance technologique très importante au niveau du client/serveur protocolaire ICA, était la seule
architecture réellement fonctionnelle et crédible.
C’est aussi à cette époque que ce type d’architecture s’est fait connaître et c’est ainsi que nombre d’éditeurs ou
de sociétés de services en ingénierie informatique ont associé "architecture clients légers" avec "architecture
Citrix". Le réel problème est que ce quasiadage n’a depuis que rarement été remis en cause...
Windows Server 2000 est certes avant tout l’apparition d’une interface type Windows 9x et d’Active Directory,
mais c’est aussi l’intégration de la "couche TSE" au sein d’un produit désormais unifié. On ne peut pas dire que
Microsoft ait fortement travaillé le MultiWin, ses efforts se sont plutôt concentrés sur son intégration avec le

noyau Windows, et sur le client serveur protocolaire RDP, qui passe pour l’occasion à sa version 5 côté serveur,
et 5 puis rapidement 5.1 côté client sous l’impulsion de Windows XP.
C’est comme toujours une solution complète et désormais fonctionnelle bien qu’imparfaite que peuvent acquérir
les entreprises. C’est aussi la brique de base pour les solutions Citrix MetaFrame remises à jour, le MultiWin
étant toujours et définitivement intégré au noyau et hors périmètre stratégique de l’éditeur Citrix. On peut donc
qualifier clairement Citrix MetaFrame de "surcouche" à Windows Server 2000, 80 % des fonctionnalités liées à
l’architecture clients légers faisant partie du noyau avec MultiWin intégré.
Malgré tout, et surtout grâce à une avance technologique historique et quelques produits complémentaires
comme le bureau transparent ou le portail Nfuse, Citrix et ICA conservent une confortable longueur d’avance par
rapport au couple natif Microsoft TSE/RDP. On peut cependant considérer que 50 % des mises en œ uvre en
entreprise peuvent se contenter du couple Microsoft, avec un avantage financier certain.
À cette époque, beaucoup de prestataires clients légers sont arrivés sur le marché, profitant de l’intégration
standard de TSE dans Windows 2000. Certains, s’affirmant hâtivement spécialistes, proposaient des solutions
Citrix plus par facilité que par nécessité.
Windows Server 2003 reste une évolution mineure du système d’exploitation de Microsoft sauf sur 3 points :
l’architecture .NET, la souplesse apportée à Active Directory et les Terminal Services. En effet, le noyau MultiWin
est repris et amélioré, ainsi que le client/serveur protocolaire RDP qui s’annonce en version 5.2. L’écart se réduit
fortement avec le couple Citrix ICA et le besoin fonctionnel de Citrix en entreprise peut se quantifier à 1 ou 2 cas
sur 10 seulement. En parallèle, les solutions alternatives s’affinent (Systancia en tête).
L’adage "Clients légers = Citrix" reste fortement ancré dans les esprits.
Avec la sortie de Windows 2008 R2, et comme vous pouvez le découvrir, les fonctionnalités de base d’une
architecture clients légers sont désormais quasi équivalentes.
Même la terminologie s’estompe : Microsoft parle désormais de Présentation Virtualization et positionne donc les
Services RDS comme une soustechnologie… majeure !
Il faut bien comprendre que vous disposerez nécessairement et toujours a minima de Microsoft RDS en premier
lieu, les solutions Citrix ou Systancia restant des surcouches techniques et tarifaires. Pour mettre en œ uvre une
solution clients légers basée sur Citrix ou Systancia, une entreprise doit acquérir Windows Server 2008 R2 ainsi
que les licences d’accès client (CAL) RDS pour le nombre de postes concernés, c’estàdire disposer d’une
solution complète et peutêtre pleinement fonctionnelle dans son cas (RDS plus RDP), avant de payer des
licences tierces en supplément, avec un ordre de grandeur tarifaire de 180 à 300 euros le poste connecté.
Dans l’hypothèse d’un déploiement sur seulement 200 postes, le delta tarifaire est alors déjà de 40 à 60.000
euros ; et il n’est pas certain que l’on n’aurait pas pu se passer de la solution tierce... Si l’on prend le ratio
précité, dans 80 % des cas, il est possible de se contenter de la solution native Microsoft.
Que l’entreprise choisisse ou non une solution tierce, Microsoft gagne la même somme d’argent, ni plus, ni moins.
C’est l’entreprise qui subit les conséquences financières de son choix.
Enfin, quel intérêt Microsoft auraitil à promouvoir une solution concurrente, alors que ce dernier joue finalement
le rôle de service commercial et marketing de luxe, et surtout... gratuit !
Il faut réaliser que certains éditeurs tiers ne disposent que de leur suite de produits logiciels pour architectures
clients légers pour vivre ; ce qui les condamne à être commercialement excellents. Ils restent donc très
dynamiques auprès des entreprises clients, mais aussi et surtout auprès des sociétés de services, des éditeurs
et autres prestataires logiciels. Ainsi pullulent des pseudos argumentaires techniques, qui comparent des choses
parfois peu comparables, sans que Microsoft ne contredise... Et c’est l’entreprise cliente qui payera ses licences...
Tous cherchent d’ailleurs depuis plusieurs mois à réorienter leur gamme de produits afin de prévenir le jour
fatidique où, pour une raison encore insoupçonnée, les entreprises réaliseront que la valeur ajoutée réelle de
l’éditeur est bien moindre qu’on ne l’entend.
Conclusion

Pour toutes les raisons citées, et étant donné qu’il faut payer la solution Microsoft RDS/RDP complète avant de
pouvoir accéder à celle d’un tiers offreur, nous conseillons vivement de tester d’abord la solution Microsoft. Si
jamais l’entreprise est dans les 20 à 30 % de cas pour lesquels une solution tierce présente un réel avantage,
alors elle en connaît la raison et le prix.

Quelques idées reçues
1. Un concept nouveau
Si l’on considère le principe technologique, l’essence même des architectures centralisées couplées à des
terminaux passifs date de bien avant l’ère de postes puissants type PC.
Ce qui est réellement nouveau, c’est l’application d’un vieux principe aux qualités reconnues à des technologies
et des outils modernes : interfaces graphiques puissantes et ergonomiques, Internet, etc.
Depuis les années 90, les architectures clients légers passent en production dans les entreprises, avec une forte
accélération depuis le passage à l’an 2000.
2. Un projet global
La mise en œ uvre d’une solution RDS peut répondre à un besoin spécifique réduit. Elle peut être
avantageusement déployée en tant que simple frontal de diffusion, sans remettre en cause l’architecture
existante.
Il reste certain que si l’on souhaite généraliser cette approche technologique et tirer la quintessence de ces
architectures, le projet sera plus impliquant pour le reste de l’infrastructure systèmes et réseaux de l’entreprise.
3. Un projet simpliste
Pour activer les services de Bureau à distance, deux trois clics de souris suffisent à se connecter sur le serveur
RDS ! Certes, mais lors du passage en production à l’échelle de l’entreprise, les erreurs d’architecture et surtout
les utilisateurs sauront vous rappeler qu’un projet clients légers est avant tout un projet de centralisation qui se
prépare longuement. Les implications de sa mise en œ uvre peuvent porter sur d’autres technologies, elles aussi
complexes, comme par exemple Active Directory, ses unités d’organisation et stratégies associées.
Il faut aussi considérer que, si la technologie est centrale et porte sur des serveurs, cela reste avant tout un
projet utilisateur assez perturbant pour être rejeté lors du passage en production.
4. Un projet centralisé, donc risqué
Certes la centralisation augmente le risque au point central : un serveur RDS en panne et c’est l’ensemble des
utilisateurs qui est impacté.
Les solutions de redondance existent bien évidemment, à commencer par l’équilibrage de charge réseau,
abusivement appelé clustering. C’est encore une fois au niveau de l’architecture globale du projet que cet écueil
sera (facilement) évité.
5. Des serveurs centraux imposants
Le calibrage des serveurs est un aspect stratégique de l’architecture clients légers, mais l’on croise autant de cas
réels que d’annonces commercialotechnicomarketing.
La vérité est qu’il faut en fonction du profil applicatif des serveurs, et des populations d’utilisateurs, arbitrer entre
le calibre et le nombre de serveurs. En clair, il faut faire un plan de montée en charge digne de ce nom dès que
l’on sort de la simple diffusion traditionnelle bureau Windows plus pack Office (ou tout autre couplage connu et
déjà mis en production).
Mais il est faux de penser qu’il faut un serveur quadriprocesseur pour 50 utilisateurs au profil lambda !

Comme nous le découvrirons dans ce livre, les architectures 64 bits permettent désormais de réduire le nombre
de serveurs par ferme.

Introduction
Le nouvel opus des systèmes d’exploitation serveur phare de Microsoft nommé Longhorn durant sa phase de
développement, a finalement laissé place au traditionnel référencement, à savoir Windows Server 2008.
Lancé officiellement au premier trimestre 2008, il nous revient un an et demi plus tard dans sa nouvelle version :
Windows Server 2008 R2. Microsoft entend ne pas rééditer les erreurs passées notamment dans le domaine de la
sécurité. Pour ce faire, de nombreuses améliorations du système d’exploitation ont été introduites. Pour autant,
Microsoft a quand même mis l’accent sur de nouvelles fonctionnalités permettant de rendre le système plus
flexible, tout en le rendant plus granulaire.
1. Amélioration du contrôle
L’installation de Windows 2008 R2 est désormais basée sur des rôles, ce qui permet d’avoir un contrôle plus fin
de ses serveurs et de limiter le nombre de services inutilisés installés par défaut.
La nouvelle MMC Gestionnaire de serveur permet aux équipes informatiques de n’installer que les
fonctionnalités dont elles ont besoin. Elles sont épaulées par de nouveaux assistants qui automatisent la plupart
des tâches habituellement fastidieuses.
De nombreux outils système ont été améliorés, tel le moniteur de performances, afin de mieux superviser son
système et de signaler des problèmes potentiels avant qu’ils ne deviennent bloquants.
De plus, l’accent a été mis sur l’automatisation des tâches d’administration avec l’introduction d’un nouveau
langage de script, le PowerShell, qui remplacera sans nul doute le Vbscript dans les années à venir.
2. Amélioration de la sécurité
Windows 2008 R2 propose d’intégrer de nouvelles technologies de sécurité afin de renforcer le système
d’exploitation. Certaines innovations, tel que PatchGuard, permet de réduire la surface d’attaque du noyau ce
qui rendra le serveur plus stable.
De nombreuses autres améliorations comme la protection de l’accès réseau (NAP), les contrôleurs de domaine en
lecture seule (RODC), une nouvelle infrastructure à clef publique (PKI) ou encore le renforcement des services
Windows, contribuent à accroître la sécurité de votre infrastructure.
3. Amélioration de la flexibilité
Un des grands challenges des services informatiques est de pouvoir faire évoluer facilement son infrastructure au
gré des nouveaux besoins de l’entreprise et de ses utilisateurs.
La mise en œ uvre de nouvelles technologies, comme la passerelle SSL, permet de répondre aux besoins
croissants de mobilité des utilisateurs en leur permettant d’accéder aux données de l’entreprise, où qu’ils se
trouvent.
De même, Windows 2008 R2 permettra d’augmenter la vitesse de déploiement ainsi que la maintenance des
systèmes grâce au nouveau service de déploiement Windows (WDS), de favoriser la consolidation par le biais de
la virtualisation (HyperV) et également de sécuriser les contrôleurs de domaine des succursales grâce aux
RODC.
4. Améliorations apportées par le Service Pack 1
Le service Pack 1 ne se contente pas d’intégrer l’ensemble des correctifs disponibles, il apporte également
quelques nouveautés au rang desquelles on trouve :

● La restauration des dossiers précédents (Restore previous folders at logon).
● Ajout de nouveaux champs d’identification IKEV2 permettant la prise en charge des authentifications de
type "Email ID" ou "Certificate Subject" sous RRAS et IPSEC.
● Support des extensions de vecteurs avancés (AVX, Advanced Vector Extensions) permettant d’améliorer

les performances des applications utilisant massivement les calculs en virgule flottante.
● Amélioration des performances avec les disques de 4 ko (format de stockage avancés 512 E).

Virtualisation
1. Introduction
Depuis quelques années, la démocratisation des outils informatiques a conduit les sociétés à se doter de
nombreux serveurs. Il y a souvent un serveur de messagerie, généralement au moins deux contrôleurs de
domaine, un serveur de fichiers, une GED (Gestion Électronique de Documents) et des serveurs de bases de
données. Cela conduit vite à un très grand nombre de serveurs. Dès lors, nombreuses sont les sociétés qui sont
tentées par le pari de la virtualisation, non seulement pour consolider leurs infrastructures, mais aussi pour la
mise en œ uvre de plan de reprise d’activité (PRA).
Consolidation de serveurs
Dans un environnement de production, mettre en œ uvre un serveur qui ne serait sollicité qu’à 10 % de sa
capacité de traitement serait une gageure. Pourtant si l’on prend l’exemple d’un serveur DHCP, qui ne servirait
qu’à distribuer quelques centaines de baux, il semblerait un peu riche de lui dédier une machine. Dans ces
conditions, les entreprises ont tendance à multiplier les petits rôles (DNS, serveur de fichiers, impressions) sur le
même serveur ce qui, paradoxalement, conduit souvent à en faire un goulet d’étranglement dans les périodes de
forte sollicitation, voire un point de rupture critique de l’entreprise. De plus, le nombre de ports ouverts sur le
serveur étant plus important, cela augmente la surface d’attaque de la machine et la rend plus vulnérable. Enfin,
l’application de correctifs (logiciel ou sécurité), sur un des services, peut engendrer des effets de bord sur les
autres.
L’utilisation de la virtualisation permet de consolider plusieurs rôles (précédemment hébergés sur des serveurs
distincts) dans des machines virtuelles indépendantes, tout en partageant la même machine physique. Cette
approche permet d’optimiser l’utilisation des ressources en les mutualisant, tout en s’assurant que chaque rôle
tournera dans un environnement virtuel isolé.
Continuité de service
Être en mesure d’assurer une continuité de service, ou tout au moins une remise en service très brève en cas de
crash d’un serveur, est un autre challenge auquel sont confrontées les équipes informatiques. En effet, effectuer
la restauration complète d’un serveur peut s’avérer long et fastidieux, surtout lorsque les appels des utilisateurs
déconnectés se multiplient et qu’il y a des attentes fortes au niveau de votre hiérarchie ! Une solution efficace
dans ce cas serait d’avoir en spare le même modèle de serveur, mais il est évident que cela coûte cher, à la fois
sur un plan matériel mais également logiciel. Dès lors, l’autre moyen qui s’offre à nous est bien sûr la
virtualisation. Pourquoi ? Me direzvous. Tout simplement parce que les machines virtuelles ne sont pas
attachées au matériel qui les hébergent. Partant de ce postulat, il suffira de restaurer le fichier image sur un
autre serveur virtuel en service (même s’il n’a pas la même configuration matérielle), de monter l’image, et le tour
est joué, votre reprise d’activité aura été quasiimmédiate.
2. Les différentes technologies de virtualisation
Moniteur de machine virtuel de Type 2 (VMM Virtual Machine Monitor)

Architecture VMM de Type 2
Les machines virtuelles de Type 2 sont également appelées machine virtuelle de type processus (Process
Virtual Machine) car elles isolent des services ou des applications. Dans ce type d’architecture, on trouve le
système d’exploitation qui est directement installé sur le serveur physique, puis le moniteur de machine virtuelle
(VMM) dont le rôle est de gérer les machines virtuelles, de leur attribuer des ressources et de conserver une
isolation entre elles (c’est, dans les faits, la couche de virtualisation). Enfin, audessus du VMM, on trouve les
invités qui sont le plus couramment des applications qui tournent avec la JVM Java ou le CLR du .net Frameworks.
Le gros point faible de ce type d’infrastructure, outre les éventuels problèmes de stabilité, reste les
performances. En effet, l’accès aux ressources matérielles se fait d’abord au travers du VMM puis de l’OS hôte ce
qui n’est, bien sûr, pas le chemin le moins sinueux.
Moniteur de machine virtuel hybride (VMM Virtual Machine Monitor)
Architecture VMM de Type hybride
Bien que la virtualisation de type 2 soit utilisée quasi quotidiennement par beaucoup sans le savoir, c’est une
autre technique de virtualisation qui a, et de loin, la préférence des équipes informatiques.
Dans un modèle hybride, le système d’exploitation hôte ainsi que le moniteur de virtualisation (VMM) accèdent
directement au matériel (bien qu’ils aient des niveaux d’accès différents aux composants matériels), alors que les
machines invitées tournent audessus de la couche de virtualisation.

En fait, si l’on y regarde d’un peu plus près, on constate que le VMM accède aux ressources matérielles au
travers du système hôte. Pour bien comprendre ce qui se passe, prenons l’exemple des cycles processeurs :
La machine hôte sollicite des cycles CPU dans son contexte, les transmet au service VMM qui les met à disposition
des machines virtuelles invitées qui en ont besoin ; il y a donc un phénomène d’allerretour permanent.
Toutefois, la différence majeure avec le modèle précèdent, qui fonctionne en mode utilisateur, tient au fait que le
VMM et l’OS hôte tournent tous les deux en mode noyau, ce qui augmente les performances.
Ce type de virtualisation, qui est actuellement celui utilisé par des produits comme Virtual Server ou
Vmware Server, n’est donc pas aussi performant que des machines physiques séparées. Par ailleurs,
bien que l’idée puisse apparaître séduisante, je vous déconseille d’utiliser ce modèle de virtualisation pour
des serveurs Exchange ou des bases de données, au risque d’être fort déçu par les performances globales
du système.
Moniteur de machine virtuel de Type 1 (VMM Virtual Machine Monitor)
Architecture VMM de Type 1
Le troisième type de virtualisation est le type 1 également connu sous le nom d’Hypervisor. Un hyperviseur est
une couche logicielle située entre le matériel et les systèmes d’exploitation des machines invitées. Le but de
cette couche intermédiaire est de créer des environnements d’exécution isolés, appelés partitions, dans
lesquelles les OS invités seront exécutés. En fait, chaque partition comprend ses propres ressources matérielles
(CPU, mémoire, périphérique…) et l’hyperviseur est chargé de contrôler et d’effectuer les arbitrages sur la couche
matérielle sousjacente.
Comme vous pouvez l’imaginer, ce modèle est de loin le plus performant et se trouve être celui utilisé par
Windows 2008 R2. Toutefois, il s’agit là d’un modèle générique que l’on retrouve dans les faits sous deux
variantes appelées Monolithic et Microkernelized.
Monolithic Hypervisor

Architecture "Monolithic Hypervisor"
Dans ce modèle, l’hyperviseur possède ses propres pilotes pour accéder au matériel sousjacent. Les machines
virtuelles (VM) invitées fonctionnent audessus de l’hyperviseur et accèdent au matériel par son intermédiaire.
Par ailleurs, l’une des machines virtuelles fournit la console d’administration qui permet de paramétrer et de
superviser toutes les machines tournant sur le système.
Le modèle Monolithic fournit d’excellentes performances mais peut présenter certaines faiblesses sur le plan de
la sécurité et de la stabilité. Au demeurant, cette faiblesse est structurelle car elle est due aux pilotes qui
tournent à un niveau très sensible. En fait, dans le cas où un programme malveillant serait en mesure de prendre
le contrôle du pilote, tout le système serait compromis.
L’autre faiblesse du modèle est la stabilité. En effet, le pilote qui est amené à être mis à jour (notamment pour la
prise en charge de nouveaux matériels) pourrait contenir des bugs ce qui mettrait en péril l’ensemble des
machines virtuelles invitées.
Microkernelized Hypervisor
Architecture "Microkernelized Hypervisor"
Dans ce modèle, qui est celui utilisé par Windows 2008 R2, les partitions correspondent à l’unité de base prise en
charge par l’hyperviseur. La première partition est dite parent alors que les suivantes seront dites enfants. Une
partition est composée d’un espace d’adressage physique, d’un ou de plusieurs processeurs logiques, ainsi que
des périphériques.
L’un des éléments capital de ce modèle est la pile de virtualisation (Virtualization stack) qui est un ensemble
d’éléments logiciels qui collabore avec l’hyperviseur pour supporter les machines virtuelles tournant sur le
système. C’est également elle qui se charge des opérations que n’effectue pas directement l’hyperviseur, comme
par exemple la mise à disposition des ressources (CPU, mémoire…) demandées par les partitions enfants.

L’avantage significatif de ce modèle, par rapport au précédent, est que les pilotes ne nécessitent pas de mise à
jour. De plus, et bien que légèrement moins performante que le modèle monolithic, cette architecture offre une
surface d’attaque plus mince et s’en trouve donc plus sécurisée.
HyperV
Architecture de virtualisation HyperV
Tout d’abord, il convient d’être informé que pour tirer parti des fonctionnalités de virtualisation décrites un peu
plus loin, il vous faudra disposer de processeurs intégrant les technologies AmdV ou Intel VT, et que cellesci
soient activées dans le gestionnaire du BIOS.
Afin de mieux appréhender le fonctionnement de cette architecture, nous allons nous intéresser aux différentes
partitions que l’on pourra créer sous HyperV.
Partition 1 Parent
Pour bien comprendre le schéma cidessus, il faut savoir que les quatre partitions présentées (1 parent et 3
enfants), fonctionnent toutes directement audessus de l’hyperviseur Windows.
La partition Parent, qui tourne en mode noyau, pourra disposer soit de la version complète de Windows 2008 R2,
soit de sa déclinaison core. Bien entendu, cette déclinaison présente l’énorme avantage d’avoir une surface
d’attaque plus mince et donc un meilleur niveau de sécurité.
D’autre part, les trois principaux éléments hébergés dans cette partition sont les suivants :
● Virtualisation Service Provider VSP : le VSP communique avec les pilotes de périphériques et agit
comme un multiplexeur fournissant un service de matériel. Par ailleurs, les requêtes sont transmises soit
directement au matériel par l’intermédiaire de son pilote, soit à des services natifs (comme le système de
fichier).
● Virtual Service Machine (VM service) : ce service permet d’administrer les machines virtuelles et leurs
processus de travail (un Worker Process par VM tournant sur le système).
● VMBus : au plus bas niveau de la partition, on trouve le VMBus qui permet de faire communiquer entres
elles les différentes VM tournant sur le système.

Partition 2 "Enfant avec un Système d’exploitation Intelligent"
Une VM invitée est considérée comme « intelligente » si son système d’exploitation a conscience de tourner au

dessus d’un hyperviseur. Dans ce cas, l’OS invité utilisera des interfaces optimisées ne nécessitant aucune
émulation. Windows 2008 R2, Vista ou Windows 7 font partie de ce type de systèmes, en revanche Windows
2003, qui est présenté dans le schéma précèdent, n’est que partiellement « intelligent » car il s’appuie sur un
pilote spécifique.
Virtual Service Client (VSC) : le VSC est un client tournant en mode noyau, qui agit comme un « solliciteur » de

services auprès d’un VSP. Par ailleurs, la notion fondamentale à retenir c’est que l’on aura toujours une paire
VSC/VSP pour tous les types de périphériques.
Pour bien comprendre le processus mis en œ uvre, prenons le cas d’une application qui souhaite écrire des
données sur disque :
● L’application sollicite le pilote du système de fichiers de la partition enfant.
● Le pilote du système de fichiers notifie au VSC qu’un accès matériel est demandé.
● Le VSC transmet la requête, au travers du VMBus, au VSP correspondant dans la partition Parent (la
fameuse paire VSC/VSP).
● Le VSP se charge d’écrire sur le disque au travers de la pile de stockage et du pilote de port approprié.
Enfin, d’après les informations communiquées par Microsoft, Windows 2008 R2 fournit les paires VSC/VSP pour le
stockage, le réseau, la vidéo et les périphériques clavier/souris. Pour les autres types de matériel, il faut
attendre que les éditeurs tiers développent leurs propres paires VSC/VSP.
Partition 3 "Enfant avec un Système d’exploitation ancien"
Pour les anciens systèmes d’exploitation, on dispose d’un fonctionnement équivalent à celui de Virtual Server qui
se contente d’émuler le matériel pris en charge par l’OS.
Partition 4 "Enfant avec un Système d’exploitation Linux"
Afin de permettre aux machines Linux de profiter de cette infrastructure avec des performances équivalentes à
celles de Windows 2008 R2, Microsoft a établi un partenariat avec XenSource (racheté par Citrix) afin de
développer un VSC pour Linux.
3. Liste des fonctionnalités d’HyperV
a. Sécurité
Un serveur hébergeant plusieurs machines virtuelles, appelé serveur consolidé, est exposé aux mêmes risques
qu’un serveur non consolidé mais le rend d’autant plus critique. En outre, ce regroupement de machines sur un
système unique pose également le problème de séparation du rôle d’administrateur. HyperV répond à ces
différentes problématiques de sécurité de la manière suivante :
● Partitionnement fort : une machine virtuelle, s’exécutant sur un serveur physique, fonctionne comme
un conteneur de système d’exploitation indépendant et totalement isolé des autres machines
virtuelles.
● Sécurité au niveau matériel : les dernières générations de serveurs disposent d’une fonctionnalité
appelée prévention d’exécution de données (DEP) qui contribue à limiter l’exécution de vers et autres
virus.
● Sécurité réseau : traduction automatique d’adresses réseaux (NAT), parefeu ou encore protection de
l’accès réseau (NAP) font partie des fonctionnalités réseau permettant de protéger au mieux les
machines virtuelles.

HyperV permet de créer un environnement dans lequel il est possible de configurer une charge de travail et un
profil de sécurité spécifique à chaque système d’exploitation. Il empêche également l’interaction entre les VM et
le système hôte, limite le niveau de privilège dévolu au service exécutant chaque VM et assure ainsi qu’une
machine virtuelle défaillante ne compromette pas les autres.
b. Isolation
Un des défis de la virtualisation est de faire cohabiter sur la même machine physique des serveurs virtuels
ayant des besoins totalement différents en ressources. HyperV propose plusieurs fonctionnalités permettant
de rendre plus efficace l’utilisation des ressources disponibles :
● Attribution de mémoire : il est désormais possible d’attribuer aux VM une quantité maximale et
minimale garantie de RAM. Cette fonctionnalité permet aux administrateurs de créer une configuration
qui équilibre les besoins de chaque VM au regard des performances globales du serveur.
● Ajout dynamique de matériel : une des grandes limitations des systèmes de virtualisation actuel est
l’ajout de matériel aux machines virtuelles. HyperV permet d’ajouter dynamiquement des processeurs
logiques, de la mémoire, des cartes réseaux ou bien encore de l’espace disque afin de pouvoir
disposer d’un système plus flexible avec un minimum d’interruption de services.
● Flexibilité réseau : HyperV fournit aux VM des fonctionnalités de parefeu, de NAT et de Vlan
permettant de répondre à des stratégies de sécurité réseau spécifiques.
Toutes ces nouvelles capacités permettent de mieux répondre aux variations de charges constatées selon les
périodes d’activités. En effet, les fins de mois sont par exemple des périodes de forte activité des serveurs
hébergeant des applications comptables et il sera désormais possible d’attribuer à ces machines plus de
ressources durant ces périodes sans pour autant redémarrer le système d’exploitation invité.
c. Performances
Les progrès dans la conception et l’intégration au matériel gérant la virtualisation permettent de gérer des
charges de travail plus contraignantes tout en assurant une meilleure flexibilité dans la répartition des
ressources. Les principales améliorations sont les suivantes :
● L’architecture de virtualisation à faible surcharge basée sur la technologie d’hyperviseur 64 Bits (Intel
VT ou Amd « Pacifica ») permet d’améliorer les performances des systèmes d’exploitation invités.
● La prise en charge multinoyau permet aux machines virtuelles de disposer d’un maximum de 64
processeurs logiques.
● HyperV s’exécute donc sur l’architecture 64 bits de Windows 2008 R2 afin de mettre à disposition un
maximum de mémoire aux machines virtuelles. En revanche, il est possible de faire cohabiter des
systèmes invités 32 ou 64 bits sur la même machine physique.
● L’installation d’HyperV peut se faire sur la version noyau (core) de Windows 2008 R2 afin de mettre à
disposition des machines virtuelles un maximum de capacité de traitement.
● Jusqu’à présent l’accès aux ressources disques des machines clientes ne pouvait se faire qu’au travers
de l’hôte, ce qui ne permettait pas d’avoir de bonnes performances d’entrée/sortie. HyperV permet
désormais un accès direct aux disques (locaux, SAN) ce qui permet d’envisager la virtualisation
d’applications telles que SQL Server ou Exchange.
d. Gestion simplifiée
Afin de pouvoir déployer des solutions de virtualisation autant dans les centres d’hébergement que dans les
succursales, il convient de disposer de moyens centralisés de gestion de ces infrastructures. HyperV permet de
répondre à ces contraintes grâce aux éléments suivants :
● Extensibilité : interfaçage avec d’autres outils de la gamme Microsoft tels que Microsoft System
Center Operations Manager (SCOM) ou Microsoft System Center Virtual Machine Manager

(SCVMM), afin d’assurer une gestion centralisée et une supervision des systèmes.
● Interface WMI : intégration d’une nouvelle interface WMI (Windows Management Instrumentation) qui

permet d’accéder à la configuration du système par des scripts (PowerShell ou autre).
● Stratégie de groupe : support de l’Active Directory (GPO) afin de paramétrer la machine hôte ou les

machines virtuelles.
4. Allocation dynamique de la mémoire physique
a. Introduction
Dans un environnement virtualisé, la gestion de la mémoire physique du serveur hôte est un élément clé
permettant une consolidation optimale.
Jusqu’à présent, HyperV n’offrait aucune technique d’optimisation de la mémoire ce qui contraignait les
administrateurs à distribuer la mémoire de façon statique aux VM. En d’autres termes, chaque VM consomme
toute la mémoire qui lui est allouée lors de son démarrage même si sa charge de travail ne le nécessite pas à
cet instant.
Supposons que nous disposions d’un serveur hôte avec 16 Go de mémoire ; la partition parente consommant
environ 2 Go (un peu moins en mode core), cela nous laisse environ 14 Go pour mettre nos VM (un peu moins
en réalité du à l’overhead).
Supposons également que nous ayons deux VM, une avec 4 Go de RAM et l’autre avec 8 Go (préconisés par les

éditeurs de nos applications).
Au démarrage de ces machines, 12 Go de mémoire sont immédiatement consommés alors qu’aucune application
n’est encore lancée. Pire encore, on constate souvent que même après le démarrage des applications on est
encore loin de consommer toute la mémoire disponible… cela sent le gaspillage !
Dans ces conditions, le dimensionnement correct d’une infrastructure virtuelle peut s’avérer complexe d’autant
qu’il faut composer avec un certain nombre d’autres contraintes au rang desquelles on trouve :
● Le coût de la mémoire serveur
● Évaluer précisément les besoins en mémoire d’une application est souvent un « parcours du
combattant »
● La consommation mémoire des applications varie dans le temps

● Le manque de mémoire peut devenir un goulet d’étranglement, et dégrader les performances
● Une surallocation mémoire réduit le nombre de VM hébergées sur un hôte
● …
La nouvelle fonctionnalité de mémoire dynamique, lancée avec le Service Pack 1 de Windows 2008 R2, permet

de gérer la mémoire disponible comme un pool unique et de l’allouer dynamiquement aux VM en fonction de
leurs besoins réels (ajout et retrait gérés directement par l’hyperviseur).
Au démarrage de l’hôte, la partition parente va consommer l’espace dont elle a besoin et le reste de la RAM
sera disponible pour les machines virtuelles (pool de 14 Go dans notre exemple).
Au démarrage des VM cellesci se voient allouer 1 Go de mémoire (paramétrable pour chaque VM) ; ce qui est
généralement suffisant (hors applications) et nous laisse encore 12 Go de libre pour commencer à envisager
l’ajout d’autres VM…
Au lancement des applications la consommation mémoire va croître régulièrement pour atteindre un pic en

pleine charge qui est généralement très inférieur aux préconisations des éditeurs (qui prennent de la marge)…
Il est désormais possible d’envisager l’ajout de machines supplémentaires tout en conservant une marge
suffisante pour un éventuel surcroît d’activité des VM existantes (VM1 et VM2 dans notre cas).
Enfin, si la quantité de mémoire nécessaire au fonctionnement des machines virtuelles diminue, celleci est
récupérée, remise dans le pool, et réattribuée en fonction des besoins.
b. Prérequis
● Partition parente :
■ Windows Server 2008 R2 SP1
■ Microsoft HyperV Server 2008 R2 SP1
- 10 - © ENI Editions - All rights reserved - adamo diarra

● Machines virtuelles :
■ 32bit ou 64bit
■ Windows Server 2003 & 2003 R2, 2008 & 2008 R2
❍ Service Pack 1 au sein des VM pour Windows Server 2008 R2
❍ Service Pack 2 au sein des VM pour Windows Server 2003 / 2008 avec hotfix
http://support.microsoft.com/kb/2230887
■ Windows Vista & Windows 7
❍ Editions Enterprise & Ultimate
❍ Service Pack 2 au sein des VM pour Vista
● Mettre à jour les services d’intégration HyperV sur vos VM
c. Principaux paramètres du gestionnaire HyperV
La gestion dynamique de la mémoire virtuelle se matérialise dans le Gestionnaire HyperV par l’apparition de
trois nouvelles colonnes :
● Mémoire affectée (Assigned Memory) :
■ Mémoire physique attribuée par HyperV à une VM ; c’est la valeur réellement « vue » par le
système d’exploitation invité.
■ Comprise entre les valeurs Min et Max des propriétés de mémoire dynamique de la VM
■ Mémoire affectée = Demande de mémoire + Mémoire tampon
● Demande de mémoire (Memory Demand) :
■ Mémoire totale validée par le système d’exploitation invité (Commited Memory)
■ Peut être supérieure à la mémoire affectée ; dans ce cas la VM utilise son fichier de pagination
● État de la mémoire OK, Faible, Avertissement (Memory Status Ok, Low, Warning) :
■ OK : Mémoire affectée > Demande de mémoire + Mémoire tampon
❍ Usuellement : taux d’utilisation < 80 %
■ Faible : Mémoire affectée < Demande de mémoire + Mémoire tampon
❍ Usuellement : 80 % < taux d’utilisation < 90 %
■ Avertissement : Mémoire affectée < Demande de mémoire
© ENI Editions - All rights reserved - adamo diarra - 11 -

❍ Usuellement : taux d’utilisation > 90 %
Si les colonnes « demande mémoire et état mémoire » sont vides, le serveur virtuel n’est pas
paramétré pour utiliser la gestion dynamique de la mémoire virtuelle.
d. Principaux paramètres de configuration des VM
Il n’existe pas de paramétrage global réalisable au niveau de l’hôte HyperV ; la mémoire dynamique doit être
activée et paramétrée directement au niveau de la machine virtuelle. De plus, par défaut, une machine virtuelle
nouvellement créée utilisera une allocation mémoire statique.
Mémoire RAM de démarrage (Startup RAM) :
Mémoire physique attribuée initialement par HyperV à la VM. Cette valeur est assignée instantanément à partir
du pool de mémoire partagée.
Comme la gestion dynamique de la mémoire n’est effective qu’après le chargement du système (au

chargement des composants d’intégration), il est important de positionner suffisamment de mémoire
au démarrage pour charger le système d’exploitation et les éventuelles applications qui démarrent
automatiquement. Toutefois, cette valeur doit rester la plus basse possible afin que la gestion dynamique
soit la plus efficiente possible et permette d’accroître le ratio de consolidation.
Mémoire RAM maximale (Maximum RAM) :

Ce paramètre spécifie la quantité maximum de mémoire que la machine virtuelle est autorisée à utiliser. Cette
valeur oscille entre la valeur de démarrage et peut aller jusqu’à 64 Go.
Bien qu’il soit possible d’allouer 64 Go à une VM dans sa configuration, la mémoire réellement utilisée
dépendra du système d’exploitation installé.
Mémoire tampon (Memory Buffer) :
Comme nous l’avons évoqué précédemment, « Dynamic Memory » détermine la quantité de RAM nécessaire
dans la machine virtuelle en calculant la « pression mémoire ». Pour réaliser ce calcul, HyperV récupère « la
mémoire totale engagée » (compteur de performance) par le système d’exploitation invité et détermine un ratio
entre ce que demande la machine virtuelle et ce dont elle dispose déjà.
La mémoire qui sera effectivement assignée par HyperV à la machine virtuelle est donc la somme entre « la
mémoire totale engagée » plus un espace tampon paramétrable.
L’espace tampon est un espace mémoire supplémentaire alloué à la VM, permettant de répondre à une
variation brutale de la mémoire nécessaire.
Le système d’exploitation de la machine virtuelle met généralement cette mémoire complémentaire en cache
afin d’améliorer les performances globales du système.
La valeur par défaut est de 20 %.
Poids de la mémoire (Memory weight) :
Par défaut toutes les machines virtuelles sont considérées comme équivalentes au regard de l’allocation
dynamique de mémoire. Bien que ce raisonnement soit vérifié quand la mémoire disponible sur l’hôte est
abondante, que ce passera t’il en cas de pénurie ? Imaginons qu’il y ait sur le même hôte un serveur
hautement critique avec l’ERP, et un serveur de distribution de package utilisé uniquement par le service
informatique. Estil souhaitable qu’ils soient traités sur un pied d’égalité ? évidemment non. Dés lors, il est
possible d’attribuer un poids pour chacune des machines virtuelles afin de « servir » en priorité les machines
critiques au détriment des autres.
Dans le cas où une machine à haute priorité demande de la mémoire supplémentaire et que l’hôte
n’en dispose plus, HyperV retire de la mémoire aux machines de faible priorité (memory ballooning)
pour la réattribuer à notre machine critique.
e. Architecture
Schéma simplifié

Composants mis en œuvre dans la partition parente
La partition parente est composée des éléments suivants :
Dynamic Memory Virtualization Service Provider (DMVSP)
Le DMVSP reçoit les données de pression mémoire du DMVSC et les redirige vers le Memory Balancer (la
communication se fait via le VMBus).
À chaque DMVSC (dans la VM), correspond un DMVSP (dans la partition parente).
Memory Balancer
Le Memory Balancer enregistre la pression mémoire dans la partition parente ainsi que dans chaque machine
virtuelle.
Lorsque de la mémoire doit être réallouée, le « Memory Balancer » commence par initier une libération de
mémoire en coordination avec les VSP.
Lorsqu’une quantité suffisante de mémoire a été libérée, elle est ajoutée aux machines en ayant besoin.
Composants mis en œuvre dans la partition enfant
Dynamic Memory est disponible pour les machines virtuelles disposant de composants d’intégration.
Les systèmes au sein des machines virtuelles et de la partition parente fonctionnent en collaboration.
Dynamic Memory Virtualization Service Client (DMVSC)
Le DMVSC est installé au sein des machines virtuelles à l’installation des IC, mais il n’est activé au démarrage
de la VM que si la mémoire est configurée en mode allocation dynamique.

Le DMVSC mesure la pression sur la mémoire au sein des machines virtuelles et la communique au VSP.
Pression mémoire
La mesure dynamique de la « pression mémoire » est un concept qui décrit la quantité de mémoire réellement
demandée par la VM. Il s’agit d’un ratio entre la mémoire demandée et celle déjà disponible.
Exemple de calcul de la pression mémoire :
Current Commit Charge÷Physical Memory=Memory pressure (Niveau de pression mémoire)
Soit 735268 ÷ 788024=93 %
Un niveau de pression de 93 % signifie :
● La machine virtuelle utilise 93 % de la mémoire qui lui est assignée.
● Elle dispose donc de 7 % de marge.
Si la pression mémoire dépasse les 100 %, la marge disponible devient négative et la machine virtuelle pagine.
Plage de pression mémoire
Chaque machine virtuelle dispose d’une plage de pression bornée par une valeur minimale et maximale.

Lorsque la pression courante se situe au sein de la plage de pression, aucune mémoire n’est ajoutée ou
enlevée.
Le processus de suppression de la mémoire démarre lorsque la pression franchit à la baisse la valeur minimale
de la plage.
Le processus d’ajout de la mémoire démarre lorsque la pression franchit à la hausse la valeur maximale de la
plage.
La plage de pression est calculée à partir des données de pression historiques de chaque machine virtuelle.
Mécanismes d’ajout de mémoire et de « ballooning »
L’ajout de mémoire dynamique à la VM est effectué à la demande si le noyau de celleci supporte l’ajout à
chaud. Au contraire, le VSC peut réclamer à la VM la mémoire inutilisée et la restituer à la partition parente afin
de pouvoir la réallouer à d’autres machines.
Fonctionnement mis en œuvre dans la partition enfant
Il existe principalement deux techniques de gestion de la mémoire dynamique.
Certaines technologies concurrentes d’optimisation mémoire ont pour principe de « mentir » à la machine
virtuelle…
Prenons l’exemple d’une machine virtuelle configurée avec 8 Go de mémoire.
Au démarrage du système d’exploitation, celuici détecte effectivement 8 Go de mémoire ; du coup, les
applications qui tournent dans cette VM voient également 8 Go de mémoire. En revanche la mémoire réellement
attribuée par l’hyperviseur (et utilisable par la VM) n’est que de 4 Go.
Si la machine virtuelle nécessite plus de 4 Go de mémoire pour fonctionner, l’hyperviseur pourra lui allouer
jusqu’à 8 Go.
Cette solution technique couramment utilisée n’est pas celle retenue par Microsoft pour HyperV.
HyperV s’appuie sur la capacité du système d’exploitation invité à ajouter de la mémoire à chaud en fonction
de la demande. En d’autres termes la machine virtuelle voit réellement la mémoire dont elle dispose à l’instant

« T ».
Cette méthode implique donc de bien connaître les besoins en mémoire nécessaires lors du démarrage d’une
machine virtuelle.
Prenons un exemple : Supposons que nous configurions la mémoire de démarrage sur 768 Mo avec un
maximum de 4 Go. Supposons également que l’on projette d’installer sur cette machine virtuelle un serveur
Exchange ou SQL et que la mémoire minimale nécessaire soit de 1 Go… le programme d’installation ne peut pas
s’exécuter car il ne détecte que 768 Mo de mémoire disponible.
En clair il ne faut pas trop sousdimensionner la mémoire de démarrage au risque de rencontrer quelques effets
de bords, mais il ne faut pas non plus la surdimensionner afin de ne pas la gaspiller.
En somme, et comme souvent, tout est affaire de compromis…
Fonctionnement de l’ajout et du retrait de mémoire dans une machine virtuelle
La mémoire est ajoutée ou supprimée via un pilote VMBUS (synthetic memory driver) :

Ce pilote utilise les techniques dites de « HotAdd Enlightenment » (Ajout à chaud) et de « Memory Ballooning
» (mémoire ballon) pour ajouter ou supprimer dynamiquement de la mémoire.
Ajout de mémoire à chaud
Lorsqu’une machine virtuelle a besoin de plus de mémoire un processus en 4 étapes est activé :
● Étape 1 : Le GMO (Global Memory Object) essaye de fournir la mémoire depuis le tampon où elle est
déjà préallouée pour être mise à disposition plus rapidement.
Si suffisamment de mémoire tampon est disponible, elle l’obtient.
● Étape 2 : Sinon, le GMO essaye de la fournir à partir de la mémoire physique de l’hôte.
Si suffisamment de mémoire physique est disponible, elle l’obtient.
● Étape 3 : Sinon, le GMO demande au Memory Balancer de retirer de la mémoire aux autres VM et de la
redistribuer.
Si suffisamment de mémoire peut être libérée, elle l’obtient.
Plus la priorité d’une VM est importante, moins elle est pénalisée lors de la réallocation de la mémoire
● Étape 4 : En dernier ressort la VM utilise son fichier d’échange (pagefile)
■ Schéma de principe :

■ Mémoire virtuelle vue depuis le gestionnaire HyperV
■ Mémoire vue depuis l’OS invité
La mémoire détectée par le système d’exploitation invité, correspond bien à la mémoire affectée par
l’hyperviseur.
Lorsque la charge augmente dans la VM, et que le besoin en mémoire s’accroît, HyperV détecte une « pression
mémoire » supplémentaire (l’état mémoire passe à « Faible » dans le gestionnaire HyperV).
HyperV répond à cette demande en ajoutant de la mémoire à la VM et le système d’exploitation invité ajoute à
chaud cette mémoire supplémentaire.
■ Schéma de principe

Retrait de mémoire
Étant donné qu’il n’est pas possible de retirer à chaud de la mémoire à une machine sans risquer
de planter le système, c’est un autre mécanisme qui sera utilisé par HyperV pour récupérer la
mémoire inutilisée… le « ballooning ».
Lorsque le DMVSC détecte que la « pression mémoire » au sein de la machine virtuelle baisse
(moins de charge, arrêt de certaines applications…), cela signifie qu’une partie de la mémoire
allouée peut repartir dans le « pool » disponible pour y être redistribuée.
Comme le DMVSC ne peut pas demander directement au système d’exploitation de la machine
virtuelle de « rendre » de la mémoire, le retrait est réalisé grâce à un mécanisme dit de « mémoire
ballon (memory ballooning) ». Le DMVSC réclame au noyau de la machine virtuelle l’allocation de
mémoire afin de l’obliger à solliciter son algorithme de gestion mémoire (« il gongle un ballon »
pour mettre le système en pénurie de mémoire).

Le DMVSC indiquera ensuite à la partition parente (via son DMVSP) les pages mémoire «
récupérables », qui seront remises dans le « pool » afin d’être réattribuées.
■ Schéma de principe
La machine virtuelle continue de voir la même quantité de mémoire (1 763 Mo), alors qu’une partie de

celleci a été récupérée par l’hyperviseur (la mémoire affectée n’est plus que de 1 024 Mo, au lieu de
1 764 Mo).
Si la VM réclame de nouveau de la RAM, le DMVSC « rendra » la mémoire à l’OS invité en « dégonflant
» le ballon.
Stratégie de gestion de la mémoire dynamique virtuelle

Pourquoi utiliser la mémoire dynamique ? Comment bien l’utiliser ? Voilà au moins deux questions qu’il convient
de se poser avant sa mise en œ uvre…
Pour rappel, l’activation de la mémoire dynamique est facultative et se gère VM par VM.
Bien qu’il existe plusieurs statégies de gestion mémoire, les plus utilisées sont les suivantes :
Désactivation (allocation mémoire statique)
Certaines applications ne supportent pas la mémoire dynamique.
L’utilisation de mémoire dynamique peut créer la confusion chez certains administrateurs système.
Optimisation
Dans cette approche, on affecte la mémoire de démarrage en fonction du système d’exploitation invité et des
applications installées. On positionne le maximum avec des valeurs réalistes (issues du retour d’expérience).
Par exemple pour un serveur SharePoint, on peut positionner 2 Go au démarrage et aller jusqu’à 8 Go de
mémoire au maximum.
Élastique
Dans cette approche, on alloue le minimum de mémoire de démarrage et on positionne la mémoire maximale en
fonction de ce que supporte le système d’exploitation invité.
Dans cette approche de type « cloud » on autorise l’utilisateur final à consommer toutes la mémoire dont il
aurait besoin.
Cette souplesse implique que les utilisateurs concernés savent ce qu’ils font et les applications installées n’ont
pas de fuite mémoire.
Architecture mémoire NUMA
L’architecture NUMA (No Uniform Memory Access ou No Uniform Memory Architecture) est une des deux
techniques multiprocesseurs utilisées dans les serveurs (avec le SMP). Cette technologie permet de regrouper
des groupes de processeurs utilisant leur propre mémoire locale, reliés entre eux par des bus spécifiques
(hyperbus très rapides). Dans un système NUMA, l’accès à la mémoire est plus rapide pour un processeur vers
sa propre mémoire que vers les autres mémoires du système.

La mémoire et le thread d’exécution de la VM utilisent le même nœud NUMA
HyperV a « connaissance » de l’architecture matérielle et essaiera toujours de conserver le « thread »
d’exécution de la VM sur le même nœ ud NUMA que la mémoire.
Toutefois, la gestion dynamique de la mémoire virtuelle vient un peu compliquer les choses…

La machine virtuelle utilise de la mémoire sur un autre nœud NUMA
Il peut arriver que la mémoire disponible sur un nœ ud NUMA soit insuffisante pour répondre au besoin d’une
VM ; dans ce cas l’allocation mémoire se fait sur un autre nœ ud NUMA.
Dans cette situation, le processeur exécutant la VM doit passer par un bus rapide (Back Channel) chaque fois
qu’il a besoin d’utiliser la mémoire allouée sur l’autre nœ ud NUMA… ce qui peut impacter les performances
globales du système. Il est donc possible de désactiver le fractionnement NUMA dans les paramètres HyperV
de l’hôte.
Une fois cette option désactivée, une machine virtuelle ne pourra pas recevoir plus de mémoire qu’il
n’y en a de disponible sur le même nœ ud NUMA.
f. Recommandations pour les applications Microsoft usuelles
Windows 7/Windows Vista en mode VDI :

Il est clairement indispensable d’utiliser la gestion dynamique de la mémoire virtuelle dés lors que l’on souhaite
mettre en œ uvre une solution de VDI.
Bien qu’il n’existe pas réellement de guide précis sur la configuration adéquate, on peut considérer les
paramètres suivants pour une utilisation VDI de type bureautique :
● Mémoire de démarrage : 1 Go (permet de démarrer le système et le client de messagerie par exemple)
● Mémoire maximum : 4 Go
● Mémoire tampon : valeur par défaut (20 %)
● Poids de la mémoire : valeur par défaut
Pour des usages plus intensifs (CAO), il conviendra de valider les paramètres adéquates par un lot
pilote avant de lancer un éventuel déploiement.
SQL Server :
L’ensemble des versions de SQL Server supporte la mémoire dynamique, en revanche seules certaines éditions
savent utiliser la mémoire supplémentaire ajoutée à la volée.
● SQL 2005 Enterprise
● SQL 2008 Enterprise/ Datacenter
● SQL 2008 R2 Enterprise/ Datacenter
Les autres éditions n’utiliseront que la mémoire allouée au démarrage.
Les paramètres suivants sont adaptés dans la majorité des cas :
● Mémoire de démarrage : 1 Go (ajouter à cette valeur la mémoire nécessaire au démarrage basique des
applications).
● Mémoire maximale : En fonction de la mémoire disponible sur l’hôte, allouer le maximum supporté par
l’édition de SQL utilisée.
● Mémoire tampon : SQL utilise son propre cache ; positionner le tampon sur « faible ».
● Poids de la mémoire : À évaluer en fonction de l’importance de la machine… généralement plus haut
que la valeur par défaut.
Exchange Server 2007 et 2010 :
Le rôle de « serveur de boîte aux lettres » ne sait pas utiliser la mémoire dynamique. Il n’utilise que la mémoire
disponible au démarrage. Pour les autres rôles… pas de support officiel.
Il est donc conseillé d’utiliser de la mémoire statique.
SharePoint 2010 et CRM Dynamics 2011
Pas de préconisation de Microsoft pour l’instant. Utiliser les mêmes contraintes que pour un serveur SQL donne
généralement de bons résultats.
g. Réservation mémoire pour la partition parente
HyperV calcule automatiquement la quantité de mémoire nécessaire pour le bon fonctionnement de la partition
parente. Cette réservation prend en compte les services de virtualisation, mais aussi le service de cluster s’il

est implémenté.
Toutefois, si d’autres fonctionnalités ont été activées, ou d’autres produits installés dans la partition parente

(ce qui est fortement déconseillé par Microsoft), la quantité de mémoire réservée peut s’avérer insuffisante. Il
est donc possible de spécifier manuellement la quantité de mémoire à réserver en modifiant la base de registre.
Lancer regedit, sous HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization créer une

entrée de type DWORD nommée memoryreserve. Éditer cette entrée de registre et spécifier la quantité
mémoire à réserver (valeur décimale en Mo : 2 048 pour 2 Go par exemple).
5. System Center Virtual Machine Manager (SCVMM)
L’outil de gestion des machines virtuelles, intégré à Windows 2008 R2, n’est pas adapté à de larges
implémentations d’infrastructures virtuelles. Pour pallier cette faiblesse, Microsoft a développé un produit
spécifique pour administrer de manière centralisée toutes les machines virtuelles, qu’elles soient sous Virtual
Server 2005 ou sous HyperV. Par ailleurs, outre la gestion des ressources, SCVMM permet également un
déploiement rapide sur une infrastructure SAN, le déplacement des VM à chaud ou encore la transformation de
machines physiques en machines virtuelles (P2V).
Pour prendre en charge les nouvelles fonctionnalités apportées par le service pack 1 de Windows 2008 R2,
SCVMM a également fait l’objet d’une mise à jour (SCVMM 2008 R2 SP1). En outre, si votre SCVMM est connecté à
SCOM 2007 via le PRO (Performance and Resource Optimization) il faudra également prévoir une mise à niveau de
celuici.
La gestion dynamique de la mémoire virtuelle impacte la manière dont SCVMM calcule le placement optimal des
machines sur les hôtes HyperV :
● La migration d’une VM utilisant la mémoire dynamique vers un hôte qui ne le supporte pas ne sera pas
possible.
● Si une machine virtuelle dispose de « X » Go de mémoire, alors elle ne pourra migrer que vers un hôte
disposant également d’au moins « X » Go de libre.
● La migration d’une machine virtuelle arrêtée ne pourra se faire que si l’hôte de destination possède
suffisamment de mémoire libre (au minimum la mémoire de démarrage).
Configuration de la mémoire dynamique virtuelle depuis la console SCVMM
Configuration d’une VM depuis le gestionnaire HyperV :

Configuration d’une VM depuis SCVMM :

Bien que les paramètres disponibles restent les mêmes, quelques éléments de terminologie ont été modifiés :
Terminologie utilisée dans le gestionnaire Terminologie utilisée dans SCVMM
HyperV
Mémoire RAM de démarrage Mémoire de démarrage
Mémoire RAM maximale Mémoire maximale
Mémoire tampon Mémoire tampon
Poids de la mémoire Affecter une priorité lors de l’allocation de
ressources mémoire sur l’hôte (dans le menu
Priorité)
Enfin, le curseur permettant de positionner le « poids de la mémoire » a été remplacé par des boutons radio.

Plateforme d’application Web
Windows Server 2008 R2 livre une plateforme unifiée pour la publication Web qui intègre Internet Information
Services 7.5 (IIS7.5), ASP.NET et Windows Communication Foundation.
Les principales évolutions de cette nouvelle mouture sont les suivantes :
1. Outils de gestion améliorés
Le nouveau gestionnaire IIS est un outil de gestion du serveur Web plus efficace. Il propose une prise en charge
des paramètres de configuration d’IIS et d’ASP.NET, des données utilisateurs et des informations de diagnostic
d’exécution. La nouvelle interface utilisateurs permet aux administrateurs de sites Web de déléguer le contrôle
administratif aux développeurs ou aux propriétaires du contenu d’un site, réduisant ainsi les interventions des
administrateurs. La nouvelle interface du gestionnaire IIS prend également en charge l’administration à distance
via http. Un nouvel outil de ligne de commande, (appcmd), est également inclus pour gérer et administrer les
serveurs, les sites et les applications Web.
2. Installation modulaire
IIS7.5 est composé de plus de 40 modules séparés. Seule une partie des modules est installée par défaut et les
administrateurs peuvent installer ou supprimer indépendamment n’importe quel module. Cette approche permet
d’installer uniquement les options dont on a besoin et réduit ainsi le nombre de fonctionnalités qui doivent être
gérées et mises à jour. Enfin, seuls les modules nécessaires s’exécutent, ce qui améliore la sécurité en réduisant
la surface d’attaque du serveur web.
3. Modèle de configuration distribuée
IIS7.5 introduit des améliorations majeures au mode de stockage et d’accès aux données. L’un des objectifs
principaux de cette nouvelle version est de permettre la configuration distribuée des paramètres d’IIS, ce qui
donne aux administrateurs la possibilité d’indiquer les paramètres de configuration d’IIS dans les fichiers qui sont
enregistrés avec leur code et leur contenu. La configuration distribuée permet aux administrateurs de spécifier
les paramètres de configuration pour un site ou une application web dans le même annuaire que celui dans
lequel le code ou le contenu est enregistré. En spécifiant les paramètres de configuration dans un fichier unique,
la configuration distribuée autorise les administrateurs à déléguer l’administration des fonctionnalités de site
web sélectionnées ou des applications web. Les administrateurs peuvent également verrouiller des paramètres
de configuration spécifiques pour qu’ils ne puissent pas être modifiés par quelqu’un d’autre. En utilisant une
configuration distribuée, les paramètres de configuration pour un site ou pour une application spécifique peuvent
être copiés d’un serveur à l’autre quand l’application est déplacée du développement au test, puis finalement à
la production.
4. Dépannage et diagnostic
IIS7.5 facilite le dépannage du serveur web grâce au diagnostic incorporé et à la prise en charge du traçage qui
permettent à l’administrateur de scruter le serveur Web et de consulter des informations de diagnostic détaillées
en temps réel. Le diagnostic et le dépannage permettent à un développeur ou un administrateur de voir les
requêtes qui s’exécutent sur le serveur web, ce qui permet de déterminer, par exemple, la requête dans un
processus de travail qui consomme 100 % de l’UC.
5. Déploiement simplifié des applications
IIS7.5 permet aux paramètres de configuration d’IIS d’être enregistrés dans des fichiers web.config, ce qui
facilite énormément l’utilisation de scripts (xcopy, robocopy…) pour copier des applications sur plusieurs serveurs
web, et permet de réduire la réplication, la synchronisation manuelle et autres tâches de configuration coûteuses
en temps et sujettes aux erreurs.

Gestion des serveurs
De la rationalisation de nouveaux serveurs à l’automatisation des tâches de gestion répétitives, la simplification
des tâches quotidiennes d’administration est un thème central dans Windows Server 2008 R2. Les outils de
gestion centralisés et les fonctionnalités d’automatisation permettent de gérer plus facilement les serveurs,
services et imprimantes réseau, situés localement ou dans les succursales.
1. Assistant de configuration Initial (Initial Configuration Task ICT)
L’installation de Windows 2008 R2 s’opère de la manière suivante :
● Choix du mode d’installation :
Il est uniquement possible de sélectionner une version du système d’exploitation avec un type
d’architecture x64. Cela rejoint une certaine volonté de Microsoft à ne plus éditer de système
d’exploitation serveur sur architecture x86, les processeurs actuels étant pleinement compatibles avec ce
nouveau mode d’adressage.
● Type d’installation :

À ce stade il est possible de procéder à une mise à jour de l’OS en cours ou de sélectionner une nouvelle
installation.
Les scénarios de mise à jour supportés par Microsoft sont les suivants :
De Windows Server 2003 SP2/R2 Vers Windows Server 2008 R2
Datacenter Datacenter
Enterprise Enterprise, Datacenter
Standard Standard, Enterprise
De Windows Server 2008 RTMSP1/SP2 Vers Windows Server 2008 R2
Datacenter Core Datacenter Core
Enterprise Core Enterprise Core, Datacenter Core
Foundation SP2 Standard
Standard Core Standard Core, Enterprise Core
Web Standard, Web
Web Core Standard Core, Web Core
De Windows Server 2008 RC/IDS/RTM Vers Windows Server 2008 R2
Datacenter Core Datacenter Core

Enterprise Core Enterprise Core, Datacenter Core
Foundation Standard, Foundation
Standard Core Standard Core, Enterprise Core
Web Standard, Web
Web Core Standard Core, Web Core
● Choix de l’emplacement du système :
● Définition du mot de passe de l’administrateur :

● Enfin le reste de la configuration s’effectue à l’aide de l’assistant Tâche de configuration initiale (Initial
Configuration Task, ICT) dans lequel on va spécifier les éléments suivants :
■ Activation de Windows.
■ Fuseau horaire, configuration réseau, appartenance au domaine, nom de l’ordinateur…
■ Mise à jour du serveur et configuration des mises à jour automatiques ou manuelles.
■ Ajout des rôles et des fonctionnalités.
■ Configuration du firewall, activation du bureau à distance.

Par ailleurs, il est également à noter que l’ICT n’est pas disponible dans le cas d’une mise à jour depuis
une version antérieure de Windows.
2. Console d’administration du serveur (Server Manager)
Windows Server 2008 R2 propose une seule console unifiée pour gérer la configuration et les informations
système d’un serveur. Cette nouvelle interface d’administration affiche l’état, identifie les problèmes de
configuration et gère tous les rôles installés sur le serveur. Le volet hiérarchie du gestionnaire de serveur
contient des nœ uds extensibles pour atteindre directement des consoles, afin de gérer des rôles spécifiques ou
de trouver des options de sauvegarde et de récupération après incident.

Assistants de configuration
La plupart des tâches de configuration courantes, telles que la configuration ou la suppression d’un ou plusieurs
rôles, peuvent maintenant être réalisées en une seule opération grâce aux nouveaux assistants. Windows
Server 2008 R2 exécute des vérifications de dépendances à mesure que l’utilisateur progresse dans les étapes,
s’assurant que tous les services requis par un rôle sélectionné sont installés et qu’aucun service susceptible
d’être requis n’est supprimé.
Restriction d’utilisation du gestionnaire de serveur
Le gestionnaire de serveur ne peut pas être utilisé pour gérer des versions antérieures à Windows 2008.
Il peut être installé sur un ordinateur équipé de Windows 7 mais n’est pas disponible dans une installation de
type core.
3. Administration du serveur en ligne de commande
Windows 2008 R2 fournit également un puissant outil de ligne de commande appelé ServerManagerCmd.exe
qui permet de réaliser les tâches ciaprès :
● Affichage de la liste des rôles et fonctionnalités installés.
● Ajout de rôle et de fonctionnalité, soit individuellement, soit automatiquement, à l’aide d’un fichier de
configuration au format Xml.
● Modification du paramétrage par défaut des rôles et fonctionnalités.
● Connexion à distance sur d’autres serveurs 2008 & 2008 R2.
● Administration à distance des serveurs 2008 & 2008 R2 en mode core.

4. Administration à distance Windows
Lorsque l’on souhaite administrer des serveurs Windows 2003 à distance, on dispose de deux options : soit
effectuer une prise de main à distance (remote desktop), soit installer les outils d’administrations
(adminpack.msi) ; mais qu’en estil sous Windows 2008 R2 ?
On peut dire que c’est sensiblement la même chose. En effet, comme vu précédemment, la prise de main à
distance est toujours disponible, en revanche l’adminpack, lui, a été remplacé par les outils d’administration à
distance (RSAT Remote Server Administration Tools). L’intérêt réside dans le fait qu’il est désormais possible de
sélectionner les outils à installer.
Enfin, voici une liste de ce qu’il est possible d’administrer :
● Rôle :
■ Services AD DS
■ Services AD LDS
■ Services de fichiers
■ Services bureau à distance
■ Services de certificat Active Directory
■ Serveur DHCP
■ Serveur DNS
■ HyperV
● Fonctionnalités :
■ Équilibrage de la charge réseau
■ Clustering avec basculement
■ Gestion des stratégies de groupe
■ Gestionnaire de ressources système Windows
■ Gestionnaire de stockage pour réseau SAN
■ Serveur SMTP
■ Explorateur de stockage
■ Visionneuse de mot de passe de récupération BitLocker
● Une partie de ces outils d’administration à distance est également supportée sous Windows Server
2003, à savoir :
■ Services AD DS
■ Services AD LDS
■ Services Bureau à distance
■ Services de certificat Active Directory
■ Serveur DHCP

■ Serveur DNS
■ Équilibrage de la charge réseau
■ Gestion des stratégies de groupe
5. Windows PowerShell
Pour tous les amoureux de la ligne de commande, la réalisation de scripts Shell sous Windows demeurait jusqu’à
présent un gros point noir pour l’administration des systèmes. Bien sûr, il y a le VB Script qui permet d’aller plus
loin mais cela s’apparente plus à du développement qu’à du Shell Unix. Microsoft met à disposition des
administrateurs un nouveau langage de ligne de commande appelé Windows PowerShell. En fait ce nouveau
langage, orienté objet, améliore l’invite de commande Windows et Windows Script Host (WSH) en fournissant
des cmdlets (outils de ligne de commande) qui ont exactement la même syntaxe que le langage de scripts.
PowerShell prend fort heureusement en charge les scripts existants (par exemple : .vbs, .bat, .perl) de sorte qu’il
n’est pas nécessaire de migrer immédiatement tous ses scripts pour adopter Windows PowerShell.
Nous consacrerons plus de temps à PowerShell à la fin du chapitre Concepts avancés.
6. Windows Server Core
Lors de l’installation de Windows Server 2008 R2, les administrateurs peuvent choisir de faire une installation
minimale dépourvue d’interface graphique, ce qui permettra d’une part d’alléger l’installation et d’autre part de
diminuer la surface d’attaque en limitant le nombre de services implémentés.
La première chose qui nous frappe est l’absence de barre des tâches ou de Menu Démarrer sur le Bureau (bien
que l’appellation bureau soit impropre au mode Core). De même, on pourrait se demander comment lancer un
Explorateur Windows ou bien encore où trouver l’assistant de configuration initial. Inutile de chercher, nous
sommes bien entendu en présence d’une installation minimaliste de Windows 2008 R2 dépourvue de nombreux
composants tels que :
● Bureau (pas de fond d’écran ou d’écran de veille)
● Explorateur Windows

● MMC
● Panneau de configuration
● Internet Explorer ou autre Outlook Express
Toutefois, bien que de nombreux outils graphiques ne soient plus présents, on retrouve quand même la boîte à
outils classique disponible en ligne de commande (cscript, defrag, certutil…). Qui plus est Windows 2008 R2 Core
permet désormais l’installation des fonctionnalités PowerShell, engendrant un prérequis pour ce composant, le
support du .Net Framework ! Microsoft a fait un bel effort sur ce point, permettant de ce fait l’utilisation des
serveurs Windows Core en tant que serveur d’applications tel IIS 7.5.
Le mode Core permet d’installer les rôles suivants :
● HyperV ;
● Serveur DHCP (Dynamic Host Configuration Protocol) ;
● Serveur DNS (Domain Name System) ;
● Serveur de fichiers ;
● Services d’annuaire Active Directory (AD DS) ;
● Active Directory Lightweight Directory Services (AD LDS) ;
● Services de certificats Active Directory ;
● Services Windows Media ;
● Services d’impression ;
● Services IIS ;
● BranchOffice Cache.
Enfin, il existe plusieurs solutions afin d’administrer un serveur core :
● Localement en ligne de commande, enrichie dans sa mouture R2 de l’outil « sconfig » à exécuter depuis

la fenêtre de commande. Il permet entre autre de joindre un domaine, renommer l’ordinateur, configurer
l’administration à distance, configurer Windows Update, activer le bureau à distance, configurer les
interfaces réseau…
● Via les services de Bureau à distance

● Via les outils d’administration à distance
7. Gestion de l’impression
Plus une société est grande, plus le nombre d’imprimantes est élevé et plus il faut de temps pour installer et
gérer ces imprimantes.
Windows Server 2008 R2 inclut la gestion de l’impression, qui est un composant logiciel enfichable (MMC)
permettant aux administrateurs de gérer, de contrôler et de dépanner toutes les imprimantes de l’entreprise
(même celles des sites distants) à partir d’une seule interface. De plus, la console permet de rechercher et
d’installer automatiquement des imprimantes réseau sur le sousréseau local du serveur d’impression. En outre,
l’installation et la configuration des imprimantes sur des ordinateurs clients peut se faire directement à partir
d’une stratégie de groupe.

Application de la stratégie et de la sécurité
Windows Server 2008 R2 compte de nombreuses fonctionnalités dont le but est de s’assurer que les clients sont
en conformité avec la politique de sécurité en place dans l’entreprise.
Voici quelquesunes des principales améliorations :
● Vérification de la "santé" du client : la protection NAP (Network Access Protection) permet aux
administrateurs de configurer et de mettre en place des exigences en matière de santé et de sécurité
avant d’autoriser les machines clientes à accéder au réseau.
● Contrôle des autorités de certification : la nouvelle infrastructure à clé publique (PKI, Public Key
Infrastructure) améliore les possibilités de contrôle et de dépannage des autorités de certification.
● Amélioration du parefeu : le nouveau Parefeu Windows avec sécurité avancée fournit un certain
nombre d’optimisations en matière de sécurité.
● Le chiffrement et la protection des données : Bitlocker protège les données sensibles en chiffrant le
lecteur de disque.
● Outil cryptographique : une cryptologie nouvelle génération fournit une plateforme de développement
cryptographique plus flexible.
● Isolation de serveur et de domaine : les ressources de serveur et de domaine peuvent être isolées pour
limiter l’accès aux ordinateurs authentifiés ou spécifiquement autorisés.
● Contrôleur de domaine en lecture seule (RODC) : le RODC est une nouvelle option d’installation des
contrôleurs de domaine destinée aux serveurs se trouvant sur des sites distants dont la sécurité n’est
pas toujours assurée.
1. Protection NAP
Plus les années passent et plus la protection de leur réseau devient un cassetête pour les équipes
informatiques. En effet, il est de plus en plus rare de n’avoir qu’une population d’utilisateurs au sein de
l’entreprise. De ce fait, il faut concilier les utilisateurs permanents, les nomades, les télétravailleurs, les
consultants externes, etc.
Tout cela se passerait probablement sans problèmes si l’on avait la certitude que toutes les machines qui se
connectent au réseau d’entreprise sont saines. Toutefois, soyons réalistes, il n’en est évidemment rien.
Certaines machines n’ont pas de firewall, d’autres pas d’antivirus (ou pas à jour), d’autres encore n’ont pas vu
le site Windows Update depuis longtemps…
Bref, tout cela nous conduit aux constats suivants : comment protéger efficacement mon réseau ? Comment être

sûr que seules les machines saines peuvent accéder au réseau ? Qu’adviendratil si une machine non conforme
essaie de se connecter ? Doit on l’interdire complètement ou bien la diriger vers une zone de « quarantaine »
permettant sa mise à jour ?
Bien qu’il existe à ce jour quelques solutions (Association des adresses MAC aux comptes utilisateurs AD,
contrôle de la « santé » des accès distants, Cisco NAC), fort peu d’entre elles peuvent prétendre à une portée
universelle.
Cisco est quasi inexistant dans les petites et moyennes entreprises ; le contrôle des accès distants ne répond
que partiellement au problème ; l’association des adresses MAC (via le DHCP) aux comptes utilisateurs AD
n’empêche pas de se configurer une IP fixe ; il n’est d’autre part pas toujours simple d’empêcher un DHCP de
distribuer des adresses à qui le demande. La possibilité de monter des lecteurs réseau sur des serveurs d’un
domaine dont on ne fait pas partie agrémente également les réjouissances au menu des administrateurs
Windows…
Principales fonctionnalités
Microsoft, conscient de cette carence, a donc intégré à Windows 2008 R2 ce que l’on pourrait appeler une plate

forme de mise en conformité dont le but est de travailler conjointement avec les solutions de sécurité déjà
existantes (firewall, antivirus, système de mise à jour) afin de s’assurer que seules les machines répondant aux
critères définis par les équipes informatiques peuvent accéder aux ressources réseaux.
NAP (Network Access Protection) est une infrastructure (composants et API) qui fournit le support à quatre
composants :
● Health Policy Validation : les administrateurs peuvent configurer des stratégies de santé qui
définissent des éléments tels que la configuration antivirus, les mises à jour de sécurité requises pour
les ordinateurs se connectant au réseau, la présence d’un Firewall…
● Network Access Limitation : NAP permet de limiter l’accès aux ressources réseaux pour les machines

n’ayant pas les prérequis. Il sera possible d’interdire à une machine nonconforme de se connecter à
une autre, de la mettre en quarantaine dans un sousréseau avec un accès limité à certaines machines
ou encore de se contenter de faire remonter sa présence aux administrateurs.
● Automatic remediation : dans le cas où un client est jugé nonconforme, plusieurs solutions pourront
être mises en œ uvre comme par exemple :
■ Diriger le client vers un site web lui indiquant la démarche à suivre pour se remettre en conformité.
■ Diriger le client vers une zone de mise à jour où un serveur lui appliquera les correctifs de sécurité
ou encore les signatures antivirus nécessaires et, dès que celuici sera de nouveau conforme à la
stratégie de sécurité, il retrouvera un accès illimité aux ressources.
● Ongoing compliance : il serait bien entendu insuffisant de contrôler l’état des clients uniquement au
moment de la connexion et de ne plus le vérifier par la suite. En effet, si la stratégie d’entreprise
nécessite par exemple l’activation du firewall sur le client et que l’utilisateur décide de le désactiver au
cours de sa session sur le réseau, le client NAP détecte ce changement de conformité et réactive
automatiquement le Firewall.
Enfin, NAP s’appuie sur les protocoles suivants afin de sécuriser les accès :
● Mise en place d’IPsec (Internet Protocol Security).
● Mise en place du protocole 802.1X/EAP.
● Mise en place d’un réseau privé virtuel (VPN) pour le routage et l’accès distant.
● Mise en place du protocole DHCP (Dynamic Host Configuration Protocol).
Composants d’une infrastructure NAP

Dans la partie gauche du schéma, on retrouve les clients qui sollicitent un accès au réseau interne ainsi que les
serveurs de mises à jour qui permettront une éventuelle mise en conformité des machines. Les serveurs de
mises à jour peuvent être des produits Microsoft (tel WSUS), ou tous autres produits d’éditeurs tiers (Kaspersky,
Alt iris…).
Afin de pouvoir participer à une infrastructure NAP, les clients (Windows 7, Vista, 2008, 2008 R2 et XP) disposent
d’un agent composé de plusieurs couches :
● Agent de vérification de la conformité du système (SHA (System Health Agent)) : cet élément est
chargé de vérifier que la machine satisfait aux prérequis d’une machine saine. L’agent intégré à
Windows 7 permet par exemple de valider la présence d’un antivirus, de l’activation du Firewall ou
encore des mises à jour automatiques. De nombreux SHA devraient voir le jour pour prendre en charge
les produits de sécurité d’éditeurs tiers.
● Agent de mise en Quarantaine (QA (Quarantine Agent)) : cet élément est chargé de créer une liste à
partir des éléments fournis par le SHA et de la transmettre à l’agent de mise en application (EC,
Enforcement Client) pour qu’il agisse en conséquence.
● Client de mise en application (EC (Enforcement Client)) : le client EC est chargé de mettre en
application les restrictions d’accès au réseau (complet, partiel ou nul) défini dans la stratégie de sécurité
en fonction de la santé (conformité) du client.
Dans la partie centrale, on trouve les périphériques de contrôle d’accès au réseau. Ces éléments doivent être
compatibles avec une infrastructure NAP afin d’être en mesure de communiquer l’état de santé des clients (SOH
(Statement Of Health)) aux serveurs NPS pour vérification. Dans le cas d’un serveur Windows 2008 R2, celuici
doit être doté d’un composant appelé ES (Enforcement Server) qui est le complément, côté serveur, du EC client
(on trouve par exemple côté serveur le composant DHCP NAP ES qui fonctionne conjointement avec le composant
DHCP NAP EC intégré à Windows 7).
Enfin, dans la partie droite, on trouve les serveurs de stratégie réseau et les serveurs de validation de « l’état de
santé » du système des clients. La pierre angulaire de cette partie de l’infrastructure NAP est le serveur NPS qui
est un serveur Radius (Remote Autentication DialIn User Service) servant à authentifier les utilisateurs distants.
Le serveur NPS comprend également plusieurs couches :
● Système de validation de la conformité du système (SHV System Health Validator) : cette partie

est le pendant côté serveur du SHA évoqué précédemment. On trouve là encore un SHV fourni par
Microsoft mais également à terme des SHV d’éditeurs tiers. 2008 R2 l’enrichit de fonctionnalités de
multiples configurations.

● Serveur de quarantaine (QS (Quarantine Server)) : le Serveur de quarantaine agit comme un
intermédiaire entre le SHV qui tourne sur le serveur NPS et l’ES (Enforcement Server) qui tourne sur le
serveur NAP.
Aperçu du fonctionnement d’une infrastructure NAP pour une connexion VPN
L’exemple cidessus décrit le déroulement des différentes étapes lorsqu’un client Windows 7 (avec le client NAP)
essaie de se connecter à un serveur VPN sous Windows 2008 R2 faisant partie d’une infrastructure NAP
déployée sur le réseau d’entreprise.
● Le client essaie d’établir une connexion au serveur VPN en utilisant le protocole PEAP (Protected
Extensible Authentication Protocol).
● Le serveur VPN (serveur NAP) notifie au client NAP qu’il doit lui transmettre le rapport sur l’état de santé
du client (SoH). Pour ce faire, le composant ES du serveur VPN communique en PEAP avec le composant
EC du client afin qu’il lui notifie son certificat de conformité (liste établie par l’agent de mise en
quarantaine (QA) à partir des informations transmises par les agents de vérification de la conformité
(SHA)).
● Le serveur NAP établit une communication avec le serveur NPS en utilisant le protocole Radius. Le
serveur NPS constitue une liste de conformités à partir des informations transmises par le serveur NAP
et celles du serveur de validation de la conformité système (System Health Server). Si le serveur de mise
en quarantaine (QS) détermine que le client n’est pas conforme (signatures antivirus par exemple) il
dresse une liste de nonconformité (SSoHR, System Statement Of Health Response) indiquant que le client
doit être dirigé vers un réseau à accès limité tant qu’il n’est pas identifié comme correct et la transmet au
serveur NAP (VPN).
● Le serveur VPN applique un filtrage de paquets afin de mettre le client en quarantaine. Celuici est
désormais authentifié mais dispose d’un accès restreint au réseau. Le serveur NAP transmet la liste de
nonconformité au client NAP afin qu’il effectue les actions nécessaires pour se mettre en conformité
(téléchargement des signatures antivirus dans notre exemple).
● Quand l’agent de vérification de la conformité (SHA) détermine que le client est maintenant conforme,
une nouvelle liste d’état de santé (SoH) est envoyée au serveur NAP qui la transmet au serveur NPS
pour vérification. Si tout est désormais normal les restrictions sont levées et le client peut accéder à son
réseau d’entreprise.
2. Fonctionnalités de sécurité avancée du parefeu Windows

Le nouveau parefeu permet d’autoriser ou de bloquer le trafic réseau selon sa configuration et les applications
en cours d’exécution. La capacité de prise en charge de l’interception par le parefeu du trafic entrant et sortant
est une des nouvelles fonctionnalités. Par ailleurs, l’augmentation du nombre d’options de configuration a conduit
Microsoft à intégrer un nouveau composant logiciel enfichable MMC appelé Parefeu Windows avec sécurité
avancée. Enfin, le parefeu Windows et IPsec sont désormais configurés conjointement afin d’empêcher les
chevauchements de stratégies et les paramètres contradictoires.
3. Chiffrement de lecteur BitLocker
Le chiffrement de lecteur BitLocker est une nouvelle fonctionnalité de sécurité clé dans Windows Server 2008 R2
qui aide à protéger les serveurs. BitLocker chiffre le contenu d’un lecteur de disque afin d’empêcher un éventuel
voleur exécutant un système d’exploitation parallèle ou pratiquant d’autres outils logiciels de contourner les
protections des fichiers et du système. BitLocker améliore la protection des données en réunissant deux sous
fonctions majeures : le chiffrement de volume système et la vérification de l’intégrité des composants
d’amorçage. L’ensemble du volume système est chiffré, ce qui augmente la sécurité des serveurs distants situés
dans les succursales.
4. Infrastructure à clefs publique (PKI)
Il existe un certain nombre d’améliorations de l’infrastructure de clé publique dans les systèmes d’exploitation
Windows Server 2008 R2. La gestion a été facilitée dans tous les aspects de PKI, les services de révocation ont
été retravaillés et la surface d’attaque pour l’inscription a ainsi diminué.
Voici quelquesunes des améliorations de la PKI :
● Enterprise PKI (PKIView) : est un composant logiciel enfichable MMC (Microsoft Management Console)
qui est utilisé pour analyser l’état de santé des autorités de certification et pour afficher des détails sur
les certificats générés par l’autorité de certification et publiés dans Active Directory Certificate Services
(AD CS).
● Protocole OCSP (Online Certificate Status Protocol) : un répondeur en ligne basé sur le protocole
OCSP (Online Certificate Status Protocol) peut être utilisé pour gérer et distribuer des informations sur
l’état de révocation, dans les cas où l’utilisation de CRL conventionnelle ne serait pas une solution
optimale.
● Service NDES (Network Device Enrollment Service) : le service NDES est un protocole de
communication qui permet aux logiciels exécutés sur des périphériques réseau, tels que les routeurs et
les commutateurs, qui ne peuvent pas être authentifiés autrement sur le réseau, d’obtenir des certificats
x509 auprès d’une autorité de certification.
● Web Enrollment : ce nouveau contrôle Web Enrollment (inscription par le Web) est plus sûr et plus facile
à rédiger en script.
● Stratégie de groupe et PKI : des paramètres de certificat dans la stratégie de groupe permettent aux
administrateurs de gérer les paramètres de certificat à partir d’un emplacement central pour tous les
ordinateurs du domaine.
5. Cryptographie nouvelle génération (CNG)
La CNG fournit une plateforme de développement cryptographique flexible permettant aux professionnels de
l’informatique de créer, de mettre à jour et d’utiliser des algorithmes cryptographiques personnalisés dans des
applications à caractère cryptographique, telles que Active Directory Certificate Services (AD CS), Secure Sockets
Layer (SSL) et Internet Protocol Security (IPsec). CNG implémente les algorithmes cryptographiques de la Suite B
du gouvernement américain, qui incluent des algorithmes pour le chiffrement, les signatures numériques,
l’échange de clés et le hachage.
6. Contrôleurs de domaine en lecture seule

Le contrôleur de domaine en lecture seule (RODC, Read Only Domain Controller) est un nouveau type de
contrôleur de domaine disponible dans le système d’exploitation Windows Server 2008 R2, conçu principalement
pour être déployé dans des environnements de succursales. En dehors des mots de passe des comptes, le RODC
renferme tous les objets et attributs des Services de domaine Active Directory (AD DS).
7. Isolation de serveur et de domaine
Dans un réseau Microsoft Windows, les administrateurs peuvent logiquement isoler des ressources de serveur et
de domaine pour limiter l’accès aux ordinateurs authentifiés et autorisés. Par exemple, un réseau logique peut
être créé dans le réseau physique existant, où les ordinateurs partagent une série commune d’exigences pour
les communications sécurisées. Chaque ordinateur, dans ce réseau isolé logiquement, doit fournir des
informations d’authentification aux autres ordinateurs du réseau isolé pour établir la connectivité.
Deux types d’isolation peuvent être utilisés pour protéger un réseau :
● Isolation du serveur : dans un scénario d’isolation du serveur, les serveurs spécifiques sont configurés
en utilisant la stratégie d’IPsec afin de n’accepter que les communications authentifiées issues d’autres
ordinateurs. Par exemple, le serveur de base de données peut être configuré pour n’accepter que les
connexions du serveur d’applications web.
● Isolation du domaine : pour isoler un domaine, les administrateurs peuvent utiliser l’appartenance de

domaine Active Directory afin de s’assurer que les ordinateurs, membres d’un domaine, n’acceptent que
les communications authentifiées et sécurisées émanant d’autres ordinateurs membres du domaine. Le
réseau isolé est composé uniquement d’ordinateurs faisant partie du domaine. L’isolation du domaine
utilise la stratégie d’IPsec pour assurer la protection du trafic circulant entre les membres de domaine, y
compris tous les ordinateurs clients et serveur.

Accès centralisé aux applications
Windows Server 2008 R2 apporte aux services Terminal Server, rebaptisés pour l’occasion Services Bureau à
distance, des améliorations et des innovations qui optimisent le ressenti et la mobilité des utilisateurs, soit en leur
permettant d’exécuter des applications distantes sur leur bureau en parallèle de leurs applications locales, soit
directement depuis un portail web. Toutes les nouveautés seront détaillées plus loin dans cet ouvrage mais en
voici un bref aperçu :
● Support du protocole RDP 7
● Expérience bureau & utilisateur enrichie
● Authentification unique (SSO)
● RemoteApp
● Passerelle des services Bureau à distance (RD Gateway)
● Accès web aux services bureau à distance (RD Web Access)

Haute disponibilité
Une des missions principales d’un service informatique est d’assurer la disponibilité des applications critiques. Pour
ce faire, il est évident qu’un certain nombre d’éléments, tels que les serveurs, les éléments actifs ou encore le
stockage doivent être secourus afin d’assurer la continuité de services. Il est courant aujourd’hui d’utiliser du Raid
pour prévenir les pannes disques, de faire la redondance de ses liens réseau, et bien entendu d’effectuer des
sauvegardes sur bandes afin de prévenir toutes pertes de données. En revanche ce qui l’est moins, c’est de se
prémunir contre les interruptions de services qui peuvent rapidement mettre en péril les activités de l’entreprise.
Un cluster est basiquement une collection de serveurs (appelés nœ uds) qui fonctionnent conjointement afin
d’assurer la haute disponibilité des applications. Par ailleurs, l’ajout de nœ uds supplémentaires au cluster permet
de pérenniser l’infrastructure et de la rendre plus extensible.
Depuis Windows NT4, et bien qu’ayant changé plusieurs fois de nom au cours du temps, la famille des clusters
Microsoft comprend en fait deux technologies : le cluster de serveurs et l’équilibrage de la charge réseau.
1. Clusters de basculement
Un cluster de basculement, anciennement appelé cluster de serveurs, est un groupe d’ordinateurs indépendants
(nœ uds) mais fonctionnant ensemble afin d’assurer la disponibilité des applications et des services. Si un des
nœ uds du cluster est indisponible, un autre nœ ud prend le relais par un processus connu sous le nom de
basculement (failover), assurant ainsi aux utilisateurs une interruption de services très courte (en général
quelques secondes).
Dans Windows Server 2008 R2, les améliorations apportées aux clusters ont pour but de simplifier leur mise en
œ uvre, de les rendre plus sûrs et d’améliorer leur stabilité. Voici une liste des nouveautés, dont certaines seront
développées un peu plus loin :
● Assistant de validation : permet aux administrateurs de confirmer que le système, le stockage et la
configuration réseau conviennent au cluster en réalisant les vérifications suivantes :
■ Tests de nœuds : confirment que les serveurs exécutent la même version du système d’exploitation
et disposent des mêmes mises à jour logicielles.
■ Tests réseau : déterminent si le cluster dispose d’au moins deux sousréseaux séparés.
■ Tests de stockage : analysent si l’unité de stockage est correctement configurée pour que tous les
nœ uds de clusters aient accès à tous les disques partagés.
● Gestion du stockage :
■ Prise en charge des partitions GPT ;
■ Ajout dynamique de ressources disque ;
■ Performance et stabilité améliorées ;
■ Maintenance disque ;
■ Prise en charge des volumes partagés en cluster (CSV : Cluster Shared Volumes).
● Nouveau modèle de Quorum
● Réseau et sécurité
Nouveau modèle de Quorum
Dans un cluster Windows 2003 (et version antérieure), la présence du disque Quorum est indispensable à son
fonctionnement. Bien que la fiabilité du matériel (SAN, RAID…) soit en constante évolution, la panne du disque

Quorum conduit inexorablement au plantage du cluster tout entier.
Sous Windows 2003, on trouve deux modèles de Quorum :
● Shared Disk Quorum Model : dans ce modèle, également appelé modèle standard, l’ensemble des
nœ uds du cluster partagent un disque qui contient le Quorum.
● Majority Node Set : dans celuilà, chacun des nœ uds dispose d’une réplique locale du disque Quorum.

Ce modèle est généralement peu utilisé car il se prête mieux au cluster disposant de deux nœ uds (bien
qu’il soit possible depuis le service pack 1 de Windows 2003 d’utiliser un partage de fichiers pour
remplacer la présence du troisième nœ ud).
Sous Windows 2008 R2, en revanche, les deux modèles ont été fusionnés pour donner naissance à un modèle
mixte appelé Majority Quorum Model, censé combiner le meilleur des deux approches. Le disque Quorum,
désormais appelé Witness Disk, n’est plus un point unique de rupture comme c’était notamment le cas avec le
modèle à disque partagé (ce qui peut paraître paradoxal quand on parle de haute disponibilité). Dans les faits,
chaque nœ ud du cluster, ainsi que le Quorum (Witness Disk) se voient attribuer un vote avec un poids
identique. En cas de défaillance d’un des votants, cela n’impacte donc plus l’ensemble du cluster qui continue de
fonctionner normalement (le Quorum ayant le même poids que chaque nœ ud). En d’autres termes, les clusters à
deux nœ uds (les plus fréquemment rencontrés dans les entreprises), utilisant le modèle à ressource partagée,
peuvent désormais continuer de fonctionner en l’absence du disque Quorum.
Pour résumer, voici les différentes configurations qu’il sera possible de mettre en œ uvre :
● Majority Quorum : les nœ uds et le quorum votent.
● Majority Nodes : les nœ uds votent (équivalent au MNS sous Windows 2003).
● Witness Disk : le quorum vote (équivalent au quorum à disque partagé sous Windows 2003).
● File Share Witness : les nœ uds votent, plus un serveur de fichiers indépendant (utilisé pour les
géocluster par exemple).
Amélioration de la gestion du stockage
● Afin de permettre une meilleure prise en charge des architectures SAN (Storage Area Network), le driver
de disque cluster (clusdisk.sys) a été complètement réécrit à partir de Windows 2008. La première
conséquence est la suppression des commandes de réinitialisation du bus SCSI. La deuxième est un
nouveau mécanisme de protection du disque Quorum afin qu’il ne se retrouve jamais dans un état
incohérent qui pourrait conduire à la corruption des données.
● Le disque Quorum ne doit plus nécessairement avoir une lettre de lecteur puisqu’un accès direct à la
ressource disque est maintenant possible.
● Prise en charge des partitions GPT (GUID Partition Table) : les disques GPT peuvent avoir des partitions

dépassant les deux téraoctets, disposent d’une redondance incorporée, (contrairement aux disques à
partition MBR (Master Boot Record) et acceptent jusqu’à 128 partitions par disque.
● Les outils de récupération de cluster sont intégrés et permettent notamment le rétablissement des
associations entre ressources physiques et unités logiques.
● Maintenance disque facilitée : le mode Maintenance a été amélioré de manière significative, pour que les
administrateurs puissent exécuter des outils servant à vérifier, réparer, sauvegarder ou restaurer des
disques plus facilement et avec un minimum de perturbation du cluster (utilisation du VSS).
● Prise en charge des volumes partagés en cluster : ce nouveau type de stockage est totalement adapté
à la mise en haute disponibilité de machines virtuelles HyperV . En effet, grâce à son mécanisme interne
de lecture/écriture de données, il est possible de réduire considérablement les LUN (Logical Unit Number)
de stockage des machines virtuelles ainsi que leur taille en laissant entendre aux différents nœ uds
composant le cluster de multiplesaccès à un seul et même disque dit partagé. Une ressource disque
déclarée en tant que volume partagé en cluster est présentée localement à tous les nœ uds du cluster,
les entrées/sorties vers ce disque étant redirigées au travers du réseau du cluster vers le nœ ud
coordinateur garantissant l’accès concurrentiel au périphérique physique.

Amélioration du réseau et de la sécurité
● Windows 2008 R2 intègre la nouvelle pile TCP/IP déjà présente à partir de Windows Vista qui comprend
de nombreuses nouveautés (sortant du cadre de cet ouvrage) et qui permet aux clusters de
basculement le support complet d’IPV6.
● Support du DHCP.
● Suppression des dernières dépendances avec le protocole Netbios ; seul le DNS est maintenant utilisé
(plus de diffusion NetBIOS intempestive sur le réseau).
● Remplacement du protocole RPC sur UDP au profit de TCP pour les battements de cœ ur (Heartbeats) du
cluster (time out configurable aisément).
● Possibilité d’avoir des nœ uds du cluster dans des sousréseaux différents et donc des clusters sur
différents sites géographiques (sans passer par du Vlan).
● Suppression du compte utilisateur de domaine, nécessaire au lancement du service de cluster , qui est
remplacé par le compte Local System.
● Suppression du protocole NTLM dans les authentifications au sein du cluster (Kerberos uniquement
maintenant).
Nouveauté du Service pack 1
Le SP1 améliore le support des périphériques de stockages qui ne sont pas partagés par l’ensemble des nœ uds
du cluster. Le nouvel assistant de validation supporte désormais que tous les nœ uds ne disposent pas du même
espace de stockage.
2. Équilibrage de la charge réseau
L’équilibrage de la charge réseau (NLB) est une fonctionnalité qui permet de distribuer la charge réseau entre
plusieurs serveurs (utilisé notamment avec IIS ou RDS). Il s’agit d’un système flexible dans lequel l’ajout ou le
retrait de machines supplémentaires (augmentation de la charge ou défaillance d’un des nœ uds) se fait de
manière transparente pour les clients.
Les améliorations apportées au NLB comprennent :
● La prise en charge d’IPv6 : NLB prend entièrement en charge IPv6 pour toutes les communications.
● La prise en charge de NDIS 6.0 : le pilote NLB a été entièrement réécrit pour utiliser le nouveau modèle
de filtre léger NDIS 6.0. Celuici conserve une compatibilité avec les versions précédentes.
● Améliorations WMI : les améliorations apportées à l’espace de noms MicrosoftNLB concernent IPv6 et la
prise en charge de plusieurs adresses IP dédiées.
● Fonctionnalité améliorée avec ISA Server : ISA Server peut configurer plusieurs adresses IP dédiées
pour chaque nœ ud NLB pour les scénarios dans lesquels les clients se connectent en IPv4 et IPv6.
● Prise en charge de plusieurs adresses IP dédiées par nœud : NLB prend entièrement en charge la
définition de plusieurs adresses IP dédiées par nœ ud (précédemment, une seule adresse IP dédiée par
nœ ud était prise en charge), autorisant l’hébergement de plusieurs applications sur le même cluster NLB
dans le cas où des applications séparées nécessiteraient leur propre adresse IP dédiée.
3. Sauvegarde de Windows
Windows 2008 R2 intègre un nouvel outil de sauvegarde et de restauration qui remplace efficacement le très
honorable Ntbackup (disponible depuis les premières versions de Windows NT) qui ne supportait évidemment
pas la comparaison avec des logiciels de sauvegarde d’éditeurs tiers.

La fonctionnalité de sauvegarde peut être utilisée pour protéger tout le serveur de manière efficace et fiable
sans se soucier des complexités de la technologie de sauvegarde et de récupération. De nouveaux assistants
sont également disponibles pour faciliter la mise en œ uvre des sauvegardes, mais également pour la
restauration d’éléments ou de volumes entiers.
Ce nouvel outil utilise à la fois les clichés instantanés (fonctionnalité déjà disponible avec Windows 2003), mais
aussi, et c’est une nouveauté, une sauvegarde par bloc permettant une sauvegarde et une restauration plus
efficace du système d’exploitation.
Enfin, une fois la première sauvegarde complète effectuée, des sauvegardes incrémentielles (qui enregistrent
uniquement les données qui ont changé depuis la dernière sauvegarde) s’exécuteront automatiquement.

Active Directory
Comme on pouvait s’y attendre, Windows 2008 R2 apporte ici son lot de nouvelles fonctionnalités, mais également
de vocabulaire. En effet, et bien qu’ayant la même fonction, un certain nombre de services déjà disponibles sous
Windows 2003 changent de nom afin d’adopter la racine commune AD. Voici de quoi s’y retrouver un peu :
Nom précédent Nouveau nom
Active Directory Services Active Directory Domain Services (AD
DS)
Active Directory Application Mode Active Directory Lightweight Directory
(ADAM) Services (AD LDS)
Certificate Services Active Directory Certificate Services
(AD CS)
Windows Right Management Services Active Directory Right Management
Services (AD RMS)
Active Directory Federation Services Active Directory Federation Services
(ADFS) (AD FS)
1. Nouvel assistant d’installation (Dcpromo)
Afin de faciliter la mise en œ uvre d’un domaine Active Directory, Windows 2008 R2 intègre un nouvel assistant

d’installation doté d’un mode avancé. La mise en œ uvre d’un nouveau contrôleur de domaine se fera en 2
étapes :
Ajout du rôle AD DS via l’assistant d’ajout de rôles.
● Promotion au rang de contrôleur de domaine (dcpromo).

Une fois le rôle installé, l’assistant vous propose de lancer le dcpromo. Vous avez aussi la possibilité de le faire
via le menu Démarrer Exécuter :
Le premier point à noter lors de l’installation d’un domaine Windows 2008 R2 est qu’il n’accepte plus, par défaut,
l’authentification des machines préWindows 2000 utilisant des algorithmes de cryptage faible ; cela impacte bien
entendu les machines sous NT4 mais également Samba ou encore certains NAS.
● Configuration DNS
Dans le cas où un serveur DNS valide n’est pas détecté par l’assistant, celuici, comme sous Windows 2003,
propose son installation.
● Création de la forêt Active Directory

● Nom NetBIOS (et oui certaines idées ont la vie dure…)
● Définition du niveau fonctionnel
Permet l’activation de toutes les fonctionnalités de Windows 2008 R2.
● Options complémentaires

Cette fenêtre d’options est propre à 2008 et 2008 R2 et permet de sélectionner des options complémentaires
pour un contrôleur de domaine. On notera notamment la possibilité de définir notre DC (Domain Controller ou
Contôleur de Domaine) comme serveur de catalogue global mais également comme contrôleur de domaine en
lecture seule (ce qui est une nouveauté déjà évoquée et détaillée un peu plus loin dans ce chapitre). Dans notre
exemple, le DC est le premier contrôleur de domaine de la forêt et sera donc automatiquement serveur de
catalogue global mais certainement pas RODC (Read Only Domain Controller).
● Emplacement des fichiers
● Mot de passe de restauration des services d’annuaire

Enfin, il est maintenant possible d’exporter, dans un fichier, les paramètres sélectionnés afin de les réutiliser
dans une installation sans assistance.
2. Active Directory Domain Services (Service de domaine AD)
Parmi les principales améliorations apportées à l’Active Directory, voici celles qui me paraissent les plus
importantes :
● Amélioration des audits
● Contrôleurs de domaines en lecture seule
● Service Active Directory
● Stratégie de mots de passe multiples
● Corbeille Active Directory
● Amélioration de l’administration
● Services Web Active Directory
● Jonction de domaine hors connexion
Amélioration des audits
Tout d’abord, il est important de préciser que la console de gestion des stratégies de groupe est enfin installée
nativement avec Windows 2008 R2. Il va sans dire que, bien qu’ayant toujours sensiblement les mêmes
fonctionnalités, celleci a été relookée et améliorée.
En ce qui concerne les audits Active Directory, ceuxci s’activent en deux étapes de la même manière que sous
Windows 2003 :
● Éditer la stratégie Default Domain Controllers Policy et activer l’option Auditer l’accès au service
d’annuaire (Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies
locales\Stratégie d’audit).

● Positionner l’audit sur les objets (SACL System Access Control List) ; dans l’exemple ciaprès on va
positionner l’audit sur l’OU (Organizational Unit ou Unité d’Organisation) Audit pour le groupe Utilisateurs
authentifiés :
■ Ouvrir la MMC Utilisateurs et ordinateurs Active Directory.
■ Activer les fonctionnalités avancées.
■ Afficher les propriétés de l’OU, aller dans l’onglet Sécurité\Avancé puis sur l’onglet Audit.
■ Ajouter le groupe Utilisateurs authentifiés.
■ Choisir Les objets descendants uniquement dans la liste Appliquer et sélectionner Écrire toutes
les propriétés en réussite puis valider.

● Fermer toutes les fenêtres en cliquant sur OK.
● Effectuer la modification d’un attribut d’un compte utilisateur puis ouvrir le journal des événements.

À ce stade, on est en droit de se dire "et alors ?" ; en effet, hormis la nouvelle MMC on retrouve sensiblement les
mêmes informations qu’avec Windows 2003. En fait, tout comme l’iceberg, le plus important est ce qui ne se voit
pas… Alors que sous Windows 2003 on avait uniquement l’option Auditer l’accès au service d’annuaire, on
dispose désormais des souscatégories suivantes activables en ligne de commande :
● Accès Active Directory
● Modification du service d’annuaire
● Réplication du service d’annuaire
● Réplication du service d’annuaire détaillé
Il est maintenant possible de suivre les modifications opérées sur un objet dès lors que l’on active son audit
(auditpol /set /category:"Accès DS" /success:enable : activation de l’audit pour toute la catégorie Accès DS).
L’ID d’événement 5136 permet d’avoir l’état de l’objet avant et après sa modification.

Valeur de l’attribut Adresse avant modification

Valeur de l’attribut Adresse après modification
Pour de nombreux administrateurs, le suivi des versions des objets présente peu d’intérêt. Cependant, dans le
cas où l’on souhaite assurer un minimum de sécurité dans son infrastructure, il devient indispensable de suivre
l’historique des évolutions tout au long de la vie d’un objet. Enfin, comme il peut être lourd d’auditer tous les
attributs d’un objet, il est désormais possible de modifier le schéma afin de choisir ce qui doit être audité.
Contrôleur de domaine en lecture seule
Une autre nouveauté disponible dans AD DS, et pas des moindres, est le contrôleur de domaine en lecture seule
(RODC) dont la particularité est de disposer d’une base Active Directory en lecture seule. Certains nostalgiques
pourraient se dire que l’on est de retour à la grande époque de Windows NT4 et de ses BDC, pourtant il s’agit en
fait d’une évolution majeure de la sécurité. Pour bien comprendre l’intérêt des RODC, il convient de faire un
rappel concernant les solutions existantes sous Windows 2003.
D’une manière générale les sites informatiques principaux disposent d’un accès sécurisé aux salles serveurs et
des ressources humaines nécessaires à leurs administrations. En revanche, ce n’est malheureusement pas le cas
des succursales où il est commun de trouver un contrôleur de domaine posé sur une table et accessible à tous.
Malgré cela, il n’existait à ce jour que deux options à la disposition des administrateurs pour permettre aux
utilisateurs des sites distants de se connecter au réseau d’entreprise :
● Mettre un contrôleur de domaine sur le site qui se réplique avec les serveurs du siège : dans ce cas,
les utilisateurs peuvent s’authentifier localement même si le lien WAN est coupé. Toutefois, le vol du
serveur ou de la base de données AD mettrait en péril la sécurité de toute l’entreprise.
● Ne pas mettre de DC sur le site et effectuer les authentifications vers le siège au travers du lien

WAN : le problème de cette méthode, outre les lenteurs de connexion, est l’impossibilité de se
connecter au réseau si le lien WAN est indisponible ou fortement saturé par d’autres flux.
Pour résumer, avec Windows 2003, les administrateurs disposent de deux solutions : mettre un contrôleur de
domaine sur le site ou authentifier les utilisateurs au travers du WAN. Avec Windows 2008 R2, on dispose enfin
d’une alternative grâce au RODC qui permettra de mettre un contrôleur de domaine dans les succursales, sans
mettre en péril la sécurité de son réseau d’entreprise.
Comme nous l’avons déjà évoqué précédemment, un RODC dispose d’une base de données en lecture seule ce
qui veut dire en d’autres termes que la synchronisation est unidirectionnelle et a toujours lieu d’un DC dit
"normal" vers un RODC. En outre, cela signifie également qu’il n’est pas possible d’effectuer des réplications intra
site entre deux RODC.
Un RODC est également un centre de distribution de clefs (KDC, Key Distribution Center) pour le site sur lequel il
est implanté et peut donc répondre aux requêtes de tickets Kerberos émises par les comptes utilisateurs et
ordinateurs de son site. En revanche, comme il ne dispose pas d’une base de données d’annuaire en écriture, il
n’est pas en mesure de stocker les informations d’identification (couple utilisateur, mot de passe) fournies par les
comptes utilisateurs et ordinateurs lors du processus d’authentification. Lorsqu’un utilisateur essaie de
s’authentifier, le RODC contacte un DC du site central afin d’obtenir une copie des informations d’identification. La
réponse fournie par le DC au RODC varie en fonction de la stratégie de réplication de mot de passe configuré
pour celuici. Dans le cas où la réplication des informations d’identification est autorisée, le RODC met en cache
ces informations pour pouvoir les réutiliser ultérieurement (tant qu’elles sont valides). Le résultat de ce mode de
fonctionnement est que si le RODC d’un site est dérobé, seuls quelques comptes seront compromis (ceux dont la
réplication est autorisée) et non l’intégralité de l’annuaire.
Bien que les fonctionnalités évoquées semblent alléchantes, ceux d’entre vous qui connaissent les entrailles de
l’AD doivent se dire "mais qu’en estil du catalogue global et du DNS ?"
Comme tout le monde le sait (ou non), la présence de ces deux éléments est fortement souhaitable sur les sites
distants et, de ce fait, un RODC peut héberger ces deux fonctions. Lors du dcpromo, l’installation d’un serveur
DNS local est proposé par défaut, ce qui permet la réplication des zones DNS intégrées AD et le paramétrage
automatique du solver DNS local.
Tout cela semble en apparence parfait, mais qu’en estil des mises à jour dynamiques des enregistrements DNS ?
Tout d’abord, il conviendra de paramétrer le DNS principal des clients pour pointer sur le RODC (l’utilisation d’un
DHCP facilite grandement la chose), et le DNS secondaire vers un DC du site central (au cas où). Ensuite,
lorsqu’un client essaie de mettre à jour ses enregistrements DNS auprès du RODC, celuici dirige la demande vers
un vrai DC afin qu’il procède à la mise à jour puis, peu après, le RODC contacte le DC afin de mettre à jour ses
propres informations locales (réplication du DC vers le RODC). Dans le cas où aucun DC n’est disponible pour la
mise à jour (coupure réseau par exemple), l’enregistrement n’est disponible localement que lors de la prochaine
réplication planifiée.
Enfin la dernière nouveauté liée au RODC, c’est qu’il est désormais possible de déléguer l’administration locale du
serveur à un simple utilisateur. Cela permet aux petits sites ne disposant que d’un relais informatique de réaliser
certaines opérations sur le serveur local (installation d’un pilote de périphérique demandé par l’administrateur
central par exemple) qui nécessitait précédemment d’être admin du domaine. De fait, une éventuelle mauvaise
manipulation sur le serveur n’a plus d’impact sur le reste de l’annuaire AD.
Service Active Directory
Une autre nouveauté de Windows 2008 R2 est la possibilité de redémarrer les services d’annuaire sans pour
autant démarrer le serveur en mode de restauration des services d’annuaire. En fait, AD DS est désormais un
service Windows qu’il est possible d’arrêter pour effectuer des opérations de maintenance (défragmentation hors
ligne de la base par exemple).

Toutefois, certains services liés à AD sont également stoppés en même temps que l’annuaire (DNS par exemple).
Alors que les précédentes versions des services d’annuaires ne pouvaient prendre que deux états (normal ou
restauration des services d’annuaires), la version 2008 R2, elle, en compte trois :
● AD démarré : les services d’annuaires sont activés et les clients peuvent êtres authentifiés.
● Restauration AD : identique aux précédentes versions ([F8] au démarrage du serveur).
● AD arrêté : dans cet état, un contrôleur de domaine est à la fois identique à un DC en mode de
restauration des services d’annuaires, et également à un simple serveur membre. De fait, bien que la
base de données AD soit hors ligne, le serveur est quand même accessible pour les clients (sous réserve
d’être authentifié par un autre DC en ligne).
Stratégie de mot de passe multiple
Dans les précédentes versions des services d’annuaire de Microsoft, il n’était possible de disposer que d’une
stratégie de mot de passe valable pour le domaine entier (définie dans la GPO "Stratégie de domaine par

défaut").
Une des évolutions d’Active Directory avec Windows Server 2008 R2 consiste en la possibilité de définir non plus
une seule mais de multiples politiques de mots de passe au sein d’un domaine. Pour ce faire, une nouvelle classe
d’objet appelée mdsPasswordSettings a été ajoutée.
Afin de pouvoir gérer des stratégies de mot de passe spécifique, il convient de créer un objet PSO dont les
critères positionnables sont les suivants :
● Ordre de précédence (msDSPasswordSettingsPrecedence) : ce paramètre caractérise un ordre de
préférence dans le cas où plusieurs stratégies s’appliqueraient au même objet.
● Stocker les mots de passe de manière chiffrée réversible (ms DS
PasswordReversibleEncryptionEnabled) : utilisé notamment pour les Mac.
● Nombre de mots de passe conservés dans l’historique (ms DSPasswordHistoryLength) : ce paramètre
spécifie combien d’anciens mots de passe seront mémorisés et donc pas réutilisables.
● Utilisation de mots de passe complexes (ms DSPasswordComplexityEnabled) : force les utilisateurs à
utiliser des mots de passe complexes contenant notamment des chiffres, des majuscules et des
caractères spéciaux.
● Longueur minimale du mot de passe (ms DSMinimumPassworLength).
● Durée de validité minimale du mot de passe (msDSMinimumPasswordAge).
● Nombre d’essais infructueux avant verrouillage du compte (msDSLockoutThreshold).
● Durée d’observation du verrouillage du compte (msDSLockoutObservationWindow).
● Durée de verrouillage du compte (msDSLockoutDuration).
Enfin, après avoir créé les objets PSO, il convient de les affecter soit à un groupe (de préférence) soit à un
utilisateur.
Corbeille Active Directory
Jusquelà, la suppression accidentelle d’objet quel qu’il soit dans l’AD, obligeait en cas de retour arrière à devoir
remonter une copie de sauvegarde et à effectuer une restauration faisant autorité à l’aide de l’outil ntdsutil. Ceci
impliquait la bascule du contrôleur de domaine dans un mode de restauration d’annuaire rendant impossible le
traitement des requêtes des utilisateurs. Les plus pointus d’entre vous me diront que jusqu’ici un objet supprimé
de l’AD ne l’est pas immédiatement, mais qu’il est mis dans un état de désactivation (dit Tombstone). En effet, il
était alors possible de récupérer cet objet durant une période limitée, fixée à 180 jours par défaut. Cependant, si
certains attributs étaient conservés et récupérables, d’autres, telle que l’appartenance aux groupes ne l’étaient
plus dès sa suppression. Difficile alors pour un administrateur de se fier à cette méthode de récupération.
Heureusement, grâce à Windows 2008 R2 et ses services Active Directory, une notion de corbeille AD a été
introduite, permettant la restauration rapide d’objets dans leur intégralité. Bien entendu, pour profiter de cette
nouvelle fonctionnalité, le niveau fonctionnel de la forêt doit être Windows Server 2008 R2, ce qui signifie que
tous les contrôleurs de domaines doivent être mis à jour vers Windows 2008 R2.
Microsoft a introduit un nouvel état au cycle de vie des objets appelé « Recyclés ». La différence réside dans le
fait qu’un objet à l’état supprimé conserve encore tous ses attributs, ce qui n’était pas le cas dans les versions
antérieures au niveau fonctionnel Windows Server 2008 R2. Une fois la durée de vie expirée de l’objet supprimé,
celuici passe dans l’état recyclé et perd un grand nombre de ses propriétés. Sa restauration devient alors
similaire aux versions antérieures de Windows Server 2008 R2.
Pour bien comprendre les différents états que peuvent prendre les objets AD dans le cadre de la mise en œ uvre
de la corbeille AD, le schéma suivant a été élaboré :

Par défaut, la durée de vie des objets supprimés est de 180 jours, tout comme la durée de vie des objets
recyclés. Vous pouvez bien entendu les modifier à votre guise au travers des attributs respectifs
« tombstoneLifetime » et « msDSdeletedObjectLifetime ».
Par défaut la corbeille est désactivée, nous allons voir comment la mettre en œ uvre, mais soyez vigilant car ce
processus est IRRÉVERSIBLE !
L’activation de la corbeille AD se fait au travers de cmdlets PowerShell. Lancez la console Module Active
Directory pour Windows PowerShell disponible dans le menu Outils d’administration, puis saisissez la
commande suivante :
Enable-ADOptionalFeature -Identity <ADOptionalFeature>

-Scope <ADOptionalFeatureScope> -Target <ADEntity>
Les paramètres <ADOptionalFeature> et <ADEntity> doivent être renseignés en adéquation avec le nom de
votre domaine.
Par exemple, dans le cadre du domaine w2k8forest.local, la commande à saisir sera :
Enable-ADOptionalFeature -Identity ’CN=Recycle Bin Feature,CN=

Optional
Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=
Configuration,
DC=w2k8forest,DC=local’ -Scope ForestOrConfigurationSet -Target
’w2k8forest.local’
Après avoir activé la corbeille AD, ne vous lancez pas à la recherche d’un quelconque conteneur Corbeille,
Recyclebin ou autre dans votre console Utilisateurs et ordinateurs Active Directory, la restauration d’objets se
fait intégralement en ligne de commande toujours à l’aide des applets PowerShell.

Prenons comme exemple l’utilisateur « Leon », membre du groupe global « GG_Nettoyeur », créé dans l’OU
« ou=Users, ou=France, ou=Global, dc=w2k8forest, dc=local »
Par erreur, l’utilisateur est supprimé. Via la console Module Active Directory pour Windows PowerShell, la
commande suivante me retourne mon objet, filtré sur l’attribut « displayName », et identifié comme étant
supprimé :
Get-ADObject -Filter {displayName -eq "Leon"} -IncludeDeleted

Objects

La restauration peut alors être effectuée avec la cmdlet « RestoreADObject » passée en paramètre, soit :
Get-ADObject -Filter {displayName -eq "Leon"} -IncludeDeleted

Objects | Restore-ADObject
Mon objet ainsi que tous ses attributs sont alors restaurés tels qu’ils l’étaient avant sa suppression.
Amélioration de l’administration
Pour faciliter l’administration quotidienne du système AD, Microsoft a introduit de nouveaux outils disponibles dès
la mise en œ uvre des rôles AD DS.
Module Active Directory pour Windows PowerShell
Afin de mettre une nouvelle fois en avant les possibilités d’administration et automatisation des tâches en ligne
de commande à l’aide de PowerShell, un module dédié à AD a dû être élaboré. Celuici permet la manipulation de
tous les objets ainsi que la configuration des services AD.
Pour obtenir la liste complète des cmdlets, lancez la console Module Active Directory pour Windows
PowerShell et saisissez :
Get-Command *-AD*

Active Directory Best Practice Analyzer
Best Practice Analyzer (BPA) a également été adapté ici afin de pouvoir effectuer un diagnostic du système AD
installé et fournir les recommandations associées pour tirer parti de la meilleure configuration possible. BPA
permet l’analyse des rôles suivants :
● Services de domaine Active Directory
● Services de certificats Active Directory
● Serveur DNS
● Services Bureau à distance
Centre d’administration Active Directory
Une nouvelle console fait son apparition dans cette édition 2008 R2, nommée Centre d’administration Active
Directory.
À michemin entre la MMC Utilisateur et ordinateurs Active Directory et la console PowerShell, cette nouvelle

interface permet l’administration centrale de l’AD avec toutes les tâches nécessaires à l’administration

quotidienne, à savoir création de comptes, création de groupes, création d’OU, la modification de mots de passe
et de propriétés, et bien d’autres…
Services Web Active Directory
Les services Web Active Directory fournissent une nouvelle interface d’accès de service type web vers les
domaines AD et AD LDS. Ils sont installés de base dès l’intégration du rôle AD DS ou AD LDS.
Pour les utiliser, il conviendra d’autoriser les connexions distantes sur le port TCP 9389 sur les contrôleurs de
domaine.
Jonction de domaine hors connexion
Un nouveau processus de jonction d’un ordinateur au domaine fait son apparition : la jonction de domaine hors
connexion. Le principe étant de pouvoir créer la relation d’approbation entre une machine et un contrôleur de
domaine sans avoir pour autant de connectivité réseau.
Ce processus est aujourd’hui disponible uniquement sur les systèmes d’exploitation Windows 7 et Windows
2008 R2, au travers de l’outil « djoin.exe ». Pour l’utiliser, il faut disposer des droits de joindre un ordinateur au
domaine. Les étapes sont :
● Générer les métadonnées propres à l’ordinateur à joindre au domaine. Peut être réalisé sur un
contrôleur de domaine Windows 2008 R2 à l’aide de la commande djoin.exe /provision.
● Récupérer le fichier .txt généré par la commande précédente et le transmettre sur le poste à joindre au
domaine.
● Joindre l’ordinateur au domaine à l’aide de la commande djoin.exe /requestODJ en référence au
fichier .txt et redémarrer l’ordinateur.
Soyez vigilant quant à la sécurisation du fichier .txt généré, celuici est une clé de sécurité ouvrant les portes
d’un ordinateur à votre système informatique.

● Amélioration du support des comptes de services gérés (MSA, Managed Service Account)
Le SP1 apporte une meilleure prise en charge des serveurs membres situés dans les réseaux dit de «
périmètre » (DMZ).
● Amélioration du support des liens lents pour les authentifications
Le SP1 permet de gérer de manière granulaire le nombre maximum de connexions concurrentes vers un
contrôleur de domaine.

Autres nouveautés ou améliorations
1. Services de fichiers
Sous Windows 2008 R2, la fonction de serveur de fichiers est désormais un rôle à part entière et, de ce fait, on
dispose maintenant d’une console MMC spécifique appelée Gestion du partage et du stockage. Cette console
permet d’avoir une vue centralisée des partages et des volumes configurés sur le serveur.
Les actions qu’il est possible d’effectuer dans les onglets sont les suivantes :
● Partages : cesser de partager, configurer
● Volumes : étendre, formater, configurer, supprimer
Cette console dispose également de deux nouveaux assistants permettant de paramétrer des partages ou des
volumes.

● L’assistant Prévision du stockage permet de paramétrer des LUN, de créer ou encore formater des
volumes. Windows 2008 R2 supporte de nombreux protocoles tels que fibre channel ou encore iScsi.
● L’assistant Prévision du partage permet, quant à lui, de créer des partages SMB ou NFS, de positionner
des permissions NTFS, la configuration hors connexion ou encore de définir une stratégie de quota. Au
rayon des bonnes nouvelles, on notera que l’énumération basée sur l’accès (ABEUI, module
complémentaire sous Windows 2003 permettant de ne voir que les répertoires auquel on a accès) est
maintenant intégrée sous Windows 2008 R2, et qu’il est également possible de filtrer le type de fichiers
contenus dans un répertoire (ainsi les fichiers à caractère non professionnel peuvent être bannis).

L’accès aux propriétés avancées d’un partage permet comme auparavant de limiter le nombre d’utilisateurs en
simultané sur la ressource et désormais de base l’activation de l’énumération basée sur l’accès.
Il est également possible de définir le mode de fonctionnement hors connexion mis à disposition aux utilisateurs.

Une nouvelle option fait ici son apparition, le BranchCache. Ce mode de fonctionnement, permet notamment lors
de configuration en multisite avec entités distantes, d’utiliser un serveur local au site distant faisant relais vers
les données du siège en mettant en cache les informations sollicitées par les utilisateurs. La navigation est alors
rendue plus fluide à l’utilisateur final. Cette option est disponible avec les systèmes d’exploitation Windows 7 et
Windows 2008 R2. Il faudra déployer les fonctionnalités BranchCache sur les serveurs et activer l’option sur les
partages pour bénéficier de cette optimisation.
2. Explorateur de stockage
L’explorateur de stockage est une console MMC permettant de gérer les infrastructures SAN, qu’elles soient
basées sur Fibre Channel ou sur iScsi. La console se présente sous la forme d’un arbre dépliable et permet de
visualiser la topologie de votre SAN, sans avoir à maîtriser les outils propriétaires des divers fabricants.

3. SMB 2
SMB est un protocole de partage de fichiers dont la première version (1.0) a été développée dans les années 80
90, pour les premiers réseaux Microsoft (Microsoft LAN Manager).
Malgré de nombreuses qualités et quelques évolutions au fil du temps, SMB 1.0 est un protocole bavard qui
génère beaucoup de trafic réseau et supporte un nombre restreint de partage de fichiers.
Depuis Windows 2008 et Vista, Microsoft a donc complètement réécrit le protocole. Aujourd’hui, avec Windows 7
et Windows 2008 R2, le protocole passe en version 2.1 apportant son lot de dernières corrections.
Parmi les évolutions, on peut citer :
● Support des commandes multiples dans le même paquet.
● Augmentation de la taille des buffers.
● Augmentation du nombre de partages et de fichiers ouverts simultanément sur le serveur.
● Meilleure gestion des microcoupures réseau.
Les figures cidessous (source Microsoft) permettent d’entrevoir l’optimisation effectuée sur le protocole SMB 2
dans l’utilisation de la bande passante du réseau.

Comparaison des protocoles SMB 2 et SMB1 sur un réseau LAN
Comparaison des protocoles SMB 2 et SMB1 sur un réseau Wan
4. MPIO (MultiPath Input Output)
Nombre d’administrateurs pensent que mettre en place du Raid sur les serveurs suffit à assurer une haute
disponibilité de leurs applications. Bien que leur raisonnement ne soit pas totalement erroné, la question à se
poser est : Que se passeraitil si une carte raid ou encore une nappe tombait en panne ? La réponse tombe
évidemment sous le sens et c’est le problème majeur de ce type de solution qui ne procure qu’un chemin logique
unique vers les données.
Une autre approche, que l’on trouve dans les infrastructures SAN, est de mettre en œ uvre un chemin logique
multiple (multipathing) en assurant la redondance des éléments intermédiaires tels que les cartes, les switchs ou
les câbles, situés entre le serveur et les unités de stockage.

En effet, la mise en œ uvre d’un chemin logique multiple (multipath I/O) permet aux applications installées sur le
serveur de continuer à avoir accès à leurs données, même lors de la défaillance d’un des composants. En outre,
MPIO permet également d’assurer une répartition de charge des opérations de lecture/écriture sur les différents
chemins logiques définis entre le serveur et les unités de stockage.
MPIO est en fait un pilote développé par Microsoft, qui était jusqu’à présent un composant indépendant et qui
est désormais disponible dans les fonctionnalités sous Windows 2008 R2.
Schéma logique d’une infrastructure SAN utilisant MPIO
Le nouveau pilote MPIO de Windows 2008 R2 permet de mettre en œ uvre plusieurs politiques de répartition de
charge :
● Failover : pas de répartition des entrées/sorties, un chemin préférentiel est défini tandis que les autres
sont en attente.
● Fail back : même logique que précédemment, mais dès que le chemin privilégié est de nouveau
opérationnel, il sera utilisé en priorité.
● Round Robin : tous les chemins sont employés pour répartir les requêtes d’E/S sur le principe du
tourniquet (même logique que le round robin DNS).
● Round Robin with subset of path : une partie des chemins logiques est allouée au tourniquet tandis
que le reste est en attente d’une éventuelle défaillance.
● Dynamic Least Queue, Depth : les entrées/sorties sont dirigées vers le chemin ayant le moins de
requêtes en attente.
● Weighted Path : chaque chemin reçoit un poids indiquant son niveau de priorité. Le chemin ayant le
poids le plus faible est utilisé en priorité pour servir les requêtes.
Les dernières nouveautés de MPIO résident essentiellement dans les tâches d’administration. Il est désormais
possible de générer différents types de rapports comme la bonne santé des chemins de secours, de nombreuses
statistiques en temps réel ainsi que le support des scripts via l’utilitaire en ligne de commande « mpclaim.exe ».
5. iSCSI Initiator et iSNS Server
iSCSI (internet Small Computer System Interface) est un protocole utilisé pour interconnecter des serveurs, des
clients ou des systèmes de stockage en s’appuyant sur un réseau TCP/IP.

iSCSI a été initialement développé afin de procurer une alternative moins coûteuse au protocole Fibre Channel
(FC) communément utilisé dans les infrastructures SAN.
Bien que de nombreuses entreprises ressentent le besoin d’une infrastructure SAN, l’idée d’investir dans un
réseau FC, coûteux et complexe, en parallèle de leur réseau LAN est souvent un élément rédhibitoire. De fait, le
développement croissant de solutions SAN/iSCSI bon marché permet au plus grand nombre de s’équiper.
Enfin, un autre intérêt du iSCSI est qu’il est simple à mettre en œ uvre et ne nécessite que peu de matériel
(usuellement un serveur, une unité de stockage compatible iSCSI, le tout branché sur un switch Gigabit).
Une autre fonctionnalité de Windows 2008 R2 est iSNS (internet Storage Name Service) qui permet de simplifier la
gestion des infrastructures iSCSI complexes.
6. Réseau
Bon nombre de perfectionnements ont été réalisés sous Windows 2008 R2, mais ceux qui me semblent les plus
intéressants sont les suivants :
● Prise en charge du protocole IPv6 par le nouveau serveur DHCP.
● Nouveau client VPN SSL appelé pour l’occasion SSTP (Secure Socket Tunneling Protocol), permettant
d’utiliser une connexion SSL (port 443).
7. DirectAccess
Un outil relativement intéressant faisant partie intégrante du système Windows 2008 R2 est DirectAccess. En
effet, celuici permet de fournir un accès à l’utilisateur nomade en constant déplacement, jusqu’aux ressources
de l’entreprise, et ce en s’affranchissant de toute infrastructure VPN.
Le principe est simple et s’appuie sur un serveur positionné entre le réseau de l’entreprise et Internet, jouant le
rôle de passerelle entre le client nomade et les ressources internes au travers du protocole IPsec s’appuyant sur
IPv6.
Principe de connexion
À tout moment le client DirectAccess tente d’établir une connexion avec un serveur de l’Intranet hébergeant une
ressource basée sur HTTPS. Si la connexion se fait, c’est que l’utilisateur est connecté en interne et peut accéder
à ses ressources, le processus de connexion s’interrompt alors.
Si le site Intranet ne peut être accédé, c’est que l’utilisateur est connecté à l’extérieur de la société. Le client
DirectAccess tente alors d’établir un lien vers le serveur DirectAccess au travers d’IPsec en IPv6.
Si le client est connecté à Internet, le protocole IPv6 n’étant pas disponible, le client effectue une connexion en
IPv4 à l’aide d’un tunnel IPv6overIPv4.
Si le client est bloqué par un quelconque firewall, il tente alors automatiquement une connexion au travers du
protocole HTTPS plus généralement ouvert en sortie.
Le processus d’authentification ordinateur et/ou utilisateur prend part et les règles définies via NAP sont
appliquées (si cellesci existent).
Si les règles de sécurité sont respectées, le flux est alors acheminé vers les ressources de l’entreprise.
Prérequis
Pour mettre en place DirectAccess, il est nécessaire d’avoir un ou plusieurs serveurs Windows 2008 R2, membres

du domaine avec deux interfaces réseau (une vers Internet et l’autre vers le réseau local de l’entreprise).
Sur l’interface réseau Internet, au minimum deux adresses IP publiques v4 consécutives et résolvables depuis les
DNS publics sont nécessaires.
Une architecture Active Directory et PKI pour la génération des certificats ordinateurs doit être disponible.
Côté client, les postes doivent être membres du domaine, a minima sous Windows 7 Entreprise et avec l’IPv6
d’activé.
Principe de mise en œuvre
Les grandes lignes pour la mise en œ uvre d’une infrastructure DirectAccess sont décrites cidessous. Ce principe
de mise en œ uvre est à décliner selon les spécificités de chaque infrastructure et ne saurait donc être exhaustif.
● Installer le(s) serveur(s) DirectAccess sous Windows 2008 R2 et joindre le serveur au domaine Active
Directory. Si le serveur héberge la ressource de localisation basée sur HTTPS, installer également le rôle
IIS.
● Configurer les interfaces réseaux de manière à avoir une interface sur le réseau public affectée au profil
"public" hébergeant les 2 adresses IP publiques consécutives, et une autre sur le réseau interne
affectée au profil "domaine" hébergeant l’adresse IP interne du serveur DirectAccess .
● Configurer votre infrastructure PKI pour délivrer des certificats aux ordinateurs membres du domaine.
● Générer un certificat ordinateur et l’installer sur le serveur DirectAccess (utilisé pour l’IPsec).
● Créer un groupe de sécurité du type global dans l’Active Directory. Y ajouter les comptes d’ordinateur du
domaine aptes à se connecter au travers de DirectAccess.
● Autoriser le trafic de requêtes ICMPv4 et ICMPv6 sur les ordinateurs. Ceci peut être effectué de manière
globale au travers des stratégies de groupe.
● Installer la fonctionnalité DirectAccess et lancer l’assistant de configuration. Celuici vous demandera de
sélectionner toutes les caractéristiques de votre infrastructure, à savoir, entre autres les interfaces
réseaux dédiées, les certificats à utiliser et les autorisations associées.
Avec le SP1 de Windows 2008 R2 il est désormais possible d’utiliser le NLB (équilibrage de la charge réseau) avec
des adresses 6To4 (6To4 permet à deux réseaux IPv6 de communiquer entre eux au travers d’un réseau IPv4)
et ISATAP (IntraSite Automatic Tunnel Addressing Protocol permet d’assurer une transition d’IPv4 vers IPv6).
Bien que de multiples autres fonctionnalités ou améliorations soient également disponibles dans Windows 2008
R2, elles feront sans nul doute l’objet de nombreux autres ouvrages.

RDS 2008 R2 simple mise à jour ou véritable révolution
Comme ce fut le cas à l’époque avec la mouture R2 de Windows 2003, Microsoft a su mettre en avant les
nouveautés apportées par cette nouvelle édition.
Certains caractériseront le terme nouvelle édition par une remise à niveau du côté des licences engendrant de
nouvelles dépenses, d’autres l’interpréteront d’une manière plus technique et sauront apprécier les dernières
optimisations.
Si l’accent avait donc été mis sur l’aspect amélioration de l’administration et de la sécurité lié au R2 de Windows
2003, il en est de même avec 2008, mais pas seulement, comme vous avez pu le constater précédemment.
La volonté de Microsoft à "trancher" avec le passé, a poussé le vice à la réécriture de nouvelles appellations sur de
nombreux services. Nous avons pu notamment le constater avec les services liés à Active Directory.
Il en est de même avec les services TSE bien connus jusquelà. Le nouveau terme à adopter sera donc services
de Bureau à distance ou Remote Desktop Services (RDS). Cette version nous arrive avec de bien belles
nouveautés supplantant de loin les services TSE actuels.

Client d’accès à distance version 7.1
1. Introduction
Comme ce fut jadis le cas avec l’arrivée de Windows 2003, Microsoft a retravaillé en profondeur tant la partie
serveur que la partie cliente afin d’améliorer encore le confort des utilisateurs (et accessoirement celui des
administrateurs). Les nouvelles fonctionnalités du client apportées dès sa version 6 et complétées dans la
dernière version 7 sont les suivantes :
● nouvelles résolutions d’écran ;
● utilisation de plusieurs moniteurs ;
● nouvel environnement visuel ;
● support des polices « ClearType » ;
● lecture audio/vidéo ;
● flux audio bidirectionnel.
Afin de pouvoir profiter de ces nouvelles possibilités, il faudra disposer d’un serveur RDS 2008 R2 et du client RDC
7 (disponibles nativement avec Windows 7 et en option avec Vista et XP SP3). Toutefois, certaines applications
ne seront disponibles qu’avec le couple Windows 2008 R2 et Windows 7.
2. Nouvelles résolutions d’écran
Depuis sa version 6, le client RDC prend en charge des résolutions plus larges et permet également d’utiliser
plusieurs écrans afin d’étendre la taille du bureau.
Dans les versions précédentes de TSE, la résolution d’écran ne supportait qu’un ratio 4:3 avec un maximum de
1600*1200. Désormais, il sera possible d’avoir des ratios de 16:9 voire 16:10 et une résolution allant jusqu’à
4096*2048 par moniteur.
3. Utilisation de plusieurs moniteurs (Multimon)
Le multimon permet d’étendre son bureau RDS sur plusieurs moniteurs. A contrario de son prédécesseur
monitor spanning (entre Vista et 2008), les limitations telles qu’avoir une résolution identique sur tous les
moniteurs et le support unique de l’alignement horizontal sont levées ! Le comportement final des applications
en est largement influencé. En effet si l’application requête le nombre de moniteurs présents dans la session, le
monitor spanning aurait répondu un seul tandis que le multimon renvoie le nombre réel d’écrans sur le poste de
travail final (observé notamment sur les applications de présentation tel que Microsoft PowerPoint).
Le paramétrage du multimon se fait de plusieurs manières :
● Depuis le client RDC 7.1, dans l’onglet Affichage.

● Directement dans le fichier .rdp dans lequel il faudra positionner l’option suivante :
Use Multimon:i:<valeur>
Si <valeur> = 0, multimon désactivé
Si <valeur> = 1, multimon activé
● Depuis la console avec la commande mstsc /multimon
Bien évidemment, l’administrateur a main mise sur le comportement global du système et peut limiter le nombre
d’écrans directement sur la configuration du connecteur RDP du serveur RDS, depuis les stratégies de groupe
(Configuration ordinateur Stratégies Modèles d’administration Composants Windows Services Bureau
à distance Hôte de la session Bureau à distance Environnement de session à distance Limiter le nombre
maximal de moniteurs) ou encore au travers de la classe WMI Win32_TSClientSetting et sa propriété
MaxMonitors.

4. Support des polices ClearType
Avant d’entrer dans les détails de ce que Microsoft appelle le Font Smoothing, il convient de faire un petit rappel
sur ce que sont les polices ClearType (merci à Wikipédia pour la définition qui suit) :
"Les écrans dont la conception matérielle impose une position fixe aux pixels, comme les écrans plats modernes,
peuvent subir d’importantes déformations de crénelage qui se manifestent par des traits dentelés lorsqu’on
affiche des petits éléments à forts contrastes comme du texte. ClearType utilise une technique d’anticrénelage
au niveau du souspixel afin de réduire fortement les défauts perceptibles (les artefacts), lors de l’affichage des
manuscrits, et fait apparaître des caractères plus lisses et plus lisibles.
Bien que les détails de la mise en œ uvre précise de ClearType appartiennent à Microsoft, les principes, sur
lesquels ClearType est fondé, sont anciens et bien connus car ils ont déjà été utilisés sur d’autres systèmes
d’affichage, comme les ordinateurs à téléviseur NTSC des années 1970.
Comme la plupart des autres types de rendu subpixellaire, ClearType implique un accommodement où l’on sacrifie
un aspect de la qualité de l’image (sa couleur ou sa chrominance) en faveur d’un autre (sombre ou éclairé, sa
luminance). Ce compromis améliore l’apparence du texte car, lorsqu’on lit un document en noir et blanc, la
luminance est plus importante que la chrominance. Ce compromis fonctionne car il exploite certaines particularités
de notre vision."
Bien que tout le monde ne soit pas coutumier du fait, ce qu’il faut retenir, c’est que Windows 2008 R2 intègre le
support des polices ClearType ce qui permet d’obtenir un affichage du texte plus précis, transparent et lisse,
notamment sur les écrans LCD qui tendent à se démocratiser largement.
Dans les faits, Windows 2008 R2 RDS peut être configuré pour fournir le support des polices ClearType à un
ordinateur client se connectant avec le client d’accès à distance. Cette fonctionnalité, appelée Font Smoothing,
est disponible depuis le client RDC 6.

Afin de mettre à disposition des clients le Font Smoothing, il faut vérifier que la prise en charge ClearType est
activée (par défaut normalement) sur le serveur, en allant dans le Panneau de configuration Affichage
Ajuster le texte ClearType.
Ensuite, il faut activer le lissage des polices dans les options avancées du client RDC :

La configuration peut se faire directement dans le fichier .rdp :
allow font smoothing:i:<valeur>
Si <valeur> = 0, font smoothing désactivé
Si <valeur> = 1, font smoothing activé
Bien que l’activation du lissage des polices amène un confort visuel supplémentaire aux utilisateurs, il faut bien
garder à l’esprit que cela induit également une augmentation de la consommation de bande passante. De
manière générale, toute amélioration de confort d’affichage ou autre aura pour conséquence une augmentation
du trafic et donc une consommation de bande passante plus élevée.
5. Utilisation du client RDC 7.1
Options disponibles en ligne de commande
La commande Mstsc /? permet d’afficher les options disponibles.

Lancement du client
Le lancement se fait via le menu Démarrer Programmes Accessoires Connexion Bureau à distance ou
encore via la commande mstsc.exe.

Confort Visuel
Le client RDC supporte une palette de couleurs en qualité optimale 32 bits ainsi que le lissage des polices (déjà
évoqué précédemment).
Il est à noter cependant que le paramétrage défini sur le client ne s’applique que s’il est autorisé côté
serveur.
Redirection des ressources locales
Avec la nouvelle version du client RDC, il est toujours possible de paramétrer la redirection des périphériques
locaux « plug and play » mais on trouve en plus, le support des périphériques USB RemoteFX (dont nous
parlerons plus loin dans cet ouvrage).
Attention : tous les types de périphériques USB ne sont pas supportés.

Authentification du serveur
Depuis plusieurs années, Microsoft a fait de la sécurité du système d’informations son cheval de bataille.
Pourtant, lorsque l’on se connecte à un Terminal Server 2003, l’aspect sécurité se résume à saisir son compte et
son mot de passe dans la fenêtre de connexion. Il est légitime de se poser la question : "Comment être sûr que
je suis en train de saisir mon identifiant et mon mot de passe sur la bonne machine ?".
Microsoft a intégré une étape intermédiaire, appelée authentification serveur, avant la fenêtre de connexion,
qui permet de s’assurer de la validité du serveur sur lequel je m’apprête à m’authentifier.
Cette nouvelle fonctionnalité dispose de trois options :

● Établir la connexion et ne pas m’avertir : si cette option est activée, vous pouvez établir une connexion
même si l’identité de l’ordinateur distant ne peut pas être vérifiée.
● M’avertir : si cette option est activée (option par défaut), l’utilisateur est averti si l’identité de
l’ordinateur distant ne peut pas être reconnue et il est invité à choisir ce qu’il souhaite faire.
● Ne pas établir la connexion : si cette option est activée et que l’identité de l’ordinateur distant ne peut
pas être confirmée, la connexion échouera.
Authentification niveau réseau (NLA)
L’authentification au niveau réseau (NLA (Network Level Authentication)) est un complément de sécurité à la
classique authentification des utilisateurs. Ce processus opère avant qu’une connexion complète ne soit établie
entre le client et le serveur, qui se matérialise par l’apparition de la fenêtre de connexion. Dans les faits, pour
qu’un client puisse se connecter à un serveur RDS, il doit au préalable être authentifié par celuici.
Afin de pouvoir vérifier la compatibilité de la version de votre client RDC, accédez à la boîte de dialogue À propos
de, la prise en charge est mentionnée par Authentification au niveau du réseau prise en comme visible ci
dessous :

Afin d’activer NLA, il faut modifier le paramétrage du serveur 2008 R2 et activer les authentifications NLA, ceci via
le menu Panneau de configuration Système Paramètres d’utilisation à distance.
Enfin, si un client sous Windows XP antérieur au SP3 tente d’établir une connexion à un serveur 2008 R2 sur
lequel NLA est activé, il a le message d’erreur ci après :
Par défaut, Windows XP SP3 supporte NLA (CredSSP) mais n’est pas activé. Je vous invite à suivre l’article n°
951608 de Microsoft pour sa mise en œ uvre au travers de la base de registre.
Passerelle Bureau à distance
Le client RDC possède une option lui permettant de se connecter à un serveur RDS via Internet, de manière
sécurisée, en utilisant une passerelle qui encapsule le protocole RDP dans du HTTPS. Parmi les avantages de
cette solution, on peut citer les éléments suivants :
● Plus besoin de VPN pour accéder aux applications publiées.
● Réduction des problèmes de translation induits par les firewalls.
L’absence de VPN facilite le partage de la connexion avec d’autres applications installées sur l’ordinateur client.

Le paramétrage de la passerelle côté client se réalise de la manière suivante :
Depuis le client RDC, onglet Connexion puis menu Connexion depuis tout ordinateur Paramètres.
Les méthodes d’ouverture de session sont cellesci :
● M’autoriser à sélectionner ultérieurement : le choix de la méthode de connexion s’effectue lors de la

connexion.
● Demander le mot de passe (NTLM) : demande à l’utilisateur le mot de passe à l’initialisation de la
connexion.
● Carte à puce : demande à l’utilisateur d’insérer sa carte à puce lors de la connexion.
L’option Ignorer le serveur de Bureau à distance pour les adresses locales permet de ne pas diriger
le trafic vers la passerelle lorsque la connexion est initiée depuis le réseau local.
La mise en œ uvre côté serveur est décrite plus loin dans ce chapitre.

Expérience utilisateur enrichie
1. Nouvel environnement visuel
Windows 2008 R2 dispose des fonctionnalités dites expérience utilisateur qui permettent au client RDC de
mettre à disposition des utilisateurs un bureau au plus proche de celui de Windows 7, poussant la ressemblance
jusqu’au support de Windows Aero. Ces fonctionnalités sont aussi connues sous le nom de composition du
bureau.
Pour leur mise en œ uvre côté serveur RDS, installez la fonctionnalité Expérience utilisateur depuis la console de
gestion du serveur :
Validez l’ajout des fonctionnalités dépendantes requises :

Après un redémarrage du serveur, démarrez le service Thèmes et configurezle pour un type de démarrage
Automatique.
Accédez à la console de Configuration d’hôte de session bureau à distance, éditez les propriétés du connecteur
par défaut RDPTcp, dans l’onglet Paramètres du client, portez la limite du nombre maximal de couleur à 32 bits
par pixel. Cette même configuration peut être apportée via les stratégies de groupe.
Par défaut la composition du bureau n’est pas activée sur les serveurs RDS, il faut explicitement le spécifier au
travers de la stratégie de groupe Configuration ordinateur\Stratégies\Modèles d’administration\Composants
Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Environnement de session à
distance\Autoriser la composition du Bureau pour les sessions Bureau à distance.

Enfin, il faut activer la composition du bureau sur le client RDC dans les options avancées :
allow desktop composition:i:<valeur>

Si <valeur> = 0, composition du bureau désactivé
Si <valeur> = 1, composition du bureau activé
Une fois la connexion au serveur RDS établie, accédez au menu Panneau de configuration Personnalisation, et
sélectionnez le thème Windows 7.
Si le poste de travail client le supporte, flip3D peut même être invoqué !
Cette fonctionnalité n’est à ce jour pas supportée lors de l’utilisation de plusieurs écrans (fonctionnalités
multimon décrites précédemment).
2. Lecture audio/vidéo
La lecture audio/vidéo apporte aux sessions à distance un confort visuel surprenant. Le principe est d’effectuer la
redirection des flux audio et vidéo de la session distante vers le poste client en exploitant les ressources de ce
dernier. Windows Media Player tire pleinement parti de cette fonctionnalité.
Pour en profiter, installez les fonctionnalités Expérience utilisateur comme décrit précédemment dans la section
Nouvel environnement visuel.
Démarrez le service Audio Windows et modifiez le type de démarrage en Automatique.
Accédez à la console de Configuration d’hôte de session bureau à distance, éditez les propriétés du connecteur
par défaut RDPTcp, dans l’onglet Paramètres du client, portez la limite du nombre maximal de couleurs à
32 bits par pixel. Cette même configuration peut être apportée via les stratégies de groupe.
Par défaut la composition du bureau n’est pas activée sur les serveurs RDS, il faut explicitement la spécifier au
travers de la stratégie de groupe Configuration ordinateur\Stratégies\Modèles d’administration\Composants
Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Redirection de périphérique et

de ressource\Autoriser la redirection de la lecture audio et vidéo.
Ensuite, il faut configurer la lecture audio à distance dans le menu Ressources locales Sortie audio de
l’ordinateur distant Paramètres du client RDC :
audiomode:i:<valeur>
Si <valeur> = 0, lecture audio à distance activé sur l’ordinateur local
Si <valeur> = 1, lecture audio à distance activé sur l’ordinateur distant
Si <valeur> = 2, lecture audio à distance désactivé

La lecture d’un flux vidéo du type HD 1080p devient désormais possible en mode audio/vidéo à distance sans
même pouvoir constater un quelconque phénomène de lenteur ou désynchronisation audio/vidéo, le tout sans
excès de consommation RAM et CPU côté serveur !
3. Flux audio bidirectionnel
Cette nouvelle optimisation permet de profiter d’un nouveau type de flux audio. Jusquelà, pour la lecture de
documents sonores, le flux audio provenait du serveur RDS en direction du client RDC. Désormais le flux inverse,
à savoir du client RDC vers le serveur RDS, a été implémenté. Première utilité : profiter du périphérique
microphone sur le poste client au travers de la session distante, permettant dès lors l’utilisation de logiciel VoIP
ou encore de la reconnaissance vocale Windows.
Sa mise en œ uvre reste des plus simples, démarrer dans un premier temps le service Audio Windows et le
configurer en type de démarrage Automatique.
Par défaut la redirection de l’enregistrement audio n’est pas activée sur les serveurs RDS, il faut explicitement le
spécifier au travers de la stratégie de groupe Configuration ordinateur\Stratégies\Modèles
d’administration\Composants Windows\Services Bureau à distance\Hôte de la session Bureau à
distance\Redirection de périphérique et de ressource\Autoriser la redirection de l’enregistrement audio.

Ensuite, il faut configurer l’enregistrement audio à distance dans le menu Ressources locales Sortie audio de
l’ordinateur distant Paramètres du client RDC :
audiocapturemode:i:<valeur>
Si <valeur> = 0, enregistrement audio désactivé
Si <valeur> = 1, enregistrement audio activé

Authentification unique (Single Sign On)
1. Introduction
L’authentification unique (ou identification unique : en anglais Single SignOn ou SSO) est une méthode
permettant à un utilisateur de ne procéder qu’à une seule authentification pour accéder à plusieurs applications
informatiques (ou sites web sécurisés).
Les objectifs du SSO sont multiples :
● Simplifier, pour l’utilisateur, la gestion de ses mots de passe : en effet, plus l’utilisateur doit gérer de
mots de passe, plus il aura tendance à utiliser des mots de passe similaires ou simples à mémoriser (voir
même mettre un postIt sous son clavier ou dans un tiroir), abaissant par la même occasion le niveau de
sécurité du système d’informations.
● Simplifier la gestion des données personnelles détenues par les différents services en ligne, en les
coordonnant par des mécanismes de type métaannuaire.
● Simplifier la définition et la mise en œ uvre de politiques de sécurité.
Jusqu’à présent, pour établir une connexion à un serveur TSE, l’utilisateur devait, soit entrer son mot de passe
(ou son code PIN dans le cas d’une smart card) à chaque connexion (ce qui exaspère généralement les
utilisateurs), soit enregistrer celuici « en dur » dans un fichier .rdp (ce qui reste une faille de sécurité très
importante).
La fonctionnalité de SSO est disponible en mode bureau ou applications distantes et supporte les
authentifications par mot de passe ou smart card.
Enfin, la mise en œ uvre du SSO nécessitera a minima un client XP SP3 (avec CredSSP activé, voir article Microsoft
n°951608), un serveur Windows 2008 R2 et un environnement Active Directory.
2. Paramétrage du SSO
Côté serveur
L’activation du SSO sur un serveur RDS nécessite de configurer le connecteur RDP, via la console de
Configuration d’hôte de session Bureau à distance, en positionnant le paramètre Couche de sécurité sur
Négocier ou SSL a minima.

Côté client
Afin d’activer le SSO côté client, le plus simple est de passer par une stratégie de sécurité (mais il est également
possible d’utiliser gpedit.msc) afin de positionner le paramètre Autoriser la délégation des informations
d’identification par défaut situé dans Configuration Ordinateur Modèles d’administration Système
Délégation d’information d’identification pour y ajouter la liste du ou des serveur(s) RDS/RemoteApp (préfixé
par termsrv/ ; par exemple termsrv/rds2008r2.w2k8forest.local).

Distribution d’applications transparentes (RemoteApp)
1. Introduction
RemoteApp est une fonctionnalité qui permet aux utilisateurs d’accéder à des applications exécutées à distance
par le biais des services RDS. L’application distante se lance directement par le menu démarrer du poste de
travail de l’utilisateur et apparaît de manière identique à une véritable application locale (fenêtre
redimensionnable et accessible dans la barre des tâches).
Avec Windows 2008 R2, plusieurs méthodes sont disponibles pour donner l’accès aux applications distantes :
● Utilisation d’un lien dans une page web.
● Utilisation d’un fichier .rdp.
● Ajout d’une icône dans le menu Démarrer (via un MSI).
● Double clic sur un fichier (doc par exemple) dont l’extension a été associée à une application distante
(via un MSI).
2. Mise en œuvre
Principe de fonctionnement
Installation du service Bureau à distance 2008 R2 (RDS)
Avant de se lancer dans l’installation des services Bureau à distance, il faut bien s’assurer qu’aucune application

(que l’on souhaite déployer aux utilisateurs) n’est déjà installée sous peine de s’apercevoir a posteriori qu’elle ne
fonctionne pas ou mal…
Ouvrez la console Gestionnaire de serveur et lancez l’assistant d’ajout d’un nouveau rôle :
Choisissez le ou les rôle(s) à installer :
Choisissez la méthode d’authentification en gardant bien à l’esprit que l’authentification au niveau
réseau n’est pas supportée par les clients antérieurs à Windows XP SP3.

Spécifiez le mode de licence à utiliser (ce point sera expliqué plus loin dans cet ouvrage) :
Sélectionnez les groupes autorisés à utiliser les services Bureau à distance :

Le groupe sélectionné précédemment sera automatiquement ajouté au groupe local Utilisateurs du
Bureau à distance du serveur RDS.
Définissez les paramètres de l’expérience client :
Un récapitulatif des choix effectués vous est proposé avant de lancer l’installation, et un redémarrage du serveur
est nécessaire :

Après le redémarrage du serveur, l’assistant d’installation indique le résultat de l’installation :
Installation des applications
Après la configuration initiale du RDS, il faut installer les applications qui seront déployées aux utilisateurs. Pour
ce faire, il est nécessaire de mettre le serveur dans un mode de fonctionnement particulier appelé mode
installation, ce qui peut s’effectuer de plusieurs manières :
● Lancer Installer une application sur un serveur Bureau à distance situé dans le panneau de
configuration.
● Ouvrir une invite de commande et taper la commande change user /install, procéder à l’installation

du produit, puis à la fin de l’installation taper la commande change user /execute. Attention cette
série de commandes doit être exécutée pour chaque application à installer. Il est possible de connaître à
tout instant le mode de fonctionnement du serveur à l’aide de la commande change user /query.
Publication des applications
Lancez la console Gestionnaire RemoteApp qui se trouve dans les outils d’administration ou tapez la
commande remoteprograms.msc.
Lancez l’assistant d’ajout des programmes RemoteApp :

Sélectionnez les applications (si une application n’apparaît pas, ajoutez le fichier exécutable en cliquant
sur Parcourir).
Si des paramètres supplémentaires doivent être positionnés (par exemple des arguments de ligne de
commande ou encore un ciblage sur des groupes d’utilisateurs), sélectionnez l’application concernée et
cliquez sur Propriétés.

Une fois la validation effectuée, les applications apparaissent au bas de la console :
Il est à noter qu’il est possible d’effectuer un export des applications paramétrées, afin d’accélérer la mise en
œ uvre d’un serveur RDS supplémentaire. Les prérequis pour effectuer cette opération en direct (sans passer
par un export/import de fichiers) sont les suivants :
● Il faut être connecté avec un compte d’administrateur.
● Les applications doivent exister sur le serveur cible.
● WMI doit être opérationnel.
Paramétrage des options par défaut
Le paramétrage des options utilisées par défaut par les clients distants se fait dans Paramètre du serveur hôte
de session Bureau à distance. Les options paramétrables portent sur les points suivants (pour le détail des
options, se référer au technet de Microsoft) :
● Serveur hôte de session Bureau à distance :

● Passerelle des services Bureau à distance :
● Signature numérique :

● Paramètres RDP communs :
● Paramètres RDP personnalisés :

Déploiement des applications sur les clients
Afin de mettre à disposition des clients les applications paramétrées précédemment, il est possible d’utiliser soit
des fichiers .rdp soit des packages MSI. Ceuxci doivent être positionnés sur un partage réseau ou déployés sur
les machines clientes à l’aide, par exemple, de System Center Configuration Manager ou de l’AD.
La création de ces fichiers se fait directement depuis le gestionnaire RemoteApp :
Création d’un fichier .rdp :
Sélectionnez l’application désirée et cliquez sur Créer le fichier .rdp :

Effectuez les paramétrages souhaités, puis validez (il est conseillé d’utiliser un partage réseau comme
emplacement pour le package).
Création d’un package MSI :
Sélectionnez l’application désirée (un choix multiple est possible) et cliquez sur Créer le package
Windows Installer.
Effectuez les paramétrages souhaités, puis validez (il est conseillé d’utiliser un partage réseau comme
emplacement pour le package).

Définissez le positionnement des raccourcis (menu démarrer, bureau…) et l’association des extensions
de fichiers. Si une association est effectuée, alors l’ouverture d’un fichier local se fera dans une
application distante.

Maintenant que les packages sont créés, il ne reste plus qu’à définir la méthode de déploiement adéquate.
Le plus simple, mais aussi le moins flexible, est d’indiquer à ses utilisateurs le chemin réseau (ou faire un
mappage dans un script) vers le partage. Si cette solution est implémentée, n’oubliez pas de positionner des
permissions sur les fichiers, afin d’en limiter l’utilisation aux utilisateurs (groupes de préférence) concernés.
La solution que nous conseillons est l’utilisation d’un outil de déploiement de package tel que System Center, ou
bien tout simplement l’Active Directory .
Dans l’exemple qui va suivre, un déploiement via une stratégie de groupe AD est utilisé :

Lancez la MMC Gestion de stratégie de groupe (ou gpmc.msc) et créez un nouvel objet GPO (Group
Policy Object) sur l’OU contenant les objets concernés, et positionnez un filtrage de sécurité (afin de
choisir les groupes d’utilisateurs qui recevront les applications).
Éditez la stratégie, déployez l’arborescence pour atteindre la stratégie d’installation de logiciel, puis
créez un nouveau package :
Choisissez les packages à déployer et la méthode de déploiement.
Après le déploiement sur les postes clients, les applications seront disponibles dans le menu Démarrer :

Le lancement d’une application depuis le poste client, bien que s’exécutant à distance, apparaîtra alors à
l’utilisateur comme si elle s’exécutait localement : c’est ce que l’on appelle dans le jargon une application
« seamless » ou « transparente » :

Avancées technologiques du portail web (RD Web Access)
1. Introduction
Dans la version précédente des services TSE, il existait une version web du client RDC que l’on pouvait déployer
à partir d’une page web publiée sous IIS (sous réserve d’avoir les droits d’installer un ActiveX). L’ajout, dans une
page web, d’un appel à cet ActiveX permettait d’ouvrir un bureau à distance à l’intérieur de son navigateur
Internet.
Avec l’avènement du client RDC dès sa version 6, le composant ActiveX est maintenant intégré, permettant en
outre d’accéder au nouveau portail web et d’y lancer des applications publiées.
2. Installation
L’installation de ce composant se fait depuis le gestionnaire de serveur, dans l’option Ajouter des services de

rôle.
L’installation du portail Web nécessite la présence d’IIS et propose son installation si celuici n’est pas détecté
par le programme d’installation.
Lorsque l’installation est achevée, un raccourci vers https://localhost/RDWeb est ajouté dans les outils

d’administration ainsi que deux groupes locaux (TS Web Access Administrators et Ordinateurs Accès Web TS).
L’authentification est définie de base via formulaires, rappelant directement le style de Microsoft Exchange avec
son webmail OWA (Outlook Web Access, désormais Outlook Web App sous sa mouture 2010). Le profil public, à la
différence du profil privé, ne mémorise pas le nom d’utilisateur saisi et les cookies ont une durée d’expiration de
vingt minutes, contre quatre heures et une mémorisation du login avec le profil privé.
Une fois l’authentification utilisateur effectuée, les applications publiées apparaissent.
Dans le cas où le serveur RD Web Access n’est pas luimême le serveur RemoteApp, il faudra autoriser celuici en
l’ajoutant au groupe local Ordinateurs Accès Web TS.
Enfin, il est possible de choisir la source des données (local host par défaut) utilisée pour peupler le portail à
partir de l’onglet Configuration de l’interface d’administration.

Il est désormais possible de regrouper plusieurs sources RemoteApp, mais également d’utiliser les
services Broker.
3. Utilisation du portail par les clients
Tout d’abord, avant de pouvoir utiliser le portail il faudra disposer de la version 7 du client RDC disponible dès le
SP3 de XP, dans le cas contraire vous obtiendrez ce message :
Dès lors que le client RDC est installé, le lancement d’une application se fait par un simple clic dans le portail.

Un point fort mis en œ uvre sous Windows 2008 R2 avec les services RD Web Access, est qu’il est désormais
possible de filtrer les applications publiées et mises à disposition des utilisateurs au travers de groupes d’accès !
Cela se définit au travers des propriétés des applications recensées dans la console RemoteApp décrite
précédemment.

Impressions simplifiées (RD Easy Print)
1. Introduction
Depuis les premières versions de Terminal Server, les impressions ont toujours été un point dur, voire même,
dans certains cas, un cassetête insoluble, et ce, pour deux raisons : les pilotes d’impression et la consommation
de bande passante. Afin de résoudre ces problèmes, de nombreux éditeurs (Citrix, Thinprint) proposent des
pilotes dits universels qui remplacent le système d’impression classique.
2. Présentation de RD Easy Print
Pour ne pas être en reste, Microsoft a enfin pris le problème à bras le corps, et propose, avec Windows 2008 R2,
un système d’impression sans pilote appelé Easy Print qui permet de simplifier la redirection des imprimantes
clientes. Dans les faits, RD Easy Print agit comme un proxy pour toutes les demandes d’impression et les
réoriente vers la machine cliente, sans pour autant installer un quelconque pilote sur le serveur RDS.
Prérequis
Dans la nouvelle version de Windows 2008 R2, les prérequis côté serveur ont disparus, et cela se résume à
disposer côté client du RDC en version 6.1 minimum ainsi que le Framework 3.0 SP1. Par défaut, le serveur RDS
tentera d’utiliser le driver Easy Print si le client le supporte, sinon il tentera de trouver un driver approprié dans
sa liste de drivers. Ce comportement par défaut peut être modifié au travers de la stratégie Configuration
ordinateur Modèles d’administration Composants Windows Services Bureau à distance Hôte de la
session bureau à distance Redirection de l’imprimante Utiliser d’abord le pilote d’imprimante Easy Print
des services Bureau à distance.
3. Utilisation
Afin de bien comprendre ce qu’il se passe, plusieurs imprimantes ont été déclarées sur un poste client Windows
7.

Le lancement d’une application distante permet de valider le fait que la redirection des imprimantes locales dans
la session distante soit effective.
Dans notre exemple, l’activation de la nouvelle option de réorientation de l’imprimante par défaut (nouvelle
option des GPO, Configuration ordinateur Modèles d’administration Composants Windows Services
Bureau à distance Hôte de la session bureau à distance Redirection de l’imprimante Rediriger
uniquement l’imprimante cliente par défaut) permet de rediriger uniquement l’imprimante par défaut du client
(ici, une HP LaserJet 4).

L’affichage des préférences de l’imprimante laisse entrevoir un message annonçant la redirection des
préférences de l’imprimante sur le poste client, et la fenêtre des propriétés de l’imprimante du client est bien
affichée :

Enfin, si l’on regarde les imprimantes du serveur RDS, on s’aperçoit également qu’aucune nouvelle imprimante
n’apparaît sur le serveur confirmant bien la transparence de l’opération de redirection.

4. Nouvelles stratégies de sécurité
Windows 2008 R2 propose évidemment son lot de nouvelles stratégies paramétrables pour les services Bureau à
distance. Pour s’assurer que les clients utilisent bien RD Easy Print et limite le nombre d’imprimantes à rediriger
dans la session distante, deux nouvelles stratégies sont particulièrement intéressantes :
Ces stratégies se situent sous le nœ ud : Configuration Ordinateur Stratégies Modèles d’administration

Services Bureau à distance Hôte de la session Bureau à distance Redirection de l’imprimante.
● Utiliser d’abord le pilote d’imprimante Easy Print des services Bureau à distance
Les valeurs possibles sont :
Activez ou ne configurez pas ce paramètre de stratégie : le serveur RDS tente d’abord d’utiliser le pilote de la
fonction d’impression facile des services Bureau à distance pour installer toutes les imprimantes clientes. Si, pour
une raison quelconque, le pilote d’imprimante de la fonction d’impression facile des services Bureau à distance ne
peut pas être utilisé, un pilote d’imprimante sur le serveur RDS correspondant à l’imprimante cliente est utilisé. Si
le serveur RDS n’a pas de pilote d’imprimante correspondant à l’imprimante cliente, l’imprimante cliente n’est pas
disponible pour la session des services Bureau à distance.
Désactivez ce paramètre de stratégie : le serveur RDS tente de trouver un pilote d’imprimante adéquat pour
installer l’imprimante cliente. Si le serveur RDS n’a pas de pilote d’imprimante correspondant à l’imprimante
cliente, il tente d’utiliser le pilote de la fonction d’impression facile des services Bureau à distance pour installer
l’imprimante cliente. Si, pour une raison quelconque, le pilote d’imprimante de la fonction impression facile des
services Bureau à distance ne peut pas être utilisé, l’imprimante cliente n’est pas disponible pour la session des
services Bureau à distance.
● Rediriger uniquement l’imprimante cliente par défaut
Les valeurs possibles sont :
Activez ce paramètre de stratégie : seule l’imprimante cliente par défaut est redirigée dans les sessions des
Désactivez ou ne configurez pas ce paramètre de stratégie : toutes les imprimantes clientes sont redirigées
dans les sessions des services Bureau à distance.

Passerelle RDS 2008 R2 (RD Gateway)
1. Introduction
Le rôle de passerelle pour les services Bureau à distance (bureau ou applications distantes) permet aux
utilisateurs nomades de se connecter aux ressources de l’entreprise à partir de n’importe quel accès Internet.
Cette passerelle s’appuie toujours sur le protocole RDP mais l’encapsule au travers du protocole HTTPS, afin de
sécuriser la connexion dans un tunnel crypté.
Intérêts de la solution
RD Gateway autorise un accès sécurisé au réseau interne sans utiliser de client VPN.
Il accepte une connexion point à point (RDP) au réseau plutôt que d’ouvrir l’intégralité des ressources.
Cette solution admet l’établissement d’une connexion vers des machines situées derrière un parefeu en ouvrant
une connexion sur le port 443 (généralement autorisé) au lieu du port standard RDP (3389) qui est normalement
bloqué.
La console de gestion permet de définir les stratégies d’autorisation que devront respecter les clients ouvrant
une session sur le réseau. Par exemple :
● Utilisateurs ou groupes autorisés à se connecter
● Ressources qui seront accessibles
● Groupe d’appartenance de la machine cliente
● Type d’authentification (mot de passe, smart card ou autre)
● Utilisation de NAP (Network Access Protection)
● Activation de la redirection des périphériques locaux
● Utilisation conjointe avec ISA Server
● Audit des événements de connexion
Synoptique de fonctionnement

Fonctionnement d’une architecture TS Gateway
L’ordinateur client, situé dans la zone Internet, tente d’établir une connexion avec un serveur RDS situé sur le
réseau interne, derrière une paire de parefeu.
La passerelle RDS est cachée derrière le premier parefeu qui supprime la partie http des paquets entrants et lui
transmet les paquets RDP.
La passerelle RDS interroge le serveur de stratégie réseau (si une infrastructure NAP est présente) afin de
vérifier si le client est autorisé à utiliser le serveur RDS, puis interroge l’Active Directory afin de procéder à
l’authentification de l’utilisateur.
Enfin, une fois authentifié, l’utilisateur peut lancer les applications distantes disponibles sur le serveur RDS.
2. Mise en œuvre
Prérequis
Pour mettre en place une passerelle RD Gateway, il faut disposer des éléments suivants :
● Windows 2008 R2
● Certificat SSL
● Active Directory
● IIS 7.5
● Proxy RPC sur http
● Serveur NPS
● Service d’activation des processus Windows
Installation
Installation d’un certificat SSL :
Le certificat peut être délivré par une autorité de certification publique (telle VeriSign) ou privée, voire même
autosignée à des fins de maquettage, comme c’est le cas ici.

Dans le cas où le certificat n’émanerait pas d’une autorité de certification publique, il faudrait ajouter le
certificat délivré sur les serveurs RDS et les postes clients.
Définition d’une stratégie d’autorisation des connexions au service Bureau à distance (RDS CAP) :
Les stratégies CAP permettent de préciser qui peut utiliser et donc se connecter à la passerelle RDS.
Pour ce faire, il suffit de déterminer un groupe d’utilisateurs qui peut être local à la passerelle ou dans l’annuaire
Active Directory :
Attention, bien que les stratégies CAP autorisent les utilisateurs à accéder à la passerelle, elles ne les
autorisent pas pour autant à se connecter aux ressources des services Bureau à distance.
Choix de la méthode d’authentification :

Ici, une stratégie d’autorisation de connexion aux services Bureau à distance au travers de la passerelle RDS doit
être définie. Vous avez le choix de la méthode d’authentification : mot de passe / carte à puce.
Définition de la stratégie d’accès aux ressources (RDS RAP) :
Les stratégies d’autorisation d’accès aux ressources permettent de déterminer les ressources réseaux internes
(ordinateurs) auxquelles les utilisateurs distants peuvent avoir accès via la passerelle RDS.
Installation d’un serveur NPS :
Les utilisateurs distants se connectant au réseau via la passerelle RDS, sont autorisés à accéder aux ordinateurs
du réseau interne s’ils répondent aux conditions spécifiées dans au moins une stratégie d’autorisation des

connexions et une stratégie d’autorisation d’accès aux ressources.
3. Console de gestion de la passerelle RDS
La console de gestion permet de paramétrer toutes les options disponibles sur la passerelle, de créer les
stratégies d’autorisation des connexions et d’accès aux ressources.
La console permet également de visualiser et de gérer les connexions actives sur la passerelle RDS.

Le nouveau Connection Broker
1. Introduction
Remote Desktop Connection Broker est le nouveau nom d’un service déjà connu sous Windows 2003 en tant

que Session Directory (annuaire de sessions) et sous Windows 2008 en tant que Session Broker. Cette
fonctionnalité, uniquement disponible avec une version Entreprise sous Windows 2003, permet aux utilisateurs
ayant une session dans un état déconnecté sur un serveur TSE (membre d’une ferme) de pouvoir s’y
reconnecter. En fait, l’annuaire de session maintient une liste indexée par utilisateur et serveur TS afin de
permettre la redirection d’un utilisateur vers le serveur hébergeant déjà une session déconnectée à son nom, et
ce, même si la connexion est initiée depuis une autre machine.
Sous Windows 2003, une ferme de serveurs est généralement couplée à un mécanisme de répartition de charge
(Windows NLB, ou autre), et associée à un annuaire de session afin d’assurer souplesse, évolutivité et haute
disponibilité.
Dès Windows 2008, Session Directory disparaît, laissant place au TS Session Broker qui incorpore un mécanisme
de répartition de charge amené à remplacer NLB (bien qu’il puisse encore l’utiliser, au même titre qu’un
quelconque produit tiers).
Par ailleurs, et contrairement au Session Directory, le Session Broker est disponible dès la version Standard de
Windows 2008.
Avec Windows 2008 R2, cette technologie s’appelle Connection Broker et de nouvelles fonctionnalités
apparaissent prenant notamment en compte les accès via RemoteApp. Ce service reste également disponible
dès la version Standard de Windows 2008 R2.
2. Fonctionnalités disponibles
Comme cela a déjà été évoqué dans l’introduction, le but du Connection Broker est de répartir la charge des
sessions au sein de la ferme des serveurs hôte de Bureau à distance, et ce, de manière équilibrée (redirection
des nouvelles connexions vers le serveur le moins chargé).
Connexion Broker opère en deux phases :
● La connexion initiale de l’utilisateur est envoyée vers un serveur RDS de la ferme par un premier
dispositif de répartition de charge (tourniquet DNS, NLB, produits ou matériels d’éditeurs tiers). Après
l’authentification, le serveur RDS ayant accepté la requête de connexion initiale, interroge le Connection
Broker pour savoir vers quel serveur l’utilisateur doit être redirigé.
● L’utilisateur est aiguillé vers le serveur affecté par le Connection Broker d’après les critères suivants :
■ Un utilisateur ayant déjà une session déconnectée sur un serveur de la ferme est réorienté vers lui
afin de la récupérer.
■ Un utilisateur n’ayant pas de session existante est acheminé vers le serveur ayant le moins de
connexions actives.
Connection Broker limite le nombre de requêtes de connexion en attente pour un serveur à dix, afin d’éviter un
phénomène connu sous le nom de Black Hole Effect (les administrateurs de fermes Citrix en ont certainement
entendu parler, voire subi…) et qui peut conduire à la saturation d’un serveur de la ferme (ce qui risque de
mécontenter les utilisateurs souhaitant ouvrir une session).
En fait pour bien comprendre ce phénomène, supposons que nous sommes le matin et que tous les utilisateurs
lancent une connexion distante afin de consulter leurs emails. L’ensemble des serveurs de la ferme se
retrouvent alors avec un taux de charge pouvant atteindre 70 à 80 % de leur maximum. En parallèle, je démarre
un autre de mes serveurs RDS, dont je viens de terminer la maintenance, et là en moins de temps qu’il n’en faut
pour le dire, la hotline est saturée d’utilisateurs n’arrivant pas à se connecter. Que s’estil passé ?

Rien de bien mystérieux en fait :
Le nouveau serveur reçoit toutes les nouvelles demandes d’ouverture de session car il sera systématiquement
considéré comme le moins chargé des serveurs de la ferme par le load balancer ce qui conduit à sa saturation.
Connection Broker permet également d’assigner un poids aux serveurs de la ferme afin de compenser les écarts
de performances liés au matériel. Attention toutefois, ce mécanisme ne permet pas d’atteindre la finesse de
paramétrage proposée par d’autres éditeurs, tel Citrix ou Systancia.
En outre, un nouveau mode maintenance (drain mode) fait son apparition et permettra de mettre
momentanément hors ligne un serveur de la ferme pour effectuer des opérations de maintenance. À la différence
de ce qui existe sous Windows 2003, le drain mode permet d’interdire de nouvelles connexions vers un serveur
RDS, mais permet aux utilisateurs ayant une session déconnectée de la récupérer afin de terminer leurs travaux
en cours.
Schéma de principe
Particularités du Connection Broker utilisé avec un tourniquet DNS (DNS Round Robin)
La solution de répartition de charge (pour la phase initiale précédemment évoquée) la plus économique reste
sans nul doute l’utilisation d’un tourniquet DNS. Pour ce faire, il suffit de créer un enregistrement d’hôte (type A),
pour chaque adresse IP des serveurs RDS composant la ferme, avec le nom choisi pour la ferme (le nom de la

ferme est celui qui sera utilisé par les clients pour se connecter à la ferme et affecté au Connection Broker).
Le serveur DNS utilise un mécanisme de tourniquet afin de ne pas systématiquement retourner la même réponse
aux clients et permettre ainsi une répartition de charge des connexions initiales, vers les différents serveurs de
la ferme.
La connexion initiale s’opère donc comme suit :
● Le client émet une requête au DNS afin d’avoir la liste des IP correspondant aux serveurs de la ferme et
met en cache l’ensemble de la réponse (la commande ipconfig /displaydns permet de voir le cache du
client DNS).
● Le client essaie d’établir une connexion vers la première adresse IP retournée par le DNS. Si la
connexion échoue, le client essaie de se connecter à l’adresse suivante (après un "time out" de 20
secondes).
Ce mécanisme assure une sorte de tolérance de panne (très basique), si un des serveurs RDS est indisponible.

3. Mise en œuvre
Prérequis
Le serveur hébergeant le service doit être sous Windows 2008 R2 mais pas forcément serveur hôte Bureau à
distance. Il est d’ailleurs conseillé de l’installer sur un serveur backend (serveur de fichiers par exemple).
Le service peut être utilisé par différentes fermes (attention à la charge).
Tous les serveurs constituant la ferme doivent être sous Windows 2008 R2 avec les mêmes applications
installées.
Les clients doivent utiliser au minimum un client RDC 5.2.
Installation
Ouvrez le Gestionnaire de serveur.
Si le rôle Services Bureau à distance est déjà installé, ajoutez le service de rôle Service Broker pour les
connexions Bureau à distance.
Sinon ajoutez le rôle Services Bureau à distance, puis choisissez le service de rôle Service Broker pour les
connexions Bureau à distance.
Ajoutez les serveurs RDS composant la ferme au groupe Ordinateurs du service Session Broker créé durant
l’installation. Si le service de rôle Connection Broker est installé sur un contrôleur de domaine, le groupe
Ordinateurs du service Session Broker est porté dans l’Active Directory en tant que groupe de sécurité local.
Configurer Connection Broker avec une stratégie de sécurité
Pour éviter toute erreur, il est plus judicieux de configurer les serveurs à utiliser Connection Broker au travers
d’une stratégie. La même configuration sera alors appliquée à vos serveurs RDS.
Créez une GPO que vous appliquerez sur une OU contenant les serveurs RDS.
Sous Configuration Ordinateur/Stratégies/Composants Windows/Service Bureau à distance/Hôte de la

session Bureau à distance/Service Broker pour les connexions Bureau à distance :
Activez l’option Joindre le service Broker pour les connexions Bureau à distance.
Activez l’option Configurer le nom de la batterie de serveurs du service Broker pour les connexions
Bureau à distance et ajoutez le nom DNS de la ferme.
Activez l’option Configurer le nom du serveur du service Broker pour les connexions Bureau à
distance et ajoutez le nom DNS du serveur ayant le service.
Activez l’option Utiliser l’équilibrage de charge du service Broker pour les connexions Bureau à
distance.

Après l’application de la stratégie sur le(s) serveur(s) RDS de la ferme, un message indiquant que le serveur a
bien joint la batterie (ferme) de serveurs doit apparaître dans le journal système.
Il est possible d’effectuer la vérification de l’application des paramètres par stratégies via la console de
configuration d’hôte de session Bureau à distance dans la section paramètres Service Broker pour les
connexions Bureau à distance :

Enfin, après avoir publié les applications sur tous les serveurs RDS de la ferme, il ne reste plus qu’à générer un
nouveau package MSI ou un fichier .rdp en utilisant, comme nom de serveur, le nom de la ferme déclarée dans le
DNS.

Virtualisation IP des services Bureau à distance (RD IP
Virtualization)
1. Introduction
Une autre fonctionnalité apparue avec Windows 2008 R2 est RD IP Virtualization. Cela consiste à délivrer des
adresses IP à des sessions Bureau à distance selon une session ou un programme spécifique. Cela sert à
déjouer une contrainte de certaines applications imposant aux connexions sources d’utiliser des adresses IP
différentes.
En effet, et sans ce mécanisme, les applications 1, 2 et 3 qui s’exécutent sur le serveur RDS (serveur de bureau à
distance) se présenteront au serveur de base de données (serveur BDD) avec la même adresse IP, soit
10.0.0.20. L’application 1 sera autorisée à se connecter tandis que les applications 2 et 3 se verront refuser
l’accès.
Après l’activation du mécanisme de virtualisation d’adresse IP (ici en mode par application), il sera possible
d’émuler trois adresses IP source (10.0.0.20, 10.0.0.21 et 10.0.0.22) en partance du serveur RDS vers le serveur
BDD. Les trois applications auront alors un fonctionnement correct et simultané.

2. Mise en œuvre
Pour une mise en œ uvre simple de RD IP Virtualization, il vous faudra un serveur DHCP correctement configuré
(autorisé dans l’AD, étendues et options correctement définies).
L’activation et la configuration se fait à l’aide de la console Configuration d’hôte de session Bureau à distance,
sous la catégorie Virtualisation IP des services Bureau à distance.
Il suffit de cocher la case Activer la virtualisation IP, de sélectionner l’interface réseau à utiliser et de spécifier le
mode de virtualisation IP :
● Par session : chaque session bénéficiera de la virtualisation d’adresse IP des services Bureau à
distance.
● Par programme : les applications listées bénéficieront de la virtualisation d’adresse IP des services
Bureau à distance.

3. Configuration avancée
Il est également possible de configurer la virtualisation IP des services Bureau à distance plus finement au
travers de la base de registre pour y affecter un pool d’adresses IP spécifique. Cela peut être utile dans le cas où
aucun serveur DHCP ne serait accessible sur le réseau.
Accédez à la base de registre à l’aide de l’outil regedit.exe.
Ouvrez la clef de registre cidessous :
HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\TSAppSrv\VirtualIP
Paramétrer les entrées de registre suivantes :
● EnableVirtualIP (REG_DWORD)
■ 0x0 : désactiver la virtualisation IP des services Bureau à distance.
■ 0x1 : activer la virtualisation IP des services Bureau à distance.
● VirtualMode (REG_DWORD)
■ 0x0 : mode par session.
■ 0x1 : mode par application.
● AdapterAddress (REG_SZ)

■ Contient l’adresse MAC (adresse de l’interface réseau utilisée pour la virtualisation IP).
● IPPool (REG_SZ)
■ Définir sa valeur à "%SystemRoot%\system32\TSVIPool.dll" pour l’utilisation d’une plage IP statique.
■ Laisser vide pour l’utilisation d’adresses IP spécifiques.
Ouvrir la clef de registre cidessous :

HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\TSAppSrv\VirtualIP\IPPool
Paramétrer les entrées de registre suivantes :
● Start (REG_SZ)
■ Contient l’adresse de début de la plage IP.
● End (REG_SZ)
■ Contient l’adresse de fin de la plage IP.
● SubnetMask (REG_SZ)
■ Contient l’adresse de sousréseau de la plage IP.
● StaticIPList (REG_MULTI_SZ)
■ Liste les IP spécifiques à utiliser.
S’il existe à la fois des adresses IP et une plage d’adresse IP de définis, RD IP Virtualization utilise
d’abord les adresses IP.

Gestion des licences
1. Rappel : la gestion de licences TSE 2003
Ce chapitre est généralement complexe du fait de la variété des possibilités d’achat et de gestion des licences
achetées, mais surtout des situations dans lesquelles les entreprises se trouvent. Comme vous pourrez le
découvrir plus loin, vous disposez de 120 jours de tranquillité, appelés période de grâce, afin de comprendre tout
cela et de mettre correctement en œ uvre le système de licences, sans gêner le fonctionnement global de votre
solution.
Étant donné que les services TSE sont inclus dans le système serveur Windows 2003, et qu’il n’y a donc pas de
licence serveur particulière à acquérir pour pouvoir utiliser les fonctionnalités TSE, ce chapitre portera
exclusivement sur les mécanismes de gestion des licences d’accès client, communément appelés CAL par
abréviation (Client Access License en anglais), et particulièrement sur les licences associées à Windows 2003
Server (sauf précision contraire pour des systèmes plus anciens).
Les deux catégories de CAL
Pour pouvoir se connecter à un serveur TSE, un poste client doit disposer de deux CAL différentes. Disposer ne
veut pas nécessairement dire installées : selon le système du poste client, il n’y a pas de manipulation
particulière à faire sur le poste luimême (et c’est généralement le cas à 98 %). Cela veut donc dire qu’il convient
d’acquérir ses licences conformément aux préconisations de l’éditeur, voire de les installer sur un serveur de
licences comme nous le verrons plus loin.
La première licence que doit posséder le poste client est une licence d’accès client Windows 2003 Server, que
l’on peut qualifier assez facilement de CAL 2003 standard, sans faire analogie avec la version de Windows 2003
Server luimême. Cette licence est nécessaire pour accéder aux ressources d’un serveur Windows 2003, telles
que les fichiers, les imprimantes, Active Directory, etc.
Dans le cas spécifique de l’accès aux services TSE, le poste client doit posséder une licence d’accès client aux
services de terminaux pour Windows 2003 Server, que l’on peut appeler couramment CAL 2003 TSE. Cette
licence doit être installée sur un serveur de licences CAL TSE dans les 120 jours suivant le premier accès au
serveur.
Les licences applicatives
Le principe reste relativement simple : si un certain nombre de clients accède à un serveur TSE diffusant une
application A, alors vous devez vous porter acquéreur du nombre de licences correspondant au nombre de clients
qui POTENTIELLEMENT peuvent y accéder. En général donc, le nombre de licences de l’application A à acquérir
correspond au nombre de licences CAL TSE achetées pour ce serveur.
Cette approche peut être pondérée par la mise en œ uvre de techniques particulières comme par exemple les
stratégies de restrictions logicielles, afin de réduire le nombre de licences à acquérir en fonction du nombre
d’utilisateurs réels d’une application plutôt que l’ensemble des utilisateurs du serveur TSE.
Il est aussi possible de rentrer dans un contexte de licences concurrentes dès lors qu’un serveur TSE dédié sera
limité en nombre d’accès au niveau du couple port de connexion/écouteur RDPTCP.
Les trois types de CAL
Que ce soit pour les CAL 2003 standard ou les CAL 2003 TSE, il existe trois types de licences : les licences par
utilisateur (user en anglais) ou par périphérique/dispositif (device en anglais), et la licence External Connector.
La différenciation de type par utilisateur et par périphérique/dispositif n’existait pas avec les précédentes
versions de Windows Server. Elle a été créée pour répondre aux besoins des entreprises, tant en terme de
gestion des licences que de réduction des coûts globaux de licences, en permettant de coller au mieux à
l’organisation de l’entreprise.

Donc les CAL 2000 TSE, nécessaires avec toutes versions de Windows 2000 Server dont les services de
terminaux ont été activés, correspondent en fait à l’actuelle licence par périphérique/dispositif. Ceci a pour
conséquence d’établir le type de licence actuellement livré par défaut si aucune précision sur le type n’est
apportée lors de la commande de CAL 2003 TSE : la licence par périphérique/dispositif ; ce qui est d’autant plus
dommage que les entreprises ont généralement plus un profil d’organisation interne collant avec le type par
utilisateur que par périphérique/dispositif. Soyez donc vigilants lors de vos achats.
La CAL 2003 TSE par Utilisateur
Ce type de CAL est attribué à l’utilisateur des services de terminaux, c’estàdire que c’est le couple nom
d’utilisateur/mot de passe, ou plutôt l’identifiant unique correspondant, qui possède et utilise la licence.
Concrètement, l’utilisateur peut se connecter à un ou plusieurs serveurs TSE, à partir de n’importe quel poste de
travail, en utilisant une seule licence pour tous ces accès.
On perçoit de suite l’intérêt financier pour l’entreprise dont les utilisateurs sont plus ou moins mobiles et se
connectent de postes différents (au bureau, depuis la maison ou de chez les clients,…), ou possèdent plusieurs
postes (un fixe et un portable par exemple). C’est dans le doute, le choix de type de licences qu’il faudrait faire
par défaut.
La CAL 2003 TSE par périphérique/dispositif
Ce type de CAL est attribué au poste de travail à partir duquel un utilisateur quelconque se connecte au serveur
TSE.
Ce type de licences est intéressant pour les postes de travail qui sont utilisés par plusieurs personnes au fil du
temps, comme par exemple deux secrétaires à mitemps se partageant le même poste ou encore des postes en
atelier utilisés par des personnels travaillant en équipe. Il peut être également très intéressant pour tous les
postes de type libreservice, salles de formation, etc. Une salle de formation de vingt postes verra peutêtre
défiler des centaines d’utilisateurs par an, mais vingt CAL par périphérique/dispositif suffiront…
La CAL External Connector
Si l’entreprise souhaite mettre en œ uvre un serveur TSE afin que des clients, des partenaires ou même le public
accède à des applications hébergées chez elle, elle ne peut connaître de façon précise ni les postes ni les
utilisateurs qui accèderont à ce serveur.
La licence External Connector permet de ne pas avoir à choisir entre les deux types par utilisateur ou par
périphérique/dispositif, et offre un nombre illimité d’accès aux serveurs TSE.
Attention : cette licence est réservée pour des utilisateurs non salariés de l’entreprise. Pour reprendre
les termes exacts de l’éditeur : « Une personne «extérieure à l’entreprise» est tout utilisateur autre
qu’une personne employée par l’entreprise ou l’une de ses filiales en tant que salarié, prestataire
indépendant, agent, fournisseur de services ».
Les CAL gratuites
L’histoire de l’enchaînement des sorties des produits Windows 2000 Server TSE, des CAL TSE associées, puis de
Windows XP Professionnel, et enfin de Windows 2003 Server TSE et des nouvelles CAL TSE associées, a conduit
à une situation particulière qui incita Microsoft à considérer que dans certaines situations, les CAL 2003 TSE
avaient déjà été acquises par l’entreprise et n’avaient pas à être repayées.
C’est le cas des entreprises qui auraient acheté des licences du système d’exploitation Windows XP
Professionnel avant le 24 Avril 2003, date de sortie officielle de Windows 2003 Server : dans ce cas, chaque
licence Windows XP Pro achetée donne droit à une licence CAL 2003 TSE gratuite.
Si l’entreprise a passé un accord d’achat de licences de type Open avec Software Assurance, elle dispose aussi
de la mise à jour automatique de ses licences CAL 2000 TSE vers des CAL 2003 TSE.
Sinon, toute licence CAL 2000 TSE achetée pour un serveur Windows 2000 TSE est obsolète et doit être rachetée
pour pouvoir fonctionner avec un serveur Windows 2003 TSE.

La gestion des CAL 2003 TSE
La gestion des CAL 2003 TSE est prise en charge par un serveur de licences installé nécessairement sous
Windows 2003 Server :
Tout serveur sous Windows 2003 Server est activé auprès de Microsoft Clearinghouse (en général via une
connexion web automatique, mais cela peut être fait à la main ou par téléphone), ainsi que les licences CAL 2003
TSE qui doivent être installées puis activées pour être reconnues.
Elles sont alors gérées par le gestionnaire des licences Terminal Server ou TSLM en anglais.
Le service TSLM
Le gestionnaire des licences Terminal Server, ou TSLM en anglais, doit être installé sur un serveur Windows 2003
quelconque. Il est alors accessible via la console COMPOSANT LOGICIEL ENFICHABLE gestionnaire des licences
Terminal Server qui se trouve dans les outils d’administration du serveur.
Quelconque, c’estàdire qu’il peut être contrôleur de domaine Active Directory, mais ce n’est plus une
obligation, ce qui permet d’intégrer une solution TSE 2003 dans un système d’informations géré par un
annuaire Novell, Unix ou autre. Il n’est pas nécessaire non plus que le serveur de licences soit un serveur
TSE à part entière. Ce service est indépendant des versions standard, enterprise et datacenter de
Windows 2003 Server.
Toutefois une restriction existe, liée au périmètre de gestion du service TSLM défini lors de l’installation du
service (ajout/suppression de composants Windows) :
Si le périmètre choisi est Toute votre entreprise, vous ne pourrez installer un serveur de licences d’entreprise
que sur un contrôleur de domaine ou sur un serveur membre d’un domaine et non sur un serveur autonome car
ce rôle est publié vers Active Directory.
Si le périmètre choisi est Votre domaine ou groupe de travail, il n’est pas nécessaire que l’ordinateur sur lequel
vous installez le serveur de licences soit un contrôleur de domaine. Malgré tout, si vous voulez que le serveur de
licences soit automatiquement détecté par les serveurs Terminal Server qui communiquent avec lui, l’ordinateur
sur lequel vous l’installez doit être un contrôleur de domaine. Si l’ordinateur sur lequel vous prévoyez d’installer
le serveur de licences se trouve dans un groupe de travail, il sera détecté automatiquement, uniquement par les
serveurs Terminal Server situés sur le même sousréseau.
Le faible niveau de ressources consommées permet de placer le service TSLM sur un serveur remplissant d’autres
rôles sans soucis de performance. Pour fixer les idées, le service TSLM consomme moins de 10 Mo de RAM et la
taille de la base de données pour 5.000 CAL gérées n’excède pas 5 Mo. Cette base est par défaut stockée dans
le répertoire C:\WINDOWS\system32\lserver du serveur de licences.

Lors de l’installation du service TSLM, il va falloir choisir entre les deux périmètres de gestion proposés :
● Toute votre entreprise : dans ce cas, le service TSLM servira des licences CAL 2003 TSE à tout serveur
TSE situé dans le même site Active Directory que luimême, qu’ils appartiennent ou non à un même
domaine. Comme nous l’avons dit plus haut, il faut alors être contrôleur de domaine ou a minima
membre de l’un des domaines du site.
● Votre domaine ou groupe de travail : en ce cas, le service TSLM servira des licences CAL 2003 TSE
uniquement aux serveurs situés dans le même domaine ou dans le même sousréseau que le groupe de
travail.
Il faut ensuite l’activer par le biais de la console gestionnaire des licences Terminal Server : clic droit sur le
serveur et choisir Activer. La procédure automatique via le Web est pleinement fonctionnelle… si le serveur
dispose d’une connexion ! En cas de réactivation d’un même serveur de licences, il conviendra de se munir de
son contrat de licence Microsoft et de contacter le service téléphonique indiqué dans l’assistant.
Les serveurs TSE installés chercheront à se connecter automatiquement à un serveur de licences TSLM actif. Il
est possible qu’aucun serveur de licences ne soit trouvé ou au contraire qu’il y en ait plusieurs et que le serveur
TSE n’ait pas trouvé le bon (entendre celui qui convient à l’administrateur). Il peut donc être intéressant de
spécifier expressément le serveur de licences TSLM auquel le serveur TSE doit se référer.
Pour ce faire, et uniquement si vous disposez du Service Pack 1 de Windows 2003 Server, cliquez sur
Configuration des services Terminal Server dans Outils d’administration du serveur TSE, puis dans
l’arborescence de la console, cliquez sur Paramètres du serveur. Dans le volet d’informations, cliquez avec le
bouton droit sur Mode détection du serveur de licences, puis cliquez sur Propriétés. Cliquez sur Utiliser ces
serveurs de licences et tapez le nom et l’adresse IP des serveurs de licences dans la zone de texte, en les
séparant par des virgules. Cliquez sur Vérifier les noms, apportez toutes les corrections nécessaires et cliquez
sur OK.
Si vous ne disposez pas du Service Pack 1, il faut alors aller dans la base de registre du serveur TSE, et se
positionner sur la clé : HKLM\System\CurrentControlSet\Services\TermService\Parameters
Dans le menu Edition, choisissez Nouveau Clé, puis tapez LicenseServers pour nommer la nouvelle clé. Dans
cette nouvelle clé, dans le menu Edition, choisissez Nouveau Clé, et tapez le nom NetBIOS du serveur de
licences que vous voulez utiliser, puis appuyez sur [Entrée]. Le nom de la nouvelle clé peut aussi être l’une des
désignations suivantes qui représentent le serveur de licences :

● le nom NetBIOS du serveur ;
● le nom de domaine complet du serveur ;
● l’adresse IP du serveur.
Il faudra ensuite redémarrer votre serveur.
a. Gestion du type de CAL TSE
Comme nous l’avons vu plus haut, le gestionnaire de licences TSLM doit considérer deux types de licences CAL
2003 TSE : les licences par utilisateur et les licences par périphérique/dispositif. Il est possible de gérer les
deux types de licences sur un même serveur de licences, mais un serveur TSE ne prendra en charge qu’un seul
type de licences à la fois.
Sur le serveur de licences TSLM, il suffit d’ajouter autant de licences que nécessaire, qui peuvent être de type
différent, grâce à l’assistant du composant logiciel enfichable gestionnaire des licences Terminal Server. Elles
seront alors gérées comme décrit ciaprès.
Sur le serveur TSE, il faut spécifier quel type de licences doit être utilisé par le client pour pouvoir établir une
connexion. Par défaut, le type est par périphérique/dispositif. Pour le changer, il faut aller :
● Soit dans le composant logiciel enfichable configuration des services terminal server dans les Outils
d’administration, rubrique paramètres du serveur, et dans la partie droite, double cliquer sur licence
pour changer le mode.
● Soit si vous disposez du Service Pack 1 de Windows 2003 Server, aller dans la stratégie de groupe
local du serveur TSE, partie Configuration Ordinateur \ Modèles d’administration \ Composants
Windows \ Services Terminal Server, et sur le paramètre Définir le mode de concession de licences
Terminal Server pour activer le mode Par utilisateur.
Note importante : la stratégie de groupe remplace la configuration définie à l’aide de l’outil
Configuration des services Terminal Server.
Pour changer une stratégie pour un domaine ou une unité d’organisation, connectezvous au contrôleur de
domaine principal en tant qu’administrateur, puis ouvrez la Stratégie de groupe en utilisant le composant
logiciel enfichable Utilisateurs et ordinateurs Active Directory, ce qui vous permettra de spécifier quel
ensemble de postes dispose d’une licence par périphérique/dispositif et quelle population d’utilisateurs dispose
d’une licence par utilisateur.
b. Les périodes de fonctionnement global

Si le gestionnaire de licences Terminal Server TSLM n’est pas installé et activé, le serveur 2003 TSE sera tout de
même fonctionnel durant 120 jours après la première requête TSE émise par un client et répondra à toutes les
requêtes des clients suivants. Le 121 è m e jour, aucun client ne pourra se connecter sur ce serveur.
Si un client émet une requête sur un serveur TSE sans que ce dernier ne dispose de CAL 2003 TSE valide (c’est
àdire installée et activée), il est alors autorisé et utilise une licence CAL TSE temporaire d’une durée de vie de
90 jours. Le 91è m e jour, ce client spécifique ne pourra plus se connecter au serveur TSE.
Il est donc possible de faire fonctionner un serveur TSE au maximum 210 Jours sans disposer de CAL TSE
d’aucune sorte. Il faut pour cela être précis dans l’enchaînement des opérations : faire fonctionner le serveur
TSE sans avoir installé de serveur de licences TSLM durant 119 jours, le 120è m e jour, installer les serveurs de
licences TSLM et raccrocher le serveur TSE à ce dernier afin de commencer à utiliser les 90 jours de licences
temporaires. Si vous procédez tout d’un bloc lors de l’installation initiale, vous ne disposerez en fait que de la
période de 90 jours correspondant aux licences temporaires fournies par le serveur TSLM.
Nous attirons toutefois votre attention sur le fait que la période de 120 jours n’est pas une période de gratuité
et n’affranchit pas l’entreprise de payer ses licences CAL 2003 TSE. C’est une période technique octroyée pour
faciliter la mise en œ uvre technique d’architectures complexes ou longues à déployer.
Durant les 15 jours précédant l’expiration de la licence CAL TSE temporaire fournie à l’utilisateur et si la gestion
de licences CAL TSE n’a pas été correctement mise en place, un message d’avertissement s’affiche sur la
session de l’utilisateur à chaque nouvelle ouverture de session. Il est possible de réduire ce délai (attention de
ne pas le passer à 0, vous n’auriez plus l’information et de sérieux dysfonctionnements pourraient survenir) en
allant dans la base de registre, dans la section HKLM, sur la clé LicensingGracePeriodExpirationWarningDays.
Comme nous allons le voir, ces périodes ont des influences directes sur le mécanisme de fonctionnement au
quotidien du système de licences.
c. Gestion des CAL 2003 TSE par Utilisateur
Voici donc un mode de gestion qui a le mérite d’être simple et efficace : il est inexistant ! En effet, le
gestionnaire de licence ne sait pas « gérer » ce type de CAL et ne les contrôle donc pas.
Il est important de ne pas se laisser perturber par la phrase « … n’est actuellement pas gérée. », ci

dessous.
Ceci explique la phrase ésotérique « L’allocation de licences par utilisateurs n’est actuellement pas gérée. » qui

s’affiche lorsque l’on veut spécifier le mode de gestion des licences d’un serveur TSE dans le composant logiciel
enfichable « Configuration des services Terminal Server ».
L’explication est historique : Microsoft voulait mettre en place, avec Windows 2003, un système de gestion de
licences CAL TSE par processeur mais devant la levée de bouclier des entreprises clientes, décida au dernier
moment de mettre en place la gestion des CAL TSE par utilisateur (ce qui est nettement plus pratique). Mais
n’ayant plus le temps matériel de développer ladite gestion et ne souhaitant pas pour cela retarder la date de
sortie de son produit serveur, il n’y eut finalement de ce mode de gestion que le nom et la possibilité de
basculer vers un mode… non géré !
En clair, si l’entreprise se porte acquéreur de licences CAL 2003 TSE par utilisateur, les installe et les active sur
un serveur de licences TSLM, auquel est correctement raccroché un serveur TSE en mode de gestion de licences
par utilisateur : tout fonctionne et rien n’est géré/contrôlé par le service TSLM !
Attention : qui dit "rien n’est géré" ne veut surtout pas dire "rien ne doit être acheté". L’entreprise doit se
porter acquéreur du nombre de licences correspondant au nombre d’utilisateurs de la solution TSE, selon les
termes des accords de licence Microsoft.
Mais du point de vue de l’administrateur, c’est autant de tracas en moins.
d. Gestion des CAL 2003 TSE par périphérique/dispositif

Le mécanisme de gestion des CAL 2003 TSE par périphérique/dispositif est globalement assez ingénieux, mais
particulièrement complexe et nécessite une mise en œ uvre préalable des services TSLM et des serveurs TSE
raccrochés assez rigoureuse. Si ce n’est pas le cas, le fameux message d’avertissement d’expiration de licences
apparaissant 15 jours avant la date fatidique devra éveiller l’attention de l’administrateur quant à un problème
de configuration de l’ensemble du système de gestion des licences CAL TSE.
Le principe de fonctionnement des CAL 2003 TSE par périphérique/dispositif est le suivant.
Les CAL sont installées et activées sur un serveur de licences TSLM luimême activé. Un serveur TSE est déclaré
fonctionnant avec des licences CAL TSE en mode par périphérique et pointe correctement vers le serveur de
licences TSLM.
Un client établit une requête RDP vers le serveur TSE. Ce dernier étant en mode par périphérique, il vérifie si le
client possède bien une telle licence CAL TSE.
Si le client n’en a pas, le serveur TSE se connecte sur le serveur de licences TSLM pour en obtenir une (ou
successivement sur tous les serveurs de licences TSLM déclarés dans le serveur TSE jusqu’à ce qu’un serveur
TSLM puisse en délivrer une). Si le serveur TSE ne trouve aucun serveur de licences TSLM disponible pour lui
répondre, alors le poste client ne pourra pas ouvrir de session TSE, sauf si le serveur a été installé depuis
moins de 120 jours (cf. paragraphe cidessus Les périodes de fonctionnement global).
Dans tous les cas, le serveur TSLM fournit au serveur TSE, une licence CAL 2003 TSE temporaire de 90 jours,
qu’il transmet au client, poursuivant alors son processus de connexion.
Si le client s’authentifie correctement (nom d’utilisateur et mot de passe), le serveur TSE contacte à nouveau le
serveur TSLM pour lui signifier la validité de la requête de connexion. Le serveur TSLM marque alors dans sa
base de données que la licence fournie est valide.
Lors de la prochaine demande de connexion, le client présentera au serveur TSE sa licence temporaire, lequel
serveur contactera le serveur TSLM. Si, sur le serveur TSLM, cette licence est marquée comme valide, alors le
serveur TSLM la transformera en licence permanente, le renverra au serveur TSE qui la fournira au client afin
qu’il puisse désormais l’utiliser. Si la licence n’est pas marquée comme valide, alors le client pourra se connecter
quand même, mais toujours avec sa licence temporaire 90 jours, et à chaque nouvelle demande de connexion,
la même vérification pour tentative de transformation en licence permanente sera effectuée. Si 15 jours avant
la fin du délai des 90 jours, la licence du client n’a toujours pas été transformée, alors, le message
d’avertissement apparaîtra sur le poste client à chaque nouvelle ouverture de session.
Ce mécanisme à double détente est particulièrement adapté à la réalité de l’entreprise. Il est apparu avec le
Service Pack 3 de Windows 2000 Server et permet d’attendre que l’utilisateur soit réellement authentifié sur le
domaine pour lui attribuer une licence CAL TSE par périphérique/dispositif permanente. Auparavant, la licence
était attribué immédiatement, et donc à chaque requête involontaire d’un poste client nouveau sur un serveur
TSE en écoute (erreurs de manipulation ou dans le choix du serveur à adresser, tests pour voir si le serveur
TSE réponds, etc.), une licence CAL TSE était inutilement consommée, laquelle manquait tôt ou tard à un autre
poste qui, lui, en avait besoin. Ce dysfonctionnement est désormais résolu.
La licence CAL 2003 TSE par périphérique/dispositif est donc stockée sur le poste client afin d’être présentée
par ce dernier à chaque demande de connexion à quelque serveur TSE que ce soit : c’est l’intérêt même de la
licence par périphérique/dispositif. Elle peut être assimilée à un certificat, puisqu’elle n’aura plus à être fournie
par le serveur de licences TSLM. En effet, ce dernier aura dû au préalable contacter le serveur Microsoft
Clearinghouse, qui fait autorité de certification, pour activer le nombre de licences (ou certificats donc) CAL 2003
TSE achetées par l’entreprise.
Sur les postes clients basés sur un système d’exploitation Windows 32 bits, ce certificat de licence est stocké
directement dans la base de registre, dans
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE00x, où le x de 00x est
remplacé par un chiffre (il peut y avoir plusieurs licences installées sur un même poste). Il est donc possible de
supprimer cette licence en supprimant cette clé, ce qui peut être utile par exemple si l’on constate qu’un poste
utilise une licence CAL 2003 TSE par périphérique/dispositif alors que l’on préfèrerait que ce poste se réfère à
des serveurs TSE en mode par utilisateur.
Stockée sur le poste client sousentend que le serveur de licences TSLM ne dispose plus de cette licence dans
sa base de données. Or le poste client peut être amené à être réinstallé, réinitialisé ou changé car en panne.
En pareil cas, la licence CAL TSE stockée sur le poste est perdue : le serveur de licences TSLM ne la connaît plus

et le nouveau poste (ou le même réinstallé) n’en dispose plus non plus. Le processus décrit plus haut
fonctionne toujours, mais va aboutir à fournir une deuxième licence CAL TSE pour finalement un même poste. Et
cela peut se reproduire n fois, conduisant à un manque inéluctable de licences…
Cet écueil a été contourné dès Windows 2000 Service Pack 3 par la mise en place des licences CAL TSE
permanentes temporaires, historisées aussi sur le serveur de licences TSLM.
Vous avez bien lu : les licences CAL TSE permanentes, et donc particulièrement les CAL 2003 TSE, se voient
désormais attribuer une date d’expiration aléatoire oscillant entre 52 et 89 jours et le serveur de licences TSLM
en conserve la trace, ainsi que le poste client à qui cette licence est transmise.
Le mécanisme de connexion est alors le suivant :
● Quand le poste client se connecte au serveur TSE, il présente sa licence CAL 2003 TSE par
périphérique/dispositif. Elle est vérifiée par le serveur de licences TSLM, tant en terme de validité qu’en
terme de date. Si la date d’expiration est supérieure de 7 jours, alors tout est validé et le client se
connecte normalement ; sinon (on est à 7 jours maximum de la date d’expiration), le serveur de
licences TSLM renouvelle la période de cette licence pour une valeur aléatoire comprise entre 52 et 89
jours, avant de laisser poursuivre la connexion.
● Quand une licence CAL 2003 TSE par périphérique/dispositif arrive à sa date d’expiration, c’est que le
poste client ne s’est pas connecté à un quelconque serveur TSE dans les 7 derniers jours (soit qu’il
n’existe plus, soit qu’aucun utilisateur n’a utilisé le client RDP depuis ce poste). Elle est alors rendue au
pool de licences disponibles dans la base de données du serveur TSLM. Donc si le poste n’existe
réellement plus (ou a été réinstallé), le nouveau poste obtiendra une nouvelle licence (car il y en a au
moins une de disponible : celle que l’on vient de rendre). Si le même poste client cherche à se
reconnecter (au retour de vacances de l’utilisateur par exemple), il obtiendra aussi une nouvelle
licence.
Comme le serveur de licences TSLM stocke désormais des informations sur les dates d’expiration des licences
CAL 2003 TSE par périphérique/dispositif, il n’est pas possible qu’un client renouvelle une licence temporaire 90
jours (même s’il la supprime de sa base de registre locale).
Il faut prendre en considération qu’une licence CAL 2003 TSE par périphérique/dispositif permanente ne peut
pas être remplacée au terme de son expiration par une licence temporaire 90 jours ; ce qui signifie que si, à
l’expiration de la période 5289 jours, le serveur TSE ne peut pas obtenir le renouvellement de la période pour
la licence qui lui est présentée, le poste client ne pourra pas se connecter.
Comment cela pourraitil arriver ? Il suffit qu’une coupure réseau ou une indisponibilité quelconque empêche le
serveur TSE et le serveur de licences TSLM de communiquer ensemble ; ou alors, c’est que l’entreprise n’a pas
acheté le nombre adéquat de licences CAL 2003 TSE… Car si c’était le cas, la situation de blocage (hors
coupure/panne) ne pourrait pas arriver.
Une solution est d’installer et d’activer un serveur de licences TSLM supplémentaire, si possible à proximité
relativement immédiate du ou des serveurs TSE, sans pour autant acquérir, installer et activer de licences CAL
2003 TSE par périphérique/dispositif dessus. En effet, si le serveur TSLM principal ne fonctionne plus pour
quelque raison que ce soit, le serveur TSE contactera le serveur TSLM secondaire qui, ne disposant pas de
licences permanentes à attribuer, fournira des licences temporaires 90 jours aux postes clients, ce qui
permettra la poursuite des connexions, et laissera 89 jours pour remettre en œ uvre le serveur TSLM
« principal ». Le rôle TSLM secondaire étant uniquement un rôle de secours, il ne sert à rien de dédier un
serveur à cela : il est conseillé de positionner le rôle sur un serveur existant, du moment qu’il fonctionne sous
Windows 2003 Server.
Si l’intégration du système de licences est correcte (et que l’entreprise dispose du nombre adéquat de
licences), il n’y a pas de dysfonctionnement. La finesse du mécanisme tient dans le fait que les licences
temporaires durent 90 jours, et les licences permanentes au maximum 89 jours, soit un jour de moins…
Imaginons une entreprise ayant 100 postes clients connectés à un serveur TSE et ayant correctement installé
les 100 CAL 2003 TSE par périphérique/dispositif achetées. Un des postes dispose d’une licence permanente
d’une durée de 89 jours (le maximum du fait du random). Il tombe en panne et est complètement réinstallé,
donc perd sa licence permanente. Lorsqu’il se reconnecte, il est vu par le serveur TSLM comme étant un poste
nouveau, donc sans licence, et comme le serveur TSLM ne dispose plus de licences permanentes libres, il lui
attribue une licence temporaire 90 jours. 89 jours plus tard, la licence permanente est rendue au pool de

licences du serveur TSLM. Le 90è m e jour, le poste client contacte le serveur TSLM car sa licence temporaire a
expiré, lequel lui fournit la seule licence permanente à sa disposition, à savoir celle que le poste avait avant. Le
seul désagrément de l’histoire est que l’utilisateur sera, par défaut, notifié de l’expiration de sa licence
temporaire 15 jours avant la date butoir, alors que tout s’enchaînera logiquement et correctement le jour de
l’expiration.
En conclusion, on peut simplement affirmer qu’il convient d’être rigoureux dans sa gestion de parc et de bien
évaluer le contexte de fonctionnement de son projet TSE pour mettre en œ uvre le système de gestion de
licences CAL TSE le plus adapté/correct qui soit.
2. Mise en œuvre dans le système d’information
L’intérêt est de mettre en œ uvre le système de gestion de licences tant correctement, afin de garantir le bon
fonctionnement de l’architecture TSE au quotidien, qu’astucieusement afin de réduire au maximum le nombre de
licences CAL 2003 TSE à acquérir.
Positionnement des serveurs de licences TSLM
Le positionnement correct des serveurs de licences TSLM est important pour assurer le bon fonctionnement des
serveurs TSE euxmêmes. En effet, si un serveur TSE ne peut pas contacter de serveur TSLM (et audelà de la
période initiale de 120 jours, c’estàdire dès lors que son infrastructure TSE est passée en production), même
temporairement, la connexion sera refusée au poste client.
Voici donc plusieurs exemples d’intégration de serveurs de licences TSLM.
Le premier exemple est le plus simple, mais présente divers écueils :
● Il n’y a qu’un seul serveur de licences TSLM sur le site central 1. Si ce dernier tombe en panne, il n’y a
plus de connexion RDP possible.
● Le site distant 2 ne dispose pas de serveur de licences TSLM local : la communication entre le serveur
TSE local et le serveur TSLM distant transite par le lien WAN, lequel peut être soit coupé, soit saturé,
interdisant alors la connexion des clients RDP du seul site 2 sur leur serveur TSE local.

La solution suivante permet d’améliorer certains écueils :
Le serveur TSLM du site 2 ne dispose pas de CAL 2003 TSE installées et ne diffusera que des licences
temporaires en cas de besoin. Il faut par contre bien veiller à déclarer ce serveur comme deuxième serveur de
licences TSLM sur le serveur TSE du site 2, afin que les postes clients du site 2 aillent bien chercher une licence
permanente sur le serveur TSLM du site 1.
Le schéma idéal pourrait être le suivant :
Le serveur de licences TSLM supplémentaire du site 1 serait alors déclaré en tant que second serveur de licences
dans le serveur TSE du site 1.

Il est certain que l’on pourrait se contenter de déclarer le serveur TSLM du site 2 comme second serveur de
licences dans le serveur TSE du site 1, ainsi que le montre le schéma suivant, mais l’on serait alors encore
dépendant du lien WAN (même s’il est vrai qu’il faudrait un vrai gros problème pour qu’à la fois le serveur TSLM
du site 1 et le lien WAN soient en panne) :
Attention : tous ces schémas ne sont que des exemples. Il faut aussi tenir compte de la présence ou
non de l’éventuelle architecture associée Active Directory, ainsi que du périmètre de gestion choisi pour
TSLM lors de son installation (Toute votre entreprise ou Votre Domaine ou Workgroup), pour déterminer
l’architecture du système de gestion de licences TSLM la plus adaptée, particulièrement si vous êtes en
présence de multiples domaines ou de sites Active Directory imbriqués.
Comme nous l’avons dit dans les paragraphes précédents, le principal écueil de l’architecture TSE est qu’en
général et avec des choix par défaut, elle a la mauvaise habitude de se mettre à fonctionner et de ne présenter
ses travers que beaucoup plus tard, du genre 90 ou 120 jours plus tard pour le sujet qui nous anime en ces
lignes…
Arbitrage entre les types de licences CAL 2003 TSE
Nous écarterons de ce paragraphe la licence External Connector et étudierons seulement les finesses du choix
entre les CAL 2003 TSE par périphérique/dispositif et par utilisateur.
Imaginons une entreprise, somme toute assez classique, éparpillée sur de nombreux sites distants et dont le
profil de travail des salariés, en corrélation ou non avec les sites distants d’ailleurs, fait ressortir au moins deux
populations distinctes : celle qui dispose d’un poste de travail informatique dédié (500 utilisateurs à
l’administration, au commerce, etc.), et celle qui se partage un poste de travail à plusieurs (1 000 ouvriers sur
des chaînes de production se partageant 200 postes).
Il convient alors d’acheter 500 CAL 2003 TSE par utilisateur pour la première des populations, mais plutôt 200
CAL 2003 TSE par périphérique/dispositif pour la seconde qui se partage le même poste.
Vous avancerez en acquérant que des CAL 2003 TSE par utilisateur, étant donné que la gestion par le biais du
serveur de licences TSLM n’est pas assurée, c’est globalement plus simple. Oui, mais globalement beaucoup plus
coûteux (1 000 ouvriers se partageant 200 postes de travail, c’est 800 licences à plus ou moins 100 euros
inutiles, soit 80 000 euros inutilement dépensés...).

Il faut se souvenir qu’un serveur TSE ne peut considérer qu’un seul type de licences à la fois, et qu’un serveur
TSLM peut lui gérer différents types de licences. Ce qui veut dire que pour gérer pour la population 1 des licences
CAL 2003 TSE par utilisateur, et pour la population 2 des licences par périphérique/dispositif, il faut mettre en
œ uvre deux serveurs (ou deux fermes de serveurs équilibrés) distinct(e)s. Ceci n’est souvent pas rédhibitoire car
les profils applicatifs des deux populations n’ont souvent pas grand chose de comparable, et nécessitent par
euxmêmes la mise en place de serveurs distincts.
Étudions un premier cas où les deux populations sont segmentées sur deux sites…
Le serveur TSE « PROD » du site 2 est alors paramétré pour accepter des licences par périphérique/dispositif qu’il

obtient de la part du serveur TSLM principal du site 1 dans le pool des 200 disponibles. Le serveur TSE « ADM »
du site 1 est, lui, paramétré pour accepter des licences par utilisateur qu’il obtient dans le pool des 500
disponibles.
Tout fonctionne et va pour le mieux, mais les entreprises ressemblent généralement plus à cela :

Dans ce cas, la population d’ouvriers du site 1 doit se connecter sur le serveur TSE « PROD » du site 2, et la
population d’administratifs du site 2 doit se connecter sur le serveur « ADM » du site 1, donc dépendre
réciproquement du lien WAN.
La première alternative est de doubler les serveurs afin que chaque site dispose d’un serveur PROD et d’un
serveur ADM. Il est souvent plus simple ou moins coûteux de prévoir un lien WAN de secours, et de s’orienter
vers la centralisation des deux serveurs sur un seul et même site.
On arrive alors au schéma suivant :
Une fonctionnalité de Windows 2003 Server permet de spécifier des autorisations d’accès au serveur de licences
TSLM, ce qui permet concrètement de spécifier quel serveur TSE a le droit de négocier des licences avec le
serveur de licences TSLM, et donc pourquoi pas de segmenter le serveur de licences TSLM en deux : un pour la
gestion des licences CAL 2003 TSE en mode par périphérique/dispositif, l’autre pour la gestion de celles en mode
par utilisateur.
Cette fonctionnalité est à activer par l’intermédiaire d’une stratégie appliquée au serveur qui héberge le serveur
de licences TSLM. Il faut, pour cela, aller dans l’éditeur de stratégies de groupe de l’ordinateur local, précisément
dans Configuration ordinateur / Modèles d’administration / Composants Windows / Services Terminal
Server / Licence et activer le paramètre Groupe de sécurité du serveur de licences.
Un groupe local de sécurité appelé Ordinateurs Terminal Server est alors créé sur le serveur de licences TSLM,
lequel répondra exclusivement aux requêtes émanant des serveurs TSE (ou groupes de serveurs TSE) qui
appartiennent à ce groupe. Attention : le groupe Ordinateurs Terminal Server est vide par défaut. Le serveur
de licences Terminal Server n’accorde de licence à aucun ordinateur tant que vous n’avez pas rempli ce groupe
de façon explicite.
Si le serveur de licences TSLM est aussi un contrôleur de domaine Active Directory, alors le groupe créé est un
groupe de sécurité de domaine local dans l’Active Directory.
Approche TSE de la gestion des licences applicatives
Comme nous l’avons déjà annoncé, l’installation d’une application dans un environnement TSE ne modifie pas
son mode de licence.
Les applications courantes peuvent être rangées en trois principales familles de gestion de licences (il peut y
avoir d’autres modes de licence spécifiques, dans ce cas, il convient de se rapprocher de l’éditeur de ces
applications, pour en connaître le fonctionnement) :

● Les applications par utilisateur simultané ou concurrent : il faut une licence de l’application à chaque fois
que l’application est exécutée, par quelque utilisateur que ce soit. En clair, sur 100 utilisateurs, si
seulement 12 exécutent simultanément l’application concernée, il faut payer 12 licences de l’application.
● Les applications par utilisateur potentiel ou déclaré : il faut une licence de l’application pour chaque
utilisateur qui peut être amené à exécuter l’application. En clair, sur 100 utilisateurs, si seulement 12
exécutent simultanément l’application concernée, il faut tout de même payer 100 licences de
l’application.
● Les licences par processeur : le nombre de licences à payer dépend directement du nombre de
processeurs présents dans le serveur hôte. C’est le cas notamment de certains SGBD.
L’architecture TSE étant une architecture centralisée du point de vue du rassemblement des utilisateurs sur un
même serveur (ou une même ferme de serveurs) et surtout du rassemblement de leurs applications, il est
fréquent de générer un problème dans la gestion des licences : en effet et par défaut, tous les utilisateurs
peuvent techniquement utiliser toutes les applications installées sur le serveur TSE, sans nécessairement
respecter les accords de licences passés entre l’entreprise et les divers éditeurs applicatifs.
Il convient à l’administrateur de concevoir une architecture TSE qui respecte ces accords de licences. Plusieurs
possibilités s’offrent alors à lui.
En combinaison de ces diverses possibilités, il est même possible de contrôler et du même coup de gérer
facilement les usages applicatifs de l’entreprise.
Pour les exemples suivants, nous considérons une entreprise de 100 utilisateurs connectés sur 1 serveur TSE,
dont 40 peuvent potentiellement accéder à une certaine application, mais seulement 12 y accèdent en simultané.
Si cette application est gérée en mode utilisateur potentiel (la plupart des applications du marché, notamment les
applications Microsoft), il faudrait donc 40 licences, mais comme nous sommes sur un serveur TSE, les 100
utilisateurs peuvent y accéder, et il faut donc payer 100 licences. Pour restreindre l’usage de cette application
aux 40 utilisateurs concernés, il est possible d’agir de plusieurs manières :
● Positionner des droits NTFS sur l’exécutable de l’application. Procédure un peu lourde s’il y a beaucoup

d’utilisateurs et une grande diversité d’applications, surtout dans la gestion quotidienne ultérieure, elle
a toutefois l’avantage d’être simple et rapide. Elle peut être améliorée par la création de groupes
d’utilisateurs correspondants à chaque application concernée.
● Si l’on est face à un seul serveur TSE monoapplicatif, il sera plus simple de rendre le groupe
d’utilisateurs membre du groupe Utilisateurs du bureau à distance.
Si cette application est gérée en mode simultané ou concurrent, il faut payer 12 licences, mais il faut interdire
l’exécution de l’application pour un 13è m e utilisateur en procédant au choix comme suit :
● Limiter à 12 le nombre de connexions RDPTCP sur le serveur TSE au niveau protocolaire (dans les
propriétés de RDP, dans la console Configuration des Services Terminal Server). Il sera alors
impossible au serveur TSE de répondre à une 13 è m e requête RDP, de quelque utilisateur ou provenance
que ce soit ; ce qui sousentend que le serveur TSE est dédié à cette application…
● Acquérir la suite Citrix/ICA ou solution de présentation et distribution d’applications équivalente…
Si les utilisateurs doivent utiliser un ensemble d’applications en mode potentiel et une en mode concurrent, il faut
alors installer deux serveurs TSE : un frontal qui diffusera les applications en mode potentiel, et un dédié qui
diffusera l’application en mode concurrent.
Afin que les utilisateurs ne soient pas obligés de se connecter aux deux serveurs séparément, il conviendra
d’encapsuler le serveur dédié dans (ou plutôt derrière) le serveur TSE nommé alors serveur frontal :

S’il y a plusieurs applications en mode concurrent au sein de l’entreprise, la première possibilité est de dédier
autant de serveurs que d’applications (ce qui parfois est exigé du fait de l’éditeur luimême et des contrats de
support associés à l’application).
Il est aussi possible de faire cohabiter plusieurs applications en mode concurrent sur un même serveur en
déclarant plusieurs ports de connexion RDPTCP (dans la console Configuration des Services Terminal Server,
et uniquement si vous avez autant de cartes réseau dans le serveur que vous aurez de ports de connexion à
créer, donc autant qu’il y a d’applications hébergées en mode concurrent), chacun paramétré pour ne diffuser
qu’une monoapplication, et chacun limité en nombre de connexions simultanées en fonction de l’application
monodiffusée :

3. Gestionnaire de licences RDS 2008 R2
L’objectif du gestionnaire de licences RDS, nommé pour l’occasion Remote Desktop Licensing Manager (RDLM),
est de simplifier la gestion des licences des services Bureau à distance (RDS CAL : Remote Desktop Services Client
Access Licence). En d’autres termes, il doit aider le client et donc l’administrateur à mieux gérer ses licences en
s’assurant qu’il n’en n’achète pas plus que nécessaire (ou plutôt qu’il en achète suffisamment…). Le gestionnaire
permet en outre de visualiser les clients ne disposant pas de licences, disposant de licences temporaires ou enfin
d’une licence valide. Le gestionnaire de licences 2008 R2 permet de gérer les licences d’accès par périphérique
ou par utilisateur, et ce, pour Windows 2008 R2, Windows 2008 et Windows 2003.
Fonctionnement des licences par périphérique
Quand un client souhaite se connecter à un serveur RDS, le serveur commence par déterminer si le client
nécessite une licence. Si tel est le cas, il contacte un serveur ayant un service de licences valides (si le service
n’est pas activé, seules des licences temporaires seront délivrées) afin de solliciter un jeton d’accès qu’il
transmet alors au client (le serveur de licences conservant la trace de la licence émise).
Fonctionnement des licences par utilisateur
Ce type de licences, bien qu’étant disponible, n’était pas géré jusqu’à présent par le service de licences Windows
2003 (aucun contrôle du nombre de licences distribuées dans ce mode).
Une des nouveautés proposées par Windows 2008 R2 est précisément de combler cette lacune. En effet, le
nouveau service de licences s’appuie désormais sur l’Active Directory pour assurer le suivi des licences délivrées.
Révocation des licences clients
Jusqu’à présent lorsqu’une licence par périphérique était distribuée à un poste client, et que celuici tombait en
panne ou devait être réinstallé, il n’existait aucun moyen de remettre la licence vacante dans le pool de licences
disponibles ce qui était fort ennuyeux quand on n’en disposait pas d’avance. En fait, pour être parfaitement
exact, la licence était automatiquement remise dans le pool des licences disponibles si tant est que l’on avait la
patience d’attendre entre 52 et 89 jours...
La nouvelle console de gestion permettra aux administrateurs de sélectionner un certain nombre de licences
Windows 2008 R2 par périphérique et de les révoquer (remettre dans le pool de licences disponibles).
Toutefois, Microsoft, qui est d’un naturel méfiant, a posé un certain nombre de restrictions sur cette fonctionnalité
de révocation. Le principe est qu’il ne sera pas possible d’avoir plus de 20 % du total de ses licences dans un
état Révoqué.
Afin de bien comprendre le principe un petit exemple s’impose :
Si je dispose de 100 licences, il sera possible d’en révoquer 20. Ces 20 licences seront taguées comme
«révoquées » et le resteront jusqu’à la date normale de leur expiration (durée aléatoire, allant de 52 à 89 jours,
définie lors de sa distribution au client). Au terme de ce délai normal d’expiration, le tag sera automatiquement
réinitialisé.
Outil de diagnostic
Avant Windows 2008 et 2008 R2, diagnostiquer un problème de communication, entre un serveur TSE et son
serveur de licences, tenait un peu du parcours du combattant.
La console de configuration des services Bureau à distance dispose maintenant d’un outil intégré qui permettra
de visualiser et de diagnostiquer les éventuels problèmes de connexion avec le serveur de licences, en générant
notamment des rapports sur l’utilisation des licences.

Une fois le rapport généré, il est intéressant d’enregistrer celuici au format .csv, devenant ainsi lisible avec un
simple blocnotes :
Il devient alors aisé pour l’administrateur de connaître la consommation de ses licences à l’instant T.

RemoteFX
1. Introduction
Avant de détailler les apports de RemoteFX, revenons quelques instants sur les limites actuelles du protocole RDP
pour les applications usuelles. Le tableau cidessous présente la satisfaction utilisateur constatée, par type
d’application, et fonction du réseau utilisé.
Type Rendu RDP 7.0

d’application
LAN WAN
GDI Côté client
WPF Côté serveur
Silverlight Côté serveur
Flash Côté serveur
WMV Côté client (RDP 7.0)
Côté serveur (<RDP
7.0)
Quicktime Côté serveur
DirectX Côté serveur (avec
carte 3D)
OpenGL SW Côté serveur
OpenGL HW Côté serveur (avec
carte 3D)
Ressenti des utilisateurs par type d’application

a. Qu’estce que RemoteFX ?
RemoteFX est une technologie acquise lors du rachat de la société Calista, dont l’objectif principal est d’améliorer
ce que l’on appelle « l’expérience utilisateurs ».
Dans le cas de postes de travail distants ou virtualisés, cette expérience repose essentiellement sur des
technologies permettant l’affichage à distance, la prise en compte des périphériques locaux (imprimantes, caméra
USB etc.) et la capacité à transmettre et synchroniser les flux audio et vidéo de manière bidirectionnelle. Pour ce
faire, RemoteFX fourni aux postes de travail virtualisés, une carte virtuelle 3D, des codecs « intelligents » et la
possibilité de rediriger tous types de périphériques USB.
b. Qui est concerné par cette fonctionnalité ?
Les utilisateurs qui travaillent ou utilisent :
● Des applications Silverlight et Flash
● Des applications 3D de DirectX
● Des périphériques USB dans une machine virtuelle
● Des applications Microsoft Office
● Des applications Media player
● Des applications hébergées sur Internet
● Des applications métier
À ces utilisateurs il faut ajouter les administrateurs système qui ont, ou souhaitent, implémenter une
infrastructure VDI sous HyperV, ainsi que les administrateurs RDS.
c. RemoteFX dans RDP
Schéma de principe
Un nouveau canal virtuel a été ajouté au protocole RDP 7.1 afin de traiter le trafic RemoteFX.

Composants mis en œuvre côté client
La pile logiciel du client RDC 7.1 comporte maintenant un décodeur RemoteFX (logiciel ou matériel) permettant de
décompresser les flux.
Composants mis en œuvre côté serveur
Le noyau côté serveur comprend désormais une librairie d’encodage des flux utilisant soit le processeur soit un
dispositif matériel spécialisé.
d. Quelles fonctionnalités RemoteFX fournitil ?

Rendu du côté hôte
Le rendu côté hôte autorise les graphiques à être restitués sur le serveur au lieu de l’être sur le client en
transmettant des images bitmap compressées. Par ailleurs, cela permet également aux applications de bénéficier
du GPU et du CPU du serveur hôte.
Virtualisation du GPU
La virtualisation du GPU est une technologie qui permet de mettre à disposition des machines virtuelles un
périphérique graphique 3D. Plusieurs bureaux virtuels peuvent se partager le ou les GPU présent(s) sur le
serveur HyperV.
Capture d’écran intelligent
Ce dispositif est responsable de :
● Vérifier les modifications opérées à l’écran et d’envoyer au codage uniquement les bits modifiés.
● Analyser le réseau disponible entre le client et l’hôte et ajuster la quantité de données à transmettre
pour éviter de saturer la connexion. Toutefois, pour permettre un rendu optimal, la bande passante
disponible doit être élevée.
Encodeur RemoteFX
L’encodage RemoteFX peut être réalisé par le processeur, le GPU ou un matériel dédié. Une fois les données
d’écran compressées, elles sont envoyées au bureau virtuel qui les transfère au travers du client RDC.
Dans les machines où les processeurs sont fortement sollicités, l’usage d’un matériel dédié garantit que
l’expérience utilisateur ne soit pas affectée par la charge.
Décodeur RemoteFX
Le décodeur RemoteFX décode les bitmaps transmis par le bureau virtuel à l’ordinateur client. Le décodage peut
être réalisé par le CPU, le GPU ou encore à l’aide d’un décodeur matériel.
Redirection USB RemoteFX
La redirection USB RemoteFX permet à de nombreux périphériques USB d’être redirigés vers un bureau virtuel
sans nécessiter l’ajout de pilotes supplémentaires sur le client.
e. Quels paramètres ont été ajoutés ou modifiés ?
Deux services supplémentaires ont été ajoutés afin de contrôler l’exécution de RemoteFX :
● un gestionnaire de session RemoteFX qui fournit les services de démarrage pour RemoteFX.
● un gestionnaire de licences RemoteFX qui émet et valide les licences.
Les paramètres de stratégie de groupe suivants permettent de configurer RemoteFX au sein de votre
environnement :
Nom Localisation
Configurer RemoteFX Configuration ordinateur\Modèles
d’administration\Composants Windows\Services
Bureau à distance\Hôte de la session Bureau à
distance\Environnement de session à distance
Optimiser l’expérience visuelle pour les sessions Configuration ordinateur\Modèles
de service bureau à distance d’administration\Composants Windows\Services
Bureau à distance\Hôte de la session Bureau à

distance\Environnement de session à distance
Autoriser la redirection de protocole RDP des Configuration ordinateur\Modèles
autres périphériques USB RemoteFX pris en d’administration\Composants Windows\Services
charge à partir de cet ordinateur Bureau à distance\Client Connexion bureau à
distance\Redirection de périphérique USB
RemoteFX
f. Éditions supportant RemoteFX ?
RemoteFX est disponible dans les éditions suivantes de Windows Server 2008 R2 SP1 :
● Windows Server 2008 R2 Standard
● Windows Server 2008 R2, Enterprise
● Windows Server 2008 R2 Datacenter
● Microsoft HyperV Server 2008 R2
RemoteFX est disponible dans les éditions suivantes de Windows 7 avec Service Pack 1 :
● Windows 7 entreprise
● Windows 7 Édition intégrale
RemoteFX n’est utilisable que depuis un client bureau à distance utilisant le protocole RDP 7.1.
g. Comparaison des fonctionnalités disponibles en mode RDVH/VDI et RDSH
En mode Hôte de virtualisation des services bureau à distance (RDVH, Remote Desktop Virtualization Host) :
● Carte graphique 3D virtuelle
● Codec intelligents
● Redirection USB RemoteFX
En mode Hôte de session bureau à distance (RDSH, Remote Desktop Session Host) :
● Optimisation de la bande passante réseau lors de l’utilisation d’applications graphiques enrichies
2. Installation de RemoteFX sur un serveur RDSH
a. Prérequis
Pour installer RemoteFX, les éléments suivants sont nécessaires :
● Le processeur doit intégrer le jeu d’instruction SSE2
● Optionnel : ASIC RemoteFX
● Le client peut être de type « riche » (PC), fin, ou ultafin supportant RDP7.1
● Une liaison haut débit (LAN) est conseillée entre le client et le serveur RDS

b. Configuration
L’ensemble des paramètres cidessous peuvent être distribués par une GPO (conseillé). Ces
paramètres sont situés sous « Configuration ordinateur\Modèles d’administration\Composants
Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Environnement de session
à distance ».
Nombre maximal de couleurs
Lancez la mmc « Configuration d’hôte de session Bureau à distance » (tsconfig.msc) et accédez aux
propriétés de la connexion RDPTCP.
Positionnez le nombre de couleurs sur « 32 bits par pixel ».
Activation de la compression RemoteFX
Lancez gpedit.msc et positionnez le paramètre Configurer Remote Fx sur Activé.
Validation du fonctionnement
Ouvrez une connexion bureau à distance avec un compte administrateur (MSTSC.exe) ; dans l’onglet
Avancé, activez toutes les options (ou choisissez LAN (10Mbits/s ou plus) dans le menu déroulant).

Revenez sur l’onglet Général et cliquez sur Connexion…
Une fois connecté, ouvrez l’observateur d’évènements :
Allez dans la rubrique Journaux des applications et des

services\Microsoft\Windows\RemoteDeskopServicesRemoteDesktopSessionManager\Admin, et
vérifiez la présence d’un évènement d’ID 1000 validant le bon fonctionnement.
Si le serveur dispose d’une carte de compression RemoteFX, un évènement d’ID 1001 est présent.
Activation de l’optimisation visuelle RemoteFX
Lancez gpedit.msc puis,
Positionnez le paramètre Optimiser l’expérience visuelle… sur Activé.
Positionnez le Taux de captures d’écran sur élevé.
Positionnez la Qualité d’affichage des images sur Moyen ou élevé en fonction du réseau disponible.

Bien que RemoteFX optimise la bande passante consommée et améliore encore l’expérience utilisateur,
le gros des nouveautés de cette technologie ne s’applique qu’aux infrastructures VDI.

Composants de Terminal Server
1. Améliorations apportées au noyau
Dès Windows 2008 des améliorations ont été apportées au moteur des services TSE et désormais RDS. Le noyau
du moteur des services TSE (Termsrv.dll) a été divisé en deux composants : Lsm.exe qui est le noyau du
gestionnaire de sessions et Termsrv.dll qui est le gestionnaire des connexions distantes.
Le Gestionnaire de Sessions Locales (LSM Local Session Manager) est un processus tournant en mode noyau qui
est lancé au démarrage du système. LSM interagit avec d’autres composants clefs du système, tels que smss.exe
(Session Management Subsystem), winlogon.exe (Windows LogOn Process) ou encore crss.exe (Client/Server
Runtime Subsystem). Son but est d’assurer la parfaite synchronisation des différents éléments du système
d’exploitation avec les opérations menées par le gestionnaire de sessions (par exemple les opérations de
chargement/déchargement des pilotes vidéo lors du passage d’une session active à une session déconnectée).
Le service Termsrv (Termsrv.dll tourne à l’intérieur d’un processus svchost.exe) héberge un écouteur qui
communique avec un pilote TDI (mode noyau) afin d’écouter les requêtes de connexions. Il interagit également
avec le serveur de licences, la pile de protocole RDP ou encore avec le Gestionnaire de Sessions Locales.
En outre, désormais seul le gestionnaire de sessions locales fonctionne avec un compte de service système, le
service Termsrv tourne lui avec un compte de service réseau ce qui permet d’améliorer la sécurité.
Enfin, voici deux tableaux récapitulant les services et les fichiers importants utilisés sous Windows 2008 R2 :
Services :
Nom du Service Localisation
Services Bureau à distance %systemroot%\system32\svchost.exe k termsvcs %
(TermServices) systemroot%\system32\termsrv.dll
Configuration des services Bureau %systemroot%\system32\svchost.exe k netsvcs %
à distance (SessionEnv) systemroot%\system32\sessenv.dll
Passerelle des services Bureau à %systemroot%\system32\svchost.exe k tsgateway %
distance (TSGateway) systemroot%\system32\aaedge.dll
Service Broker pour les connexions %systemroot%\system32\tssdis.exe
Bureau à distance (Tssdis)
Redirecteur de port du mode %systemroot%\system32\svchost.exe k
utilisateur des services Bureau à LocalSystemNetworkRestricted %systemroot%\system32
distance (UMRdpService) \umrdp.dll
Fichiers :
Composant Description
AACLIENT.DLL TS Web Access
CREDSSP.DLL Support du SSO
MSTSCAX.DLL ActiveX de contrôle TS
MSTSC.EXE Exécutable du bureau à distance
RDPCFGEX.DLL Extension de configuration des connexions
RDPD3D.DLL Extension de rendu Direct 3D (Dx10)
RDPDD.DLL Pilote vidéo
RDPINIT.EXE Utilisé pour l’initialisation de RemoteApp (lancé par USERINIT.EXE)

RDPSHELL.EXE Shell pour RemoteApp (remplace explorer.exe)
RDPSIGN.EXE Permet de signer les fichiers .rdp
RDPWSX.DLL Utilisé pour les opérations de connexion/déconnexion
RDPDD.DLL Pilote écran TS
RDPCLIP.EXE Redirection du pressepapier
TERMSRV.DLL Gestion de la pile de connexion
TSDDD.DLL Pilote écran pour une connexion console
WINLOGON.EXE Fournit les opérations de connexion/déconnexion [Ctrl+Alt+Suppr]
WINSTA.DLL Fournit les informations de session (durée d’inactivité par exemple)
WINMM.DLL Support des services multimédia
WTSAPI32.DLL Api de développement
2. Isolation de la session 0
Une des nouvelles fonctionnalités permettant d’accroître la sécurité du système est l’isolation de la session 0.
Sous Windows 2003, les applications et les services tournaient tous dans la session 0 (appelée session console)
ce qui n’était pas sans risque dans la mesure où de nombreux services fonctionnent avec des privilèges
systèmes.
Dès Windows 2008, seuls les services tournent dans la session 0 (plus de connexion interactive), les
applications, elles, fonctionnent dans d’autres sessions (un programme malveillant ne pourra plus utiliser une
application mal codée pour attaquer un service afin d’élever son niveau de droits).
a. Les différents états des sessions
Dès lors qu’un utilisateur se connecte à un serveur (localement ou à distance), il ouvre ce que l’on appelle une
session interactive. Cette session contient aussi bien des processus systèmes, que des applications ou encore
le bureau de l’utilisateur.
Sous Windows 2008 R2, le premier ID des sessions interactives est le 1 (l’ID 0 est réservé aux services), que
l’utilisateur soit connecté localement (à la console du serveur) ou à distance.
Durant sa vie, une session passe par plusieurs états dont les plus intéressants sont actif et déconnecté :
● Etat actif : l’utilisateur travaille actuellement dans sa session.
● Etat déconnecté : l’utilisateur n’est pas connecté à la session mais les applications continuent de s’y
exécuter.
b. Terminal local ou distant

Quand une session est active, celleci est attachée à un certain nombre de périphériques d’entrée/sortie
(clavier, écran…) qui forment ce que l’on appelle un terminal. Le terminal peut être soit local (s’il s’agit des
éléments physiquement connectés sur le serveur), soit distant (s’il s’agit d’une liaison avec les entrées/sorties
du client). Dans le cas d’un terminal distant, celuici est également associé à un objet de connexion qui contient
notamment des informations sur la pile de protocole ou encore les pilotes d’extension.
Quand une session est déconnectée, elle n’est plus attachée à aucun terminal. S’il s’agit d’une connexion
distante, le terminal et l’objet connexion sont alors détruits. En revanche, un terminal local n’est jamais détruit
de manière permanente. Quand la session attachée à un terminal local passe à l’état déconnecté, une nouvelle
session console est générée et un nouveau terminal local y est rattaché (bien que la session ne soit pas active,
elle est quand même attachée au terminal local). Ce type de session est dans un état appelé connecté
(affichage de l’écran [Ctrl][Alt][Suppr]).
c. Reconnexion de session
Une session déconnectée doit être rattachée à un nouveau terminal (local ou distant) avant de pouvoir être
réutilisée. Voici les différentes étapes qui se déroulent dans ce cas :
● Si l’utilisateur se connecte localement sur le serveur, une session (ID 1) est attachée au terminal local
et passe dans l’état actif. La session créée porte le nom de session console.
● Quand l’utilisateur se déconnecte (ou verrouille sa machine), la session passe dans l’état déconnecté.
À cet instant, la session 1 n’est plus attachée à aucun terminal. Quand le terminal a fini de se fermer,
une nouvelle session (ID 2) est créée et rattachée au terminal local (session dans l’état connecté). La
session d’ID 1 reste, elle, dans l’état déconnecté et le nom console est assigné à la session d’ID 2.
● Si le même utilisateur se connecte à distance sur le serveur, un nouveau terminal distant est créé et
rattaché à sa session déconnectée (ID 1). La session d’ID 1 passe dans l’état actif avec ce terminal
distant.
● Lorsque l’utilisateur se déconnecte, le terminal distant est détruit et la session repasse dans l’état
déconnecté.
● La session d’ID 1 ne sera fermée que lorsque l’utilisateur initiera une fermeture de session (ou que
l’administrateur forcera la fermeture).
d. Option /console du client RDC
Sous Windows 2003, la session d’ID 0 est appelée session console et rattachée au terminal local. Lorsqu’un
utilisateur ouvre une session locale, il est de fait connecté sur la session d’ID 0 (qui n’est fermée que lors d’un
arrêt du système). Dans les faits, certaines opérations, telles que des installations d’applications ou l’affichage
de certaines boîtes de dialogues, ne peuvent se faire qu’à la console. Pour permettre aux administrateurs
d’accéder à la session 0 à distance, le commutateur /console a donc été ajouté au client RDC.
Comme dit précédemment, depuis Windows 2008, la session d’ID 0 n’est plus interactive (réservée aux
services). La session dite console, quant à elle, est simplement celle qui est connectée au terminal local, ce qui
signifie, en d’autres termes, que n’importe quelle session (quel que soit son ID) peut être associée au terminal
local et donc être de type console.
Contrairement à ce qui existe sous Windows 2003, il n’y a plus de raison, avec Windows 2008 et 2008 R2, de
chercher à se connecter à distance au terminal local (session dite console) car l’ensemble des sessions
distantes bénéficient des mêmes fonctions que celleci. De fait, le commutateur /console, disponible jusqu’à
présent dans les clients RDC, ne sert sous Windows 2008 qu’à administrer le serveur sans consommer de
licence TSE CAL. Depuis la version du client RDC 6.1, le commutateur /admin a été introduit en remplacement
du commutateur /console, dévolu aux tâches d’administrations.
Enfin, il faut savoir que le commutateur /admin ne sert que si l’on se connecte à un serveur Windows 2008
Terminal Server ou Windows 2008 R2 RDS (pour ne pas consommer de CAL). L’utilisation de ce commutateur sur
un serveur en mode administration à distance n’a aucun effet.

3. Support des polices ClearType
Avec la démocratisation des écrans LCD, l’arrivée de Windows 7 en remplaçant direct de Vista et d’Office 2007,
les polices ClearType revêtent un caractère primordial. En effet, de nombreuses polices sont désormais
optimisées pour l’utilisation de ClearType et apparaîtraient bien fade si sa prise en charge n’est pas activée.
Pour autant, la finesse des polices a un coût. Normalement, sous RDS (sans activer le lissage des polices), les
polices sont transmises vers le client sous forme de caractères, ce qui est géré de manière efficace (mise en
cache) par le protocole RDP afin de limiter la consommation de bande passante. En revanche avec l’activation du
ClearType, les polices sont transmises sous forme d’images ce qui conduit à une augmentation significative de la
consommation de bande passante. D’après les tests réalisés par Microsoft, l’activation du lissage des polices
conduirait à une surconsommation de bande passante de l’ordre de quatre à dix fois celle mesurée lors de la
transmission des polices en mode caractère.
4. Prioritisation de l’affichage
Le client RDC 6 et 6.1 résout le problème de la prioritisation d’affichage en ajoutant la possibilité de contrôler les
canaux virtuels. Cela permet de positionner une importance plus faible pour les flux annexes tels que l’impression
ou le transfert de fichiers.
Le paramétrage, défini par défaut est de 70 % pour l’affichage et les entrées sorties (clavier/souris) et de 30 %
pour le reste des flux. Ce paramétrage peut être ajusté à l’aide des clefs de registre suivantes (Type DWORD) :
Sous HKLM\SYSTEM\CurrentControlSet\Services\TermDD :
FlowControlDisable : positionner cette entrée à 1 pour désactiver la prioritisation de l’affichage. Les requêtes
seront alors traitées par un classique mécanisme de First In, First Out (Premier Entré, Premier Sorti).
FlowControlDisplayBandwidth : ce paramètre caractérise la priorité relative de l’affichage sur les autres canaux
virtuels. La valeur par défaut est 70 et le maximum 255.
FlowControlChannelBandwidth : ce paramètre détermine la priorité relative des autres canaux virtuels. La
valeur par défaut est 30 et le maximum 255.
FlowControlChargePostCompression : cette valeur spécifie si l’allocation de bande passante doit être calculée
avant ou après la compression. La valeur par défaut (0) stipule un calcul sur les octets avant compression.
5. Installation automatisée des services RDS
Lors du déploiement de fermes de grandes tailles, il devient intéressant d’automatiser au maximum les tâches

d’installation. Pour ce faire, il conviendra d’utiliser un fichier Unattend.xml et d’y ajouter quelquesunes des
options suivantes (il est conseillé d’utiliser Windows SIM pour la création du fichier, disponible avec l’outil WAIK,
Windows Automated Installation Kit, fourni par Microsoft).
● Activation des connexions distantes
Ce paramètre détermine si les connexions à distance sont autorisées.
Composant : MicrosoftWindowsTerminal ServicesLocalSessionManager
Paramètre : fDenyTSConnections
Valeurs :
True : les connexions distantes sont désactivées (valeur par défaut).
False : les connexions distantes sont activées.

● Authentification des utilisateurs
Ce paramètre spécifie si l’utilisateur doit être authentifié avant l’établissement de la session RDP.
Composant : MicrosoftWindowsTerminalServicesRDPWinStationExtensions
Paramètre : UserAuthentication
Valeurs :
0 : Network level authentication pas obligatoire (par défaut)
1 : Network level authentication obligatoire
● Couche de sécurité
Ce paramètre précise la manière dont le client et le serveur doivent communiquer pour établir une connexion
RDP.
Composant : MicrosoftWindowsTerminalServicesRDPWinStationExtensions
Paramètre : SecurityLayer
Valeurs :
0 : Utilisation d’une couche de sécurité RDP
1 : Négocier la méthode de connexion (par défaut)
2 : Utilisation du protocole SSL (TLS) (Secure Socket Layer / Transport Layer Security)

6. Certificats de passerelle RDS
a. Prérequis pour les certificats de passerelle
La mise en œ uvre d’une passerelle RDS sur un serveur nécessite un certificat respectant les éléments
suivants :
● Le nom fourni dans le champ sujet (CN Certificate Name) doit être identique au nom DNS utilisé par les
clients pour se connecter à la passerelle.
● Certificat de type ordinateur.
● Certificat de type authentification de serveur ; EUK (Extended Key Usage) 1.3.6.1.5.5.7.3.1.
● Le certificat a sa clef privée correspondante.
● Le certificat n’est pas expiré.
● Le certificat doit être approuvé par les clients (membre du magasin Autorités de certification racines de
confiance).
b. Comment obtenir un certificat pour sa passerelle SSL
Comme évoqué précédemment, le protocole TLS 1.0 est utilisé pour chiffrer les communications ayant lieu entre
le client et la passerelle, ce qui nécessite l’installation d’un certificat x509 sur celleci.
Si votre société possède déjà un certificat public, vous pouvez l’utiliser s’il répond aux critères suivants :

● Il est membre du programme Microsoft Root Certificate (http://go.microsoft.com/fwlink/?LinkID=59547).
● Il respecte les prérequis nécessaires pour RD Gateway décrits précédemment.
Dans le cas contraire (par exemple certificat autogénéré), il faudra l’ajouter au magasin local de certificats
(pour la passerelle et les clients qui y accèdent).
7. Partage de Session sous 2008 R2 (Session Sharing)
Le partage de session (Session Sharing) tient une place prépondérante dans une infrastructure à répartition de
charge. Cette technique permet de limiter le nombre de sessions différentes ouvertes sur les serveurs de la
ferme.
Pour bien comprendre ce concept, un petit exemple s’impose : supposons que l’on publie les applications Word,
Excel et Outlook dans une ferme de trois serveurs. Un utilisateur lance Word et ouvre une session (mode
seamless) sur le moins chargé des serveurs de la ferme. Le même utilisateur lance maintenant Outlook, cette
application se lancera, sous réserve d’être présente sur le serveur, dans la même session. Cette technique
présente deux intérêts majeurs :
● Rapidité : pas de nouveau processus d’ouverture de session à effectuer.
● Fiabilité : limite sensiblement les problèmes de profils utilisateurs, notamment dans le cas de profils
itinérants.
Cette technologie n’était pas disponible nativement sous Windows 2003 et il fallait, pour en bénéficier, utiliser
des produits d’éditeurs tiers tels Citrix et Systancia.
Avec Windows 2008 R2, le partage de session est maintenant disponible avec RemoteApp.
Si l’on accède au gestionnaire des services Bureau à distance après avoir lancé deux applications avec le même
compte d’utilisateur, on constate que cellesci sont bien exéctuées dans la même session (tcp#0).
Pour autant et bien que le Session Sharing soit avantageux à bien des égards, l’utilisation qui en est faite par le
Connection Broker est plus discutable. En effet, on pourrait croire que lorsqu’un utilisateur lance une deuxième
application distante, Windows vérifie d’abord si l’application demandée est présente sur le serveur hébergeant la
première et agisse en conséquence ; dans les faits, ce qui se produit est moins élégant.
Le problème tient au fait que le Connection Broker n’a pas connaissance de l’application distante qui est lancée
par l’utilisateur, donc il se contente de diriger l’utilisateur vers le serveur sur lequel une session est déjà active.
Le problème de cette approche est qu’elle suppose que les fermes soient équilibrées et que tous les serveurs
RDS ont les mêmes applications d’installées. Or, les conflits interapplications ne sont pas un mythe et conduisent
bien souvent à en isoler certaines sur des serveurs dédiés. Dans une telle situation, le Session Sharing ne vous

sera, malheureusement, d’aucune utilité.
8. Création de session en parallèle (Parallel Session Creation)
Le reproche le plus courant fait par les utilisateurs lorsqu’ils utilisent des applications distantes est le temps
d’attente pour leur lancement.
En effet, supposons qu’un utilisateur, habitué à attendre moins de cinq secondes pour lancer Excel avec son
ancien PC, doit désormais en attendre vingt avec sa nouvelle machine flambant neuve parce que celleci est
dépourvue de suite Office localement, la révolte risque fort de se préparer…
Malheureusement, une partie du problème se trouve dans la méthode même de création des sessions qui est
une opération séquentielle. En d’autres termes, un serveur RDS ne peut traiter qu’une demande d’ouverture de
session à la fois, les autres attendant leur tour. Pour bien comprendre la portée que peut prendre le problème,
prenons un petit exemple. Imaginons que votre entreprise utilise dix serveurs RDS pour un total de 200
connexions simultanées. Si le temps de lancement de l’application métier prend 20 secondes, cela signifie que 30
utilisateurs par minute peuvent ouvrir une session. En d’autres termes, et dans le meilleur des cas (utilisation
optimale des ressources), il ne faudra pas moins de sept minutes pour connecter tous les utilisateurs.
Le problème peut prendre encore plus d’ampleur avec les architectures 64 bits, qui permettent d’augmenter le
nombre d’utilisateurs par serveur. En effet si l’on réduit à cinq le nombre de machines, l’addition passera alors au
quart d’heure, etc.
Windows 2008 R2 intègre une nouvelle fonctionnalité appelée Parallel Session Creation qui permet d’initier au
moins quatre sessions en parallèle, voire beaucoup plus dans le cas de système multiprocesseurs.
Pour autant, bien que cette fonctionnalité permette de réduire de manière significative le temps de connexion
global de l’ensemble des utilisateurs, cela ne diminuera pas pour autant le temps d’ouverture intrinsèque de
chaque session qui, dans notre exemple, restera de vingt secondes.
9. RDS ET WSRM (Windows System Resource Manager)
Le gestionnaire de ressources système de Windows 2008 R2 permet de contrôler la quantité de CPU et de
mémoire allouée aux applications, services et processus. La gestion des ressources du système permet de
s’assurer, par exemple, qu’une application dispose toujours de suffisamment de mémoire ou encore de répartir
précisément les ressources processeur.
WSRM est disponible sous la forme d’une fonctionnalité, nécessitant la présence des fonctionnalités base de
données interne Windows, et doit être installé après le composant Service Bureau à distance.

Architecture réseau et haute disponibilité
Bien que la répartition de charge se fasse essentiellement sur la comptabilisation du nombre de connexions
connectées et déconnectées, les fonctionnalités offertes par le Connection Broker ne se limitent pas à cela. En
effet, Il intègre nativement une protection contre l’effet trou noir, ainsi qu’une limitation du nombre de sessions par
serveur.
Afin de prévenir l’effet trou noir, qui est totalement bloquant pour les utilisateurs, deux techniques sont
généralement utilisée :
● La première consiste à charger artificiellement les serveurs qui ne doivent plus recevoir de nouvelles
connexions afin qu’ils ne soient plus éligibles aux yeux du répartiteur de charge (on évite ainsi une
surcharge). La charge revient à un niveau normal dès que le processus d’ouverture de session est
achevé.
● La deuxième, celle utilisée par le Connection Broker, consiste à limiter le nombre de sessions en attente
de traitement vers le même serveur RDS (par exemple pas plus de huit connexions concurrentes par
serveur). Cette technique est éminemment simple mais très efficace. La limitation du nombre maximum de
connexions consiste, quant à elle, à déterminer le nombre de sessions limite qu’un serveur peut héberger.
Cette technique permet de ne pas pénaliser les utilisateurs déjà connectés en allant audelà de la charge
acceptable par le serveur. Toutefois, cette limite n’est pas calculée automatiquement par le serveur RDS,
ni même configurable dans une quelconque interface graphique, et l’opération à mener sur chacun des
serveurs.
L’activation de cette option se fait via la clef UserSessionLimit dans
HKLM\System\CurrentControlSet\Control\Terminal Server, en y positionnant le maximum souhaité.
La mise en œ uvre d’une solution de haute disponibilité peut aller d’une architecture très simple à une autre très
complexe, suivant le niveau de service attendu.
1. Haute disponibilité basée sur le DNS

Dans cette approche minimaliste (déjà évoquée dans le chapitre Tour d’horizon de Windows 2008 R2), la
répartition des requêtes entre les serveurs se fait par un tourniquet DNS (activé par défaut depuis Windows
2003). Le processus d’ouverture de session est le suivant :
1) Interrogation du serveur DNS afin de connaître l’adresse IP d’un des serveurs de la Ferme.
2) Connexion sur le serveur RDS 1.
3) Le serveur RDS 1 contacte le service Connection Broker afin de déterminer où l’utilisateur devra finalement
ouvrir une session.
4) Le Connection Broker indique au serveur RDS 1 que l’utilisateur n’a pas de session déconnectée et que le
serveur RDS 2 est le moins chargé.
5) Le serveur RDS 1 redirige le client via RDP vers le serveur RDS 2.
6) Le client RDP contacte le serveur RDS 2.
7) La session de l’utilisateur est créée sur le serveur RDS 2.
2. Haute disponibilité basée sur le DNS avec redirecteur dédié

Lorsque l’adresse IP de tous les serveurs RDS est associée à l’alias de la Ferme, les requêtes des clients sont
dirigées par le tourniquet DNS vers n’importe quel serveur de la Ferme. Le serveur qui reçoit la requête initiale de
connexion agit comme un redirecteur (vers le service Connection Broker).
Cette situation peut s’avérer préjudiciable au plan des performances sur des fermes de grandes tailles ou
fortement chargées. Dès lors, la solution consiste à dédier des serveurs RDS au rôle de redirecteur. Ces serveurs
acceptent les requêtes entrantes, mais pas de sessions utilisateurs.
La configuration se fait comme suit :
● Créer des entrées pour le tourniquet DNS. Chaque redirecteur doit avoir une entrée correspondant au
nom de la ferme.
● Configurer les serveurs RDS pour interdire les connexions : ouvrir la console de configuration d’hôte de
Bureau à distance.
Dans la partie Modifier les paramètres, double cliquer sur Mode d’ouverture de session de l’utilisateur
et sélectionner Autoriser les reconnexions mais refuser les nouvelles ouvertures de session.

Bien entendu un administrateur peut toujours se connecter sur le serveur en utilisant le
commutateur /admin de son client RDC.
Dans cette configuration le processus d’ouverture de session pourrait, par exemple, être le suivant :
1) Interrogation du serveur DNS afin de connaître l’adresse IP d’un des redirecteurs RDS.
2) Connexion sur le serveur R2.
3) Le serveur R2 contacte le service Connection Broker afin de déterminer où l’utilisateur devra ouvrir une
session.
4) Le Connection Broker indique au serveur R2 que l’utilisateur a une session déconnectée sur le serveur RDS 1.
5) Le serveur R2 redirige le client via RDP vers le serveur RDS 1.
7) L’utilisateur récupère sa session déconnectée sur le serveur RDS 1.
3. Haute disponibilité avec redirecteurs dédiés et NLB
Bien que la solution précédente fournisse déjà un certain niveau de disponibilité, elle s’appuie hélas encore sur
un mécanisme simple de tourniquet DNS.
Une solution plus sécurisée consiste à remplacer ce tourniquet DNS par un mécanisme de répartition de charge
tel que NLB (Network Load Balancing) afin d’orienter les requêtes vers les redirecteurs.

La mise en œ uvre d’un dispositif d’équilibrage de la charge réseau permet d’assurer la disponibilité permanente
d’au moins un redirecteur pour servir les clients.
a. Prérequis nécessaires pour l’utilisation de Network Load Balancing
La mise en place d’un NLB nécessite de disposer des éléments suivants :
● Au moins une carte réseau.
● Activer uniquement TCP/IP sur cette interface.
● Tous les membres du cluster NLB doivent être dans le même sousréseau.
● S’assurer que les clients puissent atteindre ce sousréseau.
● Tous les serveurs NLB de la ferme doivent être dans le même domaine.
b. Installation du NLB
Depuis le gestionnaire de serveur, aller dans l’ajout de fonctionnalités et sélectionner Equilibrage de la charge
réseau, puis valider pour procéder à l’installation.
c. Configuration du NLB
La configuration du cluster NLB se fait en trois étapes :

● Configuration individuelle de chaque nœ ud du cluster.
● Configuration des paramètres pour le cluster.
● Paramétrage des règles de ports.
Pour plus de détails, consulter l’article « StepbyStep Guide for Configuring Network Load Balancing
with Terminal Services » sur le TechNet Microsoft.
Dans cette configuration le processus d’ouverture de session pourrait être le suivant :
1) Interrogation du serveur DNS afin de connaître l’adresse IP virtuellement partagée par les deux serveurs du
cluster NLB.
2) Connexion sur le cluster NLB qui redirige le client sur le serveur R2.
3) Le serveur R2 contacte le service Connection Broker afin de déterminer où l’utilisateur doit ouvrir une
session.
4) Le Connection Broker indique au serveur R2 que l’utilisateur n’a pas de session déconnectée et que le
serveur RDS 2 est le moins chargé.
5) Le serveur R2 redirige le client via RDP vers le serveur RDS 2.
7) L’utilisateur ouvre une session sur le serveur RDS 2.
4. Haute disponibilité avec redirecteurs dédiés, NLB et Connection Broker en
cluster
À ce stade de l’architecture, tous les éléments sont doublés et dimensionnés pour accepter suffisamment de
connexions. La dernière question qui me vient à l’esprit est : que se passeraitil si mon service Connection Broker
n’est plus disponible ? La réponse est simple : il n’y aurait plus de répartition de charge dans la ferme, ni même
de reprise des sessions déconnectées…
Il est évident que cette faiblesse dans l’architecture, n’est pas acceptable ; dès lors la solution qui s’impose est
la mise en cluster du service Connection Broker (ce que l’on faisait déjà sous Windows 2003 avec l’annuaire de
session).

Le fonctionnement de cette architecture est identique au précédent mais ne contient plus aucun élément non
secouru. Bien que ce type d’architecture soit techniquement alléchant et présente un haut niveau de tolérance
de panne, il n’en reste pas moins difficile à mettre en œ uvre et relativement coûteux.
Pour ce qui est de définir l’architecture qui convient le mieux à son entreprise, la première question que l’on doit
se poser est : Quelle est la durée d’interruption de service tolérable pour mes applications ? Si la réponse est
aucune (ou disons le moins possible), alors il faudra accepter le coût et la complexité inhérents à ce type de
contraintes.

Service d’annuaire et stratégies de groupes
1. Nouvelle infrastructure des GPO
a. Introduction
Si vous utilisez les stratégies de groupes, vous savez, bien sûr, comment utiliser les modèles d’administration
pour configurer les paramètres des systèmes d’exploitation et des applications. Les fichiers ADM, inclus avec
Windows ou encore Office, couvrent la plupart des configurations ou restrictions nécessaires à nos
environnements RDS. Toutefois, il faut parfois créer ses propres modèles ADM pour incorporer des paramètres
personnalisés ou des applications d’éditeurs tiers. La conception de modèles ADM est souvent laborieuse, car
ils ont une syntaxe unique et doivent être créés à l’aide d’un éditeur de texte. Bien sûr, avec le temps et
l’expérience, beaucoup d’entre nous sont passés maîtres dans l’art de créer leurs propres fichiers ADM.
Avec l’avènement de Windows Vista/2008 et plus récemment Windows 7/2008 R2, Microsoft a transformé le
format des modèles de stratégie de groupe désormais basé sur une structure Xml. Ce nouveau format, appelé
ADMX, offre de nombreux avantages par rapport aux anciens fichiers ADM, notamment la prise en charge
multilingue et la possibilité de disposer d’un emplacement de stockage centralisé.
Tout cela s’annonce sous de très bons hospices, toutefois, qu’en estil si vous voulez créer vos propres fichiers
ADMX et n’êtes pas familier avec Xml ? Plus important encore, que deviennent tous ces fichiers ADM
personnalisés que vous avez créés durant toutes ces années ?
Avant de répondre à ces questions, revenons sur le fonctionnement actuel des stratégies de groupe et voyons
en quoi consiste exactement cette nouvelle infrastructure.
Avant Windows Vista (et Windows 2008), le traitement de la stratégie de groupe se déroulait au cours d’un
processus appelé Winlogon.
Le processus Winlogon.exe (Winlogon signifiant Windows LogOn Process, en français : ouverture de session

Windows) est un processus générique de Windows NT/2000/XP chargé de gérer l’ouverture et la fermeture des
sessions mais également de servir les diverses tâches de stratégie de groupe.
La stratégie de groupe possède désormais son propre service Windows (gpsvc : client de stratégie de groupe).
De plus, elle est renforcée, ce qui signifie qu’il est impossible de l’arrêter ou qu’un administrateur puisse
prendre possession des autorisations définies sur la stratégie de groupe pour les désactiver. Ces modifications
améliorent la fiabilité globale du moteur de la stratégie de groupe.
b. Amélioration de la détection réseau
Dans les versions antérieures à Windows Vista/2008, le moteur de la stratégie de groupe essaye de
déterminer si l’accès au contrôleur de domaine s’effectue via un lien lent ou un lien rapide. Il utilise ensuite
cette information pour permettre la définition des paramètres de stratégie à appliquer. Cette opération n’a pas
été supprimée dans la nouvelle infrastructure, mais la méthode de calcul de la bande passante disponible a
quelque peu évolué.
Jusqu’à présent, la détermination de cette vitesse était effectuée par l’envoi de paquets ICMP (ping) aux
contrôleurs de domaine. Cette approche simpliste connaissait quelques problèmes dans la pratique. D’abord,
certains administrateurs désactivent le protocole ICMP sur leur routeur. Ensuite, si la connexion s’établit via des
liens à latence élevée (satellite par exemple), les calculs ne sont pas fiables.
La nouvelle stratégie de groupe est désormais plus intelligente et permet de connaître la connectivité réseau
en temps réel. La principale modification concerne le moteur de stratégie de groupe, qui utilise maintenant le
service NLA (Network Location Awareness) qui l’alerte lorsqu’un contrôleur de domaine est disponible afin de
procéder, si nécessaire, à une actualisation de la stratégie de groupe.
Bien évidemment, dans la majorité des architectures centralisées, les serveurs RDS sont sur le même LAN que
les contrôleurs de domaine et disposent donc toujours d’une connexion rapide. Toutefois, il n’est pas rare de

trouver un serveur RDS isolé sur un site distant dépourvu de contrôleur de domaine proche…
c. GPO locales multiples
Bien que les GPO soient le meilleur moyen de verrouiller l’environnement de travail dans une ferme RDS, celleci
suppose que l’on dispose d’un domaine Active Directory. Malheureusement, on trouve également des serveurs
de terminaux dans des domaines NT4 voire même dans des groupes de travail. Dans ce cas, la solution
consiste à positionner des stratégies locales au serveur avec l’inconvénient majeur qu’elles s’appliquent à tous,
y compris aux administrateurs.
La nouvelle fonctionnalité de multiplicité des GPO locales résout ce problème en utilisant un modèle en couches.
Il existe toujours une GPO locale par défaut, qui s’applique au contexte de l’ordinateur local et qui affecte tous
les utilisateurs sur le système, mais il est désormais possible de définir des stratégies qui s’appliquent aux
administrateurs et aux nonadministrateurs.
Ouvrez la MMC. (Cliquez sur Démarrer, cliquez dans la zone exécuter et tapez mmc.exe, puis validez
par [Entrée].)
Dans le menu Fichier, cliquez sur Ajouter/Supprimer un composant logiciel enfichable.
Dans la boîte de dialogue Ajouter/Supprimer un composant logiciel enfichable, cliquez sur Éditeur
de stratégies de groupe, puis sur Ajouter.
Dans la boîte de dialogue Sélection d’un objet de stratégie de groupe, cliquez sur Parcourir.
Cliquez sur Cet ordinateur pour modifier l’objet de stratégie de groupe locale.

Cliquez sur Utilisateurs pour modifier les objets de stratégie de groupe locale Administrateur, Non
administrateur ou par utilisateur.
Cliquez sur Terminer, sur Fermer, puis sur OK.
L’Éditeur de stratégie de groupe locale ouvre l’objet de stratégie de groupe (GPO) que vous
voulez modifier.

Évidemment, si le système a été lié à un domaine Active Directory, les objets de stratégie de groupe
Active Directory ont la priorité sur les stratégies locales.
d. ADM vs ADMX
Les fichiers ADM fournissent des modèles de définition pour une grande partie des éléments disponibles dans
une stratégie de groupe. Bien que celleci ne soit évidemment pas entièrement contrôlée par les fichiers ADM,
ils sont tout de même responsables de tous les éléments situés sous Configuration de l’ordinateur/de
l’utilisateur Modèles d’administration.
Malgré leurs qualités, ces fichiers ADM présentent quand même quelques inconvénients :
● Chaque fois qu’un nouvel objet GPO est généré, tous les fichiers ADM qui y sont utilisés sont copiés
dans le dossier ADM (qui se trouve dans le dossier SYSVOL) propre à la GPO ; chaque objet pesant en
moyenne quelques Mo.
● La multiplication des GPO entraîne donc un grand nombre de fichiers modèles en double, ce qui accroît
la quantité de données à répliquer entre les contrôleurs de domaine.
● Les fichiers ADM sont dépendants de la langue dans laquelle ils sont créés, ce qui pose quelques
problèmes pour les sociétés qui ne sont pas francofrançaise.
Le nouveau modèle de stratégie de groupe résout ces inconvénients en introduisant un nouveau format XML
pour les fichiers de définition de stratégie. Comme les fichiers ADMX sont indépendants de la langue, ils
s’accompagnent d’un ou de plusieurs fichiers ADML spécifiques à la langue.
Le format ADMX permet également la mise en œ uvre d’un dépôt centralisé pour tous les modèles. Ainsi, on

évite la réplication de doublon et on facilite la mise à jour des fichiers.
Windows 2008 R2 est livré avec environ 150 fichiers ADMX (et autant de fichiers ADML) pour remplacer les 6 à 8
fichiers ADM fournis dans les versions précédentes de Windows. Ces fichiers sont stockés dans le répertoire %
SystemRoot%\PolicyDefinitions et les fichiers ADML sont stockés dans un sousrépertoire spécifique à la langue
(enUS pour l’anglaisaméricain, ou frFR pour le français).
Migration des fichiers ADM
L’utilitaire ADMX Migrator (http://go.microsoft.com/fwlink/?LinkId= 77409) est un outil gratuit, développé par
FullArmor Corporation et mis à la disposition de Microsoft sous licence, offrant deux avantages principaux :
● Il permet de créer vos propres fichiers ADMX personnalisés.
● Il peut convertir vos anciens fichiers ADM au format ADMX.
ADMX Migrator propose deux méthodes de conversion : par le biais de l’éditeur ou à l’aide d’un programme de
ligne de commande.
2. Console de gestion des stratégies de groupe
La console de gestion des stratégies de groupe, ou GPMC, était disponible en téléchargement pour Windows XP
et Windows Server 2003.
La GPMC est maintenant directement intégrée au système, sous la forme d’une fonctionnalité à ajouter si la
machine pour gérer les stratégies n’est pas un contrôleur de domaine.
3. Stratégies de groupe Windows 2008 R2
Le premier élément notable est le nouveau découpage qui comprend Stratégies et Préférences. Le deuxième
élément est le nombre considérable de paramètres manipulables. Dans notre cas, nous allons nous intéresser
uniquement aux nouvelles stratégies propres à RDS 2008 R2 (le passage en revue de la globalité des stratégies
et préférences pouvant faire l’objet d’un ouvrage complet…).

Les stratégies ordinateur
Vous trouverez cidessous une liste des stratégies les plus intéressantes impactant sur le comportement global
de l’ordinateur.
Section Composants Windows\Services Bureau à distance\Hôte de la session Bureau à

distance\Connexions
● Autoriser le démarrage distant de programmes non répertoriés
Ce paramètre de stratégie permet de spécifier si des utilisateurs distants peuvent démarrer tout
programme sur le serveur hôte de session Bureau à distance, ou s’ils peuvent uniquement démarrer des
programmes répertoriés dans la liste Programmes RemoteApp.
Vous pouvez contrôler quels programmes sur un serveur hôte de session Bureau à distance peuvent
être démarrés à distance en utilisant le Gestionnaire RemoteApp pour créer une liste des programmes
RemoteApp. Par défaut, seuls les programmes figurant dans la liste Programmes RemoteApp peuvent
être démarrés lorsqu’un utilisateur démarre une session des services Bureau à distance.
Si vous activez ce paramètre de stratégie, les utilisateurs distants peuvent démarrer n’importe quel
programme sur le serveur hôte de session Bureau à distance. Par exemple, un utilisateur distant peut le
faire en spécifiant le chemin de l’exécutable du programme au moment de la connexion à l’aide du client
Connexion Bureau à distance.
Si vous désactivez ou ne configurez pas ce paramètre de stratégie, les utilisateurs distants peuvent
uniquement démarrer des programmes répertoriés dans la liste Programmes RemoteApp dans le
Gestionnaire RemoteApp TS lorsqu’ils démarrent une session des services Bureau à distance.
● Configurer l’intervalle de conservation des connexions
Ce paramètre de stratégie vous permet d’entrer un intervalle de conservation pour garantir que l’état de

la session sur le serveur hôte de la session Bureau à distance est cohérent avec l’état du client.
Lors d’une perte de connexion au serveur d’hôte de la session bureau à distance (RDS), il arrive que la
session reste active sur le serveur au lieu de passer à un état déconnecté (même si le client est
physiquement coupé du serveur). En cas de reconnexion du client, une nouvelle session risque d’être
créée (si le serveur le permet) au lieu d’effectuer une reprise de la session déjà existante, créant ainsi
un doublon sur le serveur.
Si vous activez ce paramètre de stratégie, vous devez entrer un intervalle de conservation. L’intervalle
de conservation détermine la fréquence (en minutes) à laquelle le serveur vérifie l’état de la session. La
plage des valeurs que vous pouvez entrer est de 1 à 999 999.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, aucun intervalle de conservation
n’est défini et le serveur ne vérifiera pas l’état de la session.
● Limiter le nombre de connexions
Vous pouvez utiliser ce paramètre pour limiter le nombre de sessions des services Bureau à distance qui
peuvent être actives sur un serveur. Si ce nombre est dépassé, les utilisateurs supplémentaires qui
tentent de se connecter reçoivent un message d’erreur leur indiquant que le serveur est occupé et de
réessayer plus tard. La limitation du nombre de sessions améliore les performances, car un nombre
moins élevé de sessions nécessite moins de ressources système. Par défaut, les serveurs hôte de la
session Bureau à distance autorisent un nombre illimité de sessions de services Bureau à distance et le
Bureau à distance pour administration autorise deux sessions de services Bureau à distance.
Pour utiliser ce paramètre, entrez le nombre maximal de connexions que vous souhaitez spécifier pour le
serveur. Pour spécifier un nombre illimité de connexions, tapez 999999.
Si vous activez ce paramètre, le nombre maximal de connexions est limité au nombre spécifié cohérent
avec la version de Windows et le mode des services Bureau à distance qui s’exécutent sur le serveur.
Si vous désactivez ce paramètre ou ne le configurez pas, les limites du nombre de connexions ne sont
pas appliquées au niveau de la stratégie de groupe.
● N’autoriser qu’une session de services Bureau à distance par utilisateur
Ce paramètre de stratégie vous permet de limiter les utilisateurs à une seule session de services Bureau
à distance.
Si vous activez ce paramètre de stratégie, les utilisateurs qui ouvrent une session à distance via les
services Bureau à distance sont limités à une seule session (active ou déconnectée) sur ce serveur. Si
l’utilisateur quitte la session dans un état déconnecté, il se reconnecte automatiquement à cette session
lors de la prochaine ouverture de session.
Si vous désactivez ce paramètre de stratégie, les utilisateurs sont autorisés à faire un nombre illimité de
connexions simultanées à distance à l’aide des services Bureau à distance.
Si vous ne configurez pas ce paramètre de stratégie, le paramètre Limiter les utilisateurs à une seule
session de l’outil Configuration de l’hôte de la session Bureau à distance détermine si les utilisateurs
sont limités à une seule session de services Bureau à distance.
Section Composants Windows\Services Bureau à distance\Client Connexion Bureau à distance
● Configurer l’authentification du serveur pour le client
Cette stratégie indique si le client peut quand même établir une connexion au Serveur RDS même s’il ne
peut l’authentifier. Si cette stratégie est activée, les paramètres suivants peuvent être définis :
■ Toujours connecter, même si l’authentification échoue
■ M’avertir si l’authentification échoue
■ Ne pas connecter si l’authentification échoue
Si cette stratégie est désactivée ou non configurée, la configuration spécifiée dans le fichier .rdp ou le client
d’accès distant est utilisée.
● Demander des informations d’identification sur l’ordinateur client
Ce paramètre de stratégie détermine si un utilisateur est invité à fournir sur l’ordinateur client des
informations d’identification pour établir une connexion à distance à un serveur hôte de la session

Bureau à distance.
Si vous activez ce paramètre de stratégie, un utilisateur est invité à fournir sur l’ordinateur client, plutôt
que sur le serveur hôte de la session Bureau à distance, des informations d’identification pour établir
une connexion à distance à un serveur hôte de la session Bureau à distance. Si les informations
d’identification de l’utilisateur sont enregistrées sur l’ordinateur client, l’utilisateur n’est pas invité à les
fournir de nouveau.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, la version du système
d’exploitation du serveur hôte de la session Bureau à distance détermine à quel moment un utilisateur
est invité à fournir des informations d’identification pour établir une connexion à distance à un serveur
hôte de la session Bureau à distance. Pour Windows 2000 et Windows Server 2003, un utilisateur est
invité sur le serveur Terminal Server à fournir des informations d’identification pour établir une connexion
à distance. Pour Windows Server 2008, un utilisateur est invité sur l’ordinateur client à fournir des
informations d’identification pour établir une connexion à distance.
Section Composants Windows\Services Bureau à distance\Gestionnaire de licences des services Bureau à
distance
● Empêcher la mise à jour de licence
Ce paramètre de stratégie permet de spécifier la version de la licence d’accès client (CAL) des services
Bureau à distance (RDS) délivrée par un serveur de licences des services Bureau à distance au client qui
se connecte aux serveurs hôte de la session Bureau à distance exécutant d’autres systèmes
d’exploitation Windows.
Un serveur de licences tente de fournir la CAL RDS la plus appropriée à une connexion. Par exemple, un
serveur de licences Windows Server 2008 tente de délivrer une CAL RDS Windows Server 2008 au client
qui se connecte à un serveur hôte de la session Bureau à distance exécutant Windows Server 2008 et
tente de délivrer une CAL TS Windows Server 2003 au client qui se connecte à un serveur Terminal
Server exécutant Windows Server 2003.
Par défaut, si la CAL RDS la plus appropriée n’est pas disponible pour une connexion, un serveur de
licences Windows Server 2008 délivre une CAL TS Windows Server 2008, si elle existe, aux clients
suivants :
■ Client se connectant à un serveur Terminal Server Windows Server 2003
■ Client se connectant à un serveur Terminal Server Windows 2000
● Si vous activez ce paramètre de stratégie, le serveur de licences délivre une CAL RDS temporaire au
client uniquement si aucune CAL RDS appropriée n’est disponible pour le serveur hôte de la session
Bureau à distance. Si le client a déjà reçu une CAL RDS temporaire qui a expiré depuis, il ne peut pas se
connecter au serveur hôte de la session Bureau à distance, sauf si la période de grâce de la licence RDS
du serveur hôte de la session Bureau à distance n’a pas expiré.
● Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, le serveur de licences adopte le
comportement par défaut décrit cidessus.
● Groupe de sécurité du serveur de licences
Ce paramètre de stratégie permet de spécifier les serveurs hôte de la session Bureau à distance
auxquels un serveur de licence Bureau à distance offre des licences d’accès client (CAL, Client Access
License) aux services Bureau à distance (RDS).
Vous pouvez utiliser ce paramètre de stratégie pour gérer les serveurs hôte de la session Bureau à
distance pour lesquels le serveur de licence Bureau à distance délivre les CAL RDS. Par défaut, un
serveur de licences délivre une CAL RDS à tous les serveurs hôte de la session Bureau à distance qui en
font la demande.
Si vous activez ce paramètre de stratégie et l’appliquez à un serveur de licences Bureau à distance, le
serveur de licences répondra uniquement aux demandes de CAL RDS issues des serveurs hôte de la
session Bureau à distance dont les comptes d’ordinateur sont membres du groupe Ordinateurs Terminal
Server sur le serveur de licences.
Par défaut, le groupe Ordinateurs Terminal Server est vide.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, le serveur de licences Bureau à
distance délivre une CAL RDS à tous les serveurs hôte de la session Bureau à distance qui en font la
demande. Le groupe Ordinateurs Terminal Server n’est ni supprimé, ni modifié d’une quelconque façon
par la désactivation ou la nonconfiguration de ce paramètre de stratégie.

Section Composants Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Délais
d’expiration des sessions
● Définir la limite de temps pour la fermeture de sessions RemoteApp
Ce paramètre de stratégie permet de spécifier combien de temps une session RemoteApp d’un
utilisateur restera dans un état déconnecté avant que la session du serveur hôte de session Bureau à
distance soit fermée.
Par défaut, si un utilisateur ferme un programme RemoteApp, la session est déconnectée du serveur
hôte de session Bureau à distance.
Si vous activez ce paramètre de stratégie, lorsqu’un utilisateur ferme un programme RemoteApp, la
session RemoteApp reste dans un état déconnecté jusqu’à ce que la limite de temps que vous avez
spécifiée soit atteinte. Lorsque cette limite est atteinte, la session RemoteApp est fermée sur le serveur
hôte de session Bureau à distance. Si l’utilisateur démarre un programme RemoteApp avant que la limite
de temps ne soit atteinte, l’utilisateur se reconnecte à la session déconnectée sur le serveur hôte de
session Bureau à distance.
Si vous désactivez ou ne configurez pas ce paramètre de stratégie, lorsqu’un utilisateur ferme un
programme RemoteApp, la session est déconnectée du serveur hôte de session Bureau à distance.
● Définir le délai d’expiration des sessions de services Bureau à distance ouvertes mais inactives
Ce paramètre de stratégie vous permet de spécifier la durée maximale pendant laquelle une session de
services Bureau à distance active peut demeurer inactive (sans saisie de données de la part de
l’utilisateur) avant d’être automatiquement déconnectée.
Pour activer ce paramètre de stratégie, vous devez sélectionner le délai souhaité dans la liste
déroulante Limite de session inactive. Les services Bureau à distance déconnecteront
automatiquement les sessions ouvertes mais inactives après la période de temps spécifiée. L’utilisateur
reçoit un avertissement deux minutes avant la déconnexion de la session, ce qui lui permet d’appuyer
sur une touche ou de déplacer la souris pour maintenir la session active. Si vous avez une session de
console, les limites de durée des sessions inactives ne s’appliquent pas.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, les services Bureau à distance
autorisent les sessions à rester ouvertes mais inactives pendant une durée illimitée. Vous pouvez
spécifier des limites de durée pour les sessions ouvertes mais inactives dans l’onglet Sessions de l’outil
Configuration de l’hôte de la session Bureau à distance.
Si vous voulez que les services Bureau à distance mettent fin à une session au lieu de la déconnecter
quand le délai d’expiration est atteint, vous pouvez configurer le paramètre de stratégie Configuration
ordinateur\Modèles d’administration\Composants Windows\Services Bureau à distance\Hôte de la
session Bureau à distance\Délais d’expiration des sessions\Mettre fin à la session quand les délais
d’expiration ont été atteints.
Ce paramètre de stratégie s’affiche à la fois dans Configuration ordinateur et dans Configuration
utilisateur. Si les deux paramètres de stratégie sont configurés, le paramètre de stratégie de
Configuration ordinateur est prioritaire.
● Définir le délai d’expiration des sessions déconnectées
Ce paramètre de stratégie vous permet de configurer un délai d’expiration pour les sessions des
services Bureau à distance déconnectées.
Vous pouvez utiliser ce paramètre de stratégie pour spécifier la durée maximale pendant laquelle une
session déconnectée est maintenue active sur le serveur. Par défaut, les services Bureau à distance
permettent aux utilisateurs de se déconnecter d’une session de services Bureau à distance sans se
déconnecter et mettre fin à la session.
Quand une session est dans un état déconnecté, les programmes en cours d’exécution sont maintenus
actifs même si l’utilisateur n’est plus connecté de façon active. Par défaut, ces sessions déconnectées
sont conservées pendant une durée illimitée sur le serveur.
Si vous activez ce paramètre de stratégie, les sessions déconnectées sont supprimées du serveur après
une durée spécifiée. Pour appliquer le comportement par défaut consistant à conserver les sessions
déconnectées pendant une durée illimitée, sélectionnez Jamais. Si vous avez une session de console,
les limites de durée des sessions déconnectées ne s’appliquent pas.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, les sessions déconnectées sont
conservées pendant une durée illimitée. Vous pouvez spécifier des limites de durée pour les sessions

déconnectées dans l’onglet Sessions de l’outil Configuration de l’hôte de la session Bureau à distance.
utilisateur. Si les deux paramètres de stratégie sont configurés, le paramètre de stratégie de

distance\Gestionnaire de licences
● Définir le mode de concession de licences des services Bureau à distance
Ce paramètre de stratégie permet de spécifier le type de licence d’accès client (CAL) des services Bureau
à distance (RDS) nécessaire à la connexion à ce serveur hôte de la session Bureau à distance.
Vous pouvez utiliser ce paramètre de stratégie pour sélectionner un des deux modes d’octroi de licence :
par utilisateur ou par périphérique.
Le mode de licence par utilisateur impose que chaque compte d’utilisateur qui se connecte à ce serveur
hôte de la session Bureau à distance dispose d’une CAL RDS par utilisateur.
Le mode de licence par périphérique impose que chaque périphérique qui se connecte à ce serveur hôte
de la session Bureau à distance dispose d’une CAL RDS par périphérique.
Si vous activez ce paramètre de stratégie, le mode de licence que vous y spécifiez a priorité sur le mode
de licence spécifié lors de l’installation de l’hôte de la session Bureau à distance ou dans l’outil
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, le mode de licence spécifié lors
de l’installation du service de rôle hôte de la session Bureau à distance ou dans l’outil Configuration de
l’hôte de la session Bureau à distance est utilisé.
● Utiliser les serveurs de licences Bureau à distance indiqués
Ce paramètre de stratégie permet de spécifier l’ordre dans lequel un serveur hôte de la session Bureau
à distance tente de localiser les serveurs de licences Bureau à distance.
Si vous activez ce paramètre de stratégie, un serveur hôte de la session Bureau à distance tente
d’abord de localiser les serveurs de licences spécifiés. Si cette opération échoue, le serveur hôte de la
session Bureau à distance procède ensuite à la détection automatique des serveurs de licences.
Dans le processus de détection automatique des serveurs de licences, un serveur hôte de la session
Bureau à distance appartenant à un domaine Windows Server essaie de contacter un serveur de
licences dans l’ordre suivant :
1. Serveurs de licences spécifiés dans l’outil de configuration de l’hôte de la session Bureau à distance
2. Serveurs de licences publiés dans les services de domaine Active Directory (AD DS)
3. Serveurs de licences installés sur des contrôleurs du même domaine que le serveur hôte de la session
Bureau à distance
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, le serveur hôte de la session
Bureau à distance utilise le mode de détection des serveurs de licences spécifié dans l’outil

distance\Redirection de l’imprimante
● Ne pas définir l’imprimante par défaut du client pour êtrel’imprimante par défaut d’une session
Ce paramètre de stratégie vous permet de spécifier si l’imprimante par défaut du client est définie
automatiquement en tant qu’imprimante par défaut d’une session sur un serveur hôte de la session
Bureau à distance.
Par défaut, les services Terminal Server désignent automatiquement l’imprimante par défaut du client
comme imprimante par défaut d’une session sur un serveur hôte de la session Bureau à distance. Vous
pouvez utiliser ce paramètre de stratégie pour modifier ce comportement.
Si vous activez ce paramètre de stratégie, l’imprimante par défaut est l’imprimante spécifiée sur
l’ordinateur distant.
Si vous désactivez ce paramètre de stratégie, le serveur hôte de la session Bureau à distance mappe
automatiquement l’imprimante par défaut du client et la définit comme imprimante par défaut au moment

de la connexion.
Si vous ne configurez pas ce paramètre de stratégie, l’imprimante par défaut n’est pas spécifiée au
niveau de la stratégie de groupe. Cependant, un administrateur peut configurer l’imprimante par défaut
des sessions client à l’aide de l’outil Configuration de l’hôte de la session Bureau à distance.
● Rediriger uniquement l’imprimante cliente par défaut
Ce paramètre de stratégie permet de spécifier si l’imprimante cliente par défaut est la seule imprimante
redirigée dans les sessions des services Bureau à distance.
Si vous activez ce paramètre de stratégie, seule l’imprimante cliente par défaut est redirigée dans les
sessions des services Bureau à distance.
Si vous désactivez ou ne configurez pas ce paramètre de stratégie, toutes les imprimantes clientes
sont redirigées dans les sessions des services Bureau à distance.
● Utiliser d’abord le pilote d’imprimante Easy Print des servicesBureau à distance
Ce paramètre de stratégie vous permet de spécifier si le pilote d’imprimante Easy Print des services
Bureau à distance est d’abord utilisé pour installer toutes les imprimantes client.
Si vous activez ou si vous ne configurez pas ce paramètre de stratégie, le serveur hôte de la session
Bureau à distance tente d’abord d’utiliser le pilote d’imprimante Easy Print des services Bureau à
distance pour installer toutes les imprimantes client. Si pour une raison quelconque le pilote
d’imprimante Easy Print des services Bureau à distance ne peut pas être utilisé, un pilote d’imprimante
du serveur hôte de la session Bureau à distance correspondant à l’imprimante client est utilisé. Si le
serveur hôte de la session Bureau à distance ne dispose d’aucun pilote d’imprimante correspondant à
l’imprimante client, celleci n’est pas disponible pour la session Bureau à distance.
Si vous désactivez ce paramètre de stratégie, le serveur hôte de la session Bureau à distance tente de
trouver un pilote d’imprimante adéquat pour installer l’imprimante client. Si le serveur hôte de la session
Bureau à distance ne dispose d’aucun pilote d’imprimante correspondant à l’imprimante client, il tente
d’utiliser le pilote d’imprimante Easy Print des services Bureau à distance pour installer l’imprimante
client. Si pour une raison quelconque le pilote d’imprimante Easy Print des services Bureau à distance ne
peut pas être utilisé, l’imprimante client n’est pas disponible pour la session des services Bureau à
distance.
Si le paramètre de stratégie Ne pas autoriser la redirection de l’imprimante client est activé, le
paramètre de stratégie Utiliser d’abord le pilote d’imprimante Easy Print des services Bureau à
distance est ignoré.

distance\Redirection de périphérique et de ressource
● Ne pas autoriser la redirection de périphérique PlugandPlay
Ce paramètre de stratégie vous permet de contrôler la redirection de périphériques PlugandPlay pris
en charge, tels que des appareils mobiles Windows, vers l’ordinateur distant lors d’une session de
Par défaut, les services Bureau à distance autorisent la redirection de périphériques PlugandPlay pris
en charge. Les utilisateurs peuvent utiliser l’option Autres de l’onglet Ressources locales de Connexion
Bureau à distance pour choisir les périphériques PlugandPlay pris en charge à rediriger vers
l’ordinateur distant.
Si vous activez ce paramètre de stratégie, les utilisateurs ne peuvent pas rediriger leurs périphériques
PlugandPlay pris en charge vers l’ordinateur distant.
Si vous désactivez ce paramètre de stratégie ou si vous ne le configurez pas, les utilisateurs peuvent
rediriger leurs périphériques PlugandPlay pris en charge vers l’ordinateur distant.
Section Composants Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Sécurité
● Modèle de certificat d’authentification serveur
Ce paramètre de stratégie vous permet de spécifier le nom du modèle de certificat qui détermine le
certificat sélectionné automatiquement pour authentifier un serveur hôte de la session Bureau à
distance.
Un certificat est nécessaire pour authentifier un serveur hôte de la session Bureau à distance lorsque

SSL (TLS 1.0) est utilisé pour sécuriser les communications entre un client et un serveur hôte de la
session Bureau à distance pendant des connexions RDP.
Si ce paramètre de stratégie est activé, vous devez spécifier un nom de modèle de certificat. Seuls les
certificats créés à l’aide du modèle de certificat spécifié sont pris en compte lors de la sélection
automatique d’un certificat pour authentifier le serveur hôte de la session Bureau à distance. Un
certificat est sélectionné automatiquement uniquement si aucun certificat n’a été spécifié.
S’il n’existe aucun certificat créé à l’aide du modèle de certificat spécifié, le serveur hôte de la session
Bureau à distance émet une demande d’inscription de certificat et utilise le certificat actif jusqu’à ce que
la demande soit traitée. S’il existe plusieurs certificats créés à l’aide du modèle de certificat spécifié, le
certificat dont la date d’expiration est la plus éloignée et qui correspond au nom actuel du serveur hôte
de la session Bureau à distance est sélectionné.
Si ce paramètre de stratégie est désactivé ou n’est pas configuré, un certificat autosigné est utilisé par
défaut pour authentifier le serveur hôte de la session Bureau à distance. Vous pouvez sélectionner un
certificat à utiliser pour authentifier le serveur hôte de la session Bureau à distance dans l’onglet
Général de l’outil Configuration de l’hôte de la session Bureau à distance.
● Ne pas autoriser les administrateurs locaux à personnaliser les autorisations
Spécifie de désactiver ou non les droits d’administrateur pour personnaliser les autorisations de sécurité
dans l’outil Configuration de l’hôte de la session Bureau à distance.
Vous pouvez utiliser ce paramètre pour empêcher les administrateurs d’apporter des modifications aux
groupes d’utilisateurs dans l’onglet Autorisations de l’outil Configuration de l’hôte de la session Bureau
à distance. Par défaut, les administrateurs peuvent effectuer de telles modifications.
Si l’état est Activé, l’onglet Autorisations de l’outil Configuration de l’hôte de la session Bureau à
distance ne peut pas être utilisé pour personnaliser les descripteurs de sécurité par connexion ni pour
modifier les descripteurs de sécurité par défaut pour un groupe existant. Tous les descripteurs de
sécurité sont en lecture seule.
Si l’état est Désactivé ou Non configuré, les administrateurs du serveur ont des privilèges illimités de
lecture et d’écriture sur les descripteurs de sécurité de l’utilisateur dans l’onglet Autorisations de l’outil
● Nécessite l’utilisation d’une couche de sécurité spécifique pour les connexions distantes (RDP)
Spécifie s’il faut requérir l’utilisation d’une couche de sécurité spécifique pour sécuriser les
communications entre les clients et les serveurs hôte de la session Bureau à distance lors des
connexions RDP.
Si vous activez ce paramètre, toutes les communications entre les clients et les serveurs hôte de la
session Bureau à distance doivent utiliser la méthode de sécurité spécifiée dans ce paramètre. Les
méthodes de sécurité suivantes sont disponibles :
■ Négocier : la méthode Négocier applique la méthode la plus sécurisée qui est prise en charge par
le client. Si TLS (Transport Layer Security) version 1.0 est prise en charge, elle est utilisée pour
authentifier le serveur hôte de la session Bureau à distance. Si TLS n’est pas pris en charge, le
chiffrement RDP natif est utilisé pour sécuriser les communications, mais le serveur hôte de la
session Bureau à distance n’est pas authentifié.
■ RDP : la méthode RDP utilise le chiffrement RDP natif pour sécuriser les communications entre le
client et le serveur hôte de la session Bureau à distance. Si vous sélectionnez cette valeur, le
serveur hôte de la session Bureau à distance n’est pas authentifié.
■ SSL (TLS 1.0) : la méthode SSL nécessite l’utilisation de TLS 1.0 pour authentifier le serveur hôte
de la session Bureau à distance. Si TLS n’est pas pris en charge, la connexion échoue.
● Si vous désactivez ce paramètre ou ne le configurez pas, la méthode de sécurité à utiliser pour les
connexions à distance aux serveurs hôte de la session Bureau à distance n’est pas appliquée via la
stratégie de groupe. Vous pouvez, cependant, configurer une méthode de sécurité obligatoire pour ces
connexions à l’aide de l’outil Configuration de l’hôte de la session Bureau à distance.
● Requérir des communications RPC sécurisées
Spécifie si un serveur hôte de la session Bureau à distance requiert des communications RPC sécurisées
avec tous les clients ou bien autorise des communications non sécurisées.
Vous pouvez utiliser ce paramètre pour renforcer la sécurité des communications RPC avec les clients en
autorisant seulement les demandes authentifiées et chiffrées.

Si l’état est défini sur Activé, le serveur des services Bureau à distance accepte les demandes des
clients RPC qui prennent en charge les demandes sécurisées et n’autorise pas les communications non
sécurisées avec les clients non approuvés.
Si l’état est défini sur Désactivé, le serveur des services Bureau à distance requiert toujours la sécurité
pour tout le trafic RPC. Cependant, les communications non sécurisées sont autorisées pour les clients
RPC qui ne répondent pas à la demande.
Si l’état est défini sur Non configuré, les communications non sécurisées sont autorisées.
● Requérir l’authentification utilisateur pour les connexions à distance à l’aide de l’authentification au
niveau du réseau
Ce paramètre de stratégie permet de spécifier s’il faut requérir l’authentification utilisateur pour les
connexions à distance au serveur hôte de la session Bureau à distance en utilisant l’authentification au
niveau du réseau. Ce paramètre de stratégie renforce la sécurité en imposant l’authentification
utilisateur plus tôt dans le processus de connexion à distance.
Si vous activez ce paramètre de stratégie, seuls les ordinateurs clients qui prennent en charge
l’authentification au niveau du réseau peuvent se connecter au serveur hôte de la session Bureau à
distance.
Pour déterminer si un ordinateur client prend en charge l’authentification au niveau du réseau, démarrez
Connexion Bureau à distance sur l’ordinateur client, cliquez sur l’icône dans le coin supérieur gauche de
la boîte de dialogue Connexion Bureau à distance, puis cliquez sur À propos de. Dans la boîte de
dialogue À propos de la Connexion Bureau à distance, recherchez l’expression « Authentification au
niveau du réseau prise en charge ».
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, l’authentification au niveau du
réseau n’est pas nécessaire pour l’authentification utilisateur avant d’autoriser les connexions à
distance au serveur hôte de la session Bureau à distance.
Vous pouvez spécifier que l’authentification au niveau du réseau soit requise pour l’authentification
utilisateur à l’aide de l’outil Configuration de l’hôte de la session Bureau à distance ou de l’onglet
Utilisation à distance dans Propriétés système.
Section Composants Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Service
Broker pour les connexions Bureau à distance
● Configurer le nom du serveur du service Broker pour les connexions Bureau à distance
Ce paramètre de stratégie permet de spécifier le serveur du service Broker pour les connexions Bureau
à distance utilisé par le serveur hôte de la session Bureau à distance pour suivre et rediriger les
sessions utilisateur d’une ferme de serveurs hôte de la session Bureau à distance à charge équilibrée.
Le serveur spécifié doit exécuter le service Broker pour les connexions Bureau à distance. Tous les
serveurs hôte de la session Bureau à distance d’une ferme à charge équilibrée doivent utiliser le même
serveur de ce service.
Si vous activez ce paramètre de stratégie, vous devez spécifier le serveur par son nom d’hôte, son
adresse IP ou son nom de domaine complet. Si vous spécifiez un nom ou une adresse IP non valide, un
message d’erreur est enregistré dans l’Observateur d’événements sur le serveur hôte de la session
Bureau à distance.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, vous pouvez définir le nom ou
l’adresse IP du serveur du service Broker pour les connexions Bureau à distance à l’aide de l’outil
Configuration de l’hôte de la session Bureau à distance ou du fournisseur WMI des services Terminal
Server.
Pour Windows Server 2008, ce paramètre de stratégie est pris en charge par Windows Server 2008
Standard et éditions supérieures.
Ce paramètre est effectif uniquement lorsque le paramètre Joindre le service Broker pour les
connexions Bureau à distance est activé ou lorsque le serveur hôte de la session Bureau à distance
est configuré pour se joindre au service Broker pour les connexions Bureau à distance à l’aide de l’outil
Configuration de l’hôte de la session Bureau à distance ou du fournisseur WMI des services Terminal
Server.

Pour être membre actif d’une ferme de serveurs hôte de la session Bureau à distance compatible avec
le service Broker pour les connexions Bureau à distance, le compte d’ordinateur de chaque serveur
hôte de la session Bureau à distance de la ferme doit être membre du groupe local Ordinateurs annuaire
de sessions sur le serveur du service Broker pour les connexions Bureau à distance.
● Configurer le nom de la batterie de serveurs du service Broker pour les connexions Bureau à
distance
Ce paramètre de stratégie permet de spécifier le nom d’une ferme à joindre au service Broker pour les
connexions Bureau à distance. Ce service utilise le nom de la ferme de serveurs pour déterminer les
serveurs hôte de la session Bureau à distance appartenant à la même ferme. Vous devez donc utiliser le
même nom de ferme pour tous les serveurs hôte de la session Bureau à distance qui appartiennent à la
même ferme de serveurs à charge équilibrée. Le nom de la ferme ne doit pas nécessairement
correspondre à un nom des services de domaine Active Directory.
Si vous donnez un autre nom à la ferme, une nouvelle ferme de serveurs est créée dans le service
Broker pour les connexions Bureau à distance. Si vous indiquez le nom d’une ferme existante, le serveur
se joint à cette ferme.
Si vous activez ce paramètre de stratégie, vous devez spécifier le nom d’une ferme dans le service
Broker pour les connexions Bureau à distance.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, le nom de la ferme n’est pas
spécifié dans la stratégie de groupe. Dans ce cas, vous pouvez définir le nom de la ferme à l’aide de
l’outil Configuration de l’hôte de la session Bureau à distance ou du fournisseur WMI des services
Terminal Server.
Ce paramètre est effectif uniquement lorsque les paramètres Joindre le service Broker pour les
connexions Bureau à distance et Configurer le nom du serveur du service Broker pour les
connexions Bureau à distance sont tous deux activés et configurés à l’aide de la stratégie de groupe, de
l’outil Configuration de l’hôte de la session Bureau à distance ou du fournisseur WMI des services Terminal
Server.
● Joindre le service Broker pour les connexions Bureau à distance
Ce paramètre de stratégie permet de spécifier si le serveur hôte de la session Bureau à distance doit se
joindre à une ferme de serveurs du service Broker pour les connexions Bureau à distance. Ce service
réalise le suivi des sessions utilisateur et permet à un utilisateur de se reconnecter à sa session
existante dans une ferme de serveurs hôte de la session Bureau à distance à charge équilibrée. Pour
joindre le service Broker pour les connexions Bureau à distance, le service de rôle de serveur hôte de la
session Bureau à distance doit être installé sur le serveur.
Si le paramètre de stratégie est activé, le serveur hôte de la session Bureau à distance se joint à la
ferme spécifiée dans le paramètre Configurer le nom de la batterie de serveurs du service Broker
pour les connexions Bureau à distance. La ferme existe sur le serveur du service Broker pour les
connexions Bureau à distance spécifié dans le paramètre de stratégie Configurer le nom du serveur du
service Broker pour les connexions Bureau à distance.
Si vous désactivez ce paramètre de stratégie, le serveur ne se joint à aucune ferme de serveurs du
service Broker pour les connexions Bureau à distance et le suivi des sessions utilisateur n’a pas lieu. Si
le paramètre est désactivé, vous ne pouvez pas utiliser l’outil de configuration de l’hôte de la session
Bureau à distance ou le fournisseur WMI des services Terminal Server pour joindre le serveur du service
Broker pour les connexions Bureau à distance.
Si le paramètre de stratégie n’est pas configuré, il n’est pas spécifié au niveau de la stratégie de
groupe. Dans ce cas, vous pouvez configurer le serveur pour qu’il se joigne au service Broker pour les
connexions Bureau à distance à l’aide de l’outil de configuration de l’hôte de la session Bureau à
distance ou du fournisseur WMI des services Terminal Server.
Si vous activez ce paramètre, vous devez également activer les paramètres de stratégie Configurer le
nom de la batterie de serveurs du service Broker pour les connexions Bureau à distance et
Configurer le nom du serveur du service Broker pour les connexions Bureau à distance ou les
configurer à l’aide de l’outil de configuration de l’hôte de session Bureau à distance ou du fournisseur WMI

des services Terminal Server.
● Utiliser l’équilibrage de charge du service Broker pour les connexions Bureau à distance
Ce paramètre de stratégie permet de spécifier s’il convient d’utiliser la fonctionnalité d’équilibrage de
charge du service Broker pour les connexions Bureau à distance pour équilibrer la charge entre les
serveurs d’une ferme de serveurs hôtes de session Bureau à distance.
Si vous activez ce paramètre de stratégie, le service Broker pour les connexions Bureau à distance
redirige les utilisateurs qui n’ont pas de session en cours vers le serveur hôte de session Bureau à
distance dans la ferme de serveurs ayant le moins de sessions. Le comportement de redirection pour les
utilisateurs ayant des sessions en cours n’est pas affecté. Si le serveur est configuré de façon à utiliser
le service Broker pour les connexions Bureau à distance, les utilisateurs ayant une session en cours sont
redirigés vers le serveur hôte de session Bureau à distance où réside leur session.
Si vous désactivez ce paramètre de stratégie, les utilisateurs qui n’ont pas de session en cours se
connectent au premier serveur hôte de session Bureau à distance auquel ils se sont initialement
connectés.
Si vous ne configurez pas ce paramètre de stratégie, vous pouvez configurer le serveur hôte de session
Bureau à distance pour qu’il participe à l’équilibrage de charge du service Broker pour les connexions
Bureau à distance à l’aide de l’outil de configuration d’hôte de session Bureau à distance ou du
fournisseur WMI des services Terminal Server.
Si vous activez ce paramètre de stratégie, vous devez également activer les paramètres de stratégie
Joindre le service Broker pour les connexions Bureau à distance, Configurer le nom de batterie de
serveurs du service Broker pour les connexions Bureau à distance et Configurer le nom de serveur du
service Broker pour les connexions Bureau à distance.
● Utiliser la redirection d’adresse IP
Ce paramètre de stratégie permet de spécifier la méthode de redirection à utiliser lorsqu’un périphérique
client se reconnecte à une session existante des services Bureau à distance dans une ferme de serveurs
hôte de la session Bureau à distance à charge équilibrée. Ce paramètre s’applique à un serveur hôte de
la session Bureau à distance configuré pour utiliser le service Broker pour les connexions Bureau à
distance, et non au serveur de ce service.
Si vous activez ce paramètre de stratégie, un client des services Bureau à distance interroge le service
Broker pour les connexions Bureau à distance, puis il est redirigé vers sa session existante à l’aide de
l’adresse IP du serveur hôte de la session Bureau à distance où elle se trouve. Pour utiliser cette
méthode de redirection, les ordinateurs clients doivent être capables de se connecter directement par
adresse IP aux serveurs hôte de la session Bureau à distance de la ferme.
Si vous désactivez ce paramètre de stratégie, l’adresse IP du serveur hôte de la session Bureau à
distance n’est pas envoyée au client, mais incorporée à un jeton. Lorsqu’un client se reconnecte à
l’équilibreur de charge, le jeton de routage est utilisé pour rediriger le client vers sa session existante
sur le serveur hôte de la session Bureau à distance correct de la ferme. Désactivez ce paramètre
uniquement lorsque votre solution d’équilibrage de charge réseau prend en charge l’utilisation des
jetons de routage du service Broker pour les connexions Bureau à distance et lorsque vous ne voulez
pas que les clients se connectent directement par adresse IP aux serveurs hôte de la session Bureau à
distance de la ferme à charge équilibrée.
Si vous ne configurez pas ce paramètre de stratégie, le paramètre Utiliser la redirection d’adresse IP
de l’outil Configuration de l’hôte de la session Bureau à distance est utilisé. Par défaut, ce paramètre
est activé dans l’outil Configuration de l’hôte de la session Bureau à distance.
Section Composants Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Profils
● Définir le chemin d’accès au profil utilisateur itinérant des services Bureau à distance

Ce paramètre de stratégie permet de spécifier le chemin d’accès réseau utilisé par les services Bureau à
distance pour les profils utilisateur itinérant.
Par défaut, les services Bureau à distance stockent tous les profils utilisateur localement sur le serveur
hôte de la session Bureau à distance. Vous pouvez utiliser ce paramètre de stratégie pour spécifier un
partage réseau qui stocke centralement les profils utilisateur, permettant ainsi à un utilisateur d’accéder
aux mêmes profils pour ses sessions sur tous les serveurs hôte de la session Bureau à distance
configurés pour utiliser le partage réseau contenant les profils utilisateur.
Si vous activez ce paramètre de stratégie, les services Bureau à distance utilisent le chemin d’accès
spécifié en tant que répertoire racine pour tous les profils utilisateur. Les profils sont contenus dans des
sousdossiers nommés d’après le nom de compte de chaque utilisateur.
Pour configurer ce paramètre de stratégie, tapez le chemin d’accès au partage réseau sous la forme
\\NomOrdinateur\NomPartage. Ne spécifiez pas d’espace réservé pour le nom du compte d’utilisateur,
car les services Bureau à distance l’ajoutent automatiquement lorsque l’utilisateur ouvre une session et
que le profil est créé. Si le partage réseau spécifié n’existe pas, les services Bureau à distance affichent
un message d’erreur sur le serveur hôte de la session Bureau à distance et stockent les profils
utilisateur localement sur le serveur hôte de la session Bureau à distance.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, les profils utilisateur sont stockés
localement sur le serveur hôte de la session Bureau à distance. Vous pouvez configurer le chemin
d’accès au profil d’un utilisateur sur l’onglet Profil des services Bureau à distance de la boîte de dialogue
Propriétés du compte de l’utilisateur.
Les profils utilisateur itinérant activés par ce paramètre de stratégie s’appliquent uniquement aux
connexions des services Bureau à distance. Un utilisateur peut également posséder un profil utilisateur
itinérant Windows configuré. Le profil utilisateur itinérant des services Bureau à distance a toujours priorité
dans une session des services Bureau à distance.
Pour configurer un profil utilisateur itinérant obligatoire des services Bureau à distance pour tous les
utilisateurs qui se connectent à distance au serveur hôte de la session Bureau à distance, utilisez ce
paramètre de stratégie en même temps que le paramètre de stratégie Utiliser les profils obligatoires sur
le serveur hôte de la session Bureau à distance situé dans Configuration ordinateur\Modèles
d’administration\Composants Windows\Services Bureau à distance\Hôte de la session Bureau à
distance\Profils. Le chemin d’accès défini dans le paramètre de stratégie Définir le chemin d’accès au
profil utilisateur itinérant des services Bureau à distance doit contenir le profil obligatoire.
Section Système\Délégation d’informations d’identification
Cette série de paramètres de stratégie s’adresse aux applications utilisant le composant Cred SSP (Security
Suppport Provider) tel que les services Bureau à distance).
Section Système\Profil des utilisateurs
● Nombre maximal de tentatives de déchargement et de mise à jour du profil utilisateur
Détermine combien de fois le système essaie de décharger et de mettre à jour la partie Registre d’un
profil utilisateur. Quand le nombre de tentatives spécifié par ce paramètre est atteint, le système cesse
d’essayer. En conséquence, il est possible que le profil utilisateur ne soit pas à jour et que les profils
utilisateur local et itinérant ne correspondent pas.
Quand un utilisateur ferme une session sur l’ordinateur, le système décharge la partie du Registre
relative à l’utilisateur (HKEY_CURRENT_USER) vers un fichier (NTUSER.DAT) et le met à jour. Cependant,
si un autre programme ou service effectue une lecture ou une modification du Registre, le système ne
peut pas le décharger. Le système essaie plusieurs fois (avec une fréquence d’une fois par seconde) de
décharger et de mettre à jour les paramètres du Registre. Par défaut, le système répète ces tentatives
périodiques 60 fois (donc pendant une minute).
Si vous activez ce paramètre, vous pouvez régler le nombre de fois que le système essaie de décharger
et de mettre à jour les paramètres du Registre pour l’utilisateur (vous ne pouvez pas modifier la
fréquence des tentatives).
Si vous désactivez ce paramètre ou ne le configurez pas, le système répète ses tentatives 60 fois.
Si vous définissez le nombre de tentatives à 0, le système n’effectue la tentative qu’une seule fois. Il ne
réessaie pas.

● Supprimer les copies de mise en cache des profils itinérants
Détermine si le système enregistre une copie du profil itinérant de l’utilisateur sur le disque dur de
l’ordinateur lorsque l’utilisateur ferme sa session.
Ce paramètre, ainsi que les paramètres associés de ce dossier, décrivent ensemble une stratégie de
gestion des profils utilisateur résidant sur des serveurs distants. En particulier, elles indiquent au
système comment répondre lorsqu’un profil distant est lent à charger.
Les profils itinérants résident sur un serveur réseau. Par défaut, lorsque des utilisateurs avec des profils
itinérants ferment leur session, le système enregistre également une copie de leur profil itinérant sur le
disque dur de l’ordinateur qu’ils utilisent, dans le cas où le serveur qui stocke le profil itinérant est
indisponible lors de l’ouverture de session suivante. La copie locale est également utilisée quand la
copie distante du profil utilisateur itinérant est lente à charger.
Si vous activez ce paramètre, toutes les copies locales du profil itinérant de l’utilisateur sont supprimées
quand l’utilisateur ferme sa session. Le profil itinérant est conservé sur le serveur réseau qui le stocke.
N’activez pas ce paramètre si vous utilisez la fonction de détection des liens lents de Windows 2000
Professionnel et de Windows XP Professionnel. Pour répondre à un client lent, l’ordinateur nécessite
une copie locale du profil itinérant de l’utilisateur.
Section Configuration ordinateur\Modèles d’administration\Composants Windows\Services Bureau à

distance\Hôte de la session Bureau à distance\Environnement de session à distance
Cette série de paramètres de stratégie permettent d’activer les nouvelles fonctionnalités RemoteFX apportées
par le Service Pack 1
● Configurer RemoteFX
● Optimiser l’expérience visuelle pour les sessions de service bureau à distance
● Optimiser l’expérience visuelle lors de l’utilisation de RemoteFX
Section Configuration ordinateur\Modèles d’administration\Composants Windows\Services Bureau à

distance\Client Connexion bureau à distance\Redirection de périphérique USB RemoteFX
Ce paramètre de stratégie permet d’activer la redirection des périphériques USB RemoteFX dans une machine
virtuelle Windows 7 avec le Service Pack 1
● Autoriser la redirection de protocole RDP des autres périphériques USB RemoteFX pris en charge à
partir de cet ordinateur
Les stratégies utilisateur
Vous trouverez cidessous une liste des stratégies les plus intéressantes impactant sur le comportement global
de l’utilisateur.
Section Composants Windows\Services Bureau à distance\Passerelle des services Bureau à distance
● Définir la méthode d’authentification de la passerelle des services Bureau à distance
Spécifie la méthode d’authentification que les clients doivent utiliser lors des tentatives de connexion à
un serveur hôte de la session Bureau à distance via un serveur de passerelle Bureau à distance. Vous
pouvez forcer l’application de ce paramètre de stratégie ou permettre aux utilisateurs de le remplacer.
Par défaut, lorsque vous activez ce paramètre de stratégie, il est appliqué. Dans ce cas, les utilisateurs
ne peuvent pas le remplacer, même en sélectionnant l’option Utiliser ces paramètres de serveur de
passerelle Bureau à distance sur le client.
Pour permettre aux utilisateurs de remplacer ce paramètre de stratégie, activez la case à cocher
Autoriser les utilisateurs à modifier ce paramètre. Dans ce cas, les utilisateurs peuvent spécifier une
autre méthode d’authentification en configurant les paramètres sur le client, en utilisant un fichier RDP
ou en recourant à un script HTML. Si les utilisateurs ne spécifient pas d’autre méthode d’authentification,
celle qui est spécifiée dans ce paramètre de stratégie est utilisée par défaut.

Si vous désactivez ce paramètre de stratégie ou si vous ne le configurez pas, la méthode
d’authentification spécifiée par l’utilisateur est utilisée le cas échéant. Si aucune méthode
d’authentification n’est spécifiée, le protocole NTLM (NT Lan Manager) activé sur le client ou une carte à
puce peut servir à l’authentification.
● Activer la connexion via une passerelle des services Bureau à distance
Si vous activez ce paramètre de stratégie, lorsque Connexion Bureau à distance ne parvient pas à se
connecter directement à un ordinateur distant (un serveur hôte de la session Bureau à distance ou un
ordinateur sur lequel Bureau à distance est activé), les clients tentent de se connecter à l’ordinateur
distant par l’intermédiaire d’un serveur de passerelle Bureau à distance. Dans ce cas, les clients tentent
de se connecter au serveur de passerelle Bureau à distance spécifié dans le paramètre de stratégie
Définir l’adresse du serveur de passerelle Bureau à distance.
Vous pouvez appliquer ce paramètre de stratégie ou permettre aux utilisateurs de le remplacer. Par
défaut, lorsque vous activez ce paramètre de stratégie, il est appliqué. Dans ce cas, les utilisateurs ne
peuvent pas le remplacer, même en sélectionnant l’option Utiliser ces paramètres de serveur de
passerelle Bureau à distance sur le client.
Pour permettre aux utilisateurs de remplacer ce paramètre de stratégie, activez la case à cocher
Autoriser les utilisateurs à modifier ce paramètre. Dans ce cas, les utilisateurs du client peuvent
choisir de ne pas se connecter par l’intermédiaire de la passerelle des services Bureau à distance en
sélectionnant l’option Ne pas utiliser un serveur de passerelle Bureau à distance. Les utilisateurs
peuvent spécifier une méthode de connexion en configurant des paramètres sur le client, en utilisant un
fichier RDP ou en recourant à un script HTML. Si les utilisateurs ne spécifient pas de méthode de
connexion, celle qui est spécifiée dans ce paramètre de stratégie est utilisée par défaut.
Si vous désactivez ce paramètre de stratégie ou si vous ne le configurez pas, les clients n’utilisent pas
l’adresse du serveur de passerelle Bureau à distance spécifiée dans le paramètre de stratégie Définir
l’adresse du serveur de passerelle Bureau à distance. Si un serveur de passerelle Bureau à distance
est spécifié par l’utilisateur, une tentative de connexion du client est effectuée par l’intermédiaire de ce
serveur de passerelle Bureau à distance.
● Définir l’adresse du serveur de passerelle Bureau à distance
Spécifie l’adresse du serveur de passerelle Bureau à distance que les clients doivent utiliser lors des
tentatives de connexion à un serveur hôte de la session Bureau à distance. Vous pouvez forcer
l’application de ce paramètre de stratégie ou permettre aux utilisateurs de le remplacer. Par défaut,
lorsque vous activez ce paramètre de stratégie, il est appliqué. Dans ce cas, les utilisateurs ne peuvent
pas le remplacer, même en sélectionnant l’option Utiliser ces paramètres de serveur de passerelle
Bureau à distance sur le client.
Pour autoriser les utilisateurs à remplacer le paramètre de stratégie Définir l’adresse du serveur de
passerelle Bureau à distance et à se connecter à un autre serveur de passerelle Bureau à distance,
vous devez activer la case à cocher Autoriser les utilisateurs à modifier ce paramètre et les
utilisateurs sont alors autorisés à spécifier un autre serveur de passerelle Bureau à distance. Les
utilisateurs peuvent spécifier un autre serveur de passerelle Bureau à distance en configurant des
paramètres sur le client, en utilisant un fichier RDP ou en recourant à un script HTML. Si les utilisateurs
ne spécifient pas d’autre serveur de passerelle Bureau à distance, le serveur spécifié dans ce paramètre
de stratégie est utilisé par défaut.

distance\Connexions
● Définir les règles pour le contrôle à distance des sessions utilisateur des services Bureau à distance
Ce paramètre de stratégie vous permet de spécifier le niveau de contrôle à distance autorisé dans une
session de services Bureau à distance.
Vous pouvez utiliser ce paramètre de stratégie pour sélectionner l’un des deux niveaux de contrôle à
distance : Afficher la session ou Contrôle total. Afficher la session permet à l’utilisateur du contrôle à
distance de consulter une session. Contrôle total permet à l’administrateur d’interagir avec la session.
Le contrôle à distance peut être établi avec ou sans l’autorisation de l’utilisateur.
Si vous activez ce paramètre de stratégie, les administrateurs peuvent interagir à distance avec la
session de services Bureau à distance d’un utilisateur selon les règles spécifiées. Pour définir ces règles,
sélectionnez le niveau de contrôle et l’autorisation souhaités dans la liste des options. Pour désactiver le
contrôle à distance, sélectionnez Aucun contrôle à distance autorisé.
Si vous désactivez ce paramètre de stratégie ou ne le configurez pas, les règles de contrôle à distance

sont déterminées par le paramètre de l’onglet Contrôle à distance dans l’outil Configuration de l’hôte
de la session Bureau à distance. Par défaut, les utilisateurs du contrôle à distance disposent du contrôle
total de la session avec l’autorisation de l’utilisateur.
utilisateur. Si les deux paramètres de stratégie sont configurés, le paramètre de stratégie

Stratégies d’accès et sécurité du système
Microsoft introduit dès Windows Server 2008 de nombreuses nouvelles fonctionnalités et technologies dont les
principaux objectifs sont d’améliorer le niveau de sécurité des systèmes fonctionnant sous Windows. L’approche
retenue pour cela, par les architectes de Microsoft, est de ne minimiser aucun des aspects qui permettent de
renforcer la sécurité de l’ensemble de l’infrastructure du système d’information.
1. Nouvelle version du noyau NT
Windows Server 2008 et Windows Vista intégraient déjà une nouvelle version du noyau NT qui passa alors en
version 6.0. La version station de travail et la version serveur de ce nouveau système d’exploitation partagent
une grande partie de leur code. Cette stratégie de développement, qui est en vigueur depuis NT, permet de
garantir un haut niveau de compatibilité et de fonctionnalités, tout en assurant un niveau de maintenance et de
support homogène entre les serveurs et l’ensemble des postes de travail du réseau. Ainsi, tous les systèmes de
la même famille ont les mêmes fondamentaux et peuvent être gérés de manière uniforme avec les mêmes outils
et, plus ou moins, les mêmes connaissances. Suivant le même principe de conception et de développement, les
grandes améliorations apportées à Windows Vista en matière de sécurité se retrouvent également dans
Windows 2008.
Il en est de même pour la version serveur de Windows 2008 R2 et sa version jumelle déclinée en système
d’exploitation pour station de travail, à savoir Windows 7. Avec cette nouvelle version, le noyau NT passe en
version 6.1.
Du point de vue du système et de son noyau, les équipes de développement de Microsoft utilisent depuis
Windows Server 2003 un cycle de développement sécurisé (Security Development Livecycle). Celuici est
représenté, entre autre, par l’acronyme SD3+C. Celuici signifie « Secure by Design, Secure by Default, Secure in
Deployment and Communication ».
Les principes de moindre privilège et d’organisation des services en couches ont donc largement guidé les
derniers développements dès Windows Server 2008.
2. Restriction des comptes de services
Il existe désormais des SID associés aux services qui garantissent que l’identité utilisée est vraiment privée. Les
accès aux ressources nécessaires à un service sont directement pris en charge par celuici, lequel se charge
d’appliquer les bonnes permissions. Cette fonctionnalité est très intéressante car il n’est désormais plus du
ressort de l’administrateur de configurer les permissions des ressources critiques pour les limiter au strict
nécessaire.
3. Environnement d’exécution des programmes
Windows Server 2008 R2 utilise un nouveau système de gestion de la sécurité de l’environnement d’exécution
des programmes. Cette fonctionnalité appelée Windows Integrity Control (WIC), protège le système
d’exploitation de l’exécution de code de faible confiance. En fait, WIC rajoute un niveau de contrôle d’intégrité
supplémentaire aux permissions habituellement déclarées à l’aide des listes de contrôles d’accès (ACL).
WIC affecte un niveau d’intégrité aux utilisateurs et aux objets de telle sorte qu’il est possible d’avoir un niveau
de distinction supplémentaire, en plus du niveau de privilèges habituel. Lorsqu’une ressource est accédée, le
niveau d’intégrité de l’appelant est comparé à celui de l’objet. Si le niveau de l’appelant est inférieur à celui de
l’objet alors les opérations d’écriture ou d’effacement sont interdites. Ces contrôles sont prioritaires puisqu’ils ont
lieu avant même la vérification des ACL. Dans le cas où les ACL accorderaient plus de privilèges, le contrôle WIC
interdit l’opération si l’appelant dispose d’un niveau d’intégrité inférieur à celui de l’objet.
4. Authentifications IPsec et support de NAP

Dans les versions précédentes de Windows, l’association de sécurité IPsec était négociée à l’aide du protocole
IKE (Internet Key Exchange). Windows 2008 R2 intègre, et ce depuis la version 2008, le protocole Authenticated
IP (AuthIP) qui ajoute des méthodes d’authentification supplémentaires permettant la prise en charge de NAP
(Network Access protection). L’usage de certificats utilisateur, le support de l’authentification Kerberos et NTLMv2
pour les ordinateurs et les utilisateurs sont également au programme. Toutes ces évolutions permettent
d’authentifier les flux IPsec dans le contexte de l’utilisateur et plus uniquement dans celui de la machine (sous
Windows Server 2003, le protocole IKE ne supporte que les certificats de type ordinateur, l’authentification
Kerberos des comptes d’ordinateur et les clés de type secret partagé).

Gestion des impressions
Afin de bien comprendre tout l’intérêt que peut présenter la mise en œ uvre de RD Easy print, il me paraît important
de faire un rappel sur la problématique des impressions dans un environnement TSE/RDS et quelles sont les
solutions disponibles à ce jour.
Avant d’aborder la problématique des pilotes d’impression, il paraît judicieux de repréciser le fonctionnement des
impressions Windows, et par extension, celles sous TSE et RDS :
Les impressions sous Windows
Elles peuvent se découper en trois phases :
● Phase 1 : Application Windows
Génération des données EMF (flux natif)
● Phase 2 : Soussystème d’impression
Conversion EMF vers RAW
● Phase 3 : L’impression
Les données transformées sont transférées vers le périphérique d’impression.
L’application Windows génère ellemême les données à imprimer, c’estàdire la vue du document, à l’aide des
fonctions GDI.
Le GDI va générer un métafichier au format EMF représentant le document à imprimer. Ce fichier EMF est rapide à
générer, indépendant de l’imprimante et nécessite peu d’espace.
Le soussystème d’impression réceptionne les données EMF.
Il détermine si l’imprimante est réseau ou locale.
Le fichier EMF est converti au format RAW (spécifique à l’imprimante) à l’aide des pilotes d’impressions.
Les données sont positionnées dans le serveur d’impression.
Les données sont transférées du serveur d’impression vers l’imprimante (cas d’une imprimante locale).
Les impressions sous TSE et RDS
Le fonctionnement global est identique, cependant il convient de distinguer deux cas (accès depuis le serveur ou
depuis le client) :
Accès depuis le serveur (imprimantes déclarées sur le serveur RDS) :
● Imprimantes locales (lpt, usb, tcpport...)

● Imprimantes réseau accessibles depuis un partage (\\NomduServeur\NomDuPartage)
Le fichier d’impression est créé sur le serveur (étapes 1 à 3).
Le travail est ensuite routé vers le serveur d’impression (4).
Conversion RAW et Transfert vers l’imprimante (5 et 6).
Avantages
● Bonne performance si le serveur d’impression est sur le même LAN que l’imprimante
● Fiabilité
● Pas de distinction entre les clients légers (terminaux) et les clients lourds (PC)
● Flux d’impression distinct du flux RDP (Qos Possible)
Inconvénients
● Paramétrage de l’imprimante selon le client
● Contrainte LAN/WAN
Accès depuis le Client (imprimantes remappées) :
● Imprimantes connectées directement au poste de travail

● Imprimantes réseau
Avantage
● L’imprimante apparaît directement dans la session Bureau à distance de l’utilisateur sans paramétrage
spécifique.
Inconvénients
● Données d’impression créées sur le serveur RDS
● File d’attente d’impression gérée par le serveur RDS (problèmes de charge et de pilotes)
Les données RAW transitent dans le flux RDP au travers d’un canal virtuel.
À ce stade de la lecture, il serait tentant d’aller au plus simple et de se contenter d’activer la redirection des
imprimantes locales dans la session RDS. Cependant, dans la vraie vie, tout n’est pas aussi simple. En effet, pour
que la redirection des imprimantes locales du client dans la session RDS fonctionne, le même pilote doit être
présent sur le client ET sur le serveur. Là où le problème se corse, c’est lorsque le pilote du client n’existe pas pour
le système d’exploitation du serveur ou pire qu’il le rende instable (les écrans bleus furent monnaies courantes
avec des pilotes fonctionnant en mode noyau). Afin de contourner le problème, de nombreux éditeurs (Thinprint,
Citrix, Systancia et même Microsoft) proposent aujourd’hui des pilotes dits universels.
Afin de bien comprendre en quoi ces pilotes sont universels, un petit tour d’horizon des solutions existantes
s’impose :
Tout d’abord, le terme universel signifie que l’utilisateur est en mesure d’imprimer sur la majorité des modèles
d’imprimantes. La plupart des pilotes dits universels utilisent une des trois techniques suivantes :

Imprimante universelle basée sur un pilote générique(solution quasiment obsolète aujourd’hui) :
Ce type de pilotes est le premier à avoir fait son apparition (avec Citrix Metaframe ou plus récemment Microsoft
avec son « fallback driver ») et s’appuie en fait sur un pilote HP Laserjet 4 pour le Noir&Blanc et sur un HP Laserjet
4500 pour la couleur.
Dans les faits, cette technique n’a d’universelle que le nom car il s’agit surtout d’un pilote de substitution.
L’inconvénient majeur de cette technique est que le pilote propose un paramétrage minimaliste, ce qui peut être
frustrant quand on vient d’acheter le dernier modèle multifonctions.
Imprimante universelle basée sur le format EMF :
Ce type d’imprimante s’appuie sur un concept simple qui consiste à dire : « pourquoi transférer un fichier RAW
alors que l’on pourrait transférer un fichier EMF ». Pour bien comprendre le fonctionnement, prenons l’exemple de
la solution d’imprimante universelle proposée par l’éditeur Systancia dans son produit Applidis Universal Printer.
Impressions vers l’imprimante Applidis installée sur le serveur RDS (1 et 2).
Le flux d’impressions est capté par l’imprimante (3).
Les données d’impressions sont compressées et transférées par le driver « Applidis Universal Printer » vers le

client, via le canal RDP (5).
Le client Applidis reçoit le flux et rejoue l’impression sur le client vers l’imprimante souhaitée (6).
Avantages
● Une seule imprimante installée sur le serveur RDS.
● Utilisation des pilotes d’impressions locaux au client (avec toutes les fonctionnalités).
Inconvénients
● Nécessite un client Windows ou un terminal évolué.
● Solution utilisable uniquement sur la plateforme Microsoft (Format EMF).
Imprimante universelle basée sur le format PDF
La dernière solution fonctionne sensiblement comme la précédente si ce n’est qu’elle utilise le format Adobe PDF.
Le fichier EMF est transformé en PDF sur le serveur, puis envoyé au client qui le retransforme avant de l’imprimer.
Avantages
● Format disponible sur la majorité des systèmes.
● Taille des fichiers générés inférieurs au format EMF.
Inconvénients
● Perte de qualité liée à la compression PDF.
● Options d’impressions limitées à celles disponibles sur le pilote utilisé.
Maintenant que les impressions dans un environnement RDS et les solutions disponibles n’ont plus de secret pour
vous, vous comprenez probablement mieux pourquoi foncer tête baissée dans la mise en place de son
infrastructure RDS, sans y intégrer une réflexion de fond sur son système d’impression risque de plomber les
performances finales du système.

Gestion des applications
La gestion des applications avec RDS 2008 R2 n’est pas de tout repos. En effet, contrairement à ce que l’on trouve
avec des éditeurs tels que Citrix ou encore Systancia, RDS 2008 R2 pêche par la faiblesse de ses outils
d’administration. En fait, la mise en œ uvre d’applications nécessite de solides connaissances Active Directory, et
plus particulièrement la maîtrise des stratégies de groupe. Certes, Microsoft semble combler petit à petit ses
lacunes faces aux éditeurs, en intégrant notamment des possibilités de publication d’application selon
l’appartenance aux groupes comme décrit dans le chapitre Services Bureau à distance 2008 R2 Avancées
technologiques du portail web (RD Web Access) sur la publication via le portail RD Web Access.
Le déploiement d’une application sous Windows 2008 R2 devra alors suivre les étapes suivantes :
● Installer de manière identique les applications sur tous les serveurs de la Ferme.
● Publier l’application dans le gestionnaire RemoteAPP sur un des serveurs de la Ferme.
● Exporter les paramètres RemoteApp vers les autres serveurs de la Ferme.
● Générer les packages de distribution (fichier rdp ou package MSI).
● Dans le cas d’un déploiement par l’Active Directory, mettre en œ uvre une stratégie de groupe pour
l’installation des applications sur les postes clients.
L’administration quotidienne n’est pas des plus simples non plus, la faute là encore aux outils d’administration qui
ne permettent pas de gérer, de manière centralisée, les applications déployées dans la ferme et encore moins de
savoir facilement quels utilisateurs exploitent telle ou telle application, si ce n’est via la console du gestionnaire de
passerelle Bureau à distance (à la condition qu’il l’utilise) ou via la console Gestionnaire des services Bureau à
distance mais qui liste la totalité des processus en cours (à vous de faire le tri).
En outre, il n’existe pas non plus d’outils permettant de visualiser la charge des différents serveurs, ni même
d’obtenir des statistiques afin d’effectuer des rapports d’utilisation. Il n’est pas possible non plus d’interroger le
Connection Broker de manière simple et efficace afin d’en connaître le contenu, ni même d’effectuer
dynamiquement son paramétrage.
Enfin, les prérequis nécessaires pour les clients (PC ou terminaux) sont également un frein à l’adoption de cette
nouvelle mouture, imposant un parc relativement neuf et totalement à jour.

PowerShell
1. Introduction
Windows PowerShell, anciennement Microsoft Command Shell MSH, (nom de code Monad) est une interface en
ligne de commande et un langage de script développé par Microsoft. Il est basé sur la programmation orientée
objet et le Framework Microsoft .NET.
PowerShell est un langage de script orienté objet qui s’apparente plus à Perl qu’à des langages de Shell, comme
bash. Il n’y a aucune ressemblance entre le PowerShell et le très simpliste langage batch hérité de MSDOS qui, il
faut bien l’avouer, faisait pâle figure face au Shell UNIX.
Les buts de PowerShell sont multiples : être au moins égal sinon meilleur que le Shell UNIX, avoir une
interopérabilité et une compatibilité avec les commandes et les scripts existants, une meilleure sécurité, une
navigation approfondie (système de fichiers, base de registre, partage réseau...) et bien d’autres encore.
2. Fonctionnement
Le PowerShell inclut ce que l’on appelle les cmdlets (prononcer commandlets) qui peuvent être simplement
décrits comme des commandes.
Les cmdlets diffèrent des commandes des autres environnements de Scripting sur de nombreux points :
● Ce sont des instances d’une classe .NET et pas de simples exécutables.
● Ils peuvent être créés avec très peu de lignes de code.
● Des attributs sont employés pour identifier les paramètres d’entrée ou pour gérer les redirections
(pipeline « | »).
● Des API sont proposées pour gérer l’affichage ou les erreurs.
● Ils manipulent et fournissent des objets, plutôt que des flux (texte), en entrée et en sortie.
● Ils sont orientés enregistrement, traitant un seul objet à la fois.
Pour avoir la liste des cmdlets (la liste est longue), il suffit d’utiliser getcommand :

Par exemple getprocess [as]* retourne la liste des processus allant de a à s.
3. Règle de nommage
La règle de nommage est simple et consiste en la composition d’un verbe et d’un nom, le tout séparé par un tiret
().

Les noms représentent des ressources du système : ils identifient le type d’objets sur lequel on opère. Pour
nommer un cmdlet, il faut choisir de préférence des noms de substantifs spécifiques et éviter l’utilisation de noms
génériques qui risquent fort d’être déjà employés par PowerShell : Alias, Children, Command, Content, Drive,
History, Item, Location, Object, Property, PropertyValue, Provider, RunSpace, Variable.
Le verbe identifie l’action que le cmdlet effectue : les concepteurs de PowerShell ont souhaité que les
administrateurs système puissent effectuer 80 à 90 % des opérations sur le système en utilisant moins de 50
verbes. Cette logique permet d’apprendre, voire de deviner, rapidement quelles combinaisons utiliser sur un
nouvel objet.
4. Exécution de Scripts Powershell
Tout d’abord un détail important, l’extension d’un script Powershell est .ps1. Ensuite, pour exécuter un script
dans la console, il faut composer avec les paramètres de sécurité sans quoi l’exécution d’un script donne le
résultat suivant :
En fait, la couche de sécurité intègre un élément appelé politique d’exécution, qui est positionné par défaut sur
Resctricted (restreint), empêchant l’exécution des scripts.
La commande GetExecutionPolicy permet de visualiser le niveau de sécurité actuel.
Le niveau de sécurité peut être positionné avec la commande SetExecutionPolicy et prendre les valeurs
suivantes :
Restricted
● Stratégie d’exécution par défaut.
● Autorise l’exécution de commandes individuelles, mais pas de scripts.
AllSigned
● Les scripts peuvent être exécutés.
● Requiert la signature numérique d’un éditeur approuvé sur tous les scripts et fichiers de configuration, y
compris les scripts que vous écrivez sur l’ordinateur local.
● Vous demande confirmation avant d’exécuter des scripts provenant d’éditeurs approuvés.
● Risque d’exécuter des scripts signés, mais malveillants.
RemoteSigned
● Les scripts peuvent être exécutés.

● Requiert la signature numérique d’un éditeur approuvé sur les scripts et fichiers de configuration
téléchargés à partir d’Internet (y compris les programmes de messagerie électronique et de messagerie
instantanée).
● Ne requiert pas de signatures numériques sur les scripts exécutés depuis l’ordinateur local.
● Ne vous demande pas de confirmation avant d’exécuter des scripts provenant d’éditeurs approuvés.
Unrestricted
● Les scripts non signés peuvent être exécutés.
● Les scripts et fichiers de configuration téléchargés à partir d’Internet (y compris Microsoft Outlook,
Outlook Express et Windows Messenger) sont exécutés après que vous êtes informés de leur
provenance.
● Risque d’exécuter des scripts malveillants.
Un autre élément déroutant au premier abord est qu’il faut spécifier le chemin complet vers le script pour
procéder à son exécution même si l’on est déjà positionné dans le bon répertoire (ou préfixer le « .\ », un peu
comme le fait le shell UNIX avec « ./ »). Dans le cas contraire, l’erreur ciaprès se produit :
Enfin, l’exécution d’un script ou d’un cmdlet peut également se faire sans démarrer la console PowerShell.
L’option noexit permet de ne pas fermer automatiquement la fenêtre d’exécution à la fin de la commande.

5. PowerShell et WMI
L’accès à WMI est aussi simple que sous VBScript. PowerShell s’appuie sur le référentiel WMI afin d’accéder aux
ressources physiques.
Par exemple, la commande GetWmiObject sur la classe win32_logicaldisk permet d’afficher les disques
logiques de la machine puis le pipe redirige le résultat vers la commande formattable qui met en forme le
résultat :
Ce rapide aperçu du PowerShell incitera, je l’espère, un maximum d’administrateurs à s’y mettre. Bien qu’il ne soit
jamais facile de passer à un nouveau langage, celuici présente l’immense intérêt d’être utilisable pour gérer la
plupart des nouveaux produits Microsoft tels que : Exchange Server 2007 et 2010, System Center Operation
Manager 2007, System Center Data Protection Manager V2, et bien sûr Windows 2008 et Windows 2008 R2 !

Méthodologie globale
Implémenter une architecture clients légers basée sur RDS reste le plus souvent un projet important pour
l’entreprise (nous excluons volontairement les cas de mise en œ uvre de serveurs unitaires ou monoapplicatifs
simples). (En effet, agissant sur l’environnement de travail d’un ensemble généralement important d’utilisateurs, et
nécessitant un ensemble de serveurs fonctionnels périphériques (Active Directory, serveurs de fichiers, Connection
Broker, RDLM, etc.), l’impact en termes de changement pour le système d’information global est imposant.)
Il convient dès lors d’aborder un tel projet avec une méthodologie de gestion de projet informatique adaptée.
La méthodologie présentée ciaprès n’est ni miraculeuse, ni unique, mais a le mérite d’être très simple. À défaut
d’une méthode plus élaborée, celleci nous permettra de la décliner en fonction des spécificités des architectures
RDS. Elle a été mise à profit avec succès dans de nombreuses entreprises de tailles diverses.
1. Phases du projet
Le projet global peut être abordé et découpé en six phases distinctes :
● Phase I : Analyse Contextuelle
● Phase II : Spécifications Fonctionnelles
● Phase III : Maquette Fonctionnelle
● Phase IV : Pilote Opérationnel
● Phase V : Mise en Production
● Phase VI : Exploitation
Phase I : Analyse Contextuelle
L’analyse contextuelle n’est pas une phase informatique du projet. Son objectif est de connaître les tenants et
les aboutissants d’un projet de mise en œ uvre d’une architecture clients légers, et d’en déterminer les intérêts
pour l’entreprise, tant technique qu’humain et financier.
Cette phase est souvent minimaliste, voire ramenée à une approche commerciale, ce qui est bien dommage. Elle
devrait au contraire prendre toute sa valeur, voire faire l’objet d’un véritable audit, ce qui permettrait de
n’engager les phases suivantes qu’en ayant préalablement compris pourquoi.
Phase II : Spécifications Fonctionnelles
Cette phase est la première phase technique, mais ne porte a priori pas sur la manipulation de machines ou de
systèmes : il s’agit d’une autre phase d’analyse, technique cette foisci, mais toujours papier, qui vise à
déterminer l’architecture globale de la solution envisagée, les composants et technologies qui la composent,
leurs interactions, les prérequis et/ou les contraintes, les méthodes d’intégration, etc.
Cette phase doit permettre un rebouclage avec la première, particulièrement dans l’analyse financière, qui peut
avoir subi de graves dérapages et conduire à la disparition de l’intérêt même du projet.
Le périmètre technique du projet peut prendre une telle ampleur que, outre les aspects financiers, le temps
global de réalisation du projet peut lui aussi être rédhibitoire.
Dès lors, à cette phase de projet, une dimension nouvelle voit le jour : la segmentation en différentes étapes
techniquement, financièrement et contextuellement réalistes. À défaut, le projet s’arrête.
La manipulation de machines ou systèmes n’est donc pas obligatoire, sauf si l’on n’est pas familier avec ces
architectures et ces technologies : il est toujours plus facile d’appréhender une fonctionnalité en la visualisant
et/ou la manipulant. Dans ce cas, on peut parler d’une manipulation technique s’apparentant plus à de la

démonstration qu’autre chose.
Si le service informatique (ou un tiers prestataire) mène habituellement cette phase de projet, l’implication des
utilisateurs stratégiques (chefs de services ou de départements par exemple) est toujours préférable.
A minima, une connaissance exhaustive des habitudes de travail, de l’infrastructure existante et de ses
spécificités ainsi que des cas particuliers (techniques ou humains) est essentielle pour mener à bien cette phase
de projet.
Phase III : Maquette fonctionnelle
À ce stade, nous sommes désormais certains que la mise en œ uvre d’une architecture clients légers est
intéressante et réalisable au sein de l’entreprise. Il convient de mettre en œ uvre cette infrastructure afin d’en
déterminer les paramètres et de résoudre les éventuelles (mais fréquentes…) difficultés techniques et d’éviter les
derniers écueils.
La maquette est donc une simulation de l’architecture globale réalisée par le seul service informatique (ou un
tiers prestataire).
Elle permet enfin d’affiner les premières approches budgétaires, notamment par la réalisation d’un plan de
montée en charge qui saura aboutir au choix des configurations matérielles adaptées. Comme toujours, un
rebouclage avec l’étape précédente et une analyse des écarts sont primordiaux.
Un échec de la maquette n’est pas un échec du projet, mais plutôt une réussite : s’il peut éventuellement mettre
en évidence une carence de la phase précédente (souvent du fait de la non exhaustivité des informations
fournies ou de spécificités techniques de l’existant), il permet surtout de ne pas avoir engagé l’entreprise dans
une impasse annoncée.
Phase IV : Pilote opérationnel
Le pilote opérationnel implique directement quelques utilisateurs de l’entreprise. C’est une phase de pingpong
entre les utilisateurs du pilote, qui testent en conditions réelles la nouvelle infrastructure, et le service
informatique qui intervient pour affiner le paramétrage.
C’est une phase de rédaction et validation des procédures techniques (qui auront pu être entamées lors de la
phase précédente), ainsi que de validation des configurations matérielles définitives.
Enfin, il est préférable de ne pas se fixer de contraintes temporelles lors de cette phase : elle doit durer le temps
nécessaire et suffisant. C’est la dernière phase de sécurité avant l’investissement global et la mise en
production.
Phase V : Mise en production
Phase technique d’installation des machines et des systèmes, et phase stratégique car impactant un ensemble
plus ou moins important d’utilisateurs, pour une durée que l’on souhaite toujours la plus courte possible mais qui
peut s’avérer importante quand même.
Elle peut être de type bascule, donc quasiponctuelle, ou au contraire progressive, donc étalée dans le temps
selon une stratégie prédéterminée (du fait de contraintes techniques ou organisationnelles).
Cette phase s’accompagne souvent d’un plan de formation des utilisateurs, ou a minima d’information des
utilisateurs. Les ressources en assistance (technique ou à destination des utilisateurs) ne doivent pas être sous
estimées, particulièrement dans le cadre d’un projet d’architecture clients légers, très perturbant pour les
utilisateurs finaux.
Phase VI : Exploitation
C’est la phase classique de fonctionnement de l’infrastructure, portant tant sur l’administration des serveurs et
des systèmes que sur l’assistance aux utilisateurs, ou de l’évolution de l’infrastructure.

Un bilan du projet avec l’analyse des écarts est toujours bénéfique : s’il ne constitue pas nécessairement une
phase en tant que telle, il permet de connaître les erreurs ou problèmes rencontrés afin de mieux les éviter lors
du prochain projet.
Approche financière parallèle
Aux six phases élémentaires de gestion de projet, il conviendrait d’intercaler deux, voire trois étapes financières :
● Phase I : Analyse Contextuelle
● Phase II : Spécifications Fonctionnelles
■ Investissement partiel minimal
● Phase III : Maquette Fonctionnelle
■ Investissement partiel
● Phase IV : Pilote Opérationnel
■ Investissement complet
● Phase V : Mise en Production
● Phase VI : Exploitation
Investissement partiel minimal
Pour les besoins de la maquette, il est possible que nous ne puissions nous contenter de matériels existants,
soit que l’entreprise en possède un nombre trop réduit, soit qu’ils sont trop anciens et/ou inadaptés.
Il est alors nécessaire de se porter acquéreur de certains matériels ou de s’en faire prêter.
Si vous deviez acquérir quelques matériels, référezvous aux spécifications fonctionnelles pour ne pas acheter de
machines trop puissantes/chères qui pourraient s’avérer inutiles si d’aventure la maquette n’est pas validée.
Vous pouvez vous orienter vers des machines fonctionnelles secondaires, comme les serveurs de licences, plus
traditionnelles et donc plus facilement recyclables.
Le plan de montée en charge peut, par contre, imposer l’acquisition d’au moins une machine significative ou
représentative de celles envisagées.
Aucune acquisition de licences n’est nécessaire : les versions d’évaluations sont généralement largement
suffisantes.
Investissement partiel
Suite à la maquette fonctionnelle, il va falloir mettre en œ uvre le pilote opérationnel, c’estàdire une
infrastructure peut être incomplète en terme de nombre de composants (dans une ferme de serveurs équilibrés
par exemple), mais pleinement fonctionnelle et installée sur des machines et des systèmes appelés à partir en
production, donc calibrés en fonction (c’est aussi et pour rappel une phase de rebouclage du plan de montée en
charge).
En général, les licences à acquérir peuvent encore être très limitées.
Investissement complet
Maquette et pilote validés : il faut partir en production ! L’investissement complet (matériels et licences minorés

des quelques achats préliminaires) est d’actualité.
Le but de cette approche en trois phases est de minimiser le risque financier lié à un projet qui pour quelque
raison que ce soit n’aboutirait pas à une mise en production : j’ai malheureusement trop souvent vu des

entreprises mettre en place des infrastructures inadaptées simplement parce qu’elles les avaient déjà achetées…
Beaucoup d’entreprises considèrent que faire appel à des experts permet de garantir la réussite d’un projet :
c’est faux. Si elle réduit considérablement le risque d’un échec global, elle ne peut garantir de dérapages souvent
préjudiciables : l’expert connaît la technique, pas votre entreprise.
Et posezvous toujours cette judicieuse question : connaissonsnous et sommesnous en mesure (nous, service
informatique de l’entreprise) d’apporter une information exhaustive autant que synthétique sur notre existant et
nos habitudes de travail, spécificités et exceptions comprises ?
Nous aimerions tous que la réponse à une telle question soit positive…
2. Détail des phases clés du projet
L’énumération présentée ciaprès est (sauf exceptions) chronologique.
Phase I : Analyse Contextuelle
Motivations et objectifs du projet : si les objectifs d’un projet peuvent être simples à identifier et clairs, il n’en
est souvent pas de même des motivations. Si elles sont, à l’origine, liées à un problème (d’obsolescence, de
performance ou autre), elles doivent aussi trouver leur expression dans la rubrique évaluation des contraintes
plutôt que des seules motivations. Si elles sont dans la recherche de valeur ajoutée, l’écho de telles motivations
se fait entendre du côté des objectifs du projet ; mais il existe aussi fréquemment les objectifs inavouables du
projet : qu’ils soient propres à certaines personnes ou à l’entreprise, ceuxci sont particulièrement importants
pour ne pas se tromper dans les solutions proposées.
Expression du besoin : en fonction des interlocuteurs impliqués dans l’expression du besoin, ce dernier peut
s’avérer plus ou moins flou. S’il n’est à ce stade pas nécessaire d’être exhaustif et précis, les principaux écueils à
sa bonne formulation sont généralement :
● Les difficultés linguistiques : au problème du pur vocabulaire français s’ajoute souvent le problème des
différents métiers qui, chacun, utilisent un vocabulaire technique souvent hermétique.
● Les difficultés humaines : problème de l’impossibilité d’exprimer correctement ou complètement le besoin
(manque de temps, voire absence des interlocuteurs importants), et/ou problème de volonté de
l’exprimer correctement (pour des raisons liées aux motivations ou aux objectifs du projet, ou
simplement à un manque de communication autour justement des motivations et objectifs du projet).
Il faudra être vigilant lors de la phase des spécifications fonctionnelles si l’expression du besoin nous a
semblé incorrecte ou insuffisante.
Évaluation des contraintes : là non plus, il ne s’agit pas d’être immédiatement exhaustif, mais d’identifier les
contraintes majeures qui pourraient dès à présent remettre en cause le projet ou tout du moins sa faisabilité
(délais, budgets, méthodes...).
Analyse rapide de l’existant :
● Humaine : intervenants et acteurs, missions et compétences
● Technique : topologies systèmes et réseaux
Définition de(s) l’architecture(s) possible(s) : il est amusant (alarmant ?) de constater que le plus souvent,
l’analyse contextuelle d’un projet se résume à l’expression de l’architecture prévisionnelle : « c’est un projet
clients légers ! ». Je préfère que l’architecture prévisionnelle soit la conséquence de l’expression d’un besoin,
quel qu’il soit, clairement identifié, exprimé et validé. Il s’agit donc ici de présenter le(s) projet(s) technique(s)
potentiel(s).
Évaluation budgétaire globale : dans le respect d’une approche TCO, et selon la portée temporelle habituelle de

l’entreprise, cette approche budgétaire ne doit faire ressortir que la faisabilité globale et l’intérêt pour
l’entreprise à se lancer dans le projet.
Planification prévisionnelle globale du projet.
Validation des intérêts pour l’entreprise : poursuivonsnous ?
Phase II : Spécifications Fonctionnelles
Compléments puis validation de l’expression des besoins : lors de l’analyse contextuelle, l’expression du
besoin a été formulée de façon générique afin de déterminer l’intérêt global à mener le projet. Elle doit être
désormais exhaustive, afin que les solutions recherchées et proposées couvrent réellement l’ensemble des
besoins de l’entreprise. Cette étape implique donc le plus souvent les utilisateurs représentatifs ou responsables
dans le projet ainsi que dans son aboutissement.
Expression exhaustive puis validation des contraintes : il convient d’inventorier les contraintes multicritères de
l’entreprise, (techniques, humaines, financières, temporelles, etc.), et de les catégoriser en fonction de leur
caractère (obligatoire à souhaitable).
Compléments puis validation de l’existant : les informations techniques, portant sur l’infrastructure existante et
nécessitant d’être précisées dans le cadre du projet, doivent aussi être exhaustives pour éviter toute « mauvais
surprise » ultérieure.
Détermination de l’architecture globale du projet : vision d’ensemble de la solution proposée, jouant le rôle de
fil conducteur des actions futures de chaque acteur du projet.
Détermination des technologies et composants de l’infrastructure globale : énumération complète et détaillée
des composants, afin de déterminer les interactions induites, les contraintes techniques associées et les
solutions trouvées ou restant à trouver (lors de la maquette fonctionnelle). Cette étape aboutit en général à la
rédaction d’une liste noire comportant deux items principaux :
● Les zones d’incertitudes techniques
● Les hypothèses techniques et les arbitrages possibles
Évaluation de la méthode d’intégration.
Évaluation des segmentations possibles : découpage en étapes du projet global pour permettre une réalisation
progressive.
Réévaluation du planning du projet.
Réévaluation de l’approche financière du projet.
Stop and Go : décision de poursuivre le projet ou non en fonction du réalisme, quant à la faisabilité technique, et
du toujours présent intérêt pour l’entreprise.
Phase III : Maquette Fonctionnelle
Intégration de la maquette : installation des matériels et systèmes nécessaires à la réalisation de cette phase
de maquette.
Évaluation/validation des différents paramétrages : grosse étape technique qui varie selon les possibilités
offertes par la nouvelle infrastructure et les besoins exprimés lors des spécifications fonctionnelles. Cette étape
vise à trouver un ensemble de solutions à des problématiques techniques souvent ardues. Elle ne doit pas
remettre en cause les spécifications fonctionnelles, sauf à procéder à une nouvelle validation des nouvelles
spécifications fonctionnelles, voire du projet global si les solutions trouvées sont « traumatisantes pour lui » (ou
n’existent simplement pas…).
Rédaction des procédures de paramétrages : ces procédures viennent naturellement enrichir les procédures

d’intégration globale qui seront finalisées lors de la phase pilote.
Plan de montée en charge : simulation d’un nombre important, ou en tout cas représentatif, d’utilisateurs type,
afin d’identifier le comportement de l’infrastructure en terme de consommation de ressources. Ne porte pas que
sur l’objet de la maquette : il faut également considérer les influences de l’infrastructure en charge sur le reste
des composants existants du système d’informations actuel.
Calibrage prévisionnel des matériels : arbitrage entre les besoins en performance globale, les contraintes de
montée en charge et les possibilités offertes par l’architecture existante et future.
Validation fonctionnelle de la maquette : cette validation effectuée par le seul service informatique doit
répondre à une dimension technique (« Tout fonctionnetil correctement ? »), organisationnelle (« Les
procédures ontelles été correctement et exhaustivement rédigées ? ») et contextuelle (« Tout estil prêt pour
réaliser un pilote ?»).
Réévaluation et analyse des écarts avec la phase précédente (spécifications fonctionnelles), et réévaluation
financière globale du projet (en fonction du calibrage des matériels et des éventuels besoins en licences
complémentaires).
Stop & Go : décision finale de poursuivre le projet ou d’en rester à la maquette.
Phase IV : Pilote Opérationnel
Intégration du pilote : installation des matériels et systèmes nécessaires à la réalisation de la phase pilote.
Choix puis formation des utilisateurs devant évaluer la nouvelle infrastructure. Une erreur très répandue est de
solliciter des utilisateurs standard ou fiables. Il convient au contraire d’impliquer :
● Soit des utilisateurs complexes : de par leurs besoins, leurs méthodes de travail ou leurs spécificités.
● Soit des utilisateurs à problème : utilisateurs compétents et/ou à orientation bidouilleurs / râleurs. Ces
utilisateurslà sont plus à même de remonter des informations techniques qu’il convient certes de trier,
mais qui font progresser énormément la phase de pilotage…
● Soit des utilisateurs responsables de services ou de départements, qui ont une vision plus globale des
besoins.
● Soit, l’idéal, un mix des trois précédentes catégories.
Le but d’un pilote n’est pas que le service informatique se congratule en validant trop rapidement son travail, par
l’implication de personnels qui valident facilement la nouvelle infrastructure : ce serait un échec probable lors de
la mise en production, avec des contraintes financières et temporelles très fortement désagréables…
Fin de rédaction des procédures d’intégration des matériels et systèmes.
Évaluation du pilote : utilisation de la nouvelle infrastructure par les utilisateurs du pilote et remontée des
informations (performances, dysfonctionnements, etc.).
Ajustements de la maquette : modifications éventuellement portées à l’infrastructure par le service informatique,
en fonction des retours d’informations précédentes.
Mise à jour des procédures d’intégration des matériels et systèmes.
Réévaluation & validation du pilote : utilisation de la nouvelle infrastructure jusqu’à ce qu’il n’y ait plus d’allers
retours et d’ajustements, pour conduire jusqu’à sa validation complète et définitive.
Validation des configurations matérielles définitives : les technologies évoluant très vite et les phases
précédentes ayant pu être longues, il convient de rafraîchir les possibilités offertes au dernier moment (juste
avant l’investissement global).
Si les phases I à IV sont réalisées avec rigueur, les phases suivantes de mise en production et d’exploitation ne
doivent être qu’une formalité et ne nécessitent pas d’être détaillées ici.

Méthodologie spécifique à RDS
1. Spécificités au niveau des phases du projet
Que ce soit lors des spécifications fonctionnelles ou lors de la maquette fonctionnelle, il est préférable de suivre
un ordre logique d’évaluation des composants d’une architecture clients légers basée sur RDS.
En effet, cela peut permettre de gagner du temps ou du moins de ne pas en perdre, soit en ne procédant pas n
fois aux mêmes étapes, soit parce qu’un aspect rédhibitoire est mis en évidence plus tôt.
Bien que cela ne reste pas parfait (entendre par là qu’il y aura obligatoirement quelques allerretour dans vos

réflexions et/ou tests), l’ordre logique peut être le suivant :
● Validation de la compatibilité des applications.
● Validation de la compatibilité des périphériques.
● Recherche d’informations :
■ Identification des contraintes réseaux : sites, bandes passantes.
■ Identification des populations d’utilisateurs.
■ Identification des flux d’informations et volumétries.
● Détermination du type d’accès client (classique, Web, monoapplicatif, encapsulé, etc.).
● Détermination du type de poste client (PC, terminal Windows,…).
● Détermination du protocole client (RDP , AIP ou ICA ).
● Choix des profils de montée en charge des logiciels.
● Détermination de l’architecture des serveurs RDS.
● Détermination des systèmes des serveurs RDS.
● Détermination de la solution d’impression.
● Détermination des méthodes de sécurisation de la nouvelle infrastructure.
● Détermination des besoins en serveurs ou ressources complémentaires.
● Détermination de l’architecture globale : positionnement des serveurs.
● Recherche d’optimisation des licences.
● Identification des flux d’informations dans la nouvelle architecture.
● Réévaluation des besoins en bande passante.
Bien qu’un besoin en bande passante initialement sousévalué puisse finalement conduire à l’avortement de tout
ou partie du projet, il n’est malheureusement pas possible de procéder à son évaluation fiable plus tôt : il faut en
effet savoir où se trouvent les serveurs pour connaître quels sont les flux qui transitent et évaluer leur
volumétrie.
2. Conduite du changement
Nous ne présentons pas ici de méthodologie efficace, mais nous vous sensibilisons plutôt à la nécessaire
conduite du changement à laquelle il vous faut procéder, si vous menez un projet de mise en œ uvre
d’architecture clients légers à grande échelle.

À grande échelle ne sousentend pas uniquement des milliers d’utilisateurs : il s’agit d’une échelle
importante pour l’entreprise. Comprendre : un projet dont le pourcentage d’utilisateurs directement
impactés est important, voire très important (cela peut aller jusqu’à 90 % dans certaines entreprises !).
Comme nous l’avons régulièrement répété jusqu’à présent, un projet clients légers est avant tout un projet
utilisateurs, non pas qu’on va le leur laisser faire mais bien qu’ils seront, malgré eux parfois, fortement impliqués
ou perturbés dans le changement qui ne manquera pas de s’opérer dans leurs habitudes de travail.
Pour étayer mes propos et cette problématique du changement, je vous présente quelques exemples réels et
finalement très fréquents que j’ai pu croiser ces quelques dernières années :
● Dans une architecture décentralisée, malgré l’existence de serveurs de fichiers suffisamment adaptés
tant en termes d’espace libre que de performance, les utilisateurs ont souvent la mauvaise habitude
d’enregistrer des fichiers en local sur leur poste. C’est d’autant plus vrai quand leur espace de stockage
est restreint sur les serveurs de fichiers. Ils peuvent aussi avoir des dossiers personnels de messagerie,
stockés en local.
Lors du passage à une infrastructure centralisée, mais ce coupci incontournable comme ce peut être le
cas des infrastructures RDS, il est nécessaire de contrôler les espaces disques des serveurs de
stockage, et donc souvent de mettre en œ uvre une politique de quota. En effet, l’entreprise stocke
désormais en central un ensemble de données nouvelles : profils, répertoires de base et documents
personnels.
À la démarche déjà compliquée car parfois très/trop structurante de ranger ses documents selon une
nouvelle norme commune, l’utilisateur peut se voir confronté à la nécessité de trier ses documents ;
comprendre, par là, supprimer ou archiver des documents certes anciens voire inutiles, mais que son
appréhension personnelle qualifierait plutôt « d’importants au cas où » ou « de personnellement
importants », car du point de vue de l’entreprise, l’utilité des dossiers personnels de messagerie et de
leur volume de données non professionnelles reste relative et constitueraient une bonne cible d’élagage
de données…
On voit dès lors que la bascule vers une architecture RDS peut être ressentie négativement, comme une
contrainte supplémentaire ou une manière détournée du service informatique (ou par extension de
l’entreprise) d’obliger les « pauvres » utilisateurs à supprimer certains documents.
● Le remplacement de postes de travail par des terminaux Windows est lui aussi régulièrement épique… Il
s’accompagne, en effet, non exclusivement mais principalement de la disparition du lecteur de CDRom et
de son périmètre stratégique d’utilisation au bureau : la musique (ou du son sur les fichiers non moins
stratégiques type mpeg, avi, pps, etc.).
J’ai réellement vu une grève se déclencher suite au retrait des lecteurs CDRom et une infrastructure
complète de près de 200 postes être retirée en hâte pour repositionner, sur les tables, les anciens PC !
Cela reste certes anecdotique, mais franchement révélateur.
● La bascule sur une infrastructure RDS est aussi, et par nécessité pour l’entreprise et l’infrastructure elle
même, l’occasion de mettre (enfin) des droits utilisateurs qui ne soient que des droits utilisateurs. Fini
les installations sauvages, les exécutions d’utilitaires, de jeux ou autre qui sortent du contrôle direct du
système d’informations centralisé.
Là encore et pour beaucoup c’est une perte de pouvoir, mais parfois aussi simplement un changement
d’habitudes (correctes) de travail, qu’il convient d’anticiper et d’accompagner afin que les utilisateurs ne
perdent pas trop en terme de productivité individuelle.
Procéder à une bonne conduite du changement apparaît dès lors nécessaire…
Ce n’est pas un si « gros mot » que cela : la conduite du changement, c’est essentiellement l’art et la manière de

faire prendre conscience à un utilisateur que le changement lui sera bénéfique. Les solutions clients légers ont
suffisamment d’avantages pour cela, y compris du point de vue des utilisateurs !
Cela passe parfois simplement par un peu d’écoute et de communication. L’implication de certains utilisateurs,
dès les premières phases du projet, est une bonne occasion d’entamer la communication, le pilote en étant
l’apogée.
Restons conscients que nous avons réellement besoin des utilisateurs pour réussir un projet, c’estàdire qu’ils
se l’approprient et finalement, utilisent notre infrastructure !

Le choix de l’architecture réseau
Tout ce qui est présenté dans ce chapitre ne peut être considéré comme vérité absolue, mais simplement comme
principes et axes de réflexion. Seule une bonne gestion de projet peut vous conduire à des certitudes.
Élément clé de toute infrastructure partiellement ou complètement centralisée, le réseau adapté (entendre
disponible, performant mais point trop coûteux) reste complexe à déterminer, particulièrement dans les
architectures clients légers.
1. Le couple RDS/RDP et les performances réseaux
a. Les composantes de la performance réseau selon RDS/RDP
La bande passante
C’est la composante de performance la plus souvent considérée car facilement mesurable et appréhensible. Il
s’agit de la "taille du tuyau", c’estàdire de la quantité d’informations qui peuvent être véhiculées sur le réseau
dans un certain laps de temps.
Les unités traditionnelles de mesure sont exprimées en nombre de bits par seconde, par exemple 56 Kb/s (ou
Kbps pour Kilobits par seconde) pour des liens type RTC, 100 Mb/s (ou Mbps pour Mégabits par seconde), ou
encore 1 Gb/s (pour Gigabits par seconde).
Attention : ne pas confondre l’unité « b » pour « bits » avec l’unité anglosaxonne « B » pour « Byte »,

qui est l’équivalent des octets, donc qui respecte le principe « 1 Byte = 1 octet = 8 bits ». Cette
parenthèse pour vous alerter sur l’expression de certaines capacités de réseaux, ou évaluations de
consommations de bande passante, commercialement (et judicieusement) requalifiées en Bytes plutôt
qu’en bits, ce qui reste plus avantageux. Attention aussi lors de l’évaluation de flux de données : on
parle bien alors d’octets…
Dans le cas d’une architecture RDS, la bande passante exprime donc essentiellement une capacité à travailler
en plus grand nombre simultanément sur un ou plusieurs serveurs Bureau à distance et, dans une moindre
mesure, le niveau d’agrément de cette utilisation.
En fait, la bande passante n’a d’influence néfaste sur les performances réseaux que lorsqu’elle est saturée,
c’estàdire quand le volume de données qui transitent à l’instant t dépasse sa capacité maximum. Dès lors, et
un peu comme sur une route, un "bouchon" se crée et il faut patienter afin que le flot/flux de données puisse
entièrement passer.
C’est à cet instant particulier que les utilisateurs du Bureau à distance sont particulièrement gênés : ils ont en
effet besoin d’une bande passante minimum pour pouvoir interagir avec leur serveur RDS (évènements
clavier/souris et rafraîchissements d’images).
Il reste donc évident que plus l’on dispose de bande passante, plus on peut connecter d’utilisateurs simultanés
et/ou retarder le moment où l’on se trouve saturé. De même, en cas de saturation, le temps nécessaire pour
écouler le flot de données est plus court avec plus de bande passante.
Le temps de latence
Cette composante de la performance réseau est primordiale dans le contexte des architectures clients légers. Il
s’agit du temps nécessaire à la transmission d’informations d’un point A du réseau vers un point B,
généralement exprimé en millisecondes (ms).
Dans le cas des communications entre un client RDC et le serveur RDS associé, la performance (ou le manque
de performance) ressentie par l’utilisateur dépend directement du délai d’affichage de l’image sur son écran.
Comme tout est centralisé, il faut que les évènements clavier/souris soient transmis au serveur RDS, traités,

puis que l’image associée soit renvoyée au client RDC pour affichage. Prenons l’exemple de la rédaction d’un
document sur Word : si l’utilisateur tape « Bonjour ! », les 9 caractères saisis au clavier doivent être transmis
au serveur, qui doit générer et renvoyer l’image correspondant à l’affichage de ce texte sur le document.
Le temps de latence est donc pris à parti deux fois : à l’aller et au retour. Du point de vue de l’utilisateur, si le
temps de latence est trop important, il saisira son texte « Bonjour ! », mais ne verra apparaître les caractères
que plus tard (soit de façon saccadée, les uns après les autres mais plus lentement que sa frappe clavier, soit
d’un bloc mais franchement plus tard). Il est clair que l’appréhension de la performance varie grandement d’une
personne à l’autre. On peut considérer qu’à partir de 400 ms (donc presque une demiseconde), l’écart entre
les actions faites et le résultat visualisable est franchement gênant pour l’utilisateur commun. Ce qui
correspond donc à un temps de latence maximum de 200 ms. Je persiste à penser que l’idéal se situe quand
même en dessous d’un temps de latence de 100 ms.
Sur un réseau local, ceuxci sont généralement excellents (donc très faibles, de l’ordre de 1 ms voire moins).

Sur un réseau étendu, c’est généralement moins le cas, comme nous le montre l’exemple suivant.
Évaluer rapidement un temps de latence est simple : il suffit de procéder à un ping classique entre le point A et
le point B du réseau. On obtient alors la durée approximative des boucles en ms.
Dans notre exemple, nous voyons que le réseau étendu (qui n’est autre que le serveur DNS bien connu de mon
fournisseur d’accès ADSL) présente des variations non négligeables des temps de latence au fil des paquets
envoyés, et que l’on est loin de la milliseconde du réseau local. Attention : le temps affiché présente l’aller
retour complet. Le cas de liens type RTC, RNIS ou Frame Relay serait plus alarmant encore : on oscille
facilement entre 200 et 500 ms !
Il faut aussi considérer la taille des paquets envoyés, qui par défaut dans une commande ping sont de 32
octets. La taille des paquets RDPTCP oscille entre 50 et 1000 octets (mais la moyenne dépend des usages), ce
qui a une influence directe sur la performance de transmission dans les réseaux étendus.
Les deux exemples ciaprès envoient respectivement des paquets de 100 puis de 1 000 octets aux mêmes
serveurs local et distant, et l’on voit que l’influence de la taille des paquets n’existe que sur le réseau distant et
plus particulièrement dans le cas de gros paquets (les temps de latence augmentent de 50 %) :

Influences réciproques
Si le temps de latence n’a pas d’influence sur la quantité de bande passante, l’inverse est par contre faux.
En effet, quelle que soit la quantité de bande passante maximale dont un lien réseau puisse disposer, s’il
atteint un niveau de saturation, la transmission de l’ensemble des paquets est ralentie. Nos trames RDPTCP,
noyées dans le flot de données (ou plutôt "coincées dans le bouchon"), se voient donc ralenties et un simple
caractère Word pourra mettre un temps interminable à s’afficher sur l’écran de l’utilisateur.
À l’expression consacrée le "serveur rame" généralement formulée à cet instant, il faudra aussi être attentif à
une éventuelle saturation du réseau, et oui, le "réseau rame" aussi...
b. Consommation RDS/RDP de la bande passante
Consommation unitaire

Le principe technologique du protocole RDP (communication graphique compressée limitée au rafraîchissement
d’écran dans un sens, et évènements clavier/souris dans l’autre) induit une faible consommation de bande
passante eut égard à celle nécessaire aux échanges traditionnels où des fichiers entiers se promènent à
travers le réseau.
A minima, lorsque l’utilisateur ne manipule pas clavier ou souris et que rien ne bouge à l’écran (lecture d’un
document par exemple), seules quelques trames de contrôle de connexion transitent sur le réseau (afin de
vérifier que le poste est toujours connecté au serveur). Il y a, à cet instant, une consommation de bande
passante quasi nulle.
Nous avions précédemment dit qu’a maxima, lorsque l’utilisateur rafraîchit l’intégralité de la surface de l’écran,
par exemple lorsqu’il va basculer d’une application à une autre par le raccourci [Alt][Tab] sous Windows, la
consommation de bande passante est de l’ordre de 90 à 100 Kbps. Ceci est tout de même faux : c’est un
maxima pour un usage bureautique ou applicatif classique, mais la consommation de bande passante par RDP
peut être bien supérieure si, par exemple, on affiche une vidéo plein écran à 24 images seconde (ce n’est pas
de l’usage normal d’une architecture RDS). En pareil cas, la bande passante peut atteindre des valeurs de
l’ordre de 400 Kbps !
En moyenne, c’estàdire en utilisation courante d’un utilisateur actif mais pas forcené de l’[Alt][Tab], on
constate que la bande passante consommée oscille entre 60 et 80 Kbps. Toutefois, l’architecture est
pleinement fonctionnelle pour un seul utilisateur dès lors que l’on dispose d’au moins 20 Kbps (et bien sûr d’un
temps de latence toujours correct).
On obtient donc une consommation de bande passante oscillant entre quasi 0 Kpbs et 128 Kbps, avec une
moyenne normalisée oscillant entre 0 et 80 Kbps par poste connecté.
Consommation instantanée
La consommation instantanée de bande passante intègre deux dimensions supplémentaires : la simultanéité et
la réalité de l’entreprise.
Considérons une dizaine d’utilisateurs qui travaillent en mode client léger (c’estàdire connecté via RDP à un
serveur RDS). Le protocole ne consommant que l’équivalent de la somme des rafraîchissements de l’ensemble
des écrans des utilisateurs, combien d’écrans complets cela peutil représenter à l’instant t ? Car à l’instant t+1,
si les utilisateurs ne poursuivent pas leurs actions, la consommation tend à nouveau vers zéro. On constate
généralement que l’on peut diviser le nombre d’utilisateurs par deux pour avoir la réponse, et multiplier par 64
Kbps par utilisateur pour obtenir un ordre de grandeur de la bande passante utilisée (ou nécessaire), soit dans
notre exemple : (10 / 2) x 64 Kbps = 320 Kbps pour dix utilisateurs actifs.
Dans la réalité de l’entreprise, un salarié ne passe pas tout son temps à manipuler son ordinateur (sauf
quelques activités ou postes spécifiques) : il téléphone, manipule du papier, assiste à des réunions, etc. Cela
reste donc difficile à évaluer, mais l’on peut considérer dans notre exemple précédent de 10 utilisateurs
simultanés qu’ils représentent en fait une population moyenne de 15 à 20 salariés.
La qualité du projet pilote sera déterminante pour bien connaître le profil de travail des utilisateurs dans
l’entreprise et donc bien calibrer ses lignes. Il peut aussi à ce titre être utilisé des logiciels d’analyse de
réseaux, comme Sniffer Pro ou plus simplement PRTG Traffic Grapher, afin de déterminer les flux et débits
associés.
Quoi qu’il en soit, nous arrivons à un ordre de grandeur de 15 à 20 utilisateurs pour 320 Kbps de ligne télécom
par exemple, s’il s’agit de relier une agence au siège central.
Tierces influences directes
Le choix de la résolution d’écran des sessions RDS/RDP impacte directement la consommation en bande
passante, ce qui reste logique étant donné qu’il s’agit d’un protocole essentiellement graphique :
● Plus la résolution d’affichage de la session RDS/RDP est grande, plus la bande passante consommée
est grande (une session 1280x1024 consomme plus de bande passante qu’une session 800x600).
● Plus le nombre de couleurs gérées et affichées dans la session RDS/RDP est grand, plus la bande

passante consommée est grande.
● Plus le nombre de canaux virtuels (mappages de lecteurs, de ports, etc.) gérés entre le client RDC et le
serveur RDS est grand, plus la bande passante consommée est grande.
● Plus l’écran de l’utilisateur est graphiquement complexe, par exemple avec un fond d’écran de haute
résolution ou un Active Desktop, plus la bande passante consommée est grande.
Tierces influences indirectes
Comme nous avons pu le découvrir dans le chapitre Concepts avancés Gestion des impressions, le choix d’une
méthode d’impression plutôt qu’une autre a un impact direct sur la consommation de bande passante, ainsi que
la résolution même d’impression des documents. Une mauvaise approche de la gestion des impressions aboutit
généralement à une saturation de la bande passante pour des durées plus ou moins longues, et donc à
l’immobilisme apparent des sessions RDS transitant sur le même segment de réseau.
D’une manière générale, tout ce qui touche aux contenus des canaux virtuels a une influence sur la bande
passante, comme par exemple le mappage de lecteurs locaux particulièrement chargés (en nombre d’éléments)
ralentit tant leur exploration qu’il utilise plus de bande passante.
c. Consommation RDP avec RemoteFX
Avant de commencer, il est important de ne pas oublier que l’utilisation de RemoteFX nécessite une bande
passante élevée (LAN)…
Afin d’évaluer la consommation de bande passante, plusieurs tests ont été conduits avec des profils d’usages
différents. La batterie de tests est réalisée « en mode haute qualité ».
RDSH
● Configuration côté serveur :
■ RemoteFX activé : Oui
■ Expérience utilisateur disponible : Oui (Avec Aero)
● Configuration côté client :
■ Couleurs : 32bits
■ Nombre d’écrans : 1
■ Résolution d’écran : 1024 x 768
● Redirections locales :
■ Lecture Audio : Non (sauf Test streaming vidéo sous IE8 )
■ Enregistrement Audio : Non
■ Imprimantes : Non
■ Pressepapiers : Oui
● Vitesse de connexion : « LAN 10 Mbits/s »
Test avec Outlook 2010 :

Test avec Powerpoint 2010 (Lecture présentation) :
Test avec IE8 :
Test streaming vidéo sous IE8 :
On constate sur ce relevé que l’utilisation d’Outlook peut s’avérer extrêmement consommatrice de bande
passante avec un paramétrage « Haute qualité ».
RDVH
● Configuration côté hôte de virtualisation :
■ RemoteFX activé : Oui
● Configuration côté Machine Virtuelle :
■ Carte3DFX : Oui
■ Interface Aero : Oui
● Configuration côté client :
■ Couleurs : 32bits
■ Nombre d’écrans : 1

■ Résolution d’écran : 1024 x 768
● Redirection locales :
■ Lecture Audio : Oui
■ Enregistrement Audio : Non
■ Imprimantes : Non
■ Pressepapiers : Oui
● Vitesse de connexion : « LAN 10 Mbits/s »
Test avec Outlook 2010 :
Test avec Powerpoint 2010 (Lecture présentation) :
Test avec IE8 :
Test streaming vidéo sous IE8 :
Test d’une application flash 3D (jeux) :

Test Application DirectX :
Test de manipulation d’un document Acrobat Reader 3D :
L’utilisation d’applications « massivement graphiques », ou de vidéos, doit être réservée à un réseau
local (haut débit) sous peine de saturer le lien réseau.
Avec redirection USB RemoteFX (webcam) :
Avec redirection USB RemoteFX (Imprimante) :
Prévisualisation sous PowerPoint 2010 et impression Document .ppt de 20 pages en N&B (spool 10 Mo).
Avec redirection USB RemoteFX (Scanner) :

L’utilisation de la redirection USB RemoteFX pour utiliser une webcam ou un scanner peut consommer
jusqu’à 10 Mbps ce qui réserve ces usages à un réseau local.
Au regard de ces résultats, on comprend mieux pourquoi Microsoft préconise l’utilisation de RemoteFX
sur le LAN…Pour autant, la mise en œ uvre d’architectures mixtes (avec et sans RemoteFX) permet de
s’adresser autant aux « gros sites » qu’aux succursales (disposant d’un faible débit réseau).
2. Évaluation du besoin en bande passante
a. En fonction des utilisateurs
Flux RDS/RDP
En résumé (les explications ont été vues précédemment), on peut évaluer le besoin en bande passante pour
les flux RDS/RDP suivant la « formule » :
● Déterminer le nombre d’utilisateurs potentiels transitant par le segment réseau, par exemple 100.
● Déterminer un cœ fficient de simultanéité pour cette population, c’estàdire un pourcentage
représentatif du nombre de personnes qui interagissent simultanément avec leur session informatique
(tenir compte de l’absentéisme comme de l’activité propre à chacun). Par exemple : 60 %.
● Appliquer le cœ fficient précédent au nombre d’utilisateurs potentiels, puis diviser le résultat par 2
(cœ fficient de simultanéité graphique), ce qui nous donne alors le nombre d’utilisateurs simultanés.
Dans notre exemple : (100 utilisateurs potentiels x 60 %) / 2 = 30 utilisateurs simultanés.
● Selon votre ressenti du comportement graphique des utilisateurs, c’estàdire de la fréquence et de
l’ampleur du rafraîchissement de l’écran d’un utilisateur typique (qu’il peut être bon d’observer…),
choisissez une bande passante moyenne consommée par utilisateur de :
■ 50 Kbps pour les utilisateurs graphiquement peu actifs ;
■ 80 Kbps pour les utilisateurs graphiquement actifs ;
■ 120 Kbps pour les utilisateurs graphiquement forcenés (au sens bureautique du terme…).
● Multiplier la bande passante consommée choisie par le nombre d’utilisateurs simultanés pour obtenir
un ordre de grandeur de la bande passante nécessaire, soit dans notre exemple si nos utilisateurs
sont forcenés : 30 utilisateurs x 120 Kbps = 3 600 Kbps nécessaires
Il est bien sûr possible de segmenter la population des utilisateurs en fonction de leur comportement
graphique.
Important : il reste impératif de vérifier cette évaluation lors du pilote, puis de la mise en production ;
évaluation qui ne peut dès lors être qu’une première estimation !!!
Une évaluation de bande passante nécessaire ne doit pas représenter un maximum, mais bien un
minimum…

Flux connexes
Nous ne saurions formuler une méthode qui puisse vous permettre d’évaluer correctement votre besoin en
bande passante pour les flux connexes : ils sont trop nombreux et variés pour cela !
Dans un contexte d’architecture RDS, certains sont toutefois quasi toujours présents, au rang desquels et
principalement les flux d’impressions et les transferts de fichiers entre lecteurs locaux et distants.
Il eut été possible de les traiter dans la logique des flux RDS/RDP, du fait que ces flux sont encapsulés dans les
canaux virtuels du protocole RDP, mais leur nature est tellement différente qu’ils nécessitent le plus souvent
une analyse spécifique.
Considérez donc toujours que :
● Un document imprimé localement à partir d’une session distante Bureau à distance est un "job
d’impression" (donc parfois plus volumineux que le document luimême) qui transite (a minima) dans le
segment réseau qui sépare le serveur d’impression de l’imprimante.
● Dans une session RDS, un document utilisé, copié ou enregistré, sur ou à partir d’un lecteur local
mappé, est un document qui transite dans le segment réseau séparant le serveur RDS du poste client.
b. En fonction du positionnement des serveurs
Dans un contexte multisites/multiserveurs, il est évident que le positionnement des serveurs sur les différents
sites et/ou segments de réseaux a des influences directes certes sur les fonctionnalités, mais surtout sur les
performances des réseaux et donc de l’architecture clients légers globale.
Là encore, chaque cas reste spécifique et nous n’illustrerons que quelques exemples afin de mettre en lumière
certains principes et écueils courants.
Dans les exemples suivants, entendre "centralisé" par "présent sur le site siège" et "décentralisé"
par "présent sur le site distant".
Positionnement des serveurs RDS
Tous sur un même site central
C’est l’architecture la plus simple et la plus recherchée dans une logique de centralisation. Elle revêt toutefois
quelques inconvénients, tant en terme de sécurisation que de performances, donc en fait de coût global.

Sur le plan de la sécurité, les utilisateurs du site distant sont complètement isolés en cas de coupure réseau, et
il convient donc de mettre en œ uvre les solutions de redondance du lien intersite adaptées.
Sur le plan de la performance, le nombre d’utilisateurs du site distant va directement impacter le niveau de
performances du site distant et donc, pour rester dans des niveaux acceptables, augmenter le besoin en bande
passante du lien intersite. Le coût parfois exorbitant de ce type de lien télécom, dans des contrées isolées ou
sur de grandes distances, rend parfois l’autre approche de répartition des serveurs RDS sur les différents sites
malgré tout plus intéressante.
Répartis sur différents sites

Outre le nombre parfois plus important de serveurs RDS nécessaires, cette approche a pour principal
inconvénient de générer des centres névralgiques distants, à exploiter, administrer, etc.
Sur le plan de la sécurité, la solution semble satisfaisante mais, sur le plan des performances, elle dépend en
fait du positionnement des serveurs connexes à RDS et surtout complémentaires au système d’informations.
Positionnement des serveurs RDLM associés
● Hypothèse 1 : Serveurs RDS centralisés

Dans cette hypothèse, ni doute ni intérêt à positionner les serveurs de licences RDLM ailleurs que sur le site
central, à proximité immédiate des serveurs RDS.
● Hypothèse 2 : Serveurs RDS décentralisés et serveurs de licences centralisés

Comme nous avons déjà pu le découvrir dans un précédent chapitre, la communication entre les serveurs de
licences et les serveurs RDS intervient rituellement et selon la situation propre au service RDLM (serveur de
licences RDS) toutes les 15, 60 ou 120 minutes, mais aussi à chaque fois qu’un client tente d’ouvrir une session
Bureau à distance avec une licence expirée ou sans licence.
En terme de performance, il n’y a pas de réel problème au fait que les serveurs RDS 3 et 4 accèdent aux
serveurs de licences sur un site central : les communications sont en effet ponctuelles et légères.
En terme de sécurité, l’impossibilité de contacter les serveurs de licences lors de coupures réseau peut conduire
à l’impossibilité de connecter certains postes du site distant, durant toute la coupure.
● Hypothèse 3 : Serveurs RDS et serveurs de licences décentralisés
Cette approche peut être intéressante et convenir même si l’on ne souhaite pas répartir les licences achetées
par serveur de licences en fonction du nombre de postes des deux sites, mais bien les centraliser sur le serveur
de licences 1. Dans ce cas et lors de coupures réseau du lien intersite, les serveurs RDS 3 et 4
obtiendraient des licences temporaires 90 jours de la part du serveur de licences 2, alors que le siège
continuerait à fonctionner normalement.
Il faudrait cumuler panne du serveur de licences 1 et panne du lien réseau intersite pour que les utilisateurs du
site central s’en trouvent gênés, ce qui reste peu probable.
Si d’aventure la bande passante du lien intersite était vraiment trop (fréquemment) saturée, il pourrait être
intéressant de segmenter les licences achetées sur chacun des serveurs de licences et donc des sites.
Serveurs complémentaires

Serveurs de fichiers
Dans cette hypothèse, ni doute ni intérêt à positionner les serveurs de fichiers ailleurs que sur le site
central, à proximité immédiate des serveurs RDS, sauf pour des besoins locaux du site distant hors
périmètre RDS mais qui peuvent amener une remise en cause de l’intérêt de centraliser tous les
serveurs RDS.
● Hypothèse 2 : Serveurs RDS décentralisés et serveurs de fichiers centralisés.
Dans le lien réseau intersite, à chaque manipulation de quelque fichier que ce soit (et ne seraitce que déjà à
l’ouverture de sa session et lors du chargement de son profil), un utilisateur du site distant agissant sur sa
session Bureau à distance certes locale, induit nécessairement un transfert du dit fichier dans le lien réseau
intersite, effondrant rapidement et peut être dramatiquement les performances.
De plus, toute coupure même minime du lien intersite peut corrompre les données manipulées.
Cette architecture est donc généralement à bannir.
● Hypothèse 3 : Serveurs RDS et serveurs de fichiers décentralisés

C’est à mon sens la seule implémentation sérieusement possible, malgré l’accroissement
progressif du nombre de serveurs à gérer sur le site distant.
Serveurs Active Directory
L’impact positif en terme de performances de la présence de serveurs Active Directory à proximité des serveurs
de fichiers est telle, que nous considérons qu’il ne peut en être autrement dans nos hypothèses.
Dans cette hypothèse, ni doute ni intérêt à positionner les serveurs Active Directory ailleurs que sur le
site central, à proximité immédiate des serveurs RDS et des serveurs de fichiers, sauf pour des besoins
locaux du site distant hors périmètre RDS mais qui peuvent amener une remise en cause de l’intérêt de
centraliser tous les serveurs RDS.
● Hypothèse 2 : Serveurs RDS décentralisés et serveurs de fichiers et Active Directory centralisés

Nous sommes exactement dans le même cas que pour l’hypothèse précédente « Serveurs RDS décentralisés et
serveurs de fichiers centralisés ». Solution donc à bannir autant que possible !
● Hypothèse 3 : Serveurs RDS, serveurs de fichiers et Active Directory décentralisés

C’est là encore, à mon sens, la seule implémentation sérieusement possible, malgré l’accroissement désormais
sensible du nombre de serveurs à gérer sur le site distant.
Il est clair qu’on se rapproche de la terminologie deux sites identiques, donc intéressante uniquement à partir
d’un certain nombre d’utilisateurs sur le site distant afin que les coûts et inconvénients d’une informatique
décentralisée soient plus supportables que ceux d’une informatique centralisée, dont le besoin en bande
passante fiable et performante et donc le surcoût associé.
Serveurs d’applications
En termes de performances, les serveurs d’applications ont toujours intérêt à être proches des serveurs RDS,
afin que seuls des flux protocolaires RDS/RDP ne transitent dans les liens réseaux. Mais ils se positionnent en
général selon des critères qui leurs sont propres et constituent le plus souvent une contrainte ou un pré
requis, plus qu’une solution…
Serveurs d’impressions
Il n’est pas possible de bâtir des hypothèses de positionnement des serveurs d’impression : cela dépend
directement de la technologie retenue (voir chapitre Concepts avancés Gestion des impressions), et/ou des
éventuelles possibilités offertes par les produits tiers qui s’accompagnent souvent de contraintes de mise en
œ uvre.
Quoi qu’il en soit, il est très important d’identifier avec précision les flux d’impressions (fréquence, qualité,
volumétrie,etc.) qui existeront, et de chercher à les réduire au maximum sur les liens réseaux séparant les
clients RDC de leur serveur RDS : leur impact sur ces liens reste fortement négatif.
Note importante : souvenezvous qu’un serveur a parfois plusieurs rôles !

La recherche de performance étant souvent une manière détournée de réduire les coûts (ou du moins
d’empêcher leur accroissement dans le cas de liens télécoms distants), prenez en considération une
portée temporelle cohérente pour comparer les différentes solutions qui s’offrent à vous. Le lien réseau
intersite peut être une charge mensuelle, alors qu’un serveur peut être un investissement amorti plus
une charge mensuelle d’administration : il faut choisir de comparer les deux approches sur un mois, un
an, ou autres (durée de l’amortissement, durée de vie du serveur ?).
3. Besoin en bande passante et besoin de sécurisation
Il n’est nul besoin d’un grand chapitre pour comprendre qu’une fois le besoin en bande passante évalué, trois
possibilités vont s’offrir :
● Soit mettre en œ uvre un lien unique couvrant 100 % du besoin.

Sans commentaires.
● Soit mettre en œ uvre un lien principal couvrant 100 % du besoin et un lien de secours couvrant par
exemple 20 % du besoin.
La panne du lien principal conduirait à un fonctionnement en mode dégradé qui peut être suffisant pour
certains sites distants et certaines activités.
● Soit mettre en œ uvre deux liens couvrant au total 100 % du besoin, et se répartissant les flux de
données.
L’intérêt de la redondance et de la performance réunies ; mais l’inconvénient d’une mise en œ uvre souvent fort
coûteuse de solutions matérielles et/ou logicielles tierces.
À vos politiques et/ou budgets !

Le calibrage des serveurs
La plus grande difficulté concernant ce chapitre reste de vous connaître : êtesvous, cher lecteur, confronté à une
installation de deux applications sur un serveur pour 25 utilisateurs ou de 200 applications sur n serveurs pour 10
000 utilisateurs ? Ou peutêtre êtesvous confronté aux deux cas en tant que prestataire informatique ?
Dans l’ignorance, tout ce qui est présenté dans ce chapitre ne peut être considéré comme vérité absolue mais
simplement comme principes et axes de réflexion. Seules une bonne analyse et une bonne gestion de projet
(maquette puis pilote) pourra vous conduire à des certitudes.
Et souvenezvous que la performance d’une architecture RDS n’est pas seulement liée à la performance d’un ou
plusieurs serveur(s) RDS : les performances réseaux sont aussi primordiales !
1. Considérations d’ensemble
Le calibrage des serveurs est une opération délicate car elle détermine directement le niveau d’agrément obtenu
d’une architecture RDS, tant pour les utilisateurs (en terme de performances) que pour les administrateurs (en
terme de fiabilité). La difficulté est d’obtenir le maximum de performances et de fiabilité, pour le minimum de
complexité et… de coût !
Les possibilités financières de l’entreprise constituent une potentielle contrainte au calibrage judicieux des
serveurs RDS. Nous ne pourrons rentrer dans l’évaluation de telles contraintes, qui conduit (trop fréquemment) à
des arbitrages, mais tenterons simplement de faire que ces derniers ne soient pas arbitraires…
Je croise malheureusement très ou trop fréquemment des entreprises dont les choix matériels et les
investissements associés ont été faits avant même de procéder à un quelconque plan de montée en charge, ou à
défaut (de temps ou de moyen, peu importe) d’une rapide analyse préalable qui aurait permis de ne pas faire de
mauvais choix ou arbitrages techniques.
Comme nous avons pu le découvrir dans ce chapitre, le calibrage unitaire des serveurs RDS est aussi directement
impacté par l’architecture d’ensemble retenue. Reprenons le même exemple pour illustrer cette affirmation :
Soit une entreprise souhaitant mettre en œ uvre une architecture RDS pour dix applications sur dix serveurs pour
800 utilisateurs. Deux approches sont alors possibles :
● Installer les dix applications sur chacun des dix serveurs RDS et répartir les utilisateurs sur cette ferme
que l’on peut qualifier d’homogène.

Sur le plan de la performance pure, il est certain qu’installer toutes les applications sur un même serveur ne peut
que conduire à une charge serveur relativement conséquente voire inopérante du point de vue des utilisateurs : il
suffit que deux ou trois applications aient le même profil de consommation de ressources pour qu’elles « se
battent » cette ressource serveur unique dans une architecture centralisée ; et la probabilité que ces applications
soient utilisées en même temps sur un même serveur est plus grande du fait que tous les serveurs sont
identiques.
Dans ce cas, le calibrage des dix serveurs sera identique, mais délicat.
● Regrouper certaines applications et les installer sur des fermes de serveurs dédiées, par exemple : quatre
applications sur quatre serveurs, trois autres applications sur quatre serveurs et enfin les trois dernières
applications sur deux serveurs.
La difficulté exposée dans le chapitre sur les performances est donc de constituer des regroupements judicieux
d’applications, notamment en fonction des profils de consommation de ressources serveur, lesquels permettront
de minimiser le calibrage unitaire des serveurs de chaque ferme.
Si plusieurs applications sont très gourmandes en ressource processeur par exemple, il est préférable de ne pas
les positionner sur les mêmes serveurs mais plutôt de les répartir sur chacune des fermes, en les associant avec
d’autres applications dont le profil de consommation de ressources serveur touche par exemple plus la mémoire
RAM.

Dans ce cas, le calibrage des serveurs pourra être différent d’une ferme à l’autre, mais les serveurs constituant
chaque ferme devront être identiques.
Quelle que soit l’approche retenue, le calibrage des serveurs RDS passe par une connaissance préalable et très
précise du contexte de travail de l’entreprise, particulièrement pour :
● Les applications qui seront utilisées sur le(s) serveur(s) RDS.
● Les utilisateurs qui en feront l’usage.
Dès lors, avec ou sans plan de montée en charge, quelques principes techniques vous permettront des déterminer
les configurations serveurs nécessaires, ou tout du moins, de ne pas les sousestimer. Mais rassurezvous : il est
faux de penser qu’architecture RDS est obligatoirement synonyme de gros, voire très gros serveurs centraux !
Et les coûts constamment en baisse des matériels serveurs proposés nous rendent un peu de sérénité à
l’approche de cette fameuse étape de calibrage.
a. Impact des applications
Chaque application a un profil de consommation de ressources serveur différent : certaines consomment plus de
mémoire RAM alors que d’autres sollicitent principalement le processeur ou encore le soussystème disque. On
comprend donc bien qu’à caractéristiques serveurs identiques, les performances ressenties par un utilisateur en
fonction de l’application manipulée pourront être très variables.
De même, les applications sont généralement 32 bits, mais certaines applications 16 bits voire DOS peuvent
encore exister en entreprise et leur mécanisme d’émulation peut conduire à des baisses de performances
impressionnantes, créant alors des dommages collatéraux certains. Ces applications ne doivent à mon sens pas
être installées sur des fermes de serveurs RDS 32 bits ou alors être encapsulées sur des serveurs dédiés.
Cette logique est respectée pour les applications 32 bits fonctionnant sur des fermes de serveurs 64 bits, de
plus en plus fréquentes. Là encore, il convient de mesurer précisément l’impact du fonctionnement de ces
applications sur les performances, bien que les systèmes 64 bits gèrent efficacement la mémoire RAM
(contrairement aux systèmes 32 bits).
Cependant, la catégorisation des applications doit aller plus loin : une application dont l’usage est
essentiellement graphique a un impact (négatif en l’occurrence) certain sur les performances ressenties, quand
bien même son profil de consommation de ressources serveur soit en adéquation avec les caractéristiques (et la

disponibilité à l’instant t) du serveur RDS sur lequel l’utilisateur est connecté. RDP reste un protocole
essentiellement graphique ! Il est dès lors clair que les performances ressenties avec PowerPoint ne seront pas
les mêmes que celles de Word et que, pour ce dernier, un document texte sobre ne peut être assimilé à un
document évolué à fort caractère graphique.
Enfin, il ne faut pas non plus négliger les utilisations croisées, dont l’existence et la portée doivent être
identifiées. C’est par exemple le logiciel de messagerie Outlook, qui peut (et c’est généralement le cas par
défaut…) appeler Word comme traitement de texte par défaut des nouveaux messages électroniques. L’impact
mémoire (pour ne focaliser que sur lui) est alors double (Outlook + Word) pour un usage pourtant visuellement
simple (Outlook) : c’est alors a minima 8 à 10 Mo de mémoire en plus par utilisateur.
La catégorisation des applications est donc nécessaire et va permettre :
● Leur regroupement sur des fermes de serveurs distinctes.
● Leur validation quant à être installée ou non sur une architecture RDS, en fonction d’ellesmêmes, mais
aussi de leur cohabitation avec d’autres applications.
Une catégorisation possible des applications peut être obtenue en remplissant le tableau suivant (valeurs
données à titre d’exemple et ne reflétant aucune réalité) :
Le principe du tableau est de catégoriser les applications selon des informations relevées lors de tests
préalables plus ou moins simplifiés ou collectées auprès des éditeurs ou services concernés. Ne s’agissant pas
d’un réel plan de montée en charge, cette première évaluation sera toutefois plus efficace si l’on implique
quelques utilisateurs représentatifs.
La notion de « poids » porte sur une échelle de 1 à 5 : du moins gênant au plus gênant pour la future
architecture. Le but reste d’identifier les applications qui peuvent ou non cohabiter sur un même serveur.
Quelques précisions sur ce tableau et la manière dont je l’utilise :
● L’échelle de consommation de RAM est :
De 0 à 10 Mo Poids = 1
Plus de 60 Mo Poids = 5
● La « consommation réseau » porte sur les échanges entre le serveur RDS et les autres serveurs,
généralement et principalement le serveur de fichiers et les serveurs applicatifs. Elle détermine donc les
besoins en bande passante « arrière » et ne porte pas sur les flux RDP frontaux.
● La consommation processeur est évaluée de façon empirique ou, mieux, selon les indications d’un
éventuel éditeur, car toute consommation instantanée exprimée en pourcentage dépend de la
puissance du processeur utilisé pour la mesurer.
● Le profil graphique est aussi évalué de façon empirique, en fonction du pourcentage de la superficie de
l’écran qui change à chaque manipulation de l’utilisateur et de la fréquence de ces changements. Par
exemple, une vidéo est en fonction de sa taille très ou trop gourmande, comme un navigateur Web
affichant des animations flash par exemple… La CAO n’a donc pas sa place…

b. Impact des utilisateurs
L’impact des utilisateurs sur le calibrage des serveurs RDS reste le plus important car il influe aussi la répartition
des applications.
Comme pour les applications, les utilisateurs doivent être catégorisés en fonction de leur profil de travail : sont
ils des utilisateurs légers, standards ou forcenés ?
Ils doivent aussi être, en parallèle, répartis en fonction des applications susceptibles d’être installées sur les
serveurs RDS, afin de répondre à la question suivante : cette application est utilisée par combien de personnes,
et de quelle manière ?
La complexité porte sur les multiples combinaisons possibles en terme de répartition des utilisateurs sur les
serveurs RDS (nous faisons abstraction des serveurs monoapplicatifs ou des monoserveurs RDS, dépourvus de
complexité par essence) afin de trouver le meilleur ratio performancescalibrage possible.
Catégorisation des utilisateurs
Chaque utilisateur, hormis les administrateurs mais y compris par exemple les personnels du service d’assistance
aux utilisateurs, doit être membre d’une des catégories de profil suivantes :
Utilisateurs Légers
Il s’agit d’utilisateurs occasionnels de l’informatique, non pas au sens temps de présence devant son écran, mais
plutôt au sens comportement d’utilisation. Un utilisateur léger lance une ou deux applications à la fois et n’en
utilise généralement qu’une. Ce n’est pas un champion de la saisie au clavier ou de la manipulation des logiciels
en cliquant partout. C’est un utilisateur posé/réfléchi, qui utilise l’informatique plus par contrainte ou pratique que
par envie.
Utilisateurs Standards
Il s’agit des utilisateurs habituels de l’entreprise, qui forment généralement le plus grand nombre. S’ils peuvent
toutefois avoir un profil d’utilisation de type léger, ils lancent en général trois à six applications, sont à l’aise avec
l’ensemble des manipulations Windows et bureautiques courantes et basculent facilement entre deux
applications. Statistiquement, ils ont souvent un ordinateur personnel et/ou plusieurs années d’utilisation
derrière eux.
Utilisateurs Confirmés
Il s’agit de quelques utilisateurs très à l’aise avec l’outil informatique, utilisant simultanément plusieurs
applications dont ils tirent la quintessence, manipulant (clavier/souris) très rapidement et généralement
sensibles aux performances des outils informatiques mis à leur disposition. Outre les services informatiques, on
retrouve dans cette catégorie, les services classiquement consommateurs de ressources informatiques : bureaux
d’études, services commerciaux et/ou marketing/communication, etc.
On comprend rapidement qu’il conviendrait de répartir ces utilisateurs :
● Soit sur des serveurs dédiés en fonction de leur profil
Dans ce cas, les serveurs pour les utilisateurs légers pourraient soit être moins calibrés, soit accueillir plus
d’utilisateurs simultanément, à l’inverse de ceux dédiés aux utilisateurs forcenés. Mais cela va à l’encontre de
l’homogénéisation des configurations serveurs (physiques et logiques).
● Soit sur chaque serveur proportionnellement à leur représentativité dans l’entreprise.
Dans ce cas, les n serveurs sont calibrés de façon identique, un énième des utilisateurs de chaque catégorie
étant réparti dessus. Mais cela va à l’encontre des possibilités standard d’équilibrage de charge automatique
entre différents serveurs d’une même ferme…

Malheureusement, tout n’est pas aussi simple : pour une application donnée, il se peut que l’on soit en présence
de profils d’utilisateurs complètement opposés…
Répartition des applications par utilisateur
La détermination de la solution idéale passe donc par un recoupement entre les applications, le nombre et le
profil des utilisateurs qui les utilisent de façon potentielle (approche pour une éventuelle gestion des licences)
mais surtout simultanée (approche pour la gestion des performances et donc le calibrage).
La simultanéité d’utilisation d’une application est toujours difficile à appréhender : elle passe tant par la
simultanéité de présence d’un utilisateur dans l’entreprise (congés, RTT, etc.), que par la fréquence d’utilisation
de l’application d’un utilisateur présent et enfin par le profil de l’utilisateur lorsqu’il utilise cette application. Il
reste vrai que des utilisateurs forcenés participent à l’augmentation de la simultanéité, parfois artificiellement (si
je m’en réfère à mon simple cas : en moyenne huit applications ouvertes pour deux à trois utilisées réellement en
parallèle… donc cinq applications certes utilisées simultanément du point de vue du serveur mais aucune du point
de vue du travail…).
Le tableau suivant peut permettre d’évaluer l’usage fait par les utilisateurs des applications pressenties :
Ce sont bien les usages simultanés qui impactent le calibrage serveur, sous réserve que ceuxci aient été bien
évalués. Il reste évident qu’il ne s’agit pas de calibrer trop juste, mais de prévoir une marge de manœ uvre en
terme de réserve de puissance, afin de subvenir tant aux éventuels pics d’utilisation simultanée qu’aux
immanquables évolutions logicielles et leur cohorte de conséquences dont le nouveau profil de consommation de
ressources serveur.
c. Un gros serveur ou plusieurs petits ?
Le calibrage unitaire des serveurs RDS va bien sûr dépendre aussi du choix d’architecture et du nombre total de
serveurs, dans la mesure où l’on considère que c’est le nombre de serveurs souhaité qui détermine le calibrage
de chacun d’eux. On pourrait bien évidemment partir du concept inverse, à savoir que le calibrage unitaire
possible des serveurs en détermine le nombre, mais je préfère généralement réserver cette approche à une
optimisation financière ultérieure qu’à une démarche initiale volontaire.
Donc globalement, les considérations précédentes concernant les utilisateurs et les applications servent à
déterminer le besoin total en puissance, mémoire, processeur ou autre… Le problème est de choisir une
architecture pour disposer de cette puissance.
Plusieurs logiques de regroupements de serveurs peuvent être considérées (et/ou combinées), essentiellement
sur des critères fonctionnels, ce qui aboutit à un nombre minimum de serveurs déterminé par ferme.
Si l’on considère ensuite la puissance totale à fournir pour une ferme et que l’on divise par le nombre minimal de
serveurs obtenu précédemment, on obtient la puissance unitaire d’un serveur RDS de la ferme considérée.
Toutefois, il est possible :
● Que la puissance serveur unitaire soit trop importante au regard des possibilités techniques des
serveurs du marché au moment escompté.

● Qu’il soit économiquement plus intéressant de rediviser cette puissance sur de multiples plus petits
serveurs.
Méthodologiquement, il est toujours préférable de trouver d’abord l’adéquation « nombre minimum de
serveurs/puissance unitaire possible maximum », pour ensuite vérifier si un ratio « nombre supérieur de
serveurs/puissance unitaire inférieure » est économiquement, voire stratégiquement, plus intéressant.
L’intérêt économique peut être apporté par le fait que des serveurs « moins gros » constituent la plus grosse
part en volume des ventes, et que donc les tarifs et/ou les possibilités de négociation sont plus alléchantes dans
un environnement réellement concurrentiel.
L’intérêt stratégique peut venir du fait que si un gros serveur sur deux constituant la ferme RDS tombe en panne,
c’est 50 % de la population des utilisateurs concernés qui s’en trouve gênée (voire 100 % si l’on considère que le
seul dernier serveur disponible va devoir encaisser toute la charge…) ; alors que dans le cas d’une ferme de 5
serveurs plus petits, ce ne serait que 20 % des utilisateurs qui seraient directement touchés par la perte d’un
serveur et la répartition de charge sur les 4 « survivants » n’imposerait qu’un pic de charge supplémentaire de
5 % !
Vous l’aurez compris : je suis par défaut plus partisan de grandes fermes de petits serveurs (dont la mesure du

raisonnable s’entend), que de quelques gros serveurs. Mais cela s’évalue au cas par cas : moins de serveurs,
c’est aussi parfois moins de licences et toujours moins d’administration !
Une approche alternative satisfaisante serait la mise en œ uvre de multiples machines virtuelles "légères" sur
quelques gros serveurs hôtes basés sur HyperV. Cette solution déjà mise en œ uvre chez nombre de clients, a
plus que fait ses preuves à ce jour. Essayez, dans la mesure du possible, d’avoir une certaine redondance entre
les rôles de machines virtuelles sur des machines physiques. Vous minimiserez ainsi les points de rupture.
Souvenezvous de cette règle d’or : répartition fonctionnelle d’abord, segmentation physique ensuite.
2. Le choix des composants
Les composants matériels d’un serveur RDS sont généralement plus sollicités que la moyenne des autres types de
serveurs : cela vient du simple fait que le serveur RDS peut être simultanément utilisé par des utilisateurs aux
applications et profils différents.
Si elle reste la question numéro un que se posent les administrateurs quant à l’implémentation d’une solution
clients légers basée sur RDS, le choix des serveurs et de leurs composants ne devrait pas occulter le choix d’une
architecture globale judicieuse.
Si nous traitons les composants séparément, il reste entendu que nous n’envisageons d’acquérir que des serveurs
dignes de ce nom, c’estàdire conçus en bloc par des constructeurs pour en assurer/assumer les rôles.
a. Le(s) processeur(s)
Ces derniers temps les architecture processeur ont largement évoluées. Désormais, les serveurs du marché se
retrouvent nativement équipés de processeurs 64 bits. Rien ne vous empêche de les installer sous un système
d’exploitation 32 bits si cela est une contrainte technique ou applicative. Nous traiterons ici des processeurs 32
bits (et donc des versions systèmes associées) et traiterons les architectures 64 bits un peu plus loin dans le
chapitre.
Un processeur classique du marché (Intel Xeon par exemple) est cadencé en fonction des possibilités offertes par
son constructeur et de la période à laquelle on en projette l’acquisition. Il n’est donc pas très
intéressant/important de faire un comparatif des possibilités offertes par un tel processeur à 2,4 GHz plutôt
qu’un autre à 3 GHz : les deltas sont minimes et indignes d’intérêt (pour mémoire : doubler la fréquence du
processeur n’apporte qu’un gain de 25 % en terme de performances globales). Prenez ce qu’il y a !
Un processeur classique du marché intègre aussi une part de mémoire cache, dont on peut dire globalement que
plus il y en a, plus les performances sont bonnes. À titre d’information, doubler la taille de la mémoire cache de
second niveau équivaut à augmenter les performances d’un serveur RDS d’environ 10 %.

Le réel choix porte donc sur le nombre de processeurs dont nos serveurs RDS vont être dotés : un, deux, quatre
ou plus.
Un serveur monoprocesseur est rapidement limité, soit en terme de puissance brute, soit de saturation : si une
application consomme temporairement 100 % des ressources processeur, c’est l’ensemble du serveur et des
utilisateurs qui sont saturés. La démocratisation des processeurs MultiCore repousse toutefois ce problème.
Un serveur biprocesseurs présente a contrario, l’avantage d’une très faible probabilité de saturation, tout en
restant abordable en termes de coûts : il s’agit de plus en plus de serveurs d’entrée de gamme, parfois à moins
de 1 000 Euros ! Il reste toutefois dommage d’acquérir un tel serveur et de ne l’équiper que d’un seul processeur
en réservant le second « au cas où » : l’agrément d’utilisation en présence du second processeur est sans égal.
Les serveurs à quatre processeurs ou plus sont généralement réservés à d’autres usages que RDS (tel les
SGBD). Il reste bien entendu possible de les mettre en œ uvre, mais la puissance processeur autorise une telle
concentration d’utilisateurs avant d’être saturée que d’autres composants serveurs ne sont plus aptes à
répondre à la charge bien avant les processeurs, rendant souvent inutiles de telles machines (sauf exceptions…).
En clair : il n’est pas du tout certain qu’un serveur quadriprocesseur vaille deux serveurs biprocesseurs (et par
défaut, considérez que non). D’autant plus que l’ajout de processeurs supplémentaires n’est pas synonyme de
progression linéaire des performances : passer d’un monoprocesseur à un biprocesseur accroit les performances
brutes de plus de 50 % (et permet de bénéficier d’une capacité de « non saturation » plus grande), alors que
passer d’un biprocesseur à un quadriprocesseur n’ajoute que moins de 50 % de performances.
Vous l’aurez donc compris : privilégiez les biprocesseurs. Toutefois, dans le cas de systèmes 64 bits, les
quadriprocesseurs peuvent être avantageux.
Gardez aussi à l’esprit qu’un processeur chargé à 98 % n’est pas moins rapide que s’il est chargé à 2 % (mais

pas plus non plus…) : il est seulement très (trop ?) bien calibré !
b. La mémoire RAM
Un point très important.
La mémoire est le composant qui détermine le plus fréquemment le calibrage du serveur final. En effet, RDS est
un gros consommateur de mémoire vive, ce qui est logique du fait que de nombreux utilisateurs exécutent
simultanément l’ensemble de leur environnement informatique sur une même machine.
Pour mémoire, voici le tableau des possibilités offertes par Windows en fonction des différentes versions
disponibles :

Attention aux systèmes 32 bits standard : pour simplifier les exemples et les calculs, nous considérerons ciaprès
que leur capacité de gestion de 4 Go de mémoire RAM est complète, ce qui n’est dans la réalité pas vraiment le
cas (les services de terminaux se contentent bien souvent d’environ 1,5 Go).
Pour calibrer la mémoire vive, il va donc falloir procéder en deux étapes :
● Évaluer le besoin total en mémoire vive d’une ferme de serveurs :
■ En fonction des profils d’applications,
■ En fonction des profils d’utilisations,
■ En fonction d’une pondération risque d’erreurs/évolutions.
● Trouver la répartition entre les serveurs la plus adéquate possible :
■ En fonction des possibilités de Windows,
■ En fonction des possibilités du modèle de serveur pressenti,
■ En fonction des coûts.
À titre d’exemple, et bien qu’il s’agisse d’un ratio empirique de calibrage, fixons le contexte suivant et déroulons
notre illustration : 240 utilisateurs standards utilisant simultanément leur ERP, la messagerie Outlook, deux
applications bureautiques (Word, Excel, Navigateur Internet, etc.), un utilitaire Windows, le tout via un bureau
Windows standard.
Suite à une analyse très poussée des profils d’utilisation et d’application, nous arrivons à la conclusion que
chaque utilisateur consomme environ 50 Mo par session :
● 10 Mo pour la session RDP, le bureau Windows et l’utilitaire. Ce chiffre est une valeur représentative de
ce type.
● 10 Mo pour chaque application bureautique (donc 20 Mo au total).
● 15 Mo pour l’ERP (par exemple), et pour Outlook (donc 30 Mo au total).
Le besoin total en mémoire vive est donc de 240 x 60 Mo = 14 Go
À ce niveau, j’applique habituellement une pondération forfaitaire de 20 % visant à couvrir :
● Le risque d’erreur dans l’évaluation : soit de la simultanéité (il y a parfois plus de 240 utilisateurs
simultanés), soit de la charge unitaire des applications, etc.
● Le changement de version d’une ou plusieurs applications qui aurait des répercussions négatives sur
l’usage mémoire.
On arrive donc à un besoin total final en mémoire vive d’environ 17 Go.
Il nous reste maintenant à trouver la répartition de ces 17 Go entre les serveurs, la plus adéquate possible :
En fonction des possibilités de Windows
La version standard 32 bits ne gérant que 4 Go de mémoire vive, il nous faudrait en ce cas cinq serveurs
minimum, mais chacun d’eux serait alors quasisaturé (bien que l’exemple soit litigieux : si l’on considère les 14
Go de RAM nécessaires avant pondération, on peut se contenter soit de quatre serveurs saturés, soit de cinq
serveurs disposant de 3 Go de RAM chacun.
La version enterprise 32 bits gérant jusqu’à 32 Go de RAM, on pourrait théoriquement se contenter d’un unique
serveur, au mépris de toute redondance de serveur élémentaire. Deux serveurs dotés de 8 Go de RAM chacun
peuvent toutefois convenir, mais dans ce cas, nous aurions 120 utilisateurs par serveur et un serveur standard

risque d’être saturé du point de vue des autres composants (processeur notamment), nous obligeant à changer
de gamme.
Les versions 64 bits apportent désormais des possibilités nettement intéressantes en terme de gestion de
mémoire. C’est ce pourquoi Microsoft tend à ne plus supporter d’OS en 32 bits.
En fonction des possibilités du modèle de serveur pressenti
Les serveurs entrée de gamme savent désormais gérer des quantités de mémoire importante, mais il faut
toutefois être vigilant quant à des quantités de RAM approchant ou dépassant les 8 Go par serveur (hypothèse 2
serveurs sous Windows Enterprise 32 bits par exemple).
Quelle que soit la solution trouvée/retenue, elle ne peut être applicable que si et seulement si :
● Elle a été confrontée aux autres contraintes de calibrage de composants (processeurs, disques, etc.).
● Elle respecte les principes d’architecture préalablement définis (nombre de serveurs minimum,
fonctionnalités système minimum, etc.).
● Vous n’avez pas oublié que chaque serveur doit a minima faire fonctionner son système d’exploitation.
L’évaluation de la mémoire virtuelle nécessaire n’a, quant à elle, d’impact que sur le calibrage des disques durs,
s’agissant d’un fichier d’échange situé sur le disque dur.
c. Le(s) disque(s) dur(s)
Le disque dur d’un serveur RDS est :
Vivement sollicité par les utilisateurs pour leurs applications et leurs profils locaux.
Très vivement sollicité par le système pour la gestion de la mémoire virtuelle.
L’espace disponible sur le disque dur, bien que très important, n’est plus un problème depuis longtemps : les
capacités actuelles sont telles que tout serveur RDS correctement paramétré (c’estàdire ne disposant pas
directement de données utilisateurs) se suffit amplement de disques standards, dans la mesure d’une mémoire
virtuelle raisonnable (la taille standard admise est de 1,5 fois la quantité de RAM, 1,5 x 32 Go = 48 Go, cela n’est
pas négligeable).
C’est donc bien la vitesse de rotation du disque qui impacte le plus favorablement les performances des
architectures RDS, ainsi que sa constance de débit. C’est donc naturellement que nous préfèrerons un disque de
15 000 tours/minute en SCSI, plutôt qu’un 7 200 tours/minute en IDE…
La configuration minimaliste étant d’un disque dur par serveur, étudions plutôt les deux alternatives suivantes :
Deux disques durs par serveur
Le premier disque prend en charge le système, les applications et les profils utilisateurs, le second prend en
charge la mémoire virtuelle. Le fichier d’échange de la mémoire virtuelle est constamment sollicité, même si l’on
dispose d’une quantité de mémoire vive suffisante : disposer d’un disque et donc d’une tête de lecture/écriture
dédiée n’est parfois pas un luxe !
Trois disques durs par serveur :
Le premier disque prend en charge le système et les applications, le deuxième les profils utilisateurs, le troisième
la mémoire virtuelle. Cette approche est à privilégier dès lors que chaque serveur RDS adresse un nombre
important d’utilisateurs, les profils utilisateurs étant a minima synchronisés à l’ouverture et à la fermeture de
session, mais constamment sollicités en cours d’utilisation de la session de l’utilisateur.
Le problème apparaît pour les configurations serveurs d’entrée de gamme au format rack : tous n’acceptent pas
trois disques durs dans leur châssis, ce qui sera encore plus vrai si l’on envisage une quelconque redondance,

même à partir de deux disques…
3. Les redondances possibles
a. Le soussystème disque
Dans le système RAID, nous ne considérerons que les approches matérielles : le RAID logiciel assuré/assumé par
le système d’exploitation Windows ne saurait satisfaire en terme de performances un serveur RDS par ailleurs
déjà bien sollicité !
Le débat porte principalement sur le choix du niveau d’utilisation du RAID : niveau 1 ou niveau 5 ?
Le RAID 1 propose une redondance par miroir et nécessite deux disques durs physiques pour fonctionner (le
disque source qui fonctionne et le disque miroir qui est recopié en cas de défaillance du disque source).
Le RAID 5 propose une haute disponibilité par reconstitution/parité et nécessite au minimum trois disques durs
physiques pour fonctionner. Audelà de l’intérêt et de l’efficacité du système RAID 5, il faut se rappeler que ce
système est particulièrement performant en lecture, mais beaucoup moins en écriture… Or, dans un système RDS
qui écrit naturellement beaucoup et en permanence (profils utilisateurs mais surtout mémoire virtuelle), cet
handicap devient très rapidement rédhibitoire en terme de performances.
Le RAID 5 est donc à bannir des configurations RDS, sauf contexte très particulier et clairement identifié.
Il nous reste donc la seule solution RAID 1, mais avec cette lancinante question : quel intérêt aurionsnous à
sécuriser le soussystème disque dans une ferme de serveurs RDS équilibrés ?
En effet, si le disque dur d’un serveur en RAID 1 tombe en panne, il sera possible après redémarrage de travailler
sur le second disque en miroir ; mais c’est aussi le cas (et l’un des rôles) d’une ferme de serveurs RDS !
Le RAID 1 présente alors les avantages suivants :
● Lors du redémarrage, la charge par serveur RDS de la ferme est respectée puisque nous disposons
toujours du même nombre de serveurs.
● Lorsqu’une opération technique logique sensible doit être testée (mise à jour système ou applicative),
elle peut l’être sur un seul des deux disques, permettant un retour en arrière très simple et évitant
d’avoir à disposer d’un serveur de tests dédié.
● Lorsqu’une opération technique logique sensible doit être menée (mise à jour système ou applicative
n’ayant à tort pas été testée au préalable), elle peut l’être sur un seul des deux disques, permettant un
retour en arrière là aussi très simple.
Ces avantages peuvent être réels pour de petites fermes de serveurs, mais deviennent coûteux pour de
grandes fermes : sortir temporairement un serveur de la ferme n’est plus un problème. Si l’on considère le
classique coefficient de marge de manœ uvre de 20 % dans tout calibrage, on voit qu’à partir de cinq serveurs
équilibrés, le retrait de l’un d’eux pour quelque raison que ce soit n’a pas d’influence directe sur les performances
de l’architecture globale. Et le surcoût du RAID 1 (contrôleur + deuxième disque) est non négligeable.
Le deuxième problème est posé par les gammes de serveurs : entrée de gamme ou moyenne gamme, au format
tour ou au format rack.
Si l’on respecte le principe de calibrage à deux disques, il en faudra au total quatre pour implémenter du RAID 1.
Si l’on pense à trois disques, il en faut alors six…
Tous les châssis serveurs ne sont pas aptes à accepter six disques durs en interne, particulièrement les formats
rack, mais tous les contrôleurs RAID « entrée de gamme » ne sont pas non plus aptes à gérer efficacement trois
grappes de deux disques en RAID 1 !
À changement de gamme, changement de coût… Évaluez vos (réels) besoins.

b. L’alimentation
Dans la droite ligne du thème précédent, le choix d’une alimentation redondante pour chaque serveur RDS est à
évaluer en fonction des possibilités éventuellement déjà offertes par le calibre plus ou moins imposant de votre
ferme de serveurs RDS et la robustesse de votre système de courant secouru associé.
Elle s’avère par contre judicieuse dans le cas de monoserveurs ou en l’absence de réelle fiabilité électrique (bien
qu’en cas de sinistre, ce sont généralement les deux alimentations qui souffrent).
c. Les cartes réseaux
Au niveau des cartes réseaux, l’idéal reste de segmenter les flux :
● Frontaux : ce sont les échanges entre le serveur RDS et les clients.
S’agissant de flux permanents, mais à faible volume du fait des performances du protocole RDP, une carte réseau
1 Gb/s livrée désormais de série avec tout serveur respectable, ferait théoriquement l’affaire pour 8 300
utilisateurs forcenés consommant chacun 120 Kb/s pour leur session RDP. Ce sont les flux connexes (jobs
d’impressions, transferts de fichiers, etc.) qui peuvent généralement réduire cette importante capacité.
Mais si l’on considère une approche fonctionnelle qui nous fait constater que dans la plupart des cas, un serveur
RDS est mis à disposition pour 200 utilisateurs maximum, on voit que cette carte réseau standard assumera
facilement ses fonctions.
● Dorsaux : ce sont les échanges entre le serveur RDS et les autres serveurs (contrôleurs de domaine,
serveurs de fichiers ou d’applications, de messagerie, etc.).
Ces flux sont au contraire des précédents très volumineux et, au regard du nombre d’utilisateurs connectés sur
le serveur RDS considéré, permanents eux aussi. Une carte dédiée de 1 Gb/s constitue un minimum et,
rapidement, le besoin d’agréger plusieurs cartes ou de passer au 10 Gb/s peut se faire ressentir.
Souvenezvous que la vitesse des échanges entre les serveurs constitue, du point de vue de l’utilisateur, la
vitesse ressentie de son poste de travail, à savoir sa session RDP.
4. Les architectures alternatives
a. Les serveurs lames
Ce type de serveurs peut être particulièrement intéressant dans le cas de fermes de serveurs appelées à grandir
rapidement ou tout du moins à évoluer régulièrement.
Outre le gain de place, la modularité physique de chaque lame ou serveur au sein du châssis permet de modifier
facilement son architecture.
Il faut toutefois rester vigilant sur les possibilités de redondance de telles machines (alimentation, carte fond de
panier, etc.), ainsi que sur les techniques employées pour gérer le soussystème disque associé (performance et
redondance).
Les performances réelles sont elles aussi à mesurer avant de procéder à toute acquisition.
b. Les architectures virtuelles
Le principe est d’installer sur un serveur hôte une solution logicielle de virtualisation, tel HyperV ou encore
VMWare, laquelle permet de faire fonctionner plusieurs serveurs virtuels indépendants sur un seul et même
serveur physique.
Cette approche est très intéressante tant en terme de consolidation de serveurs que de souplesse pour votre

architecture.
c. Les architectures 64 bits
Nous l’avons vu dans le chapitre Tour d’horizon de Windows 2008 R2, les architectures 64 bits sont d’ores et
déjà disponibles et constituent l’orientation naturelle de nos platesformes. Cela se confirme notamment avec la
version 2008 R2 de Windows, disponible uniquement en version 64 bits.
Si l’intérêt des architectures 64 bits porte essentiellement sur les performances liées à l’adressage de la
mémoire, et dans notre cas sur la possibilité d’une version standard 64 bits de Windows de gérer de grandes
capacités de mémoire vive, toutes les applications ne sont malheureusement pas prêtes à fonctionner en mode
64 bits.
Le fait de faire fonctionner des applications pour l’instant 32 bits sur ce type de système s’accompagne d’une
baisse de performance liée à la conversion des requêtes entre les formats 64 et 32 bits.
À surveiller régulièrement toutefois : dès la disponibilité des applications souhaitées, une plateforme 64 bits
homogène sera très intéressante pour nos serveurs RDS !
Une architecture à deux niveaux peut permettre d’utiliser avantageusement et immédiatement les systèmes 64
bits : les applications 32 bits sont installées sur des serveurs 32 bits, auxquels accède une ferme frontale en 64
bits sur laquelle les utilisateurs se connectent et travaillent.
5. Le plan de montée en charge
Procéder à un plan de montée en charge reste la voie royale pour procéder à un calibrage serveur des plus
judicieux. Il n’est malheureusement pas toujours possible d’en réaliser un, par manque de temps ou de moyens
principalement, car il s’agit d’une étape longue et fastidieuse.
La première approche est donc d’en faire l’économie et de s’en référer aux indications fournies auparavant,
croisées avec d’autres sources d’informations, pour déterminer un calibrage présumé qui sera si possible validé
lors d’un pilote, et dans tous les cas mis à l’épreuve lors de la réelle montée en charge en production. Cette
approche doit donc être retenue uniquement si elle est admise, tant sur un plan contextuel (utilisateurs,
dirigeants) que financier (il faudra sûrement procéder à des rallonges budgétaires successives pour atteindre le
niveau de performances escompté).
Comme je vous l’ai indiqué, les informations contenues dans ce chapitre ne peuvent être considérées comme
exactes et vérité absolue : chaque cas en entreprise est différent. Mais ces mêmes informations restent réalistes
et basées sur l’expérience.
C’est par exemple le cas des évaluations empiriques de nombre d’utilisateurs simultanés sur tel ou tel calibre de
serveur : cela dépend de la façon de travailler des utilisateurs. Et pour un usage identifié, cela peut quand même
varier fortement : un Word en arrièreplan ne consomme pas la même mémoire vive que le même Word avec le
même document, mais réduit en barre des tâches !
C’est comme cela que l’on arrive à des évaluations/annonces du type : un utilisateur RDS standard consomme
environ 10 Mo de mémoire pour travailler normalement, ou encore qu’il est possible de mettre 200 utilisateurs
bureautiques sur un seul serveur avec 4 Go de RAM. Personnellement, je n’ai jamais vu cela… Mais il est sûr que
cela fait commercialement moins peur qu’une autre annonce, empirique elle aussi, de 50 Mo de RAM par
utilisateur !
La seconde approche, souvent réservée aux grandes entreprises et/ou aux projets stratégiques, est de réaliser
ce fameux plan de montée en charge.
Une grande erreur dans la réalisation des plans de montée en charge est de chercher à savoir quel calibre de
serveur est nécessaire pour accepter 100 utilisateurs de tel profil. C’est exactement l’inverse ! Le plan de montée
en charge permet de connaître à serveur donné, le nombre maximum d’utilisateurs que nous pourrons avoir avant
de passer en dessous d’un niveau de performances jugé correct.
Il doit donc être réalisé :

● Soit en testant un panel de serveurs mis à notre disposition, afin de déterminer quelle solution sera
retenue en fonction de critères économiques (et pas techniques).
● Soit en testant les serveurs pressentis lors d’une première approche empirique, afin de valider que l’on ne
s’est pas trompé.
Il ne doit surtout pas être réalisé en cherchant à savoir quelle charge représentent 10 utilisateurs, puis en
multipliant la charge par 10 pour obtenir la charge présumée de 100 utilisateurs et choisir la machine adéquate.
Cette méthode ne peut qu’être une indication, certes intéressante mais souvent fausse, pour pressentir les
machines à tester et/ou renforcer un peu plus notre évaluation empirique.
Il ne semble pas judicieux de rentrer ici dans le contenu détaillé d’un plan de montée en charge, lequel risquerait
de ne pas être adapté à votre situation. Il reste préférable d’en identifier les principales étapes :
Déterminer le périmètre du plan de montée en charge
À chaque profil fonctionnel de serveur doit correspondre un plan de montée en charge dédié : si vous devez
mettre en œ uvre trois fermes de serveurs RDS distinctes comprenant chacune d’elles des applications différentes
ou s’adressant simplement à des utilisateurs différents, vous devez procéder à trois plans de montée en charge.
Le but est donc pour un plan de montée en charge donné, d’une part de recenser l’ensemble des applications
utilisées pour une ferme donnée et d’autre part les profils des populations d’utilisateurs (simultanéité et
classification).
Déterminer les tâches habituelles exécutées par les utilisateurs
Chaque application peut être plus ou moins utilisée par une population d’utilisateurs : il s’agit de connaître avec
précision les usages faits des applications de notre ferme afin de les simuler.
Un Excel utilisé simplement pour visualiser un tableau ou tracer quelques bordures ne peut être comparé à un
classeur complexe avec moultes formules au service d’un contrôleur de gestion.
Déterminer le niveau de performance souhaité/supporté par les utilisateurs
Audelà de la simple satisfaction des utilisateurs, voire de leurs fantasmes, il est important de connaître le niveau
de performances en dessous duquel il ne faut pas descendre.
Une illustration peut être le temps de réponse pour l’affichage des caractères dans Word : une secrétaire à 250
mots/minute est moins tolérante qu’un directeur tapant avec deux doigts… Un autre aspect important : le temps
d’impression d’un document type, par exemple une facture client en caisse lorsque le client attend.
Créer le script ou paramétrer le programme qui simule la charge
Si pour un plan de montée en charge donné, vous êtes face à diverses populations d’utilisateurs (légers,
standards ou forcenés), vous devrez créer autant de scripts que de populations.
Préparer judicieusement le logiciel de suivi/monitoring
Dérouler le plan de montée en charge
Il s’agit dès lors de simuler progressivement les utilisateurs, par adjonction successive d’un petit nombre
d’utilisateurs (cinq à dix grand maximum), et de laisser tourner en boucle les scripts de tâches plusieurs fois pour
une durée significative (par exemple dix minutes).
Le moniteur de performances enregistre alors les données de charge et nous permet de savoir à quel moment
(donc à partir de combien d’utilisateurs) ce type de tâches est réalisé en dessous du seuil de performances
escomptées.
Analyser les résultats
Pensez à prendre en compte la charge induite par les logiciels utilisés pour la réalisation du plan de montée en

charge, pour mieux la déduire de vos résultats.
Soyez clairs et convaincants dans la présentation de vos résultats : il sera financièrement toujours compliqué de
demander des configurations plus nombreuses et/ou plus calibrées à l’issue d’un plan de montée en charge certes
bien réalisé, mais lui aussi déjà coûteux, alors que tous espéraient qu’il conduirait à une optimisation et une
réduction des machines nécessaires, et donc des coûts…
En résumé, le plan de montée en charge est important pour calibrer ses serveurs, mais ne peut se substituer à
une phase pilote menée avec des utilisateurs réels : les graphes et résultats techniques obtenus ne peuvent être
assimilés à la subjectivité bien réelle de tout être humain !

Aller plus loin avec le VDI (RD Virtualization Host)
1. Introduction
Virtual Desktop Infrastructure (VDI) ou encore infrastructure de virtualisation du poste de travail. Il s’agit là de la
combinaison originale des architectures virtuelles et des clients légers. On a connu de nombreuses révolutions
pour l’utilisateur final à ce jour, et ce de manière directe ou encore indirecte. De la consolidation de serveur en
environnement virtuel (HyperV), à la virtualisation d’application (AppV) en passant par la mutualisation des
ressources (RDS), tous les moyens imaginés à ce jour pour satisfaire les besoins des utilisateurs ont été mis en
œ uvre. Le dernier en date s’appelle donc VDI : sur un serveur hôte de virtualisation, sont installés plusieurs
systèmes clients Windows XP, Vista ou encore Windows 7, sur lesquels sont activés les services de terminaux via
l’accès Bureau à distance.
Les utilisateurs disposent dès lors de simples terminaux et chacun d’entre eux accède en RDP à son
poste/système, avec ses applications spécifiques. Plus poussé encore : ne donner accès qu’à une application
spécifique du système client virtualisé au travers de RemoteApp pour garantir la compatibilité de cette application.
L’intérêt de telles architectures réside dans le fait d’utiliser physiquement des terminaux, faciles à déployer et à

exploiter, tout en respectant la logique un utilisateur/un poste spécifique. Elles sont par exemple très adaptées
pour les salles de formation.
2. Mise en œuvre
Prérequis
L’infrastructure gravitant autour de VDI est relativement complexe et exige de nombreux composants :
● Un domaine Active Directory de niveau fonctionnel minimum Windows Server 2008.
● Un serveur hôte de virtualisation des services Bureau à distance.
● Un serveur hôte de session Bureau à distance en mode de redirection.
● Un serveur Connection Broker.
● Un serveur RD Web Access.
● Autant de machines clientes virtuelles que de connexion à mettre à disposition.
Installation
Nous assumons que les rôles des serveurs AD DS, RDS, Connection Broker et RD Web Access ont déjà été mis en
œ uvre durant les précédents chapitres.
Hôte de virtualisation des services Bureau à distance :
Pour installer le rôle de virtualisation des services Bureau à distance, accédez à la console de gestion du serveur
puis ajoutez le rôle Services Bureau à distance et le service de rôle Remote Desktop Virtualization Host :

Validez l’ajout des rôles requis, ici HyperV :
Sélectionnez les interfaces réseau à utiliser avec HyperV :

Un redémarrage du serveur est exigé avant d’utiliser les services installés.
Machines virtuelles clientes :
Provisionnez le nombre de machines virtuelles clientes souhaité depuis la console Gestionnaire HyperV. Installez
les OS et intégrezles au domaine Active Directory. Nous avons choisi ici d’installer un poste sous Windows XP SP3
et un poste sous Windows 7 :

Pour chacune des machines virtuelles clientes, appliquez la configuration cidessous :
Activez le Bureau à distance : clic droit Propriétés sur le poste de travail, paramètres d’Utilisation à
distance, cochez la case Autoriser la connexion des ordinateurs exécutant n’importe quelle version
du Bureau à distance.
Ajoutez les comptes des utilisateurs affectés à la machine virtuelle dans le groupe local Utilisateurs du
Bureau à distance : depuis la console précédente paramètres d’Utilisation à distance, cliquez sur
Sélectionnez des utilisateurs, puis ajoutez les utilisateurs à autoriser à se connecter à ce client.
Autorisez les appels de procédures distants (RPC) : lancez l’éditeur de base de registre regedit.exe,
accédez à la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer, éditez la

valeur de l’entrée AllowRemoteRPC et donnezlui la valeur 0x1.
Créez les exceptions sur le parefeu pour autoriser la gestion des services à distance : accédez au
Panneau de configuration, puis Parefeu Windows, et sélectionnez Autoriser un programme ou une
fonctionnalité via le parefeu Windows. Autorisez la Gestion des services à distance pour le profil de
domaine.
Ajoutez les sécurités sur le protocole RDP : pour gérer la machine virtuelle, le compte d’ordinateur du
serveur hôte de virtualisation des services Bureau à distance doit avoir les droits sur le protocole RDP.
Pour ce faire, ouvrez une invite de commande en tant qu’administrateur sur la machine virtuelle cliente
(cmd.exe), et saisissez les commandes cidessous en remplaçant domaine\srvhote$ par le nom de
votre domaine réel et de votre serveur hôte de virtualisation (par exemple w2k8forest\hyperv$) :
wmic /node:localhost RDPERMISSIONS where TerminalName="RDP-Tcp"

CALL AddAccount "domaine\srvhote$",1
wmic /node:localhost RDACCOUNT where "(TerminalName=’RDP-Tcp’ or

TerminalName=’Console’) and AccountName=’domaine\\srvhote$’" CALL
ModifyPermissions 0,1


net stop termservice
net start termservice
Serveur RD Web Access :
Autorisez le serveur RD Web Access à se connecter au serveur Connection Broker en ajoutant son
compte d’ordinateur dans le groupe local Ordinateurs Accès Web TS du serveur Connection Broker.
Configurez ensuite le serveur RD Web Access pour utiliser une source type Un serveur du
service Broker pour les connexions Bureau à distance et pointant vers le serveur Connection Broker :
Configuration
Une fois l’infrastructure en place, la configuration se fait au travers de la console Gestionnaire de connexion aux
services Bureau à distance depuis le serveur Connection Broker.

Lancez l’assistant Configurer les bureaux virtuels. Saisissez le nom de votre serveur hôte de
virtualisation et cliquez sur Ajouter. Si l’hôte est valide, le nom FQDN (Fully Qualified Domain Name) du
serveur apparaît dans la liste des serveurs hôtes.
Spécifiez ensuite le nom du serveur hôte de session Bureau à distance. Il est proposé à ce niveau là
d’activer la prise en charge des clients RDC 6.1 ou antérieures, et d’empêcher l’assistant de configurer le
serveur hôte de session Bureau à distance de manière automatique (il faudra donc le faire
manuellement).

Si aucun serveur web d’accès à distance n’a été spécifié jusquelà, saisissez son nom. Sinon, celuici est
détecté automatiquement.
Validez le récapitulatif des actions à appliquer et validez si tout est correct.

Validez le résultat des actions et laissez cochée la case Affecter un bureau virtuel personnel pour
lancer l’assistant d’affectation de bureau virtuel personnel. Il reste bien évidemment possible de relancer
cet assistant à tout moment par la suite depuis la console Gestionnaire de connexion aux services
Bureau à distance, sous Serveurs hôtes de virtualisation des services Bureau à distance Bureaux
virtuels personnels, en cliquant sur Affecter un bureau virtuel personnel.
Sélectionnez l’utilisateur et l’ordinateur virtuel associé. Si jamais le nom de l’ordinateur sélectionné ne
correspond pas à un nom FQDN, le message suivant apparaît :

Accédez alors à la console Gestionnaire HyperV depuis le serveur hôte de virtualisation des services
Bureau à distance, et renommez l’ordinateur avec son nom FQDN. Relancez l’assistant d’affectation de
bureaux personnels qui vous laisse continuer sans embûche. Terminez l’assistant.
Il est dès lors possible de se connecter via le navigateur internet à la page du serveur RD Web Access avec
l’utilisateur autorisé précédemment. Le bureau doit apparaître sous Programmes RemoteApp :
Cliquez sur Mon Bureau, la connexion au poste client Windows 7 s’effectue au travers du serveur hôte
de session Bureau à distance (RDS2008R2 ici).

3. Paramètres avancés
Interactions avec Active Directory
L’affectation d’un bureau virtuel à un utilisateur au travers de l’assistant décrit précédemment, affecte directement
les attributs de l’utilisateur dans l’Active Directory.
Si l’on accède aux propriétés de l’utilisateur "Leon" de l’Active Directory, sous l’onglet Bureau virtuel personnel,

l’activation de la case à cocher Attribuer un bureau virtuel à cet utilisateur a été activée, et le champ Nom de
l’ordinateur, renseigné avec la machine virtuelle associée.

Pour dissocier une machine virtuelle d’un utilisateur, décochez simplement la case Attribuer un bureau virtuel à
cet utilisateur et l’utilisateur concerné n’y aura plus accès.
Pool de bureaux virtuels
Il peut être intéressant de créer un pool de bureaux virtuels à mettre à disposition des utilisateurs pour assurer
une disponibilité de machines virtuelles plus élevée à l’utilisateur final. Cependant les restrictions cidessous
doivent être respectées :
● Les ordinateurs virtuels dans un pool de bureaux virtuels doivent être configurés de manière identique, y
compris en ce qui concerne les programmes installés.
● Un ordinateur virtuel peut être membre d’un seul pool de bureaux virtuels à la fois.
● Un ordinateur virtuel ne doit pas être à la fois membre d’un pool de bureaux virtuels et affecté à un
utilisateur en tant que bureau virtuel personnel.
● Un pool de bureaux virtuels n’est pas affecté de manière spécifique à un utilisateur. Plusieurs utilisateurs
peuvent partager le même pool de bureaux virtuels.
● Un seul utilisateur à la fois peut utiliser un ordinateur virtuel dans un pool de bureaux virtuels.
● Vous pouvez rendre plusieurs pools de bureaux virtuels disponibles par le biais de Connexions aux
programmes RemoteApp et aux services Bureau à distance. L’utilisateur voit une icône différente pour
chaque pool de bureaux virtuels.
● Les utilisateurs ne doivent pas enregistrer de fichiers sur un ordinateur virtuel qui fait partie d’un pool de
bureaux virtuels. Si un utilisateur ferme une session sur un ordinateur virtuel dans un pool de bureaux
virtuels, la prochaine fois qu’il ouvrira une session sur le pool de bureaux virtuels, il se peut qu’il soit
connecté à un ordinateur différent dans le pool de bureaux virtuels.

Si un utilisateur se déconnecte d’un ordinateur virtuel dans un pool de bureaux virtuels, lorsqu’il se
reconnectera, il sera reconnecté au même ordinateur. En revanche, s’il ferme sa session, la reconnexion
se fera sur un nouvel ordinateur virtuel.
Un ordinateur virtuel dans un pool de bureaux virtuels peut être configuré de façon à être restauré
automatiquement à son état d’origine après la fermeture de session de l’utilisateur. Toute modification apportée
par un utilisateur connecté sera annulée.
Pour ce faire, lancez la console Gestionnaire de connexion aux services Bureau à distance, sélectionnez Serveur
hôte de virtualisation des services Bureau à distance et cliquez sur Créer un pool de bureaux virtuels dans le
menu Actions. L’assistant s’exécute.
Sélectionnez les machines virtuelles à affecter au pool de bureaux virtuels.
Définissez les propriétés du pool de machines virtuelles et terminez l’assistant.

Un autre intérêt de définir des pools de machines virtuelles est de pouvoir définir des comportements différents
sur chacun d’eux :

● Possibilité de masquer le pool aux utilisateurs (pour raison de maintenance sur les machines du pool par
exemple).
● Possibilité d’activer l’enregistrement automatique des ordinateurs virtuels.
● Définir les règles d’accès aux périphériques et ressources ainsi que les paramètres d’affichage.

● Définir de nouveaux paramètres personnalisés propre au pool.
Le rendu côté client :
Lorsque l’utilisateur clique sur Mon pool, il ne sait pas directement sur quel ordinateur il sera redirigé, mais ce sera
à coup sûr une machine virtuelle du pool disponible à cet instant.
Supervision
La supervision d’accès aux ressources (machines virtuelles) se fait depuis la console Gestionnaire des services
Bureau à distance, qui énumère les machines ayant le rôle « Services de Bureau à distance »..
Pour la configurer, positionnezvous à la racine et cliquez sur Importer à partir du service Broker pour les
connexions Bureau à distance du panneau Actions. Saisissez le nom de votre serveur Connection Broker et

validez.
Déroulez l’arborescence Service Broker pour les connexions Bureau à distance, le nom de vos pools et la liste
des machines virtuelles doivent apparaître ainsi que les utilisateurs connectés sur chacun d’entre eux.
Rollback
Le processus de rollback (restauration) permet d’effectuer un retour rapide de l’état du système à un instant
spécifique, supprimant toutes données et programmes installés par l’utilisateur lorsque celuici ferme sa session.
La fonctionnalité est activée de base sur l’environnement. Pour l’utiliser, créez une capture instantanée (snapshot)
de la machine virtuelle dans l’état où vous souhaitez la restauration, et renommer cette capture RDV_Rollback.
Lorsque l’utilisateur affecté à la machine ferme sa session, la machine virtuelle est restaurée.

Attention lors de l’utilisation de cette fonctionnalité à faire en sorte d’empêcher l’utilisateur de stocker
des données localement, via stratégies de redirection de Mes Documents sur le réseau par exemple, au
risque de perdre toutes ses informations stockées en local durant sa session !
4. Mise en œuvre de RemoteFX sur un serveur RDVH
a. Prérequis
● Carte graphique avec GPU (12 VM max par GPU)
● Support du SLAT (Second Level Adress Translation)
■ EPT (Extend Page Tables) chez Intel
■ NPT (Nested Page Tables) chez AMD
● HyperV (GPU identique si LiveMigration)
● Optionnel : ASIC RemoteFX
b. Paramétrage de l’hôte
Ajouter la carte graphique dans le serveur (valider au préalable que le modèle supporte RemoteFX) et installer
les derniers pilotes disponibles.
Ajouter le rôle Services Bureau à distance.

Sélectionner Services de base et RemoteFX sous Hôte de virtualisation des services Bureau à distance.
À la fin de l’installation redémarrer le serveur.

c. Ajouter une carte vidéo 3D RemoteFX à une machine virtuelle
Une carte vidéo 3D RemoteFX ajoute le support de DirectX, par le biais d’un pilote WDDM, aux machines
virtuelles.
Aucune carte 3D n’est disponible par défaut sur les VM, celleci doit être ajoutée depuis le gestionnaire HyperV.
Les machines virtuelles disposant d’une carte virtuelle 3DRemoteFX consomment de la mémoire graphique
uniquement lorsqu’elles sont démarrées ou en état de pause.
Un « serveur RemoteFX » peut disposer jusqu’à 4 GPU identiques.
● Par défaut une machine virtuelle dispose d’un périphérique vidéo VMBus :

Le lancement de l’outil de diagnostic DirectX confirme qu’aucune fonction d’accélération 3D n’est disponible avec
la carte vidéo installée par défaut.
● L’ajout d’une carte 3D RemoteFX se fait depuis le gestionnaire HyperV machine virtuelle arrêtée.
Éditer les paramètres de la machine virtuelle, et Ajouter un matériel de type Carte vidéo 3D RemoteFX.
Configurer les paramètres de la carte.

Les options disponibles (Nombre de moniteurs/Résolution) sont les suivantes :
Nombre maximal de moniteurs Résolution maximale
1 ou 2 1024 X 768
1280 X 1024
1600 X 1200
1920 X 1200
3 1024 X 768
1280 X 1024
1600 X 1200
4 1024 X 768
1280 X 1024
La résolution et le nombre de moniteurs disponibles dans les VM déterminent la quantité de mémoire
nécessaire sur le(s) GPU du serveur RemoteFX.
Pour chacune des machines virtuelles disposants d’un adaptateur 3D RemoteFX, il est possible de

configurer la résolution et le nombre d’écrans disponibles dans la session distante. Cette
configuration détermine la mémoire qui sera réservée sur le(s) GPU pour cette machine, et par
extension le nombre de VM que pourra « héberger » le serveur. Cet élément capital est à prendre en
considération lors du dimensionnement d’une infrastructure VDI mettant en œ uvre RemoteFX.
Le serveur hôte RemoteFX vérifie avant le démarrage de chaque VM s’il est en mesure d’allouer la
mémoire nécessaire à son fonctionnement.
Le tableau ciaprès fournit un abaque élaboré par Microsoft permettant d’aider au dimensionnement des
serveurs RemoteFX :
Résolution Nombre maximum de moniteurs pris en charge dans la machine virtuelle
maximum
1 moniteur 2 moniteurs 3 moniteurs 4 moniteurs
1024 X 768 75 Mo 105 Mo 135 Mo 165 Mo
1280 X 1024 125 Mo 175 Mo 225 Mo 275 Mo
1600 X 1200 184 Mo 257 Mo 330 Mo Non supporté
1900 X 1200 220 Mo 308 Mo Non supporté Non supporté
● Détection du nouveau matériel dans la machine virtuelle :

Démarrer la machine virtuelle et ouvrir une session ; le système va détecter le nouveau matériel puis demander
le redémarrage de la machine virtuelle.
Après installation du pilote vidéo, il n’est plus possible de se connecter à la machine virtuelle par la connexion à
un ordinateur virtuel (via HyperV).

Il faut utiliser l’assistant de connexion à un bureau distant (mstsc.exe), directement depuis le serveur ou depuis
la machine distante.
Une fois la connexion établie et la session ouverte, dans le gestionnaire des périphériques de la machine
virtuelle, on trouve une nouvelle carte graphique.
Le lancement de l’outil de diagnostic DirectX confirme que l’accélération 3D est désormais disponible dans la
machine virtuelle.

● Amélioration de l’expérience utilisateur
L’ensemble des paramètres cidessous peut être distribué par une GPO (conseillé). Ces paramètres
sont situés sous Configuration ordinateur\Modèles d’administration\Composants
Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Environnement de session
à distance.
Lancer gpedit.msc et positionner les paramètres comme suit :
● Optimiser l’expérience visuelle… sur Activé.
● Taux de captures d’écran sur Le plus élevé.
● Qualité d’affichage des images sur Moyen ou Élevé en fonction du réseau disponible.

Il est nécessaire de redémarrer la machine virtuelle après configuration du paramètre pour sa prise en compte.
Il faut utiliser un thème Aero pour bénéficier d’une expérience visuelle optimale dans la machine
virtuelle.

d. Prise en charge de RemoteFX depuis un poste client
Il est nécessaire de disposer du client d’accès distant « RDC 7.1 » (protocole RDP 7.1) pour prendre en charge
RemoteFX (Windows 7 SP1 par exemple).
Configuration de la connexion d’accès à distance :
Positionner les options d’affichage sur Qualité optimale (32 bits).

Positionner l’indice de performance sur LAN (10 Mbits/s ou plus).

Vérification du fonctionnement
Pour s’assurer que la connexion utilise bien RemoteFX dans la machine virtuelle, il convient de vérifier
l’observateur d’événements :
Sous WindowsRemoteDesktopServicesRdpCoreTS/Admin, on trouve l’évènement d’ID 2 validant le

fonctionnement.
En outre, on constate également la disponibilité de l’interface Aero (flip 3D).
Ou encore les excellentes performances vidéo…

Maintenant quelques exemples pour bien mesurer les apports de RemoteFX :
● Lancement d’un jeu utilisant DirectX :
Avec la carte 3DRemoteFX, le jeu fonctionne convenablement :
Sans la carte 3DRemoteFX, il ne s’installe pas :

● Lancement d’un jeu en flash3D :
Avec la carte 3DRemoteFX, le jeu fonctionne convenablement et de manière fluide :

Sans la carte 3DRemoteFX, l’affichage est dégradé et le jeu saccade :

Enfin, les tests menés avec des applications plus lourdes de type client/serveur ou CAO ont également donné
des résultats pour le moins « bluffant »…Toutefois, il ne faut pas oublier que la bande passante réseau
consommée nécessite d’être sur un réseau local.
5. Installation et paramétrages de la redirection USB avec RemoteFX
a. Introduction
De plus en plus de périphériques connectés aux postes de travail utilisent une interface USB : Smartphones,
Lecteurs biométriques, Téléphone sur IP, Multifonctions...
Or jusqu’à présent la majorité d’entre eux n’était pas supportée dans un environnement VDI ce qui était un frein
à son adoption. L’utilisation conjointe de la redirection « High level RDP » et USB RemoteFX va probablement
changer la donne…
b. Périphériques supportés
La liste cidessous est celle officiellement supportée par Microsoft. En revanche, d’autres périphériques non listés
peuvent également fonctionner.
Périphérique Support Méthode de

redirection
Imprimante Tout en Un Oui Redirection RemoteFX

(RFX)
Imprimante Oui Impression simplifiée

(Easy Print)
Scanner Oui Redirection RFX
Lecteur Biométrique Uniquement dans la Redirection RFX

session
Caméra Numérique (PTP) Oui Redirection PMP
Media Player Oui Redirection PMP

Webcam Oui (sur réseau local) Redirection PMP
Voix sur IP Oui (sur réseau local) Redirection RFX
Son Oui Redirection audio
Lecteur CD/DVD Lecture uniquement Redirection de lecteur
Disque dur ou carte flash Oui Redirection disque
Lecteur « Smart card » Oui Redirection « Smart

card » (carte
intelligente)
Connecteur USB vers série Oui Redirection RFX
Adaptateur réseau USB Bloqué N/A
Écran USB Bloqué N/A
Souris et clavier USB Oui Redirection des entrées
c. Comparaison entre USB RemoteFX et HighLevel RDP
RemoteFX USB RDP HighLevel
Pilotes nécessaires sur le client ? Non Oui
Pilotes nécessaires sur le serveur ? Oui Non
Méthode de redirection pour tous les Oui Non

périphériques USB ?
Usage simultané du périphérique depuis Non Oui

plusieurs sessions ?
Optimisation réseau LAN, comme le reste LAN et WAN

de RemoteFX
d. Schéma de l’architecture

Un des avantages de la redirection USB RemoteFX est qu’il n’est pas nécessaire de disposer de pilotes de
périphériques spécifiques installés sur les clients.
Lors de l’utilisation d’un périphérique USB, la partie cliente utilisera un pilote générique RemoteFX afin de se
connecter à un hub USB. Dans le même temps, côté serveur, le hub USB RemoteFX utilisera les pilotes natifs
(installés préalablement dans la VM) pour communiquer avec le périphérique (au travers d’un service de proxy).
e. Configuration côté « client »
La première étape consiste à autoriser la redirection USB RemoteFX depuis le poste client vers la session RDP.
Soit localement via gpedit.msc, soit via les stratégies de groupe en appliquant ce paramètre sur toutes les
machines virtuelles disposant de la carte 3D (conseillé).
Sous Configuration ordinateur\Modèles d’administration\Composants Windows\Services Bureau à

distance\Client Connexion Bureau à distance\Redirection de périphérique USB RemoteFX.
Paramètres :
Autoriser la redirection de protocole RDP des autres périphériques USB RemoteFX pris en charge à partir de
cet ordinateur sur Activé
Droits d’accès de la redirection USB RemoteFX : Administrateurs et utilisateurs
Redémarrer le PC pour prendre en compte le nouveau paramétrage.

Afin de pouvoir mener un test complet audio/video nous allons également activer la redirection audio et
enregistrement audio dans notre machine VDI :
Par défaut la redirection de l’enregistrement audio est activée sous Windows 7 (contrairement à
Windows 2008 R2). Toutefois si ce n’était pas le cas, il faut explicitement le spécifier au travers de la
stratégie de groupe Configuration ordinateur\Stratégies\Modèles d’administration\Composants
Windows\Services Bureau à distance\Hôte de la session Bureau à distance\Redirection de
périphérique et de ressource.
Mettre le paramètre Autoriser la redirection de l’enregistrement audio sur Activé, puis redémarrer
la machine virtuelle.
f. Validation du fonctionnement pour différents périphériques
● Redirection audio/vidéo via une Webcam
Après le redémarrage du PC, lancer le client RDC et dans l’onglet Ressources locales sélectionner Autres…
On constate désormais la présence sous Autres périphériques USB RemoteFX d’une webcam que nous allons

pouvoir rediriger dans notre session VDI.
Pour ce faire, cocher le périphérique à rediriger et valider par OK.

Ensuite activer la redirection audio et enregistrement audio, toujours dans l’onglet Ressources locales.

Lancer une connexion bureau à distance vers la machine VDI.
Un message d’avertissement apparaît, indiquant que le périphérique USB qui va être redirigé ne sera plus
disponible localement pendant la durée de la session.
Le nouveau périphérique est détecté et installé dans la machine virtuelle ; la webcam USB apparaît maintenant
dans le gestionnaire de périphérique.
Afin de valider le bon fonctionnement de la redirection USB RemoteFX, configurer par exemple une session

audio/video avec MSN Messenger :
● Redirection d’une imprimante multifonctions USB
Le PC client dispose d’une imprimante multifonctions (imprimante / scanner).

Lancer le client RDC et dans l’onglet Ressources locales sélectionner Autres…, cocher la redirection de
l’imprimante USB.
Lancer une connexion bureau à distance vers la machine VDI et ouvrir une session.
Lancer l’assistant d’ajout d’une imprimante et sélectionner Ajouter une imprimante locale.

Créer une imprimante, choisir Port d’imprimante virtuelle USB, et installer les pilotes.
La nouvelle imprimante est maintenant disponible dans la session bureau à distance.
On constate que l’imprimante passe en mode « hors connexion » sur la machine cliente.

Pour rappel il n’est pas possible d’utiliser simultanément l’imprimante localement et à distance (VDI) lors d’une
redirection USB RemoteFX.
La fonctionnalité Scanner est également disponible dans la session bureau à distance :
À la lumière de ces résultats, on peut aisément imaginer les perspectives qu’offre l’utilisation de RemoteFX…
En effet, de nombreux projet VDI n’ont jamais vu le jour car les limites actuelles ne permettaient pas d’adresser
toutes les populations d’utilisateur.
Désormais, que l’on soit un dessinateur dans un bureau d’étude, ou une assistante RH utilisant une imprimante
USB dans son bureau, le VDI devient enfin une solution crédible que l’on pourra déployer dans tous les services

de l’entreprise.

Services-RDS de Windows SERVER 2008 R2

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Services-RDS de Windows SERVER 2008 R2

Transféré par

Droits d'auteur :

Table des matières 1

6. Quelques idées reçues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3. Plate-forme d'application Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

9. Autres nouveautés ou améliorations. . . . . . . . . . . . . . . . . . . . . . . . . 160

5.3 Utilisation du portail par les clients . . . . . . . . . . . . . . . . . . . . . 225

11.1.4 Quelles fonctionnalités RemoteFX fournit-il ? . . . . . . . 287

2.3 Haute disponibilité avec redirecteurs dédiés et NLB . . . . . . . . 314

4.4 Les architectures alternatives. . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Les chapitres du livre :

© ENI Editions - All rights reserved - adamo diarra - 1-

© ENI Editions - All rights reserved - adamo diarra - 1-

© ENI Editions - All rights reserved - adamo diarra - 1-

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 3-

- 4- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 5-

- 6- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 1-

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 3-

- 4- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 5-

© ENI Editions - All rights reserved - adamo diarra - 1-

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 3-

- 4- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 5-

© ENI Editions - All rights reserved - adamo diarra - 1-

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 3-

- 4- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 5-

- 6- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 1-

Systancia : la suite logicielle Applidis propose un package d’outils de management et quelques fonctionnalités

Neoware et HP partageaient le leadership avec Wyse : depuis que HP a racheté Neoware fin 2007, le « couple »

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 3-

- 4- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 5-

- 6- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 1-

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 1-

● Support des extensions de vecteurs avancés (AVX, Advanced Vector Extensions) permettant d’améliorer

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 1-

- 2- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 3-

- 4- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 5-

Une VM invitée est considérée comme « intelligente » si son système d’exploitation a conscience de tourner au­

Virtual Service Client (VSC) : le VSC est un client tournant en mode noyau, qui agit comme un « solliciteur » de

- 6- © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 7-

● Interface WMI : intégration d’une nouvelle interface WMI (Windows Management Instrumentation) qui

● Stratégie de groupe : support de l’Active Directory (GPO) afin de paramétrer la machine hôte ou les

Supposons également que nous ayons deux VM, une avec 4 Go de RAM et l’autre avec 8 Go (préconisés par les

- 8- © ENI Editions - All rights reserved - adamo diarra

La nouvelle fonctionnalité de mémoire dynamique, lancée avec le Service Pack 1 de Windows 2008 R2, permet

© ENI Editions - All rights reserved - adamo diarra - 9-

- 10 - © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 11 -

Comme la gestion dynamique de la mémoire n’est effective qu’après le chargement du système (au

- 12 - © ENI Editions - All rights reserved - adamo diarra

© ENI Editions - All rights reserved - adamo diarra - 13 -

- 14 - © ENI Editions - All rights reserved - adamo diarra

Une VM invitée est considérée comme « intelligente » si son système d’exploitation a conscience de tourner au

● Système de validation de la conformité du système (SHV System Health Validator) : cette partie

● Majority Node Set : dans celuilà, chacun des nœ uds dispose d’une réplique locale du disque Quorum.

À michemin entre la MMC Utilisateur et ordinateurs Active Directory et la console PowerShell, cette nouvelle