1. Windows Terminal Services for Remote PVSS Access Peter Chochula – ALICE 17 June 2004

2. Outline Motivation Motivation Technology : RDP, RDC, Windows Server 2003 Technology : RDP, RDC, Windows Server 2003 CERNTS, licensing issues CERNTS, licensing issues ALICE Test Setup ALICE Test Setup Tests to be performed Tests to be performed

3. Motivation for using TS Remote access to control systems is required by several groups Remote access to control systems is required by several groups We were looking for secure and reliable solution We were looking for secure and reliable solution Number of protocols passing through CERN’s firewall should be limited to minimum Number of protocols passing through CERN’s firewall should be limited to minimum CERN’s security team recommends TS in conjunction with PVSS remote UI as a preferred solution CERN’s security team recommends TS in conjunction with PVSS remote UI as a preferred solution

4. Remote Connection to Control Systems (basic ideas) Remote client CERN’s firewall W2003 TS Control System Remote desktop connection over VPN PVSS Remote UI PVSS Master Projects

5. Technology behind the Windows TS Windows 2003 TS component is an evolution of Terminal Services Windows 2003 TS component is an evolution of Terminal Services Allows for delivery of Windows based applications to remote (even non-Windows) computers Allows for delivery of Windows based applications to remote (even non-Windows) computers Secure communication with clients is based on RDP (remote data protocol Secure communication with clients is based on RDP (remote data protocol

6. Remote desktop clients (RDC) Implemented in Windows XP Implemented in Windows XP Clients available for Clients available for  Windows 95/98/98SE/ME/NT4/2k  Windows CE – allows for using palmtops on client side!  Linux  MAC OS X 10.2.8 or later Web based interface available for ActiveX enabled browsers Web based interface available for ActiveX enabled browsers

7. Client Resource redirection File System File System  Client drives are mounted inside server session Ports Ports  Client COM and LPT ports can be mounted to the server Audio Audio  Sound can be redirected to client Printers Printers  Client printers (including networked) are visible to server Windows keys Windows keys  Combinations such as ALT-TAB etc. can be redirected to server (CTRL-ALT-DEL is disabled for security reasons)

8. Additional features Time Zone redirection Time Zone redirection  RDC client can provide its time zone to the server – this allows for working across different time zones (makes sense for agenda etc.) Virtual channels Virtual channels  provide possibility to enhance communication between client and application running on server Roaming disconnects Roaming disconnects  Allow for reconnection to disconnected sessions Clipboard mapping Clipboard mapping  Copy/Paste support between client and server 24-bit color support 24-bit color support

9. Benefits from TS and RDC Centralized maintenance of remote UI projects Centralized maintenance of remote UI projects  No need to install project on each client machine Low-bandwidth access to data Low-bandwidth access to data  Only screen view of the data is transmitted  RDP provides techniques such as data compression or persistent bitmap caching  Connection optimization based on network bandwidth High level of security High level of security  128 bit bi-directional RC4 encryption (client dependent)  Additional FIPS compliant encryption level

10. Enhancing security on TS TS user rights can be assigned to individual users or groups TS user rights can be assigned to individual users or groups Software restriction policies Software restriction policies  Administrators can allow only certain programs to be run by specified users  Client settings can be overridden by server  Client access can be restricted to PVSS00NV, (closing this application would terminate the connection)

11. Windows TS capacity MS provides tools for measuring the performance of servers MS provides tools for measuring the performance of servers Rough estimates based on “Knowledged workers” and “Data Entry workers” groups (as defined by the Gartner group) Rough estimates based on “Knowledged workers” and “Data Entry workers” groups (as defined by the Gartner group) Server is considered to be at capacity when it is 10% slower as it was with single user load Server is considered to be at capacity when it is 10% slower as it was with single user load Numbers should be taken as a guide, real test must be done with PVSS in order to verify our real needs Numbers should be taken as a guide, real test must be done with PVSS in order to verify our real needs

12. Server capacity estimate Server Configuration Knowledge Worker Data Entry Worker 4x Intel Xeon MP 2 GHz, 4096 MB 270520 2x Intel Xeon 2.4 GHz 2.4 GHz, 4096 MB 200440 1x Intel Xeon 2.4 GHz, 4096 MB 140200 4x Intel Pentium III 0.8 GHz, 1024 MB 50120

13. Estimated memory requirements Total recommended memory for TS: Total recommended memory for TS: 128 MB + (# of users) * (Memory per user) Where memory per user can be estimated as Where memory per user can be estimated as  9.5 MB for Knowledge workers  3.5 MB for Data Entry workers  We measured ~3-30 MB for Remote UI projects (very very preliminary)

14. Windows 2003 Server Editions Four editions available Four editions available  Web edition (no TS support)  Standard Edition  Enterprise Edition  Datacenter Edition (optimized for mission critical applications - large database servers etc. ) In our evaluation we focused on Standard and Enterprise editions In our evaluation we focused on Standard and Enterprise editions

15. Comparison between Standard and Enterprise Editions Only “relevant” parameters are listed Only “relevant” parameters are listed For details see http://www.microsoft.com/windowsserver2003/evaluation/features/compareeditions.mspx For details see http://www.microsoft.com/windowsserver2003/evaluation/features/compareeditions.mspx Standard Edition Enterprise Edition Max. memory per server 4 GB 16/32 GB NLB cluster nodes 1632 Server Cluster Nodes (failover for applications) N/A8 64bit support (Itanium) NOYES Price (rough estimate) ~USD 1000 ~USD 4000

16. Overview of TS licensing Two licensing modes Two licensing modes  Per user  Per device License is issued to the client by the server License is issued to the client by the server  License server provides a pool of licenses  Licenses are not returned to the pool after disconnecting the session  E.g. a colleague using a laptop goes away with the license  Reformatting a client disk wipes out the license  Unused licenses will be returned to pool after a timeout period (~80 days) If the connection to licensing server is lost, TS issues temporary licenses to clients If the connection to licensing server is lost, TS issues temporary licenses to clients

17. TS at CERN Central service provided by CERN’s IT is now operational (CERNTS) Central service provided by CERN’s IT is now operational (CERNTS) User rights are restricted to minimum (basically the user is allowed to use only the Office applications) User rights are restricted to minimum (basically the user is allowed to use only the Office applications) No possibility to install new software by the user No possibility to install new software by the user PVSS support not foreseen PVSS support not foreseen

18. Cloning of CERN TS for experiments No manpower for central maintenance of additional TS available No manpower for central maintenance of additional TS available We were offered help with installation of the servers and setting-up of licensing and local policies We were offered help with installation of the servers and setting-up of licensing and local policies  Credits and thanks to Ruben D. Gaspar Aparicio BUT!: BUT!:  We can profit from CERN License Server  A reasonable number of licenses (~5000) available at CERN (out of them ~300 presently in use)

19. Test Setup in ALICE CERN network 2x W2003 Enterprise Edition running TS PVSS Master Projects RDC Private network RDC PVSS Master Projects

20. Tests to perform A preliminary list of tests to be performed has been prepared A preliminary list of tests to be performed has been prepared  Credits Wayne, Bruce Some test were already done – as a proof of the concept Some test were already done – as a proof of the concept Systematic tests will be performed this summer Systematic tests will be performed this summer Everyone is invited to participate Everyone is invited to participate Following slides show the status and should trigger discussion Following slides show the status and should trigger discussion

21. Tests to perform Understand what is needed to set-up a WTS able to run PVSS UIM Understand what is needed to set-up a WTS able to run PVSS UIM Present status: Present status:  2 Servers installed (180 day trial of Enterprise Edition) and created remote UI projects To be done: To be done:  Check if this is what we need  People should have a look at the service and comment

22. Tests to perform Understand what is needed to set-up a WTS cluster able to run PVSS UIM Understand what is needed to set-up a WTS cluster able to run PVSS UIM Present status: Present status:  NLB cluster setup in progress – it will be setup on private network To be done: To be done:  Test the performance  Decide if we really need a server cluster (tending to say “no”)

23. Tests to perform Understand how to set-up the access to multiple different (10) of PVSS systems Understand how to set-up the access to multiple different (10) of PVSS systems Present status: Present status:  Simultaneous access to 2 systems tested (even across CERN’s firewall) To be done: To be done:  Test the performance  Perform tests with more realistic (big) projects (scheduled for early July)

24. Tests to perform Understand the load of the WTS in the previous cases Understand the load of the WTS in the previous cases Present status: Present status:  Rough estimate done, will be repeated with proper tools To be done: To be done:  Perform tests with realistic (big) projects  Sort of “data challenge” would be needed  Your help would be really appreciated

25. Tests to perform Look on the effect on users if one user initiates a high CPU- load task Look on the effect on users if one user initiates a high CPU- load task Present status: Present status:  Tested a policy which allows to execute only remote UI projects  High CPU-load tasks can be killed by administrator  Test should be done with proper tools – e.g. Values from Task Manager could be misleading. We will follow the test methodology proposed by Microsoft To be done: To be done:  Identify high CPU-load tasks which are needed  Look on the effects and define policies  See how clustering helps

26. Tests to perform Try access to the WTS from Windows machines (XP,2000,NT), Linux and MAC Try access to the WTS from Windows machines (XP,2000,NT), Linux and MAC Present status: Present status:  We tested RDC with XP, Windows 2000, Windows 98 SE and Linux To be done: To be done:  Perform tests with MAC, Windows CE ….

27. Tests to perform Determine the behavior if the connection between WTS and PVSS is lost (also on PVSS system if any) Determine the behavior if the connection between WTS and PVSS is lost (also on PVSS system if any) Present status: Present status:  Temporary cut the connection between WTS and network  Operation correctly resumes if the disconnection is shorter than ~7s  Otherwise the remote UI loses connection and has to be restarted  No effects on master PVSS project observed To be done: To be done:  Perform real tests

28. Tests to perform Determine the behavior if the connection to the WTS is lost (also on PVSS system if any) Determine the behavior if the connection to the WTS is lost (also on PVSS system if any) Present status: Present status:  RDC allows for re-connection to a disconnected session – tested even across CERN’s firewall (and it works)  On server side a policy can be defined which kills disconnected sessions after a predefined timeout  We were able to reconnect to a session even after 3 days To be done: To be done:  Perform more tests with big systems ( also on NLB cluster to check the roaming)

29. Tests to perform Identify the requirements for licensing Identify the requirements for licensing Present status: Present status:  Discussed with IT, our test server is recognized by CERN License server  Seems to work (tested with ~20 simultaneous connections to WTS) To be done: To be done:  Read again the description of non-trivial MS licensing model  Follow the developments of Longhorn Servers (present licensing model is completely different from W2000)  Discuss future support with IT

30. Tests to perform Look at any possible security issues with this approach and how to minimize the risk Look at any possible security issues with this approach and how to minimize the risk Present status: Present status:  The approach is recommended by CERN security team  Additional tests scheduled in ALICE for July  A firewall will be placed between the WTS and PVSS projects running on private network  Several tests will be performed at private network (Administrative Circular Nr. 5 restricts the tests on CERN’s network) To be done: To be done:  This is a critical issue with many consequences and has to be studied carefully with help of CERN Security and Network teams  One should especially look at resource sharing as this is a potential source of problems

31. Tests to perform Look at how to handle login (single or multiple) Look at how to handle login (single or multiple) Present status: Present status:  We looked so far only at local policies and defined a group of users To be done: To be done:  This topic has to be followed – what are the requirements?  The client can securely share credentials with WTS  File system permission between Windows and Unix could be also handled by Windows Services for Unix (SFU) – it provides NFS server and client, password synchronization etc. (we installed SFU and will test it soon)

32. Tests to perform Look at performance when changing frequently the panels or when panels are frequently modified Look at performance when changing frequently the panels or when panels are frequently modified Present status: Present status:  Pending To be done: To be done:  It has to be done

33. Additional tests All tests should be done more systematically and with more realistic systems All tests should be done more systematically and with more realistic systems  So far we tried just to check the concept Identify bottlenecks (e.g. network influence) Identify bottlenecks (e.g. network influence) Understand user requirements Understand user requirements Study related technologies (e.g. SFU, SUS…) Study related technologies (e.g. SFU, SUS…) What else did we forget? What else did we forget?

34. Conclusions Concept of TS has been studied in ALICE Concept of TS has been studied in ALICE Test setup including 2 Enterprise servers is operational (we will be forced to reinstall at least one server by the end of July – grace period is over) Test setup including 2 Enterprise servers is operational (we will be forced to reinstall at least one server by the end of July – grace period is over) No major problems discovered so far No major problems discovered so far We will continue our tests and report the results We will continue our tests and report the results  Any help is appreciated