Deploy Remote Desktop Services in a Workgroup or Domain Easily!


Update 10/9/2017

This article was the underlying document the post came from. Notice at the bottom it is valid for 2016 as well!

Applies to

Windows Server 2016 Datacenter, Windows Server 2016 Standard,
Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard,
Windows Server 2012 Datacenter, Windows Server 2012 Foundation



For all you Terminal Server or Remote Desktop Services or RDP Geeks out there, Let me spend a minute to clarify a call driver that continues to be popular.

The Scenario is deploying Remote Desktop Services in a work group. Call this a corner case, or call it what you will. The reason this is a popular support call is due to the fact that there are two articles needed to complete the setup.

Oh sure Microsoft does tell you to add a policy after your setup, but they specify you use GPEDIT. not much help there… Until Today!

First you need to Deploy the roles correctly. The Specific KB I chose for this article, is the one you would use for the simplest setup. One that keeps you clear of very common mis-steps of walking through the setup in the Server Manager. If you did your deployment correctly, you didn’t even need Server Manager.

So begin by reading this:

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

“”RD Session Host without the Connection Broker

To be clear about this deployment:

  • No Domain Controller
  • No Hyper-V
  • Install Remote Desktop Services.
  • You won’t get to select more until the end. You may install the following
      1. Remote Desktop Licensing and
      2. Remote Desktop Session Host
      3. RDWEB
      4. RD Gateway
  • For a work group you do not have to add the Terminal Server to the Terminal Server License server group. Why? With No DC, you don’t have to report to anyone.
  • Activate the Terminal Server using one of the three methods.. This is most common
  • Activate your RD Cal Licenses with KB2833839 or cc725890

So Far, so good. Now this is where we start to diverge from some existing Documentation

  • If you are in a work-group, go to “edit local users and groups”
  • Find the group folder and create a group for your RDP users and add your users to this group.
  • Alternatively, you may add your users to the RDP users group already there
  • Remember the group you are using. It becomes important
  • Now you are going to edit the Local Policy by doing the following:
      1. Start and Run GPEDIT.MSC
      2. Navigate to the following:

Local Computer Policy ->Computer Configuration-> Administrative Templates-> Windows Components-> Remote Desktop Services-> Remote Desktop Session Host-> Licensing

Figure 1. GPEDIT.MSCUntitled

You are going to see now, the two LSO (Local Security Object) you will be enabling.

Use the Specified Remote Desktop License Servers –Value- IP address of RD License Server.

Set the Remote Desktop Licensing Mode- Value – 2 or 4. 2 is for Device CAL and 4 is user Cal.

Figure 2. Local Policy. Untitled

Now there is another Policy to set. For this, you want to just go back to the top. Start out at Local Security policy like before (GPEDIT.MSC).See figure 3.


Figure 3 GPEDIT.MSCimage


Expand Computer –>Configuration,–> expand Windows Settings, –> expand Security Settings,–> expand Local Policies and then click User Rights Assignment.




Enable this policy and add the group you used earlier. It is highlighted in this article above. Add this group to this policy. In addition, add the Remote Desktop Users group to this policy if desired. Don’t and your administrator name here. The Admin already has access. If you ad your admin name, it will lock you out. So best to to stick to adding the Remote Desktop users group.



Notice it says administrators (Plural), that is fine, but the single administrator should not be in this list. there is a well known break here if you do that.  When you are finished, you just need to add the users you want to give access to, to the group we just added to the Policy (likely the remote desktop users group)

Step 8 comes right out of the KB2833839

  • Open an elevated Windows PowerShell prompt
  • Type the following command on the PS prompt and press Enter:
    $obj = gwmi -namespace “Root/CIMV2/TerminalServices” Win32_TerminalServiceSetting
  • Run the following command to set the licensing mode:
    Note: Value = 2 for Per device, Value = 4 for Per User
  • Run the following command to replace the machine name with License Server:
  • Run the following command to verify the settings that are configured using above mentioned steps:
    You should see the server name in the output.

You have now covered all your bases, and  your RDP should be happy!! It will be happy because you paid attention to all the rights things!

Now I did find an interesting article to which I cant really comment on. However, it is an interesting article. IT deals with some issues, you could run across.

Based on a comment to this article, I want to address this KB    “Best practices for setting up Remote Desktop Licensing (Terminal Server Licensing) across Active Directory Domains/Forests or Work group”

This is where it tells you not to use a work group server. So Please consider this against this KB_

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

One article says don’t use a work-group. The other says “This server can be part of a work-group or may be configured as a DC.” Which do you believe? They are both true. Microsoft does not want you to use it in a work-group, but you can because they provided a way for you to do it. The cost? Printer Redirection issues, and a few other small things, but you can do it if you need to. Bottom line is Install your Terminal Server in a Domain. But, If you have no other choice then use a work-group if you have to.


Well That is it. I hope this has been helpful for work groups or non-work groups. this basically  can be set up on either.




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


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.


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


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.


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


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:



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



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



Otherwise, just choose an OS


Fill out the configuration:


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.



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.


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.



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, 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:
    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

    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 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 “” 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



That’s about it accept 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:



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.