1. It’s nice when all terminals are the same and are recent enough to let office display all it’s little goodies with default settings. If you’re using Citrix, those little vga monitors on old systems will need console work with Citrix settings behind the scenes or attaching individual profiles to each login (blegh!!)
2. Unless you have a very dependable 100mgb/full-duplex network and fast servers, you might want to force any login to be active for a minimum amount of time to bend user habits away from “quickies.” This is because terminal servers usually instance a full environment for each login. Circa 1998, only one company offered a partially shared environment space (dll’s only) and I don’t remember who that was.
3. Go to the trouble of configuring individual (or better yet, group) profiles to limit down features that should not be needed for that class of user and turn off as many goodies as possible like picture screen savers, animated menues, etc. Usually, terminal workforces already have definite pre-defined tasks and you can model what they can access after their job descriptions.
4. I’d go with hard ip’s, not dhcp. If you lose the netbios name, you can still track down a problem without sorting through the server logs.
5. Have as much functionality served via Rumba or Reflections using mainframe screens rather than those screens’ Windows counterparts.
6. Make sure the Windows licensing is hunky-dorey on the server (unless you buy a roll-out pack of licenses, each instance’s product key must be properly registered with MicroSoft) so that any verification problems don’t bring down the whole floor.
7. A more complex arrangement is to put MS support dll’s and libraries on the client and merely execute from the server. More installation, but much faster.