What to Do Every Week

In addition to the tasks that should be performed daily there are other tasks that should be performed once a week. You should consider doing weekly tasks on the same day of the week. If a task is done on Monday one week and Friday the next week, 10 days go by without doing the maintenance tasks. A slip of a few days can lead to longer slips in scheduled maintenance leading to the possibility of bigger problems occurring.

Check for System Updates

Microsoft regularly releases system updates and hotfixes to address myriad bugs and issues. These updates are critical to the security and stability of your system.

Although updates are released on a semiregular basis, you should not blindly download and install each and every patch that is released. Patch management is a critical factor in system maintenance. Always download and test a new patch in a lab environment. This gives you an opportunity to test the new patch with applications to see if the patch or update causes anything on the system to stop working. When stability of a patch seems likely, apply it to the server during a maintenance window. Make sure you have a recent backup just in case. The following tasks should be performed when performing patch management:

• Check for new patches. This can be done easily via the Windows Update feature in Windows 2003 or by visiting the Web at http://www.microsoft.com/windowsupdate.

• Determine which servers the patch is applicable to. This process can be simplified through the use of the Microsoft Baseline Security Analyzer tool. It checks the services and applications running on a server and compares this information to an XML file maintained by Microsoft that references which patches are applicable to which services and operating systems.

• Download the patch and install it on a test server in the lab. This test server should be representative of the type of server this patch is applicable to.

• Test the applications on the server with the new patch in place. Pay attention to potential changes in performance, memory usage, and so on.

• If the patch tests out okay, pick a maintenance window in which to install the patch.

• Perform a system state backup of the server before applying the patch, just in case.

• Apply the patch and reboot if necessary.

Proper patch management is one of the most important maintenance tasks there is. Being up to date with the latest security fixes greatly reduces the chances of you being affected by hackers, worms, and viruses.

Better Confidence in Windows 2003

Windows 2003 has proven to have an extremely low rate of regularly released patches and updates. Unlike previous versions of Windows that had dozens of patches and updates released soon after the product introduction, Microsoft Windows 2003 has had virtually no updates required soon after release. This level of clean code provides better confidence that Windows 2003 will require less maintenance than previous versions of Windows.

Hardware Availability

If availability of hardware in the test lab is a concern, consider using Virtual Machine technology from companies like VMWare or Microsoft. This enables you to maintain images of each type of server in your environment all on a single box. When you want to test a patch for SQL you simply "boot" the SQL Virtual Machine (configured just like your machine in production) and test the patch. Then launch your Exchange server and test and appropriate patches For Exchange. You can even test interaction between virtual systems after patch application to ensure that they won't break things in production. This will allow you to have a single system in the lab to test multiple systems and it's a whole lot faster than rebuilding the test system each time you need to test a new application.

BEST PRACTICE: Keeping Up with Patches

Historically, some of the worst worms and viruses have taken advantage of vulnerabilities that were posted and fixed months prior to the release of the worm or virus. The SQL_Slammer Virus, for example, that wreaked havoc on thousands of SQL servers, exploited a security hole that had been posted and patched several months previously. Servers that were affected hadn't downloaded and installed the patch. The failure to keep up with patch maintenance resulted in an exciting weekend for a large number of system administrators.

Verify Active Directory Replication

The Windows 2003 support tools provide a lot of useful applications for monitoring the health of the Active Directory. These tools are located on the Windows Server 2003 CD in the /Support/Tools directory. One of the key things to verify with these tools is that Active Directory replication is occurring properly.

In environments that are fairly "static," it is easy to miss a problem in Active Directory replication. You could easily go weeks without noticing that a user in a remote location with a local DC doesn't appear in your view of Users and Computers. Failures in replication of Active Directory can lead to myriad problems so it is critical to verify successful replication.

The tool Replmon.exe is very useful in verifying replication success. Consult this tool weekly to verify replication between all domain controllers.

Audit Administrative Group Membership

System administrators are frequently on the alert against hackers and other forms of unauthorized user access. In an effort to control system access, many administrators have taken advantage of the granular approach to security rights offered by Active Directory. This results in less of a need for people to be Domain Administrator, Schema Administrator, or Enterprise Administrator. As such, companies are making efforts to keep the number of people in these groups as low as possible. Invariably, someone feels they need to be in one of these groups in order to accomplish a particular task. Sometimes they are placed in one of these groups for a specific task and then they are not removed. To control these types of rights and reduce the chances of accidental changes to the system it is very useful to audit these high level administrative groups weekly and ensure that there are no surprises in the membership. It's a great way to catch accounts that only needed temporary rights and it's a great way to spot hackers that have added their accounts into these groups. Take a look at the local administrators group on your member servers as well. You might be surprised what you find that you did not expect.

Perform a Test Restore

As mentioned previously, successful backups of Windows 2003 and Active Directory are critical to the maintenance of the networking environment. Verifying successful backups daily is a great way to ensure there is a healthy copy of the network backup. Even more important than backups are restores . As many surprised administrators find, when they really need to restore from tape and the backup is corrupt or not accessible, the importance of being able to successfully restore from tape is most apparent. Reading the backup logs is a good start but it's critical that a test restore is performed weekly to ensure that the backup tapes are actually viable . Pick a tape randomly from the past week and restore some random files. Uncheck the Restore to Original Location option and place the files in a temporary directory. Try to choose files that can be opened to verify their integrity. Restore the files and then open each of them. If any of the files fails to restore or are corrupted when you restore them, alert the backup group immediately, or if you are the person in charge of backups, review your backup procedures and test the process until a successful backup can be achieved.

Examining the Size of the Active Directory Database

Once a week, the size of the NTDS.DIT file should be checked. Compare the size of it to the size it was the previous week. After a few weeks you should have a good feel for "normal" growth of the file. If its size changes drastically for no apparent reason (such as migration of objects from another environment, recent hiring of a large number of employees , replication with a new LDAP source) this should flag to you that something out of the ordinary is going on and you should determine the cause immediately.

Examine the DHCP Scopes

Make sure that the DHCP scopes for the network have enough available addresses to cover any anticipated growth. Because allocating additional network addresses might involve multiple individuals or groups of individuals, it is important to be able to predict when you will run out of addresses for a particular network and request additional resources in time.