Windows Server 2008 R2 : Services de bureau distants - Manuel du propriétaire

L’utilisation des services Bureau à distance avec Windows Server 2008 R2 offre une large gamme de scénarios de déploiement utilisant de nouveaux rôles de serveurs et d’autres fonctionnalités.

Kristin Griffin

Il n'est pas rare pour les gens qui ont l'expérience de Services Terminal Server sur Windows Server 2003 pour être incertain de quel soutien des services de rôle Remote Desktop Services (RDS) qui utilisent des cas. Pas tout le monde a le temps de bien concevoir un déploiement, soit — c'est souvent un cas de « déployer tout d'abord, poser des questions plus tard ».

RDS dans Windows Server 2008 R2 est assez différent de Services Terminal Server dans Windows Server 2003. Cette version antérieure a soutenu seulement un Terminal Server et un serveur de licences dans l'édition Standard.

RDS appuie séances et gestion des licences, avec nombreuses améliorations à l'utilisateur l'expérience et des fonctions de gestion de licence. Il comprend également le soutien de machine natif de virtuelle (VM), ainsi que les rôles de serveur pour faciliter la découverte, le courtage de connexion, les batteries de serveurs (pour les déploiements à grande échelle et la redondance) et de sécuriser l'accès WAN.

Au cours des prochains mois, vous apprendrez comment mieux débuter à l'aide de RDS, à partir de scénarios familiers comme prestation de serveur unique session et de passer ensuite à Virtual Desktop Infrastructure (VDI), ce qui est nouveau dans Windows Server 2008 R2. Puis vous découvrirez plus grands scénarios de déploiement à l'aide de batteries de serveurs hôte de la Session RD et agent de connexion RD, activation de la découverte à l'aide de la RD Web Access et permettant aux scénarios WAN avec RD Gateway.

Livraison de Session serveur unique

Anciennement Terminal Server, le serveur hôte distant de Session de bureau (RD Session Host) est le rôle de serveur RDS. Il peut fournir des ordinateurs de bureau complets et de demandes individuelles, appelés programmes RemoteApp. Il est idéal pour la livraison des applications hautement évolutive. Plusieurs utilisateurs peuvent se connecter à un serveur hôte de la Session RD et exécuter des applications indépendamment les uns des autres.

Bien que n'importe quel serveur Windows peut accepter des connexions entrantes simultanées de RDP jusqu'à deux à des fins administratives, seulement un serveur hôte de la Session RD peut soutenir plus de deux connexions à distance, tout en permettant encore toutes les fonctionnalités avancées de Remote Desktop Protocol (RDP) 7.

Un déploiement de serveur unique est mieux adapté pour les environnements plus petits, comme un petit bureau de l'entreprise ou de branche. Un seul serveur est aussi le scénario RDS plus facile à déployer. Vous aurez besoin de rappeler ce qui suit :

  • Le serveur unique limite le nombre de sessions qui peuvent être pris en compte.
  • Un déploiement d'un serveur est une source unique de défaillance. Si vous perdez le serveur, toutes les connexions sont touchées. Il n'y a aucune redondance.

Activation de la RD hôte de la Session

Pour activer un serveur RD hôte de la Session, vous devez d'abord installer le rôle RDS sur le serveur de Windows. Installez ensuite le service de rôle RD hôte de la Session. Comme vous allez grâce à l'installation, vous aurez à :

  • Choisir d'exiger l'authentification de niveau réseau (NLA) pour les ouvertures de session. NLA permet l'authentification des utilisateurs avant de créer une session complète sur le serveur hôte de la Session RD. Cela donne plus rapide d'ouverture et protection contre les tempêtes de connexion intentionnelle pouvant conduire à un déni de Service (DoS).
  • Ajoutez les groupes d'utilisateurs que vous souhaitez autoriser l'accès au serveur hôte de la Session RD sur le groupe utilisateurs du Bureau à distance sur le serveur.
  • Configurez les options d'expérience utilisateur par audio permettant (ou invalidante) et la lecture vidéo, enregistrement audio et Composition Desktop (activation Desktop Composition permet aux caractéristiques Aero).
  • Spécifier un mode de licence pour le serveur. Chaque utilisateur ou l'appareil a besoin d'une licence pour se connecter à un serveur hôte de la Session RD. Choisissez l'octroi de licences par utilisateur ou par le périphérique pour ces connexions. Vous n'avez pas de mettre en place un serveur de licences immédiatement parce qu'il y a une période de grâce.

Il est facile de mettre en place le côté client. Le client de Remote Desktop Connection (RDC) fait partie du système d'exploitation Windows. Pour s'assurer d'avoir la meilleure expérience de l'utilisateur, vous devez installer le dernier client RDP si vous utilisez une version de Windows antérieures à Windows 7. Vous pouvez Télécharger les plus récents clients sur le site Web de Microsoft.

Licences requises

Une fois la période de grâce de licences est passé, vous devez posséder une licence pour chaque utilisateur ou dispositif de connexion pour vous connecter à un serveur hôte de la Session RD. Vous aurez également besoin d'installer un serveur de licences de la RD. Vous pouvez installer le service de rôle RD licences sur le même serveur — le service n'est pas très exigeant — ou sur un serveur distinct.

Vous devrez acheter des licences d'accès Client RDS (CAL) et de les installer sur le serveur de licences de la RD. Ces CALs RDS sont liés au serveur, mais RDS vous permet de les déplacer de nouveau matériel si nécessaire. N'oubliez pas que RDS appuie par utilisateur et par périphérique de licence. Le modèle que vous choisissez doit dépendre de savoir si vous avez plusieurs utilisateurs ou des ordinateurs. RDS n'a pas de licences utilisateur simultanées et les licences que vous choisissez doivent correspondre à la mode pour lequel vous configurez le serveur hôte de la Session RD.

Installer le service de rôle RD Licensing tout comme vous l'avez fait le service de rôle RD hôte de la Session. Ensuite, vous devez :

  • Activer le serveur de licences de la RD
  • Installez des CALs RDS afin que le serveur de licences de la RD eux peut allouer aux utilisateurs et aux dispositifs
  • Indiquer le serveur hôte de la Session RD pour utiliser le serveur de licences de RD (vous devez faire cela même si les services de deux rôles sont situées sur la même machine)

Dimensionnement de serveur

Une des questions plus courantes de nouvelles personnes à la session d'hébergement est combien de personnes peut utiliser le serveur en même temps. Malheureusement, il n'y a pas de réponse simple à cette question. Elle dépend entièrement des conditions telles que, mais non limité à, où les gens des applications sont en cours d'exécution et le type de données avec laquelle les gens travaillent.

Beaucoup de gens estimer la taille basé sur un projet pilote pour obtenir les chiffres réels pour eux-mêmes. Pour aider à la modélisation de l'utilisation, le groupe de produits RDS a créé un livre blanc et un outil de simulation de charge. Heureusement, Windows Server 2008 R2 est 64 bits seulement, donc la mémoire n'est pas un goulot d'étranglement qu'il peut être sur un système d'exploitation 32 bits.

Vous pouvez virtualiser un serveur hôte de la Session RD, mais vous verrez probablement une réduction du nombre de sessions simultanées, qu'il peut prendre en charge. N'oubliez pas de modèle sur le même type de machine (physique ou virtuel) vous avez l'intention d'utiliser. Si vous construire un serveur virtuel de la RD hôte de la Session, vous devez probablement utiliser un serveur avec un processeur de traduction d'adresses de second niveau (becs) afin de réduire les frais généraux de mappage de mémoire entre la machine physique et les VMs. Pour réduire les frais généraux, il est également conseillé d'utiliser un hyperviseur de Type 1 comme Hyper-V, pas un Type 2.

Plein de bureau Sessions vs. RemoteApps

Hôte de la Session RD serveurs support deux modèles de prestation de demande : séparent les ordinateurs de bureau complets du bureau local ou programmes RemoteApp qui intègrent visuellement avec le bureau local. Ce dernier apparaît à l'utilisateur que les applications locales. RemoteApp programmes sont les meilleures pour les environnements où les utilisateurs exécuter un mélange d'applications locales et distantes parce qu'ils n'auront pas à basculer entre deux ordinateurs de bureau.

RemoteApp programmes lancés par le même utilisateur et sur le même serveur seront exécutera dans la même session. Vous aurez besoin seulement une copie du profil ouvert. Cela permettra de réduire les frais généraux sur le serveur, car vous aurez seulement à lancer un exemplaire des processus de base nécessaires à l'exécution d'une session.

Il s'agit d'un aperçu rapide de déploiement de serveur unique, ce que vous pouvez utiliser pour des séances, certaines différences entre les sessions et RemoteApps et le modèle de licence de RDS. Le mois prochain, vous allez être introduits à Microsoft VDI.

Pour des instructions détaillées sur la façon de déployer des directives RDS et design, optez pour la Windows Server 2008 r2 Remote Desktop Services Resource Kit, de Microsoft Press.

Kristin Griffin

Kristin Griffinest un MVP de Services Remote Desktop. Elle modère un forum de Microsoft dédié à aider la communauté informatique sur serveur (social.technet.microsoft.com/Forums/en-US/winserverTS/threads/) et tient à jour un blog RDS à blog.kristinlgriffin.com. Elle contribue à de Mark Minasi Mastering Windows Server 2008 et livres 2008 R2 (tous deux de Wiley), elle a coécrit également la "Microsoft Windows Server 2008 Terminal Services Resource Kit" (MS Press, 2008) et le "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (sorti en décembre 2010), avec Christa Anderson.

Contenu associé

SIDEBAR

RDS FAQ

Voici plusieurs questions communes, j'entends au sujet de la configuration et l'utilisation des Services de bureau distant (RDS), et les réponses pour les résoudre.

Q.   J'ai remarqué que les exécutables différents dans le gestionnaire des tâches en cours d'exécution lorsque je démarre un RemoteApp de lorsque j'exécute un bureau complet. Pour quelle raison ?

R : RemoteApps et ordinateurs de bureau complets utilisent différents obus et des mécanismes d'ouverture de session. PC de bureau complet utilisez l'Explorateur.EXE pour présenter l'utilisateur avec le Bureau, tandis que RemoteApps utiliser RDPSHELL.EXE. RemoteApps utiliser RDPINIT.EXE, l'équivalent de RemoteApp de USERINIT.EXE utilisés dans les sessions de bureau complet, qui à son tour les deux lance RDPSHELL.EXE et mises à jour de la barre des tâches du côté client et traite la logique de la fermeture de session.

Q. avez-vous toujours besoin de verrouiller le serveur lorsque vous utilisez des programmes RemoteApp ?

R : Absolument. Les programmes RemoteApp sont une commodité d'affichage, pas une fonction de sécurité. Si un utilisateur peut obtenir au système de fichiers, ils peuvent exécuter tout fichier exécutable qu'ils ont accès, ainsi vous devrez verrouiller le serveur. Vous pouvez utiliser AppLocker (ou stratégies de Restriction logicielle), autorisations NTFS et stratégie de groupe pour verrouiller descendant vos serveurs.

Q.   Pouvez-vous configurer un serveur de seulement permettre aux utilisateurs de se connecter via RemoteApps et bloquer un utilisateur de se connecter à l'ordinateur de bureau ?

R : Non, cette option n'est pas supportée.

— K.G.