Tag Archive for RDS

Installing Windows 2012 RDS Roles (License Server, Connection Broker, RD Session Host and RD Web Access)

terminal

Instructions

  • Log into your server
  • Click on Dashboard and under Configure this local server, select Add roles and features

TS1

  • Choose Role based or feature-based installation

TS2

  • Select the destination server for these roles

TS3

  • Select Remote Desktop Services. Click Next

TS4

  • Select any features as required

TS5

  • Read the description and click Next

TS6

  • Select Role Services
  • If you choose the Connection Broker role, it will prompt you to install Windows Internal Database

TS7

  • Choose the RDS Services you need. Note. I am installing 4 roles today

TS8

  • You will see a Web Server (IIS) page. Click Next

TS9

  • Select Role Services. This shows the IIS role services. Leave as they are for now.

TS10

  • Check the Confirm Installation Selections Page. I would tick Restart the destination server automatically if required.

TS11

  • To Activate the Licensing Server, Go to Tools > Terminal Services and Launch Remote Desktop Licensing Manager.
  • You will see it is not activated

TS12

  • Right click on the server and select Activate Server

TS13

  • This will bring up the Welcome to the Activate Server Wizard

TS14

  • You will now see the Connection Method screen

TS15

  • You will need to fill in your company information followed by some optional information. When you have done this click Next. It should then activate your server and ask you if you want to install Licenses

TS16

  • You will now see the Welcome to the Install Licenses Wizard
  • Note you can go try to go through this as we did but it didn’t work with web enrolment. It may work with your setup
  • We had to go back to the Licensing manager and right click on the server > select properties and then change the connection method to Telephone and activate our TS User CALs this way.
  • We the used the below link to call Microsoft to activate our licenses who then gave us back a product key to put in the Install Licenses wizard.

TS17

  • You will now see the License Program Page
  • Select your License Program. In our case it is Service Provider License Agreement
  • Depending on what option you select you will require enrollment numbers or agreement numbers etc

TS21

  • Choose your O/S
  • Choose whether it is Per Device/Per User or VDI Suite.
  • In our case it was 20 Per User Licenses

TS20

  • Click Next and you will see
  • Now go back to your RD Licensing Manager screen and click on Review.

TS22

  • You will see this page

TS23

  • You need to be a Domain Admin to add the license server to the Terminal Servers group in AD

TS24

  • Note at this point if you haven’t managed to activate your user CALs then this the point I mentioned earlier about going to the properties of the server and selecting telephone, phoning Microsoft and getting a key from them to put in the Install Licensing Wizard

TS25

  • Next go back to your 2012 Dashboard and select Add Roles and Features

TS26

  • Choose Remote Desktop Services Installation

TS28

  • You will now be on the Select Deployment Type page. Select your broker server and choose Standard Deployment

TS29b

  • On the Select Deployment Scenario choose Session-based desktop deployment

TS30

  • You will find that the roles we previously installed will come up here
  • Click Next

TS31

  • It will say the RD Connection Broker Server already exists
  • Click Next

TS32b

  • On the Specify RD Web Access Server, put a tick in the box which says “Install the RD Web Access role service on the RD Connection Broker server

TS33b

  • On the Specify RD Session Host servers, select the machine you want the RDS Session host role to be on

TS34

  •  Check the Confirm Selections and tick to Restart the destination server automatically if required followed by clicking on Deploy

TS35

  • It should start to install

TS36

  • Once the RDS Roles are installed, we see the graphical description of our environment, the roles installed on each of the servers and the FQDN names of each server on the Overview page
  • In case you are trying to find the tools that used to be available on a server running the RD Session Host….You can stop looking. The tools Remote Desktop Session Host Configuration and Remote App Manager have been removed from the RD Session Host role in Windows Server 2012. Instead, most of the settings can now be configured using the new Server Manager console, or using the new PowerShell module RemoteDeskop. For other settings, you can still use GPO’s.

TS38

  • Next, we will configure the Session Host
  • Go to Server Manager > Remote Desktop Services > Overview
  • Click on RD Session Host > Tasks > Edit Deployment Properties
  • Ignore RD Gateway
  • On the RD Licensing page select your licensing mode and put in your license server

TS37

  • You can check your RD License Server configuration in Powershell by running the below

TS40

  • You may find that your licensing errors and says “The licensing mode for the remote desktop session host server is not configured”
  • If this is the case, you will need to open gpedit.msc and navigate to the 2 locations below
  • Navigate until : Computer Configuration | Administrative Template | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Licensing
  • Modify Use the specified Remote Desktop License Servers and put in the license server
  • Modify the Remote Desktop Licensing mode to Per User or Per Device depending on your agreement
  • Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing

TS51

  • Next On to Session Collections.
  • Go to Server Manager > Remote Desktop Services > Collections
  • Note: The Connection Broker connects and reconnects users to their virtual desktops, RemoteApp-published applications and session-based desktops. It’s a mandatory RDS component in Windows Server 2012, and it’s installed by default when you deploy Remote Desktop Services. The Connection Broker load-balances requests to RD Session Host servers in a session collection or to virtual desktop pools
  • Click Tasks > Create Session Collection
  • Collections are a logical grouping of Remote Desktop Servers that provides either session-based or virtual machine-based (VDI) deployments.
  • Each Session host that’s a member of an RDS collection is limited to only participating in one collection.

TS41

  • Click Next

TS42

  • Put in a name and description

TS43

  • Specify the RD Session Hosts you want to add to this collection

TS44

  • Specify the User Groups

TS45

  • Specify user profile disks – Uncheck the Enable user Profile Disks checkbox and hit next.

TS46

  • Confirm Selections

TS47

  • You might also want to look into certificates which is accessed from Server Manager > Remote Desktop Services > Overview > Tasks > Edit Deployment Properties

TS48

  • Select Certificates

TS50

  • More information can be found on Microsoft’s webpages 🙂

Some other important information

We also had 2 Terminal servers in this setup which were on a different network. I had to do the following

  • Go to Server Overview
  • Go to Add other Servers to manage

TS52

  • Search and add the servers you need

TS53

  • Once these are added, Go to Server Manager > Remote Desktop Services and add these servers which should now appear. Be careful as it will install the RD Session host role and will reboot the servers.

Load Balancing

If you want full load balancing, your users can use RD Web Access. The GUI for the remote desktop client (on any platform) does not have a way to specify the collection. Connecting to the RD Connection Broker will not load balance, nor would connecting to any RD Session Host server directly. You can manually edit an .rdp file to specify the collection and that process works, but is convoluted for end users. RD Web Access has become the preferred method for disseminating .rdp connection info in 2012 to accommodate the change to collections and the RDCB role.

RD LIcensing Manager

You may notice there is an expiry period on issued licenses in RD LIcensing Manager

RD-Licensing-Expiry

The time is based on the minimum transfer rights in the license agreement which is a Service Provider Agreement. (IBM’s licensing agreement from Microsoft) In this case 60 days.

The license agreement is a part of the purchase. It varies by region and by how you purchased it. It is a legally binding document and describes how the purchased product can be used. For example, an OEM server license offend includes the stipulation that it cannot be transferred to a new machine at all. The discounted OEM pricing benefit comes at the cost of reduced mobility.

For CALs, it is common to see restrictions stating that a CAL can only be transferred to a new user every 60/90/120 days. This allows you to reassign a CAL in the event a user had to be dismissed, but prevents abuse by using one user CAL for multiple shift users by claiming “I transfer the CAL every 8 hours.”

SO in theory you buy the amount of licenses for the amount of users you have. So say you have 20 licenses and 20 users log in and take a license. If for some reason a 21st person logs in, the system will allow it because it will assign a temporary CAL however this is a breach of your license agreement until another CAL expires and is released after the 60 days. Note that TS/RDS CALs are *not* legally licensed by concurrent users, but by TOTAL users. So if you have 50 users, but only expect 17 to be logged on at a time. You still need 50 CALs. Not 10, or even 20. The same applies to device licensing and device CALs. You pay for total devices, not concurrent devices. Which in the era of mobility, BYOD, and similar trends, can be an unknown, making user licensing more flexible in most (but not all) circumstances.

Other good links

http://ryanmangansitblog.com/2013/09/27/rds-2012-deployment-and-configuration-guides/

http://pdfs.loadbalancer.or/Microsoft_Remote_Desktop_Services_Deployment_Guide.pdf

 

Terminal Services Profiles and Home Folders

Many Administrators misunderstand the use of the Terminal Services Home Folder. The setting which can be configured as part of the user account or through Group Policy determines the location of a folder that is used by Terminal Services to store user specific files for multi user applications.

Logging in Using the Terminal Services Client Software

(Remote Desktop Services User Profile)

Specifies the profile path assigned to the user when the user connects to an RD Session Host server.
Assigns the user a separate profile for Remote Desktop Services sessions. Many of the common options that are stored in profiles, such as screen savers and animated menu affects, are not desirable when using Remote Desktop Services

  • If a Terminal Services Profile is specified, this path is used.
  • If this path is not specified, but a User Profile is specified, this path is used.
  • If neither path is specified, an existing local profile is used, or one is created in the %SYSTEMDRIVE%\Documents and Settings\%username% folder.
  • If both a Terminal Services Profile and a User Profile are specified, the Terminal Services Profile is used.

(Remote Desktop Services Home Folder)

  • If a Terminal Services Home Directory is specified, this path is used.
  • If this path is not specified, but a Home Folder is specified, this path is used.
  • If neither path is specified, the Home Directory is set to the %SYSTEMDRIVE%\Documents and Settings\%username% folder.
  • If both a Terminal Services Home Directory and User Home Folder are specified, the Terminal Services Home Directory is used.

Planning a Terminal Services Deployment

The first step in planning a deployment is understanding how the following Terminal Sever components fit together

  • Terminal Server

The server itself is at the core component of a Terminal Services deployment. This is the server that the clients connect to so they can access their applications

  • Terminal Server Farm

A Terminal Server farm is a collection of Terminal Servers used to provide high availability and load balancing to clients on an organisational network. Client connections to Terminal Server Farms are mediated by Terminal Services Session Directory Servers. Terminal Server farms are more likely to be deployed at large sites than small ones

  • License Servers

License servers provide Terminal Server Client Access Licenses (TS CALS) to Terminal Servers on the network. Unless a license server is deployed, clients are only able to connect to Terminal Services for a limited time only.

  • Terminal Services Gateway Servers (TS Gateway)

These servers provide access to Terminal Servers to clients on untrusted networks. In Enterprise networks, you can use a TS Gateway server as a bridge between the standard internal network and a Terminal Server farm on a network protected by server isolation policies

Terminal Server Licensing

All clients that connect to a Terminal Server require a TS CAL. This license is not included with the O/S a client uses or a standard server license.

TS CALs are managed by a Terminal Server Licensing server

  • What is the scope of the licensing server. Will it service clients in the domain or workgroup or manage the licenses for all clients in the forest
  • How will the license server be activated with Microsoft. Automatic, Web Browser or Telephone
  • How many license servers do you need for your organisation?
  • What type of licenses will be deployed

Terminal Server Session Broker

The Terminal Server Session Broker service simplifies the process of adding more capacity to an existing Terminal Services Deployment. It enables Load Balancing of terminal services in a group and ensures the reconnection of clients to existing sessions in that group. In Terminal Server Session Broker, a group of Terminal Servers is called a Farm.

The Terminal Server Session Broker is a database which keeps track of TS sessions. TS can work with DNS Round Robin or with NLB. When configured with NLB, the Terminal Server Session Broker Service monitors all servers in the group and allocates clients to to the servers which have the most amount of free resource.

When used with DNS Round Robin, clients are still distributed, the main benefit being is that Terminal Server Session Broker remembers where a client is connected. TS Load Balancing is restricted to Windows 2008 Terminal Servers only

Clients must support RDP 5.2 or later

Each Terminal Server must have the same application configuration

The following diagram provides a more detailed representation of the traffic flow. In the diagrammed scenario, all terminal servers in the farm have host resource records in DNS that map to the terminal server farm name (“Farm1”). Therefore, any terminal server in the farm can act as a redirector and process the initial connection requests

http://technet.microsoft.com/en-us/library/cc772418(v=ws.10).aspx

Terminal Server Gateway Server

Plan the deployment of Terminal Server Gateway Servers when you need to enable RDP over HTTPS connections to RDP Servers located on Protected internal networks to clients on the internet or untrusted networks. TS Gateway servers are not limited to screened subnets between internal networks and the internet but can also be deployed to enable access to servers that are the subject of IPsec isolation policies

What is the /admin switch in Microsoft Terminal Services Client (MSTSC) for Windows 2008 and Vista?

Although the /console switch no longer has any effect on Server 2008 and Vista Terminal Server connections, a new switch called the /admin switch has a similar effect when you use it to connect to a Server 2008 server with the Terminal Services role. When you use this switch with MSTSC, connections don’t consume Terminal Services CALs.

The /admin switch involves elevated rights. If a user has the authority to use the /admin switch but has been marked with Deny Users Permissions To Log On To Terminal Server, he or she will be able to connect using mstsc /admin. Also, if a terminal server is in drain mode (no new sessions are accepted), an /admin session can still be created. The /admin sessions don’t count toward the session limit that may be configured on a terminal server to limit the number of session