Remote Desktop Services 2016, Standard Deployment – Part 10 – Useful Tips

When we are designing our RDS environment we have a few things to take care of before we even start to install RDS roles and configure them.  In this part we will discuss about those things like role placement or rds domain vs. workgroup and a few other things that a lot of users have problem with. I will talk about those questions that I receive the most.

Let’s get started.

RDS 2016 REQUIREMENTS

I received a lot of questions regarding RDS in a workgroup and what are the requirements for RDS 2016? The only requirement is a domain membership. Remote desktop services are designed to be joined to a domain where we have at least one RD Connection Broker and that RD Session Host servers are managed as a collection using Server Manager or if you are a powershell guy you can configure everything with powershell. Now I am not saying that you can’t run RDS in a workgroup but preferred way is to join servers to a domain. If you want to run RDS in a workgroup you will need to install RD Session Host and Licensing role and create local users which will connect to the server. Next you will need to use local group policy to assign the licensing server and session settings like idle time or log off and WMI, registry settings to manage rds in a workgroup. It is much harder to administer rds in a workgroup. RDS environments using workgroup mode are less and less and I recommend domain joined. For example a single license of Server 2016 Standard will allow you to have Server 2016 installed on the physical machine with Hyper-V, and two VMs running Server 2016. Next you can install one VM as a domain controller and second VM you can use for RDS.

 

RDS 2016 ROLE PLACEMENT

Next very important part is where should we place the RDS roles? It all depends on the environment, requirements and applications that you are going to run on those hosts. Role placement in standard deployment can be like this if you want to minimize servers:
Example:
     RD Connection Broker –> 1 VM
     RD Session Host –> 1 VM
     RD Web Access + RD Gateway –> 1 VM
     RD Licensing –> RD Licensing uses very little resources so from that standpoint you can put it wherever you want. In general, you want it to be on a separate server from your RDSH servers, and putting it on a DC is often a good choice. You want RD Licensing to always be available for when users connect and that description fits well with a DC. This is the only RD Role that should be installed on a domain controller.
Many users are asking me about role placement and if connection broker, session host server or other roles should be installed on a DC. THE ANSWER IS A BIG NOOO. Never place session host role (or any other rd role, except licensing) on a domain controller. You don’t want users to login on a domain controller and you definitely want to avoid installing 3 –party software’s on it.
Regarding Connection broker on a DC. I am not sure if this can be even done in 2016 (I would never recommend it and because of it I never tried to install it on a DC) and if you try it, you will find yourself in a big trouble with a lot of errors. There was a hotfix that we could install on windows server 2012 R2 that allowed broker – dc relationship but that is a big no. RDCB and DC don’t like each other and please avoid this scenario. If you need to configure RDS for a small office, then install everything on one server but never on a domain controller.

 

UPGRADE FROM RDS 2012 R2 –> RDS 2016

I am not a fan of an in-place upgrade but if you need to upgrade your environment this way the only supported scenario is if you are running 2012 R2. Be sure to have a backup before you continue. If you are running RDS 2012 then you will need to upgrade it to 2012 R2 and then to 2016. Keep in mind that roles should be upgraded in the following order:

• RD Connection Broker should be upgraded first. Reason for this is that RDS is only backwards compatible which will give us option to run RDCB in 2016 and rest of the servers in 2012 R2 but not vice versa. You cannot connect session host that are 2016 to 2012 R2 connection broker. If you are using RDCB HA then all servers should be upgraded in the same time. The deployment will not be available during RD Connection Broker servers upgrade.

 

• RD License server should be upgraded second before we upgrade Session Hosts and it is because RD Licensing server can host licenses from all previous versions of Remote Desktop Services and the current version of Remote Desktop Services but not the above. If you have RD Licensing server that is 2012 R2 it can host CAL’s up to 2012 R2.

 

• RD Session Host servers can be upgraded next. If you want to minimize downtime you can log off all users, block new connections on the hosts and remove hosts that you want to upgrade from the collection. When you are done with the upgrade add that host to the collection. If you have 2 hosts you can first upgrade one with this process and when you are done proceed with the next one.

 

• RD Virtualization Host servers is next one. If you don’t have it just skip this step.

 

• RD Web Access and RD Gateway can be upgraded anytime. Keep in mind that the Windows Server 2016 does not include Network Access Protection (NAP) policies – they will have to be removed. The easiest way to remove the correct policies is by running the upgrade wizard. If there are any NAP policies you must delete, the upgrade will block and create a text file on the desktop that includes the specific policies. To manage NAP policies, open the Network Policy Server tool. After deleting them, click Refresh in the Setup tool to continue with the upgrade process.

 

RENAME RDS SERVER 

When it comes to renaming RDS farm you will find yourself in not that easy procedure and many times re-building the RDS environment will be better and easier option to do. Keep in mind that there is no option to rename RDS servers in the farm, you will need to remove servers, rename them and add them back to the farm. The biggest challenge is the RD Connection Broker. There is no option to rename RD CB because it is the brain of the whole deployment and trying to do this will destroy the configuration. You will need to first get details about any customizations and settings, remove all the RemoteApps, remove all the collections, all roles from it and change the name of your RDCB and then rebuild everything so the process is really complex so I would recommend to rebuild the farm.

One scenario where installing the new farm may not be the option is when you have a lot of applications installed on the session host servers. Installing them on the new RDSH servers and configuring settings, permissions may be a very painful and long process.

 

RDS 2016 CONNECTION BROKER ACTIVE/PASSIVE MODE

In 2008, the RD Connection Broker role service has supported an active/passive clustering model. This provided high availability in the case of component failure, but it did not address high scale requirements. High availability for the Remote Desktop Session Broker has changed (improved) a bit in Server 2012. The Active/Active Broker feature in Windows Server 2012 eliminates the need for clustering and provides a fully active/active model; with this model two RD Connection Broker servers can be combined under a single DNS entry to provide both fault tolerance and load balancing. This prevents the RD Connection Broker server from being a single point of failure and also allows “scale out” as load demands. You will need to have sql to configure this. So there is no Active / Passive mode in 2016.

 

REMOTE APP AND SINGLE-SIGN ON (Users are being prompted for authentication again when clicking on the RemoteApps) 

I got a lot of questions regarding SSO with RemoteApps. To make this work be sure to add the RD Connection Broker server/s to RDS Remote Access Servers group on each RD Session Host server. If the certificate is not issued by a trusted public CA, the certificate must be imported into the Trusted Root Certification Authorities certification store on the client computer to be trusted by the client operating system.

The Trusted Certificate Authority Root’ certificate must be imported in the Trusted Root Certification Authorities certification store on the client computer and on the RD Session Host and RD Connection Broker machines. After that it should work.

If for some reason you need to digitally sign your rdp files you will need first to get the Thumbprint of the certificate. Open powershell as admin and run

Next to sign an .rdp file navigate to the folder where you saved the .rdp file, and then type the following:

 

If a RDS License server fails, is there a grace period for clients

There is no separate grace period provided apart from the one in the beginning ( that is already consumed in your case). If your RDSH is not able to contact the license server – the clients that are having valid license will not get connection denial even if your license server is down for some time. Only the clients that either have no license or have expired licenses, will face connection denial.

For each permanent Per Device CAL that is issued, an expiration period is applied. This expiration period is a random number of days between 52 to 89 days after the license is issued. The terminal server always attempts to renew these CALs seven days before they expire. This functionality facilitates the automatic recovery of Per Device CALs that are lost due to hardware failure, operating system reinstallation, and other, similar events.

Disable user profile disks for Administrator

This is not possible and I am afraid that this will be the same in Server 2019.

Speed Up RDS Deployment

We live in a time where automation is a must. There is no space for click-next and we must focus on automation. To create a deployment we need to run one-liner in powershell. It is much easier to run on command an to go through the wizard and click-next things. To do this login to server that will become connection broker and in powershell run

New-RDSessionDeployment -ConnectionBroker rdcb01.domain.com -SessionHost rdsh01.domain.com -WebAccessServer rdwa01.domain.com

Later I will post a script that install deployment, collections etc.. in once shoot. That will speed up RDS deployment and only thing that you need to decide is the server and collection name.

RESET Grace Period To defaults 

If you would like to view how many days are left open RUN and type in

TLSBLN.EXE

To reset grace period to default in a test environment delete the Reg binary in

(OBS!!! Before you can delete it be sure to give your admin account full permissions)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

Once done restart the RDS Session Host server. Now we have 119 days again.

Thanks for reading!

Cheers,

Nedim