Designing deploying and supporting windows terminal services at cern
1 / 23

- PowerPoint PPT Presentation

  • Updated On :

Designing, Deploying and Supporting Windows Terminal Services At CERN. by Ruben Gaspar IT – Internet Services Group CERN. Overview. What is? What for? Architecture Implementation System Management issues Conclusions. What are “Terminal Services”. Alias “Remote Desktop”

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - DoraAna

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Designing deploying and supporting windows terminal services at cern l.jpg

Designing, Deploying and Supporting Windows Terminal ServicesAt CERN


Ruben Gaspar

IT – Internet Services Group


Overview l.jpg

  • What is?

  • What for?

  • Architecture

  • Implementation

  • System Management issues

  • Conclusions

What are terminal services l.jpg
What are “Terminal Services”

  • Alias “Remote Desktop”

  • Allows a remote windows session from a computer to another computer, not necessarily running Windows

  • Multi user environment supported in Windows 2000 Server and Windows 2003 Server

    • Also built-in Windows XP professional, but restricted to 1 simultaneous user (remote desktop)

Introduces duality on something that is today very successful l.jpg
Introduces duality on something that is today very successful

Windows / Mac / Linux Client

with X-terminal


Linux / Mac / Windows Client

with remote desktop


Windows Terminal Services


Motivations l.jpg
Motivations successful

  • A step forward in Linux / Windows / Mac integration

  • Reduces (but does not replace) the need for …

    • VMWare, Virtual PCs and windows emulators, Multi boot installation, …

    • “does not replace” because network access is required

  • User’s motivations

    • I am on Macintosh/Linux and I need access to Windows applications

    • I am not at CERN and I want access to the CERN environment

    • Security (Controls, ACB, VPN, …)

    • I do not have that particular application installed, I cannot install it, but I need it.

      • License reasons

      • Complex installations centrally managed

    • I have a slow computer and I want a faster one

The service l.jpg
The service successful

  • Service started at 1st April 2004 following March Desktop Forum

    • Limitation of 50 simultaneous sessions (manpower issue)

  • Well defined Service Manifest establishes an SLA

    • Active sessions have no time limit

    • Idle and disconnected sessions will be logged off after 18 hours

    • RSA RC4 (128 bits encryption key) required to connect

    • Profile limited to 500 MB

    • Only core 16 applications available to users. Additional applications can be installed only following management approval and must pass technical criteria. Dedicated service may be necessary for some applications (see later)

    • It becomes the recommended solution for other services:

      • Public PC areas

      • GPRS

    • Designed to be clonable and customized to cover specific needs, while preserving central manageability (see later)

      • Complete documentation available in the Internals site

Core applications l.jpg
Core Applications successful

The architecture l.jpg
The architecture successful

  • A farm of servers behind a unique name:

  • Load balancing automated across farm nodes + session directory

    • Able to reconnect to the correct node on disconnected sessions

  • User profiles and settings independent on the application server node

  • License Server: provides a client pc with rights to access an application server

  • Highly scalable, redundant, reliable

Slide9 l.jpg

Architecture - Session Directory successful

5. Server authenticates “JaneDoe” and checks Session Directory for existing session

8. Session broken down on TS-2. Client reconnects to load-balancer with token and credentials


Session Directory

6. SD informs TS that user has a session on TS –3














Load-Balancer (LB-1)

3. Server responds

1. User connects to load-balancer

7. TS returns user credentials with token and tells client to reconnect


4. User enterscredentials

2. Load Balancer (F5, Radware) routes user to “least-loaded” server

9. Load-balancer examines token and directs connection to TS3, passing through credentials

User session on TS-3

10. Original session from TS3 presented to user


User profiles and settings l.jpg
User profiles and settings successful

  • Terminal services profile different from standard NICE profiles

    • Avoid incompatibilities with desktop application settings

  • One profile server for Windows terminal services

    • Provide an homogenous look and feel (feeling of connecting always to the same machine)

  • Desktop, Favorites, My Documents are redirected

    • Same home directory server

    • Provide an homogenous, similar environment between desktop and TS sessions

Slide11 l.jpg

4 successful




Standard Windows

Desktop session










Home Directory Server

(My documents, Favorites, Desktop)

License server l.jpg
License Server successful

  • All Application servers in the farm require the existence of a license server that keeps tracks of client certificates

  • This service was installed in the session directory server

  • It is also used by non-central terminal services farms

    • A central accounting mechanism for all Application servers within the organization

    • Licenses rely on the Microsoft Campus agreement

Technical implementation l.jpg
Technical implementation successful

  • Currently two machines CERNTS03/04

    • Load balancing installed

    • All machines in the same network segment. Foreseen 8 IPs.

    • Data and System located in different Volumes

    • Careful permission settings on File System

      • Write privilege only on User profile location

      • Quotas possible but not yet enforced

  • Dedicated server for the session directory and license server

  • Dedicated server for terminal service profiles

    • Configured as Windows roaming profile servers

    • Can be used also by non-official terminal servers

  • All based on Dual Xeon CPU and Server 2003 technology

  • Standard backup mechanism

  • Several scripts developed for monitoring the service and logging usage

    • Aim to reach a complete automated service

Using the service l.jpg
Using the service successful

  • Windows Terminal Services site:

  • Registration is mandatory

    • Under discussion to void this requirement

  • User can manage its TS profile

  • Internet explorer users can connect from the browser


  • Service address:

  • Client software available to all platforms

    • Detailed instructions and documentation on the WTS web site

    • See Windows clients, Linux clients, Macintosh clients

Slide15 l.jpg

DEMO successful

Usage statistics l.jpg
Usage Statistics successful

  • Registered users: 782 - Active Users: 460

  • License server has distributed 400 client licenses

    • Client licenses expires after 90 days

  • Peak of simultaneous sessions: 45

    • Remember: Max limit set to 50

  • Average sessions per day: 36

  • Average session duration per day: 10h20

Applications usage l.jpg
Applications Usage successful

Conclusions and issues l.jpg
Conclusions and Issues successful

  • Feedback from the User community encouraging

  • Stable set of applications

  • Manpower available for long term service evolution still unclear

    • Remember Max 50 users limit will be hit soon

    • Applications management and Security (Patch, hot fix installation)

  • Many requests to install additional application, centrally managed

    • No clear process to decide what is core and non core

  • Many pending requests from other groups to have “cloned” services running specific applications

    • Currently we can give only technical advices

    • They need to use official service infrastructure, profiles, licensing

      • LHCB build service

      • AB/CO controls applications

      • ST/MA Asset Tracking and Maintenance Management

      • EP/SFT for several custom applications

      • IT/PS for some engineering applications

  • Support ([email protected]):

    • Second and third line support missing

    • User questions and answers

Slide23 l.jpg

Questions successful