Exchange outlook sending email to wrong domain
I have a strange situation with exchange and outlook. I recently installed exchange localling in an office. Prior to that they were using hosted exchange. I have worked out all of the sending issues except one. For some reason when sending to other office members the emails get bounced. The emails get bounced because they are being sent to the old hosted server. This happens because the auto complete references the old server instead of the new server. I discovered this when editing the NK2 file. I have removed these references and then the emails sent to in office recipients get there with no problem. this lasts for about a week and then somehow the reference to the old server returns and the emails get bounced, until I remove the reference. How is the reference returning and how do I make it stop.
The computers do not reside on the domain. they function as workstaions in a workgroup. The users log onto the exchange server as if it were a remote connection. Exchange anywhere. since there are only 4 users I didn't feel the need to convert the computers to domain computers. Espencially since these computers have been being used as workgroup computers for so long.
I can't figure out how the computers can be picking up the obsolete reference to the old server.
thanks
jon
The computers do not reside on the domain. they function as workstaions in a workgroup. The users log onto the exchange server as if it were a remote connection. Exchange anywhere. since there are only 4 users I didn't feel the need to convert the computers to domain computers. Espencially since these computers have been being used as workgroup computers for so long.
I can't figure out how the computers can be picking up the obsolete reference to the old server.
thanks
jon
Which version of Exchange, you are using?
ASKER
2010 exchange on 2011 sbs
I don't know whare to look for recipient policy or recipient update service
I don't know whare to look for recipient policy or recipient update service
ASKER
and how would anything on the server get any information from old server without me inputing that information, which I never have. the only place I have seen any reference to the old server is in the autocomplete file. And I assume it had that information from the old NK2 file that I merged with the new file after I created the new profile. but what I don't get is how it keeps getting the information for the old server and associating it with the in house users.
jon
jon
ASKER
Ok, I went throught that. there is no reference to old exchange server
Hi topprops,
Wow - rather a strange problem you have there!
When you say you edited the *.NK2 file, how so? Was that using NK2View/NK2Edit or some other such tool?
I would go as far as to suggest that you remove the Outlook profiles for those remote users entirely, re-create them and allow them to cache the mailboxes again from the remote Exchange Server. The side effect of creating a new profile will provide them with a fresh NK2 file, which provides a clean slate from which testing can occur.
Within Exchange and Outlook, internal messages do use a value called the "legacyExchangeDN", also known as an X.500 address, to refer to recipients on email messages, rather than the recipient's SMTP address. If these remote users are replying to email messages which were sent when users were still on the hosted Exchange instance, it's possible that the old X.500 addresses from that instance are being added to the NK2 file as a result of that interaction. Of course, these messages would bounce back as undeliverable, but the addition of the invalid address to the NK2 will cause further messages to fail, too.
If you can identify that as a particular behaviour which is occurring, then we could get around it by adding secondary X.500 email addresses to the internal user mailboxes which contain the X.500 value from the hosted Exchange server. This means Exchange could continue to deliver email, regardless of whether it was sent to the old, hosted X.500 address, an SMTP address or the new, internal legacyExchangeDN on the SBS box.
-Matt
Wow - rather a strange problem you have there!
When you say you edited the *.NK2 file, how so? Was that using NK2View/NK2Edit or some other such tool?
I would go as far as to suggest that you remove the Outlook profiles for those remote users entirely, re-create them and allow them to cache the mailboxes again from the remote Exchange Server. The side effect of creating a new profile will provide them with a fresh NK2 file, which provides a clean slate from which testing can occur.
Within Exchange and Outlook, internal messages do use a value called the "legacyExchangeDN", also known as an X.500 address, to refer to recipients on email messages, rather than the recipient's SMTP address. If these remote users are replying to email messages which were sent when users were still on the hosted Exchange instance, it's possible that the old X.500 addresses from that instance are being added to the NK2 file as a result of that interaction. Of course, these messages would bounce back as undeliverable, but the addition of the invalid address to the NK2 will cause further messages to fail, too.
If you can identify that as a particular behaviour which is occurring, then we could get around it by adding secondary X.500 email addresses to the internal user mailboxes which contain the X.500 value from the hosted Exchange server. This means Exchange could continue to deliver email, regardless of whether it was sent to the old, hosted X.500 address, an SMTP address or the new, internal legacyExchangeDN on the SBS box.
-Matt
ASKER
sending to the old hosted exchange server would bounce because that account has been shut down and it wouldn't know where to send the emails. what is x.500? And where is this information housed? if it is the source of this recurring problem, then can I edit this information. I would think the issue has to be on the users computer somewhere, since this information has never been on the server. Yes, I edited the NK2 file with NK2Edit. and recreating the profile won't help because the user will insist that I move all of his auto complete information over with it. which is all I did last time. so the auto complete is somehow picking this up from somewhere else. I just need to figure out where and eliminate that source.
thanks
jon
thanks
jon
ASKER
when it works correctly the auto complete references:
/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recip
when it doesn't work correctly the auto complete reference starts with:
/o=exch017 followed by a bunch of stuff I haven't paid a lot of attention to because I know that exch017 is the name of server for intermedia.net where the exchange was hosted.
Why would this information keep returning to the autocomplete file after I have removed it at least 4 times. It doesn't seem to have returned to the other users auto complete files. but I will have to keep an eye on it.
thanks
jon
/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recip
when it doesn't work correctly the auto complete reference starts with:
/o=exch017 followed by a bunch of stuff I haven't paid a lot of attention to because I know that exch017 is the name of server for intermedia.net where the exchange was hosted.
Why would this information keep returning to the autocomplete file after I have removed it at least 4 times. It doesn't seem to have returned to the other users auto complete files. but I will have to keep an eye on it.
thanks
jon
Okay, yes, it's a legacyExchangeDN issue.
I would certainly not advise modifying the legacyExchangeDN attribute of mailboxes on the new server as that is just destined to cause all manner of problems.
Adding an X.500 address is accomplished in the Exchange Management Console, by editing a mailbox, going to the Email Addresses tab and choosing to add a new address of type "Other". However, I do not think that tactic is suitable if this is just one user having this problem, because you would need to add in X.500 addresses for every mailbox which was previously situated on the hosted instance.
As I said before, the legacyExchangeDN / X.500 address is used internally by Exchange to represent the sender on internal emails. If the user is interacting with old messages (which were sent while still on the hosted server) in some way, then I suspect that is how the old DN is re-appearing in the NK2 file.
Is the user interacting with data (email / calendar items etc) which was originally sent / created while they were hosted on the old hosted service?
-Matt
I would certainly not advise modifying the legacyExchangeDN attribute of mailboxes on the new server as that is just destined to cause all manner of problems.
Adding an X.500 address is accomplished in the Exchange Management Console, by editing a mailbox, going to the Email Addresses tab and choosing to add a new address of type "Other". However, I do not think that tactic is suitable if this is just one user having this problem, because you would need to add in X.500 addresses for every mailbox which was previously situated on the hosted instance.
As I said before, the legacyExchangeDN / X.500 address is used internally by Exchange to represent the sender on internal emails. If the user is interacting with old messages (which were sent while still on the hosted server) in some way, then I suspect that is how the old DN is re-appearing in the NK2 file.
Is the user interacting with data (email / calendar items etc) which was originally sent / created while they were hosted on the old hosted service?
-Matt
ASKER
I'm sure he is. he has huge collection of old emails that he refers to and he may also be replying to emails that were replies to him from his old emails.
Okay, that would be where the problem is creeping in. Those old emails are referring to the legacyExchangeDN attributes from the hosted instance - the moment a message is composed to one of those old X.500 addresses, it will enter the autocomplete file.
No easy way around that problem. If he is replying to emails which were replies to him from his old emails, then he is either going to need to re-type the user's email address, so that it picks them up from the new system, or you are going to have to add an X.500 alias to every mail-enabled user on the system which matches their old legacyExchangeDN from the hosted system.
Unless this causes a huge problem for the whole company, the latter is going to involve a lot of overhead and management, and ties you to legacy names which you probably don't really want hanging around going forward.
-Matt
No easy way around that problem. If he is replying to emails which were replies to him from his old emails, then he is either going to need to re-type the user's email address, so that it picks them up from the new system, or you are going to have to add an X.500 alias to every mail-enabled user on the system which matches their old legacyExchangeDN from the hosted system.
Unless this causes a huge problem for the whole company, the latter is going to involve a lot of overhead and management, and ties you to legacy names which you probably don't really want hanging around going forward.
-Matt
ASKER
I'm not sure how to do what you are suggesting. and I don't understand how it would work. the old server exist on someone else's network. how would I make the old legacyexchangdn point to the current server.
jon
jon
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks I'll try that when I get back from vacation
may be the offline address book is still having address pointing to old server.