Remote Desktop Services (Terminal Services) Team Blog

RemoteApp and Desktop Connection Feed Extensibility

termserv — Thu, 17 Dec 2009 23:30:40 GMT

In our earlier blog post, we introduced RemoteApp and Desktop Connections to enable users to have their RemoteApp and Desktop icons integrated on their Windows 7 start menu. RemoteApp and Desktop Connections works with this new feature of Remote Desktop Web Access (RD Web Access)--the RemoteApp and Desktop Connection feed. This RemoteApp and Desktop Connection feed provides significant extensibility to partners and customers in presenting remote resources in various ways. The connection feed feature contains information about published remote resources (e.g. RDP files and their associated icon and image files) in a software-parsable XML format.

On Remote Desktop Web Access (RD Web Access) Server, there are two URLs available to serve the connection feed. You need to choose one depending on the extensibility scenario.

“/rdweb/pages/webfeed.aspx” URL:
This URL is used for RD Web Access website extensibility. You can create a new web page similar to the RD Web Access default webpage. Below are some of the features that are possible by using this URL

Branding or customizations for your customers or organization.
Visually sorting or segregating remote resource types (e.g. RemoteApp and Remote Desktop resources).
Filtering remote resources at display time (for example, additional filtering apart from RemoteApp filtering ).
Silverlight-based webpage for a rich user experience.

By using this connection feed URL

There is no need to write a custom authentication mechanism because the webpage runs within the RD Web Access web application.

It is easier to support Single Sign On for launching remote resources. In a future post, we will cover on how to enable SSO.

“/rdweb/feed/webfeed.aspx” URL:
This URL can also be used to provide extensibility and is more flexible than the above URL. In addition to above feature set, below are some of the other features that are possible by using this URL:

Creating new client applications similar to RemoteApp and Desktop Connections for downlevel windows clients and for thin clients.
Creating new web portal similar to RD Web Access, not just a webpage alone.
Integrating remote resource presentation with your existing web portal.

By using this connection feed URL

Client applications get an authentication cookie that will not expire. This can be used for easier automatic updates without re-prompting user for credentials.

Here is a sample connection XML containing information about remote resources:

<?xml version="1.0" encoding="utf-8"?>

<ResourceCollection PubDate="2009-07-09T17:57:30.323Z" SchemaVersion="1.1" xmlns="http://schemas.microsoft.com/ts/2007/05/tswf">
  <Publisher LastUpdated="2009-07-09T17:57:12.588625Z" Name="Remote Desktop Services Default Connection" ID="Contoso" Description="">
    <Resources>
      <Resource ID="60fb077b94a241a473cf982140337213e4d93177" Alias="mspaint" Title="Paint" LastUpdated="2009-07-09T17:57:12.588625Z" Type="RemoteApp" ExecutableName="mspaint.exe">
        <Icons>
          <IconRaw FileType="Ico" FileURL="/RDWeb/Pages/rdp/mspaint032x32.ico" />
          <Icon32 Dimensions="32x32" FileType="Png" FileURL="/RDWeb/Pages/rdp/mspaint032x32.png" />
        </Icons>
        <FileExtensions />
        <HostingTerminalServers>
          <HostingTerminalServer>
            <ResourceFile FileExtension=".rdp" URL="/RDWeb/Pages/rdp/Contoso-mspaint.rdp" />
            <TerminalServerRef Ref="Contoso" />
          </HostingTerminalServer>
        </HostingTerminalServers>
      </Resource>
    </Resources>
    <TerminalServers>
      <TerminalServer ID="Contoso" Name="Contoso" LastUpdated="2009-07-09T17:57:12.588625Z" />
    </TerminalServers>
  </Publisher>
</ResourceCollection>

The bolded attributes in the connection provide information about the remote resources. The schema file for the connection is located at %windir%\schemas\tsworkspace\tswf.xsd in Windows Server 2008 R2 or on a Window 7 client machine.

Website extensibility: Using the connection to create a new web page

Following is a code sample in C# (ASP.NET) on how to use the connection to create a new web page as demonstrated at PDC 2008. This code sample uses a connection at the “/rdweb/pages/webfeed.aspx” location. Below are the steps that need to complete in creating the new web page.

In Page PreInit, check for user authentication. If the user is not authenticated, redirect the request to the login page.
In Page Load, get the connection by calling Server.Execute on the webfeed.aspx page.
Parse the connection XML to get information on the remote resources. Use this information to present remote resources in your customized way.
Replace the default.aspx at %windir%\Web\RDWeb\Pages\en-US folder with this newly created page. This webpage will run inside the RD Web Access web application using an out-of-the box authentication mechanism.

Notes on this sample code:

It does not show how to enable RemoteApp and Desktop Connection’s Single Sign On feature.
It does not show how to differentiate the page content between the admin and a regular user.
It assumes that application locale is en-US.

<%@ Page Language="C#" Debug="false" Trace="false" %>

<% @Import Namespace="System.IO" %>
<% @Import Namespace="System.Collections.Generic" %>
<% @Import Namespace="System.Web.Configuration" %>
<% @Import Namespace="System.Xml" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script language="C#" runat="server">

    protected void Page_PreInit(object sender, EventArgs e)
    {
        AuthenticationMode eAuthenticationMode = AuthenticationMode.None;
        AuthenticationSection objAuthenticationSection = ConfigurationManager.GetSection("system.web/authentication") as AuthenticationSection;

        if (objAuthenticationSection != null)
        {
            eAuthenticationMode = objAuthenticationSection.Mode;
        }

        if (eAuthenticationMode == AuthenticationMode.Forms)
        {
            if (HttpContext.Current.User.Identity.IsAuthenticated == false)
            {
                // User is not logged in, so redirect the request to login page.
                Response.Redirect("login.aspx?ReturnUrl=" + Request.FilePath);
            }
        }
    }

    protected void Page_Load(object sender, EventArgs e)
    {
        try
        {
            string connectionXml;

            // Execute the handler for webfeed.aspx in the context of current request 
            // and capture output connectionXml.
            using (StringWriter stringWriter = new StringWriter())
            {
                // This new web page is running under the same web application, and 
                // with using existing authentication.
                // So We need run the Server.Execute to get the connection Xml.
                HttpContext.Current.Server.Execute("..//webfeed.aspx", stringWriter);
                connectionXml = stringWriter.ToString();
            }

            // Set current reponse content type
            Response.ContentType = "text/HTML";

            //Strip out the BOM (U+FEFF)
            connectionXml = connectionXml.Trim();

            // Sample code to parse the connection xml. Instead of parsing the connection xml, we can also use XSL transformations directly to display the remote resources
            List<ConnectionResourceInfo> listConnectionResourceInfos = GetConnectionResourceInfo(connectionXml);

            dataListResources.DataSource = listConnectionResourceInfos;
            dataListResources.DataBind();

            labelStatus.Text = "Connection Resources : " + listConnectionResourceInfos.Count;
        }
        catch (Exception ex)
        {
            labelStatus.Text = "Error occurred ~ " + ex.Message;
        }
    }

    private String GetAbsolutePath(string relativePath)
    {
        return String.Format("{0}://{1}{2}", Request.Url.Scheme, Request.Url.Host, relativePath);
    }

    // Parse the XML file for demo purpose. In this function we are not using all 
    // the xml information available, just the title and resource's image file path.
    private List<ConnectionResourceInfo> GetConnectionResourceInfo(string connectionXml)
    {
        List<ConnectionResourceInfo> listConnectionResourceInfos = new List<ConnectionResourceInfo>();
        XmlDocument xmlDocument = new XmlDocument();

        // Load the connection xml string
        xmlDocument.LoadXml(connectionXml);

        XmlNamespaceManager xmlNamespaceManager = new XmlNamespaceManager(xmlDocument.NameTable);
        xmlNamespaceManager.AddNamespace("tswf", "http://schemas.microsoft.com/ts/2007/05/tswf");

        // Get the list of Resource elements
        XmlNodeList xmlNodeList = xmlDocument.SelectNodes("/tswf:ResourceCollection/tswf:Publisher/tswf:Resources/tswf:Resource", xmlNamespaceManager);

        // For each resource get the title and image file relative path
        for (int i = 0; i < xmlNodeList.Count; i++)
        {
            ConnectionResourceInfo connectionResourceInfo = new ConnectionResourceInfo();

            connectionResourceInfo.Title = xmlNodeList[i].Attributes["Title"].Value;

            XmlNode xmlNodeIcon32 = xmlNodeList[i].SelectSingleNode("tswf:Icons/tswf:Icon32", xmlNamespaceManager);

            // Convert the image's relative path to ablosute path
            connectionResourceInfo.ImageFilePath = GetAbsolutePath(xmlNodeIcon32.Attributes["FileURL"].Value);

            listConnectionResourceInfos.Add(connectionResourceInfo);

            // Here you would want to retrieve any other XML information you
            // want for each resource from the connection
        }

        return listConnectionResourceInfos;
    }

    protected void SignOut_Click(object sender, EventArgs e)
    {
        //Redirect the request to logoff page
        Response.Redirect("LogOff.aspx");
    }

    // Entity class to hold connection resource info, for now it contains only the resource title, and its image path
    private class ConnectionResourceInfo
    {
        private string title;
        private string imageFilePath;

        public string Title
        {
            get { return title; }
            set { title = value; }
        }

        public string ImageFilePath
        {
            get { return imageFilePath; }
            set { imageFilePath = value; }
        }
    }

</script>

<html>
<head id="Head1" runat="server">
    <meta http-equiv="CONTENT-TYPE" content="TEXT/HTML; CHARSET=UTF-8">
    <meta http-equiv="CACHE-CONTROL" content="NO-CACHE">
    <meta http-equiv="PRAGMA" content="NO-CACHE" />
    <title>New RD Web Access</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:Button ID="btnSignOut" runat="server" Text="SignOut" OnClick="SignOut_Click" />
        <br />
        <asp:Label ID="labelStatus" runat="server" Text=""></asp:Label>
        <br />
        <asp:DataList ID="dataListResources" runat="server" RepeatDirection="Horizontal"
            RepeatColumns="4" BorderColor="black" CellPadding="1" BorderWidth="1" ItemStyle-BorderWidth="1">
            <ItemTemplate>
                <asp:Image ID="ResImage" ImageUrl='<%# DataBinder.Eval(Container.DataItem, "ImageFilePath") %>'
                    runat="server" /><br />
                <%# DataBinder.Eval(Container.DataItem, "Title") %>
            </ItemTemplate>
        </asp:DataList>
    </div>
    </form>
</body>
</html>

The sample page will appear as below.

Customized client applications: Using the connection to create a new client application

Following is a code sample in C# on how to use the connection to create a client application. This code sample uses the connection at the “/rdweb/feed/webfeed.aspx” location.

Send request to the connection URL page with auto-redirect enabled along with user credentials. The connection URL uses cookie-based authentication, so this initial request sent to the connection URL will be redirected to the login page. The login page, which uses Windows-based authentication, responds with the authentication cookie. The supplied user credentials in the request will be used in RemoteApp filtering.
Cache the authentication cookie for all subsequent requests. The cookie will not expire, so you can also reuse the same cookie for easy automatic connection updating without prompting the user for credentials.
Send the request to the connection URL with the authentication cookie, and get the connection XML in response.
Parse the connection XML, and download subsequent resource files and their associated icon and image files.

using System.IO; 
using System.Net;
using System.Web.Security;

private void GetConnectionContents()
{
    System.Diagnostics.ConsoleTraceListener trace = new System.Diagnostics.ConsoleTraceListener();

    //RemoteApp and Desktop Connections uses HTTPS to connect to the server. 
    //In order to connect properly, the client operating system must trust the SSL certificate of the RD Web Access server. 
    //Also, the server name in the URL must match the one in the server’s SSL certificate

    // User credentials to access the connection. Fill in <username>, <password>, <domainname> with your user credentials.
    NetworkCredential networkCredential = new NetworkCredential("<username>", "<password>", "<domainname>");            

    //This URL will generally be of this form.  Fill in <servername> with your server’s name
    string connectionUrl = "https://<servername>/rdweb/feed/webfeed.aspx";            

    string formsAuthenticationCookie = GetFormsAuthenticationCookie(connectionUrl, networkCredential, trace);

    string connectionXml = GetConnectionXml(connectionUrl, formsAuthenticationCookie, trace);

    //Fill in your code to parse the connection, and to download resource files and associated icon & image files. Use earlier cache cookie for authentication. 
}

private string GetFormsAuthenticationCookie(string connectionUrl, NetworkCredential networkCredential, System.Diagnostics.ConsoleTraceListener trace)
{
    //
    // Request connection page is protected by Forms Authentication Cookie. So making a request to that page will be redirected to login page
    // The login page is
    //
    trace.Write("Requesting : " + connectionUrl);
    HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(connectionUrl);
    CredentialCache credentialCache = new CredentialCache();
    credentialCache.Add(new Uri(connectionUrl), "Negotiate", networkCredential);
    httpWebRequest.Credentials = credentialCache;
    httpWebRequest.AllowAutoRedirect = true;

    HttpWebResponse httpWebResponse = (HttpWebResponse)httpWebRequest.GetResponse();

    if (httpWebResponse.StatusCode == HttpStatusCode.OK)
    {
        trace.Write("Response: 200 ");
        trace.WriteLine(httpWebResponse.StatusCode);
    }
    else
    {
        trace.Fail("Response status is " + httpWebResponse.StatusCode + ". Expected was OK");
    }

    trace.WriteLine("Response will be the Forms Authentication Cookie");
    trace.WriteLine("");

    string formsAuthenticationCookie;

    using (StreamReader streamReader = new StreamReader(httpWebResponse.GetResponseStream()))
    {
        formsAuthenticationCookie = streamReader.ReadToEnd();
        streamReader.Close();
    }

    trace.WriteLine("formsAuthenticationCookie " + formsAuthenticationCookie);

    return formsAuthenticationCookie;
}

private string GetConnectionXml(string connectionUrl, string formsAuthenticationCookie, System.Diagnostics.ConsoleTraceListener trace)
{
    //
    // Request connection page
    //
    trace.Write("Requesting : " + connectionUrl);
    HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(connectionUrl);

    httpWebRequest.CookieContainer = new CookieContainer();

    //
    // Set Froms Authentication Cookie
    //
    httpWebRequest.CookieContainer.Add(new Cookie(FormsAuthentication.FormsCookieName, formsAuthenticationCookie, "/", httpWebRequest.RequestUri.Host));

    // Get response
    HttpWebResponse httpWebResponse = (HttpWebResponse)httpWebRequest.GetResponse();

    if (httpWebResponse.StatusCode == HttpStatusCode.OK)
    {
        trace.Write("Response: 200 ");
        trace.WriteLine(httpWebResponse.StatusCode);
    }
    else
    {
        trace.Fail("Response status is " + httpWebResponse.StatusCode + ". Expected was OK");
    }

    trace.WriteLine("Response will be the connectionXml");
    trace.WriteLine("");

    string connectionXml;

    using (StreamReader streamReader = new StreamReader(httpWebResponse.GetResponseStream()))
    {
        connectionXml = streamReader.ReadToEnd();
    }

    trace.WriteLine("connectionXml " + connectionXml);

    return connectionXml;
}

As shown above, RemoteApp and Desktop Connection provides an easy way to customize the standard look and feel of RD Web Access or to present remote resources in new ways.

RemoteApp for Hyper-V

termserv — Wed, 16 Dec 2009 00:37:00 GMT

Today, we want to talk about a little known feature in Windows Server 2008 R2 that could be described as RemoteApp for Hyper-V. Like Microsoft RemoteApp, it allows users to access a specific hosted application remotely, as opposed to the entire desktop. With RemoteApp, the application runs in the context of a server session; however, RemoteApp for Hyper-V enables remote access to an application running in a Hyper-V VM.

With the advent of Windows 7, some enterprise customers were facing application compatibility issues with line-of-business applications that were specifically written for Windows XP and would not work on Windows 7.

One obvious way to resolve this issue is to run those incompatible applications in Windows XP Mode, a new feature that is available in certain Windows 7 SKUs and which simplifies migration to the new OS by allowing legacy XP applications to seamlessly run in their own context within a Windows 7 environment. Windows XP mode has specific hardware, OS and memory requirements. While this solution works well on newer machines with hardware virtualization support, the hardware requirements for XP mode might be prohibitive for some older PCs.

RemoteApp for Hyper-V allows users to remotely access Windows XP applications from their Windows 7 desktop with no additional hardware requirements.

SKU support: RemoteApp for Hyper-V is supported on the following SKUs running as the guest OS:
- Windows XP SP3: Professional
- Windows Vista SP1 and above: Enterprise and Ultimate
- Windows 7: Enterprise and Ultimate

Here are some examples of applications that will benefit from this feature:

Applications that are compatible only with Windows XP SP3
Applications that can run on Windows Server 2003, but not Windows Server 2008 or Windows Server 2008 R2
Applications that are supposed to be run only on a data center server for data security or compliance reasons

To use this feature, a user connects remotely from a client computer to the VM-hosted application. To host the applications, an administrator sets up a virtual machine with a guest OS on a Hyper-V server hosting the virtual machine.

The client computer must run Windows 7, but the guest OS on the virtual machine can run Windows XP SP3, Windows Vista (with SP1 and above) or Windows 7. For a guest OS running Windows XP SP3, an update is required; for a guest OS running Windows Vista SP1 or above, another update is needed.

So, how can an administrator deploy this?

There are two ways in which RemoteApp for Hyper-V can be deployed. The first way is the stand-alone scenario, in which all the administrator needs to do is set up a Hyper-V server with virtual machines running a client OS (for example, Windows XP SP3). The administrator would then set up the application and create RDP files that launch this application. A user can connect to the application via a simple Remote Desktop connection using the RDP file.

Here’s how this setup would look:

While this is a simple setup that an administrator can use to pilot the RemoteApp for Hyper-V, it offers no extra efficiency or ability to load balance. One serious drawback of this method is that since only one user can connect to an application at a time, one user connecting to multiple virtual machines effectively blocks out other users.

To get around this problem, the recommended way to install RemoteApp for Hyper-V is over a complete VDI farm or personal virtual desktop setup, including setting up the RD Connection Broker role. An administrator would still need to perform the same manual steps of setting up the application and creating an RDP file, but there are significant advantages to going through the RD Connection Broker. An obvious one is load balancing. In addition, there is increased efficiency, simply because when a user is connected to a virtual machine, all applications launched by that user are redirected to the same virtual machine. Only one user can connect to applications running on a particular virtual machine at a time.

One single user cannot block out an entire farm by holding onto different virtual machines on it at the same time. Until a user’s virtual machine is terminated, redirection is always to the same VM. RD Connection Broker ensures that a user connected to a VM stays connected until logged out.

Here’s how the second setup scenario described above would look (running from a Windows XP SP3 farm, for instance):

Hosting applications in a farm of virtual machines running Windows XP SP3 is a simple way to give multiple people on the domain access to the applications. There is no security filtering for applications on a virtual machine farm. All domain users who have access to the farm will have access to the applications.

If an administrator wants to give only a specific user access to an application, the application should be hosted on a personal desktop. In all cases--farms or personal desktops--an administrator only needs to create an RDP file and hand it over to a user, either via a network share or email.

RemoteApp for Hyper-V is a basic but powerful platform capability which was designed with advanced administrators in mind who are willing to do the manual configuration steps to enable an environment that includes remote access to VM-hosted applications. It serves also as an extensibility point for our RDS partner ecosystem who may want to take advantage of this infrastructure capability and provide additional value-add to RDS customers by streamlining the configuration and expanding the usability and manageability of it. For example, with additional code, it is possible to integrate the RDP files with Remote Desktop Web Access.

Deploying Windows Vista or Windows XP as the guest operating system in a Virtual Machine

termserv — Tue, 01 Dec 2009 22:32:45 GMT

Overview

The purpose of this post is to help an Administrator configure a Windows Vista or Windows XP operating system in a virtual machine for a Remote Desktop Services Virtual Desktop Infrastructure (VDI) deployment.

This post is an addendum to the Step 2: Installing and Configuring the Virtual Machine section for the following Step-by-Step guides published in Microsoft ®TechNet:

Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide.
Deploying Virtual Desktop Pools by Using RemoteApp and Desktop Connection Step-by-Step Guide.
Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide.
Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide.

Additional Steps required to support Windows Vista and Windows XP

The following steps need to be completed before the Configure the virtual machine for Remote Desktop Services section in the guides mentioned above.

Choose supported operation system: Install the supported version of the Windows Vista or Windows XP as the guest operating system. The following link contains the reference to the list of various supported versions of Windows Vista or Windows XP.
Install Integration Services component: Follow the instructions here at Step 4: To install the integration services on the virtual machine.
Only for Windows XP: Install PowerShell package: Follow the instructions here to install this package. This step is not needed if you are using VBS script for configuring the guest operating systems.

The following steps need to be completed before moving on the Step 3 in the guides mentioned above.
Only for Windows XP: Restart the Windows XP machine.

Additional Resources

Configure Guest OS for Microsoft VDI using Powershell: http://gallery.technet.microsoft.com/ScriptCenter/en-us/bd2e02d0-efe7-4f89-84e5-7ad70f9a7bf0
Configure Guest OS for Microsoft VDI using VB Script: http://gallery.technet.microsoft.com/ScriptCenter/en-us/68462b23-0890-4dbd-95b6-8de5763e4f68)
Note: If you choose to use the VB Script to automate configuring the settings, then you can skip Step# 3 in the section above.

Windows Server 2008 R2 Haiku Contest

termserv — Thu, 19 Nov 2009 21:59:09 GMT

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

termserv — Tue, 17 Nov 2009 04:17:51 GMT

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:

Technical Library	Microsoft Download Center
Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=147909)	Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=147908)
Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=154801)	Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=154800)

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

termserv — Thu, 12 Nov 2009 01:35:00 GMT

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:

Register the plug-in.
regsvr32 mySamplePlugin.dll
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)
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

termserv — Mon, 09 Nov 2009 23:03:28 GMT

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 -

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.
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.
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.
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

termserv — Wed, 04 Nov 2009 18:36:27 GMT

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

termserv — Tue, 03 Nov 2009 03:02:20 GMT

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:

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
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
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
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
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
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.

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.
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.
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:

Windows XP VM does not support Kerberos for client/server and/or user authentication
Windows XP VM does not support Network Layer Authentication (NLA): the remote session can be created even for a rogue user
Windows XP VM, does not support Server Authentication, so this VM can be used by any RDP server to steal user credentials
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.

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
Windows 7 supports offline domain join, which makes the process of joining a VDI VM to a domain faster and less error-prone
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

termserv — Fri, 30 Oct 2009 20:27:21 GMT

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

termserv — Wed, 28 Oct 2009 16:13:00 GMT

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

termserv — Fri, 23 Oct 2009 03:35:36 GMT

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

termserv — Tue, 20 Oct 2009 23:33:10 GMT

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

termserv — Wed, 14 Oct 2009 21:29:17 GMT

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

termserv — Tue, 29 Sep 2009 00:21:19 GMT

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.

Client / Server -> \| v	Windows 7	Windows Server 2008	Windows Server 2008 R2
Windows XP	Client : (1), (2)	Client : (1), (2) Server : (3)	Client : (1), (2) Server : (4)
Windows Vista	Client : (1), (2)	Client : (1), (2) Server : (3)	Client : (1), (2) Server : (4)
Windows 7		Server : (3)	Server : (4)
Windows Server 2008	Client : (2)	Client : (2) Server : (3)	Client : (2) Server : (4)
Windows Server 2008 R2		Server : (3)	Server : (4)

(1) RDC 6.1 or above (Windows XP with Service Pack 3 and above includes this).

(2) Even if RDC 6.1 or above is used, the user must install a supported version of .NET Framework separately. Microsoft .NET Framework 3.5 (which includes .NET Framework 3.0 SP1) can be downloaded from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=109422 ).
(3) Terminal Services role.
(4) Remote Desktop Session Host Role.

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.