Server 2012 setting up remote gateway, remote desktop and RemoteApp

Having set up lots of these using Server 2008 I thought this should be straightforward.  However the changes in Server 2012 make this quite a different process in some scenarios with some new limitations (as well as significant benefits too!)

There are quite a number of related components that all need installing, but can mostly be installed through a wizard provided you are on a domain.  This  post will describe a simple install where all components are installed on a single server.

One of the biggest differences is that Microsoft really now expect you to be joined to a domain for any of this to work.  Having said that it is still possible to install Remote Gateway and Licencing as in Server 2008 R2 (the old style GUIs for these are still there – but not used during a domain install).  What I have been unable to do is to use RemoteApp on Server 2012 without a domain.  This is managed via collections now and the tools to manage it all require you to be on the domain.

Microsoft also say if you are installing everything on a domain controller (i.e. a single machine)– you can not install the Connection Broker component (RDCB) as this will not work (not yet tested this scenario).

There is a good walk through of the process here so I won’t repeat that but will instead concentrate on differences I found.

Your server needs to be joined to a domain for this to work (it is possible to install the gateway by itself without a domain

Installing without a domain

Clearly this will only be of use for a standalone server. This can be done  using the Add Roles and Features directly – similar to Server 2008 – it is (eventually) a supported option in Server 2012 – see  This works for remote gateway – but not yet seen how to configure RemoteApps – in fact I’m starting to believe this isn’t possible anymore without a domain.



If not on a domain you can’t use the server manager interface to configure your new install as that requires you to be a domain member


But you can run remote gateway (as in Server 2008 under Admin tools) and configure from there:


Add a certificate

Its important that your FQDN name (i.e. the name you will access the server with e.g. matches the name of the certificate you use – otherwise you will get all sorts of certificate warnings and may setups maybe lock access as the certificate will not be trusted.  We have a wildcard certificate so we can use any subdomain we like pointe at the server.


Browse to the .pfx file and import it – entering the password when asked.

You must the setup a CAP and a RAP – but this is all the same as 2008 RS and well described here:

Setting up licencing without a domain

Microsoft really seem to want you to run this on a domain.

You can configure the licence server fine - and register your licences - but you can't configure the session host using the server interface if its not on a domain - which means you can't define the licence server of the licencing mode (user / device).

You can though use gpedit.msc to edit the group policy and set it in there:

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


  • "Use the specified RD license servers" = YourServerName
  • "Set the Remote Desktop licensing mode" = "Per User"

As a separate issue you may get the warning bubble saying "Remote desktop services will stop in xxx days"

This can be removed by removing the following key from registry HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Grace Period

You may find you have to grant ownership to that key to your Administrator before it will allow you to delete.

Installing on a domain

Nice description here:

and here

This install process is very different from installing with no domain.  The diagram below shows the components that are installed.  Fortunately the wizard does most of the work for you.


To install

1. In the server manager select “Add Roles and Features”


2. Select Remote Desktop Services Installation


3. Select Quick start


If it gives a message saying your server has been excluded due to compatibility issues then.

You need to ensure that  Powershell Remoting is enabled and also that it has enough memory to work with:

  • Start PS Shell as Administrator (right-click, Run As Administrator).
  • Run the commands:
    • Enable-PSRemoting –force
    • Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000
  • Reboot the server.

In my case I got away with just Enable-PSRemoting –force and no reboot

You should then be able to continue

Configuring remote gateway

Once the install has completed you are presented with a screen where the green bits need further configuration by clicking on it


You will need to enter the name of the SSL certificate.  This MUST match the name of the FQDN that you will access the gateway with and that will match your certificate.  e.g.

On completion you will be prompted to configure your certificate


This must be done once for each service


Until it looks like this:


Changing the FQDN to match the name of your certificate

Its essential that the name matches that of your certificate, or at least the domain element of it if using a wildcard certificate like *  For some reason Microsoft have removed the interface to control this – but fortunately it can bee done using a PowerShell script which can be downloaded from here: and then run from a powershell window:

.\Set-RDPublishedName "”
Note you may also have to elevate your powershell script permissions first:
Set-ExecutionPolicy RemoteSigned

Make sure your FQDN resolves on the server

As you have to connect using a subdomain name (e.g. that matches your signed certificate, there is an issue in that the can not be resolved on the server. So this needs resolving either by adding an A record into your DNS – or an easier way given we are simply dealing with a single server here – we can enter it into the hosts file (remember you need to open Notepad as Administrator so you can save the file back to its location)


Allowing users to connect

Users have to be given permissions to connect to RemoteApps and also to a specific RemoteApp collection.  Fortunately the wizard takes care of this for us and sets this to Domain users which is normally OK

However I still had problems connecting until I altered the Remote Authorization Policy (RAP) which is accessed via the Remote Desktop Gateway Manager in Administrative tools .  I found by default this was set as Domain Computers which meant a user couldn’t connect to the server.  Changing it to any network resource resolved this.


Licencing server

You should also set this up if this is more than a test server – though you have a90 day grace period to get this sorted so it won’t stop you getting going in a test scenario.

Setting up RemoteApp collections

You can setup a number of different “Collections” which can expose different RemoteApps to different users. By default a “QuickSessionCollection” will have been created – with 3 default apps to test with.

You can control who can access the collection etc using Tasks.

Adding or removing a RemoteApp to a collection is simply a case of pointing at the exe There are no longer pre prepared rdp files etc


User permissions

Must be member of Remote Desktop User

Also local security policy has to “Allow log on through Remote Desktop Services” – this was set for me on Gateway machine – but wasn’t on second server with Session host – I had to manually set this

Remote App permissions

If you are setting up your own remote Apps, make sure users have rights to execute in the folders on all servers – for some reason I ended up with Domain users having rights on one server – but not on a second.

Testing connections

You are now connecting over https – so you must have port 443 open both out of the client (which it usually would be) and inbound on the server.

If using RemoteApp you can connect by:

If you are wanting to create an RDP connection then make sure both the RDGateway and the server name are set to your FQDN (e.g.  Also remember to include the domain in your logon name.





Find out more