Remote Desktop Services (Terminal Services) Team Blog

Windows Server 2008 R2 Haiku Contest

The Windows Server team is running a Haiku contest for Windows Server 2008 R2.  Come up with the best Haiku, and you could win a Home Entertainment System.  See http://www.r2haiku.com/ to enter.

Maybe Remote Desktop Services will provide your inspiration!

Personal Virtual Desktops

With Windows Server 2008 R2 we support two VDI deployment scenarios: virtual desktop pools and personal virtual desktops. The two scenarios present two different models of assigning virtual machines to end users: shared and dedicated. This blog post describes personal virtual desktops.

What is a personal virtual desktop? - A personal virtual desktop is a virtual machine hosted on a Remote Desktop Virtualization Host (RD Virtualization Host) server and assigned to a user. Unlike a virtual desktop pool, where a virtual machine can be configured to rollback the changes when a user logs off, a personal virtual desktop retains all changes made by the user.

How do you assign a personal virtual desktop? - The Remote Desktop Connection Broker Manager (RD Connection Broker Manager) can be used to assign an unassigned virtual machine to a user. The assignment is stored in Active Directory. The assignment stays intact even after the user logs off from his or her assigned personal virtual desktop. An administrator can reassign a personal virtual desktop or make changes to the assignment through RD Connection Broker Manager.

How do you access and log off from a personal virtual desktop? - Users can access their assigned personal virtual desktops through RemoteApp and Desktop Connections or RD Web Access. When a user clicks on the personal virtual desktop icon, Microsoft VDI solution prepares a pre-assigned virtual machine for a remote RDP connection. Whether the user has logged off or has a disconnected session he is assigned the same virtual machine each time.

Can a personal virtual desktop be made part of a virtual desktop pool? – No. It is a misconfiguration to add a virtual machine designated as a personal virtual desktop to a virtual desktop pool if the goal is to allow only the assigned user to access that virtual machine. When the designated user makes a connection to his personal virtual desktop which is now part of a virtual desktop pool, the connection will fail and a type mismatch event will be logged.

What is the cost of ownership of personal virtual desktops compared to virtual desktop pools? - Since there is a one-to-one mapping between a virtual machine and a user in the personal virtual desktop scenario, the initial cost and overall cost of ownership of a personal virtual desktop is higher than in the virtual desktop pool scenario in which virtual machines are shared between users.

How many personal virtual desktops can be assigned per user? – One. ISVs can extend the inbox solution and provide users access to more than one personal virtual desktop. Refer to: http://msdn.microsoft.com/en-us/library/dd401684(VS.85).aspx

Can the same Hyper-V server be used to deploy personal virtual desktops and virtual machines from virtual desktop pools? – Yes. It is not required to have personal virtual desktops isolated from virtual desktop pools.

For details on how to set up personal virtual desktops, refer to:

RemoteApp and Desktop Connection Management Extensibility for provisioning apps via RD Web Access

Earlier, we described publishing in Windows Server 2008 R2 and how RDP resources can be published by using the RemoteApp and Desktop Connection Management service to users in RD Web Access. This blog post describes the third-party extensibility support available in the RemoteApp and Desktop Connection Management service, and how third parties (Enterprises or ISVs) can leverage it to publish any resources (RDP or non-RDP) in Windows Server 2008 R2.

The RemoteApp and Desktop Connection Management service, which is part of the RD Connection Broker role service, is a new publishing feature in Windows Server 2008 R2. By default, the following three plug-ins are provided in the service:

• LegacyTS plug-in: Aggregates RemoteApp programs from Remote Desktop Session Host servers.
• VMFarm plug-in: Aggregates virtual desktop pools.
• MyDesktop plug-in: Provides the user with the assigned personal domain desktop.

All three plug-ins provide only RDP files, in the following scenarios:

• RDP files for RemoteApp programs
• RDP files for virtual desktops in virtual desktop pools
• RDP files for per-user assigned virtual desktops

In order to provide RDP or non-RDP files in any scenario other than the ones described above, you can write a plug-in to provide the list of resources, register it with the RemoteApp and Desktop Connection Management service, and display the resources in RD Web Access. For example, if you want to serve several different files (for example, some hand-crafted RDP files and some .osd (app-v) files that are on a physical drive on the machine running the RemoteApp and Desktop Connection Management service), you can write a simple plug-in that will aggregate the files from the location and pass them on to the service, which will then pass them on to RD Web Access. As a result, users will be able to access these files via the web page.

Writing a third-party plug-in

Create a DLL that implements the ItsPubPlugin COM interface as described here: http://msdn.microsoft.com/en-us/library/dd401684(VS.85).aspx

• HRESULT  mySamplePlugin::GetResourceList(LPCWSTR userID, __out LONG *pceAppListSize, __deref_out_ecount(*pceAppListSize)pluginResource ** resourceList)
  
      typedef struct {
          WCHAR alias[256];
          WCHAR name[256];
          [string, unique] WCHAR *resourceFileContents;
          WCHAR fileExtension[24];
          WCHAR resourcePluginType[256];
          boolean isDiscoverable;
          long resourceType;
          unsigned long pceIconSize;
          [size_is(pceIconSize)] byte *iconContents;
          unsigned long pcePluginBlobSize;
          [size_is(pcePluginBlobSize)] byte *blobContents;
      } pluginResource;

This interface is the one that the RemoteApp and Desktop Connection Management service will call into, when a user request comes in, to get the list of resources.

• STDMETHODIMP mySamplePlugin::GetResource(LPCWSTR alias, LONG flags, __out pluginResource * resource)

This interface is a placeholder and does not need to be implemented. You can simply return E_NOTIMPL.

• STDMETHODIMP mySamplePlugin::GetCacheLastUpdateTime(__out unsigned long long * lastUpdateTime)

This interface is called by the RemoteApp and Desktop Connection Management service to get the last cache updated time. If you don’t plan to implement caching, returning the current system time in Windows File Time format for the lastUpdateTime will indicate to the service that it needs to call the GetResourceList function (discussed above) to get the latest list of resources, instead of using its cache. However, this is not the recommended way of implementing the plug-in because this will cause RD Web Access to not use its cache, which will cause more data to be transferred across the network and slow user response time. The recommended way to implement this routine is to return the latest time that a resource has changed.

• STDMETHODIMP mySamplePlugin::get_pluginName(__deref_out BSTR * pVal)

This interface is used to get the plug-in name.

• STDMETHODIMP mySamplePlugin::get_pluginVersion(__deref_out BSTR * pVal)

This interface is used to get the plug-in version.

• STDMETHODIMP mySamplePlugin::ResolveResource(     __RPC__out DWORD *resourceType,
      __RPC__out_ecount_full_string(256) wchar_t resourceLocation[ 256 ],
      __RPC__out_ecount_full_string(256) wchar_t endPointName[ 256 ],
      __RPC__in_string wchar_t *userID,    __RPC__in_string wchar_t *alias)

This interface is used by the Remote Desktop Connection Broker service to resolve which virtual desktop is assigned to the user. It is not essential to have this implemented, and you can simply return E_NOTIMPL, unless you plan to have a custom implementation for providing the Personal Domain Desktop functionality.

Registering the third-party plugin:

After you have written the plug-in, complete the following steps:

1. Register the plug-in.
   regsvr32 mySamplePlugin.dll
2. Create the following registry entries:
   1. Create a sub-key under HKLM\software\Microsoft\Windows NT\CurrentVersion\TerminalServer\Centralized Publishing\ with the CLSID of the mySamplePlugin
   2. Create a DWORD under HKLM\software\Microsoft\Windows NT\CurrentVersion\TerminalServer\Centralized Publishing\{mySamplePlugin-CLSID} called IsEnabled and set it to 1. (Setting it to 0 is equivalent to disabling the plugin)
3. The publishing service will pick up the registry changes automatically and restart the publishing service, or you can restart the publishing service manually by using the following command:
   net stop tscpubrpc & net start tscpubrpc

After completing these steps, you are finished creating the third-party plug-in. When a client connects, in addition to the enabled default plug-ins, the publishing service will also aggregate the applications provided by your own plug-in and display them in RD Web Access. Note that this will work only for the RD Web Access scenario. In order to make extensibility work in the RemoteApp and Desktop Connections scenario so that you can download the published applications onto your Start menu, you must complete some additional steps, which will be covered in the next post.

Per User CAL Reporting Script

We have introduced a script to help the administrators tracking the usage trend of Windows Server 2003 Terminal Server (TS) Per User (PU) client access licenses (CALs), total usage of Windows Server 2008 TS PU CALs (including expired), and the usage of Windows Server 2008 TS PU CALs for a list of specified domains.

The major scenarios addressed by the script includes the following -

1. For a Windows Server 2003 TS, this script helps the administrators tracking the users logged in to a TS in PU licensing mode over a period of time.
2. For a Windows Server 2008 TS or a Windows Server 2008 R2 Remote Desktop Session Host Server (RDSH), this script helps the administrator tracking both valid & expired PU CALs.
3. For a license server running Windows Server 2008 or Windows Server 2008 R2, this script enables administrators to generate PU CAL usage details for a list of specified domains.
4. For a license server running Windows Server 2008 or Windows Server 2008 R2, while generating the PU CAL usage report for a list of specified domains, even if one or more of the domains in the list is unreachable, this script will still report the usage for all the reachable domains.

For more detailed information, download the Per User Report Generation script from here. The batch script to execute the Per User Report Generation script periodically for a Windows Server 2003 TS is available at here.

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.

Update 2: The Multilingual User Interface (MUI) package for XP SP3 is now available for download. Please follow the KB article 969085 for package description and download information.

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