Remote Desktop Services 2016

A client has an existing 2012r2  server environment, with an existing Remote Desktop Services server in production (all published apps). I'd like to add a 2016 Server with RDS (full desktop) to test some new applications, but not sure of the best approach.
Additionally.... if these new applications don't work out as expected, we will want to remove the new server and leave as little trace  possible to the production environment.

I'm sure I can't use the existing licensing server (2012r2) for the 2016 RDS... and maybe other roles that the new 2016 RDS server can't use from the 2012r2 server? And maybe the whole idea isn't possible without upgrading the existing RDS  to 2106 for some roles? (or maybe the idea of introducing a 2016 RDS in to a 2012 production environment is just crazy, and will blow stuff up?)

I'm still reading up on my options... but input from those who've been there, and done that is very welcome.
1. Is it possible?
2. Recommended proceedure
3. helpful articles
4. Landmines to avoid

All is appreciated!
Who is Participating?
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
Use a Windows Server ISO from TechNet to set up the test environment. This along with RDS Trial Mode will give you a lot of time to test things.


Set up new AD DC VM, RDS Broker/Web/Gateway, and RD Session Host(s) in the new AD. Set up a VM with two vNICs to use as a router.

Set up internal DNS with with the IP pointing to the WAN IP of the router VM. Route 443 inbound to the Broker.

SSL the Broker/Gateway/Web ( using a third party trusted certificate. Make sure to export with Public Key to be able to re-use on the production setup.

Test. Test. Test.

Once satisfied, flatten everything and set up on the production network. Make sure to keep a copy of the certificate.

EDIT: Note, the test environment runs in a Private virtual network on Hyper-V.
Pushpakumara MahagamageVPCommented:
You need separate Server or Vertual server with windows server 2016. keep existing server as it is and allow RDS on new 2016 server. setup new applications on new 2016 server and test them. if test is success you can migrate your application server to new windows 2016.
Cliff GaliherCommented:
1) It is possible.
2) I *never* recommend testing on a love network. Between Hyper-v and Azure, there are options for a fully isolated test lab.
3) Many helpful articles. Care to be more specific?
4) Skipping wizards is a landmine. You're already running 2012 so hopefully you know this  but the newer broker architecture trips people up coming from 2008 and earlier.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

DrPingAuthor Commented:
Thanks PM... I intend to introduce a separate physical server as the 2016 RDS. But to test it I have to use their existing infrastructure.
My concern is the new server going to take over something on the domain, that's hard to fix if/when we take it out.
Like make itself the license server, or something?
(I don't know all the changes made by the wizard)
DrPingAuthor Commented:
Thanks CG... I'll try to clarify:

1. Thanks for letting me know it's at least possible (I really wan't sure)
2. OEM licensing on the production server, and strict licensing with the production application make a test lab very difficult, or at least cost prohibitive.
3. Helpful articles regarding the introduction of a 2016 RDS server into an existing 2012r2 RDS environment.
4. I don't know all the changes the 2016 wizard will make to the existing domain. I'm kind of afraid it will take control over a role that I'd hope to leave on the existing server (licensing for example)... and it may need to because I don't think a 2012 server can do RDS licensing for a 2016 server can it?
Cliff GaliherCommented:
1) seems covered.

2) if you only have OEM server licenses, then Azure is the way to go. As for the app, whatever restrictions prevent you from doing a proper test lab would almost assuredly also prevent you from spinning up a test 2016 server in the production environment. So I can't really see how you justify learning in a production environment.

3) Very few if any. Just because it's doable doesn't mean it's recommended. And almost everyone wanting to introduce 2016 upgrade their infrastructure first. Much easier to have older hits with newer infrastructure roles than the other way around. I only know it works because my azure lab is an intentionally a mix of VMs for testing various upgrade scenarios. And it's probably been 8 months since I did a 2016 collection with 2012 infrastructure backend roles.

4) RDS makes no changes to the domain that I am aware of. It uses a domain and wants one because of authentication and how the RDCB redirects. But the actual topology info is self contained in the SQL database to my knowledge.

As such, the wizard won't change existing things, but it'd want servers for the various roles it wants to install. You'd effectively have two completely separate RDS deployments by default. Introducing 2016 into the 2012 environment would be in larger part a manual affair.  See above about me recommend against this approach.

Spendign a little less but of money for VMs, whether Azure or Amazon or other that don't need to run (and therefore don't cost compute) when you aren't actively testing is a very inexpensive investment to plan your upgrade.
DrPingAuthor Commented:
Another thought about the test, and if this is possible....

Set up the new server (physical) as its own domain controller in it's own domain.
Create a VM for the RDS server (on the new server).
(Now the new server will have everything it needs in 2016 versions... not affecting anything on the production server)

Create users on the 2012 domain to test, and match those with users on the 2016 (same credentials)
I'm guessing if I can successfully map network drives, I can install the client applications to the RDS server.

This seems like a way to test without affecting the live server at all except as a network client.

Am I thinking right?
Cliff GaliherCommented:
Two problems with your plan. Don't make the host a DC. Do that in a VM.

I don't understand creating accounts in your 2012 environment to match accounts in your test environment. The while point of doing the 2016 DC is to give you that isolation. Take advantage of that. Never terms on a live environment. Not even partially. Not in any way, shape, or form.
DrPingAuthor Commented:
Thanks Cliff... I posted the previous comments, before I noticed you had new input.... and might be understanding my new idea is as bad as the old idea?

To clarify a little more:
Application licensing is controlled by dongles on the server (i said they were strict).
The existing RDS server doesn't host applications... it only acts as a network client... where client applications are installed to connect to the data server, and all applications are provided as published apps.

Adding a new and completely separate server with it's own DC and RDS to the network should be fine, and not hurt anything on the existing servers? And if I can get an RDS session to map drives to the existing data server... I can install the network clients and test the new server, and the only thing the existing server will see is a new network client... no RDS roles will have to be shared between the test environment, and the production environment at all?
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
If the software dongles are USB use Fabulatech's USB over Ethernet to redirect them into the test environment when testing. When production/live turn redirection off so that the dongles are present to the production environment.
Cliff GaliherCommented:
I think part of the problem is your mixing of terminology.  RDS hosts applications. That's what it does. But you say it isn't hosting applications.  Now in a client/server application, it may host the application client while the server is hosted elsewhere, but that isn't the same as not hosting an application at all.  Similarly, when you say the only thing the server will see is a new "network client"  ...that is also a rather vague statement as well.  Especially when you start talking about network shares which you've also mentioned.  QuickBooks is a great example of an application where the data file itself is simply on a network share, but for multi-user access, there is also a database component that must be installed and quickbooks makes connections to both.

Unfortunately there is enough vagueness and unfamiliarity that I can't guarantee good suggestions.

What I can say is that I stand by my initial assertion. Testing on a live network is *always* bad practice and I've never seen a justifiable reason I agree with in all my years consulting.

Even in your example, I'd say this:

1) If the application is so important that it needs to run 24/7 and the business loses a lot money while its down then even a slight risk is going to be too expensive.  Work with the company to get test licensing or another dongle or whatever. The cost is going to be better than if you break it doing this partial test, and probably not worth your job either if something goes wrong.

And if the application *doesn't* lose a lot of money while its down, or if it isn't up 24/7, or both, you have a justifiable way to create a maintenance window where the dongle can live on the test server for awhile.  Unplug. Test for an hour. Plug back in. And I'd *still* work with the vendor to get a valid test platform up first before going that route. But at least its a doable option.

No matter what, there are ways around testing on a live network.  Just my opinion. Not sure I will have a lot more to offer after that.
DrPingAuthor Commented:
Thanks for your input and time Cliff, and you're right about the mis-terminology on my part.
(the RDS server is hosting the network client software, but doesn't have the database actually installed)

Your opinion about test environments is noted... but these poor folk will have to rely on good luck, and thoroughly tested backups.

I believe my idea of a separate DC with a VM RDS server will be safe to set up and test running the network client software.
However you recommended to make the test DC a VM too, and not on the physical... completely possible, (and I don't mean any insult by questioning your suggestion about this)... just hope to understand if this is helping me avoid a landmine, makes something easier, or just more opinion.
Cliff GaliherCommented:
Best practice. Hyper-v management OS (mistakenly called a host by many) should always be just that and never run other roles. The changes hyper-v makes to network up the hyper-v is or and the VM is does break things. A quick Google search will show that collocation the DC and the hyper-v roles is bad news.
DrPingAuthor Commented:
Both of your time and input is appreciated. Philips advice to segment the network, gave me the inspiration to just segment the domains, and I won't have to worry about breaking the existing production environment.

Cliff reminded me to be careful ;>)

Thank you both!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.