- Table of Contents
- Introduction to the Reference Guide
- The New Itinerary for Windows Server 2008
- The Registry
- Domain Organization
- Executing the Migration Plan
- Resource Management
- Security
- Networking at the Link Level
- Network Applications
- Issues with Exchange Server 2007 and Outlook 2007
- Using PowerShell to Track Exchange Troubles
- Sewing Exchange 2007 Back Together with PowerShell
- The DNS Menace
- Internet Information Services
- The Perils of Anonymous Access
- Comprehending the Architecture of IIS
- The New Architecture of Terminal Services
- Making Terminal Services Work Without Getting Too Terminal
- Putting Local Applications on Remote Desktops
- Building the Web Site Gateway
- Establishing a Catalog for an IIS Web Site
- POP3 and SMTP Services
- Books and e-Books
- Official Documentation
- SharePoint Portal Server 2003
- Presence
- The Presence of Live Communications Server 2005
- Office 2003 Deployment
- Windows Management Instrumentation
- The Dawn of Windows Server 2008
- Windows Server By Command
Making Terminal Services Work Without Getting Too Terminal
Last updated Jul 25, 2008.
Terminal Services was a feature that some businesses used, though not too many, and that was getting a bad rap for being antiquated in the face of virtualization. Then Microsoft improved it, and that started waking people up.
But the improvement, like so much else that Microsoft has done, took place through a series of add-ons. As a result, there’s no one obvious place, no one reasonably memorable sequence, or not even one exhaustively comprehensive wizard to enable you to set things up exactly the way you need. As it turns out, there are several places you have to go in Windows Server 2008, a few of which will throw you for a loop, and some of which don’t necessarily have to be visited in sequence.
Straightening Out the Certificates
Getting Terminal Services onto your OS is straightforward enough. There, you do go through the Add Roles wizard, and one of the steps you’ll see there has to do with certification. For Terminal Services Gateway to work, it needs access to Secure Sockets Layer, which means it has to encrypt the connection, which means in turn that it needs a valid certificate to sign the encryption.
At this point, you truly should have an SSL certificate issued to you by a legitimate and recognized signing authority such as VeriSign. When you’re testing a Windows Server setup, you do have the option during setup to install Certificate Services and also to create your own self-signed certificate; but the problem there is, none of your Web browsers (not even the one on the same system as your Terminal Server) will recognize your self-signed certificate as legitimate automatically. You have to force your Web browsers to recognize “yourself” as legitimate.
You’d think the place to do that would be Certificate Services. Actually, it’s IIS7. From here, you’ll want to export your self-signed certificate so it can be imported not only by your test clients’ Web browsers, but by your server’s Web browser as well. Here’s what you do:
- From the Connections pane at left, choose the server from which Terminal Services is running.
Figure 1 The panel from Internet Information Services from which you make sure you have a certificate with which to encrypt and sign your connection.
- From the Home pane at center, under IIS (it’s nice that IIS has a section called “IIS,” isn’t it?) double-click on Server Certificates. The center pane becomes the Server Certificates list.
- Your self-signed certificate, created during the Add Roles wizard process, will not have a Name. In fact, that’s how you may be able to identify it. The Issued To and Issued By authorities will be identical. Choose this nameless entity, and from the Actions pane, select Export.
- In the Export Certificate dialog box, make sure you click on the ellipsis (...) button because there’s something you’ll want to make sure of. When the Specify save as file name appears, in the extension box beside the File name field on the bottom, choose .pfx. Then enter a file name into the field and click on Open (you’re not really opening anything; Microsoft simply forgot to change the name of the button).
- In the two password fields, enter a memorable password. This will be used to secure the private key that is shipped along with your certificate; you need the .pfx format in order to include this password.
- Click on OK. At this point, you’ll have a file that you can distribute to your clients, for a self-signed certificate that can be used for testing purposes. Your client Web browsers may need to import this certificate later, and we’ll walk you through that too.
Giving Remote Users Permission to Log On
The next non-obvious process you’ll have to undertake is making certain you have a group policy in place that enables your intended clients to log on. Here’s what you do next:
- From the Administrative Tools menu, select Local Security Policy.
- In the Local Security Policy window, from the left pane, under Security Settings, choose Local Policies, followed by User Rights Assessment.
- In the right list, double-click on Allow logon through Terminal Services.
- In the dialog box, click on Add User or Group.
- You probably already know how to use the Select Users or Groups dialog box, if you’re a veteran of Active Directory. Be sure to enter only the names of folks or groups whom you intend to enroll later as remote application users.
- Click on OK to finalize your addition.
You want to be able at this point to attach your supposedly valid signing certificate so that you can both certify and encrypt the RemoteApp connection. The only problem is, there’s a good chance Windows Server doesn’t yet recognize the certificate as valid.
Strangely enough, the place where you solve this problem...is Internet Explorer. Like I said, this process isn’t exactly self-evident. Here’s how this works:
- From the menu bar of Internet Explorer, select Tools, Internet Options.
- In the Internet Options dialog box, in the Content tab, under Certificates, click on (appropriately enough) Certificates. The Certificates dialog box will appear, to your astonishment.
- You’ll want to click on the Trusted Root Certification Authorities tab, the full title of which may be covered up on the right side. If the certificate you intend to use to certify your server as valid is not in that list, then you’ll want to import that certificate you just exported. So click on Import.
- Enjoy the warm welcome from the wizard you didn’t expect to see, then click on Next.
- In the next panel, click on Browse. Locate the .pfx file you exported earlier from the Open dialog box, then click on Open (which this time around means “Open”).
- Click Next.
- In the next panel, enter the password you created earlier for the private key, then click Next.
- Make sure the field in the next panel reads Trusted Root Certification Authorities, then click Next.
- To finalize your settings, click Finish.
For each of your clients that’s using Internet Explorer, you’ll want to repeat this exact procedure for importing your server signing certificate.
References
- “Terminal Services Gateway.” Documentation from Microsoft TechNet.
- “Remote Access for Windows Server 2008” by Tony Northrup. Article from BizTech magazine online, published by the IT retailer CDW.
Books and E-books
- Mancuso, Paul A.; Miller, David R. MCITP 70-622 Exam Cram: Supporting and Troubleshooting Applications on a Windows Vista Client for Enterprise Support Technicians. Exam Cram Press, 2008. Preview “Configure and Troubleshoot Security for Windows Internet Explorer 7” from Chapter 2, “Managing Windows Vista Security,” on Safari.
- Cowart, Robert; Knittel, Brian. Special Edition Using Microsoft Windows Vista, 2nd Edition. Que Corporation, 2008. Preview “Customizing the Browser and Setting Internet Options” from Chapter 15, “Using Internet Explorer 7,” on Safari.





Account Sign In
View your cart