Exchange: Error-Prone Messaging Tracking
Troubleshooting a service pack error that continues even after a reinstall.
I'm getting this error from the event logs on our new Exchange 2003 server:
Error code :1031
One of the System Attendant's task is blocked.
I reinstalled the service pack on the server but this did not sort the problem out. Can you help?
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?
Tech Help—Just An
Got a Windows, Exchange or virtualization question
or need troubleshooting help? Or maybe you want a better
explanation than provided in the manuals? Describe
your dilemma in an e-mail to the MCPmag.com editors
the best questions get answered in this column and garner
the questioner with a nifty MCPmag.com baseball-style
When you send your questions, please include your
full first and last name, location, certifications (if
any) with your message. (If you prefer to remain anonymous,
specify this in your message, but submit the requested
information for verification purposes.)
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.
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 firstname.lastname@example.org; 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!
Sekou Page, MCSE, CCNA, has been in IT more than 10 years, having architected and administered Active Directory, Exchange mail systems, and network environments for small to enterprise-class systems. Sekou specializes in AD and Exchange migrations and has led more than 50 successfully, over 30 of which were in Exchange 2003. His expertise also includes infrastructure architecture/optimization, mail systems and security. He's currently principal Exchange knowledge architect at Zenprise, provider of real-time e-mail diagnosis and problem resolution.