Server Solver

Exchange: Error-Prone Messaging Tracking

Troubleshooting a service pack error that continues even after a reinstall.

• By Sekou Page
• 10/03/2005

Error code :1031
One of the System Attendant's task is blocked.
Function: ScSaveGatewayTrackingDataEx

I reinstalled the service pack on the server but this did not sort the problem out. Can you help?
— Brett

On the surface this error might seem a bit unclear. However, I would be curious to know a little bit more history on the issue. Is this something that has been occurring since you set up the server? Did this start recently after a specific change? If nothing has changed and this is a recent issue, what other warning and error level events are being logged, not only during the day, but after the server is restarted?

The System Attendant function you mention, ScSaveGatewayTrackingDataEx can be found mentioned in other Microsoft Knowledge Base articles such as 313570, "An Event ID 5007 Error Message Is Logged When Messages with a Special Code Page Subject Are Tracked; Fix Requires Exchange 2000 SP2" (click here to read it). Errors with this function can be found when the System Attendant is unable to perform some operations relevant to message tracking. So, it seems like we should start by investigating how your message tracking is configured.

Testing the Obvious
Does the problem occur when message tracking is disabled? Does it occur with subject logging enabled or disabled? Are your message tracking logs being properly truncated based on the retention time you’ve set (Event 5008)? We might also want to look into any other events and warnings that are being generated on the system.

Since this is message about a “blocked” task, is there anything you can think of that might affect the ability of the server to access tracking related data, namely the message tracking logs and database? Has the security been tightened on your message tracking logs, for example? The logs are located at \\servername\servername.log and have default security that allows at least Administrators and SYSTEM full control (among others default permissions). Other users that perform message tracking operations will need at least read access to these files. What about the database files?

Getting down to the Problem
Are you running anti-virus software on the server? It's more likely that the cause of your issue is related to anti-virus software and potentially some sort of database corruption. Have you made the necessary exclusions for your file system antivirus? File system antivirus should never scan Exchange databases or logs. In fact, it's easy enough to exclude the entire Exchsrvr directory under your installation path. In Exchange 2000, the M drive should excluded if present. File system antivirus is certainly recommended, but it is important to make sure you’ve made the necessary exclusions so that important things like log files aren’t quarantined or corrupted.

What about database corruption? If there is a corrupted or inaccessible e-mail message that the System Attendant needs access to, it may be possible that an error similar to this is generated. If you are able to, it may be advisable to run at least an offline defrag with “eseutil /d ” and an integrity check with “isinteg –s ServerName –fix –test alltests”. See Microsoft articles 192185, "How to defragment with the Eseutility utility," and 182081, "Description of the Isinteg utility," for information on these utilities.

One thing to remember before running these tools is that you can (and should) make a copy of your database files before proceeding. This way you can ensure you have a backup of your data should there be any problems mounting the database after these operations. If you find any errors with isinteg, make sure you run it again until it passes through without errors at least two times.

Best of luck with this issue. Please write to me with additional information as you gather it and if any of the steps mentioned above helped to solve your problem.

Reader Challenge
The System Attendant performs many critical tasks on both the database and the data inside of the database. Making sure your database is healthy will be critical to your success with Exchange and Microsoft has provided tools like eseutil and isinteg to help you be successful. What was the most difficult problem you solved using these tools? What strange or cryptic problem on your server really turned out to be an issue with the database?

Write to me at [email protected]; the best answers will be published in a future "Exchange Solver" column and one submitter will be chosen for an MCPmag.com baseball-style cap. Let's see those answers and good luck!