How Terminal Services Licensing Works
All communication during the licensing process occurs between the client and the terminal server, and between the terminal server and the license server. The terminal server client never communicates directly with the license server.
When a client device attempts to connect to a terminal server in Per Device mode, the terminal server determines if the client has a license token. Terminal server clients store license tokens in the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing
If a client has no license token, the terminal server attempts to contact a license server from its list of discovered license servers. If no contact is made, the terminal server restarts the discovery process. If no license server responds, the device can not connect to the terminal server unless it is operating within the terminal server grace period.
When a license server responds, the terminal server requests a temporary token for the device because this is the first time the device has connected to a terminal server. The terminal server then pushes this temporary token to the device. After a user has provided valid credentials resulting in a successful logon, the terminal server instructs the license server to mark the issued temporary token as validated.
The next time a user attempts to connect to a terminal server in Per Device mode from this device, the terminal server requests a Windows Server 2003 TS Device CAL token for this device. If the license server has available TS Device CAL tokens, the license server removes one token from the available pool, marks it as issued to the device, logs the device name, the user name of the device, and the date issued, and then pushes this TS Device CAL token to the device.
If the license server has no TS Device CAL tokens, it will first look to any other license server in its domain, workgroup, or site. License servers maintain information about where other accessible license servers exist, and if they have license tokens. If another license server is accessible that does have inventory, the first license server will request a license token from the second license server and deliver it to the terminal server, which then passes the token to the client device. If there are no available TS Device CAL tokens, the device will continue to connect with the temporary token.
Temporary tokens allow devices to connect for 90 days, and will then expire. TS Device CALs, while representing perpetual licenses, are set to expire 52-89 days from the date they are issued. The terminal server always attempts to renew these tokens 7 days prior to their expiration. The purpose of this system is to recover TS Device CAL tokens that are lost due to events such as hardware failure or operating system reinstallation.
——————————————————————————————————————————————————————-
Terminal Services Session Directory Service
Session Directory is a load balancing feature that enables users to easily reconnect to a disconnected session on a server farm running Terminal Services. The Session Directory is a database that tracks user session’s that are running on load-balanced terminal servers. It provides information when a user reconnects (after disconnecting intentionally or because of a network failure) to ensure that the user reconnects to the same session rather than starting a new session. Session Directory, which can support several thousand sessions, is also cluster-aware. Session Directory is compatible with the Windows Server 2003 load balancing service and is supported by third-party external load balancer products
How Session Directory Works
An incoming connection to the cluster is load balanced to one node, which provides the logon prompt.
When the user logs on to the Terminal Server cluster, the Terminal Server receiving the initial client logon request sends the user name to the Session Directory server.
The Session Directory server checks the user name against its database and sends the result to the requesting server. The Session Directory database is a jet database containing a list of sessions indexed by user name.
If the user has no disconnected sessions, the log on process continues at the server hosting the initial connection.
If the user has a disconnected session on another serer, the initial hosting server sends the client information necessary for the client to continue authentication against the server hosting the disconnected session. The transition from one server to the other is transparent to the user.
When the user logs on to the disconnected session, the Session Directory is updated.
The Terminal Server Session Directory database is updated and queried by the Terminal Servers whenever users log on, log off, or disconnect from a session.
Whether you’re looking for troubleshooting tips, deep dives into systems architecture, or the latest in cloud computing, I’m here to help you navigate the evolving tech landscape. Let’s connect, learn, and grow together!
📧 ravi.chopra1709@gmail.com
- Top Azure Interview Questions with Expert Answers (Scenario Based) - 22 December 2024
- Entra ID (Azure Active Directory): Migration and Integration Guide - 20 December 2024
- Active Directory Federation Services (ADFS): Implementation Guide - 16 December 2024