WindowsNetworking.com Monthly Newsletter of June 2010 Sponsored by: SolarWinds
Welcome to the WindowsNetworking.com newsletter by Debra Littlejohn Shinder, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: firstname.lastname@example.org
I spent last week at TechEd in New Orleans, working at the Remote Desktop Services booth in the Windows Server and Virtualization area. That meant diving deeply into the new features of RDS (formerly called Terminal Services) in Windows Server 2008 R2 and fielding some pretty complex questions about deployment in various situations. There were also lots of people whose question was "What is RDS?" Many thought it referred to Remote Desktop Administration, which uses the RDC client to connect to a server to do maintenance and administrative tasks and is restricted to two concurrent connections. Others wanted to know the difference between providing users with a desktop via RDS and doing the same thing via VDI. Many had questions about setting up a Remote Desktop Gateway to allow users to connect over the Internet with an SSL connection or setting up Remote Desktop Web Access so users could access published applications via a web browser.
I started playing around with Terminal Services back when it only came in a special edition of Windows NT. In the "old days" (Windows Server 2003 and prior), it was a pretty simple and straightforward thing. You enabled terminal services application mode on a Windows server and configured the users who would have access. You used the Terminal Services Manager to view and manage users, sessions and processes. Oh, you could create a load balanced farm with Server 2003 machines, but Microsoft's Network Load Balancing (NLB) had a lot of limitations and you often needed to resort to third party solutions.
Server 2008 and 2008 R2 bring major changes and improvements to the TS/RDS role, including:
Other additions and enhancements include RDS provider for PowerShell, improvements to load balancing and Fair Share CPU scheduling, true multiple monitor support on a remote desktop connection, audio/video improvements and a new version of the Remote Desktop Protocol (RDP) and Remote Desktop Connection (RDC) client. Performance improvements mean you might not need Citrix ICA now to get the kind of performance you want.
What we used to know as Terminal Server running in Application Mode is now called the RD Session Host server. It is a role service that you enable after enabling Remote Desktop Services itself in Server Manager on your Server 2008 R2 machine. RemoteApp is part of the RD Session Host, so you can publish individual applications from your RD Session Host server. However, you will notice that there are a number of other role services that can be enabled for different deployment scenarios, and things can get complicated pretty quickly.
First, you will need an RD Licensing Server, although RDS will operate for 120 days without one. After that, RDS will stop working. Licensing is on a per-user or per-device basis; you will want to use per-user licensing if you have more devices than users (i.e., one user connects from multiple computers) and per-device licensing if you have more users than devices (several users share one computer). It is recommended that the licensing server be installed on a separate server (physical or virtual) that is not an RD Session Host.
If you want to allow users to connect over the Internet via RDP over HTTPS (which will work through firewalls that block RDP and VPN connections), you need to configure an RD Gateway. This, too, is a role service and it should be on a separate machine. Improvements to the Gateway in Server 2008 R2 include configurable idle and session timeouts, background session authentication and authorization, device redirection enforcement, and NAP remediation.
If you have users who need to access remote desktops or remote applications but do not have the RDC client installed, you can set up an RD Web Access server. This role service should be installed on a separate server from the RD session host and IIS will automatically be installed with it. You will need to install and configure an X.509 certificate for the web site, either from your own PKI or a trusted third party certification authority. Users who log onto the URL for your RD web access server will be presented with a page showing only those apps to which you have assigned them access. You can enable single sign-on via Group Policy to simplify user logon.
If you have many users and need to deploy more than one RD Session Host, you can set up an RDS farm and use the RD Connection Broker (which was named Session Broker in Terminal Services) to enable load balancing and reconnection to existing sessions. This ability to reconnect when a user is disconnected is a big advantage of using the Connection Broker instead of Windows Server 2008 R2's NLB or a third party load balancing solution.
In addition to managing your RDS servers via the Remote Desktop Connection Manager and Remote Apps Manager (available in the Administrative Tools menu), Server 2008 R2 adds an RDS module for PowerShell that lets you access the configuration settings of the RDS role services via the PowerShell interface. This makes it possible for you to automate recurring tasks by scripting them, or change settings and perform tasks directly from the command line.
As you can see, there's a lot to love - and a lot to learn - in the new Remote Desktop Services, especially if you're coming from a Server 2003 or prior Terminal Services environment - and we haven't even touched on VDI. We'll save that topic for a future article. In the meantime, if you want to know more about RDS and all of the virtualization technologies in Server 2008 R2, I highly recommend the book Mastering Microsoft Virtualization, published by Sybex. It's written by a group of Microsoft employees and goes into great detail about how RDS works and how to deploy it. You'll also want to check out the Remote Desktop Services Deployment guides on the TechNet web site.
Let us know what you think. Have you tried RDS in Server 2008 R2? What do you like or not like about it? Are you delivering full desktops to thin clients, giving users seamless access to individual applications running on the server via RemoteApp, or deploying some other scenario? What further improvements would you like to see? Write to me at email@example.com and if security is your concern, check out my forthcoming article on securing Remote Desktop Services in Windows Server 2008 R2 that I will be writing for the Windowsecurity.com web site in the next month.
See you next month - Deb.
3. WindowsNetworking.com Articles of Interest
How to Set Multiple Services on Multiple Remote Computers
This article can be useful for users who want to set multiple services on remote computers. The following steps can be performed to accomplish this:
You can find this administrator tip here.
For more administrator tips, go to WindowsNetworking.com/WindowsTips
Are you getting ready to migrate to Windows Server 2008 R2? Need specific information on how to migrate various server roles - including Active Directory Domain Services and DNS, Certificate Services, DHCP, Branch Cache, File Services, Hyper-V, RRAS, NPS and many more - onto the new platform? This set of migration documentation and tools can ease the process, whether you're moving from Windows Server 2003 or Windows Server 2008, and simplify the deployment of your servers, including those running Server Core or those that are virtualized.
The good news is that most of the tools and scenarios are very flexible, allowing you to migrate between physical and virtual environments or from x86 to x64 based platforms, and they will cover most of the "gotchas" that you might encounter during your migration process and help you prepare for a smooth and pain-free migration with minimal downtime.
Check them out here.
I have been working with Active Directory for many years and one big pain that I find is the process that you have to go through to restore a deleted AD object: restore the system state of the domain controller, boot into Directory Services restore mode and do a selective authoritative restore of the object. Sheesh!! It's my understanding that Server 2008 R2 makes this easier. Can you tell me how that works and whether there are any caveats? Thanks! - Allen H.
Windows Server R2 includes a new feature that's called Active Directory Recycle Bin. Microsoft recognized that the existing process takes a lot of administrative time and also results in server downtime that can affect productivity, and that there had to be a better way to restore deleted objects to the directory.
You have to enable the AD Recycle Bin feature as it's disabled by default. When you do, the attributes of objects are preserved and restored to the same state they were in right before the deletion occurred. What this means is that if you deleted a user account, when you restore it, it will still have its group memberships and so forth.
As for caveats, before you can enable this feature, you have to raise the forest functional level to Windows Server 2008 R2. This means that all the domain controllers in the forest have to be running WS 2008 R2 - and that can be a big "gotcha". If you can meet that requirement, then by all means, go for it. You can find the instructions on how to enable the AD Recycle Bin and how to use it to restore a deleted AD object here.