The other day I was in a conversation where I drew the distinction between reliable and robust. I hadn’t really thought about it precisely but when asked to articulate the distinction I said that robust was “reliable across a wide range of conditions”. A lot of what Klaas describes in his blog about RDS reminds me of that definition. Remote Desktop Services in Windows Server 2012, is reliable across a much wider range of conditions. It works better across a wide range of networking configurations, it works better across a wide range of hardware devices and configurations (physical or virtual) and it works better across a wide range of administrative scenarios. Oh yeah, it also adds a bunch of great new features. I think you are going to enjoy what you see here.
For Windows Server 2012 we listened to our customers and partners and added the most desired features and resolved the top pain points in Remote Desktop Services (RDS). Following a description of RDS, I’ll summarize some of the many dramatic improvements we have made.
For those people that are not familiar with RDS, it is the workload within Windows Server that enables users to connect to virtual desktops, session-based desktops and RemoteApp programs. The key value that RDS provides is the ability to centralize and control the applications and data that employees need to perform their job from the variety of devices that the employee uses. This provides “work anywhere from any device” while ensuring that your control and compliance needs are met.
In the previous release, we received consistent feedback that:
- RemoteFX was very popular however its underlying protocol (RDP) did not provide a great experience over Wide Area Networks (WANs)
- Session and virtual machine infrastructures were complicated and costly and
- The administration experience was not simple.
Windows Server 2012 addresses each of these issues.
For Windows Server 2012 we have made RemoteFX dramatically better over a WAN as well as balancing between scale (host side cost) and reduced bandwidth. Specific improvements include:
- Adaptive Graphics. We support a mix and match approach, determining and using the right codec for the right content instead of one size fits all. We included codecs optimized for multimedia, images, and text. We improved caching as well as added progressive rendering. Progressive rendering allows RemoteFX to provide a responsive experience over a highly constrained network.
- Intelligent Transports. We support UDP as well as TCP. UDP provides a better experience over a lossy WAN network but, is not always possible dependent on the routers, and firewalls involved. RDP will automatically use TCP when UDP cannot be used to ensure connectivity and the best possible experience.
- Optimized Media Streaming. We utilize a new codec to reduce bandwidth consumption for media content (in some cases a 90% bandwidth reduction) while also providing a great end user media experience.
- Adaptive Network Auto Detect. In this release, the end user no longer has to set the network in the Remote Desktop Connection client: the client auto-detects the network type and, also adapts as the network changes.
- DirectX11 Support with vGPU. In Windows Server 2008 R2 SP1, we first introduced the RemoteFX Virtual GPU (vGPU), which provided DirectX 9 application support and Aero theming for virtual machines running on Hyper-V servers with physical GPUs. In Windows Server 2012, the vGPU feature is expanded and all Windows 8 virtual machines can take advantage of a DirectX 11 capable GPU, either emulated in software (softGPU) when no GPU is present in the host or para-virtualized and hardware-accelerated (vGPU) when a DirectX11 compatible video card is present in the host. We do support multiple GPU’s within one server and are seeing greater engagement with OEM’s to provide systems that support this.
- Single Sign-On. In Windows Server 2008 R2, it was possible to configure an RDS deployment so that users will need to enter their credentials only once when connecting to RemoteApps and hosted desktops. However, this configuration was very cumbersome. In Windows Server 2012 we dramatically simplified this by eliminating the need to use multiple certificates. We also made it possible to use locally logged on domain credentials so that users connecting from managed devices can connect seamlessly without any credential prompts.
- Email and web discovery of Remote Applications and desktops. Users now can find the correct remote workspace to connect to by just providing their email address. This removes the requirement to remember a long website URL. In addition, Remote Desktop Web Access now supports other browsers such as Chrome, Firefox, and Safari.
- Multi Touch. We support full remoting of gestures (e.g. pinch and zoom) between the client and host with up to 256 touch points. This provides for a consistent experience when using a touch enabled device locally or, over RemoteFX. As more apps are written supporting touch as the primary interface, this will become more important.
- USB Redirection. In Windows Server 2008 R2 SP1 we supported USB isochronous remoting only for vGPU enabled virtual machines. We have added support when using sessions and physical hosts which provides a consistent experience independent of physical, session, or virtual machine based host.
- Metro-style Remote Desktop. In the app store we have added a new Metro-style application to provide an immersive touch-first remoting experience. Discoverability of remote resources, touch optimization, easy reconnect to your favorites, are just some of the specific features added.
The second main improvement area is in overall infrastructure simplification and cost reduction. Cost and complexity is a major roadblock for Virtual Desktop Infrastructure (VDI) and hosted desktop deployments of all sizes. In Windows Server 2012 we made many improvements to address this problem, such as:
- Robust Pooled Virtual Desktop Collection model. “Pooled virtual desktop collection” model refers to the idea that a large number of virtual machines can be managed as a single entity by using a single virtual desktop template. This model is very attractive in VDI because it allows IT admins to provide a work desktop to multiple users without having to maintain a full OS for each user. In Windows Server 2012 we fully support this deployment model. Virtual machines can be created in batch from a virtual desktop template, patched by only modifying that virtual desktop template, and recreated/refreshed automatically by the RD Connection Broker. This dramatically reduces the cost and complexity of supporting a large number of users.
- User Profile Disk. A major blocker for the “pooled virtual desktop collection” model has been lack of personalization: Since the pooled virtual desktop collection is based on a common virtual desktop template, the user’s personal documents, settings, and configurations would normally not be present. User Profile Desk was added to solve this problem for either virtual machine-based or session based desktop deployments. As the user logs on to different virtual machines within the pool or different RD Session Hosts within the session collection, his/her User Profile Disk gets mounted, providing access to the user’s complete profile. Since User Profile Disk operates at a lower layer, it works seamlessly with existing user state technologies such as Roaming User Profiles and Folder Redirection.
- Wide range of high-performance and low cost storage options. RDS is built on top of Hyper-V and Windows Server 2012 storage, so the enhancements made throughout the hypervisor and storage stack in Windows Server 2012 benefit all RDS deployments. To name a few, we support:
- VDI over SMB, SANs, or direct attached local storage
- Pooled virtual desktop collections can be configured with storage tiers to optimize IOPS
- Highly scalable and resilient configurations with Clustering and with Storage Spaces
- All these improvements provide a dramatic reduction in costs while maintaining performance and management benefits of central storage.
- Fairshare of resources in RD Session Host. In Windows Server 2012, RD Session Host server allocates CPU, Disk I/O, and Network I/O such that a single user cannot consume resources that would negatively impact other users on the same host. Each user will get a “fair share”. This is done with minimum overhead so the CPU, disk, and network resources are used to maximum capacity.
- GPU Optional. In Windows Server 2008 R2 SP1 we had a requirement on a physical GPU for the new RemoteFX features that shipped in that release. In Windows Server 2012 the physical GPU is optional for VDI where it provides value if you are running applications that could benefit from hardware offload such as a CAD/CAM application.
- Removal of a dedicated RD Session Host server running in redirection mode. We have removed the RD Session Host server running in Redirection mode which was a required component in previous versions. This functionality is now incorporated into the RD Connection Broker. This reduces the number of components to deploy and manage.
The third and final focus area for improvements made in RDS has been in overall management simplification. This is targeted at improving the E2E management experience as well as enabling partner solution creation. Improvements include:
- RDS Management Interface integrated into Server Manager. RDS now includes a single management interface through which you can deploy RDS end to end, monitor the deployment, configure options, and manage all your RDS components and servers. This management interface is built into the new Server Manager, taking advantage of many new Windows Server 2012 management capabilities such as multi-server deployments, remote configuration, and orchestrated configuration workflows. This interface replaces older tools such as Remote Desktop Services Manager, RemoteApp Manager, and RD Session Host Configuration. The management tools for RD Gateway and RD Licensing are still provided separately since these roles are often deployed independently.
- Scenario-Focused Deployment. The new Server Manager provides a scenario-focused wizard that dramatically simplifies the task of bringing up a complete RDS deployment. This wizard sets up all the roles needed for an RDS deployment, configures each server role correctly to communicate with the other roles, and walks you through creating your first virtual desktop or session collection as well. The wizard comes in two flavors:
- Quick Start is optimized for deploying Remote Desktop Services on one server, and creates a collection and publishes RemoteApp programs.
- Standard Deployment allows you to deploy Remote Desktop Services across multiple servers, allowing for a more customized deployment.
- Active/Active RD Connection Broker. In previous releases 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. In this release, we have eliminated the need for clustering and switched to an active/active model. With this model, two RD Connection Brokers can be combined as a farm to provide both fault tolerance and load balancing. This prevents the broker from being a single point of failure and also allows ‘scale out’ as load demands.
- PowerShell support. All platform functions and capabilities can be controlled through a comprehensive and rich PowerShell layer. IT administrators can use this layer to build sophisticated automation that helps fit RDS into their IT infrastructure and workflows. We also anticipate third-party vendors to use this new extensibility layer to address unique new scenarios and integrate Windows Server 2012 RDS into management tools.
Remote Desktop Services in Windows Server 2012 provides a single infrastructure, and consistently great remoting experience even over WAN while offering three deployment choices: Session, Pooled virtual desktop collection, Personal virtual desktop collection to reduce the cost appropriate to the needs of the user. The administration is simplified and platform hooks are provided for partner extension to provide additional value and solutions.
Customers are excited about RDS with Windows Server 2012 and some have already rolled out a pre-release version into production taking advantage of these new benefits! We are proud of the work we have done and look forward to providing more information as we drill into the specific features in blogs posts to come at the RDS Blog.
– The Entire Remote Desktop Virtualization Team
Remote Desktop Services (RDS) in Windows Server 2012 is Microsoft’s VDI (Virtual Desktop Infrastructure) offering. RDS formerly known as Terminal Services (TS) provides session-based virtual desktops, virtual-machine based virtual desktops and applications to end users. To be able to use these features, you must install Remote Desktop Services in Windows Server 2012 or 2012 R2. So, in this post I will show steps to install Remote Desktop Services in Windows Server 2012.
The diagram below shows the scenario for this post. The network consists of one domain controller and one RDS server.
Log on to RDS server (MBG-RDS01). Open Server Manager. Click Add Roles and Features.
Click Next on Before you begin page. Choose installation type as Remote Desktop Services installation. Click Next.
As you can see below there are two ways of installing RDS services in Server 2012. They are quick or standard. In quick deployment option, three of the required RDS services are installed on single server. The three services are, RD Session Host, RD Connection Broker and RD Web Access. Similarly, the quick installation also creates a collection and publishes some RemoteApp programs. Here, I will install quick deployment option. If you wish to separate each RDS components then you can choose standard deployment option. Choose Quick Start as Deployment Type and click Next.
Deployment Scenario can also be either virtual machine-based or session-based. Here, I will choose session-based. Click Next.
Under Server Selection page, the current server will be automatically added as shown below. Click Next.
Review the installation options. Check, Restart the destination server automatically if required option. Click Deploy.
The installation will now begin. The server will reboot automatically. After the reboot, log back in, you can see the installation has completed successfully. Click Close.
Now, let’s verify the installation. Open Server Manager. Click Remote Desktop Services on the left pane. You can see the RDS deployment Overview as shown below. As we can see, RD Web Access, RD Connection Broker and RD Session Host have been installed. If you want applications or desktop sessions to be accessed from the Internet then you have to install RD Gateway. Similarly, You must install RD Licensing to activate RDS server.
You can also view installed applications. Under Collections, click QuckSessionCollection which is just a collection named created by Quick Deployment installation option. As you can see, calculator, paint and wordpad applications have been published.
To access those applications, open web browser and type URL of RD Web Access server. Type username and password and log on the server as shown below. You can also customize the look of RD Web Access page.
You can view the published applications below. Double-click to open any application. I have double-clicked calculator.
Accept the certificate warning. The application will open as shown below.
So in this way you can install RDS in Windows Server 2012 using Quick Deployment option. You can now install certificates, publish required apps, publish session-based desktops, customize RD Web Access, and so on.
The following two tabs change content below.
- Bio
- Latest Posts
Bipin is a freelance Network and System Engineer with expertise on Cisco, Juniper, Microsoft, VMware, and other technologies. You can hire him on UpWork. Bipin enjoys writing articles and tutorials related to Network technologies. Some of his certifications are, MCSE:Messaging, JNCIP-SEC, JNCIS-ENT, and others.
UPDATE: If you are looking for a guide on a newer OS, I posted this guide updated to Windows Server 2019: Step by Step Windows 2019 Remote Desktop Services – Using the GUI
A step by step guide to build a Windows 2012 R2 Remote Desktop Services deployment.
Part 1 – Deploying a single server solution.
Although it is called a single server installation, we will need 2 servers as shown below.
Software used in this guide:
Windows Server 2012 R2 ISO (evaluation can be downloaded here: http://technet.microsoft.com/en-us/evalcenter/dn205286.aspx)
SQL Server 2012 SP1 Express x64 With tools (free version can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=35579. After clicking the download button select SQLEXPRWT_x64_ENU.exe)
SQL Server 2012 SP1 Native Client (free version can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=35580. After clicking the download button select ENU\x64\sqlncli.msi)
And a certificate. I got mine for free from https://startssl.com. This certificate needs to contain the FQDN you will use as the RD Web Access URL (mine is gateway.it-worxx.nl in this guide). It needs to be in .pfx format and you need to have the private key in it.
This guide will not focus on building a domain using a single domain controller and adding the second server as a member server to this domain.
Also some basic knowledge is assumed in this guide. I will not detail how to create a Security Group and adding a computer account to it. I will also not detail how to install SQL Express, or adding logins to a SQL Server Instance security context. If you need extra help with this, Bing it or drop me a mail with details, and I will provide steps to continue.
I will be using Hyper-V 3.0 on my Windows 8.1 laptop and I have prepared 2 servers:
ITWDC01 (1 vCPU, 512MB memory, dynamic, 60GB Harddisk)
Installed Windows IPv4 192.168.66.20/24
Added .NET Framework 3.5 as a feature
Added Active Directory Domain Services as a role
Configured this server as a Domain Controller in a new forest: itw.test
ITWRDS01 (1 vCPU, 512MB memory, dynamic, 60GB Harddisk)
Installed Windows
Added .NET Framework 3.5 as a feature
IPv4 192.168.66.21/24, DNS server 192.168.66.20
Configured it as a member server in the itw.test domain
Installing the Remote Desktop Services Roles
Log on to the Domain Controller, and in Server Manager right-click the All Servers node and add the second server using the Add Servers command (or select the All Servers node, click Manage and click Add Servers).
Now that all servers needed in this deployment scenario are present, click Manage, and click Add Roles & Features.
Before you begin
Click Next.
Select Installation Type
Select Remote Desktop Services installation. Click Next.
Select Deployment Type
Although Quick Start might be a valid option for a single server deployment, leave the default selected. This will explain the steps necessary to install Remote Desktop Services in greater detail.
Click Next.
Select Deployment Scenario
Select Session-based desktop deployment. The other option will be a different post in this series.
Click Next.
Review Role Services
Review the services that will be installed.
Click Next.
Specify RD Connection Broker server
Click the member server and click the Add button.
Click Next.
Specify RD Web Access server
Check Install the RD Web Access role on the RD Connection Broker server.
Click Next.
Specify RD Session Host server
Click the member server and click the Add button.
Click Next.
Confirm selections
Check Restart the destination server automatically if required.
Click Deploy.
View progress
Wait until all role services are deployed and the member server has restarted.
Click Close.
In Server Manager click Remote Desktop Services and scroll down to the overview.
As you can see the deployment is missing a RD Gateway server and a RD Licensing server.
Installing the missing Remote Desktop Services Roles
Click the Add RD Licensing server button.
Select a server
Click the domain controller and click the Add button.
Click Next.
Confirm selections
Click Add.
View progress
Wait until the role service is deployed. No restart is needed.
Click Close.
Click the Add RD Gateway server button.
Select a server
Click the member server and click the Add button.
Click Next.
Name the self-signed SSL certificate
The wizard creates a self-signed certificate. We will deal with certificates in this deployment in a little bit. Enter the external Fully Qualified Domain Name which you will also use for the Web Access URL. In my case, for lack of a better name, I used “gateway.it-worxx.nl”. I didn’t want to use “remote.it-worxx.nl” or “desktop.it-worxx.nl” or anything else.
Click Next.
Confirm selections
Click Add.
View progress
Wait until the role service is deployed. No restart is needed.
Notice that “gateway.it-worxx.nl” was configured for the deployment.
Also notice that even more certificate configuring is need, but we’ll get to that later. Pay no attention to it for now.
Click Close.
Let’s have a quick look at the certificate configuration.
Reviewing the Remote Desktop Services certificate requirements
In Server Manager, Remote Desktop Services, Overview, click Tasks and click Edit Deployment Properties.
Configure the deployment
Review the RD Gateway settings and notice what settings are available.
Click RD Licensing.
Configure the deployment
Notice that a RD License server is available, but no license type is selected yet.
I selected Per User, but since this is just a guide setup, it really doesn’t matter.
Click RD Web Access.
Configure the deployment
By default the RD Web Access IIS application is installed in /RdWeb. If you want to know how to change this, check another post: https://msfreaks.wordpress.com/2013/12/07/redirect-to-the-remote-web-access-pages-rdweb/
Click Certificates.
Configure the deployment
Notice that the certificate level currently has a status of Not Configured.
As you can see, certificates are used for different goals within the deployment.
The RD Gateway certificate is used for Client to gateway communication and needs to be trusted by the clients. Either install the self-signed certificate on all clients, or use a certificate for which the complete certificate chain is already trusted by all clients. As it said in the wizard, the external FQDN should be on the certificate.
The RD Web Access certificate is used by IIS to provide a server identity to the browser clients (and to the Feed clients, but that’s a subject for a future post).
The RD Connection Broker actually has two goals for which it needs certificates. To enable single sign on (server to server authentication), and for publishing (signing RDP files). If you look in the deployment you’ll see that the Connection Broker is now configured to use “itwrds01.itw.test”, so we have to change it to use an external FQDN as well.
If we use the same FQDN for all goals described above, we need only 1 certificate, and only 1 external IP address.
We’ll come back to this wizard later to assign the certificate. First order of business is to change the internal FQDN for the Connection Broker to an external FQDN.
Click OK (no reason why we shouldn’t commit the change we made on the licensing tab, remember?)
Preparing for completing the Remote Desktop Services configuration
Open DNS Manager on the domain controller and browse to Forward Lookup Zones.
Right click Forward Lookup Zones and click New Zone… Go through this wizard accepting the defaults until you have to enter a Zone Name.
Enter the external FQDN which will also be used by the Connection Broker.
Finish the rest of the wizard accepting the defaults.
Browse to the newly created zone.
Right click the newly created zone and click New Host (A or AAAA)…
New Host
Leave the Name field blank, but enter the member server’s (holding the RD Connection Broker role) IPv4 address.
Click Add Host.
Create a new Global Security Group called “RDS Connection Brokers” and add the computer account for the member server to it as a group member.
We need this group to be able to convert the RD Connection Broker to a highly available RD Connection Broker. You’ll see why we need to do this in a few steps.
Reboot the member server to let it know it’s a member of the RDS Connection Brokers security group.
Install SQL Express on the Domain Controller (or use an existing SQL Server if you already have one). Here’s a list of needed features:
Now you see why I pre-configured the servers with the .NET Framework 3.5 feature before starting anything.
Use the Default Instance (so click Default, and do not leave the wizard’s selection on Named instance: SQLEXPRESS).
When the installation is done open SQL Configuration manager and browse to Client Protocols under SQL Native Client 11.0 Configuration.
Check if TCP/IP is enabled under Client Protocols. SQL Express install enables this by default, but check it just to be sure, especially if you use an existing SQL Server.
Browse to Protocols for MSSQLSERVER under SQL Server Network Configuration.
Enable TCP/IP. If this is a new SQL installation, this will be disabled by default.
Restart the SQL Server service if you changed this setting.
On the SQL Server, make sure port 1433 is not being blocked by Windows Firewall.
I added the SQL Server executable to the exception list to allow all inbound traffic.
Open SQL Server Management Studio and browse to Logins under Security.
Right click Logins and click New Login…
Login – New
Click Search…
Select User, Service Account, or Group
Click Object Types… and select Group.
Type the RDS Connection Brokers security group name and click Check Names.
Click OK.
Login – New
Click Server Roles and select dbcreator.
Click OK.
We have just effectively granted the RDS Connection Broker server the right to create databases.
We need this because the RDS Connection Broker service will try to migrate from WID (Windows Internal Database to a (high available) SQL Server instance when we convert the Broker to a high available broker.
Install the SQL Native Client on the member server (Client Components only).
Everything we need is now in place to convert the RD Connection Broker, so let’s do just that.
Convert the RD Connection Broker
In Server Manager click Remote Desktop Services and scroll down to the overview.
Right click RD Connection Broker and click Configure High Availability.
Before you begin
So we’re actually building a single node cluster here 
Look at the pre-requisites.
If you have more than one RD Connection Broker they need to be configured using DNS Round Robin. More on that in a later post.
Click Next.
Configure RD Connection Broker for High Availability
Database connection string:
DRIVER=SQL Server Native Client 11.0;SERVER=ITWDC01;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=ITWRDCB
Folder to store database files:
C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA
I used the instance default folder.
DNS round robin name:
The DNS Zone name we configured in DNS earlier.
Click Next.
Confirmation
If you get an error before this page:
– Check if TCP/IP is enabled in client protocols and for your instance
– Check if you can reach port 1433 on the SQL Server from the member server
Click Configure.
Progress
If you get an error on this page:
– Check SQL permissions for the security group
– Check if the database path you entered is correct
Click Close.
The RD Connection Broker is now in High Availability Mode and we are finally ready to complete the configuration.
Completing the Remote Desktop Services configuration
In Server Manager, Remote Desktop Services, Overview, click Tasks and click Edit Deployment Properties, then click Certificates.
Configure the deployment
Click RD Connection Broker – Enable Single Sign On and click Select Existing certificate.
Browse to the .pfx file, enter its password, and check Allow the certificate..
Click OK.
So click Apply. This takes a little while, be patient.
Configure the deployment
Click RD Connection Broker – Publishing and click Select Existing certificate.
Browse to the .pfx file, enter its password, and check Allow the certificate..
Click OK.
Click Apply. This again takes a little while, be a little more patient.
Configure the deployment
Click RD Web Access and click Select Existing certificate.
Note: Did you notice the warning when you select RD Web Access? Browse to the .pfx file, enter its password, and check Allow the certificate..
Click OK.
Click Apply again. This takes another little while longer, be a slightly more patient.
Configure the deployment
Last one. Click RD Gateway and click Select Existing certificate.
Browse to the .pfx file, enter its password, and check Allow the certificate..
Click OK.
Click OK to finish the certificate configuration.
Configured all servers, configured certificates..
One thing left to do: Tell our RDS environment exactly what to publish.
In fact you can use this setup to either provide full desktop sessions on the Session Host, or you can choose to publish only applications on the Session Host.
Let’s publish full desktop sessions.
Publish a full Remote Desktop environment
In Server Manager, Remote Desktop Services, Session Collections, click Tasks and click Create Session Collection.
Before you begin
Review the requirements. This won’t be an issue in this setup, but you could restrict access to this collection by selecting a select group of people.
Click Next.
Name the collection
Enter a descriptive name. This name will be displayed under its icon in the Web Access interface.
Click Next.
Specify RD Session Host servers
Click the member server and click the Add button.
Click Next.
Specify user groups
You can limit access here. Add one or more groups to restrict access to these groups only. In this setup Domain Users will do fine.
Click Next.
Specify user profile disks
User profile disks are not in focus in this guide. Since I have no file shares configured in this setup, uncheck Enable user profile disks for now.
Does and Don’ts will be covered in a future post.
Click Next.
Confirm selections
Review the information and click Create.
View Progress
Wait until the collection is created and the server is added to the collection.
Click Close.
Time to test the setup!
Testing the Remote Desktop Services
On a machine that has access to your test setup (you may have to add the external FQDN to your hosts file if you didn’t publish it to the internet) open https://gateway.it-worxx.nl/rdweb.
Hey! At least the RD Web Access application works 
Enter a valid username and password (ITW\username or username@itw.test).
Create a user for this, or simply use the domain admin account.
Click Sign in.
After logging in you’re presented with the full desktop session collection we created.
After clicking the Full Desktop icon you get the warning that devices are going to be redirected.
And when you click Connect, you actually connect
Enjoy.
In the next part of this series I will show how to extend this setup to use multiple session hosts, combine these with remote applications, and setting up dedicated servers for Web Access, Gateway and Connection Broker.
Arjan
Upate: Part 2 in the series was just published. Find it here: https://msfreaks.wordpress.com/2013/12/23/windows-2012-r2-remote-desktop-services-part-2/
Microsoft Remote Desktop Services [RDS] allows users to access centralized applications and workstations in the data center remotely. Microsoft RDS is the new expanded and renamed Microsoft Terminal Services. In this post I will document the implementation of RDS in my home lab using an ‘all-in-one’ configuration.
vBoring Blog Series:
- Setup Remote Desktop Services in Windows Server 2012 R2
- Setup RD Licensing Role on Windows Server 2012 R2
- Setup RD Gateway Role on Windows Server 2012 R2
Server Roles in RDS:
There are three core roles to setup a RDS environment and are as follows:
- Remote Desktop Session Host [RDSH]: Applications are installed and published from the Session Host servers.
- Remote Desktop Connection Broker [RDCB]: This role handles user sessions by load balancing among the RD Session Host servers. Also allows disconnected users to reconnect to their existing sessions without starting a new one.
- Remote Desktop Web Access [RDWA]: This role provides a web portal to access the RDS environment. Also allows Windows 7 & 8 desktops to connect using the RemoteApp and Desktop Connection.
The follows roles are not required but add additional abilities to RDS:
- Remote Desktop Gateway [RDG]: This role enables remote users to use the Remote Desktop Protocol (RDP) over HTTPS. It is placed on the edge of your network and acts as the entry point to your RDS environment externally.
- Remote Desktop Virtualization Host [RDVH]: This allows RDS integration with a Hyper-V hypervisor to manage virtual desktops
- Licensing: RDS comes with a 120 day trial period. When the trial period ends RDS will no longer accept connections. The RDS License role handles the licensing for RDS.
For additional reading about the roles for RDS check out the Microsoft RDS Overview
Installing RDS Roles:
When setting up RDS you have the option of running the three core roles run on a single server or separate each role onto its own server. If you are setting RDS up for a lab or a small environment then a all-in-one setup would save you hardware resources. If your environment is large you will want to separate these roles to spread the resources across multiple servers. No matter which setup you pick they both can scale outward depending on user growth.
For my documentation I went with a single server called a Quick Start setup. To start open Server Manager then click Manager -> Add Roles and Features
Click Next
Change the selection to Remote Desktop Services Installation then click Next
In my environment I will have the three core RDS roles running on a single VM (all-in-one con. If you have a large number of users you will run through the Standard deployment where the three core services run on separate servers.
If you pick a Quick Start setup you can add additional servers to each role to allow expansion. Either option will allow you to grow with your environment!
We are setting up application publishing. Change selection to Session-based desktop deployment and click Next
Since we did the Quick Start selection the Connection Broker, Web Access and Session Host roles will be installed on the single server. Click Next
Check the box labeled Restart the destination server automatically if required then click Deploy
Here is what the progress window looks like. In my install it rebooted after the Remote Desktop Services role but did not for Session Collection and RemoteApp.
Once finished click Close. Remote Desktop Services is now installed!
Publishing Applications:-
A collection is a logical grouping of RDSH servers that application can be published from. Note: Each RDSH server can only participate in a single collection
If you went through the Quick Setup of RDS it will create a collection called “QuickCollection” that contains the applications Wordpad, MS Paint, and Calculator.
To add applications to the collection, click Tasks -> Publish RemoteApp Programs
It will scan your RDSH for installed applications and display them in a list. I have the vSphere Client installed, select your application then click Next
Confirm your application selection(s) and click Publish
Click Close to complete the publish process
RemoteApp Global Permissions:
By default the QuickSessionCollection gives all Domain Users access to Remote App programs. To change this click Tasks -> Edit Properties
Click User Groups. If you wanted to add or remove users Click Add and search.
If you want to remove Domain Users you must first add a user or group first before you can remove it. (There has to be at least 1 in User Groups)
Once you have a second user or group you can now remove Domain Users.
Remember this is at the Collections level. By default all RemoteApp programs inherit these permissions.
RemoteApp Program Permissions:
If you want to change the inherent permissions of a RemoteApp, select the application -> right click and click Edit Properties
Click User Assignment -> then change the option to Only specified users and groups. You can now Add and Remove the permissions inherit from the collection. In my example I wanted only my VMware Admins AD group to have permission to the vSphere Client. Click Apply and Ok to save you changes.
Accessing RemoteApp Programs via the Web Access:
To access your newly deployed RDS environment enter the following address of your RDWeb Access into your browser. Allow the add-on to run if prompted.
https://FQDN-or-IP-Address-of-RDWA-server/RDweb
Once logged in you will see applications that you have access to. If you went through the Quick Setup of RDS it will have created a “Collection” that contains Calculator, MS Paint and Wordpad. Click on a application to launch it. If you get a certificate error click Continue.
The application should launch! If you go to Help -> About you will see Server 2012 instead of the local OS. The application is being ran on the RDSH server and are only viewing it via RDS.
Continue reading – Part 2: Setup RD Licensing Role on Windows Server 2012 R2
When you’re ready to install Microsoft RDS, keep an eye on each component. Some are mandatory in Windows Server 2012 and others aren’t.
If you want to use Microsoft RDS to give users remote access to desktops and applications, you must know how to install it.
Installing Microsoft Remote Desktop Services (RDS) starts with understanding each of its components. In part one of this series, I explained the RDS roles and what each of them does. Before breaking down how to install RDS, let’s review the components:
Remote Desktop (RD) Virtualization Host: Hosts virtual machines
RD Session Host (RDSH): Hosts RemoteApp published applications or session-based desktops.
RD Connection Broker (mandatory): Connects and reconnects users to virtual desktops, RemoteApp published applications and session-based desktops. Distributes load among RD Session Host servers in a session collection.
RD Web Access (mandatory): Allows users to access RemoteApp and desktop connection via the Start menu on Windows 8, Windows 7 or via the Web browser.
RD Gateway (optional): Provides Internet-connected devices access to virtual desktops, RemoteApp published apps and session-based desktops on internal network.
RD Licensing (mandatory): Manages licenses required to connect to RD Session Host collections or virtual desktop collections.
Choosing an RDS installation method
You can install all the roles from a single server using the Microsoft RDS tool via the new Server Manager in Windows Server 2012. Here’s how:
- Open the Server Manager Console and select option three: «Add other servers to manage»
- Add the servers you want to deploy Remote Desktop Services to
- In the Server Manager Console, select option two: «Add roles and features»
- Select «Remote Desktop Services installation»
Then, install RDS in one of two ways:
Standard deployment. With this method, you deploy Microsoft RDS roles to multiple servers. For typical production deployments, choose a standard deployment that allows you to install each role service separately on separate servers if desired.
If you select a Standard deployment, you will be prompted to choose which server(s) you would like to deploy the RDS role services to. For a typical RDS installation where high availability and security are important, you should deploy each component to a dedicated server.
Quick Start. With Quick Start, you install RDS role services onto a single server. This route is usually reserved for proof-of-concepts or very small deployments.
If you choose Quick Start, you will be asked for one server to deploy the RD roles to.
Determining your deployment type
The next step is to select the type of RDS deployment you want to do. Here’s where the first two RDS roles come in. There are virtual machine (VM) based deployments (RD Virtualization Host) and session-based desktop deployments (RDSH).
To deploy Windows 7 virtual desktops, for instance, choose the VM-based deployment, and the wizard will install the Virtualization Host. To deploy RemoteApp published application or session-based desktops, choose the session-based desktop deployment, and the wizard will install the RDSH.
You can deploy both components, but the wizard only allows you to choose one or the other at one time. You will have to run the wizard again to install both RDSH and RD Virtualization Host.
Based on which installation method you chose, the following role services are then deployed to their servers: RD Connection Broker, RD Web Access, and either RD Virtualization Host or Remote Desktop Session Host.
After the installation is complete, you can choose to add RD Gateway and RD Licensing roles to the environment through the Overview screen of the Microsoft RDS Console.
You can also use that screen to install more RDS roles after the initial wizard is complete within the Windows Server 2012 Server Manager console. Right-clicking on any of the components allows you to add or remove additional roles or servers for high availability.
For high availability with RD Web Access and RD Gateway, add two or more servers and use DNS round robin, Windows Network Load Balancing or a third-party load balancing tool. High availability for the RD Connection Broker is also improved in Windows Server 2012 Remote Desktop Services.
Next Steps
Part one: Breaking down RDS roles
What’s remote access?
Simplifying VDI deployment with RDS
What a VMware pro thinks of RDS and RemoteFX
Quiz: How much do you know about Windows Server 2012 RDS?
Dig Deeper on Virtual desktop delivery tools
-
What are RDP file settings and how do they work?
By: Chris Twiest
-
Microsoft Remote Desktop Web Access (Microsoft RD Web Access)
By: Rahul Awati
-
What are RDS CALs and how should IT use them?
By: Ed Tittel
-
Remote Desktop Session Host (RDSH)
By: Margaret Jones
