Today's blog post is a real treat. Why? Because it is a complete series of posts written by Eddie Kwasnik, an outstanding virtualization consultant that I have met through the Atlanta pro camp series last year. Eddie has a passion for VDI and Terminal Services, and has recently decided to start blogging to share his knowledge with others. In this blog series he dives into Windows Server 2012 R2 Remote Desktop Services(formerly known as Terminal Services). He guides us through building our own environment step-by-step. So let's jump in and get started!
The first post in the series dives into the beginnings of building the RDS farm: "In our deployment, we will be logged into a single server and through Server Manager we will deploy our new Remote Desktop farm. Each of the servers designated in the environment are virtual, domain joined and were created from a template with the latest Windows updates. No other special changes or configurations were done to any of the servers with the exception of the RD Session Host servers. Some applications were installed on the RD Session Host servers in order for us to deploy our RemoteApp programs.": http://thewolfblog.com/2014/02/08/deploying-a-2012-2012r2-remote-desktop-services-farm/
Then Eddie dives into publishing remoteapps and session desktops. "We will now need to add the user group(s) which will have access to the collection. To make things easy, it defaults to Domain users. As a good practice, a specific security group should be created and assigned for each of the collections. For this example, you can leave domain users. Since I’ve already created a specific security group for this collection, we will go ahead and add the group. The group is called demolab\RemoteApp Office Apps. Click next.": http://thewolfblog.com/2014/02/10/collections-publishing-remoteapp-programs-and-session-desktops-on-rds-2012-2012-r2/
Next he walks us through the process of the RD Gateway service role to the farm as well. "In order to secure a user’s connection into a RDS farm, a RD Gateway server will be required. The RD Gateway enables authorized remote users to connect to resources in an internal corporate or private network, from any Internet-connected device that can run the Remote Desktop Connection (RDC) client. The network resources can be RD Session Host servers, RD Session Host servers running RemoteApp programs, or computers with Remote Desktop enabled." Continue on here: http://thewolfblog.com/2014/02/13/deploying-the-rd-gateway-service-role-in-a-2012-2012-r2-rds-farm/
Once we have the farm established we need to make it highly available right? Eddie dives into that next! Per the TechNet article on RDS: -Allows users to reconnect to their existing sessions in a load-balanced RD Session Host server farm. This prevents a user with a disconnected session from being connected to a different RD Session Host server in the farm and starting a new session. -Enables you to evenly distribute the session load among RD Session Host servers in a load balanced RD Session Host server farm. -Provides users access to virtual desktops hosted on RD Virtualization Host servers and to RemoteApp programs hosted on RD Session Host servers through RemoteApp and Desktop Connection. http://thewolfblog.com/2014/02/02/configuring-ha-for-the-remote-desktop-connection-broker/
Finally, Eddie wraps up series with configuring the RD Gateway Servers. "From your RD Gateway Server you will need to create a new Remote Desktop resource authorization policy (RD RAP) with an RD Gateway-managed group that includes the DNS Round Robin name of the RD Connection Broker servers. From within server manager in Remote Desktop Services node, right-click on the RD gateway server and launch the RD Gateway Manager. (If this is being done from a server other than the Gateway server, please ensure the RD Gateway Management Console is installed on the server)": http://thewolfblog.com/2014/02/02/configuring-the-rd-gateway-server-for-an-rds-farm-with-ha-enabled-for-the-rd-brokers/