Exchange 2000 SP3 Matabase dump not showing correct information

There is much history behind my question. Suffice to say that I am working with Microsoft on this issue but would like the Experts opinion as well...  

In my default recipient policy on the Email Addresses (Policy) tab in Exchange System Manager I have four lines for SMTP domains and another for X400.

Doing a dump of the matabase shows the following information (this is a clip from the dump).

RelayForAuth                    : (INTEGER) 0
KeyType                         : (STRING) "IIsSmtpSessions"

KeyType                         : (STRING) "IIsSmtpAlias"

KeyType                         : (STRING) "IIsSmtpUser"

KeyType                         : (STRING) "IIsSmtpDL"

KeyType                         : (STRING) "IIsSmtpDomain"
KeyType                         : (STRING) "IIsSmtpDomain"
RouteAction                     : (INTEGER) 32

KeyType                         : (STRING) "IIsSmtpDomain"
RouteAction                     : (INTEGER) 32

KeyType                         : (STRING) "IIsSmtpDomain"
RouteAction                     : (INTEGER) 32

I apologize that I don't have the script and command that was run to generate this info. I ran this at the request of a MS tech assigned to my case. The tech is concerned about a section not showing up in the dump along with the other "IIsSmtpDomain" strings.

This is all a product of my server starting to send relay denied messages back to my local outlook clients that looked like this:

Your message did not reach some or all of the intended recipients.
      Subject:      Older Resume
      Sent:      4/29/2004 12:04 PM

The following recipient(s) could not be reached:
      '' on 4/29/2004 12:05 PM
            There was a SMTP communication problem with the recipient's email server.  Please contact your system administrator.
          < #5.5.0 smtp;550 <>... Relaying denied>

I tracked a message that gave me this message and found that the relay denied message was being generated before it ever left my mail server and it seems that my mail server is refusing to send the mail from an authenticated user with a local outlook client on my network. This happens to about 1% of the mail leaving the server seemingly at random times to random external domains. After repeatedly resending the same mail message the email does go through "normally". I have been working with MS for about a week on this and they think I have matabase corruption and are leaning towards reinstalling IIS on the mail server.

I realize that there may be  A LOT of information I need to give anyone reading this before they can make comments on this. I am not an exchange expert and will try to fill in information wherever I can.

Who is Participating?

Improve company productivity with a Business Account.Sign Up

rhandelsConnect With a Mentor Commented:

Looking at the article, i''m afraid you're right. Never thought this would be necesarry. But just reïnstalling it won't work, this part of the article ("After you uninstall it, you should also check the %Systemroot%\System32\inetsrv folder (which is not deleted by the uninstall process) for a file named metabase.bin. If you find one, delete it before reinstalling IIS.") is very important, else the old metabase will be used (like you didn't saw that one..;)).

I do believe, after reïnstalling IIS, the metabase is build up again, so that might be a little bit of a relief.

Hi Kevin,

I didn't follow all of what they/you have written down, but here goes my 2 cents...

I do think that the missing in your metabase is the problem. If you try to send an e-mail from a mailacoount that isn't on your own domain, than this is called relaying (e.g. on your mailserver a mail from to is being send). To make sure that this is not possible, relaying is prohibited on a Exchange server. Telling you how to enable this isn't the best way to go, you shouldn't enable relaying, it is a serious security breache.. So i think that that's your problem. Unfortenaltely, i don't know how to fix this problem, but seeing that Microsoft helps you, they should fix it for you.

And that brings me to my next opinion... I am a Exchange 2000 MCP, and for as far as i know (and the microsoft books state) a réïnstall of the IIS doen NOT fix the corruption of the IIS metabase. To restore the metabase, you should restore the System State Back-up.

Hope this helps a little bit and good luck with the Microsoft people (i'm afraid you'll need it)
kevinmcse1Author Commented:
That's an important opinion rhandel, thanks. I have a system state backup of that server but this issue has been going on for some time (months) and I have been backing up the "possibly" corrupted matabase along with the system state for who knows how long then. No chance of getting a clean matabase back through a restore now. How else would you correct the corruption? New mail server? (said with a nervuos amount of sarcasm...)
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.


Good news... You don't have to reïnstall the mail servers... You can also manually put back the metabase. Here's an article about how to do it. Also, my suggestion about the system state was right, see the first paragraph. I still don't know why microsoft says to do a reïnstall on IIS, maybe they have their reasons.. ;)..  Don't they have reasons for everything.. lol...

Hope this helps you out...
kevinmcse1Author Commented:
I read through the article you refer to rhandels. It looks as though it assumes that the matabase you are restoring is a kmown good version (obviously) but my backups are not known to be good and are most certainly in the same state as the current Matabase. At the end of the article it states that the only recourse maybe a reinstall.

Unless I am missing somthing in the article (possible) I think I'm stuck with a IIS reinstall?

kevinmcse1Author Commented:
This thread is very old but thought I would share a few things about what i learned after the fact...

1) If you talk to MS support the number of different answers you get is directly porportional to the number of techs you talk to...

2) The issue I was having was not IIS related AT ALL. It was simply that companies that randomly produced the Relaying denied messages were also running servers that had port 25 open but were not mail servers. I have no idea why this would be the case but I verified that this was true with the third MS tech I talked to about my Relaying denied issue. This tech seemed to actually be knowledgeable and directed me to the real issue almost immediately.

It seems that my mail server would attempt to connect to the receiving mail server via DNS and a MX record and if it failed the first attempt it would automatically try an A record lookup instead ( silly you ask? I thought so, but this is by MS design). The A record could be any server running IIS and have port 25 open. This apparently happens more often than I thought. So, in succesfully connecting to a non mail server that has no mail clients accociated with it my mail server tries to send mail and the bogus destination server obviously send the Relaying denied message to my server.

That's it. Once the companies that my mail server was trying to connect to closed the servers with the A records down to IIS and port 25 traffic my mail server failed in the DNS lookup and simply retried in the specified amount of time. Eventually making the MX connection with the REAL mail server. It has been almost exactly a year since I posted this question and I have not seen but a handfull of these Relaying denied messages. I appreciat all the help I got from you experts. I just wish MS had not sent me on a wild goose chase for a week or more last year.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.