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.
Exchange 2003 Incoming Mail From POP Connectors Stuck in Categorizer
We are troubleshooting a problem on what should be a simple SBS 2003 server setup.
All mail is delivered via an SMTP connector and all mail is received by POP connectors. The SMTP connector works perfectly but the POP connectors are having problems.
Mail is being retreived from the external server. Following KB885685, we traced the incoming mail and can see it arrive in the Incoming Mail folder and transfer to the Pickup Folder but from there, it goes nowhere. With message tracking turned on, we see the following:
SMTP: Message Submitted to Advanced Queuing
SMTP: Started Message Submission to Advanced Queue
SMTP: Message Submitted to Categorizer
I've Googled the problem but everything Microsoft has to say about messges stuck in the Categorizer doesn't match the symptoms. For example, KB952841: IIS doesn't have the metabase entries that cause this problem.
Other solutions simply say to run the Internet and E-mail Setup Wizard and enter the external domain name when prompted. The problem with this approach is that the domain name ends up in the default SMTP virtual server and becomes the SMTP domain in the IIS metabase; which in turn means that an internal user can't send mail to a mailbox on the external server. (Not all of the mail accounts on external mail domain have ADS user accounts on the Exchange server. Some of users are remote who access mail directly from the external mail server.)
Hopefully the above makes sense. Any help would be appreciated.
All mail is delivered via an SMTP connector and all mail is received by POP connectors. The SMTP connector works perfectly but the POP connectors are having problems.
Mail is being retreived from the external server. Following KB885685, we traced the incoming mail and can see it arrive in the Incoming Mail folder and transfer to the Pickup Folder but from there, it goes nowhere. With message tracking turned on, we see the following:
SMTP: Message Submitted to Advanced Queuing
SMTP: Started Message Submission to Advanced Queue
SMTP: Message Submitted to Categorizer
I've Googled the problem but everything Microsoft has to say about messges stuck in the Categorizer doesn't match the symptoms. For example, KB952841: IIS doesn't have the metabase entries that cause this problem.
Other solutions simply say to run the Internet and E-mail Setup Wizard and enter the external domain name when prompted. The problem with this approach is that the domain name ends up in the default SMTP virtual server and becomes the SMTP domain in the IIS metabase; which in turn means that an internal user can't send mail to a mailbox on the external server. (Not all of the mail accounts on external mail domain have ADS user accounts on the Exchange server. Some of users are remote who access mail directly from the external mail server.)
Hopefully the above makes sense. Any help would be appreciated.
Who is Participating?
First thing to do is uninstall any spam or antivirus software you have on the server and reboot. 99 times out of 100 when I see this that is the cause.
I would go for an SP2 re-install, sounds like a strange setup you have?
I don't understand why you can't run the Connect to Internet Wizard?
I don't understand why you can't run the Connect to Internet Wizard?
I can run the Connect to Internet Wizard as long as I leave the E-mail Domain Name blank. If I put the external mail domain name in that field, the SMTP connector for outgoing mail doesn't work.
I'll re-install Exchange SP2 and let you know what happens.
I'll re-install Exchange SP2 and let you know what happens.
OK, any errors in the event log? Are the messages queuing? And if so what is the queue message/error?
How much disk space does the server have?
How much disk space does the server have?
Unfortunately you are running not just one but two scenarios that fall well outside of what is considered best practices.
First and foremost, the pop3 connector was designed to be a short term migration tool and should not be used in production for an extended period of time.
Secondly, for any given namespace, it is best to have all mailboxes on the Exchange server. Exchange has OWA, RPC over HTTPS, and other technologies to make that mail available to the users, so there is rarely a reason to keep a namespace split among multiple service providers.
Ideally your solution would be to resolve both of those. My recommendation would be to centralize your mailboxes first, resolve any lingering configuration issues for the users that used to be hosted separately, and then make a plan to migrate from pop3 to SMTP delivered email.
If there is a technical or business reason why this cannot be done (and I stress CANNOT...not just because it sounds hard, but actually CANNOT be done) then you need to run the Internet and Email Setup Wizard. As you pointed out, this will replace the external name in all the places required to get the pop3 connector working. First problem solved.
Then, to resolve delivery to the external mailboxes, you will have to manually configure a shared-namespace scenario. The process to do this in Exchange 2003 is outlined here:
http://technet.microsoft.com/en-us/library/aa997194(EXCHG.65).aspx
You will want to follow Method #1 for sharing a domain space with another system.
Note that SBS wizards will be unaware of these changes and some SBS dashboards and wizards will not work as expected and during any significant system changes you will likely have to repeat the process...but it *will* get you up and running.
-Cliff
First and foremost, the pop3 connector was designed to be a short term migration tool and should not be used in production for an extended period of time.
Secondly, for any given namespace, it is best to have all mailboxes on the Exchange server. Exchange has OWA, RPC over HTTPS, and other technologies to make that mail available to the users, so there is rarely a reason to keep a namespace split among multiple service providers.
Ideally your solution would be to resolve both of those. My recommendation would be to centralize your mailboxes first, resolve any lingering configuration issues for the users that used to be hosted separately, and then make a plan to migrate from pop3 to SMTP delivered email.
If there is a technical or business reason why this cannot be done (and I stress CANNOT...not just because it sounds hard, but actually CANNOT be done) then you need to run the Internet and Email Setup Wizard. As you pointed out, this will replace the external name in all the places required to get the pop3 connector working. First problem solved.
Then, to resolve delivery to the external mailboxes, you will have to manually configure a shared-namespace scenario. The process to do this in Exchange 2003 is outlined here:
http://technet.microsoft.com/en-us/library/aa997194(EXCHG.65).aspx
You will want to follow Method #1 for sharing a domain space with another system.
Note that SBS wizards will be unaware of these changes and some SBS dashboards and wizards will not work as expected and during any significant system changes you will likely have to repeat the process...but it *will* get you up and running.
-Cliff
Due to issues with having mailboxes multiple places, I still would not recommend this setup. Where reliability is an issue, it would still be better to use a true SMTP setup with a "backup" SMTP server that will deliver mail to the primary server when it comes back online. Many companies offer this service; one of my favorites is DynDNS "Backup MX" service. No actual mailboxes reside outside of Exchange, but you get that redundancy you need in scenarios such as yours. Far more reliable and easier to troubleshoot and maintain than a pop3/hybrid solution.
-Cliff
-Cliff
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.
demazter - No errors in Event Viewer and over 200GB free disk space.
cgaliher - The concept for this setup is simple but i agree that it is a little unusual. It's a small business that had an existing Exchange server in place when we got involved and they added remote users. Despite it being unusual, I think I understand the reasoning behind it - they are in the country where the Internet connection has reliability issues and they have a dynamic IP; so this arrangement provided the office people with the functionality of Exchange but have the stability of the external mail service for remote users.