New "beta" pages for Application installation on TS are coming up. These will be very raw for a while.
What does it mean to say something is compatible with Terminal Services?
Unfortunately, in and of itself very little if we talk about compatibility in the sense of "it will run on a Terminal Server".
This is due to the design of TS. On occasion see applications which won't work correctly on Windows NT and 2000 quite happily run on a system in Terminal Services mode; they even appear to run well, but when a system has a large load of users that story may change. The capabilities given to us by application compatibility support require understanding by administrators of the software being so used.
That is true of applications on any system, but it is even more critical with a Terminal Server. Anyone doing computer support knows that installation of Windows and some applications onto a computer is very simple, but being able to install software doesn't mean that you can operate and support it correctly for years, anymore than being able to pull the choke and start the engine on a Cessna means that you can fly it. This is even more the case with a Terminal Server, which is the equivalent of a Boeing 747 if we extend the flying analogy.
The answer is - you don't until you try it. This may sound frightening at first, but the fact is that Terminal Services shifts the weight of maintenance and support responsibilities dramatically.
To operate optimally in a complex environment, almost all applications need some tuning. The problems of untuned applications are simply much more obvious in a Terminal Services environment. Once well-configured though, due to the homogeneous underlying environment and the tight administrative control possible, application support time required is dramatically decreased compared to supporting individual PCs. The larger the server and the more users of an application, the greater the problems with bad applications, but the lower the long-term cost of supporting them.
I'm going to build up some general concepts for use in TS application installs that many people have found to be effective in the past. This won't give you precise answers to all questions, but it certainly can help.
Always begin with the Terminal Server. All Terminal Servers are not alike; after all, not only do they have different core specifications, they have differing numbers of users. Let's discuss some of the details of making sure a Terminal Server is "good enough".
The original NT4TSE was designed as a member server. Windows 2000 and .NET Terminal Servers, in contrast, can have any role you choose. Don't take advantage of this!
There are exceptions to every rule; but they shuld be considered carefully. I have never set up a Terminal Server as a DC for real-life use myself due to the annoyances involved. I do know of two successful Terminal Servers in this role; both are Windows 2000 Small Business Servers, each with dual CPUs faster than 1 GHZ, each with over a gigabyte of installed RAM, and each with less than 10 regular users. Both still have minor problems that occur occasionally.
The typical problems are all performance and functionality related. They all come back to the fact that a Terminal Server is really just a clustered workstation, and attempting to compromise the workstation and server roles produces significant compromise decisions.
A server participating in a domain security role is intended to be secure, allowing normal users at most access to certain carefully defined subsets of the services run on it. One of the primary means of ensuring that users cannot damage anything accidentally is to prevent interactive logon by normal users. This restriction obviously must be removed from a DC acting as a general-use TS, and immediately opens your server to attack. The most likely source of attack is not malicious intent on the part of your users, but other sources such as viruses and side-effects of application installs.
Switching to Terminal Server Application mode makes dramatic changes to the performance tuning of the server. The demands of sharing desktops are utterly different from those of serving print queues, files, SQL data, and DNS clients.
One of the more obvious changes is that you will find a dramatic decrease in the performance of any secondary services offered by a system in TS mode. A less obvious chnage, but one which will show up under load, is that some of these services with lowered priority may cause disastrous loss in TS desktop responsivity when it finally attempts to serve them.
This is particularly a ridiculous problem to deal with when you consider the fact that if you truly are switching over to using a Terminal Server as your source of application services, savings on desktop expenses over the following one-two years for even a small organization will be more than enough to cover the cost of a new server.
There are a few rules of thumb to follow when setting up the server. Lets look at basic server resources needed and then at the server configuration.
A Terminal Server needs to have sufficient resources available. One way to ensure it is adequate is to run the intensive scaling test suite available from Microsoft's Terminal Server portal site. This can be difficult for a random small organization to do, but there are some decent estimates that can be used for resources.
The 3 key factors are RAM, disk capacity, and CPU capacity.
RAM is the most important determinant of server abilities, and this is particularly the case with a Terminal Server. For a basic Windows 2000 server with no special function and minor demands, 128 MiB is a sufficient basic amount ot install, but it will not do for a Terminal Server. Each user session will take up extra RAM. For several users with the same specific set of applications, if the applications are truly Terminal Server aware the load for succesive users will drop somewhat. If not, reduction in server RAM needs will be minor for the additional sessions.
For a Terminal Server, you really want to look at 3 issues as you size the RAM.
The first is a "raw" estimate of need. I usually like a basic value of 192-256 MiB of RAM, plus 20-40 MiB per user at peak load. The 20-40 range is based on whether using 1-2 small applications or keeping a couple of fairly hungry ones running.
The second is slot capacity. To ensure easy, inexpensive expansion, you should maximize RAM as you go; put as much RAM in a slot as it can deal with.
The third issue is maximum system capacity. Every year applications get hungrier; and if you install the Terminal Server correctly, demand for it will increase over time even considering the same base user population. I would suggest that a server be capable of handling at least 256Mib + [64Mib x (# of users)].
This may seem like a minor issue if you keep data elsewhere, but profiles are temporarily cached locally. These should be tiny, but between users dropping things on their desktops and occasional glitches in temp files, you should seriously consider the possibility of profiles being as large as 128 MiB per user. There are ways to prevent such problems, but it pays to be prepared for the worst.
Fast CPUs can be a good thing to have - but they are not the key factor in a Terminal Server. The typical response of a CPU under load is to rise dramatically and then drop off; one overly-simplistic explanation of this is that since the bus speed of a system is significantly lower than the CPU speed, the bus winds up being the bottleneck.
This suggests quite reasonably that multiple CPUs are the answer. Even if you have to make tradeoffs on cost during purchase, you should at least ensure that your motherboard has dual CPU support; this will give you an easy upgrade path when it is needed.
CPU speed itself is not the most important issue; there are plenty of 350 MHZ Terminal Servers out there. If doing a new install today (September 2002) I would prefer not to install on anything slower than 450 MHz, but beyond thatmy greater concerns would be dual CPUs and RAM cpacity.
For a Terminal Server, the best thing to do is to start clean. This is best done with a fresh install of Windows 2000.
If that is not possible, remove every installed application, and clean up all files from them, before installing TS or switching to Application mode. The reason for this is simple: if the application is an interactive user app, it will not work correctly after changing modes. If it is not a user application, it shouldn't be on there anyway.
Next, make sure that you have at least installed either SP3 or the Licensing Enhancements and SP2. Note that these should also be applied to the domain controller which will act as a Licensing Server.
As for other applications: remove them. You don't need IIS; if you want to serve the TSWeb applet, install it on another server. The TS should not be a print server, a DNS server, a DHCP Server, a file server, or anything else: it is a workstation.