Building A Common Server Oper ating Environment By Thach Vo   It's Monday morning. The message light on your phone is blinking and your alphanumeric pager has been going off since you arrived at work. "911: Bermuda server. Users cannot log on!" You determine that the server is up, but only some users can log on. Rebooting the server locks everyone out. You have no record of what is installed on the server, so you have to call the local site administrator for help. After spending many hours on the phone and faxing log files, you discover that the Bermuda administrator downloaded newer LAN drivers from a Web site and applied it to the server and connected clients last Friday. The promised bug-free drivers cause a ring r einsertion problem if a CTRL-ALT-DEL is pressed instead of a cold-reboot. Further complicating the problem, the new drivers work only with a certain Token-Ring NIC chip set. Does this scenario sound familiar to you? One way to avoid server outages and to reduce troubleshooting time is to enforce a common server operating (CSO) environment, which includes maintaining records of server changes that have been made. We'll look at some of the issues involved in data replication in a CSO environment and some of the methods and tools you can use to enforce it. What Is a Common Server Operating Environment? In a nutshell, a CSO environment is where all the deployed servers within an organization or a company have an identical core area--such as system and common application files, the same hardware platform including peripherals, the file and directory structure and network drive assignments. But defining the physical common server environment is only half the battle. Enforcement of this environment can be difficult because it requires the coordination of the central IS team and the cooperation of remote LAN administrators. The central IS team is responsible for monitoring, downloading and testing patches, bug fixes and updated drivers. This team also is responsible for record keeping, developing pre- and postreplication procedures and coordinating the actual replications. The prereplication procedure may include discussing what will be changed. It is primarily used as a heads-up to inform the local site administrator which files will be updated, why the updates are needed and when the replication will take place. The prereplication procedure also gives the local site administrator an opportunity to communicate any concerns regarding updates to central IS. The postprocedure may contain detailed instructions such as what needs to be done locally by the onsite LAN administrator once the changes have been propagated. For example, the administrator may need to search and delete all old CTL3DV2.DLL files on the client desktop and update that file with a later one using Symantec Corp.'s Norton Administration for Network. The postprocedure itself may contain the Norton script file and instructions detailing how to use Norton Admin to push the change to client desktops. Many issues may crop up during the replication process. The most effective way to deal with these is to establish a server maintenance window, during which users are not allowed to log in. Remote LAN administrators are responsible for performing the changes on the server, if necessary. Note that the replication process will distribute only updated files from central to remote servers. If physical action on the server, such as rebooting or replacing device drivers, is required, the local administrator will need to perform these changes. Data Replication There are two methods involved in replicating data in a common server environment: incremental and full synchronization. In the incremental synchronization method, only the core areas of a server are refreshed. In a Novell NetWare environment, the core areas may include the system, public, application and administration (update drivers, script files and client system files) directories. On the other hand, f ull synchronization usually includes both refreshing the existing core file areas with new ones as well as deleting files that are located on the destination server, but not on the master server. In either case, the patches, bug fixes and driver files should be thoroughly tested before being pushed to the remote site. Usually, the incremental synchronization will safely enforce the common server environment if the deviation from remote and central master server is minor; the local administrator does not make changes on the server independently from the central IS.

The Road to Fast Ethernet Networks by Joel Conover Updated Februayr 7, 1997