Use Windows Azure for RD Gateway, with your own domain name on port 443.

Prologue

2 and a half years ago, I struggled to create a remote desktop web/RD Gateway lab with Windows Azure. This took an inordinate amount of time, at the time. I think I got it to work, not because I knew what I was doing, but because I just got lucky. Since that time many people have asked me how to set it up. I have been committed to document my steps, recreating the setup. Fear of not being able to create my gaffe, has stopped me from tearing down my beautiful mistake, to teach myself how I did it.

That day has finally come. I hate letting the cat out of the bag early, but I found it’s what you know, initial to the deployment, which dictates weather you will succeed. So, without adieu, let me spill the beans.

Concept

Setting up remote desktop gateway, on windows azure, is a lot like setting up the scope on your favorite rifle. However, there are three points of reference, creating a likely-hood, which all three may not line up. Those variables are the “location” embedded into the VHD, the location as designed by your vitual network, and your designed affinity. Huh? Don’t worry, I explain.

Sight location designations matter

First thing, before you create a VM, you need to set your network up. This is not as bad as is seems, because you can delete your VMS, leaving just a VHD, and delete your network completely. You may re-design it (the network), and then re-create your VM, using the new network, and old VHD, in minutes.

Here are the rules you need to know for this to work:

  1. Once you create a VM, it has a “site stamp” location associated with it. (WEST, Central, Asia, ETC…)
  2. Once you create an affinity group, it will have a site location hard coded into it.
  3. Your internal network (or are you using a virtual network because it has a location component as well) has a location built into its design. FYI, focus on the virtual network. you will not use the internal network here.

Limiting statements and overview

Due to the fact the complexity can exponentiate on your deployment very quickly, I want to eliminate the pain points for you, so you get up on your sea legs, before going to slay multi-site monsters at your whim. It’s best to start off with a straight line, single site deployment, then you can experiment.

The only things you need for your simple RDweb/Remote gateway deployment are the following.

  1. Create an Affinity group, knowing what location it resides.
  2. Do not check any check boxes for site to site or site to local networks. The virtual network is all you need to worky about or work on.
  3. The VHD, if you had already created it, has a location. You must create your affinity group, to point to the same site as where your VHDs reside. Otherwise, you must physically move the VHDs to the other site, or delete it and create your server OS to be on the same physical location as your affinity group.

 

 

Situational example

I have created a Domain controller and another machine and have deleted them. I kept the VHD files and I have wiped my entire azure environment, because things got messed up and I have to recreate my Remote Desktop Gateway, with RD web installed on my domain controller.

Starting with pre-existing Virtual machines means I am starting behing the 8 ball. These VMs are all homes in Us West. This means my network must be created for west.

The very first step in the new deployment is, you have to create an affinity group first. This is just something I learned the hard way.

So first go to settings-> affinity groups and make an affinity group

1

You can see my mistake that would prevent any of this from working. See one says South Central and the other says West US. West US is broken, and needs to be re-created. Which one would I use? Yes, the South Central will never work, due to my pre-existing VHDXs.

2

Here is the correct affinity group for my exisiting VHDX files-

2

When you create your virtual network, as I said above, no check boxes. The DNS server is even blank, to this point in my deployment, and all the remote connectivity works. Choose Networks->New->Custom Create-> And just get your virtual network subnet, and use the correct Site location:

3

 

Once you have completed this step, you may now create your virtual machine. In my example, I am showing you how to re-attach your old vm, however you may use the gallery to create a new virtual machine as well:

Choose- New-from virtual machine tab- -> choose virtual machine->From Gallery

5

 

If you have any existing VHD files, the choice will by my Disks:

6

 

Otherwise, just choose an OS

7

Fill out the configuration:

8

Move to last page-This is where you add your port 443 for access, I added TCP 443 for HTTPS, and UDP port 3391 for RD Gateway.

9

 

This last page is where the mistakes happen. Notice the region, affinity group above/below? This needs to match the network you have created. Recall, I had you create your own name for the affinity group. Here is why; this is where it shows up. See local 2015 US West? This is the item that needs to match the VHD, and the network I created. As you can see, this is an easy slip, and difficult to understand how they tie together, when you first set these objects up.

10

Finally, if you did everything correctly, you will have a virtual machine. Set up RD Gateway and RD WEB, the way you find on basic instructions online. There is no fancy work here, just have a Domain controller, and a second VM for the RDgateway and RD WEB role.

11

 

Now we run into some other possible issues, depending on where you install the roles. I will simply provide you with a difficult to find link. If you are using RD Web in a gateway or on a Domain controller or Workgroup, you will face additional permissions issues, which should be remedied by this article entitled:

Guidelines for installing the Remote Desktop Session Host role
service on a computer running Windows Server 2012 without the
Remote Desktop Connection Broker role service

This KB http://support.microsoft.com/kb/2833839, Doesn’t work in IE, at least for me. This is important text so i will include the important steps here.

KB Excerpt

  • If the Server is a domain controller– If the system is a Domain Controller, add the Domain Users group (or the specific list of users) to the Allow logon through Remote Desktop Services local group policy. To edit the local group policy object setting, follow these steps:
    Open GPEDIT.MSC
    Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies and then click User Rights Assignment.
    Double-click Allow log on through Remote Desktop Services and then click Add User or Group.
    Type the user account, click OK and then click OK
    Close the Group Policy Object Editor.
  • Add the users you want to allow to connect to the Remote Desktop Users group.
    For example: Domain Users. (On DC this will be in Built in groups)
  • Configure the Remote Desktop Session Host role with to use the local Remote Desktop Licensing server. Follow these steps:
    1. Open an elevated Windows PowerShell prompt
    2. Type the following command on the PS prompt and press Enter:

      $obj = gwmi -namespace “Root/CIMV2/TerminalServices” Win32_TerminalServiceSetting
    3. Run the following command to set the licensing mode:
      Note: Value = 2 for Per device, Value = 4 for Per User

      $obj.ChangeMode(value)
    4. Run the following command to replace the machine name with License Server:$obj.SetSpecifiedLicenseServerList(“LicServer”)
    5. Run the following command to verify the settings that are configured using above mentioned steps:$obj.GetSpecifiedLicenseServerList()

      You should see the server name in the output.

Final Reflection

This  is at least the snapshot of what I wanted to convey, as the Azure lab is very nice, when you can connect to it, on port 443. This means you can use it just about anywhere. Other things you will need, of course, are a domain name. I use godaddy for my domain name. for no additional charge, you can go into the godaddy GUI, and add the public IP of your RD Gateway server, to an A record. You will then use Remote.domin.com/rdweb to connect.

There is a lot of mis-information on the internet about this setup. All you need to set-up remote access to your azure, is the RDWEB, RDATEWAY and the licensing role, which you wont need to license anything, unless you plan to have an hundred people logging in. Avoid all the session collection stuff around, unless you really need terminal services Sessions. Mine is not a session based install. This is just installing the roles, configure the gateway with a certificate, and use the name “remote.domain.com” to connect to it. I will share one missing item on many set up documents. After you configure RD gateway, you will need to add the TSRAP and TSCAP policies, add your cert, and then your done. There is one last item, add your Remote Connection string to IIS:

  • Start run Inetmgr
  • Default Web Site->RDWEB->Pages
  • Application Settings-> Default TS gateway
  • Add your remote connection FQDN here as well as in DNS

14

 

That’s about it accept details

 

Details

Godaddy Domain is about $5 if you get a cheap name like .info and the Cert, you will want to do a little shopping. There have been single name certificates out there for $5 as well. Here is an example of my DNS, pointing to my Azure RDWEB:

 

13

I hope this has been helpful and I hope you are able to use this if you get stuck in your setup. I definitely had some tough times setting mine up, but it is very nice, now that i can connect from anywhere!

 

References for setup assistance for RDGateway.

http://www.maijen.nl/?p=122

https://support.microsoft.com/en-us/kb/2833839

https://technet.microsoft.com/en-us/library/Dd983941(v=WS.10).aspx