Archive for Terminal Services

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

June 16, 2015 Terminal Services No comments

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

 

Installing the Microsoft Remote Desktop Gateway Role Service

March 13, 2014 Terminal Services No comments

gw

What is Microsoft Remote Desktop Gateway?

A Remote Desktop Gateway (RD Gateway) server is a type of gateway that enables authorized users to connect to remote computers on a corporate network from any computer with an Internet connection. RD Gateway uses the Remote Desktop Protocol (RDP) along with the HTTPS protocol to help create a more secure, encrypted connection.

In earlier versions of Remote Desktop Connection, people couldn’t connect to remote computers across firewalls and network address translators because port 3389—the port used for Remote Desktop connections—is typically blocked to enhance network security. However, an RD Gateway server uses port 443, which transmits data through a Secure Sockets Layer (SSL) tunnel.

Benefits of an RD Gateway server

  • Enables Remote Desktop connections to a corporate network from the Internet without having to set up virtual private network (VPN) connections.
  • Enables connections to remote computers across firewalls
  • Allows you to share a network connection with other programs running on your computer. This enables you to use your ISP connection instead of your corporate network to send and receive data over the remote connection.

How does RD Gateway work?

When a client makes a connection, RD Gateway first establishes SSL tunnels between itself and the external client. Next, RD Gateway checks the client’s user (and optionally the computer) credentials to make sure that the user / computer are authorized to connect to RD Gateway. Then RD Gateway makes sure the client is allowed to connect to the requested resource. If the request is authorized then RD Gateway sets up an RDP connection between itself and the internal resource. All communication between the external client and the internal endpoint goes through RD Gateway

Connections to RD Gateway use the RDGSP protocol. RDGSP creates two SSL tunnels (one for incoming data and one for outgoing data) from the external client to RD Gateway. Once the tunnels are established the client and RD Gateway establish a main channel over each tunnel. Data between client and the destination machine is sent over the channels and RD Gateway sits in the middle proxying the data back and forth

RD Gateway2

RDGSP uses a transport to create the channels.  In Windows Server 2008 R2, RDGSP used the RPC over HTTP transport. RPC over HTTP is still available for down-level RDP clients, but whenever available, RDP 8.0 clients will use the new and much more efficient HTTP transport. The difference is this: RPC over HTTP makes RPC calls for every data transfer to and from the client. This adds significant CPU overhead. The new HTTP transport does not have this overhead so it’s possible to accommodate up to twice as many RDP sessions on the same hardware.

Important Notes about Certificates

The certificate must meet these requirements:

  • The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. If your organization issues certificates from an enterprise CA, a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
  • The certificate is a computer certificate.
  • The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
  • The certificate has a corresponding private key.
  • The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
  • A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
  • The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the Trusted Root Certification Authorities store on the client computer

Checklist to install the Remote Desktop Gateway Role

  1. Install the Remote Desktop Gateway role service.
  2. Obtain a certificate for the RD Gateway server.
  3. Create a Remote Desktop connection authorization policy (RD CAP)
  4. Create a Remote Desktop resource authorization policy (RD RAP)
  5. Configure the Remote Desktop Services client for RD Gateway.

Install the Remote Desktop Gateway Role

  • Open Server Manager and select Add Roles and Features. You will get the Before you begin page. Click Next

rdgateway1

  • Select Installation Type. Choose Role based or Feature based Installation

rdgateway2

  • Select Destination Server

rdgateway3

  • Select Server Roles. Choose Remote Desktop Services

rdgateway4

  • Click Next on Features

rdgateway5

  • Click Next on Remote Desktop Services Page
  • On the Select Role Services, choose Remote Desktop Gateway

rdgateway7

  • Click Add Features

rdgateway8

  • On the Network Policy and Access Screen, click Next

rdgateway9

  • Leave Network Policy Server checked

rdgateway10

  • Confirm Installation Selections and click Install

rdgateway11

  • Next launch Remote Desktop Gateway Manager by going to Server Manager > Tools > Terminal Services > Remote Desktop Gateway Manager

rdgateway12

  • Select the Servername and you will see several messages to further configure this server

rdgateway13

  • Select View or modify certificate properties
  • You do not need a certification authority (CA) infrastructure within your organization if you can use another method to obtain an externally trusted certificate that meets the requirements for TS Gateway. If your company does not maintain a stand-alone CA or an enterprise CA and you do not have a compatible certificate from a trusted public CA, you can create and import a self-signed certificate for your TS Gateway server for technical evaluation and testing purpose
  • I am going to use a Self-Signed Certificate. Select Create and Import Certificate.

rdgateway14

  • The following screen will come up

rdgateway15

  • It will pop up with a confirmation box below

rdgateway16

  • In the Server Farm tab, enter the name of the Remote Desktop Gateway Server and click Add
  • The add the second Remote Desktop Gateway Server etc if you have one

rdgateway17

  • Now have a look at the other settings
  • Look at General

rdgateway20

  • Look at Transport Setttings

rdgateway18

  • Next is RD CAP Store

rdgateway19

  • Look at Messaging

rdgateway21

  • Look at SSL Bridging

rdgateway22

  •  Look at Auditing

rdgateway23

  • Now we need to define Connection Authorization Policy. Select Create connection authorization policy.

rdgateway24

  • Click Requirements and add your User Groups or Computer Groups

rdgateway25

  • Click on Device Redirection

rdgateway26

  • Click on Timeouts

rdgateway27

  • Next go back to the main console and create a resource authorization policy

rdgateway28

  • Click User Groups and add a group or groups

rdgateway29

  • Click Network Resource

rdgateway30

  • Click Allowed Ports

rdgateway31

  •  Complete
  • Now test your mstsc access!

Useful Step by Step Guide from Microsoft

http://technet.microsoft.com/en-us/library/cc771530%28v=ws.10%29.aspx

PDF Guide

TS Gateway Step by Step Guide

Useful Notes about Certificates

http://go.microsoft.com/fwlink/?LinkID=74577

Useful RD Gateway Firewall Blog

http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx

Resolving Issues

  • You must make sure you have the correct certificates. You must use a certificate with a SAN (Subject Alternative Name) and this must match the internal FQDN.

RDWEB4

  • You must make sure you have set up the correct RAPs and CAPs
  • You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa
  • Make sure you haven’t limited connections
  • Check DNS for individual servers and RDS Farms
  • Check Event Viewer on the Gateway Server > Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway > Operational
  • You may have a Port assignment conflict. You can use netstat tool to determine if port 3389 (or the assigned RDP port) is being used by another application on the Remote Desktop server
  • Users must be a member of the Remote Desktop Group on the servers they want to connect to

If using RD Gateway with RD Web Access then it can be useful to check the following

  • If you are using a Terminal Server Farm, you need to make sure the Start > All Programs > Administrative Tools >  Remote Desktop Services > Remote Desktop Session Host Configuration has the following set for Networking

RDWEB1

RDWEB2

  • Sometimes you may need to check NIC Order in Network Connections

RDWEB3

  • In RemoteApp Manager check you have a FQDN in your RemoteApp Deployment Settings and the port is correct
  • Check RD Gateway Settings are correct. Note I have blanked out the FQDN but this should be the case in these fields

RDWEB5

  • Make sure on each individual RDS Server in a farm that you have the Connection Broker Server and the RD Web Access Server.

Creating a Terminal Services Farm with 2 Servers

February 5, 2013 Terminal Services No comments

images

Requirements

  • 1 x Windows Server 2008 R2 Server
  • 1 x Windows Server 2008 R2 Server
  • 1 x Terminal Services Connection Broker Server (Can be combined with Licensing Server)
  • 1 x Terminal Services Licensing Server (Can be combined with Connection Broker Server)
  • A name for your RDS Farm (Goes in Settings and DNS)

Procedure

  • Go to your DNS Server and add 2 A record entries. One for the first servers IP Address to correspond to the Farm Name and one for the second servers IP Address to correspond to the same Farm Name
  • Next go to your Connection Broker Server
  • Click Start  > Administrative Tools > Remote Desktop Services > Remote Desktop Connection Manager
  • Select RemoteApp Sources
  • Click Add RemoteApp source

RDS20

  • Add your Farm anme
  • Click OK
  • Next Go to the first Terminal server and open Server Manager
  • Click Roles > Add Roles
  • Select Remote Desktop Services

RDS1

  • Click Next

RDS2

  • Click Next and choose Remote Desktop Session Host

RDS3

  •  Click Next

RDS4

  • Click Next and choose your Authentication method for Remote Desktop Session Host.
  • I have chosen Do not require Network Level Authentication but this can be changed afterwards

RDS5

  • Click Next and choose your Licensing Mode
  • I selected Per User for now

RDS6

  • Click Next and add Authorised Users

RDS7

  • Click Next and Configure the Client Experience
  • I just left this blank

RDS8

  • Click Next and Confirm Installation Services > Click Install

RDS9

  • When the install has finished, you will be prompted to restart

RDS10

  • Following reboot, all the server to finish off the installation and then Use the Remote Desktop Session Host Configuration Tool to specify a Remote Desktop License Server

RDS11

  • Click Start > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration
  • In the Edit Settings under licensing, double click Remote Desktop Licensing Mode

RDS12

  • You will get this message

RDS13

  • Click Close and add your license server

RDS14

  • Click OK
  • Next
  • Click the General tab and check the settings

RDS15

  • Click RD IP Virtualisation and just ignore this for now

RDS16

  • Next Click RD Connection Broker

RDS17

  • Before you change this setting, you must make sure that your Remote Desktop Servers are present in the Local Security Group called “Session Broker Computers” in the RD Connection Broker Server

WebAccess

  • Before you change this setting, you must also make sure that the RD Connection Broker Server is added into the Local TS Web Access Computers group on the RDS Session Host Server

SessionHost

  • If you don’t change these, you will get an error like the below one when you try and add the Session Host to a Farm

RDS

  • Click Change Settings and choose Farm Member
  • Enter the RD Connection Broker Name and the Farm Name

RDS18

  • Click OK then select an IP Address to be used for reconnection. This will be your LAN Connection
  • Tick Participate in Connection Broker Load Balancing

RDS19

  •  Now do everything bar the adding the RemoteApp source taskto your second Terminal Server

Other Settings

  • On each Terminal Server, go to the Remote Desktop Session Host Configuration
  • Right click on RDP-Tcp in the Connections Window and have a look through all the settings
  • General

RDS21

  • Log on Settings

RDS22

  • Sessions

RDS23

  • Environment

RDS24

  • Remote Control

RDS25

  • Client Settings

RDS26

  • Network Adapters

RDS27

  • Security

RDS28

 

Terminal Services Profiles and Home Folders

July 3, 2012 microsoft, Terminal Services No comments

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

June 16, 2012 microsoft, Terminal Services No comments

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

Remote Desktop Login always creates a temporary profile

June 13, 2012 microsoft, Terminal Services No comments

Just a quick fix for this as this happened to me today and is a fairly annoying problem

Resolution

  • Log into server as an Administrative User
  • Start > Run regedit
  • [HKEY_LOCAL_MACHINE]\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  • Delete the profile which is failing usually has a .bak extension
  • Try logging in again
  • Success

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

May 21, 2012 microsoft, Terminal Services No comments

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