Windows Terminal Services for Remote PVSS Access Peter

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

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

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

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

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

Remote desktop clients (RDC) Implemented in Windows XP n Clients available for n Ø Windows 95/98/98 SE/ME/NT 4/2 k Ø Windows CE – allows for using palmtops on client side! Ø Linux Ø MAC OS X 10. 2. 8 or later n Web based interface available for Active. X enabled browsers

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

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

Benefits from TS and RDC n Centralized maintenance of remote UI projects Ø n Low-bandwidth access to data Ø Ø Ø n No need to install project on each client machine 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 Ø Ø 128 bit bi-directional RC 4 encryption (client dependent) Additional FIPS compliant encryption level

Enhancing security on TS user rights can be assigned to individual users or groups n 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 PVSS 00 NV, (closing this application would terminate the connection)

Windows TS capacity n n 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) 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

Server capacity estimate Server Configuration Knowledge Worker Data Entry Worker 4 x Intel Xeon MP 2 GHz, 4096 MB 270 520 2 x Intel Xeon 2. 4 GHz, 4096 MB 200 440 1 x Intel Xeon 2. 4 GHz, 4096 MB 140 200 50 120 4 x Intel Pentium III 0. 8 GHz, 1024 MB

Estimated memory requirements n Total recommended memory for TS: 128 MB + (# of users) * (Memory per user) n 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 preliminary)

Windows 2003 Server Editions n Four editions available Ø Ø n 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

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

Overview of TS licensing n Two licensing modes Ø Ø n Per user Per device 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 Ø Ø Ø n 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

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

Cloning of CERN TS for experiments n n 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 Ø n Credits and thanks to Ruben D. Gaspar Aparicio BUT!: Ø Ø We can profit from CERN License Server A reasonable number of licenses (~5000) available at CERN (out of them ~300 presently in use)

Test Setup in ALICE CERN network RDC PVSS Master Projects Private network 2 x W 2003 Enterprise Edition running TS RDC PVSS Master Projects

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

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

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

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

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

Tests to perform n n Look on the effect on users if one user initiates a high CPUload task Present status: Ø Ø Ø n 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: Ø Ø Ø Identify high CPU-load tasks which are needed Look on the effects and define policies See how clustering helps

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

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

Tests to perform n n Determine the behavior if the connection to the WTS is lost (also on PVSS system if any) Present status: Ø Ø Ø n 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: Ø Perform more tests with big systems ( also on NLB cluster to check the roaming)

Tests to perform n n Identify the requirements for licensing Present status: Ø Ø n 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: Ø Ø Ø Read again the description of non-trivial MS licensing model Follow the developments of Longhorn Servers (present licensing model is completely different from W 2000) Discuss future support with IT

Tests to perform n n Look at any possible security issues with this approach and how to minimize the risk Present status: Ø Ø The approach is recommended by CERN security team Additional tests scheduled in ALICE for July Ø Ø n 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: Ø Ø 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

Tests to perform n n Look at how to handle login (single or multiple) Present status: Ø n We looked so far only at local policies and defined a group of users 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)

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

Additional tests n 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) n Understand user requirements n Study related technologies (e. g. SFU, SUS…) n What else did we forget? n

Conclusions n 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) No major problems discovered so far n We will continue our tests and report the results n n Ø Any help is appreciated