Designing, Deploying and Supporting Windows Terminal Services At CERN

1. Designing, Deploying and Supporting Windows Terminal ServicesAt CERN by Ruben Gaspar IT – Internet Services Group CERN

2. Overview • What is? • What for? • Architecture • Implementation • System Management issues • Conclusions

3. 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)

4. Introduces duality on something that is today very successful Windows / Mac / Linux Client with X-terminal software Linux / Mac / Windows Client with remote desktop software Windows Terminal Services LXPLUS

5. Motivations • 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

6. The service • 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

7. Core Applications

8. The architecture • A farm of servers behind a unique name: cernts.cern.ch • 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

9. Architecture - Session Directory 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 TS-3 Session Directory 6. SD informs TS that user has a session on TS –3 TS-1 LB-1 TS-3JaneDoe *********** LB-1 TS-3JaneDoe *********** LB-1 TS-3JaneDoe *********** JaneDoe *********** JaneDoe 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 TS-2 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 TS-3

10. User profiles and settings • 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

11. 4 1 CERNTS.cern.ch 2 6 Standard Windows Desktop session cernts0X cernts04 cernts03 cernprofts 5 7 cernprof 3 LICENSE Server Home Directory Server (My documents, Favorites, Desktop)

12. License Server • 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

13. Technical implementation • 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

14. Using the service • Windows Terminal Services site: http://cern.ch/terminalservices/ • Registration is mandatory • Under discussion to void this requirement • User can manage its TS profile • Internet explorer users can connect from the browser • http://cern.ch/wts/TSWeb/cerntslb.htm • Service address: cernts.cern.ch • Client software available to all platforms • Detailed instructions and documentation on the WTS web site • See Windows clients, Linux clients, Macintosh clients

15. DEMO

16. Terminal services site

17. Outlook 2003 at WTS

18. Saving a doc in your WTS profile

19. Usage Statistics • 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

20. Average Simultaneous sessions

21. Applications Usage

22. Conclusions and Issues • 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 (support-terminalservices@cern.ch): • Second and third line support missing • User questions and answers

23. Questions