Local area networks.
A fundamental truth in the computer world is that software is continuously upgraded. While many users are constantly calling for software fixes and improvements, they frequently have other things to say when confronted with the reality of installing, learning, and adjusting to the latest version of the software they have grown to love and hate. The thought of possibly losing files, a couple of features, or a particular utility may be enough to scare some users away from upgrades once they have been received.
This apprehension is increased by several orders of magnitude when a network administrator is confronted with an upgrade to network software. The possibility that network software, applications, or data files belonging to individuals could be lost or corrupted is, once again, enough to give anyone second thoughts about beginning the installation process.
There are steps and questions the prudent individual might consider to provide a reasonable level of insurance and confidence when proceeding with the process. First, are there at least two reliable back-ups of the network and its contents? Second, how good (thorough and complete) is the documentation that has been developed for the network? Third, how long is the installation of the new software calculated to take? Fourth are there plans for disposing of the older version of the software? These questions do not exhaust the possibilities, but they can serve as catalysts for others relevant to local circumstances.
We have found that it is almost impossible to have too many network back-ups. However, the mere fact that back-up software has been run should not be taken as assurance that there is indeed a back-up copy. Unless you have tried to recover files from the back-up copy, there is no guarantee a back-up copy actually exists.
We have heard of network administrators who were careful to follow backup procedures, but, to their dismay, discovered they had no back-up after a crisis occurred. Somewhere during their routine a failure occurred that prevented the creation of the network back-up.
Some of the causes for such failures might include, but certainly are not limited to, the tape being empty, the hidden files of the network not being copied, the system running out of space on the backup medium and then writing over the files, or the system running out of space on the back-up medium, aborting the back-up and not recording a thing.
The best way to verify whether or not the back-up procedure is working is to simulate a network failure. This simulation can be useful for other reasons, too.
In order to conduct this simulation, a mini-network using a separate server will have to be created. Restoring the software on the mini network will confirm whether a back-up has truly been created. While this process may require some extra effort, it is very good insurance and can provide peace of mind to the network administrator.
The importance of documentation has been touched on in many articles, presentations, and conversations, but the fact remains that user-developed documentation is critical to the successful long-term operation of any network.
Before installing new network software, all documentation should be thoroughly reviewed and brought up to date. Specific items that should be checked for currency include the list of all users, their respective directories and rights, the list of all servers, printers, CD-ROM products, ports, and other peripheral devices.
Have all the old users who have left the library been deleted from the network? Be certain to list all the groups and the members of each group. We are aware of sites that have large numbers of files flagged in a variety of ways to increase the security of both applications and the network. Printing lists like these is an easy way to create documentation.
Like so many other projects in a library, there is never going to be a good time to upgrade the network. There are always many pressing tasks to be done, and soon installing the upgrades lags behind.
Although it may not seem the case, there are times when the network is less busy. Identify them. Once they are known, select one, but remember to allow more time than you think will be required. These projects always take longer than expected, and, too often, it is much longer than allowed.
Next alert network users to the schedule for taking the network down. Give them as much notice as possible and repeat the notice several times so no one can plead ignorance.
Inform them that there will be a major change to the network and that it is possible, although unlikely, that files could be lost. Advise them that this might be a most appropriate time for them to clean up their network file areas.
Emphasize that it might be added insurance if they were to make their own file back-ups in addition to the network backup that will be made. Let them share the responsibility for backing up their files.
Mail files are often overlooked even though they can consume large amounts of space on networks with a small user population. Take this opportunity to do a thorough house-cleaning.
If at all possible, schedule the time for the upgrade when you can have the support of others such as the local vendor or the network manufacturer who will have the special expertise you may need. Know the hours that support lines are available and remember the impact of time zones.
In our last upgrade we found that our old network interface cards (NICS) were unusable in the server after the new software was installed. The NIC vendor had to be called and a new set of drivers had to be downloaded for the cards. This kind of problem is increasingly common.
A question we hear frequently is, "What do we do with the superseded software and documentation?" since the space required to house the manuals and disks can be substantial. Sites that have used Novell for several years may have accumulated a single-faced section of shelving filled with documentation.
How long the disks from earlier versions should be preserved is another concern. If a decision is made to dispose of the software and the disks, what recourse is there if it is found that the new version of the software no longer provides an important feature OT has bugs the site cannot tolerate?
Another potential area of conflict may arise from mixing different versions of the vendor's software on the server. It is increasingly common for vendors to release upgrades in a manner that permits migration from one version to another rather than requiring the complete erasure of all the old files and then installation of completely new software.
We have found that new versions of Novell may upgrade the server portion of the network but impose no changes on the software located on each workstation (IPX and Net*). This has the potential to cause some problems when working with new application software.
The reality of networking is that new releases are inevitable. With proper preparation, the process of installing upgrades can be reasonably straight-forward, keeping inconvenience to network users to a minimum and the anxiety level of network administrators within an acceptable range.
|Printer friendly Cite/link Email Feedback|
|Author:||Nielsen, Steven; Marks, Kenneth|
|Publication:||Computers in Libraries|
|Date:||Oct 1, 1991|
|Next Article:||Library systems at RISC: a case study.|