In a mixed Exchange 2007/2003 environment with a Connector to a Non-Exchange System on an Exchange 2003 Server you cannot send messages from Exchange 2007 to a recipient in the Non-Exchange System if the following two conditions are true:
1) the Connector contains an Address Space with an underscore (“_”) in it, like in the following example:
2) one part of the address of the final recipient (for example, the “Domain”-part) matches this Address Space.
In this case, the sender of the message will receive a Non Delivery Report from the first Exchange 2007 Hub/Transport-Server and the message will not be routed to the recipient.
The Non Delivery Report contains the following error-information:
#550 5.4.4 ROUTING.NoNextHop; unable to route
This error is returned despite the fact, that the Scope of the Connector is set to “Entire organization” and the Address Space is visible in the Routing Log Viewer in Exchange 2007.
Please note, that this issue can occur in conjunction with all EDK-Gateways for Exchange 2003 and hence is not limited to the Lotus Notes Connector for Exchange 2003.
You can work around the problem by re-defining the Address Space in question so, that the underscore is eliminated from it and replaced by a wildcard. One possible solution for the example above would be, to replace “abcd_ef” by “abcd*”. As soon as this change has been replicated to Exchange 2007, the problem is resolved and messages can be sent from Exchange 2007 to the desired destination.
Categories: 5.4.4, 550, Address Space, Connector, Exchange 2003, Exchange Server, Lotus Notes, NoNextHop, Novell Groupwise, troubleshooting Exchange 2007, unable to route Tags:
Sometimes when using PFDavAdmin to view folder properties with Exchange 2007 you may see the following error in the tool:
The remote server returned an error: (404) Not Found
If you look at the IIS logs on the target machine, you will see the error was “404.11”.
This is due to enhanced security settings that can be set in IIS, and are set by default in IIS7 (Windows 2008).
The solution is described in the following article:
942076 Error message when you visit a Web site that is hosted on IIS 7.0: “HTTP Error 404.11 – URL_DOUBLE_ESCAPED”
http://support.microsoft.com/default.aspx?scid=kb;EN-US;942076
I found that the change in settings only worked after I had used APPCMD in the following way (on my W2K8 MBX server):
Under the following folder:
%windir%\system32\inetsrv
Run:
Appcmd set config “Default Web Site” /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True
If you are still having problems, seeing different errors in the IIS logs, or see different symptoms, you probably have a different issue.
So I wanted to Write a post, where I mentioned, that we used for troubleshooting extrace, but I scould not find any good public link for explaining , what is an Exchange Extrace. Actually I therefore reutilize an old Explanation for an OWA Extrace, which I sent several times to customers, but which was initially from an international colleague, I even do not remember (Yes we have a creative commons license internally, where we reutilize content for the benefit of our customers)
How to take EWS/OWA/ETL trace to troubleshoot Exchange Web Services issues and view them using ExTrace.exe
- 1) Go to the Exchange Server and fire up Extra.exe (c:\Program Files\Microsoft\Exchange Server\Bin\ExTRA.exe)
- 2) This will bring the following window, click on ‘Select a task’
- 3) Click on “Trace Control”
- 4) Configure the trace options, file location, maximum file size (10-20mb should be enough for normal scenarios)
- 5) Select sequential logging, and run traces for a time period in which you should be able to reproduce the issue. Usually 300 seconds are good enough to switch over and reproduce the error.
- 6) Click “Set components and tags for the type of tracing selected”
- 7) Type of tracing will me “6. OWA Tracing”
- 8) Under trace types, select all of them to get a verbose log
- 9) Under components, OWA will be selected by default – you might want to uncheck that as it will add logs for OWA traffic as well
- 10) Choose trace components according to your problem, in basic scenarios and EWS issues MSExchangeWebServices should be sufficient.
- 11) These are the providers which looks good to get a detailed log and uncovering the hidden issues somewhere in the communication.
- a. ADProvider
- b. ADRecipientCache
- c. ADExpansion
- d. AuthenticationProvider
- e. Common
- f. Diagnostics
- g. MSExchangeWebServices
- h. NetworkingLayer
Note: Selecting multiple providers will increase the size of log and will make it difficult to analyze, so make sure you collect as much data as you require.
- 12) You can further filter it on the basis of following criteria
- a. UserDN
- b. SenderSMTP
- c. RecipientSMTP
- d. Subject
- e. MailboxGuid
- f. MailboxDatabaseGuid
- g. WindowsIdentity
- 13) Once done, hit Start tracing
- 14) It will run the trace for the specified duration, keep it running and reproduce the problem
- 15) Once done it will generate a binary file (.ETL) which contains all the proprietary & confidential information.
- 16) Customers currently cannot analyze the extraces themselves.
Therefore, please send them to Microsoft Support. You can even try to ping someone in the Microsoft Newsgroups, so that he or she can try to grab Your Extrace. I am definitely open to analyze at least 3 Extraces to anybody, who comments on this site, that he wants us to analyze his Extrace.
