Remote Desktop Services (Terminal Services) Team Blog

Announcing the launch of Remote Desktop Services Script Center to ease management

Hi everyone. We have published scripts to help simplify Remote Desktop Services management—including Virtual Desktop Infrastructure (VDI) management. You can download these scripts from the Remote Desktop Services page on Script Center.

Here are some of the Remote Desktop Services management scripts that are available now:

Virtual machine management

Configure Guest OS for VDI (can be run as GP start-up script)

Virtual machine assignment management

Bulk assign virtual machines to users or pools

List VM assignment information

Infrastructure setup: RD Connection Broker cluster creation and management

Manage RD Connection Broker cluster (create, add nodes)

Update RD Connection Broker configuration across nodes in a cluster

Troubleshooting: Configuration verification

Others

Monitor sessions

Generate usage report

Deploy RemoteApp programs to the Start menu by using RemoteApp and Desktop Connection

Please visit the Script Center and try these scripts, and then let us know what you think. You can provide feedback either through the Comments section or the Discussion feature in Script Center.

You can also upload your scripts to Script Center. Click Upload on the right side of the Script Gallery home page and follow the simple process.

We’ll update this post when additional scripts are available. Keep watching this space.

Windows 7 with RDP7: Best OS for VDI

In the minds of IT admins looking to enable a virtual desktop infrastructure (VDI) environment, Windows XP has by far been the preferred OS running in the VMs. However, with the arrival of Windows 7, IT admins have several important reasons, as outlined in this blog, to reconsider. In fact, an upcoming RDP Performance Whitepaper will provide a rich set of data to convince even the most skeptical critics that Windows 7, with its enhanced user experience, performance on the wire, and security outshines Windows XP as the virtualized guest OS of choice.

When users connect to a Windows 7 VM, the RDP7 protocol will be used to communicate between client and VM if RDP 7 or Remote Desktop Connection 7 (RDC7) client is used. RDC7 client is offered on variety of OSs, including XPSP3, Vista SP1 and Vista SP2 and the same client is part of the Windows 7 OS (see blog post for more details: Announcing the availability of Remote Desktop Connection 7.0 for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2 ).

When an RDP 7 client connects to a Windows 7 VM, it can take advantage of all the new features implemented in Windows 7.  However, when the same RDP 7 client connects to a Windows XP VM, it will start talking the 9-year-old RDP 5.2 protocol.

User Experience

To test the user experience improvements that the RDP 7 client provides when connecting to a Windows 7 guest VM, we picked the following scenarios:

1. Media(.wmv) playing in a remote session with Windows Media Player
   1. A Windows 7 VM will give you an experience that is close to watching the same video locally from your PC
   2. On Windows XP with RDP5.x , the video may degrade to become a “slide show” with audio sync behind
2. Video playing from any popular site:
   1. You’ll find that with Windows 7 you can enjoy the video content
   2. With Windows XP, the experience is much worse. You may experience the same “slide show” effect as with media .wmv files
3. Aero graphics (“Aero glass”)
   1. RDP7 with Windows 7 is able to remote Aero for your increased productivity and pleasure, so you don’t need to default to the green field of Windows XP Classic theme.
   2. Windows XP will not be able to provide Aero
4. Audio chat experience
   1. Windows 7 will provide you with bi-directional audio, i.e. with the chance to reply, not only listen silently to the conversation. Using the microphone on your local device, you will be able to change a monologue to a dialogue
   2. With Windows XP, there will be no microphone input from your client computer
5. Multimonitor sessions--here the difference is even more pronounced
   1. If you have more than a single monitor when connected to a Windows 7 VM, all of them will be available to your virtual desktop
   2. If you continue to work with Windows XP, only one of the monitors will be used, all others will sit on your table collecting dust
6. Logon speed
   1. Window 7 Client boots faster; you can initiate logon before the whole OS is booted up.
   2. Windows XP boots slower; you have to wait for the entire OS to boot up before logging on.

Performance

Let’s examine the performance of the RDP 7 protocol compared to the RDP 5.2 protocol of the Windows XP era.

1. Windows 7 introduced a new codec that compresses bitmaps very well and can also distinguish between text and images, applying different compression techniques with different levels of “lossiness” to text or images. The goal with text is to keep it readable, so lossy compression has to be avoided. With images, the human eye is more forgiving when we allow some lossiness, in order to save bandwidth. Windows XP is using RDP 5.2 bitmap compression, which requires twice as much bandwidth on the wire as the RDP 7 codec and does not have a good dynamic approach for different types of content.
2. In addition to the bitmap compression improvement, the RDP 7 protocol supports a better byte compression technique that is 3 times more effective for all content from a VM to an RDP 7 client--graphics, print data, audio, clipboard, media, and so on. A Windows XP VM will use an older byte compression algorithm that will not be comparable to the modern compression technique available in RDP 7.
3. IT admins can prioritize interactive traffic (graphics) higher than non-interactive traffic (print/files/clipboard) by assigning a ratio of available bandwidth to these two categories of traffic. By default in both Windows 7 and Windows XP, 70% of the available bandwidth is given to graphics/interactive data, and 30% to all other content. Only Windows 7 VMs allow admins to control this ratio based on their real needs.

Security

Windows 7 with RDP 7 takes remote session security to the next level. When connecting to a Windows XP VM, a connection will be created before security handshakes are finished:

1. Windows XP VM does not support Kerberos for client/server and/or user authentication
2. Windows XP VM does not support Network Layer Authentication (NLA): the remote session can be created even for a rogue user
3. Windows XP VM, does not support Server Authentication, so this VM can be used by any RDP server to steal user credentials
4. Windows XP VM does not support Transport Layer Security (TLS) / Secure Sockets Layer (SSL)

Windows 7 VM with RDP 7 supports all of the functionality you need to keep your system more secure: user-server authentication, Single Sign On, and Network Layer Authentication.

Administration

Windows 7 VMs are easier to deploy and administrate than Windows XP VMs.

1. On Windows 7, there is no need to install an enlightenment package or to reboot VMs after a VDI configuration. On Windows XP, the administrator needs to install the enlightenment package and reboot the VMs before the OS can be accessed by the user
2. Windows 7 supports offline domain join, which makes the process of joining a VDI VM to a domain faster and less error-prone
3. Windows 7 has a newer version of sysprep, which enables the administrators to create Windows 7 VMs faster

The take-home message from this blog is simple: if you are considering deploying a VDI environment and you're after the best user experience, performance, security, and administration support, I recommend you use a device running the new RDC7 client connecting to Windows 7 as the desktop OS running in the virtual machines.

Remote Desktop Load Simulation Toolset

I am pleased to announce the availability of the Remote Desktop Load Simulation Toolset.   Many customers have asked us to provide the specific number and type of servers to use for Remote Desktop Services scalability.  This is a difficult question to answer without more complete information given the variation in use cases and the impact on server loading.

To help answer that question, the RDS team created a toolset to create and measure load when using Remote Desktop Services.  We believe this toolset will also be useful for customers that wish to conduct their own scalability testing. 

It’s important to note that this is one tool to help answer this question, but not the only one.  In addition to using this toolset, measuring and understanding your own environment and usage cases is very important.

The Remote Desktop Load Simulation Toolset is now available for download at http://www.microsoft.com/downloads/details.aspx?FamilyID=c3f5f040-ab7b-4ec6-9ed3-1698105510ad&displaylang=en

Announcing the availability of Remote Desktop Connection 7.0 for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2

We are pleased to announce the availability of Remote Desktop Connection 7.0 for downlevel operating systems on Wednesday, October 28^th. KB969084 provides a detailed description of available functionality and provides links to the download package. This follows the previous post here that described in detail the functionality available using Remote Desktop Connection 7.0 on Windows 7, Windows Vista, and Windows XP SP3.

The Windows XP SP3 Multilingual User Interface (MUI) package release is also coming soon. Stay tuned for this announcement in a few weeks.

Update: If you have previously installed the fix in KB968358 (You cannot use a mouse to select combo box items in a RemoteApp program that you connect to through Remote Desktop Connection (RDC) 6.1), installing RDC 7.0 will undo the fix.  We'll let you know when this is corrected.

RDS CAL Single Pack now available in Retail channel

Remote Desktop Services client access licenses (RDS CALs) were formerly sold in packs of 5 and 20. Customers buying Retail RDS CALs didn’t have a choice of buying a single CAL, which meant that they had to buy the next higher CAL Pack. For example, if the customer wanted 6 CALs, he had to buy two 5-CAL Packs.

In response to customer requests, we now offer Single CAL Packs, giving customers the ability to buy exactly the number of CALs that they need. Single CAL Packs are available for Windows Server 2008 and Windows Server 2008 R2 in the following two types:

• Per User
• Per Device

Single CAL Packs are available with Retail and OEM channels and not with Volume licensing channels like Select, Open and Enterprise Agreements, as they can already order in units of one. 5- and 20-CAL packs are also still available.

To install a Single CAL Pack on Windows Server 2008 R2 license server, follow the steps you would use to install any other retail CAL Pack. For Windows Server 2008, ask your TAM (Technical Account Manager) or EE (Escalation Engineer) for KB971302 and install it on the license server. After installing this QFE on Windows Server 2008 license server, you can follow the same procedure to install the Single CAL Pack as any other retail CAL Pack.

Using App-V without application sequencing for RDSH Compatibility issues

Introduction

This blog post refers to Microsoft Application Virtualization (App-V), which decouples applications from the operating system and virtualizes applications per user, per application instance. As a result, application conflicts and the need for regression testing are dramatically reduced (See here for details).

App-V mitigates the application compatibility issues under Remote Desktop Services by reducing the conflicts between multiple application instances. However, the application must be pre-processed or ‘sequenced’ before deploying it on App-V.

App-V also allows an alternative method to run an application in the virtualized environment without sequencing (for debugging purposes). The “RDS Compatibility using App-V” script leverages this functionality of App-V to enable any application to run inside an App-V bubble without sequencing it.

Who should use this script?

This script is targeted at IT administrators who intend to address application compatibility issues with applications deployed on RDSH.

The main goal of the script is to run the applications that cannot run under Remote Desktop Service Host due to compatibility issues and are not targeted for sequencing. The script is used to run these applications quickly using App-V without sequencing them and is best suited for the following scenarios:

· Fixing run-time application compatibility issues on RDSH where sequencing is not possible

· Evaluating and verifying App-V application compatibility without sequencing the applications

How is this method different from using sequenced applications?

The preferred way of running applications under App-V is to first sequence them and then run them with the App-V client. This enables the usage of the complete virtualization and other features of App-V.

The debugging method leveraged in this script does not enable file-system virtualization. Overall, this script is best suited for scenarios in which sequencing is not feasible.

How can I use this script? Where can I get this script?

The script and the instructions to use it are available at http://gallery.technet.microsoft.com/ScriptCenter/en-us/f632175d-42a5-41b5-be81-67de7b735a02

References

Microsoft App-V: http://www.microsoft.com/systemcenter/appv/default.mspx

Microsoft App-V for RDSH: http://www.microsoft.com/systemcenter/appv/terminalsvcs.mspx

Whitepaper Release: Application Virtualization 4.5 for Terminal Services

We are proud to announce the availability of the white paper “Application Virtualization 4.5 for Terminal Services.”  This white paper discusses the benefits, configurations, and considerations when planning a Terminal Services (TS) solution with Microsoft Application Virtualization for TS (App-V for TS).  Many customers want to find out the best way to configure and/or deploy App-V for TS on terminal servers.  This paper includes topics ranging from choosing an App-V for TS application delivery method to configuring RemoteApp and App-V for TS to work together.  We hope you find this document an indispensible read if you are implementing App-V for TS.

You can download the white paper here.

Using Remote Desktop Easy Print in Windows 7 and Windows Server 2008 R2

What’s new in Windows 7?
Easy Print Redirection was available for Windows Server 2008 TS only and it was not available when connecting to computers running Windows Vista. Now it will also be available when connecting to Ultimate/Enterprise editions of Windows 7 and Windows Server 2008 R2 Remote Desktop Session Host servers. In addition, we’re happy to announce that with Win7 / WS08 R2, Easy Print no longer has a dependency on .NET Framework -- a common request from customers that didn’t want to install .NET on all clients from which they wanted to print. The XPS format to GDI conversion was done via .NET Framework before, but for Win7 / WS08 R2 the operating system does this conversion itself.

For the full documentation about how Easy Print works, refer to this three-part blog :
http://blogs.msdn.com/rds/archive/2007/04/26/introducing-terminal-services-easy-print-part-1.aspx
http://blogs.msdn.com/rds/archive/2007/05/03/introducing-terminal-services-easy-print-part-2.aspx
http://blogs.msdn.com/rds/archive/2007/10/05/introducing-terminal-services-easy-print-part-3.aspx

Remote Desktop Easy Print configuration properties:
The following table displays the Client/Server combinations that support Easy Print.

If all the requirements are met, the Easy Print driver is listed in the Model field of the redirected printer’s Properties dialog.

Troubleshooting:

• If you experience formatting problems using Easy Print.
  Refer to the KB- 954744 article at http://support.microsoft.com/kb/954744 (related: KB954743).
  Refer to the KB- 970603 article at http://support.microsoft.com/kb/970603
  Refer to the KB- 959442 article at http://support.microsoft.com/kb/959442
  
• If the client printers are not redirected as Easy Print:
• First check the RDP version on the RDP client computer as well as the .NET framework version with respect to the operating system used (as explained above). Also verify that the RD Session Host / Terminal Server role is installed if the host computer is running Windows Server 2008 R2 or Windows Server 2008.
• Group Policy must be correctly set to enable Easy Print on the Server. The policy location is “Computer Configuration -> Administrative templates -Windows Components -> Remote Desktop Services > Remote Desktop Session Host -> Printer Redirection”. The setting “Use Remote Desktop Easy Print printer driver first” must be set to “Enabled” for Easy Print redirection, and it has to be “Disabled” for Legacy Print. For “Not configured”, Easy Print is chosen by default.
   
• Check The Remote Desktop Configuration Tool (tsconfig.msc) settings to ensure that the “Windows Printer” option is not disabled (it is not disabled by default).
• Make sure that the “Printers” check box in the client (mstsc.exe) window on the “Local Resources” tab is checked. The corresponding setting in the associated RDP file is “redirectprinters:i:1”.
• Ensure that the spooler service is running on both the RDP Client & Server.
  Windows Server 2008 added the ability for an Admin to configure spooler security and Windows 7/Windows Server 2008 R2 adds the UI for this. Therefore, it would be possible to alter the RDP server’s spooler security descriptor which might prevent RDP client printers from being redirected on the session. The spooler security descriptor must contain the “AU” (Authenticated User) ACL (Access Control List) which allows any authenticated user to open the spooler service for reading operations. Therefore, if that ACL is missing from the spooler security descriptor, it must be added like the example below using the command prompt (elevated).
  > sc sdshow spooler
  D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SY)
  > sc sdset spooler D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSD
  RCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SY)
  [SC] SetServiceObjectSecurity SUCCESS
• If you connect over RD Gateway, ensure that the policy that disables printer redirection is turned off.
• If everything listed so far is correct and you still have a redirection problem, check the event logs.
  
  Some of the events to look for are:

  Event ID	Message	Explanation
  1105	Printer security information for the printer could not be set.
  1109	The printer could not be set as the default printer.	The default client printer and the default printer in the RDP session must be the same.
  1111	The driver required for the printer is unknown. Contact the administrator to install the driver before you log in again.	If the Easy Print driver is missing in the host, this event will be logged.
  1116	The printer cannot be redirected by using Remote Desktop Easy Print. The client computer may not have a version of the Remote Desktop Connection client or Microsoft .NET Framework installed that supports this driver.	Make sure you’ve met all the requirements in the table above.
  1103	An internal communication error occurred. Redirected printing will no longer function for a single user session. Check the status of the Remote Desktop Device Redirector in the System folder of Device Manager.
  1124	The number of printers per session limit was reached.

  
  
• If the number of redirected printers is less than the number of the RDP client printers.
  The maximum number of printers that can be redirected is controlled by the registry key “MaxPrintersPerSession REG_DWORD” which is under the node “HKLM\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services”.
  The default value for this is 20 printers per session.
• If Easy Print is unable to print on a domain controller.
  Refer to the Knowledge Base Article 968605 at http://support.microsoft.com/kb/968605/EN-US
• If the client printer is redirected as Easy Print and the user is unable to stop a print job on the redirected printer.
  Take ownership of the printer and allow the “Print” & “Manage printers” permissions. But note that when logged off from the RD Session, the remote printer settings are not retained.
  

Control the Issuance of RDS CALs

This post is for customers or administrators who want to control which Remote Desktop Session Host (RD Session Host) servers are issued Remote Desktop Services client access licenses (RDS CALs) and which version of RDS CAL is issued to the RD Session Host servers. By default, a Remote Desktop license server issues an RDS CAL (if an appropriate RDS CAL is available) to any RD Session Host server that requests one on behalf of a client that is trying to connect to the RD Session Host server. This post also discusses how to control the auto-discovery of a license server running Windows Server 2008 R2 from terminal servers running Windows Server 2008 or Windows Server 2003.

Control which RD Session Host servers are issued RDS CALs

For security reasons, you might want to specify the RD Session Host servers to which a license server offers RDS CALs. You can apply the License server security group Group Policy setting to a Remote Desktop license server to control which RD Session Host servers are issued RDS CALs by the license server.

• If you apply this policy setting to a Remote Desktop license server, it responds only to requests for RDS CALs from RD Session Host servers whose computer accounts are members of the Terminal Server Computers group.
  Note: The Terminal Server Computers group is created as a local group on the license server the first time the Remote Desktop Licensing service is started on the license server. By default, the Terminal Server Computers group is empty. If you disable or do not configure the License server security group policy setting, the Terminal Server Computers group is not deleted or changed and the license server issues an RDS CAL (if an appropriate RDS CAL is available) to any RD Session Host server that requests one.
• You should enable the License server security group policy setting when the license server is a member of a domain so that only you can add computer accounts for RD Session Host servers to the Terminal Server Computers group. The policy setting has no effect if you enable it on a license server that is a member of a workgroup; the license server continues to issue RDS CALs to any RD Session Host server that requests RDS CALs from the license server.

Location of the License server security group policy setting: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\RD Licensing

If the License server security group policy setting is enabled and applied to a license server, it is noted in Review Configuration in the Remote Desktop Licensing Manager tool (Click Start -> Administrative Tools -> Remote Desktop Services -> Remote Desktop Licensing Manager. In the left pane, right-click the server name under the All servers node and select the Review Configuration option).

To verify whether an RD Session Host server is allowed to request RDS CALs from the Remote Desktop license server, you can use the IsSecureAccessAllowed method of Win32_TSLicenseServer class. For more details about this method, click here.

Control which version of RDS CAL is issued to RD Session Host servers

By default, a license server attempts to provide the most appropriate RDS CAL for a connection. For example, a license server running Windows Server 2008 R2 tries to issue a Windows Server 2008 R2 RDS CAL for clients connecting to an RD Session Host server running Windows Server 2008 R2, and a Windows Server 2003 TS CAL for clients connecting to a terminal server running Windows Server 2003.

If the most appropriate RDS CAL is not available, a license server running Windows Server 2008 R2 issues a Windows Server 2008 R2 RDS CAL, if available, to a client connecting to a terminal server running Windows Server 2003 or Windows Server 2000.

You can use the Prevent license upgrade Group Policy setting on the license server so that it issues only a temporary RDS CAL to the client if an appropriate RDS CAL is not available (if the licensing mode of the RD Session Host server is set to Per Device). If the client has already been issued a temporary RDS CAL and the temporary RDS CAL has expired, the client will not be able to connect to the RD Session Host server, unless the RD Licensing grace period for the RD Session Host server has expired.

Note: As the Per User licensing mode is not enforced, the license server will issue the appropriate version of CAL even if the Group Policy setting is not set. You need to have the appropriate number and version of CALs to be compliant with the Microsoft Software License Terms.

Location of the Prevent license upgrade policy setting: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\RD Licensing

To verify whether the Prevent license upgrade Group Policy setting is enabled or not, you can use the IsLSPreventUpgradeGPEnabled method of Win32_TSLicenseServer class. For more details about this method, click here.

Control the auto-discovery of the Remote Desktop license server

In Windows Server 2003 and Windows Server 2008, the terminal servers (now Remote Desktop Session Host servers) were configured to auto-discover the license server by default. If you want to over-ride the license server discovery process, this KB article might help you. In case you want your terminal server to discover the license servers automatically but don’t want your license server running Windows Server 2008 R2 to be discoverable by terminal servers running Windows Server 2008 or Windows Server 2003, here are some tips:

• If you have installed your license server in a domain scope and don’t want it to be discoverable by down-level terminal servers, install it on a domain-joined machine but not on the domain controller. If you install your license server on the domain controller, all down-level terminal servers will be able to discover that license server.
• If you have installed your license server in a forest/enterprise scope and don’t want it to be discoverable by down-level terminal servers, un-publish the license server. To un-publish the license server, you can use the UnpublishLS method of the Win32_TSLicenseServer class. For more details about this method, click here.
• If you don’t want your license server to be discoverable in some other site/domain than the current one, un-publish it from that particular site/domain.

What’s the difference between a RDS CAL and a TS CAL?

Hi, I’m Alex from the Remote Desktop Services (RDS) team.  I want to talk about the Windows Server 2008 RDS CAL which replaces the older Terminal Services (TS) CAL.  I want to explain why the name changed, what this means for you and how we have added some great new value to the RDS CAL.  There are 4 key changes I want to clarify:

1.       Equivalence of the Windows Server 2008 TS CAL & Windows Server 2008 RDS CAL

2.       Difference in price between 2008 TS CAL and 2008 RDS CAL

3.       Transition Pricing & Availability of TS CAL and RDS CAL

4.       Inclusion of Microsoft Application Virtualization (App-V) for TS with the 2008 TS CALs and 2008 RDS CALs

The rest of this post explores these items in more detail.

Equivalence of Windows Server 2008 TS CAL & Windows Server 2008 RDS CAL

Last year, we changed the name of Terminal Services to Remote Desktop Services in Windows Server 2008 R2.  As such, we renamed the CAL. You may notice the CAL is called a Windows Server 2008 RDS CAL (rather than 2008 R2 CAL).  This is because R2 is a refresh release and while you need to buy new Windows Server licenses you do not need to buy new RDS CALs if you already own 2008 TS CALs.  This means you can use the Windows Server 2008 TS CALs with your Windows Server 2008 R2 Remote Desktop Services.  If you have Windows Server 2003 TS CALs you will need to buy new RDS 2008 CALs.

Difference in price between 2008 TS CAL and 2008 RDS CAL

With Windows Server 2008 R2 Remote Desktop Services , Microsoft has added some fantastic new capabilities that improve the traditional Session Host scenarios (formerly known as terminal server) and enable new emerging Virtual Desktop Infrastructure (VDI) scenarios. For example, RDS provides:

·         Simplified management with a unified and scalable connection broker for both Session Desktops and VDI Desktops providing:

o   Unified Remote Desktop Web Access (RD Web Access) and  ‘RemoteApp and Desktop Connection’ feature for access to VDI and Session Desktops

o   Ensures users can only see the apps they are supposed to with per-user RemoteApp permissions and  filtering

·         Provides the user a rich remote experience, bringing the experience closer to that enjoyed by users accessing local computing resources such as:

o   True multi-monitor support

o   Windows Media® Player redirection,

o   Bidirectional audio,

o   Enhanced bitmap acceleration for 3D applications and rich media content such as Silverlight and Flash.

·         Improved application compatibility and management of RD session host servers with the inclusion of Microsoft Application Virtualization for TS

To reflect the addition of these new features and capabilities in Windows Server 2008 R2 Remote Desktop Services the price of the Windows Server 2008 RDS CAL will be approximately 5% higher than the previous Windows Server 2008 TS CAL it replaces.

Transition Pricing & Availability of TS CAL and RDS CAL

We understand that for some of our customers this may be an unexpected change.  As such we will be offering Windows Server 2008 RDS CALs at a transition price equivalent to the old TS CAL from their introduction on September 1, 2009 until December 31, 2009.  Beginning January 1, 2010 any new RDS CAL sales will be at the normal RDS CAL price.

The Windows Server 2008 TS CAL will no longer be available after September 1, 2009 if you have any version of Terminal Services or Remote Desktop Services you should purchase Windows Server 2008 RDS CALs.

Inclusion of Microsoft Application Virtualization for TS with the 2008 TS CAL and 2008 RDS CALs

Application compatibility and management are  significant drivers of cost for many TS / RDS customers.  By including the right to use App-V for TS as part of the TS & RDS CALs we have simplified licensing and enabled as many of our RDS customers to enjoy the benefits that App-V for TS provides; which in addition to solving app-to-app conflicts and multiuser application conflicts also enables you to do the following for both you terminal servers and session host (session hosts are the new name for terminal servers!):

·         Consolidate Session Host / terminal servers and end server siloing

·         End application conflicts and regression testing

·         Accelerate application deployment for Session Hosts

·         Reduce Deployment Risk

·         Simplify Profile Management

For more information on the benefits of Microsoft Application Virtualization for Terminal Services see http://www.microsoft.com/systemcenter/appv/terminalsvcs.mspx

The App-V CAL for TS will not be available for purchase after November 1^st 2009.

Note: This does not affect App-V for Desktop licensing on Windows .  App-V for Desktops continues to be included and licensed via the Microsoft Desktop Optimization Pack (MDOP) with no change.

What does 64-bit only change about Windows 2008 R2 RDS?

Introduction to 64-bit only

As is well known to most of us, the mainstream server shipments today contain 64-bit processors. The 64-bit Windows Server 2008 R2 offers direct access to more virtual and physical memory than 32-bit systems and processes more data per clock cycle, enabling more scalable, higher performing computing solutions. While Windows Server has supported 64-bit platforms for the past several versions, Windows Server 2008 R2 ships with a 64-bit SKU only; no 32-bit SKU is available for the server version of the operating system.

Two types of 64-bit processors

There are two 64-bit Windows platforms: x64-based and Itanium-based.

The x64 processors are compatible with the x86 processors at a hardware level and x86 instructions are executed natively by the micro-architecture. Therefore, execution speed under WOW64 on x64 is similar to its speed under 32-bit Windows. On the Intel Itanium processor, more software is involved in the emulation, and performance suffers as a result.

On the Intel Itanium processor, WOW64 adds significant overhead if two or more instances of the same 32-bit application are running concurrently. This is due to the native 8 KB pages on the Intel Itanium, which complicates the emulation of the native 4 KB pages on the x86 architecture (more pages are marked as writable; all writable pages are private to the process). This is not the case for the x64 processor.

Overall, for 32-bit applications the x64 offers a more compatible and better performing platform.

RDS ships for x64 only in Windows Server 2008 R2

As far as Remote Desktop Services (RDS) is concerned, only the x64 platform is supported. So the question really boils down to: “How does moving from x86 to x64 RDS platform affect me?”

Some of the most common FUD around this is regarding application compatibility.

In this post, we will look at a high-level overview of 32-bit application support in Windows Server 2008 R2 and point you to various resources that should help answer most of your questions related to the same. Please note that 16-bit DOS, Windows, or OS/2 applications are not supported on 64-bit Windows.

Applications on 64-bit Windows Server

Overview

The first thing to understand is that most 32-bit applications should work fine on 64-bit Windows. To enable this, Windows provides Windows 32-bit On Windows 64-bit (WOW64 – See WOW64 Implementation Details), an emulation layer that enables 32-bit Windows-based applications to run seamlessly on 64-bit Windows. Windows automatically detects an application as 32-bit and runs it using WOW64, and most of your applications should run transparently.

WOW64 is provided with the operating system and does not have to be explicitly enabled. The system isolates 32-bit applications from 64-bit applications, which includes preventing file and registry collisions. Console, GUI, and service applications are supported. The system provides interoperability across the 32/64 boundary for scenarios such as cut and paste and COM. However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution. This restriction does not apply to DLLs loaded as data files or image resource files. For more information, see LoadLibraryEx.

Limitations

At the same time there are some known limitations of WOW64 that might cause incompatibilities with some classes of applications. These issues are discussed at length in the “Best Practices for WOW64” whitepaper which is a recommended read. Some of these are listed below –

· The address space is limited to 2 GB by default, and 4 GB if /LARGEADDRESSAWARE is used

· A 32-bit process cannot load a 64-bit DLL (except for certain system DLLs) and vice-versa

· Running 16-bit processes is not supported

· DOS (Command.com)/ NTVDM is not available

· The Virtual DOS Machine (VDM) API is disabled

X64 Windows supports several application installers that use a 16-bit stub by recognizing specific 16-bit installer programs and replacing them with ported 32-bit versions. There is built-in support for several installer engines, including InstallShield 5.x installers. See Application Installation for further details.

Apart from these, there are some portability issues that 32-bit applications can run into. For example, a 32-bit driver cannot run on the 64-bit Windows kernel so it must be ported.

In short, if your application is not affected by the above-listed issues, it should work fine on a 64-bit platform.

References

To learn more or for further details, see the following documents/articles –

Running 32-bit Applications

http://msdn.microsoft.com/en-us/library/aa384249.aspx%20

64-bit System Design page

http://www.microsoft.com/whdc/system/platform/64bit/default.mspx

Porting Your Driver to 64-Bit Windows

http://msdn.microsoft.com/en-us/library/aa489557.aspx

Remote Desktop Connection 7 for Windows 7, Windows XP & Windows Vista

Introduction

Now that we have released Windows 7 & Windows Server 2008 R2 to manufacturing, we wanted to share our plans to make the Remote Desktop Connection (RDC) 7.0 client available to Windows XP and Windows Vista. RDC 7 will ensure that when connecting to Windows 7 and Windows Server 2008 R2 from an XP or Vista machines you are able to take advantage of the rich, advanced RDP7 features such as Media Player Redirection, True Multi-monitor support, etc

Note: If you use RDC 7.0 to connect to XP or Vista you do not get new Windows 7 features like Windows Media Player Redirection etc. There is no way to get these features when connecting to XP or Vista.

The new RDC 7.0 clients will be available in Q4 CY09 by using the Microsoft Download Center and WSUS and will be available for Windows Vista with Service Pack 1 (SP1), Windows Vista with Service Pack 2 (SP2), and Windows XP with Service Pack 3 (SP3) operating systems.

The following sections describe what the user experience will be when connecting to Windows 7 or Windows Server 2008 R2 from a variety of operating systems using RDP 7, RDP 6.1, or RDP 5.2.

Connectivity

This section describes the set of remote resources available to users from each operating system/client combination.

Access to Remote Desktop sessions

User can connect to full remote desktop sessions.

Access to RemoteApp programs

Users can connect to RemoteApp programs rather than a whole desktop. This allows RemoteApp programs to be displayed seamlessly on the user’s local desktop even though they run remotely.

Access to personal virtual desktops by using RD Connection Broker

Users can access to personal virtual desktops when using the new Remote Desktop Virtualization Host in Windows Server 2008 R2. Personal desktops are assigned to users on 1:1 basis and maintain state over time.

Access to virtual desktop pools by using RD Connection Broker

Users can access virtual desktop pools when using the new Remote Desktop Virtualization Host in Windows Server 2008 R2. Pooled desktops are shared between multiple users and all changes a user makes are typically rolled back when the user logs off.

Launch applications and desktops from 'RemoteApp and Desktop Connections'

Users can subscribe to all their RemoteApp programs and desktops which are then listed in their local Start menu. The list is automatically updated as items are added or deleted.

Launch application and desktops from RD Web Access

Users can launch RemoteApp programs and desktops from an ActiveX enable browser

Status & disconnect system tray icon

A single system tray icon enables users to see all their remote connections. The user can disconnect all or individual connections using this icon. The icon appears only when launching RDP connections which are associated with a RemoteApp and Desktop Connection feed.

Experience Features

This section describes the user experience when connecting to Windows Server 2008 R2 from each platform/client combination.

Windows Media Player Redirection

Windows Media Player Redirection enables content hosted in Windows Media Player to be redirected to the client for decoding on the users’ computers. This improves the quality of the video and ensures that video and audio are always in sync. This works for both full Windows Media Player and Windows Media Player controls hosted in Web pages.

Bidirectional Audio

You can redirect audio recording devices such as microphones on the client computer. This is ideal for applications like Windows 7 voice recognition and applications that record audio.

True Multimonitor Support

In Windows Vista & Windows Server 2008, Terminal Services supported only monitor spanning. Remote Desktop Services now includes true multi-monitor support for up to 16 monitors. and works for both Remote Desktop & RemoteApp programs. It is not compatible with Aero Glass support.

Aero Glass Support

Terminal Services in Windows Server 2008 did not support Aero Glass remoting for sessions. This is now supported in Windows Server 2008 R2 Remote Desktop Services (but is not compatible with multi monitor support).

Enhanced Bitmap Acceleration

Bitmap acceleration improves the remote display of graphics-intensive applications like PowerPoint, Flash, and Silverlight.

Language Bar Docking

RemoteApp allows users to use their docked Language Bar with their RemoteApp applications just like they do with the local ones.

This productive functionality was previously unavailable, and users had to resort to the floating Language bar. To use the RemoteApp docked Language bar users must use a Windows7 client connected to a Windows Server 2008 R2 server.

Easy Print

Easy Print allows users to print to their local printers from remote desktops and programs without needing to install print drivers on the host. Easy Print is now supported when connecting to Windows 7 client.

Security Features

This section describes the security features available when connecting to Windows Server 2008 R2 or Windows 7 from each platform/client combination.

Per-user filtering of RemoteApp programs

RemoteApp programs displayed in RD Web Access can be filtered so that a user will see only the applications to which he or she has access.

Web SSO & Web forms-based authentication

RD Web Access now uses forms-based authentication to improve the user experience. Web SSO ensures that once a user is logged on no additional passwords are required for RD Gateway, RD Session Host servers and RemoteApp programs.

RD Gateway-based control of device redirection

In Windows Server 2008, it was possible for non-Microsoft Remote Desktop clients to override the gateway device redirection controls. In Windows Server 2008 R2 device redirection settings defined in RD Gateway it cannot be overridden.

RD Gateway System and Logon messages

System and logon messages can be added to RD Gateway and displayed to the remote desktop user. System messages can be used to inform users of server maintenance issues such as shutdown and restarts. Logon messages can be used to display a logon notice to users before they gain access to remote resources

RD Gateway Background Authorization & Authentication

Background authentication and authorization requests are performed after a configured session timeout has been reached, sessions for users whose property information has not changed are not affected, and authentication and authorization requests are sent in the background.

RD Gateway Idle & Session Timeouts

Configurable idle and session timeouts with RD Gateway provide better control of users who are connecting through RD Gateway. An idle timeout provides the ability to reclaim resources used by inactive user sessions without affecting the user's session or data. This helps free up resources on the RD Gateway server.

NAP Remediation with RD Gateway

NAP remediation allows you to manage remote clients by updating them with the latest software updates and settings. This helps keep remote clients in compliance with network security policies.

More Information

For more information about the new features in Windows Server 2008 R2 Remote Desktop Services, see “What’s New in Remote Desktop Services,” available on Microsoft TechNet (http://go.microsoft.com/fwlink/?LinkId=131925).

Microsoft VDI - Overview

Overview

In previous versions of Windows Server, Terminal Services enabled a server to host multiple, simultaneous user sessions. In Windows Server 2008 R2, we have renamed Terminal Services to Remote Desktop Services because it offered a choice of presentation virtualization options: sessions for those for whom scalability was most important and virtual machines for those for whom isolation was most important. Since Microsoft Virtual Desktop Infrastructure is new, this blog post describes the function that Remote Desktop Services role services (and some supplemental technology) play in enabling MS VDI.

Scenarios

Personal virtual desktops are virtual machines that are permanently assigned to users by an administrator. This configuration is saved in Active Directory Domain Services. A personal virtual desktop is typically used when a user needs a dedicated virtual machine (VM) with administrative privileges (for example, a user might want to install applications).

A virtual desktop pool is a group of identically configured virtual machines that are temporarily assigned to users by the Microsoft VDI system. Administrators can configure a VM to be a part of a pool.

Role Services and Technology Included in a Microsoft VDI Deployment

The following role services and non-RDS technologies are included in a typical VDI deployment.

Remote Desktop Connection Broker (RD Connection Broker)

The main purpose of this role service is to broker a user connection to an appropriate endpoint. Brokering of the connection involves:

• Identifying the VM for the user to make a remote connection.
• Preparing the VM for remote connections by communicating with the Remote Desktop Virtualization Host server (for example, waking the VM from a saved state).
• Querying the IP address of the VM by communicating with the Remote Desktop Virtualization Host server. This IP address is returned to the Remote Desktop Session Host server running in redirection mode.
• Monitoring user sessions in a virtual desktop pool scenario. A user with an existing session in a pool is redirected to the hosting VM.

Remote Desktop Session Host (RD Session Host) server running in redirection mode

The purpose of the RD Session Host server running in redirection mode is to securely redirect an RDP client connection to a VM. The RD Session Host server running in redirection mode does not allow interactive user sessions, unless the user requests an administrative session by using the ‘/admin’ switch.

When a user requests a VM, the RD Session Host server running in redirection mode queries the RD Connection Broker server. The RD Connection Broker server in turn provisions a VM for the user and returns its IP address to the RD Session Host server running in redirection mode. The RD Session Host server running in redirection mode will then redirect the RDP client to connect to the VM by using the IP address.

It is recommended that the RD Connection Broker role service reside on the same machine as the RD Session Host server running in redirection mode (as shown in the diagram). However, the scenario where the RD Session Host server running in redirection mode and the RD Connection Broker role service are on separate machines is also supported.

Remote Desktop Virtualization Host (RD Virtualization Host)

RD Virtualization Host is a Remote Desktop Services role service included with Windows Server 2008 R2. RD Virtualization Host integrates with Hyper-V to provide virtual machines that can be used as personal virtual desktops or virtual desktop pools.

An RD Virtualization Host server has the following functions:

• Monitoring VM guest sessions and reporting these sessions to the RD Connection Broker server.
• Preparing the VM for a remote desktop connection when requested by the RD Connection Broker server.

In order for RD Virtualization Host to perform the above functions, the guest OS must be configured to give permission to RD Virtualization Host. Refer to the Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide for further details.

Remote Desktop Web Access (RD Web Access)

RD Web Access provides a user with an aggregated view of remote applications and desktop connections via a web browser. Using RD Web Access, a user can view all remote applications and virtual desktops (personal virtual desktops and virtual desktop pools) published to that user. VDI VMs are also accessible via the RADC feature (start menu) in Win7 clients.

Refer to the blog post for RD Web Access configuration in a Microsoft VDI deployment.

Remote Desktop Gateway (RD Gateway)

RD Gateway is an optional role service in a Microsoft VDI deployment. Its main purpose is to securely route RDP connections over the Internet through a firewall.

Application Virtualization (App-V)

App-V can simplify management of Virtual Machine images within a Microsoft VDI environment. Using App-V, you can dynamically load and assign applications on a user group basis, reduce application testing, reduce application to application conflicts, and increase application compatibility. 

For more information on the next version of App-V refer to Get your applications virtualized on Windows 7 Beta with Microsoft App-V.

System Center Virtual Machine Manager (SCVMM)

SCVMM's console is a one stop shop for VM Management. As part of Microsoft VDI solution it not only provides the Hyper-V UI functionality but enables fast and easy VM provisioning, which is helpful in large deployments.

Need More Details?

To learn more, refer to the Remote Desktop Services Getting Started guides.

Deploying RD Gateway R2 server with NAP

1. Background

Network Access Protection (NAP) is a policy-enforcement platform built into Windows. It is designed to inspect, assess, ensure compliance to policy, and remediate, where necessary, endpoints (such as laptops or other devices) attempting to access networked resources (such as applications, data, and information).

NAP is designed to protect client computers, networks, edge devices and hosts from malware by verifying the client’s health and making it compliant to corporate network policies. This set of technologies allows an IT administrator to keep the endpoints healthy at all times and enable access control based on health policies.

In Windows Server 2008 R2, RD Gateway (formerly referenced as TS Gateway) has significant improvements in its integration with NAP. Using this release, administrator can configure RD Gateway to remediate the client or provide information to users on compliance to enable them to make the right decisions. In all the RDG system can now evaluate the client health for logging, enforce peripheral redirect or access using NAP, and remediate clients on connection attempts.

2. RD Gateway and NAP remediation

RD Gateway enables access to corpnet applications and desktops from the Internet or intranet. Remote users have the flexibility to connect from corporate-owned, domain-joined, or private workgroup machines.

While RDG enables application access from unmanaged machines this also exposes corporate resources to added risk. For instance, a private workgroup machine infected with a virus can potentially infect the RD Server and other corporate resources as well. Using NAP RDG can solve the unmanaged machine access problem while improving security. This is done through RD client integration with NAP to collect any state information available to NAP and RD gateway integration with NAP which enables health enforcement. Together the systems support a variety of client health checks and enforcement modes, such as:

1. Deny connection and auto-remediate domain joined client desktops if the anti-virus and automatic updates are turned off.
2. Deny connection to private workgroup machine if anti-virus and automatic updates are turned off.
3. Allow connection with client device redirection turned OFF and in parallel auto-remediate the domain joined client machine with critical security updates. Turning off client devices like hard-drives, disks, PnP, clip-boards will reduce the risk to the terminal server.

3. Systems Capabilities Matrix

4. Recommendations

• Turn on auto-remediation for unhealthy domain-joined corporate machines. This is recommended to automatically remediate client machines before allowing access to corporate resources.
• Turn off client device redirection (refer section 5.a.4) for non-compliant and non-NAP capable clients. This ensures that users continue to remain productive, and, because device redirection is turned off, it provides some level of isolation for the client machine from the corporate network.
• Turn off auto-remediation for unhealthy private workgroup machines. This is recommended if you don’t want private machines to be automatically remediated without user consent. Users can attempt a manual remediation based on server health response.

5. RDC7.0 Client-side configuration

• RD Gateway NAP auto-remediation requires RDC 7.0 clients connecting to a Windows Server 2008 R2 server.
• Common settings required –
• The RDG certificate needs to be placed in COMPUTER TRUSTED store.
• You must add the RD Gateway server to the trusted gateway list. Please refer to this URL for more details: http://technet.microsoft.com/en-us/library/cc732172(WS.10).aspx#BKMK_ConfigureNAPClient_TSGateway

6. Configuring WS2008 R2 RD Gateway Server for specialized NAP scenarios

This section provides administrators with the steps to configure RD Gateway for various NAP scenarios.

a. Configure RD gateway to turn off device redirection from unhealthy clients

1. Configure network access protection (NAP). For information on creating NAP, refer to the section "Steps to configure the NAP policies"
2. Click Start > Administrative tools > Remote Desktop Services > Remote Desktop Gateway Manager to open the RD Gateway manager snap-in.
3. Click Policies and then click Connection Authorization Policies. Choose the NAP policy corresponding to non-compliance, and then select the Device Redirection tab.
   
4. On the Device Redirection tab, disable the client devices.
   

b. Configure RD gateway to deny access to unhealthy clients

1. Configure Network access policies (NAP). For information on creating NAP, refer the section "Steps to configure the NAP policies"
2. On the Network policy server snap-in, open Network Policies. Choose the NAP policy corresponding to RD Gateway non-compliance, select Settings
3. On the NAP RD Gateway Noncompliant properties page, select NAP Enforcement and enable Allow Limited Access.
   

c. Configure WS2008 R2 RD gateway to auto-remediate unhealthy clients

1. Configure network access policies (NAP). For information on creating NAP, refer to the section "Steps to configure the NAP policies".
2. On the Network policy server snap-in, open Network Policies. Choose the NAP policy corresponding to RD Gateway non-compliance, and then select Settings.
    
3. On the NAP RD Gateway Noncompliant properties page, select NAP Enforcement. Select “Enable auto remediation of client computers.”
   *Note that the RD gateway auto-remediation scenario only works when the remediation servers are directly accessible from the internet.
   

7. RDC 7.0 Client experiences

The following screenshots provide the user experience for an unhealthy client machine. In this case, the RDG is configured to deny access and auto-remediate the client.

1. Users is denied connection and informed with a balloon of the status.
    
2. The user clicks the NAP tray and is notified of the status. Due to certain limitations, the status does not change until the user closes the MSTSC process completely.
   
3. The user closes the MSTSC process and is immediately informed with a balloon of the green status.
    
4. The user attempts to connect again and succeeds.

8. Configuring WS2008 R2 NAP policies

a. Steps to configure the NAP policies

1. Administrator configures RD Gateway CAP with NAP SoH using Network Policy Server manager snap-in. Click Start, click Administrative tools, and then click Network Policy Server.
2. Click Configure NAP.
    
3. On the Select Network Connection Method for Use with NAP page, choose Remote Desktop Gateway (RD Gateway) as the network connection method and specify a name in the Policy name section. Click Next.
4. On the Specify NAP Enforcement Servers Running RD Gateway page, add RD Gateway servers running remotely and using the central NPS. In cases where the NPS and RD Gateway roles are co-located on the same server, you can skip this screen. Click Next.
5. On the Configure Client Device Redirection and Authentication Methods page, configure the device redirection and authentication method policies. Click Next.
6. On the Configure the Idle Timeout and Session Timeout Actions page, configure the Enable idle Timeout and Enable session timeout policy. Click Next.
7. On the Configure User Groups and Machine Groups page, configure Machine groups and User Groups that are allowed access. Click Next.
8. On the Define NAP Health Policy page, select Windows System Health Validator. On the Network access restrictions for NAP-ineligible client computers, choose the network action policy.
   *To configure the Windows System Health Validator, refer to the section "Steps to configure System heath Validator".
9. Click Finish

b. Steps to configure WS2008 R2 System Health Validator

1. User configures a System Health Validator on the Network Policy Server manager snap-in. Click Start > Administrative tools > Network Policy Server.
2. Click Network Access Protection à System Health Validators à Windows Security Health Validator. à Settings.
    
3. Click Default Configuration, Choose the policy settings for Windows System Health Validators.

9. References

RD Gateway NAP step-by-step WS08 (includes client configuration for NAP):

http://technet.microsoft.com/en-us/library/cc732172(WS.10).aspx

New Version of RDS Application Analyzer

Several changes have been made to the RDS Application Analyzer to fix various issues reported by users over the last few months. The latest version of the tool can be downloaded from: http://connect.microsoft.com/tsappcompat

Fixed compatibility with App Verifier

Firstly, RDS Application Analyzer has some compatibility issues with App Verifier 4.0. This has been resolved by using App Verifier 3.4 as a default.

If you have App Verifier installed, you will be directed to download and install App Verifier 3.4 by the RDS Compatibility Analyzer. However, if you already had App Verifier 4.0, then you will get a warning about the compatibility issues as usual. This behavior hasn’t been changed.

If you already have App Verifier 4.0 and want to use the RDS Application Analyzer, you need to uninstall App Verifier 4.0. After that, running the RDS Compatibility Analyzer will automatically start the download for App Verifier 3.4.

Fixed problems in XP environment

This issue is also fixed. Now you should be able to use the RDS Application Analyzer on Microsoft Windows XP and Windows 2003 as well.