Presentation on theme: "Microsoft Terminal Server at CLRC Current Use and Future Plans Chris Brew Thanks to Mark Enderby (SRD), Tony Valente (ISIS) and Mike Waters (ITD) for extra."— Presentation transcript:
Microsoft Terminal Server at CLRC Current Use and Future Plans Chris Brew Thanks to Mark Enderby (SRD), Tony Valente (ISIS) and Mike Waters (ITD) for extra information.
Contents Terminal Server Applications within CLRC –Office Applications for Unix Users (SRD & ITD) –Terminal Server and Clients in ISIS –Chubby Client Computing (PPD) Terminal Server Load Tests (ISIS & PPD)
Terminal Server Official mutli-user interface to windows NT - replaces 3rd party products like NTrigue, WinDD Clients available for Microsoft OSs 3rd party (Citrix) add-on give clients for other platforms Further add-on (NCD) gives X access Dedicated winterms are available similar in idea to X-terms Can run full desktop or just a single application
Pros and Cons Pros –Upgrade Once/Affects Many –With WinTerms: Plug in and go computing –Lowers the support load? Cons –NT wasnt written as Multi-User OS –Most software wasnt written as Multi-User –Both the above cause problems!
Office applications for Unix Users Service running in SRD for ~1 year –450MHz PII, 384MB memory –20-25 active users at any one time –Office applications + a few other utilities ITD Service now running –Replaces already running WinDD Service –Dual 450MHz PII, 512MB memory –~30 active users –Very steep learning curve
SRD Experience (1) Application Installation: –Easy(ish) if applications come TSE ready –Hard/Impossible if they do not If problems occur it is often easier to do a complete reinstallation of TSE then to try to patch things up Support from suppliers has been very patchy
SRD Experience (2) Problems: –Applications regularly crash with access violations –Some applications use their own private temp areas which cannot be moved –Temporary files do not always get deleted at logoff. Profiles can also be left behind in the registry –More users in NT Diagnostics -> Network than are logged on
SRD Experience (3) Conclusions: –Use of TSE has caused problems, a lot of effort has been required to get the system working and the support load is quite high –Cost savings have not been significant –Users need educating. Since many Unix users have anti-MS bias, this can be difficult
Future Uses ISIS –Use of WinNT TSE to provide computing functionality at multiply locations in the experimental hall using generic terminals –Could be extended to use in shared offices or Boss/Secretary offices Chubby Client Model (PPD) –Providing extra functionality to cloned PCs in a medium sized department
ISIS Idea Generic Terminals Terminal Server
ISIS Pros and Cons Pros –Easy to manage –All terminals identical –Easy to move/replace –Applications only need to be installed once Cons –Hard to provide new software. –Cost. –TSE complexity
Winterm Tests Tested two Wyse 3315SE Terminals: –Cost £375, 90MHz RISC processor, built in 10BaseT Ethernet, VGA up to 1024x768, multiple session support Test uses reports were generally favourable about the terminal. Main concerns were about screen update speeds and resolution Tests of the next model up (200MHz, 100BaseT, 1600x1200) will take place soon
ISIS Conclusions Terminal Server and Winterm terminals have the potential to save time and effort in ISIS Offers the potential of plug-in and switch-on computing in visitor and experimental areas
Chubby Client - The Problem In an environment of cloned PCs where every PC is supposed to be identical, there will always be people who need applications which are not in the core set. What is the best method to meet this need?
Three Solutions 1.Individual - Install each of the applications by hand on every machine that needs it. Easy but time/effort consuming 2.Clone - All needed applications are included in the clone. Impossible if the list gets too large, expensive in terms of unused licences 3.Server - Application files are stored on a central server but run on the local machine. Good in principle, very hard/impossible to set up for most applications We use a combination of 1 and 2, can TSE give another viable option?
The Model Desktop PCs running a core suite of packages. e.g. Office, Browser, X server, TSE Client. Terminal Server runs extra packages not needed on many machines. E.g. Compilers, Drawing packages, etc.
Conclusions Preliminary tests indicate that most of the software we would want to run on the server works without a great deal of tuning for TSE (most importantly Visual Studio 6.0, Adobe Illustrator, MS FrontPage) The indications are that the support level for these applications on TSE would be lower than our present install where needed policy
TSE Load Tests (ISIS) Dual 300MHz PII, 128MB RAM, 100baseT 4 users running Word, Excel, PowerPoint and outlook, two of the four running eXceed as well Screen Updates unaffected but the load but application start up times did degrade CPU Usage steady at ~15% but memory was short and active processed were being swaped
TSE Load Tests 2 (PPD) Dual 450MHz PII, 512MB RAM, 100baseT 4 users compiling a large Visual C++ Project simultaneously –Average compile times: Console3:31 1 remote User3:45 2 remote Users4:23 3 remote Users5:35 4 remote Users7:20 –Both CPUs flat out with two jobs but interactive response still OK with four
Load Test Conclusions Microsofts estimates of the number of users that can be supported on one TSE seem slightly high Memory seems to be the limiting factor Interactive response and screen updates were still acceptable even with two CPUs flat out
Final Conclusions Whilst far from perfect Windows NT Terminal Server Edition does seem to be a useful product, offering the prospect of reduced system management loads whilst improving the functionality. Things should get better as newer versions of third party applications are released TSE ready TSE is an integral part of W2K and is included in the certification process for software
Chubby Client for CDM Central server supplying site wide Apps. Departmental users on clients with core Apps Departmental servers supplying extra functionality