Question

  Asked: Mar 10 2006   8:37 AM GMT
  Asked by: eduado


deploying office 2003


Networking, Availability, Bandwidth, Hardware, Routers, Switches, Hubs, Cabling, 3Com, Avaya, Cisco, Dell, Enterasys, Foundry, Hewlett-Packard, Juniper, Billing and customer care, Billing Support Systems, Development, Lifecycle development, Software testing, Automated, Functional, Performance/Load, Software Testing Tools, Web, DataCenter, Desktop management applications, Altiris, Intel, LANDesk, Systems management software, Computer Associates

I want to Look at problems in deploying office 2003 in terminal server environments and get user experiences on aspects like performance

Subscribe to Alerts! Get questions and answers delivered to your Inbox.


E-mail me updates on this question



   SUBSCRIBE

hidden modal window

Answer Wiki (Improve, edit or add to this answer)


 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0



Eduado,

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.

HTH,
:) Gene
  • AddThis Social Bookmark Button

Browse more Questions and Answers on Networking, DataCenter and VoIP.

Looking for relevant Networking Whitepapers? Visit the SearchNetworking.com Research Library.


Discuss This Answer


You must be logged-in to discuss a question. Log-in/Register