Installation and Configuration Strategy

If you have read Chapter 5 and have done your homework, you are now ready to begin installing Windows Server 2003 in your lab. You may be tempted (or you may have an urgent need) to go directly to a working or production system in a production environment. Perhaps your DHCP server died or a new DNS server is needed urgently. Resist — or stick with what you know. If you have a Windows Server 2003 network and need to raise a new service to fill an urgent need, stick with Windows Server 2003.

Conversely, if you are a seasoned administrator and you know what you're doing, you probably have issues such as a hardware checklist, remote or unattended installation, hot standby, and so on well taken care of. Proceed directly to a production system only if you know what you are doing and the production system is part of a conversion and rollout project.

Generally, you should always raise servers in a lab. Then you should burn them in (run them continually) for about a week; hit them with work for at least another week. After that, and if all test items check off, ship or go live. No two environments are the same. The following sections look at various installation and configuration scenarios.

Going through the hardware checklist

Understanding role server configuration

Installing from boot disks

Installing from the command line

Installing over the network

Note A lot of people want to know how to burn in a server that is standing idle and has no users connected to it. One simple way is to set up NTBackup to run continually. Running backup is great physical therapy for a server. It works the hard disks, memory, system buses, access control, permissions and the NTFS, remote and removable storage functions, and more. You can also configure NTBackup (or any other backup utility, for that matter) to perform both pre- and post-backup routines, such as sending alerts and moving files around the house. Depending on your stress test, you may need to write a backup script to automatically overwrite media and so on. In addition, if you want to test disk I/O and other routines, you may need to write some custom software for the job.

Was this article helpful?

0 0

Post a comment