Terminal Services Team Blog

Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks

General Intro

“Man In The Middle (MITM) attack” is a term used to describe a class of security vulnerabilities in which an attacker intercepts communication between two parties and impersonates each one to the other. The attacker can view and/or modify the traffic without the two parties knowledge. As a result, a user might be tricked into entering his credentials on a spoofed server. Even though RDP traffic between the client and server is encrypted, the attacker can potentially bypass RDP encryption if he is able to get the keys used to establish the session. Thus, server authentication is necessary to prevent MITM attacks.

Significant improvements in authentication and security have been made in Terminal Services that can protect against such attacks. Terminal servers running Windows 2003 Server SP1 and later support the ability for a TS client to authenticate a TS server, which protects against MITM attacks. In Windows 2003 Server SP1 and later, you can configure the TS server with a SSL/TLS server certificate that will allow the client to verify the server’s identity. In Windows Server 2008, Network Level Authentication (NLA) is designed to be secure against MITM, and it supports the ability to authenticate the server with either a SSL/TLS server certificate or Kerberos.

Terminal servers running Windows 2003 Server without SP1 or earlier do not support a clients’ ability to authenticate the terminal server. With these earlier versions, you must ensure that your network is tamper-proof by using network level protection mechanisms (for example, IPSec) in order to protect against MITM attacks.

Server authentication mechanisms that can protect against MITM attacks

1. Network Level Authentication (NLA): NLA uses the Credential Security Support Provider (CredSSP) Protocol to perform strong server authentication either through TLS/SSL or Kerberos mechanisms, which protect against MITM attacks. In addition to improving authentication, NLA also helps protect the remote computer from malicious users and software by completing user authentication before a full RDP connection is established; an additional benefit is that fewer resources are used on the remote computer prior to authentication. Please see this MSDN article or the protocol specification for more details on the CredSSP protocol.

NLA with Kerberos

This is one of the most secure server authentication schemes for protecting against MITM. Both client and server should be a part of the same or a trusted domain.

NLA with TLS/SSL

There are scenarios in which Kerberos cannot be used for server authentication, which include:

o Terminal server farms, because farms do not have a Kerberos identity in Active Directory

o Internet connection scenarios (for example through TS Gateway), in which the client does not have access to Key Distribution Center (KDC)

o The terminal server is not domain-joined

In such scenarios where Kerberos cannot be used for server authentication, deploying SSL/TLS certificates that are issued by a trusted Certificate Authority will enable the client to identify the server’s identity and protect against MITM attacks. You will need to deploy these certificates to each TS server on which you want to have server authentication and ensure that they have the server name in the Subject field.  To set the SSL certificate for a connection on Windows Server 2008:

1. At a command prompt, run tsconfig.msc. (Note: tsconfig.msc is only available on Server SKUs.)

2.  Double-click the RDP-TCP connection object.

3.  On the General tab, click Select.

4.  Select the certificate you want to assign to the connection, and then click OK.

5. Please see this TechNet article on configuring trusted rdp publishers on the client side via Group Policy.

NLA with NTLM

If SSL/TLS certificates are not configured on the server and Kerberos authentication is not possible due to the reasons stated above, CredSSP will use the NTLM authentication mechanism to establish trust between the client and server. NTLM can verify a target server’s domain membership; however, if you would like to ensure strong server authentication, you must disable allowing credential delegation with NTLM-only server authentication. To disable these policies on Windows Server 2008, follow these steps:

a. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.

b. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

c. Ensure the following policies for NTLM-only server authentication are disabled:

i. “Allow Default Credentials with NTLM-only Server Authentication”

ii. “Allow Fresh Credentials with NTLM-only Server Authentication”

iii. “Allow Saved Credentials with NTLM-only Server Authentication”

2. Pure SSL/TLS is a standard mechanism that enables clients to authenticate to servers and provides a secure channel by encrypting communications. To use SSL/TLS, you must obtain certificates issued by a trusted Certificate Authority and configure them on each terminal server on which you want to have server authentication.

a. See steps above for setting SSL certificates on Windows Server 2008.

b. See this Knowledge Base article for information on how to configure Windows Server 2003 SP1 to use TLS for server authentication.

3. Network Level Protection mechanisms can be used to mitigate MITM attacks when the server OS version does not support NLA or pure SSL/TLS server authentication mechanisms. For example, you can configure IPSec policies on these earlier versions of TS in order to get mutual authentication and protect RDP traffic against MITM attacks.

a. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.

b. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.

4. A virtual private network (VPN) tunnel can be set up to secure your connection and prevent MITM attacks when users are connecting to servers on your network via the Internet. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.

Mitigation mechanisms supported on different Server OS versions

The table below provides a summary of mitigation mechanisms available for various server OS versions and corresponding clients.

	Server OS Version
Client OS	Windows Server 2000, 2003 Windows Server 2003 SP1 / R2 Windows Server 2008
Windows XP SP2 and earlier	Network Level Protection or VPN Pure SSL/TLS Pure SSL/TLS
Windows XP SP3*, Windows Vista, Windows Vista SP1	Network Level Protection or VPN Pure SSL/TLS NLA or Pure SSL/TLS

*Windows XP Service Pack 3 now supports NLA; therefore if you have Windows Server 2008 in your environment, it is strongly recommended that you upgrade to Windows XP SP3 or later in order to take advantage of Network Level Authentication. See this Knowledge Base article for more details on upgrading to TS Client 6.1 with Windows XP SP3.

· Note that CredSSP is not enabled on Windows XP SP3 by default; therefore you will also need to perform the steps outlined in this KB article to turn on CredSSP.

· Also note that even though RDP Client 6.1 is available on Windows XP SP2 now, NLA is still not supported on Windows XP SP2.

Windows Server 2003 SP1 and higher

Strong server authentication, which prevents MITM attacks can be achieved on Windows Server 2003 SP1 and higher, using the two server authentication mechanisms described above. Pure SSL/TLS can be used for Windows Server 2003 SP1 and Windows Server 2008. In addition, Windows Server 2008 uses NLA for clients that support it.

Earlier Server OS versions prior to Windows Server 2003 SP1

As shown in the table above, TLS/SSL certificates can only be deployed on Windows Server 2003 SP1 and later, while NLA is available only on Windows Server 2008. Windows Server 2003 without SP1 and earlier does not support NLA or pure SSL/TLS server authentication mechanisms. Therefore, on earlier Server versions, you will need to use network level protection mechanisms (such as IPSec) to get mutual authentication and protect RDP traffic against MITM attacks. Alternatively, you can set up a VPN tunnel for your connection.

1. See this KB article for information on configuring IPSec for TS communications in Windows Server 2003.

2. See this KB article for information on configuring IPSec for TS communications in Windows Server 2000.

3. See this step-by-step guide on configuring Remote Access Server on Windows Server 2003.

Client SKU used as a TS server

If you are connecting remotely to client operating systems, then only Windows Vista and Windows Vista SP1 that support Network Level Authentication will be able to provide strong server authentication with Kerberos as Windows Server 2008 described above. NLA with SSL/TLS is not possible on Client SKUs. On a downlevel client OS, you can configure VPN to secure your communications. See this KB article on configuring VPN on Windows XP.

Remote Desktop Connection (Terminal Services Client 6.1) for Windows XP SP2 x86 platforms

Hello everyone,

we heard a lot of feedback from you about the need for the Remote Desktop Connection client 6.1 to be made available as a standalone install for Windows XP SP2 to ease deployments of Windows 2008 Terminal Services.

In response to this feedback, we have released the Remote Desktop Connection client (RDC 6.1) for Windows XP SP2 on x86 platforms.

You can download RDC6.1 for Windows XP SP2 from the Microsoft Download Center (KB 952155) for the following languages:

Arabic, Chinese - Simplified, Chinese – Traditional, Danish, Dutch, English, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese – Portugal, Portuguese – Brazil, Russian, Spanish – Spain, Swedish, Turkish.

We have also released the MUI package for RDC6.1 on Windows XP SP2 from the Microsoft Download Center (KB 952230).

These are some of the supported features of Remote Desktop Client 6.1 for Windows XP SP2:

• Windows Server 2008 & Windows Vista feature support
• TS Web Access support
• TS Easy Print support
• TS Remote Programs support
• TS Gateway support

Please review the complete list of features and details about RDC6.1 for Windows XP SP2 in this Knowledge Base article.

 

 RDC6.1 is now available on the following platforms:

 

Windows Server 2008

Windows Vista SP1

Windows XP SP3

Windows XP SP2 (KB 952155)

Terminal Services Application Analyzer Beta

What is Application Compatibility for Terminal Services?

Application Compatibility is the term given to the collection of issues which prevent an application from executing satisfactorily (or in an expected manner) in a given environment - in this case Windows Terminal Services (TS) platform.

TS is deployed for a variety of reasons such as reducing total cost of ownership (TCO), better security & compliance, enabling mobility, etc.

Following are some problems faced by client applications in a TS environment:

1. Client applications are generally written for a single user. Because TS is a multiuser system, this might cause synchronization problems.
2. Some applications are written with the assumption that their binaries are running with administrator privileges. In TS, a normal user is rarely given administrative privileges.
3. Behavior of some APIs is different in a TS server environment than in a client operating system. This might cause programs such as unexpected results from some operating system calls.

 

TS Application Analyzer

TS Application Analyzer is a runtime program analysis tool to enable administrators/users to determine if they can deploy an application on TS with confidence. It provides a summary of an application’s TS-incompatible behavior. The classes of application compatibility issues targeted for detection are:

1. Shared resources – files/registries
2. Access/privilege issues
3. Windows API calls with special cases for TS

The tool does the following:

1. Enables administrators to analyze test runs on a given binary.
2. Determines whether the binary will face any problems when deployed on TS. If so, the tool determines the type of problem and its severity.
3. Summarizes the findings along with a recommendation.
4. The findings can be exported and analyzed at another computer (e.g. for analysis by a test team).
5. The tool can be deployed on a set of user computers or test computers (running the client OS or the TS server OS) seamlessly. The findings can be collected at the administrator’s computer. The administrator can then analyze the findings from all computers and decide whether the application should be deployed on TS or not.

 

More information and downloads for the tool are available at the Connect website for TS Application Compatibility: http://connect.microsoft.com/tsappcompat

 

The guide for using the tool and the End User License Agreement (EULA) are also available at this site.

 

For any queries about the tool or about TS Application Compatibility, email tsappsup@microsoft.com.

Problems using default credentials with Vista RDP clients with Single Sign-on Enabled

With Single Sign-on enabled, the current user’s credentials, also known as “default credentials”, are used to log on to a remote computer. In several scenarios, users may get the following error message when trying to connect to a TS server with Vista clients using default credentials:

Possible causes (and their recommended solutions) are identical to the issues presented for saved credentials. Just as it does with saved credentials, Windows Vista Credential Delegation policy does not allow a Vista RDP client to send default credentials to a TS server when the TS server is not authenticated. By default Vista RDP clients use the Kerberos protocol for server authentication. Alternatively, they can use SSL server certificates, but these are not deployed to servers by default.  There are three common scenarios where using the Kerberos protocol to authenticate the server is not possible, but using SSL server certificates is possible. Because SSL server certificates are not deployed by default, using default credentials does not work in these scenarios.

Below is a list of scenarios in which this problem appears, along with recommended solutions. This is identical to the scenarios for saved credentials.

Scenario 1: Connecting from home to a TS server through a TS Gateway server

When you connect from home through a TS Gateway server to a TS server hosted behind a corporate firewall, the TS client has no direct connectivity to a key distribution center hosted on a domain controller behind the corporate firewall. As a result, server authentication using the Kerberos protocol fails.  

Scenario 2: Connecting to a stand-alone computer

When connecting to a stand-alone server, the Kerberos protocol is not used.

Scenario 3: Connecting to a terminal server farm

Kerberos authentication does not work in terminal server farm scenarios because farm names do not have accounts associated with them in Active Directory. Without these accounts, Kerberos-based server authentication is not possible.  

Recommended Solution for Scenarios 1 & 2

For scenarios 1 and 2, to enable server authentication, use SSL certificates that are issued by a trusted Certificate Authority and have the server name in the subject field.  Deploy them to all servers that you want to have server authentication. To set the SSL certificate for a connection:

1. At a command prompt, run tsconfig.msc. Note: tsconfig.msc is only available on servers.
2.  Double-click the RDP-Tcp connection object.
3.  On the General tab, click Select.
4.  Select the certificate you want to assign to the connection, and then click OK.

Recommended Solution for Scenario 3

To enable server authentication in a server farm, use SSL certificates that are issued by a trusted Certificate Authority and that have the farm name in the subject field. Deploy them to all servers in your farm. The SSL certificate will provide server authentication for a TS server and therefore Credential Delegation policy will allow saved credentials to be used for remote desktop connections. 

Alternative workaround for these scenarios (less secure than recommended options):

Another option is to allow delegation of users’ default credentials with NTLM authentication mechanism. This option is not recommended because NTLM-only server authentication does not confirm the server's identity. Sending your credentials to such servers can be dangerous.

1. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.
2. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.
3. Select the "Allow Default Credentials With NTLM-only Server Authentication" setting:

 

When enabling this policy, you also need to add "TERMSRV/<Your server name>" to the server list for all servers to which you want to allow NTLM-only server authentication.

 

Instantaneous Session Broker redirection leveraging CredSSP

 

This article discusses some significant improvements achieved in Windows Server® 2008 related to redirecting connections in a TS Farm.

Understanding the terminologies:

Terminal Services Session Broker (TS Session Broker) is a role service in Windows Server® 2008 that allows a user to reconnect to an existing session in a load-balanced terminal server farm. TS Session Broker stores session state information that includes session IDs and their associated user names, and the name of the server where each session resides.

Credential Security Service Provider (CredSSP) is a new security service provider introduced in Windows Vista that enables an application to delegate the user's credentials from the client (by using the client-side SSP) to the target server (via the server-side SSP). Terminal Services client uses this feature to authenticate the user before further negotiation is done with the terminal server to start the session.

Behavior before Windows Server® 2008:

Before Windows Server® 2008, when a terminal server in a farm received a connection request, it created a temporary session to authenticate the user and load user policies. If no local disconnected session was present, it queried the TS Session Broker to see if there was a disconnected session for the user on another machine in the SB farm. If a disconnected session was found, a redirection request was sent to the client to connect to the other server instead. The temporary session was then discarded.

The temporary session creation resulted in significant delay in completing the connection because a full logon occurs in the session. Also, the user experience was unpleasant because the user saw two welcome screens, first for the temporary session and then again for the redirected session. The new technique addresses these drawbacks when a connection is made using the new Terminal Services client with CredSSP.

What changed in Windows Server® 2008:

In Windows Server® 2008, a new load balancing algorithm has been introduced to distribute the load amongst all the servers in the farm. This can increase the number of redirected connections in a Windows Server® 2008 TS farm, hence making it more important to address the drawbacks with redirection.

A new technique was introduced to improve the redirection scenario in Windows Server® 2008. When CredSSP is used, the user credential is available even before temporary session is created. The new technique uses the credentials (user name and domain name) provided by CredSSP and the initial program available at that point, to load the user profile. It then uses the same credential to query for a disconnected session in the SB farm, if the machine is in a farm. If a disconnected session is found on another machine in the farm, it immediately sends a redirect packet to the client and the client subsequently connects to the redirected server. Hence no temporary session is created before the connection is redirected.

Benefits of the changes in Windows Server® 2008:

Security improvements - The use of CredSSP provides enhanced security for terminal servers against rogue clients. With this feature, clients need to authenticate even before the connection sequence is completed and a session is created for the user.

Performance optimization - The new technique removes the expensive process of creating a temporary session if a disconnected session is already available in a farm. This helps improve the redirection performance significantly in terms of time to connect and CPU utilization on the server.

Experiments performed in our lab shows significant performance improvements in terms of CPU utilization.

Fig 1 CPU utilization for a single redirected connection:

 

Figure 1(a) Before Optimization

 

Figure 1(b) After Optimization

Fig 2 CPU utilization for a burst of redirected connections:

 

Figure 2(a) Before Optimization 

 

Figure 2(b) After Optimization

Improved customer experience - In addition to providing performance improvement, the new technique also helps deliver a better user experience for a redirection scenario. This is primarily because the user no longer sees two sessions, one for the first server (temporary session) and one on the redirected server. Instead they see only the final session after redirection occurs.

 

How MSIT Uses Terminal Services as a Scalable Remote Access Solution

 

The MSIT pilot project of Windows Server 2008 Terminal Services was so successful that Microsoft IT went on to test the scalability and performance into the production environment. The environment acts as a SSL-based remote access solution and MSIT was able to create a scalable remote access solution that is accessible by using HTTPS connections from any location worldwide. Additionally, user experience enhancements in Windows Server 2008 improved the end-user experience when using Terminal Services.

Technical White Paper | IT Pro Webcast

Video: Meet the Terminal Services Team

 

As this blog has presented over the last few months, with Windows Server 2008, we have added plenty of key new functionality for Terminal Services. Recently, technet.com completed four episodes on Terminal Services in Windows Server 2008. The episodes interview members of the team and walk through demos of several new features for Windows Server 2008. Take a look and let us know what you think.

• http://edge.technet.com/Media/395/
  Tad talks about what's new with TS in Win2008
• http://edge.technet.com/Media/405/
  Tad explains the TS Gateway and RemoteApp publishing
• http://edge.technet.com/Media/407/
  Sriram whiteboards the multi-user kernel
• http://edge.technet.com/Media/408/
  Niraj expands on TS Gateway, and Kevin talks about TS Web Access and publishing

 

Citrix Publishes FAQ on Microsoft Application Virtualization and Citrix XenApp (formerly Presentation Server) Working Together

Hello everyone!  A lot of people have speculated that Citrix and Microsoft would be at odds over the acquisition of Softricity SoftGrid as it seemed to pit the two partners against each other over application virtualization.  However, working in conjunction with Microsoft, Citrix has just posted a new blog entry which outlines how the two products continue to interoperate, bringing the best of both solutions together to maximize the customer management experience.

http://community.citrix.com/pages/viewpage.action?pageId=19235202

Microsoft also has a KB article and white paper on integrations between the two solutions:

KB931576 - How to publish a SoftGrid-enabled application in Citrix MetaFrame (http://support.microsoft.com/kb/931576)

Best Practices for Integrating Microsoft® SoftGrid® Application Virtualization with Terminal Services and Citrix® Presentation Server®:

http://download.microsoft.com/download/6/4/f/64f5dc66-832a-4df3-baf4-3b4e7fb9e500/SGAV%20White%20Paper%20-%20Terminal%20Svcs%20and%20Citrix.pdf

Enjoy!

Chad Jones | Senior Product Manager

Manual Revocation of Client Access Licenses (CALs)

Prior to Windows Server 2008, there was no way for administrators to manually revoke issued licenses. Issued licenses would automatically expire after a random period between 52-89 days and become part of the available license pool. In some cases, an administrator might want an issued license to become available immediately—typically when a particular machine will no longer be used (for example, the machine is being reformatted) and the license must be made available immediately to another client without waiting until it expires. To address this, we now have a method of revoking a license manually.

Currently, revocation support is only for per-device CALs. Per User Terminal Server mode is not enforced in Windows Server 2008, so there will not be any denial of service from terminal server.

You can only revoke 20% of a specific version of a CAL or one CAL, whichever is more. So, for example, if there are 100 Windows Server 2003 per-device CALs installed, you can revoke only 20 of them. Once 20% of the totals CAL are revoked, Admin will have to wait till any of the revoked CAL expires, so that he can revoke more CAL’s.

Manual revocation of CALs can be done by either of the following mechanisms:

• TS Licensing Manager
• WMI providers

Manual Revocation of CALs using TS Licensing Manager:

1. Open TS Licensing Manager (LicMgr.Exe)
2. Right-click the CAL you want to revoke, and then click Revoke CAL.

 

 

After revocation, the revoked CAL becomes available immediately. The status of the revoked CAL is changed from “Active” to “Revoked,” as shown in figure below.

 

Manual Revocation of CALs using WMI Providers:

Windows Server 2008 also provides support for revocation of issued CALs using WMI providers. CALs revoked through WMI are reflected in TS Licensing Manager.

The following WMI class is used to revoke issued CALs:

Win32_TSIssuedLicense:

Windows Server 2008 has a WMI class named "Win32_TSIssuedLicense" for managing issued per device CALs. This WMI class provides the following interface to manually revoke issued CALs:

Revoke: This API can be used to manually revoke an issued CAL. This is a not a static function.

The syntax of the API is

uint32 Revoke(

  [out]  uint32 RevokableCals,

  [out]  DATETIME NextRevokeAllowedOn );

Where,

• RevokableCals: Number of TS CALs of the same type as the current object that can be revoked.
• NextRevokeAllowedOn: Date that the administrator can next try to revoke licenses. This parameter only contains valid data when the Revoke method call has failed because the maximum revoke count has been reached.

Licensing Diagnosis: Problems and Resolutions

Licensing problems and resolutions for the terminal server

Licensing Diagnosis is capable of diagnosing potential problems in a typical terminal server/ license server deployment.  Here is the list of the potential problems along with their suggested resolutions.

ISSUES WITH DISCOVERY

Problem 1: The terminal server has not discovered any license servers.  If the grace period for the terminal server has expired, connections to the terminal server will be denied unless a license server is configured for the terminal server.

Resolution 1: Configure a license server for the terminal server. If you have an existing license server, use the Terminal Services Configuration tool to specify that license server for the terminal server. Otherwise, install TS Licensing on a computer on your network.

If you have configured a license server for the terminal server but the license server does not appear in the list of discovered license servers, use TS Licensing Manager to review the configuration of the license server.  TS Licensing Manager may be launched using the ‘Start TS Licensing manager' action item available in the action pane for Licensing Diagnosis tool.  For more information on reviewing the configuration for a license server, refer to How to review and configure a license server.

 

Problem 2: License server <Server Name> is not available. This could be caused by network connectivity problems, the Terminal Services Licensing service is stopped on the license server, or TS Licensing is no longer installed on the computer.

Resolution 2: Make sure you have network connectivity between the terminal server and the license server. Also check that the Terminal Services Licensing service is started on the license server. If TS Licensing is no longer installed on the computer, ensure that the license server is not manually specified and/or is no longer published in Active Directory Domain Services.  For more information on un-publishing a license server, refer to Un-publishing license server from AD .

 

ISSUES WITH CREDENTIALS

 

Problem 3: The Terminal Services Configuration tool is running with local account credentials. Licensing Diagnosis will not be able to discover domain or forest license servers automatically and the Total Number of TS client access licenses available value may be inaccurate.

Resolution 3: For best results with Licensing Diagnosis, use the Terminal Services Configuration tool with domain account credentials.

 

Problem 4: To identify possible licensing issues, administrator credentials for license server <Server Name> are required.

Resolution 4: Provide administrator credentials for the Terminal Services license server.  To provide credentials use the ‘Provide Credentials' action item in the action pane for Licensing Diagnosis.

 

ISSUES WITH CONFIGURATION

 

Problem 5: License server <Server Name> cannot issue TS CALs to the terminal server because of a version incompatibility.

Resolution 5: Check that the version of the license server supports issuing TS CALs to the terminal server. The license server must be running the same (or a more recent) version of the operating system as the terminal server. You might need to upgrade your license server to an appropriate operating system or install a new license server with the appropriate operating system.

 

Problem 6: License server <Server Name> is not activated.

Resolution 6: Use TS Licensing Manager to activate and install TS CALs on the license server.  TS Licensing manager may be launched using the ‘Start TS Licensing manager' action item available in the action pane for the Licensing Diagnosis tool.  For more information on activation and installation of TS CALs on a license server, refer to How to activate a license server.

 

Problem 7: License server <Server Name> cannot issue TS CALs to the terminal server because the "License server security group" Group Policy setting is enabled.

Resolution 7: Add the computer account for the terminal server to the Terminal Server Computers group on the license server. 

 

Problem 8: The licensing mode for the terminal server is not configured.

Resolution 8: Set the licensing mode on the terminal server to either Per User or Per Device by using Terminal Services Configuration tool. Use TS Licensing Manager to install the corresponding TS CALs on the license server.  For more information on installation of TS CALs on license server, refer to How to install CALs on a license server.

 

Problem 9: The terminal server is in <Per Device or Per User> licensing mode, but license server <Server Name> does not have any <Terminal Server Version> <Per Device or Per User> TS CALs installed.

Resolution 9: Use TS Licensing Manager to install the appropriate TS CALs on the license server.  If the license server has installed licenses of the other mode, changing the licensing mode for the terminal server may also resolve the issue.  To change the licensing mode, use the Terminal Services Configuration tool.

 

Problem 10: The terminal server is in <Per Device or Per User> licensing mode, but license server <Server Name> does not have any <Terminal Server Version><Per Device or Per User> TS CALs available.  (Note: The license server may have CALs installed but these CALs are currently not available for issuance.)

Resolution 10: Use TS Licensing Manager to install the appropriate TS CALs on the license server.  TS Licensing manager may be launched using the ‘Start TS Licensing manager' action item available in the action pane for Licensing Diagnosis tool.

Additional references

• Windows Server 2008 TechCenter

• What's new in Terminal Services Licensing - Licensing Diagnosis

• Licensing Diagnosis Snap-in
  
• Summary of Licensing Diagnosis

Microsoft Acquires Calista Technologies

Hi, my name is Chandra Shekaran, and I am the general manager for Presentation & Desktop Virtualization at Microsoft. By now, you have probably heard about our Virtualization Deployment Summit today where we made several exciting announcements pertaining to some of our important virtualization strategies (you can find them at Microsoft PressPass). One of the announcements was Microsoft completing the acquisition of Calista Technologies, a leading provider of graphic technologies for the next generation desktop and presentation virtualization solutions. As many of you know, Microsoft has been a leader in the presentation virtualization space for more than 10 years with Windows Terminal Services. With the addition of Calista we will continue to provide the best, broadest and most affordable virtualization technology portfolio for customers and partners. For more read Neal Margulis’ post (Neal is the founder of Calista).

So, what’s so exciting about Calista? Calista’s products dramatically improve the end-user experience of 3D and multimedia delivery for Microsoft multimedia applications, virtualized desktop deployments, and server-hosted virtualized desktops or applications using Windows Terminal Services. Their technologies support all file and streaming media type available, and optimize Microsoft’s widely available Remote Desktop Protocol (RDP) to reduce the network bandwidth requirements for remote display of rich media content; thus, remote workers can receive a modern Windows desktop experience without the need for dedicated hardware. As multimedia and 3D graphics are becoming more ubiquitous in business and consumer contexts alike, customers expect the full desktop experience regardless of their desktop deployment choice. With the addition of Calista technologies, Microsoft will enable users to enjoy a rich remote experience for server-hosted, virtualized desktops and applications, thus allowing an organization full flexibility in their choice to deploy centrally managed desktops or a local traditional desktop. In fact, in one of our other announcements today we talked about the concept of Windows Vista optimized desktop solutions; the idea behind it is to enable customers to use several Microsoft technologies, such as the rich user interface of Windows Vista, server based applications like Windows Server 2008 Terminal Services or hosted desktop technology like Windows Vista Enterprise Centralized Desktops, for personal computing scenarios that best meet their unique needs. Calista will be key in helping customers to make the right trade-off decisions among these deployment options, by helping to ensure a consistent, rich end user experience in those scenarios where users transition between a local and a server-hosted desktop.

There are many other product areas at Microsoft where we believe Calista’s technologies will be extremely beneficial in helping Microsoft to create a superior customer experience, and we are just starting to imagine the potential. More importantly though, I am sure you will want to better understand where in Microsoft’s product portfolio virtualization innovations such as Calista’s will start to materialize first, so please stay tuned and come back here to read our blog every once in a while for more details about the latest product plans and accomplishments.

Chandra Shekaran

Summary of Licensing Diagnosis 2

Understanding the licensing state of a terminal server though Licensing Diagnosis

Summary of Licensing Diagnosis is a summing up of various factors such as the Terminal Services Configuration and License Server information, and is a good indication of the state and availability of a terminal server.  It is the first visible entity and lies above the Terminal Server Configuration Details section in Licensing Diagnosis Snap-in.

 

 

There are 3 possible states of a terminal server as diagnosed by Licensing Diagnosis:

·         Licensing Diagnosis did not identify any licensing problems for the terminal server.

            The ‘Green state’ or   indicates that Licensing Diagnosis was not able to identify any potential issues with the terminal server/license server deployment/configuration in the network.  It also means that the Licensing Diagnosis tool was able to locate (discover) license servers which had available TS CALs that can be used by the terminal server. 

            When the terminal server is in the ‘Green state’, the terminal server is in a stable licensing state and will provide service to connecting users and devices.*

 

·         TS CALs are available for this terminal server, but Licensing Diagnosis has identified licensing problems for the terminal server.

            The ‘Yellow state’ or  indicates that the Licensing Diagnosis was able to locate license servers that had available TS CALs which can be used by the terminal server. However, the tool identified potential issues with the terminal server/ license server deployment/configuration that the administrator may want to address.  For more information about potential problems and suggested solutions, refer to the Licensing Diagnosis: Problems and Resolutions.

            When the terminal server is in the ‘Yellow state’, the terminal server does not have any critical configuration and licensing issues and will provide service to connecting users and devices.*

 

·         TS CALs are not available for this terminal server, and Licensing Diagnosis has identified licensing problems for the terminal server.

            The ‘Red state’ or  indicates that the Licensing Diagnosis has identified potential issues and has not been able to locate any license servers that have the required TS CALs available for the terminal server.  This suggests that the terminal server is in a critical state and the identified problems need to be resolved in order to prevent denial of service to connecting clients.

            When the terminal server is in the ‘Red state’, the terminal server has critical configuration and licensing issues which must be addressed to prevent denial of service.  For more information about potential problems and suggested solutions, refer to Licensing Diagnosis: Problems and Resolutions.

 * Licensing Diagnosis tries to diagnose all configuration problems with licensing that can potentially affect the service of the terminal server.  This means that though Licensing Diagnosis Summary is a good indicator of the state and availability of the terminal server, it does not take into account all possible network configurations and issues.  Thus a terminal server in ‘Green or yellow’ state can still deny service due to other problems in the network but the chances of encountering such a state are very low.

 

Additional references

·      Windows Server 2008 TechCenter

·      What’s new in Terminal Services Licensing – Licensing Diagnosis

·         Licensing Diagnosis Snap-in

·         Licensing Diagnosis: Problems and Resolutions

Changes to Remote Administration in Windows Server 2008

This article describes the differences between Windows Server 2003 and Windows Server 2008 when you use the Remote Desktop Connection (RDC) client to remotely connect to the server for administrative purposes.

 

In Windows Server 2003, you can start the RDC client (mstsc.exe) with the /console switch to remotely connect to the physical console session on the server (also known as session 0). In Windows Server 2008, the /console switch has been deprecated. (For more information, see the “Why the /console switch is no longer needed” section of this article.) In Windows Server 2008, session 0 is a non-interactive session that is reserved for services.

 

You can use the new /admin switch to remotely connect to a Windows Server 2008-based server for administrative purposes. The /admin switch is introduced with RDC 6.1. RDC 6.1 is included with the following operating systems:

•       Windows Server 2008

•       Windows Vista Service Pack 1 (SP1) Beta and RC

•       Windows XP Service Pack 3 (SP3) Beta and RC

 

Note   RDC 6.1 (6.0.6001) supports Remote Desktop Protocol (RDP) 6.1.

 

RDC 6.1 does not support the /console switch. However, for backward compatibility, you can use the /admin switch to connect to the physical console session on a Windows Server 2003-based server. For example, to connect from a Windows Vista SP1 RC-based client to the physical console session of a Windows Server 2003-based server, you can run the command mstsc.exe /admin.

 

If you try to use the /console switch with the RDC 6.1 client, the behavior is as follows.

 

 

Scenario	Behavior
You type mstsc.exe /console at the command prompt, and then connect to a remote server that does not have Terminal Server installed.	The /console switch is silently ignored. You will be connected to a session to remotely administer the server.   (For more information about the Windows Server 2008 behavior, see the “Behavior when you connect to a server that does not have Terminal Server installed” section of this article.)
You type mstsc.exe /console at the command prompt, and then connect to a remote server that has Terminal Server instal