John Howard - Senior Program Manager in the Hyper-V team at Microsoft

Senior Program Manager, Hyper-V team, Windows Core Operating System Division.

Terminal Services Gateway and Terminal Services Web Access using Hyper-V (Part 2)

Terminal Services Gateway and Terminal Services Web Access using Hyper-V (Part 2)

  • Comments 9
  • Likes

Part two of my weekend project involves a little reconfiguration of my ISA 2006 Server to allow RPC access to the Terminal Services gateway running as a virtual machine under Hyper-V beta. There’s really three rules involved in the ISA server – one to forward the RPC traffic, and two for the TS Web Access. If you followed my series of blog posts a couple of years back to get Exchange published through ISA, the process is very similar as I wanted a forms based authentication mechanism. This post focuses on the RPC traffic rule.

(Of course, my ISA server too is a Virtual Machine, but running under Virtual Server 2005 R2 SP1 rather than Hyper-V. I’ll be gradually moving all my test infrastructure across to Windows Server 2008 and Hyper-V over the next few months.)


The ISA rule is concerned with RPC over HTTP(s) traffic to make sure it gets routed from the external network (ie the Internet) through to the Terminal Server itself.

ISAConfig1


The rule is using an external listener on port 443 (HTTPS). I already had a certificate issued from my Certificate Authority for my external domain name (the machine to which users connect to externally).  The basic configuration, tab by tab as shown in the ISA rule is:

  • General:  Just a name you choose
  • Action: Allow
  • From: External
  • To: DNS name of the internal machine with requests appearing to come from the original client
  • Traffic: HTTPS
  • Listener: An external listener on port 443 using a certificate issued matching the external DNS name
  • Public Name: Requests only for the appropriate external name
  • Paths: External Path <same as internal>, Internal Path /rpc/*
  • Authentication Delegation: No delegation, but client may authenticate directly
  • Application Settings:  Defaults
  • Bridging: Redirect to SSL on port 443 (In other words, we use SSL to connect from ISA to TS)
  • Users: As required
  • Schedule: Always
  • Link Translation: None.

In other words, this rule says “Any 'https://externaldomain.com/rpc/<whatever>' requests should be forwarded to the TS gateway machine using an SSL connection between ISA and the TS gateway”.  All being well, let’s see what the user experience is now… remote desktop over the Internet.  From a client machine (Vista SP1 in my case), start "mstsc /console" and drop down the options. On the general tab, enter the internal DNS name of the target machine to connect to (the TS gateway in this example)

mstsc1


Now switch over to the Advanced tab and click on Settings under the “Connect from anywhere” box. Select “Use these TS Gateway server settings” and enter the external DNS name of your external ISA listener on the Internet. Note that I have de-selected “Use my TS Gateway credentials for the remote computer” to allow me to authenticate to the TS Gateway as myself, but authenticate to the machine I’m logging onto with a different account.

mstsc2


Now click connect. At this point, you are prompted to provide credentials to authenticate to the TS gateway. Remember in the previous post, I made sure a domain group of which I’m a member of is allowed access, so here I enter my own logon details.

mstsc3


Next you are prompted to provide credentials to logon to the remote desktop. In this example, I’m logging on to the TS gateway using the “TSAdmin” domain account I created earlier.

mstsc4


And there you have it. Here’s the desktop of the TS Gateway machine connected over the Internet running TS Gateway Manager monitoring connections. Here you can see I’m connected.

mstsc5

Cheers,
John.

Comments
  • PingBack from http://www.mydomains.co.cc/terminal-services-gateway-and-terminal-services-web-access-using-hyper-v-part-2

  • Sorry for the dearth of posts - I have been rather busy lately.&#160; As such I thought I would quickly

  • Sorry for the dearth of posts - I have been rather busy lately.&#160; As such I thought I would quickly

  • I am curious as the TS RemoteApp website is https://externalname.com/TS why your Web Publishing rule only provides for /RPC/*.

    You initially stated you created three rules for everything to work but then you only detailed the creation of one.   Could you please clarify this?  The Step-By-Step Guide for TSG only details one rule and I've not had success yet with that one rule.  Is it three? If so what are the other two?

    TIA - Dale

  • Dale - take a look at my blogcasts from a couple of years back for publishing Exchange RPC/HTTP. They have all the detail you need and are for bouncing the FBA through a seperate subnet and listener.

    Thanks,

    John.

  • Hi,

    if I publish /RPC and authentcastion to authenticated user it is not working but when I change it to all user it stated working,Can u pls help me here.

  • Arvind - as I put in the caveat to part 1 http://blogs.technet.com/jhoward/archive/2008/02/09/terminal-services-gateway-and-terminal-services-web-access-using-hyper-v-part-1.aspx, I would need to redirect you to an ISA/TMG discussion forum to get you an answer. http://social.technet.microsoft.com/Forums/en-US/categories is a good place to start.

    Thanks,

    John.

  • Hi John,

    It is my understanding that for security reasons TS should be inside the firewall and TS Web Access has to be outside.  Is it reasonable/worthwhile to put TS on the core system (2008) and TS Gateway & TS web Access on a virtual machine on the same physical server thus avoiding to have to build two separate physical servers?

    Thanks a lot

    Regards,

    Artur

  • Artur - TBH, you are better off asking this question in a forum specific to TS (- as per the caveat in part one). http://social.technet.microsoft.com/Forums/en/winserverTS/threads would be a good place to start.

    Technically, with two physical NICs, you can create this configuration in VMs by having two seperate "external" networks (from a Hyper-V perspective), each one bound to one of the physical NICs. (But you should also have a third NIC for management of Hyper-V).

    Thanks,

    John.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment