Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2008 > Novembre >  Windows Server 2008 : présentation virtualisati...
Affichage du contenu : côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
Windows Server 2008
Presentation Virtualization with Enhanced Terminal Services
Joshua Schnoll
 
At a Glance:
  • New features in Windows Server 2008 Terminal Services
  • Using TS Gateway for remote access
  • Load-balancing with TS Session Broker

Virtualization is a hot term these days, though most of the time people think it relates only to virtual machines and the virtualization of operating systems. However, Terminal Services has been abstracting the presentation layer of remotely run applications and desktops since the release of Windows NT 4.0. Terminal Services has come a long way since that time, and Windows Server 2008 delivers a mature, robust presentation virtualization platform. I will focus the key areas of improvement in Terminal Services.

What's New in Terminal Services
Terminal Services in Windows Server 2008 has many new features and capabilities:
Terminal Services RemoteApp One of the great changes in Windows Server 2008 is the ability to remote a single application. In previous versions of Terminal Services, the entire remote desktop was transmitted, even if you only wanted to access a single application. This was often confusing to users because some applications appeared on the remote desktop (via Terminal Services) and some on the local desktop—and remembering which desktop had which application could be challenging. Now, applications accessed through Terminal Services look and behave as if they were running on the end user's local computer.
Terminal Services Web Access High on everyone's wish list was a simple way for end users to launch applications. TS Web Access meets that need by allowing administrators to publish individual applications to a Web page. TS Web Access includes a default Web page that can be deployed right out of the box, but it also can be customized and integrated into a SharePoint site. In order to launch a TS RemoteApp with TS Web Access, the user visits a Web page (accessed either from the Internet or intranet), sees a list of all the available applications, and clicks on the one he wants to launch.
In Windows Server 2003, a separate ActiveX control called the Remote Desktop Web Connection (RDWC) was required to enable a connection from a browser. Now the control has been built right into the main Remote Desktop Connection (RDC) client, so nothing needs to be downloaded or installed to the client. Moreover, the full Remote Desktop Protocol (RDP) feature set is supported, which wasn't the case with the old RDWC client.
Terminal Services Gateway TS Gateway is one of the most significant new features in Windows Server 2008. RDP traffic runs over port 3389, and one of the major issues administrators had when deploying a terminal server to users outside the firewall was having to either open that port in the firewall (not recommended) or use a separate VPN solution (costly). With TS Gateway, the RDP traffic is tunneled over HTTPS (port 443) to establish an encrypted connection between remote users on the Internet and the terminal server (or remote PC). Even better, the scenario works great even if the user or terminal server is located behind a network address translation (NAT) traversal-based router.
TS Gateway can be coupled with another feature of Windows Server 2008, Network Access Protection (NAP), to help ensure the health of client machines before granting access to Terminal Services resources.
Terminal Services Session Broker Windows Server 2000 introduced Network Load Balancing (NLB) and, though it works really well for Web servers, it wasn't ideal for load balancing Terminal Services. The new TS Session Broker provides a great alternative by expanding the Session Directory capabilities of Windows Server 2003 to enable session-based load balancing.
With TS Session Broker, new sessions are distributed to the least-loaded server within the farm and users don't have to know where a session was established in order to reconnect to an existing session. IT managers can use the feature to map the IP address of each Terminal Server to a single DNS entry. This configuration can also provide fault tolerance; if one of the farm servers is unavailable, users will connect to the next least-loaded server in the farm.
Terminal Services Easy Print Printing has historically been the bane of many an administrator's existence in a Terminal Services environment. With matching print drivers required on both server and client machines, end users had less flexibility to install printers while administrators had to worry about managing print drivers on the server. With TS Easy Print, in contrast, users can now reliably print from TS RemoteApp or a full desktop session to a local print device, whether it is attached directly or via a network. The best part is that printers can now be supported without it being necessary to install drivers on the terminal server.
When a user wants to print from a TS RemoteApp program or desktop session, he will see the full printer properties dialog box from the local client and have access to all the printer functionality (such as watermarks, collating, and stapling). When the user prints, the print job is rendered with the Microsoft XPS file format on the server and sent to the client. Furthermore, with TS Easy Print, administrators can use Group Policy to limit the number of printers redirected to just the default printer, thereby reducing overhead and improving scalability.
Those are the "big ticket" features in Windows Server 2008. We will revisit TS RemoteApp, TS Web Access, TS Gateway, and TS Session Broker later in this article. First, let's take a look at some other great but less prominent features in this release.

Security Features
Security has been beefed up in the new release of Terminal Services.
Network Level Authentication (NLA) and Server Authentication (SA) With previous versions of TS, a denial-of-service or man-in-the-middle attack could have been launched against the logon screen of the terminal server, as users were presented with the logon screen after clicking Connect on the RDC client. Now NLA authenticates the user, client machine, and server credentials against each other before a TS session is spun up on the server and the logon screen is presented to the user. Server Authentication uses Transport Layer Security (TLS) to help ensure that clients are connecting to a legitimate terminal server and not some rogue machine.
Single Sign-On Users want to be able to use one set of credentials (a user-password combination or a smart card and PIN combination) to authenticate just once, and not to be asked over and over for those credentials each time they want to use a new resource. With this release, domain-joined machines running Windows Vista or Windows Server 2008, connecting to a Windows Server 2008-based terminal server or TS Gateway, can now utilize single sign-on.
System-Level Hardening Both Windows Vista and Windows Server 2008 have new system-level hardening, which basically modularizes components of the operating system and runs them at lower privilege levels. In Terminal Services, this feature was implemented by splitting the core TS engine (termsrv.dll) into two separate components (lsm.exe, the core session manager, and termsrv.dll for remote connectivity).
Previously, termsrv.dll ran at the higher system privilege level. Now, only one-third of the original termsrv.dll code runs at that level in the new lsm.exe; the remaining two-thirds run at the much lower network service privilege level. This change significantly reduces the attack surface compared to Windows Server 2003.

User Experience Features
A number of improvements help users:
Custom Display Resolutions With the expansive growth of large monitors and a wider variety of display resolution ratios, Windows Server 2008 Terminal Services steps up to meet your needs.
The end user has the ability to set custom display resolutions (up to 4096 x 2048) or change the ratios to 16:9 or 16:10 to get a wide­screen experience. All types of new monitor configurations can be supported, such as monitors with resolutions of 1680 x 1050 or 1920 x 1200. This is a great improvement over Windows Server 2003, which supported a maximum resolution of 1600 x 1200 and only 4:3 display resolutions ratios. You can set a custom display resolution from the RDC client dialog box, in an .rdp file, or from a command prompt.
In order to set a custom display resolution in an .rdp file, open the .rdp file in a text editor and add or change the following settings (note that <value> is the resolution, such as 1680 or 1050): 
desktopwidth:i:<value>
desktopheight:i:<value>
To set a custom display resolution from a command prompt, use the mstsc.exe command with the following syntax (note that <width> and <height> are the resolution, such as 1680 or 1050): 
mstsc.exe /w:<width> /h:<height>
Monitor Spanning Remote desktop sessions are now able to span multiple monitors. There are a few prerequisites for this feature to work properly:
  • All monitors must use the same resolution. For example, two monitors using 1024 x 768 can be spanned. But one monitor at 1024 x 768 and one monitor at 800 x 600 cannot be spanned.
  • All monitors must be aligned horizontally (that is, side-by-side). There is currently no support for spanning multiple monitors vertically on the client system.
  • The total resolution across all monitors cannot exceed the maximum resolution of 4096 x 2048.
To enable monitor spanning in an .rdp file, open the .rdp file in a text editor and add or change the following settings (note: if <value>=0, monitor spanning is disabled, if <value>=1, it is enabled): 
Span:i:<value>
To set monitor spanning from a command prompt, use the mstsc.exe command with the following syntax: 
mstsc.exe /span
Desktop Experience Desktop Experience makes a Terminal Services desktop much more like the Windows Vista desktop experience. This feature adds a number of components to the remote desktop, including Windows Media Player 11, desktop themes, and photo management. Here's how to enable Desktop Experience:
  1. Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.
  2. Under the Features Summary, click Add Features.
  3. On the Select Features page, select the Desktop Experience checkbox and then click Next.
  4. On the Confirm Installation Selections page, verify that the Desktop Experience feature will be installed and click Install.
  5. On the Installation Results page, you are prompted to restart the server to finish the installation process. Click Close, and then click Yes to restart the server.
Once the server has restarted, you must then confirm that the Desktop Experience feature is installed.
Font Smoothing Font smoothing is the name for Terminal Services support for ClearType, which helps display computer fonts more crisply, especially on an LCD monitor. Font smoothing is enabled by default in Windows Server 2008, and it can be enabled when a client computer connects through a checkbox in the Remote Desktop Connection, as shown in Figure 1.
Figure 1 Enabling font smoothing
You should note that font smoothing increases the bandwidth (from 4 to 10 times, depending on the scenario) used between the client computer and the terminal server. This increase in bandwidth occurs because ClearType fonts are remoted as bitmaps instead of glyphs, which RDP handles much more efficiently.
Display Data Prioritization With Windows Server 2003, printing a large job could often make your on-screen experience suffer. Display data prioritization automatically controls virtual channel traffic so that display, keyboard, and mouse data is given a higher priority over other traffic, such as printing or file transfers. This prioritization is designed in order to ensure that your screen, keyboard, and mouse performance is not impacted by bandwidth-intensive actions, such as large print jobs.
Out of the box, the setting is 70:30. Display and input data are allocated 70% of the bandwidth while all other traffic, such as file transfers or print jobs, will be allocated 30%.
You can adjust the settings by making changes to the registry of the terminal server. To do so, change the value of the following entries under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser­vices\Term­DD subkey: 
FlowControlDisable
FlowControlDisplayBandwidth
FlowControlChannelBandwidth
FlowControlChargePostCompression
If these entries do not appear, you can add them by right-clicking TermDD, point to New, and then click DWORD (32-bit) Value.
You can disable display data prioritization by setting the value of FlowControl­Disable=1. If display data prioritization is disabled, all requests are handled on a first-in-first-out basis. The default value for FlowControlDisable=0.
You can set the relative bandwidth priority for display (and input data) by setting the FlowControlDisplayBandwidth value. The default value is 70; the maximum value allowed is 255. Likewise, you can set the relative bandwidth priority for other virtual channels (such as clipboard, file transfers, or print jobs) by setting the FlowControlChannelBandwidth value. The default value is 30; the maximum value allowed is 255.
The bandwidth ratio for display data prioritization is based on the values of FlowControlDisplayBandwidth and FlowControlChannelBandwidth. For example, if FlowControlDisplayBandwidth is set to 150 and FlowControlChannelBandwidth is set to 50, the ratio is 150:50. As a result of this, display and input data will be allocated 75% of the bandwidth.
The FlowControlChargePostCompression value determines if flow control will calculate the bandwidth allocation based on pre-or post-compression bytes. The default value is 0, which means that the calculation will be made on pre-compression bytes.
If you make any changes to the registry values, you need to restart the terminal server for the changes to take effect.
Plug and Play Device Redirection In Windows Server 2008 Terminal Services, device redirection has been enhanced and expanded. Now you can redirect Windows Portable Devices, specifically media players based on the Media Transfer Protocol (MTP) and digital cameras based on the Picture Transfer Protocol (PTP).
This functionality can be enabled with the Options button in the Remote Desktop Connection. When it's enabled, a list of supported Plug and Play devices that are currently plugged in will show up. Unsupported devices will not appear. You can also select the option to redirect devices that have not been plugged in yet. Figure 2 shows how to enable these from the RDC client.
Figure 2 Enabling devices that are not yet plugged in
When the session to the remote computer is launched, you should see the Plug and Play device that is redirected get automatically installed on the remote computer—Plug and Play notifications will appear in the taskbar. After the redirected Plug and Play device is installed, it is available for use in your session with the remote computer. For example, if you are redirecting a Windows Portable Device such as a digital camera, it can be accessed directly from an application such as the Scanner and Camera Wizard on the remote computer.
You can control Plug and Play device redirection by using either of the following Group Policy settings:
  • Do not allow supported Plug and Play device redirection located in Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Device and Resource Redirection.
  • The policy settings located in Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions.
You can also control Plug and Play device redirection on the Client Settings tab in the Terminal Services Configuration tool (tsconfig.msc) by using the Supported Plug and Play Devices checkbox.

Easier Remote Access
I mentioned earlier that TS RemoteApp lets users remote a single application and TS Web Access lets them access applications easily from a Web page; now let's take look a little closer at these features and at some of the configuration details.
TS RemoteApp RemoteApp programs can be deployed to user desktops through a variety of methods. In addition to TS Web Access, you can also:
  • Create a Remote Desktop Protocol file.
  • Create a program icon on the desktop or Start menu via a previously distributed Windows Installer (.msi) package.
  • Execute a file where the file name extension is associated with a RemoteApp program. This can be configured by the administrator with a Windows Installer package.
For more information on how users can access RemoteApp programs, see "How Should I Deploy RemoteApp Programs?" in the Windows Server 2008 TS Remote­App Step-by-Step Guide at go.microsoft.com/fwlink/?LinkID=84895 .
TS Web Access TS Web Access enables the deployment of RemoteApp programs from a single server or a farm of terminal servers. The TS RemoteApp Manager provides a very quick and efficient process for publishing applications into TS Web Access—first you install Terminal Services, then you install the applications you want to host.
Use TS RemoteApp Manager to add Remote­App programs that are enabled for TS Web Access. Next, install TS Web Access on the server to which you want users to connect over the Web. Add the computer account of the TS Web Access server to the TS Web Access Computers group on the terminal server. Finally, configure the TS Web Access server to populate its list of RemoteApp programs from a single terminal server or single farm.
Once the applications have been installed through the traditional method or delivered to the terminal server with Application Virtualization (formerly known as SoftGrid), it is very straightforward to publish those applications to TS Web Access. The Remote­App Wizard walks the administrator through a few quick and easy steps and the applications then appear on the list of published Remote­App Programs.
By default, the applications will be published to TS Web Access. RemoteApp Manager will then show you a list of applications that have been published and all the applications that are available to users through TS Web Access.
Now let's take a quick peek at the out-of-the-box end user experience. The first tab in TS Web Access shows the icons of all the applications that are published (see Figure 3); the second tab lets users connect to a specific desktop computer using the Web front end. As noted earlier, this Web interface is completely customizable and the "TS Web Access Step-by-Step Guide: Customizing TS Web Access by Using Windows SharePoint Services," available at go.microsoft.com/fwlink/?LinkID=111241 , is a great resource that walks you through a customization with SharePoint Services.
Figure 3 Entering settings for the .rdp files (Click the image for a larger view)
Other Deployment Methods Besides using TS Web Access, you can deploy RemoteApp programs with .rdp files or Windows Installer packages. Those packages can be distributed through file sharing, or through Microsoft Systems Center Operations Manager or Active Directory software distribution. The next section will walk you through the key steps to create the right packages for application distribution.
To prepare RemoteApp programs for distribution through a file share or some other distribution mechanism, you must install Terminal Services and the apps you want to publish, and verify remote connection settings. The TS RemoteApp Wizard will help you to add RemoteApp programs and configure global deployment settings. Then you can create .rdp files or Windows Installer packages.
Let's walk quickly through the Remote­App Wizard. In Step 1, you configure the Terminal Server, TS Gateway, and Certificate settings for the .rdp files (see Figure 4).
Figure 4 Setting options for the program package (Click the image for a larger view)
In Step 2, you specify where the shortcut icons will appear on the desktop or Start menu and/or associate client file extensions so that local files will launch with the Remote­App (see Figure 5 ).
Figure 5 Viewing RemoteApp programs in TS Web Access (Click the image for a larger view)
In the final step, the RemoteApp Wizard opens the Packaged Programs folder so you can easily deploy these packaged applications to client machines with the distribution software of your choice (see Figure 6 ).
Figure 6 Programs packaged for deployment (Click the image for a larger view)

Terminal Services Gateway
Now I am going to examine how TS Gateway can help your remote users get access to applications, data, or desktops from outside the firewall. Figure 7 shows at a very high level the typical scenario for deploying TS Gateway in order to provide access to users through the Internet.
Figure 7 Worker connecting from laptop at home to a corporate network (Click the image for a larger view)
In essence, the TS Gateway sits in the network perimeter and tunnels the RDP traffic over HTTPS. Alternatively, you could place an SSL terminator (such as Microsoft Internet Security and Acceleration Server—ISA) in the network perimeter and forward the incoming RDP traffic to your TS Gateway on the other side.
Here are the steps illustrated in Figure 7 :
  1. A user on a home laptop can connect via the Internet by clicking on either an RDP file or a RemoteApp program icon located on the desktop, on the icon of a TS RemoteApp published via TS Web Access, or by opening the Remote Desktop Connection client.
  2. An SSL tunnel is established between the home laptop and the terminal servers using the TS Gateway server's SSL certificate. Before a connection is established, the user must be authenticated and authorized according to Terminal Services connection authorization policies (TS CAPs) and Terminal Services resource authorization policies (TS RAP). Once the TS RAP and TS CAP polices (discussed below) have been enforced, the user can open a session.
  3. The home laptop exchanges encrypted RDP packets encapsulated within SSL with the TS Gateway over port 443. The TS Gateway forwards the RDP packets to terminal server over port 3389.
You can create a farm of TS Gateway servers for larger installations, but you will need a separate solution (such as NLB or a third-party load balancer) in order to balance the load among the server farm systems. TS Session Broker does not handle load balancing for TS Gateway server.
Now let's take a quick look at how to deploy this functionality. In a nutshell, you need to obtain and configure a certificate for the TS Gateway server and create the two types of authorization policies I mentioned earlier: TS CAP and TS RAP.
Obtaining a Certificate You can either use an existing certificate or request a new one. A valid certificate is required for the TS Gateway to function and you have a choice during installation to import a certificate or create a self-signed certificate.
The self-signed option is good if you are doing internal testing, but proper deployment requires a certificate issued by an enterprise certificate authority (such as VeriSign). Once you have the certificate installed, you can then consider your deployment authorization policies.
Authorization Policies TS CAPs determine who can connect to the TS Gateway and specify under what conditions users can connect. For example, you can specify that a user group that exists on the local TS Gateway server or in Active Directory can connect to a TS Gateway and that group members must use smart cards.
TS RAPs, on the other hand, determine which internal resources users can access via the TS Gateway. For example, you can create a computer group (such as a farm of terminal servers) and associate it with your TS RAP.
You need to create both TS CAPs and TS RAPs to give remote users access to internal resources, as a user must meet the conditions of at least one TS CAP and one TS RAP in order to have access. Administrators can create both types via the TS Gateway Manager, as shown in Figure 8 and Figure 9.
Figure 8 Creating a connection authorization policy (Click the image for a larger view)
Figure 9 Creating a resource authorization policy (Click the image for a larger view)
Together, TS CAPs and TS RAPs provide two different types of authorization that allow you to configure a more finely tuned level of access control to computers on an internal network. For more information, see the "Terminal Services Gateway Step-by-Step Guide" at go.microsoft.com/fwlink/?LinkID=85872 .

TS Session Broker
The last topic I'd like to cover is Session Broker, which provides a simple-to-deploy, session-based, load-balancing solution. The functionality builds on the Session Directory capabilities of Windows Server 2003 that reconnected a user to an existing session, and adds it the ability to create a new session on the least-loaded server in the farm.
Let's look at a typical scenario in which all terminal servers in a farm have host resource records in DNS that map to a particular terminal server farm name, say Farm1. Any terminal server in the farm can therefore act as a redirector and process the initial connection requests.
Suppose a user starts an RDC client, specifying a terminal server farm named Farm1. The client contacts the DNS server to resolve the Farm1 name to an IP address, and the DNS server, which is configured to use round robin to load balance the initial connection requests, returns a list of IP addresses that are registered for Farm1.
The client sends the connection request to the first IP address on the list that is returned by the DNS server. The terminal server with that address acts as the redirector, querying the TS Session Broker server to determine which terminal server the client should log on to. The TS Session Broker server checks its database, and if the user has an existing session, Session Broker returns the IP address of that terminal server. If the user does not have an existing session, Session Broker determines which terminal server in the farm has the lowest load (based on the number of sessions and the relative server weight value) and then it returns the IP address of that particular server.
The redirector sends the client that IP address and the client then sends the connection request to that server, which processes the logon request and notifies TS Session Broker of the successful logon.
Note that while any load-balancing mechanism can be used to distribute the initial connections, DNS round robin is the easiest mechanism to deploy. However, be aware that DNS round robin does have some limitations, including the caching of DNS requests on the client, which can result in clients using the same IP address for each initial connection request, and the potential for a 30-second timeout delay if a user is redirected to a terminal server that is offline but still listed in DNS.
Deploying TS Session Broker Load Balancing with a network level load-balancing solution such as NLB or a hardware load balancer avoids the limitations of DNS while still taking advantage of TS Session Broker features. The TS Session Broker load-balancing feature lets you to assign a relative weight value to each server, which helps to distribute the load between more powerful and less powerful servers in the farm. For example, if you had a server that could handle twice as many sessions as another server in the farm, you would give that server a 200 weight relative to the other at 100.
TS Session Broker Load Balancing sets a limit of 16 for the maximum number of pending logon requests to a particular terminal server. This feature helps to prevent overwhelming a single server with new logon requests when, for example, you add a new server to the farm or when you enable user logons on a server where they had been previously denied.
Additionally, a new "server draining" mechanism is provided that lets you prevent new users from logging on to a terminal server that is scheduled to be taken down for maintenance. If new logons are denied on a particular terminal server, TS Session Broker will allow users with existing sessions to reconnect, but will redirect new users to terminal servers that have been configured to allow new logons.
For more information, see the "TS Session Broker Load Balancing Step-by-Step Guide" at go.microsoft.com/fwlink/?LinkID=92670 . There's not enough space here for me to talk more about the new features of Windows Server 2008 TS. However, there is much more content, including in-depth webcasts, on the Terminal Services Web site. In order to learn more, you should head over to technet.microsoft.com/ts .

Joshua Schnoll has more than 15 years of marketing and technology experience, focusing the last 6 years on server-based computing. He is the worldwide Senior Product Manager for Windows Server Terminal Services. Before coming to Microsoft, he held several positions with Sun Microsystems, including driving product marketing for Sun Ray ultra-thin clients.

Windows Server 2008
Virtualisation de présentation avec les services Terminal Server améliorés
Joshua Schnoll
 
Vue d'ensemble :
  • Nouvelles fonctionnalités dans les services Terminal Server Windows Server 2008
  • L'aide de TS Gateway pour l'accès à distance
  • Équilibrage de charge avec Broker session Terminal Server

La virtualisation est un terme à chaud de nos jours, bien que la plupart des personnes temps pense qu'il est lié uniquement à ordinateurs virtuels et la virtualisation des systèmes d'exploitation. Toutefois, services Terminal Server a été détachant la couche de présentation des applications Exécution à distance et des postes de travail depuis la version de Windows NT 4.0. Les services Terminal Server a sont un moyen long depuis et Windows Server 2008 propose une plate-forme de virtualisation présentation arrivent à maturité, robuste. Je me concentrerai les zones clés d'amélioration dans les services Terminal Server.

Nouveautés dans les services Terminal Server
Les services Terminal Server dans Windows Server 2008 comprend de nouvelles fonctionnalités et capacités suivants :
Terminal Services RemoteApp Une seule modification très dans Windows Server 2008 est la capacité à distance une application unique. Dans les versions antérieures des services Terminal Server, le Bureau à distance en entier a été transmis, même si vous souhaitez uniquement accéder à une application unique. Il était souvent confusion pour les utilisateurs étant donné que certaines applications apparaissaient sur le Bureau à distance (via les services Terminal Server) et certaines sur le bureau local, et sans oublier le bureau avait quelle application peut être difficile. À présent, applications accessibles par le biais des services Terminal Server rechercher et se comportent comme si elles ont été exécuté sur ordinateur local l'utilisateur final.
l'accès Web aux services Terminal Server Élevé sur liste de souhaits de tout le monde était un moyen simple pour les utilisateurs finaux de lancer des applications. TS Web Access répond à ce besoin en permettant administrateurs publier des applications individuelles à une page Web. TS Web Access inclut une page Web par défaut qui peuvent être déployée droite de la boîte de, mais elle aussi peut être personnalisé et intégrée à un site SharePoint. Pour lancer un RemoteApp Terminal Server avec TS Web Access, l'utilisateur visite une page Web (accessible soit à partir d'Internet ou intranet), voit la liste des toutes les applications disponibles et clique sur le qu'il souhaite lancer.
Dans Windows Server 2003, un contrôle ActiveX distinct appelé le RDWC (Desktop Web Connection) à distance était nécessaire pour activer une connexion à partir d'un navigateur. Maintenant le contrôle a été intégré directement dans le client Connexion Bureau à distance (RDC) principal, donc rien ne doit être téléchargé ou installé pour le client. En outre, l'ensemble de fonctionnalités RDP (Remote Desktop Protocol) est pris en charge, qui n'était pas le cas avec le client RDWC ancien.
la passerelle des services Terminal Server TS Gateway font partie des fonctionnalités nouvelles plus significatives dans Windows Server 2008. Le trafic RDP s'exécute sur le port 3389 et un des problèmes majeurs administrateurs a dû lorsque le déploiement d'un serveur Terminal Server sur utilisateurs en dehors du pare-feu a été devoir soit ouvrir ce port dans le pare-feu (non recommandé) ou utiliser une solution VPN distincte (coûteuse). Avec TS Gateway, le trafic RDP est par tunnel via HTTPS (port 443) pour établir une connexion chiffrée entre les utilisateurs à distance sur Internet et le serveur Terminal Server (ou ordinateur distant). Mieux encore, le scénario fonctionne tant mieux même si l'utilisateur ou le serveur Terminal Server se trouve derrière un routeur réseau adresse (translation) en fonction de parcours.
TS Gateway peut être associé à une autre fonctionnalité de Windows Server 2008, la protection NAP (Network Access), afin de garantir l'intégrité des ordinateurs clients avant l'accès aux ressources services Terminal Server.
Broker de session services Terminal Server Windows Server 2000 introduites charge (Network BALANCING) et, bien que cela fonctionne vraiment bien pour les serveurs Web, il n'idéal pour équilibrage de charge Terminal Services. Le nouveau Broker de session Terminal Server propose une alternative très à étendre les capacités de l'annuaire de session de Windows Server 2003 pour activer équilibrage de charge session-based.
Avec Terminal Server session Broker, nouvelles sessions sont distribuées vers le serveur moins chargé dans la batterie de serveurs et les utilisateurs n'ont pas de savoir où une session a été établie afin de vous reconnecter à une session existante. Responsables INFORMATIQUES peuvent utiliser la fonctionnalité pour mapper l'adresse IP de chaque serveur Terminal Server sur une seule écriture DNS. Cette configuration peut également fournir tolérance aux pannes ; si un des serveurs de batterie de serveurs est indisponible, les utilisateurs se connecter au suivant serveur moins chargé de la batterie de serveurs.
Terminal Services Easy Print L'impression a été traditionnellement le bane d'existence de nombreux un administrateur dans un environnement de services Terminal Server. En respectant les pilotes d'imprimante requis sur le serveur et les ordinateurs clients, les utilisateurs finaux devait moins flexibilité pour installer des imprimantes bien que les administrateurs subi à vous soucier de gestion des pilotes d'impression sur le serveur. Avec impression fichiers et paramètres Terminal Server, en revanche, les utilisateurs peuvent maintenant fiable imprimer à partir RemoteApp Terminal Server ou d'une session Bureau complète sur un périphérique local impression, si elle est attachée directement ou via un réseau. La meilleure partie est qu'imprimantes peuvent désormais être pris en charge sans qu'il est nécessaire pour installer des pilotes sur le serveur Terminal Server.
Lorsqu'un utilisateur souhaite imprimer à partir un programme RemoteApp Terminal Server ou d'une session bureau, il est la imprimante complet propriétés boîte de dialogue à partir du client local s'affiche et ont accès à toutes les la fonctionnalités imprimante (comme les filigranes d'interclassement, agrafage. Lorsque l'utilisateur imprime, le travail d'impression est affichée avec le format de fichier Microsoft XPS sur le serveur et envoyée au client. En outre, avec TS Easy Print, les administrateurs permet stratégie de groupe de limiter le nombre d'imprimantes redirigées vers simplement l'imprimante par défaut, ainsi réduire surcharge et améliore l'évolutivité.
Les sont les fonctionnalités « bon grand » dans Windows Server 2008. Nous reviendrons sur RemoteApp Terminal Server, TS Web Access TS Gateway et Terminal Server session Broker plus loin dans cet article. Tout d'abord, jetons un coup à certains autres très mais moins de fonctionnalités visible dans cette version.

Fonctionnalités de sécurité
Sécurité a été beefed haut dans la nouvelle version des services Terminal Server.
Authentification au niveau de réseau (NLA) et Authentification de serveur (SA) Avec les versions précédentes de Terminal Server, une attaque de refus de service ou homme en milieu peut avoir été lancée sur l'écran d'ouverture de session du serveur Terminal Server, que les utilisateurs ont été présentées avec l'écran d'ouverture de session après avoir cliqué sur se connecter sur le client RDC. Maintenant NLA authentifie l'utilisateur, ordinateur client et informations d'identification par rapport à l'autre du serveur avant une session Terminal Server est lancée haut sur le serveur et de l'écran d'ouverture de session est présentée à l'utilisateur. Authentification du serveur utilise TLS (Transport Layer Security) pour vous assurer que les clients vous connectez à un serveur Terminal Server légitime et pas une machine non autorisés.
Authentification unique Utilisateurs souhaitent pouvoir utiliser un ensemble d'informations d'identification (une combinaison utilisateur / mot de passe ou une carte à puce et combinaison de code) pour authentifier une seule fois et ne pas pour la demande maintes et maintes fois afin d'obtenir des informations d'identification chaque fois à utiliser une nouvelle ressource. Avec cette version, ordinateurs joint au domaine exécutant Windows Vista ou Windows Server 2008, vous connecter à un serveur Terminal Server Windows Server 2008-basé ou passerelle TS, peuvent utiliser maintenant l'authentification unique.
Renforcement du niveau du système À la fois Windows Vista et Windows Server 2008 ont renforcement nouveau au niveau du système des, qui en fait modularizes composants du système d'exploitation et les exécute au niveau de privilège inférieur. Dans les services Terminal Server, cette fonctionnalité a été implémentée en fractionnant le moteur de Terminal Server de base (termsrv.dll) en deux composants distincts (lsm.exe, le Gestionnaire de sessions noyau et termsrv.dll pour la connectivité à distance).
Termsrv.dll s'exécutaient précédemment, au niveau de privilège du plus élevé de système. À présent, uniquement un tiers du code termsrv.dll d'origine s'exécute à ce niveau dans la nouvelle lsm.exe ; les autres deux tiers exécutée à la quantité réseau service privilège niveau inférieur. Cette modification réduit considérablement la surface d'attaque par rapport à Windows Server 2003.

Fonctionnalités d'expérience utilisateur
Un certain nombre d'améliorations aide les utilisateurs :
Résolution Affichage personnalisé La croissance nombreuses de moniteurs grands et un large éventail de ratios de résolution d'affichage, les services Terminal Server Windows Server 2008 étapes à vos besoins.
L'utilisateur final a la possibilité pour définir des résolutions d'affichage personnalisés (haut à 4096 x 2048) ou modifier les proportions à 16: 9 ou 16:10 pour obtenir une expérience wide­screen. Tous types de nouvelles configurations moniteur peuvent pris en charge, tels que les moniteurs avec des résolutions de 1680 x 1050 ou 1920 x 1200. C'est une nette amélioration sur Windows Server 2003, qui pris en charge une résolution maximale de 1600 x 1200 et uniquement 4: 3 afficher ratios de résolutions. Vous pouvez définir une résolution d'affichage personnalisé à partir de la boîte de dialogue client RDC, dans un fichier .rdp, ou à partir d'une invite de commande.
Pour définir une résolution d'affichage personnalisé dans un fichier .rdp, ouvrez le fichier .rdp dans un éditeur de texte et ajouter ou modifier les paramètres suivants (Notez que <value> est la résolution, tels que 1680 ou 1050) : 
desktopwidth:i:<value>
desktopheight:i:<value>
<width>Pour définir une résolution d'affichage personnalisé à partir d'une invite de commandes, utilisez la commande mstsc.exe avec la syntaxe suivante (Notez que <largeur> et <height> sont la résolution, tels que 1680 ou 1050) : 
mstsc.exe /w:<width> /h:<height>
moniteur Spanning Sessions bureautiques à distance sont maintenant capables de s'étendre sur plusieurs moniteurs. Il existe quelques conditions requises pour cette fonctionnalité pour fonctionner correctement :
  • Tous les moniteurs doivent utiliser la même résolution. Par exemple, deux moniteurs à l'aide de 1024 x 768 peuvent être fractionnés. Mais un seul moniteur au moniteur 1024 x 768 et un à 800 x 600 et ne peut pas être couvertes.
  • Tous les moniteurs doivent être alignés horizontalement (c'est-à-dire, côte à côte). Il n'existe actuellement aucune prise en charge pour sur plusieurs moniteurs verticalement sur le système client.
  • La résolution totale sur tous les moniteurs ne peut pas dépasser la résolution maximale de 4096 x 2048.
Pour activer le moniteur sur dans un fichier .rdp, ouvrir le fichier .rdp dans un éditeur de texte et ajouter ou modifier les paramètres suivants (Remarque : si <valeur> = 0, écran fractionné est désactivé si <valeur> = 1, il est activé) : 
Span:i:<value>
Pour définir le moniteur sur à partir d'une invite de commandes, utilisez la commande mstsc.exe avec la syntaxe suivante : 
mstsc.exe /span
expérience du bureau Environnement bureau rend un Bureau des services Terminal Server beaucoup de façon analogue à la Windows Bureau Vista. Cette fonction ajoute un certain nombre de composants sur le Bureau à distance, y compris le lecteur Windows Media 11, thèmes du bureau et gestion des photos. Voici comment activer l'expérience du bureau :
  1. Ouvrez Server Manager. Cliquez sur Démarrer, pointez sur Outils d'administration et puis cliquez sur Gestionnaire de serveur.
  2. Sous le résumé des fonctionnalités, cliquez sur Ajouter des composants.
  3. Sur la page Fonctionnalités de sélection, activer la case à cocher expérience Bureau et puis cliquez sur Suivant.
  4. Dans la page confirmer la sélection de l'installation, vérifiez que la fonctionnalité Expérience Bureau sera installé et cliquez sur Installer.
  5. Sur la page Résultats de l'installation, vous êtes invité à redémarrer le serveur pour terminer le processus d'installation. Cliquez sur Fermer, puis cliquez sur Oui pour redémarrer le serveur.
Une fois que le serveur a redémarré, vous devez ensuite confirmer que la fonctionnalité Expérience Bureau est installée.
lissage des polices Lissage des polices est le nom pour le support services Terminal Server de ClearType, les polices d'ordinateur complet permet plus précisément, en particulier sur un écran LCD surveiller. Lissage des polices est activé par défaut dans Windows Server 2008, et peut être activé lorsqu'un ordinateur client se connecte à une case à cocher dans la connexion Bureau à distance, comme illustré figure 1 .
Figure 1 lissage des polices d'activation
Notez que le lissage des polices augmente la bande passante (de 4 pour 10 fois, selon le scénario) utilisée entre l'ordinateur client et le serveur Terminal Server. Cette augmentation de la bande passante se produit car les polices ClearType sont transférée à distance en tant que bitmaps au lieu de glyphes qui RDP gère beaucoup plus efficacement.
Affichage données hiérarchisation Avec Windows Server 2003, l'impression d'un travail grand a pu souvent faire de votre écran expérience pâtir. Hiérarchisation des données Affichage détermine automatiquement le trafic du canal virtuel ainsi qu'afficher, clavier, et données de la souris sont attribuées une priorité plus élevée sur le trafic, tels que les transferts l'impression ou le fichier. Cette priorité est conçue en ordre pour garantir que votre écran, le clavier et souris performances n'est pas affectée par des actions impliquant beaucoup de bande passante, telles que les travaux d'impression volumineux.
De la zone, le paramètre est 70:30. Affichage et Entrée données sont allouées 70 % de la bande passante tandis que tout autre trafic, tels que transfert de fichiers ou des travaux d'impression, sera allouée 30 %.
Vous pouvez ajuster les paramètres en modifiant le Registre du serveur Terminal Server. Pour ce faire, modifiez la valeur des entrées suivantes sous la sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser­vices\Term­DD : 
FlowControlDisable
FlowControlDisplayBandwidth
FlowControlChannelBandwidth
FlowControlChargePostCompression
Si ces écritures n'apparaissent pas, vous pouvez les ajouter en cliquant avec le bouton droit sur TermDD, pointez sur Nouveau et puis cliquez sur Valeur DWORD (32-bit) valeur.
Vous pouvez désactiver afficher données priorités en attribuant la valeur FlowControl­Disable = 1. Si hiérarchisation de données d'affichage est désactivée, toutes les demandes sont gérées sur la base premier de première sortie. La valeur par défaut de FlowControlDisable = 0.
Vous pouvez définir la priorité relative de bande passante pour afficher (et données d'entrée) en définissant la valeur FlowControlDisplayBandwidth. La valeur par défaut est 70 ; la valeur maximale autorisée est 255. De même, vous pouvez définir la priorité relative de bande passante pour autres canaux virtuel (tels que le Presse-papiers, les transferts de fichiers ou les travaux d'impression) en définissant la valeur FlowControlChannelBandwidth. La valeur par défaut est 30 ; la valeur maximale autorisée est 255.
Le rapport de bande passante pour affichage données hiérarchisation est basé sur les valeurs de FlowControlDisplayBandwidth et FlowControlChannelBandwidth. Par exemple, si FlowControlDisplayBandwidth est définie à 150 et FlowControlChannelBandwidth est définie à 50, le rapport est 150:50. En raison de cela, affichage et les données entrées seront ventilées 75 % de la bande passante.
La valeur FlowControlChargePostCompression détermine si le contrôle de flux calculera l'allocation de bande passante en fonction de pré- ou post-compression octets. La valeur par défaut est 0, ce qui signifie que le calcul sera apportée des octets pre-compression.
Si vous apportez des modifications aux valeurs du Registre, vous devez redémarrer le serveur Terminal Server pour que les modifications prennent effet.
la redirection de périphérique Plug-and-Play Dans les services Terminal Server Windows Server 2008, la redirection de périphérique a été améliorée et développée. Vous pouvez désormais rediriger des appareils mobiles Windows, en particulier les baladeurs multimédias basés sur le protocole MTP (Media Transfer Protocol) et les appareils photo numériques basés sur l'image PTP (Transfer Protocol).
Cette fonctionnalité peut être activée avec le bouton Options dans la connexion Bureau à distance. Lorsque qu'il est activé, une liste des périphériques Plug-and-Play pris en charge qui sont actuellement branchés apparaît. Périphériques non pris en charge n'apparaîtront pas. Vous pouvez également sélectionner l'option pour rediriger les périphériques n'ont pas été branchés encore. figure 2 illustre comment activer ces à partir du client RDC.
La figure 2 périphériques Activation qui ne sont pas encore branchés
Lorsque la session à l'ordinateur distant est lancée, vous devriez voir le périphérique Plug and Play qui est redirigé obtenir automatiquement installées sur l'ordinateur distant, notifications Plug-and-Play sont affiche dans la barre des tâches. Une fois le périphérique Plug-and-Play redirigé est installé, est disponible pour les utiliser dans votre session avec l'ordinateur distant. Par exemple, si vous êtes rediriger un périphérique portable Windows comme un appareil photo numérique, il est accessible directement à partir d'une application telle que l'Assistant Scanneur et appareil photo sur l'ordinateur distant.
Vous pouvez contrôler la redirection de périphérique Plug-and-Play à l'aide des paramètres de stratégie de groupe suivants :
  • N'autorisent pas la redirection de périphérique Plug-and-Play pris en charge située dans l'ordinateur d'administration\Composants Windows\Services Terminal Terminal Server\Device et redirection de ressources.
  • Les paramètres de stratégie situés dans les restrictions d'installation Installation\Device d'administration\Système\Installation de travail.
Vous pouvez également contrôler la redirection de périphérique Plug-and-Play sous l'onglet Paramètres de client dans l'outil de configuration des services Terminal Server (tsconfig.msc) en utilisant la case à cocher pris en charge Plug-and- et périphériques de lecture.

Plus facilement accès à distance
J'AI indiqué précédemment que RemoteApp Terminal Server permet aux utilisateurs à distance une application unique et TS Web Access permet les accéder aux applications facilement à partir d'une page Web; à présent prise examinons quelques affichage rapproché de ces fonctionnalités et des détails de configuration.
RemoteApp Terminal Server RemoteApp programmes peuvent être déployés par le biais des méthodes différentes pour les postes de travail des utilisateurs. En outre TS Web Access, vous pouvez également :
  • Créer un fichier de Remote Desktop Protocol.
  • Créer une icône de programme sur le Bureau ou démarrer menu via un package Windows Installer (.msi) précédemment distribué.
  • Exécuter un fichier où l'extension de nom de fichier est associée à un programme RemoteApp. Cela peut être configuré par l'administrateur avec un package Windows Installer.
Pour savoir comment les utilisateurs peuvent accéder programmes RemoteApp, consultez « Comment doit je déployer programmes RemoteApp? » dans le Guide pas-à-pas Windows Server 2008 Terminal Server Remote­App au go.microsoft.com/fwlink/?LinkID=84895 .
TS Web Access TS Web Access permet le déploiement des programmes RemoteApp d'un serveur unique ou d'une batterie de serveurs Terminal Server. Le Gestionnaire de RemoteApp Terminal Server fournit un processus très rapide et efficace pour publier des applications dans TS Web Access, tout d'abord vous installez les services Terminal Server, puis vous installez les applications à ordinateur hôte.
Gestionnaire de RemoteApp Terminal Server permet d'ajouter des programmes Remote­App qui sont activés pour TS Web Access. Ensuite, installez TS Web Access sur le serveur sur lequel vous souhaitez que les utilisateurs à se connecter via le Web. Ajoutez le compte ordinateur du serveur TS Web Access au groupe d'ordinateurs de TS Web Access sur le serveur Terminal Server. Enfin, configurez le serveur TS Web Access pour remplir sa liste de programmes de RemoteApp à partir d'un seul serveur Terminal Server ou la batterie unique.
Une fois que les applications ont été installées via la méthode traditionnelle ou remises au serveur terminal server avec la virtualisation d'applications (anciennement SoftGrid), il est très simple de publier ces applications à TS Web Access. L'Assistant Remote­App guide l'administrateur via quelques étapes rapides et faciles et les applications puis apparaissent dans la liste des programmes Remote­App publiés.
Par défaut, les applications sont publiées à TS Web Access. RemoteApp Gestionnaire s'affiche ensuite une liste des applications qui ont été publiées et toutes les applications qui sont disponibles pour les utilisateurs via TS Web Access.
Maintenant examinons un aperçu rapide à l'expérience utilisateur final emploi-la. Le premier onglet TS Web Access affiche les icônes des applications qui sont publiées (voir figure 3 ); l'onglet deuxième permet aux utilisateurs de se connecter à un ordinateur de bureau spécifique à l'aide de site Web frontal. Comme indiqué précédemment, cette interface Web est entièrement personnalisable et le » TS Web Access pas-à-pas Guide : personnalisation TS Web Access par à l'aide Windows SharePoint Services, » disponible à go.microsoft.com/fwlink/?LinkID=111241 , est une ressource de très vous guide à travers une personnalisation avec SharePoint Services.
La figure 3 Paramètres de saisie pour les fichiers .rdp (cliquez sur l'image pour l'agrandir)
autres méthodes de déploiement Outre TS Web Access, vous pouvez déployer des programmes RemoteApp avec des fichiers .RDP ou les packages Windows Installer. Ces packages peuvent être distribuées via partage de fichiers ou des distribution de logiciels Microsoft Systems Center Operations Manager ou Active Directory. La section suivante vous guide les étapes clés pour créer les packages de droit pour la distribution d'application.
Pour préparer des programmes RemoteApp pour la distribution via un partage de fichiers ou un autre mécanisme distribution, vous devez installer les services Terminal Server et les applications que vous souhaitez publier et vérifier les paramètres de connexion à distance. L'Assistant RemoteApp Terminal Server vous aidera pour ajouter des programmes RemoteApp et configurer des paramètres de déploiement global. Vous pouvez ensuite créer des fichiers .RDP ou les packages Windows Installer.
Nous allons étudier rapidement l'Assistant Remote­App. Dans l'étape 1, vous configurez les paramètres Terminal Server, TS Gateway et certificats des fichiers .rdp (voir figure 4 ).
La figure 4 Définition des options pour le package du programme (cliquez sur l'image pour l'agrandir)
Dans l'étape 2, vous spécifier dans lequel les icônes de raccourci sont affiche sur le Bureau ou démarrer menu ou associer client extensions de fichier pour que les fichiers locaux sont lancera avec la Remote­App (voir La figure 5 ).
La figure 5 RemoteApp Affichage des programmes de TS Web Access (cliquez sur l'image pour l'agrandir)
Dans l'étape finale, l'Assistant RemoteApp ouvre le dossier programmes package afin de vous pouvez facilement déployer ces applications package sur les ordinateurs client avec le logiciel de distribution de votre choix (voir La figure 6 ).
La figure 6 programmes distribué pour le déploiement (cliquez sur l'image pour l'agrandir)

La passerelle des services Terminal Server
Maintenant, je vais examiner comment TS Gateway peut aider vos utilisateurs distants les accéder à des applications, les données ou les postes de travail d'extérieur du pare-feu. figure 7 montre à un niveau très élevé, le scénario classique pour le déploiement TS Gateway afin d'offrir l'accès aux utilisateurs via Internet.
La figure 7 travail connexion à partir de portable chez à un réseau d'entreprise (cliquez sur l'image pour l'agrandir)
En gros, la passerelle Terminal Server se trouve dans le périmètre de réseau et acheminent le trafic RDP sur HTTPS. Sinon, vous pouvez placer un terminateur SSL (tels que Microsoft Internet Security et Acceleration Server, ISA) dans le réseau périmètre et avant le trafic RDP entrant à votre passerelle Terminal Server de l'autre côté.
Voici les étapes illustrées La figure 7 :
  1. Un utilisateur sur un ordinateur portable personnel peut se connecter via Internet en cliquant sur dans un fichier RDP ou un RemoteApp publié icône de programme située sur le bureau, sur l'icône d'un RemoteApp Terminal via TS Web Access, ou en ouvrant le client Connexion Bureau à distance.
  2. Un tunnel SSL est établi entre l'ordinateur portable personnel et les serveurs Terminal Server à l'aide SSL certificat du serveur de passerelle TS. Avant établissement d'une connexion, l'utilisateur doit être authentifié et autorisé selon pour les services Terminal Server ressource autorisation stratégies (RAP Terminal Server) et de stratégies d'autorisation connexion Services Terminal Server (Cap Terminal Server). Une fois le RAP Terminal Server et Terminal Server CAP stratégies (décrite ci-dessous) a été appliquée, l'utilisateur peut ouvrir une session.
  3. L'ordinateur portable personnel échange paquets RDP chiffrés encapsulées dans SSL avec la passerelle Terminal Server sur le port 443. La passerelle TS transmet les paquets RDP sur serveur terminal server sur le port 3389.
Vous pouvez créer une batterie de serveurs de passerelle TS serveurs pour les installations plus grandes, mais vous devez une solution distincte (telle que NLB ou un équilibreur de charge tiers) afin d'équilibrer la charge entre les systèmes de batterie de serveurs server. Broker session Terminal Server ne gère pas équilibrage de charge pour serveur TS Gateway.
Maintenant voyons un rapidement comment faire pour déployer cette fonctionnalité. En bref, vous devez obtenir et configurer un certificat pour le serveur de passerelle TS et créer deux types de stratégies d'autorisation mentionné précédemment: CAP Terminal Server et Terminal Server RAP.
obtenir un certificat Vous pouvez utiliser un certificat existant ou demander une autre. Un certificat valide est requis pour la passerelle Terminal Server de la fonction et que vous avez le choix lors de l'installation pour importer un certificat ou créer un certificat auto-signé.
L'option auto-signé est bien si vous effectuez des tests internes, mais bon déploiement nécessite un certificat émis par une autorité de certification entreprise (telles que VeriSign). Une fois que vous avez le certificat installé, vous pouvez ensuite considérer votre déploiement stratégies d'autorisation.
stratégies d'autorisation Cap Terminal Server déterminent qui peut se connecter à la passerelle Terminal Server et spécifiez sous ce que les utilisateurs de conditions peuvent se connecter. Par exemple, vous pouvez spécifier qu'un groupe d'utilisateur qui existe sur le serveur passerelle des services Terminal local ou dans Active Directory peuvent se connecter à une passerelle TS et regrouper les membres doit utiliser des cartes à puce.
RAPs Terminal Server, déterminent d'autre part, les ressources internes, les utilisateurs peuvent accéder via la passerelle des services Terminal. Par exemple, vous pouvez créer un groupe d'ordinateurs (comme une batterie de serveurs Terminal Server) et l'associer avec votre RAP Terminal Server.
Vous devez créer Cap Terminal Server et Terminal Server RAPs pour donner à distance aux utilisateurs l'accès aux ressources internes, comme un utilisateur doit respecter les conditions au moins un CAP Terminal Server et un RAP Terminal Server afin d'avoir accès. Les administrateurs peuvent créer deux types via le Gestionnaire de passerelle Terminal Server, comme illustré figure 8 et 9 de figure .
La figure 8 Création d'une stratégie d'autorisation de connexion (cliquez sur l'image pour l'agrandir)
La figure 9 Création d'une stratégie d'autorisation de ressource (cliquez sur l'image pour l'agrandir)
Ensemble, Cap Terminal Server et Terminal Server RAPs fournissent deux types différents d'autorisation vous permettent de configurer un niveau plus finement connecté de contrôle d'accès aux ordinateurs sur un réseau interne. Pour plus d'informations, consultez le « Terminal Services Gateway pas-à-pas Guide » à go.microsoft.com/fwlink/?LinkID=85872 .

Broker session Terminal Server
Le dernier sujet que je souhaite couvrir est session Broker, qui fournit une solution simple à déployer, session, équilibrage de charge. La fonctionnalité repose sur les fonctionnalités de l'annuaire de session de Windows Server 2003 reconnecté à une session existante, un utilisateur et l'ajoute la possibilité de créer une nouvelle session sur le serveur moins chargé dans la batterie de serveurs.
Examinons un scénario typique dans quels tous les serveurs Terminal Server dans une batterie de serveurs ont enregistrements de ressource ordinateur hôte dans DNS mapper à un nom de batterie de serveurs terminal server particulier, dites Farm1. N'importe quel serveur Terminal Server de la batterie de serveurs peut donc servir un redirecteur et traiter les demandes de connexion initiale.
Supposons qu'un utilisateur démarre un client RDC, spécifiant une batterie de serveurs Terminal Server nommé Farm1. Le client contacte le serveur DNS pour résoudre le nom Farm1 à une adresse IP et le serveur DNS, qui est configuré pour utiliser répétition alternée pour équilibrer la charge les demandes de connexion initiale, renvoie une liste d'adresses IP qui sont enregistrés pour Farm1.
Le client envoie la demande de connexion de la première adresse IP dans la liste qui est renvoyée par le serveur DNS. Le serveur Terminal Server avec cette adresse joue le redirecteur en interrogeant le serveur Terminal Server session Broker pour déterminer lequel le client doit ouvrir une session sur le serveur Terminal Server. Le serveur Terminal Server session Broker vérifie sa base de données, et si l'utilisateur a ouvert une session existante, session Broker renvoie l'adresse IP de ce serveur Terminal Server. Si l'utilisateur ne dispose pas d'une session existante, Broker session détermine le serveur Terminal Server de la batterie est la plus basse charger (en se basant sur le nombre de sessions et la valeur du poids relative de serveur), puis elle renvoie l'adresse IP de ce serveur particulier.
Le Redirecteur envoie le client de cette adresse IP, le client puis envoie la demande de connexion à ce serveur, qui traite la demande d'ouverture de session et en informe Broker de session Terminal Server de l'ouverture de session réussie.
Notez que bien que n'importe quel mécanisme d'équilibrage de charge peut être utilisé pour distribuer les connexions initiales, DNS arrondir tour de rôle est le mécanisme plus simple à déployer. Cependant, être conscient que DNS arrondir tour de rôle possède certaines limitations, notamment la mise en cache des demandes DNS sur le client, peut entraîner clients en utilisant la même adresse IP pour chaque demande de connexion initiale, et le risque d'un délai de 30 secondes Délai d'expiration si un utilisateur est redirigé vers un serveur Terminal Server qui est en mode hors connexion mais toujours répertoriée dans DNS.
Déploiement de Terminal Server session Broker charge Équilibrage de la avec une solution équilibrage de charge réseau de niveau telle que NLB ou un équilibreur de charge matériel évite les limitations de DNS tout en toujours tirant parti des fonctionnalités Broker session Terminal Server. La fonctionnalité d'équilibrage de charge Broker session Terminal Server vous permet à affecter une valeur de pondération relative à chaque serveur, qui permet de distribuer la charge entre plus puissant et moins serveurs puissantes de la batterie. Par exemple, si vous avez un serveur qui peut traiter deux fois en tant que nombre de sessions comme un autre serveur de la batterie de serveurs, vous devez donner ce serveur une épaisseur de 200 par rapport à l'autre à 100.
Sessions Terminal Server Broker charge Équilibrage définit une limite de 16 pour le nombre maximal d'en attente d'ouverture de session demande à un serveur Terminal Server particulier. Cette fonctionnalité permet d'empêcher submerger un seul serveur avec les nouvelles demandes d'ouverture de session lorsque, par exemple, vous ajoutez un nouveau serveur à la batterie de serveurs ou lorsque vous activez des ouvertures de session utilisateur sur un serveur où il avaient été précédemment refusées.
En outre, un nouveau mécanisme « serveur Purge » est fourni qui vous permet d'empêcher nouveaux utilisateurs d'ouvrir une session sur un serveur Terminal Server qui est planifiée pour prendre vers le bas pour des raisons de maintenance. Nouvelles ouvertures de session sont refusées sur un serveur Terminal Server particulier, Broker session Terminal Server va autoriser les utilisateurs aux sessions existantes à vous reconnecter, mais redirigera nouveaux utilisateurs à des serveurs qui ont été configurées pour autoriser les nouvelles connexions Terminal Server.
Pour plus d'informations, consultez le « Terminal Server session Broker Load Balancing pas-à-pas Guide » à go.microsoft.com/fwlink/?LinkID=92670 . Il y a pas suffisamment d'espace ici pour m'en dirons plus sur les nouvelles fonctionnalités de Windows Server 2008 Terminal Server. Toutefois, il est beaucoup plus contenu, notamment webcasts approfondie sur le site Web des services Terminal Server. Pour en savoir plus, vous devez passez sur à technet.microsoft.com/ts .

Schnoll Joshua a plus de 15 ans de marketing et technologie expérience, concentrer les dernières années 6 sur calcul basé sur le serveur. Il est le responsable de produit senior dans le monde de services Terminal Server Windows Server. Avant d'arrive à Microsoft, il conservés positions par Sun Microsystems, y compris les déterminants marketing produit pour les clients ultra-thin Sun il.

TechNet Features

Resources

TechNet Subscriptions

Vous n'êtes pas abonné à Technet ?

Évaluez les logiciels Microsoft et planifiez leurs déploiements en toute confiance grâce à un abonnement Microsoft TechNet.

      
Page view tracker