Unable to remove RDS Session Host

A customer had a failed RDS Session Host which needed to be removed from a cluster.  We were not able to login to the failed host as it was blue screening and needed to be forcefully removed.

Even using PowerShell with the -force switch we were unable to remove the server getting the following error:

"Unable to cleanup the RD Session Host server"

To remove the server we needed to install SQL Management Studio and connect to the RD Broker Windows Internal Database (WID) which is a lightweight install of MS SQL.

SQL Management Studio was downloaded and installed from the following link:


https://go.microsoft.com/fwlink/?linkid=2094583

Make sure you run SQL Management Studio as "Administrator" and you should be able to connect to the following instance as a Domain Admin:

\\.\pipe\MICROSOFT##WID\tsql\query

The server needs to be removed from two tables:

• rds.Server
• rds.RoleRdsh

Make note of what ID number the server you want to remove is... mine is ID 4 as shown in the screenshots below.

Next I used the following command to remove the failed server from the RD Broker database:

use RDCms;

delete from rds.RoleRdsh where ServerID = '4';
use RDCms;
delete from rds.Server where Id = '4';

I strongly recommend a full backup of the SQL database be taken before making any changes.

Hope this post was helpful.

Excluding TEMP Directory from User Profile Disks in Remote Desktop Services

I had a customer with a line of business application attempting to open PDF files on a Server 2016 RD Session Host with User Profile Disks configured.

• When a user attempts to open a PDF document within the application, they get an Access Denied Error.
• When a user attempts to open a PDF document of a standard file share, the document opens correctly.

I used Microsoft Sysinternals process monitor to view what was happening.  The application was dumping the PDF document to the %TEMP% folder which was in the Profile Disk.  This was generating an Access Denied event.

During troubleshooting, I mounted one of the User Profile Disks and granted "EVERYONE" Full Control to AppData\Local\Temp folder as a test, unmounted the disk and got the user to login.

What I noticed was any changes to NTFS permissions on a UPD get reset back to default by RDS automatically upon user login.  Only the User, Administrators and SYSTEM have full control to all files/folders within a User Profile Disk.

I then looked at excluding the TEMP directory from the User Profile Disk as there is a way of adding Exclusions in the GUI.   There seems to be a known issue with excluding folders from user profile disks, this feature doesn’t seem to work and there are many threads about it.

I tried the following formats:

%TEMP%

AppData\Local\Temp

\AppData\Local\Temp

%userprofile\AppData\Local\Temp

All had no effect.

As a workaround, Instead of selecting "Store all user settings and data on the user profile disk", I selected "Store only the following folders on the user profile disk".  I then selected all folders which selects the entire user profile apart from the AppData and Favorites directory.

As you can see the AppData doesn’t have a redirect icon on it, all other folders in the profile do.

After making this change, this fixed my issue with the line of business application not being able to open PDF documents with Adobe Reader 

Legacy File Servers with User Profile Disks

I have been involved in a number of Remote Desktop Services 2012 R2 deployments and from my experiences, I recommend to my clients to only utilise Server 2012 R2 file servers.  This is due to two issues which I have experienced with legacy file servers such as Windows Server 2008 R2:

• Problems using DFS Namespaces
• Temporary Profiles

DFS Namespaces

DFS Namespaces are supported with User Profile Disks however from my experience both the file server and DFS namespace servers must be Server 2012 R2.  If they are not Server 2012 R2 you will receive this error:

 

Unable to enable user disks on UserVHDShare. Could not create template VHD.  Error Message: The network location "\\domain.local\namespace\foldertarget" is not available.

 

 I have replicated this twice in my lab and at a production site when dealing with 2008 R2 file servers.  If you utilise 2012 R2 file servers with 2012 R2 DFS namespace servers you will not experience this error.

Temporary Profiles

I have seen at a customer sites using 2008 R2 file servers sometimes results in temporary profiles.  This happens when the user logs off and the 2008 R2 file server does not release the file handle to the server.  This results in the VHD being locked and as a result, when users login they receive a temporary profile.

In this scenario we confirmed there was no real time AV scanning on the server or third party products that could be locking the server.  It only happens rarely but enough to get the odd user complain to service desk they are getting a temporary profile.

When the VHD is locked on the file server, restarting the Server service or restarting the file server unlocks the file again (both which result in downtime).

I worked with Microsoft PSS support on this case under 115052712773011 and got no where.  After upgrading the file server to 2012 R2, we had no more issues with user profile disks being locked under a file handle on the file server.  Microsoft said that it could be an issue when dealing with the legacy SMB 2.1 protocol where the legacy protocol fails to remove the file handle on the User Profile Disk after the user logs off.

When a Windows machine connects to a legacy operating system for file shares, it will always use the legacy version of the SMB protocol as shown in the following table.  It is recommended to always utilise SMB 3.02 when using Remote Desktop Services 2012 R2 which means you need a 2012 R2 file server for storing the profile disks.

http://blogs.technet.com/b/josebda/archive/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-you-are-using.aspx

RemoteApp Disconnected This computer can't connect to the remote computer

After deploying a Remote Desktop Services environment on Server 2012 R2, users complained of an issue where they were no longer able to launch RemoteApps from the RD Web App portal.  The error they received was:

RemoteApp Disconnected

This computer can't connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

To resolve this issue open the properties for your application collection experiencing problems, navigate to security and untick "Allow connections only from computers running Remote Desktop with Network Level Authentication".

 

This sorted out the problem in my environment.

Remove Power Shell and Server Manager Pinned Icons from Start Menu Server 2012

In Windows Server 2012 and Windows Server 2012 R2 by default all users have a Power Shell icon and a Server Manager icon pinned to their start menu.  When setting up a Remote Desktop Session Host with Windows Server 2012 Remote Desktop Services you may not want users to have the Server Manager icon or Power Shell icon especially when desktop access is enabled.

 

In previous versions of Windows Server there was a Group Policy setting called "Remove pinned programs list from the Start Menu" which administrators could use to remove these pinned applications from the start menu from Remote Desktop Session Hosts.

 

 

This policy no longer works on Windows Server 2012 and there is no well documented method available for doing this on the Internet.

 

In Windows Server 2012, the three default pinned applications on the start menu are located under the following location:

 

C:\Users\username\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

 

 

The User Pinned\Taskbar  folder in the Quick Launch directory does not exist in the Default profile in Windows Server 2012 as shown below.

So how do these icons get created in the users profile and where do they come from?

This process appears to be hardcoded into Windows Server 2012 and executed upon creating a new user profile.  The user profile creation process creates Quick Launch\User Pinned\TaskBar folder as part of the login then copies a bunch of "lnk" shortcut files from the "All Users Profile".

Server Manager Pinned Icon

The "Server Manager.lnk" file gets copied by the user profile creation From:

"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Server Manager.lnk"

To:

"C:\Users\username\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Server Manager.lnk"

Windows PowerShell Pinned Icon

The "Windows PowerShell.lnk" file gets copied by the user profile creation From:

"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\System Tools\Windows PowerShell.lnk"

To:

"C:\Users\username\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Windows PowerShell.lnk"

How to Prevent the icons from getting Populated to User Profiles

To stop the "Windows PowerShell.lnk" and "Server Manager.lnk" shortcuts from getting pinned to the start menu on all users, simply delete these icons from the All Users profile under "C:\ProgramData" from the following locations:

"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\Server Manager.lnk"

and

"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\System Tools\Windows PowerShell.lnk"

 

Now when new users login for the first time, the User Profile creation process is unable to copy the "Server Manager.lnk" and "Windows PowerShell.lnk" shortcuts as they no longer exist as shown in the following screenshot.

 

 

Powershell Find and Replace the Remote Desktop Services Profile

A customer of mine has configured all roaming user profiles on a Remote Desktop Services environment through the user account in Active Directory instead of utilising Group Policy setting "Set roaming profile path for all users logging onto this computer", the Microsoft preferred method as it ensures each profile folder matches the username and prevents inconsistencies which may encore as a result of an administrator incorrectly naming a folder.  It is recommended all Remote Desktop Services environments utilise Group Policy as a means of setting roaming profile and not the Active Directory user accounts.

I am in the process of implementing a new file server into the customers environment and updating the Remote Desktop Services profiles to point to the new file server.  My customer has the remote desktop services profile specified on each user account and there are inconsistencies as to how the profile is named, it does not always match username!  As a result we are not able to simply move to Group Policy roaming profile mapping moving forward.

I need a way of performing a find and replace to update the Remote Desktop Services User Profile path to match the new file server.  I achieved this by writing a PowerShell script to perform this task which I would like to share with you - here is a copy of my code:

$erroractionpreference = “stop"

 

$pDirValueOld = "\\oldserver\rdsprofiles"

$pDirValueNew = "\\newserver\rdsprofiles"

 

$profilepath = $null

 

$searcher = New-Object adsisearcher

$searcher.Filter = "(&(objectCategory=person)(objectClass=user))"

$searcher.SearchRoot = "LDAP://OU=Users,OU=Avantgarde Technologies,OU=Companies,OU=Active Directory,DC=at,DC=local"

$searcher.PageSize = 1000

$results = $searcher.FindAll()

 

 

foreach($result in $results)

{

$ADuser = [adsi]$result.Path

        foreach($user in $ADuser)

        {

        echo $user.distinguishedName

        $profilepath = $null

        $profilepath = $user.psbase.InvokeGet(“TerminalServicesProfilePath") -replace [regex]::Escape($pDirValueOld),($pDirValueNew)

        $user.psbase.InvokeSet(“TerminalServicesProfilePath",$profilepath)

        $user.setinfo()

        }

}  

To utilise this code you want to modify the following values:

$pDirValueOld = "\\oldfileserver\share"

$pDirValueNew = \\newfileserver\share

$searcher.SearchRoot = "LDAP://OU=Users,OU=Avantgarde Technologies,OU=Companies,OU=Active Directory,DC=at,DC=local

• pDirValueOld is the value you want to search for to be replaced.
• pDirValueNew is the value you wish to set the profile to.
• $searcher.SearchRoot is the LDAP path in Active Directory you wish to run this query recursively against.

Now I have a bunch of users in the Avantgarde Technologies --> Users OU which need to be updated.  As you see I have my Remote Desktop Services profile populated below:

 

I put the code into my PowerShell ISE development environment (as an alternative from saving it as a .ps1 script).  Then I made sure the following fields were populated correctly.

 

 

Run the code and all users recursively will have the Remote Desktop Services profile updated to point to the new path through a find and replace!

 

We can see the profile was successfully updated.

 

 

You can also modify my above code to perform a fine and replace on other items in the user account!

Hope you have found this post helpful!

Export List of Remote Desktop Service Logons from an RD Session Host

Sometimes as an administrator you may be required to create a detailed report of all Remote Desktop session logon's to a RD Session Host for auditing purposes.  All logon requests to a terminal server are recorded to TerminalServices-LocalSessionManager in the event log.

 

Simply tap into this with the Get-WinEvent PowerShell cmdlet.  The following PowerShell command will create you a spreadsheet in CSV format :

 

Get-WinEvent -LogName Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | select TimeCreated,Message | Export-Csv c:\output.csv -NoTypeInformation

Icons Do Not Appear in Internet Explorer 10 for RD Web Access

After upgrading to Internet Explorer 10 when accessing a 2008 R2 Remote Desktop Services (RDS) RD Web Access, we noticed the icons no longer display.

Running Internet Explorer 9, the icons display correctly:

However if you switch Internet Explorer 10 into compatibility mode, the icons also display correctly.  To enable compatibility mode click the following page icon next to the address bar.

When it turns blue in colour, this means compatibility mode is enabled and the RD Web Access icons will reappear in RD Web Access.

A bug has been logged with Microsoft on this issue.

Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to

I experienced an issue at a customer site with with a new Remote Desktop Services deployment on Windows Server 2008 R2 when building a Server Farm.

 

When Windows 7 PC's accessed a RemoteApp or attempted create a remote desktop session using the Microsoft Terminal Services Client (MSTSC.exe) they were able to connect to the farm without problems.

 

When an Windows XP PC accessed the remote desktop farm, the following error was experienced:

 

"Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to.  Contact your network administrator for assistance."

 

After researching the issue it turned out that the RD Session Hosts needed to be configured to use RDP Security as the Security Layer.  After installing a custom trusted certificate to the RDP-Tcp connection to ensure users connecting to the session hosts do not receive RDP Certificate not trusted warnings the issue started occuring.

These configuration options can be found under "Remote Desktop Session Host Configuration"

 

By default the Security layer was set to Negotiate.

 

Set all servers to RDP Security Layer in your farm to ensure both XP and Windows 7 clients can connect.

Removing the requirement to specify domain name with Single Signon for Remote Desktop Services

Windows 2008 R2 Remote Desktop Services single signon provides the users the ability to login to RD Web Access and launch applications without having to provide login credentials twice.  While single sign on is great it does not just work out of the box, there are a few things you need to do to configure single sign on.  These steps are documented on the following blog post:

http://blogs.msdn.com/b/rds/archive/2009/08/11/introducing-web-single-sign-on-for-remoteapp-and-desktop-connections.aspx

What is not documented however is for single sign on to work by default, users must login with:

DOMAIN\Username

For example:

If a user logs in with just the user name such bugs.bunny as show in the screenshot below, when the user enters the RD Web Access and attempts to launch a remote application the user will receive the error below.

 

Error experienced:

Your computer can't connect to the remote computer because an error occured on the remote computer that you want to connect to.  Contact your network administrator for assistance.

Note: This error message is generic and is presented for a wide range of problems relating to RDS.

For my this Active Directory we want users to login by simply entering their username, we do not want users to have to specify their domain name.  To do this perform the following procedure:

 

1.     Login to the Remote Desktop Web Access role-based server with local/Domain administrative permissions.

2.     Navigate to the following location:

 %windir%\Web\RDWeb\Pages\The Language of Your Location\

3.     Backup the login.aspx file to another location.

4.     Right click the login.aspx file, and select Edit. The file will be opened with Edit status in your default HTML editor.

5.     Change the original code section:

input id=”DomainUserName” name=”DomainUserName” type=”text” class=”textInputField” runat=”server” size=”25” autocomplete=”off” /

to be:

input id=”DomainUserName” name=”DomainUserName” type=”text” class=”textInputField” runat=”server” size=”25” autocomplete=”off” value=”domainname\” /

 

6.     Save the modification.

Now when users access the RD Web Access portal the username field will already be populated with domainname\

 

RemoteApps do not appear in RD Web Access when configured to use the RD Broker

Whilst building a new RDS server farm I ran across a problem which had me stumped for a few hours.  When configuring RD Web Access you need to specify a source for the RemoteApps, either an RD Broker or a bunch of Session Hosts as per the following screenshot.

When I selected "An RD Connection Broker" and specified the name of the broker server, I did not get any RemoteApps appearing in my "RemoteApps Programs" tab.  However when I specified the name of a Remote Desktop Session Host, the applications on the session host appeared as selected.

After much troubleshooting the problem was identified.  On each RD Session host server there is a local group called "TS Web Access Computers" which documentation on TechNet says you must nest the computer accounts of any RD Session Hosts for which you want applications published.  However if you wish to publish applications through an RD Connection Broker, you must nest the RD Connection Broker computer account inside this group instead.  I found this a little unclear in the TechNet documentation.  After fixing up the group nesting the problem was resolved.

Outlook 2003/2007 Looses Email Signature on Terminal Servers

I had a really weird problem with outlook 2003 installed on a terminal server farm running Windows Server 2003 Enterprise Edition R2 x86. Whenever users logged into a different terminal server their outlook signature under tools --> options --> mail format --> signatures got set to instead of their predefined configured signature. The user would have to go back and re-select their signature every time they logged into a different terminal server.

I had multiple servers in the farm with the following configuration:

- Users profiles are redirected to a network share

- Users profiles are deleted of the terminal server when users log off

- Application Data, Desktop, Documents are all redirected off to network shares for each user.

- Citrix was installed on terminal servers in the farm.

I visited Microsoft KB918561 and deleted the ImportPRF key as Microsoft suggested from each terminal server, however this did not fix my issue.

Resolution

The problem comes with the way Microsoft implemented the installation process for Outlook. During installation, Outlook creates a registry entry called First-Run. It contains some sort of cryptic code which I don't fully understand, but you don't need to. The problem comes from the fact that when you install Outlook on the second server, it generates a NEW, UNIQUE code. When a user launches Outlook for the first time, that First-Run key gets copied into their profile and follows them around. Unfortunately, when the user next launches Outlook, if they hit a server with a different First-Run key, Outlook makes the assumption they are a new user, and will wipe out certain profile information, including the signature info. The signature itself probably isn't gone, just the information that tells Outlook to actually use it.

The First-Run key is located under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\Outlook\Setup

If you notice notice in this terminal server environment, each terminal server had a different hex code for First-Run.

Terminal Server 1 ("First-Run"=hex:0b,e4,9d,de,3f,17,87,40,8b,8f,e4,70,c7,3c,24,88)



Terminal Server 2 ("First-Run"=hex:37,47,b4,ae,5f,18,10,49,b9,e1,18,27,9e,e3,6b,59)



What I did was export the First-Run REG-BINARY value to a .reg file from Terminal Server 1 then import the reg file into all other terminal servers in the farm. Once you ensure that the hex code for First-Run is the same on all terminal servers in the farm, the issue will not occur anymore.

The same problem also exists for Office 2007. The above fix still applies, just change 11.0 to 12.0

Hope this post fixes your issue, please leave feedback.

Citrix RDP Logon Error

The following error was experianced when logging onto a citrix server using a standard user account with RDP. Administrator accounts can still logon with RDP.

The desktop you are trying to open is currently available only to administrators. Contact your administrator to confirm that the correct settings are in place for your client connection.

Also the error message "To log on to this remote computer, you must have Terminal Server User Access permissions on this computer."



The second error is ususally when you are trying to log onto a terminal server and you do not have "Allow logon over terminal services" user rights assignment in place. Most cases you nest the user account or domain users inside "Remote Desktop Users", a group that is always granted "Allow logon over terminal services".

However with citrix installed even though these permissions are right it will still not log in. To resolve this go to tscc.msc to open up the Terminal Services Configuration Connections. Go to the properties of the RDP-Tcp terminal services connector. Go to the Citrix Settings tab, and untick Non-administrators only lauch published applications.

Windows Server 2008 Terminal Services

In this post I will be going through some of the new features that are included in Windows Server 2008 terminal services. It frustrates me as many people do not know how powerful 2008 terminal services are now compared to server 2003. When most people (including administrators) think of "Terminal Services" they think of the functionality that of which was provided by Server 2003 which I can say was very limited! It also frustrates me that many companies implement Citrix as their terminal server solution blowing money away that is no longer needed to be spent. There are business cases for when you would need to use Citrix over 2008 Terminal Services however for many companies using Citrix, they do not require it - they were simply sold it as the sales guy did not know better.

Please note that these features listed below are those of which came with Windows Server 2008 RTM, not Windows Server 2008 R2. Microsoft actually changed the name in Server 2008 R2 from Terminal Services to RDS (Remote Desktop Services). But again we will not be going into the R2 stuff, only standard Terminal Services features that came with Server 2008.


Terminal Services RemoteApp

Previously in server 2003 you could only present a entire desktop to a terminal server user. Now with server 2008 you can present just applications to workstations. If the program uses a notification area icon, that icon appears in the client’s notification area. Pop-up windows are redirected to the local desktop and local drives and printers are redirected and made available within the remote program. Users may even be unaware that the remote program is any different than other local applications running side-by-side with the remote program on their desktop because similar functionality, such as cut and paste, are available. Also if a user opened a .doc file on their local machine in their my documents folder, and they have Microsoft Word presented to them by a Microsoft Remote App server, file extensions carry accross so the document file will actually open up in the terminal session - the user will not have a clue what goes on in the back end.

RemoteApp programs are programs that are accessed remotely through Terminal Services and appear as if they are running on the end user's local computer. Users can run programs from a terminal server and have the same experience as if the programs were running on their local computer, including resizable windows, drag-and-drop support between multiple monitors, and notification icons in the notification area.

Here is an example of OneNote running as a RemoteApp mixed with real physical Apps on a vista PC. Click to make it bigger.



Users can run RemoteApp programs side by side with their local programs. They can minimize, maximize, and resize the program window as well as cut and paste, and easily start multiple programs at the same time. If a user is running more than one RemoteApp program on the same terminal server, the RemoteApp programs will share the same Terminal Services session.

There are many ways of deploying remote apps to workstations however there is only one way I would recommend and that is to package the application as an msi using the remote apps MMC console on the server, then using group policy to push it out to the workstations. These MSI's are very small, all they do is add the icons (or shortcuts if you will) and create the file associations on the users workstation.

Users can run RemoteApp programs in a number of ways:
• Double-click a Remote Desktop Protocol (.rdp) file that has been created and distributed by their administrator.
• Double-click a program icon on their desktop or Start menu that has been created and distributed by their administrator with a Windows Installer (.msi) package.
• Double-click a file whose extension is associated with a RemoteApp program. (This can be configured by their administrator with a Windows Installer package.)
• Access a link to the RemoteApp program on a Web site by using Terminal Services Web Access (TS Web Access).


Terminal Services Web Access

Terminal Services Web Access (TS Web Access) is a service within Terminal Services that lets you make TS RemoteApp programs, and a link to the terminal server desktop, available to users from a Web browser. Additionally, TS Web Access enables users to launch a connection from a Web browser to the remote desktop of any server or client computer where they have the appropriate access.

Here is an example of what the TS Web Access portal looks like:



TS Web Access acts as the access or launch mechanism in conjunction with TS Gateway, to enable you to easily deploy RemoteApp programs over the internet in conjunction with TS Web Access. A user can visit a Web site, view a list of RemoteApp programs, and then simply click on a program icon to start the program. The RemoteApp programs are seamless, meaning that they appear like a local program. Users can minimize, maximize, and resize the program window, and can easily start multiple programs at the same time. For an administrator, TS Web Access is easy to configure and to deploy.

TS Web Access is very user friendly compared to other vendors that provide the same services. This is because users do not have to download a separate ActiveX control to access TS Web Access. Instead, RDC 6.1 includes the required ActiveX control. (The RDC 6.1 client supports Remote Desktop Protocol 6.1.) RDC 6.1 is included in Vista SP1 and Windows XP SP3 and combines both the traditional RDC and the ActiveX control. Citrix users will still need to download and install the Active X control to connect in which generates majority of your help desk calls. Also having done a bit of desktop support in my past years, I remember when there were citrix updates for the citrix terminal servers, and users still had the old ActiveX controls on their workstations. These didn't automatically update, I had to walk around to everyone's workstation, uninstall the old ActiveX control so it would automatically download the new one.

The TS Web Access portal is just as customizable as Citrix. You can add custom company banners, change colours and feel of the page, deploy as part of a customized webpage using ActiveX and ASP (Terminal Services client is fully scripable) - for more information visit http://msdn2.microsoft.com/en-us/library/aa383022(VS.85).aspx. You can integrate it in as part of a sharepoint service site, or you could be lazy like me and just deploy it as the default out-of-box solution. I'm not one for customizing and pretty colours.

As an administrator, you can use IIS application settings to configure whether the Remote Desktop tab is available to users. Additionally, you can configure settings such as the TS Gateway server to use, the TS Gateway authentication method, and the default device and resource redirection options.


Terminal Services Gateway

Terminal Services Gateway (TS Gateway) is a role service that allows authorized remote users to connect to terminal services based resources on an internal corporate or private network, from Internet-connected devices. The network resources can be terminal servers, terminal servers running RemoteApp programs, or computers with Remote Desktop enabled.

TS Gateway uses Remote Desktop Protocol (RDP) encapsulated in RPC over HTTPS to establish a secure, encrypted connection between remote users on the Internet and the internal network resources on which their productivity applications run.



If your organization makes Terminal Services–based applications and computers that run Remote Desktop available to users from outside your network perimeter, TS Gateway can simplify network administration and reduce your exposure to security risks. TS Gateway can also make it easier for users because they do not have to configure VPN connections and can access TS Gateway servers from sites that can otherwise block outbound RDP or VPN connections. Note if your users need more then RDP 3389 externally then I would still recommend VPN.

TS Gateway provides a secure yet flexible RDP connection allowing users access to anything to which their RDP host has access, rather than allowing remote users direct network connectivity to all internal network resources; helping protect the internal resources.

The TS Gateway Manager snap-in console enables you to configure authorization policies to define conditions that must be met for remote users to connect to internal network resources. For example, you can specify:
• Who can connect to network resources (in other words, the user groups who can connect).
• What network resources (computer groups) users can connect to.
• Whether client computers must be members of Active Directory® security groups.
• Whether device and disk redirection is allowed.
• Whether clients need to use smart card authentication or password authentication, or whether they can use either method.

TS Gateway also has full built in support for NAP (Network Access Protection) to ensure all remote clients accessing your network are virus free, up to date in patch level and have an active firewall running. The NAP Client is built into the Microsoft Security Center which is on all windows releases from Windows XP SP3 and higher.

You can use TS Gateway server with Microsoft Internet Security and Acceleration (ISA) Server to enhance security. In this scenario, you can host TS Gateway servers in a private network rather than a perimeter network and screened subnet), and host ISA Server in the perimeter network. The SSL connection between the Terminal Services client and ISA Server can be terminated at the ISA Server, which is Internet-facing.

The TS Gateway Manager snap-in console provides tools to help you monitor TS Gateway connection status, health, and events. By using TS Gateway Manager, you can specify events (such as unsuccessful connection attempts to the TS Gateway server) that you want to monitor for auditing purposes. There is also full SCOM integration for this so you can monitor your terminal services health all from OpsMgr 2007.

TS Gateway provides several new features to simplify administration and enhance security.

Monitoring Capabilities: You can use TS Gateway Manager to view information about active connections from Terminal Services clients to internal corporate network resources through TS Gateway. This information includes the connection ID, the domain and user ID of the user logged on to the client, full name of the user logged on to the client, date and time when the connection was initiated, length of time the connection was active, length of time that the connection is idle- if applicable, name of the internal network computer to which the client is connected, IP address of the client.

Group Policy Settings for TS Gateway: You can use Group Policy and Active Directory Domain Services to centralize and simplify the administration of TS Gateway policy settings. You use the Local Group Policy Editor to configure local policy settings, which are contained within Group Policy Objects (GPOs). You use the Group Policy Management Console (GPMC) to link GPOs to sites, domains, or organizational units (OUs) in Active Directory Domain Services. Group Policy settings for Terminal Services client connections through TS Gateway can be applied in one of two ways. These policy settings can either be suggested (that is, they can be enabled, but not enforced) or they can be enabled and enforced. Suggesting a policy setting allows users on the client to enter alternate TS Gateway connection settings. Enforcing a policy setting prevents a user from changing the TS Gateway connection setting, even if they select the Use these TS Gateway server settings option on the client.

TS CAPs: Terminal Services connection authorization policies (TS CAPs) allow you to specify user groups, and optionally client computer groups, that can access a TS Gateway server. You can create a TS CAP by using TS Gateway Manager. TS CAPs simplify administration and enhance security by providing a greater level of control over access to computers on your internal network. TS CAPs also allow you to specify who can connect to a TS Gateway server. You can specify a user group that exists on the local TS Gateway server or in Active Directory Domain Services. You can also specify other conditions that users must meet to access a TS Gateway server. You can list specific conditions in each TS CAP. For example, you might require a user to use a smart card to connect through TS Gateway. Users are granted access to a TS Gateway server if they meet the conditions specified in the TS CAP.

TS RAPs: Terminal Services remote authorization policies (TS RAPs) allow you to specify the internal corporate network resources that remote users can connect to through a TS Gateway server. When you create a TS RAP, you can create a computer group (a list of computers on the internal network to which you want the remote users to connect) and associate it with the TS RAP. Remote users connecting to an internal network through a TS Gateway server are granted access to computers on the network if they meet the conditions specified in at least one TS CAP and one TS RAP. Together, TS CAPs and TS RAPs provide two different levels of authorization to provide you with the ability to configure a more specific level of access control to computers on an internal network.


Terminal Services Session Broker

Terminal Services Session Broker (TS Session Broker) is a role service in Windows Server 2008 that allows a user to reconnect to an existing session in a load-balanced terminal server farm. TS Session Broker stores session state information that includes session IDs and their associated user names, and the name of the server where each session resides. I had someone from Citrix come out and give a presentation trying to tell us it worked the same as NLB (which was used in server 2003) - shows how out of date peoples knowledge in this area is.

The new TS Session Broker Load Balancing feature enables you to evenly distribute the session load between servers in a load-balanced terminal server farm. With TS Session Broker Load Balancing, new user sessions are redirected to the terminal server with the fewest sessions.

TS Session Broker is a two phased load-balancing mechanism. In the first phase, initial connections are distributed by a preliminary load-balancing mechanism, such as DNS round robin. After a user authenticates, the terminal server that accepted the initial connection queries the TS Session Broker server to determine where to redirect the user.

In the second phase, the terminal server where the initial connection was made redirects the user to the terminal server that was specified by TS Session Broker. The redirection behavior is as follows:
• A user with an existing session will connect to the server where their session exists.
• A user without an existing session will connect to the terminal server that has the fewest sessions

TS Session Broker Load Balancing sets a (total combined) limit of 16 for the maximum number of pending logon requests to a particular terminal server. This helps to prevent the scenario where a single server is overwhelmed by new logon requests; for example, if you add a new server to the farm, or if you enable user logons on a server where they were previously denied.

The TS Session Broker Load Balancing feature also enables you to assign a relative weight value to each server. By assigning a server weight value, you can help to distribute the load between more powerful and less powerful servers in the farm.

A User logon mode setting is provided that enables you to prevent new users from logging on to a terminal server that is scheduled to be taken down for maintenance. This mechanism provides for the ability to take a server offline without disrupting the user experience. If new logons are denied on a terminal server in the farm, TS Session Broker will allow users with existing sessions to reconnect, but will redirect new users to terminal servers that are configured to allow new logons.

You can still use load balancing techniques such as NLB or Round-Robin DNS to load balance 2008 terminal servers buy why would you when you have TS Session Broker.


Terminal Services Easy Print

Terminal Services Easy Print (TS Easy Print) is a feature in Windows Server 2008 that enables users to reliably print from a TS RemoteApp program or from a TS remote desktop session to the correct printer on their client computer. Microsoft Easy Print is better then the Citrix universal print driver as the universal print driver supports most printers however easy print supports all printers provided there is a driver on the client PC. Terminal Services Easy Print leverages the client-side print driver (no server side driver needed) to enable fast and reliable printing to a local or network-attached printer. End users can more productively work from remote locations. It also enables users to have a much more consistent printing experience between local and remote sessions.

The Redirect only the default client printer policy setting allows you to specify whether the default client printer is the only printer that is redirected in Terminal Services sessions. This helps to limit the number of printers that the spooler must enumerate, therefore improving terminal server scalability.

To use the TS Easy Print driver, clients must be running both of the following:
• Remote Desktop Connection (RDC) 6.1
• Microsoft .NET Framework 3.0 Service Pack 1 (SP1)

Also new in Windows Server 2008 Terminal Services is the Use Terminal Services Easy Print printer driver first Group Policy for Terminal Services printing located in the following node of the Local Group Policy Editor: Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection.


Terminal Services Licensing

Yes - still the same old stuff here. Distributes licences to each of your terminal servers on your network. Can distribute licences to multiple farms. You normally want to put this on a server as an additional role as it does not use hardly any CPU usage or memory usage.


Terminal Services and Windows System Resource Manager

Windows System Resource Manager (WSRM), allows you to control how CPU and memory resources are dynamically allocated to applications, services, and processes. Managing resources in this way improves system performance and reduces the chance that applications, services, or processes will interfere with the rest of the system. It also creates a more consistent and predictable experience for users of applications and services running on the computer.

You can use WSRM to resource allocation of the following things:
• TS Sessions on a terminal server
• Users on a server (users are seperate because remember it is possible to have 1 user with multiple sessions open in effect eating up all the resources on the terminal server). You can manage users by security group!
• Administering resource usage of multiple Microsoft SQL Server® instances sharing a server.
• Administering resource usage of IIS 6.0 application pools on a server, such as when one server hosts multiple Web sites.
• Reports on memory usage and CPU time to support service level agreement (SLA) metrics.

What you can do with WSRM is ensure that no applications eat up all processing power on a terminal server, or that 1 user or TS session does not hog all available processing power to the server. Windows System Resource Manager is a feature that is built into all 2008 servers and should be used to ensure no server has a memory leak or constant processor loop but it is particulary handy on terminal servers. I'd always lock it down to either TS Session or TS Users and you can do this to all terminal servers in your farm by simply using a group policy.

With WSRM you can ensure that everyone has an equal share to a terminal servers resources!


Other New Features

Large Display Support - Custom display resolution provides support for large display and additional display resolution ratios (up to 4096x2048). Additionally, only 4:3 display resolution ratios were supported, now can create custom ratios like 16:9 or 16:10. Finally, full 32-bit color depth is now enabled and with the new compression engine 32-bit color will typically consume less bandwidth than 24-bit color. You can set a custom display resolution in an .rdp file or from a command prompt.

Multiple Monitor Support - Monitor spanning allows you to display your remote desktop session across multiple monitors (only support for horizontal spanning); you can enable it in an .rdp file or from a command prompt by including the /span switch.

Vista Experiance - You can enable Vista Experiance on your 2008 server to give your users the full Areo desktop experiance - ooooo fancy!

RDP Protocol and Advanced Compression - Terminal Services delivers applications and data via the Remote Desktop Protocol (RDP), an optimized transport mechanism low bandwidth. Traditional client server applications that slow end-user productivity over a slow network connection, receive a performance boost when delivered via Terminal Services to remote users. This compression is not as great as ICA but it is getting there.

PnP Device Redirection Framework - The PnP Device Redirection Framework enables driver vendors to create device drivers to ensure their hardware can be utilized remotely over RDP. Microsoft includes “out-of-the-box” support for MTP Devices (Cameras and MP3 players that have a Windows mode) and Windows Embedded Point of Service Devices (WePOS).

Advanced Clipboard Redirection - The clipboard had been improved with Windows Server 2008 Terminal Services to enable stream support. This improves the performance of redirected drives, enable support for more types of data to be exchange via cut and paste e.g graphics, files, office data etc. I think this is fantastic I use it all the time - copying and pasting images in and out of RDP sessions.

Wildcard SSL Certificate Support - SSL certificates are used in TS Gateway, TS Web Access, RDP Signing and TLS Authentication. Obtaining multiple SSL certificates for all of these purposes can, for some customers, be both costly and a management challenge. TS supports Wildcard SSL certificates for all these purposes, Wildcard certificates provides a single certificate than can be used on multiple machines.

RDP Signing - RDP signing allows signing of RDP files and connections launched from TS Web Access. This helps the user be sure that they are not using malicious RDP files to potentially connect to hostile terminal servers. It is also possible, using group policy, to specify that a user can only launched signed files. This allows administrators to ensure that users only connect to know resources.


Clint's Wrap Up

These features listed above are those of what were released in the initial 2008 RTM release. With R2 and RDS (Remote Desktop Services) the Microsoft terminal technology has taken another huge leap forward - when I get time I will write another blog post of what new features have been introduced into R2 terminal services.

One thing I will admit though is Citrix is still a better solution - one of the key factors behind their success is the ICA protocol. It's bandiwidth utilization is amazing. However one thing I would like to achieve is majority of the selling points Citrix are still using (even the citrix engineers) are features that are natively supported in Windows Server - so why would you go pay for them?

Companys that have huge branch offices with an extremely slow link such as a remote mine site would definately benefit from Citrix because they can take advantage of ICA enhancers such as their WAN Scaler.

However I think for majority of businesses they would be wasting money for software that is not needed.

I would love feedback - feel free to contact me on clint@kbomb.com.au