Comments : 2

Exchange 2003 Resource Monitoring

Category : Exchange Server

 Exchange 2003 Standard and Enterprise offers the feature to monitor the Server status of the Exchange Servers. If some of the monitored services and other Resources (RAM, CPU, Services) are in “Warning State” or “Critical State” we can receive a status e-mail or a customized action provided by a script notification can be run. This article explains in detailed steps how to configure Monitoring and E-Mail notification.

In the first step we have to configure a Server for monitoring and select/configure the resources to monitor. To do so, open the Exchange System Manager Snap-In and select the appropriate Server object in the Servers container.

Right-click the Server object and open the Properties for it.

Once the Properties dialog box is open, select the Monitoring tab as shown above.

There are many resources available for monitoring. We can add the following resources:

  • Available Virtual Memory
  • CPU Utilization
  • Free disk space
  • SMTP queue growth
  • Windows 2003 Service
  • X.400 queue growth

Many other 3rd party monitoring tools like Nagios can do most of the monitoring and so we will only add the two most critical items which are not monitored by Nagios. These are:

  • Available Virtual Memory
  • SMTP queue growth 

In the first step, we will add the Available Virtual Memory instance. Click on the Add button under Monitoring tab. A dialog box similar to the one shown below will open.

Select the Available Virtual Memory from the list and click on OK.

Configuring virtual memory monitoring is very similar to configuring CPU utilization monitoring. We have skipped the CPU Utilization Monitoring. Set the duration to 5 minutes, the warning threshold to 15% and the critical threshold to 10% for Available Virtual Memory. Once the values are set, click on OK.

 

Follow the process for adding another instance and select SMTP Queue Growth this time from the list.

If SMTP queues start backing up, it often indicates that there is a major problem. It shows that message transport has failed, the Internet connection has failed, or someone is using the server to send spam. In any event, we need to know that there is a problem.

We must input a warning and a critical state threshold value, but these values are entered in minutes. The idea is that we must tell Exchange how many minutes the queue should be constantly growing for before we generate a warning or a critical state message. We can use any values that we want, but I recommend setting the warning threshold at 10 minutes and the critical state threshold at 15 minutes.

Close the dialog boxes and the Properties once done. The next step is to configure an E-Mail notification for the recipients of the “Warning” and “Critical” state conditions. To do so, open the Notifications object under Tools.

Click on New and select E-mail Notification.

In this Property dialog box we can specify the monitoring Server and the Servers / Connectors to monitor. We also have to select the State (Critical and warning) for which we configure E-Mail notification.

First we will configure the Warning State notification.

In the “To” field select a recipient for the notifications. 

Change the Email server value to some other server in your organization which runs SMTP. If you do not have any, I suggest setting up a basic MS SMTP service in IIS. This is because when the monitored Server is the same Server as the monitoring Server we can run into trouble. The Server cannot send us an E-Mail notification when it is in an critical state and is unable to send E-Mails.

Next step is to configure E-mail Notifications for Critical State. Follow the same steps that we went through earlier for Warning state notification except for the fact that this time we will select Critical from the drop down.

Once done, close all the property pages and dialog boxes. We are done with the setup.

Now when one or more of the configured resources run into a “Critical” or “Warning” state we receive a E-Mail from an account “WMI@SERVERNAME” with a error message with the server name in the subject line and the condition of the resource / service in the E-Mail body.

Technorati Profile

Comments : 6

Active Directory Health Monitoring

Category : Active Directory

Companies that have implemented Microsoft’s Active Directory need to ensure that the Active Directory is configured and operating properly. If there are issues found and not resolved, it eventually leads the components to fail or stop working and finally causing problems with Windows networking environment. This post highlights some of the FREE tools that can be used by administrators to check and verify their Active Directory health. I normally run these tests every quarter in highly changing environments since lot of updates take place.

The free tools that I mention come with Microsoft’s Support Tool Kit and while writing this post I’ve ran the tools on Windows 2003 R2 Server. Download the Support Tool Kit. Once downloaded, install the Support Tools on the server.

Now before we move on to the health monitoring tools, it is always a good idea to make a list of all the Domain Controllers in your organization along with their IP address and trust relationships if any. Assuming that you have completed this step, let’s move on to using the tools.

Since many of these tests generate logs, let’s start by creating a log folder to store the diagnostic information. I’m going to use C:\AD-Health-Logs on my server.

Let’s start by verifying the health of the Domain. For this we are going to use NSLOOKUP which is a command line tool for testing and troubleshooting DNS. We all know that DNS is the heart of Active Directory and so that’s the first thing that we will check.

For replication to happen seamlessly between multiple Domain Controllers, name resolution should work fine. Each DC should be able to resolve the _msdcs record for other DC. Open the DNS mmc and look for the _msdcs record.

Once you have the _msdcs record for the DC object, we can use NSLOOKUP to check the name resolution. Open Command Prompt and type:

NSLOOKUP <GUID._msdcs.DnsForestName> replace the GUID string in <> brackets with your actual GUID.

If the NSLOOKUP resolves the correct IP address of the replication partner than DNS is working fine. Do check that the DNS server returned in the NSLOOKUP query is returning the correct records for the replication partner.

Since DNS is working fine now, let’s move on to checking the Replication functions and topology. To verify this, we are going to use REPLMON. This tool is included in the Windows Support Tools kit and offers a GUI based interface to check a low-level status of AD replication, force replication or even monitor the status of replication. You should find REPLMON utility from the Support Tools group under Administrative Tools.

Once the GUI is opened, right-click on the Monitored Servers and click on Add Monitored Server.

 

This will invoke the Add Monitored Server wizard. Here either you can search the AD for the server that you want to monitor or you can add it explicitly by name. Since I’ve already documented my list of Domain Controllers and their corresponding IP address before I started this exercise, I’ll add the server explicitly by name. Once the server is added, click on Action, navigate to Server and choose Generate Status Report.

When prompted for the location where we should store the log file, choose the folder that you created earlier. In my case, I’m saving this to C:\AD-Health-Logs. Choose all the reporting options on the next screen and click OK.  Once the report has been written to the Log file, you’ll see a message that the Report is complete. You can now navigate to the folder where you saved the log and open it in Notepad, Word, etc. to read the contents. The report basically gives you lot of in-depth in to the replication status and topology. Play with the other options available in the REPLMON tool like Show Domain Controllers in Domain, Show Global Catalog Servers in Enterprise, etc.

My REPLMON log files did not show any problems with replication and so we will now move forward to perform the DC health check. Open Command Prompt once again and type the following command:

DCDIAG /s: <ServerName> /v /c > C:\AD-Health_logs\<servername-DCDIAG-DD-MM-YY.log>

Replace ServerName with the actual DC name and the log path with the actual values. Using the /v switch will provide us a verbose result with extended information while the /c switch will provide us with a comprehensive report by running all tests. If you get any errors you can also use the DCDIAG /fix option here to perform some soft fixes. Run this for all the DC’s in your organization by replacing the ServerName and the log file prefix. You can run this from the same machine and does not require you to log individually to machines that you are checking.

Moving ahead, we will check the network connectivity health using the NETDIAG tool. The NETDIAG tool helps in isolating network connectivity problems by performing a series of tests. Open the Command Prompt once again and type NETDIAG /v > C:\AD-Health_logs\<servername-NETDIAG-DD-MM-YY.log>.

 

Again replace the appropriate variables with the actual values and wait for the diagnostics to complete. Open the log file once the process has completed and remediate any errors that you get. Note that you may see errors related to WINS in this. If you are not using WINS in your organization these can be safely ignored.

That’s it to the basic checks for monitoring the health of your Active Directory. I’ve not covered NetDom in this series since most of the functionality can be accessed from the Active Directory mmc’s that are available in the Administrative Tools.