Performing Daily Maintenance

The processes and procedures for maintaining Windows Server 2003 systems can be separated based on the appropriate time to maintain a particular aspect of Windows Server 2003. Some maintenance procedures require daily attention, whereas others may require only quarterly checkups. The maintenance processes and procedures that an organization follows depend strictly on the organization; however, the categories described in the following sections and their corresponding procedures are best practices for organizations of all sizes and varying IT infrastructures.

Certain maintenance procedures need to be performed more often than others. The procedures that require the most attention are categorized into the daily procedures. Therefore, it is recommended that an administrator take on these procedures each day to ensure system reliability, availability, performance, and security. These procedures are examined in the following four sections.

Monitoring the ISA Dashboard

The ISA Server Dashboard, shown in Figure 17.2, allows for a quick all-encompassing view of what is going on with the ISA Server. The dashboard contains areas for showing alerts, current sessions, reports, monitored services, and connectivity verifiers, all on one screen. As part of daily maintenance, reviewing the ISA dashboard for alerts and other problems is recommended to allow for proactive management of the ISA environment.

Figure 17.2. Monitoring the ISA Dashboard.

For more information on monitoring ISA Server, see Chapter 19, "Monitoring and Troubleshooting an ISA Server 2004 Environment."

Checking Overall Server Functionality

Although checking the overall server health and functionality may seem redundant or elementary, this procedure is critical to keeping the system environment and users working productively.

Some questions that should be addressed during the checking and verification process are the following:

• Can users access published servers and services?

• Can VPN Connections be made?

• Is Internet access time especially slow?

Verifying Backups

To provide a secure and fault-tolerant organization, it is imperative that a successful backup, done either with backup software or through ISA config exports, be performed each night. In the event of a server failure, the administrator may be required to perform a restore from tape. Without a backup each night, the IT organization is forced to rely on rebuilding the ISA server without the data. Therefore, the administrator should always back up servers so that the IT organization can restore them with minimal downtime in the event of a disaster. Because of the importance of the tape backups, the first priority of the administrator each day needs to be verifying and maintaining the backup sets, or ensuring that the XML export completed successfully.

If disaster ever strikes, the administrators need to be confident that an individual server or array can be recovered as quickly as possible. Successful backup mechanisms are imperative to the recovery operation; recoveries are only as good as the most recent backups.

Although Windows Server 2003's NTBackup backup program does not offer alerting mechanisms for bringing attention to unsuccessful backups, many third-party programs do. In addition, many of these third-party backup programs can send emails or pages if backups are successful or unsuccessful. In addition, exporting out ISA configuration information using automated scripts such as the one described in Chapter 18 can help ensure the recoverability of an ISA server.

Monitoring the Event Viewer

The Windows Event Viewer, shown in Figure 17.3, is used to check the System, Security, and Application logs on a local or remote ISA server. These logs should not be confused with the ISA firewall or web proxy logging, which log network traffic through the ISA Server. Rather, the Event Viewer logs information specific to the server itself, and its functionality. These logs are an invaluable source of information regarding the operation of the underlying Windows structure of ISA. The following event logs are present for Windows Server 2003 systems:

• Security log The Security log captures all security-related events that are being audited on a system. Auditing is turned on by default to record success and failure of security events.

• Application log Specific application information is stored in the Application log. This information includes services and any applications that are running on the server.

• System log Windows Server 2003specific information is stored in the System log.

Figure 17.3. Examining the Event Viewer.

All Event Viewer events are categorized as informational, warning, or error.

Some best practices for monitoring event logs include

• Preferably, using a proactive monitoring tool with built-in intelligence to collect, filter, and alert on ISA-specific events. This includes the Microsoft Operations Manager (MOM) 2005 product, which is described in more detail in Chapter 19.

• Understanding the events that are being reported.

• Archiving event logs frequently.

To simplify monitoring hundreds or thousands of generated events each day, the administrator should use the filtering mechanism provided in the Event Viewer. Although warnings and errors should take priority, the informational events should be reviewed to track what was happening before the problem occurred. After the administrator reviews the informational events, she can filter out the informational events and view only the warnings and errors.

To filter events, do the following:

1.	Start the Event Viewer by clicking Start, All Programs, Administrative Tools, Event Viewer.
2.	Select the log that is to be filtered.
3.	Right-click the log and select View, Filter.
4.	In the log properties window, shown in Figure 17.4, select the types of events to filter. Figure 17.4. Filtering events in the Event Viewer.
5.	Optionally, select the time frame in which the events occurred. Click OK when finished.

Some warnings and errors are normal because of bandwidth constraints or other environmental issues. The more the logs are monitored, the more familiar the messages become and the more easy it is to spot a problem before it affects the user community.

TIP

The size of the log files may need to be increased to support the number of log files that are produced by the system. This is particularly true if failure events are logged in the security log.