How to set up RDP on Windows 2016 Server?

if you can run your program on Windows 10 you can do this....

https://www.serverwatch.com/server-tutorials/remote-desktop-connections-for-multiple-users-on-windows-10-and-windows-server-2012.html

I do that for remote clients wanting a terminal server, you can have unlimited clients connect and you can even watch them, kick them off, or what ever.

I would change the listening port to something super high like 9932.

it looks hard, but it's super easy.

More information is required?

where did your 2008 R2 and 2016 server is hosted?
 and how client will access application hosted on server? from internet?
You will get lot of guides how to deploy RDS but you still need to decide what exactly you need to deploy and in which way

There are a number of guides out there. This is one example: Deploying Remote Desktop Services 2016 Step-By-Step.

There are two ways to deploy:
 1: RD Gateway, Web, Broker and Session Host all on one VM
 2: RD Gateway, Web, and Broker on a VM and Session Host or Hosts on another or others

The main thing is to make sure to use RD Gateway to secure the inbound RD Client requests from the Internet. A third party trusted certificate is required for Gateway and Web while a self-issued can be used for Single Sign-On and Publishing.

Dan, you're talking about something totally different than what I'm talking about and, Mahesh, I didn't go into specifics because I'm new to Windows 2016 and am simply looking for some good documentation which Philip has provided, although I should provide some specifics since the documentation Philip provided the link to may not serve my purposes exactly.  First off, my Windows 2008 R2 setup was what I would consider to be a standard Internet-based hosting setup.  As I mentioned, that's been running for a couple years and, outside of security concerns, has worked great.  My Windows 2008 R2 setup was also the standard "Gateway==>Session Host" scenario, which is NOT what I'm looking at under Windows 2016.  The Windows 2016 RDP configuration will be entirely internal and will only be accessible to my client's internal network (i.e. NO internet access).  Therefore, a Gateway server is NOT required nor is any trusted SSL certificate.  The Windows 2016 server will be deployed on my client's hardware, accessible to my client's network (by numerous users who already have AD rights on the same network) but my application will still be accessed via an RDP connection to the Windows 2016 server which I have to set up for this RDP access.  Frankly, the issue here is system performance. Otherwise, the client's could simply use a shortcut on their Windows 10 desktops and run the application directly.  Since this is not feasible....and we're attempting to avoid using Citrix....RDP is the preferred means of connecting to and running the application.  At the moment, I'm going to "pour" through the "Step-by-Step" tutorial provided by Philip and see how that works out for me.  This is exactly what I was looking for, but I need to able to "cut out" the Gateway Server which is not needed in this scenario.  Thanks all for your responses.

Philip, I started going thru the link you provided.  I have to use the "Quick Deployment (All-In-One)" installation since they've provided me with one server to test this all out on.  The problem is that his instructions have the following "disclaimer" (or whatever...) which I don't understand at all:

OBS!!! Avoid adding RDS roles through Roles and Features Wizard if you are not a Powershell fan. You will need to configure RDS using Powershell.

He doesn't explain exactly what he means by this and proceeds to take you thru the Wizard steps (almost as if his "disclaimer" is irrelevant).  Problem is that I got thru the first 4 or 5 screens, then received an error that referenced Powershell and that the installation couldn't proceed because of "something having to do with Powershell".  Basic question is:  Why does he say you need to configure RDS using Powershell, not include anything further (in his step-by-step...) and then continue on with all the screens from the Wizard?  Doesn't work, I'm stuck, and have no idea what to do next!!!???

If running through using the Wizard that installs everything on one server then it's a fairly straight forward thing to do. The Gateway, Broker, and Web Roles would be installed that way.

Just because external access is not being used does not mean that the Gateway Role cannot be set up and left for a later date if needed.

And yes, breaking things open would mean using PowerShell. I think the Advanced Wizard would allow for no Gateway Role but I'm not 100% sure as we set all of our RDS standalone and farm configurations about 95% in PowerShell.

But that's the problem, running through the Wizard DOES NOT install anything, it errors out and, at that point, all I can do is cancel out of the entire installation!  Can you direct me to some other article on the web that could "step-by-step" me through this installation using PowerShell?

How many 2016 servers you are planning to install your application?

There should be no errors running the wizard to set things up. What do the Event Logs say?

You don't need RD connection broker and gateway even
All you need is remote desktop session host role and RD licensing role to be installed on 2016 server and install RDS CALs if this is single server deployment and allow users to connect to RD session host directly
You can do it from server manager, may be you can uninstall all RDS role1st and then start with fresh

Sorry for the delay in responding (I go to bed early....get up early).  Anyhow, to answer your question regarding the number of servers, I really have no idea.  That part of the decision making will be determined by my client.  My client is a major corporation with a lot of technical employees who will be making those types of decisions when it comes to the final deployment.  Currently, we are attempting to deploy on a single server just to make sure this will work the way we want it to, and, frankly, using RDP will give me more control of my own application with regards to future updates.  Also, the decision to NOT continue having the application hosted on my own equipment (as it is currently deployed) has already been made and, unfortunately, there's no turning back on that decision.  
Regarding the other issues, I know it seems like it should be a fairly simple process (and it really should be!) but I'm running into a roadblock trying to deploy RDP on this particular server at least.  I will follow up this comment with more details on the errors I'm receiving.

As already stated you are better off with only RD session host and license role
Else you could go with quick deployment model and install RD connection broker, session host and web access on same server and install application on top on that on single server
If HA is required, you need more servers

When I attempt to install (using the Quick Start Deployment), just when I get to the step where the wizard is supposed to start generating the roles, I get the following screen (which doesn't allow me to proceed any further):

This I know for sure:
1) The server is connected to the corporate domain.
2) The server is running Windows 2016 Server Standard.
3) I'm logged on as a member of the local Administrators group.
4) The server does NOT have a pending restart.

The other criteria that mentions PowerShell....I have no idea what the status of that is, but it just seems logical that the problem must be caused by the PowerShell requirement!?

Is the wizard being run from Server Manager on the soon to be session host?

On another server in the domain in an elevated PowerShell try:

Enter-PSSession NewRDServerName -Credential DOMAIN\AdminAccount

Select allOpen in new window

Change both the name and admin credentials to the correct ones then credential when prompted. What error happens?

On server, from elevated powershell, simply run Enable-PSRemoting and follow prompt and once successful, try again

Guys, I tried BOTH of your suggestions (Philip, I didn't receive any error code after I executed your suggestion...just brought me back to the PS prompt) and I'm still getting the same error as shown in my prior comment.  Trust me, I'm way out of my league here, so I have no idea what's actually preventing this installation from running.  Thought it made sense that it had to have something to do with Powershell, but that was just an educated guess on my part.  This server is sitting in my client's Charlotte, NC, data center and I have no idea who set it up, how they set it up, or what may or may not be different about it from other Windows Server 2016 installations.  All I do know is that it's apparently running under VMWare, if that helps at all?

I can confirm that my login credentials are my DOMAIN login credentials and that the computer is obviously connected to the domain AND that my login credentials are part of the Administrators group on the server.

You can ask them to provide non hardened instance of server, I suspect you got hardened server and in that case what is happening is expected

Unfortunately, I'm totally "at the mercy" of my client's personnel who have set up this virtual server using Windows 2016 and have no control over their time schedule.  As a result, outside of marking some of your suggestions as helpful, I can't move forward with this question until they've completed some analysis on their end.  I would like to keep this question open but, depending on how long they take to respond to my/our suggestions, I will close it out if they don't do anything for an unrealistic period of time.  Frankly, you both have given me basically what I was asking for.  I now have more insight into how to set up RDP under Windows 2016 than I had before I asked the question, so I thank you both for that.  Please bear with me for a little while longer to see if my client (who's pushing me to make this change in the first place) reacts in a reasonable amount of time.

When you ran the Enter-PSSession the PowerShell prompt would have looked like: [SERVERName] C:\Users\AdminName <-- Or something like that? That says that the connection was successful and that you essentially had a "local" PowerShell session going.

We use PS Remoting for almost all of our server setups. It makes life so much easier. :)

I tried it again and, yes, you're right.  The PS prompt came up like you described....only difference was that the path was C:\Users\AdminName\Documents....but, other than that, it came up like you said.  The problem for me is that I know nothing about PS Remoting and specifically how to set up RDP using PowerShell commands.  Do you have "step-by-step"  instructions you could point me to that would help me set up the RDP with PowerShell?

After installing the roles:

$RDBGWSHName = "RDBGWSHServer"
$Domain = "DomainName.Local"
$CollectionName = "Company's Collection"
$UPDPath = "\\UPDServerHost\UPDs"
$UPDSize = 30

New-RDSessionDeployment -SessionHost "$($RDBGWSHName).$($Domain)" -ConnectionBroker "$($RDBGWSHName).$($Domain)" -WebAccessServer "$($RDBGWSHName).$($Domain)"

New-RDSessionCollection -CollectionName "$($CollectionName)" -SessionHost "$($RDBGWSHName).$($Domain)" -CollectionDescription "The Default $($CollectionName)" -ConnectionBroker "$($RDBGWSHName).$($Domain)"

Set-RDSessionCollectionConfiguration -CollectionName "$($CollectionName)" -ConnectionBroker "$($RDBGWSHName).$($Domain)" -EnableUserProfileDisk -MaxUserProfileDiskSizeGB $UPDSize -DiskPath "$UPDPath"

Select allOpen in new window

Change the variables to the required settings and go. If no User Profile Disks are being used then remove that option from the third step.

A couple questions.  What do you mean with "After installing the roles:"?  Attempting to install the roles using the Wizard is where I got hung up in the first place....that process failed and returned the screen shot from one of my previous comments.  If these PS commands DO, in fact, install the roles, then my other question would be: What is a "collection"?  This is terminology that's new to me (2008 R2 doesn't have collections, or, at least, I never deployed anything named a "collection").   Finally, since I really don't know what User Profile Disks are, I'm assuming that I don't need them and, as a result, don't need lines 4, 5, or the end of line 11 in your commands from your comment?

Install-WindowsFeature Net-Framework-Core,Remote-Desktop-Services,RDS-Connection-Broker,RDS-Gateway,RDS-RD-Server,RDS-Web-Access,RSAT-RDS-Tools,RSAT-RDS-Gateway,RSAT-RDS-Licensing-Diagnosis-UI,RDS-Licensing-UI,Print-Services,Print-Server,Search-Service -IncludeManagementTools -Restart

Select allOpen in new window

Philip, please don't take this the wrong way.  I really appreciate all of you suggestions and comments.  Problem for me is that, being a complete novice with Windows Server 2016, you're giving me information in bits and pieces and I really need to understand the overall picture when it comes to installing RDP on 2016.  So, here are some more questions (some redundant) that I need to understand:
1)  Do I need to install the RDS-Gateway since we have no intention of using an RDP Gateway (or doesn't it matter if I install it and just don't use it)?
2)  Do I need to understand what a Collection is or is this just something new that's required but doesn't need any further configuration?
3)  Do I need to understand what User Profile Disks are or, as you implied, can these simply be left out of the installation?
4)  Finally, after I run all the PS commands that you've provided, should I be able to use the UI to make any further configuration changes necessary (assuming I'm successful with this installation)?

I mention the fact that I may not be successful with all the PS commands that you've provided, NOT because they don't work for your installs, but rather because I don't know what restrictions have been imposed on the server that my client set up and is providing for me as a POC test.  Thanks again for all your help, I just need a clearer picture of what I'm actually doing before I actually attempt it on this server!

1: RD Gateway can be left out for a standalone setup.
2: Yes. Your app will be published within the collection for local and RemoteApp.
3: If no UPDs are used the RDS will land the user's profile at C:\Users\%UserName%. So long as there is enough space on the C: partition this may not be an issue. If more than one Session Host is required then UPDs should be used to keep the user experience consistent.
4: Yes.

In an elevated CMD on the RDS to be run:

GPResult /H C:\Temp\GPResults.HTML

Select allOpen in new window

Have a look at the generated HTML to see what specific policy settings are being applied and may be interfering with the setup of RDS.

OK, I entered your PS commands, but didn't get too far.  I could see that it was starting to install, but it errored out on the "Install-WindowsFeature" command:

After this errored out, I ran your GPResult command which produced a huge list of settings that I really can't share with you in their totality, but I will include a couple of screenshots.  This part of the GPO report was fairly far down into the listing and just appears to reinforce the idea that this server has been "hardened" (which, frankly, defeats the purpose of my attempting to set up a basic POC server environment):

This screenshot is just the very beginning of the GPO listing.  Most of the GPO settings are not familiar to me (throughout the entire listing) and I have to assume that most of them are unique to Windows Server 2016 (since I've spent a significant amount of time with the GPO settings in 2008 R2 Server to lock down my own server):


Unless you can glean something out of the small portion of the GPResults file that I've attached here and have some further suggestions, I'm going to close out this question, with the possibility of reopening it at some point in the future after my client has done some analysis on this server setup and, again, since I haven't heard a word from them so far this week, I really don't expect to hear back from them in any timely manner.  Again, thanks for all your help and sharing your expertise with me!

Ask the AD folks to put the server's AD object into a TEST OU that has no Group Policy settings linked and/or enforced to it. Preferably at the root of the domain and hopefully there are no GPOs at that level that would pollute the setup.

Install-WindowsFeature Net-Framework-Core,Remote-Desktop-Services,RDS-Connection-Broker,RDS-Gateway,RDS-RD-Server,RDS-Web-Access,RSAT-RDS-Tools,RSAT-RDS-Gateway,RSAT-RDS-Licensing-Diagnosis-UI,RDS-Licensing-UI,Print-Services,Print-Server,Search-Service -IncludeManagementTools -Source d:\sources\sxs\ -Restart

Select allOpen in new window

^^^ Specifies a Source of D:. Mount the Windows Server .ISO file and set the drive letter for the source accordingly. That will allow the setup to proceed past the Source Files error.

Philip, I probably haven't made my situation as clear as I could have.  Please understand that I have absolutely no say over how this server is deployed.  I don't even know the people who are working on this server deployment.  I'm working with a HUGE multi-billion dollar corporation who got hit with a serious cyber-attack back in June of 2017.  Needless to say, they've been recovering ever since and have spent millions of dollars in both reconstructing their damaged systems and hiring "security experts" to lock down everything to the point where their employees are, frankly, having a hard time getting their own work done.  They would not have gotten to my application for at least 4 to 6 months after the cyber-attack hit, but since I had my own RDP solution running under Windows 2008 R2, we decided to move everyone (around 500-600 users) over to my network and had them back up and running in July 2017.  Now they're re-evaluating everything and some "genius" has decided that, despite all the work and time I spent tightening up my system, it currently doesn't meet their standards.  Hence, the push to move my application back into the corporate network (which is ALL on one DOMAIN, great security right?) and that's why I'm attempting to deploy on one of their "secure" servers and, despite it only being a POC situation, I'm guessing that they are not going to move off the "hardened" server.  

Bottom line is that I can't tell them to set up a TEST OU much less get any access to their Windows .ISO file or anything else.  My hands are completely tied and the only thing I can do is keep my application running on my own network and work with the people who are pushing this move back onto the corporate network (who I don't "really" know either, although I have at least spoken with them).  All the other "parties" to this deployment are "offshore" support personnel, some of whose names I've seen in emails but that's about it.  I'm sure your last two suggestions would be the way to go in ordinary circumstances, but, in this case, not possible....Thanks

I'm curious as to why you feel that my 2008 R2 setup is "too old" to be secure.  I'm sure that Microsoft has made improvements to the security aspect of their newer server OSs, but my setup uses:
1) SonicWall firewall technology to restrict access to the network to only corporate employees (they're all on the same subnet).
2) Symantec EndPoint Security to protect the server against intrusions, probably not 100% effective but very effective nonetheless.
3) GPO software and other restrictions to protect my server against any "computer savvy" corporate employee that may want to cause mischief.
4) RemoteApp technology so that the end users only have access to the application (no Administrative rights) and NO access to the remote desktop.

I understand that the prevailing wisdom is that the newer operating systems are "better", more secure!? (not totally convinced on that score), and the lack of future Microsoft support (which I've never used during my career) is an issue!? (not convinced on this either).  I guess I'm from the old school philosophy that "if it ain't broke, don't fix it", so I'm just curious as to why so many in the IT field keep buying into Microsoft's "keep the money flowing" tactic of constantly dropping one OS for another every few years or so....never could figure out why so many seem to "fall" for this.

That said, if need be, I could always update my servers to either 2012 R2 Server or 2016 Server and keep hosting the application myself in a scenario where I WOULD have some control over the setup of the OS and AD and RDS, etc.  Unfortunately, this is "extremely" unlikely at this point!

Anyway, all of the above is supposition and my ramblings, but I would definitely be interested in hearing your take on these newer server OS packages and why you appear to consider them "tighter" or potentially tighter than an older OS like 2008 R2?

As a rule, providing services to end clients the Microsoft products used should be covered by SPLA (Service Provider's License Agreement). Unless the client is providing the Server 2008 R2 license?

Suffice it to say, Windows Server 2016 and now 2019 are _a lot_ tighter security wise and the integrated Windows Defender Anti-virus with their Cloud based heuristics works really well. No more need for third party (we are dropping SEP as the license comes up for renewal as a result). We'd not even consider deploying 2008 R2 in any way as a result short of isolated in a container with jump station access and no Internet in or out at all.

I'm closing out this question, albeit without a solution to my current dilemma.  That said, until my client provides me with a POC server that I can actually configure, there really is no final answer.  And, that said, the information Philip provided may still provide a solution whenever my client gets their act together, so I basically feel that Philip provided the best solution while also providing valuable information that I truly believe I can use in the future.  A quick shout out to Mahesh as well for his contributions which were also insightful and helpful.  Thanks to all...