Geek of All Trades: Behind the Scenes with RDS
Our intrepid Geek of All Trades sits down with the authors of the Remote Desktop Services Resource Kit.
Greg Shields
Remote Desktop Services (RDS) is one of those technologies you’ll find in almost every Microsoft environment. Whether it’s configured to deliver applications or desktops, RDS is a centralized mechanism to connect users with the tools they need to do their jobs.
With the release of Windows Server 2008, the list of capabilities RDS offers grew longer. The most obvious addition was its ability to deliver individual applications as RemoteApps, as well as the traditional full desktop. This eliminated the confusing “double-desktops” problem of earlier versions. It also streamlined the user’s experience down to just the application itself.
With Windows Server 2008 R2, RDS again took a big leap forward with its integration into virtualization architectures like Microsoft Hyper-V. Combining RDS with Hyper-V gives the Jack-of-all-trades (JOAT) IT pro many of the same desktop-virtualization capabilities enjoyed by large enterprises. That combination represents some undeniably cool technology, but getting that integration to work requires a new set of skills. Even deciding whether this new path is right for your use case adds an extra step to an RDS implementation.
These decisions—along with all of the other new capabilities of RDS R2—are why Microsoft Press recently released the “Windows Server 2008 R2 Remote Desktop Services Resource Kit” (Microsoft Press, 2010). This nearly 700-page guide has been completely updated to include the new RDS R2 technologies. It’s the go-to guide for every JOAT responsible for implementing or maintaining RDS in its traditional or Virtual Desktop Infrastructure (VDI) configuration.
I caught up with the books’ two authors, Christa Anderson and Kristin Griffin. Anderson is a Microsoft program manager with the RDS team and Griffin is a Microsoft MVP for RDS. We talked about their experiences writing the book and tips they can share that will specifically assist the JOAT. Here’s what they had to say.
Speaking of RDS
Shields: You’re involved with the Microsoft RDS product team, so can you tell us which RDS features in Windows Server 2008 R2 JOATs should watch for specifically?
Anderson: RDS is huge now, addressing many more scenarios than it did in Windows Server 2003 and even more than it did in Windows Server 2008. The first thing a JOAT needs to think of is what they need to accomplish with virtualization. Then they can focus on what’s most important to their needs. For example, if all users are connected to the LAN, then they may not need to use RD Gateway.
That said, I’d recommend that all JOATs get a handle on RD Session Host—the RDS role service that performs the core functions of Remote Desktop. Many people think first of virtual desktop infrastructure as a solution for task workers. In many cases, a traditional Remote Desktop session works just as well. Traditional Remote Desktop sessions also facilitate a much greater user density per machine. So, while VDI is exciting technology, consider it as a second option only after you’ve determined if a more traditional RDS session won’t fit your needs.
Also, educate yourself on the features of the Remote Desktop Client [RDC] 7 and 7.1. If you’re coming from Windows Server 2003, you’ll find the RDC in Windows Server 2008 R2 very powerful and a great user experience for remote connections.
Griffin: I think it would be great if JOATs learned all the features. Knowing what you can accomplish is the best way to make the most of the technology. Learn what each role service does and understand which service you’ll need to accomplish your goals. Then you can spend more time focusing on the specific role services involved in your solution. Here’s a good path to guide your learning:
- If you need to give people access to an application and only have one server, start with the RD Session Host, RD Easy Print and RD Licensing role services.
- Once your needs grow past a single RD Session Host server, begin learning RD Connection Broker as well.
- Learn RD Web Access if you need to provide a Web portal for accessing applications. RD Web Access is also useful for delivering easy access to RemoteApps via the Windows 7 Start Menu (via the RemoteApp and Desktop Connection feature).
- RD Gateway should be next. Learn this when access to your applications from outside the corporate network becomes necessary.
- Finally, for applications that only work on Windows XP, or for moving your desktop experience into the datacenter, make sure you’re familiar with RD Virtualization Host, RD Licensing and RD Connection Broker.
Shields: The nature of the JOAT is to be responsible for everything in an environment. This means they’re generalists rather than specialists. How has RDS grown easier for the IT generalist?
Anderson: It’s easier in some ways, but harder in others because RDS does so much more now. The JOAT has more to learn. One way it’s easier is that more vendors are taking virtualization into account. Applications that meet Microsoft’s requirements for Windows Vista and later operating systems should work on RDS with no problems. Printing is simplified when you don’t need to take two different printer driver names into account. RDS itself is also designed to help the administrator. For example, its Best Practices Analyzer is designed to catch and alert on some basic configuration mistakes people often overlook. The basic underpinnings just work better than before.
Griffin: RDS is better documented. This really is a huge plus, especially for JOATs who have to learn fast. Printing with RD Easy Print eliminates the old troubles with kernel mode drivers crashing servers. It resolves the issues in matching up drivers on the server and client. RD Connection Broker also makes farm creation a snap.
Shields: Certificates are always a difficult topic, as are the security requirements of working in the DMZ. Yet securing RDS traffic and extending it to the Internet require experience with both. What tips and tricks should a JOAT know to ease this sometimes complex implementation?
Griffin: Avoid using the built-in self-signed certificates for live environments. Certificates are cheap these days. Spend the money and get a certificate from a real third-party vendor. Use a vendor that’s part of the Microsoft Root Certificate Program. Windows 7 clients automatically trust their third-party certificates, eliminating a source of hassle for the JOAT. This trust path is updated via Windows Update Services.
I’ve seen issues with using Server Gated Cryptography [SGC] certificates or when SGC certificates are part of a trust chain. Avoid buying these certificates and keep them out of your chain of trust. Two threads in the Microsoft TechNet RDS Forum—one on Windows 7 and one on Windows Server—discuss this issue further.
You can use self-signed certificates for testing. In many cases, you’ll have to customize the certificate’s common name to suit your needs. One example is with a farm certificate. You’ll need the certificate’s common name to reflect the farm name, not the names of individual servers in the farm as it does by default. A simple program like SelfSSL can help here. There’s information in the Resource Kit on how to do this.
Shields: VDI is a hot topic these days, and many of the new RDS features are VDI-focused. When does VDI make sense for the small environment?
Griffin: VDI can solve a number of problems, like providing access to applications that won’t run on Windows Server 2008 R2. For example, use VDI to create a pool of Windows XP VMs [virtual machines] for running incompatible applications. You can also use VDI to replace physical desktops and move them to a centralized location. Doing so gives the JOAT new abilities like snapshotting, a feature that can revert a VM to a previous working state. This is useful if something goes wrong during an update or application upgrade. New desktops can also be easier and faster to deploy in a virtualized environment as opposed to a physical one.
Anderson: I agree VDI is a hot topic. For the small business, VDI makes sense for moving existing desktops into the datacenter. This is particularly useful when those desktops run applications that depend on a legacy OS. It’s also handy when users need to install their own applications and ActiveX controls. VMs are most applicable in small environments with frequent changes, since virtualization enables much more agility through centralized management.
That said, small environments should strongly consider sessions as their first option. Sessions enable greater user density along with all the benefits of virtualization.
Shields: Is VDI a direct replacement for RDS?
Griffin: This is a common misconception. No, VDI is not a direct replacement for session virtualization—what people think of as traditional RDS. VDI is a new component of the RDS role.
VDI offers desktop virtualization, while the RD Session Host server role service offers session virtualization. VDI is best in specific instances, while in many cases RDS session virtualization may be the better option for providing application access. You need to fully understand what each solution offers in order to fully utilize the technology in the most fitting way.
For example, it makes no sense to provide all users with personal virtual desktops if all they need is access to an application that runs fine on RD Session Host.
Anderson: It’s definitely not a direct replacement. VDI is part of RDS. RDS is a complete desktop-virtualization solution, including session virtualization, desktop virtualization, methods of user discovery and WAN access. That means VDI is not always the obvious choice over using sessions.
For one thing, you’ll get a lot more users on the same server with sessions than you will with VMs. Therefore, sessions are the more cost-effective approach. This is why it’s so important to lead with your goals. Doing so means applying the right technology, rather than trying to fit business goals into a technology plan.
Shields: How can RDS help with my Windows 7 upgrade plans? Where would it fit best?
Anderson: If you’re virtualizing Windows 7, then you don’t need to upgrade your hardware to get all the features of Windows 7. If you plan a hardware refresh but have one problem application, use RemoteApp for Hyper-V to deliver that application. The nice part about RDS is that it makes it easy to blur the line between what’s local and what’s remote. You can integrate elements of both into a single workspace.
Griffin: We all know the story about wanting to move to Windows 7, but you have that one pesky, yet necessary, application that won’t run on the new OS. Maybe it only runs on Windows XP. You could use the Windows 7 XP mode to solve the problem, but now you’re dealing with two separate OSes. Some hardware doesn’t even support Windows XP mode or is incapable of running it with good performance.
An alternative is to implement pooled VMs via VDI and give users access to the Windows XP environment when it’s needed. You could even implement RemoteApp for Hyper-V and blur the lines between the Windows 7 and Windows XP environments. When you do, the Windows XP application is presented as a RemoteApp and integrates directly into the Windows 7 desktop. RemoteApp for Hyper-V is an interesting tool not many people know about.
Between the Pages
Shields: You recently released the “Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit.” Let’s talk about writing the book, the lessons you learned and the parts of RDS that you now appreciate more—or less.
Anderson: One of the interesting things about working on a [Microsoft] product group is that most of us work on specific features. So we know everything about one piece of RDS, but don’t know the inner workings of the others. Working on a book like ours is a terrific way to see the whole picture. I’m grateful for all the experts who gave us details on all those other features.
You use a lot of the features in RDS when writing a book. I don’t like working in the server room if I can avoid it, so RDS let me do the work elsewhere. RD Gateway is my personal favorite. I could access our test lab from the coffee shop when I was working weekends.
Griffin: I learned more about RDS from writing the book that I think I ever would have with regular research. There’s nothing like looming deadlines to make you dive in deep. This may sound funny, but I think I appreciate the Event Logs much more than ever. They really helped me troubleshoot my own issues when testing out the product. For those of you not familiar with the RDS event logs, take a look at the entire series you’ll find beneath Windows Logs | Applications and Services Logs | Microsoft | Windows | Terminal Services.
Like Christa, I also have a special appreciation for RD Gateway. The secure remote access it provides is fantastic, and setup is easy. The granularity of Connection Authorization Policies [RD CAPs] and Resource Authorization Policies [RD RAPs] gives the JOAT a lot of control over who gets access to certain resources. RD Gateway’s enhanced interaction with Network Access Protection makes it even more robust.
Shields: Now that you’re through with the book, can you tell us your No. 1 tip or trick that will absolutely improve the lives of an RDS admin every day?
Anderson: Buy the book. We spent almost a year testing, talking to the product group and those in the field. We also read everything we could get our hands on to help create an approachable but comprehensive guide. So the book consolidates a lot of knowledge and experience.
The best single piece of advice is to think first about what you want to accomplish. Then, create a design that accomplishes those goals. Only at that point should you dive into the details of how to implement that design.
Many people think first about the implementation part, but doing so creates unnecessary work. For example, if high user density is your goal, don’t start by investigating how to reduce your VM memory footprint. Instead, determine whether sessions will work for your user load. If they do, you’re done and you’ve got high user density. Laziness can be an underappreciated virtue.
Griffin: I tell everyone not to be afraid of this product. Its implementation is easier than you think once you understand how the pieces fit together. There’s no better way to learn than by setting up a test lab and getting your hands dirty.
That said, don’t skip the reading material and expect the product to implement itself. Do your homework. Understand what each RDS role service does, and which ones you’ll need for specific use-case scenarios. RDS relies on other technologies as well. While you learn RDS, read up on technologies like SSL certificates, Network Load Balancing, Round Robin DNS, roaming and mandatory profiles. If you already have the product up and running, use those event logs to help you troubleshoot issues. Finally, the Microsoft TechNet RDS Forum is a great resource for free help.
.jpg "Don Jones")
Greg Shields,* MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.*
Related Content