SOLVED

Exchange 2010 and 2016 coexistence

%3CLINGO-SUB%20id%3D%22lingo-sub-103316%22%20slang%3D%22en-US%22%3EExchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103316%22%20slang%3D%22en-US%22%3E%3CP%3EWe've%20just%20installed%20Exchange%20server%202016%20in%20an%20existing%20Exchange%20server%202010%20environment.%20We've%20had%20an%20issue%20where%20the%20Default%20receive%20connector%20on%20the%20HT%20servers%20has%20been%20configured%20to%20only%20receive%20mail%20from%20certain%20servers%20for%20some%20reason%2C%20and%20this%20was%20stopping%20some%20users%20from%20sending%20mail%20internally.%20We%20fixed%20this%20up%2C%20but%20I%20can't%20get%20my%20head%20around%20why%20the%20Exchange%202016%20got%20involved%20in%20this%20internal%20mail%20flow%20in%20the%20first%20place.%20None%20of%20the%20namespace%20or%20mailflow%20cutover%20has%20occured%20yet%2C%20only%20the%20intitial%20install%20of%20the%20Exchange%20servers%2C%20so%20I%20would%20have%20thought%20that%20internal%20mail%20flow%20would%20have%20been%20through%20the%20Exchange%202010%20servers%20only.%20If%20anyone%20can%20let%20me%20know%20what%20happens%20upon%20the%20intitial%20installation%20of%20Exchange%202016%20that%20cuases%20it%20to%20be%20involved%20in%20the%20internal%20mail%20flow%2C%20that%20would%20be%20great.%20some%20Technet%20articles%20describing%20this%20would%20be%20prefect.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-103316%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3E2010%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3E2016%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-214332%22%20slang%3D%22en-US%22%3ERe%3A%20RE%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-214332%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20was%20exactly%20the%20answer%20I%20needed.%20Thanks%20so%20much%20Brian!!!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-106544%22%20slang%3D%22en-US%22%3ERe%3A%20RE%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-106544%22%20slang%3D%22en-US%22%3ETo%20see%20what%20is%20happening%20get%20the%20message%20headers%20and%20post%20them%20to%20exrca.com.%20This%20will%20show%20things%20like%202010%20mapi%20to%202010%20transport%20(as%20I%20described%20above)%20and%20later%20the%20last%20hop%20being%20to%202010.%20As%20the%20mailbox%20is%20on%202010%2C%20the%20transport%20service%20must%20deliver%20it%20to%20a%20Hub%20Transport%20role.%202016%20cannot%20deliver%20to%20a%202010%20mailbox.%202016%20can%20deliver%20to%202010%20transport%20but%20only%202010%20transport%20can%20deliver%20to%202010%20mailbox%20(as%20transport%20to%20transport%20is%20not%20version%20dependant%20but%20transport%20to%20and%20from%20mailbox%20is%20version%20dependant)%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-105359%22%20slang%3D%22en-US%22%3ERe%3A%20RE%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105359%22%20slang%3D%22en-US%22%3E%3CP%3EI%20believe%20this%20is%20due%20to%20shadow%20queue%20in%20Exchange%202010%2C%20or%20Safety%20Net%20in%20Exchange%202016.%20Exchange%20will%20always%20route%20an%20email%20through%20another%20Exchange%20transport%20server%20in%20the%20same%20site%20to%20create%20another%20copy%20of%20the%20message%20for%20backfill%20if%20necessary.%20See%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Fdd351027(v%3Dexchg.141).aspx%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Fdd351027(v%3Dexchg.141).aspx%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-105283%22%20slang%3D%22en-US%22%3ERe%3A%20RE%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105283%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Brian%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20is%20not%20what%20we%20have%20just%20experienced.%20With%20Exchange%202010%20and%20Exchange%202016%20installed%20in%20the%20same%20site%2C%20Exchange%202016%20servers%20were%20picking%20up%20internal%20to%20internal%20messages%20for%20local%20delivery%20from%20the%20Exchange%202010%20servers.%20The%20only%20way%20we%20noticed%20this%20is%20that%20the%20client%20had%20played%20around%20with%20the%20default%20receive%20connectors%20on%20the%20Exchange%202010%20servers%20and%20restricted%20the%20remote%20server%20IP%20range%2C%20so%20the%20new%20Exchange%202016%20servers%20weren't%20included.%20This%20caused%20messages%20to%20queue%20on%20the%20Exchange%202016%20servers%20until%20they%20were%20allowed%20on%20Exchange%202010%20receive%20connectors.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-105220%22%20slang%3D%22en-US%22%3ERe%3A%20RE%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105220%22%20slang%3D%22en-US%22%3E%22isn't%20running%20the%20HT%20server%20role%2C%20notifications%20that%20a%20message%20is%20waiting%20are%20load%20balanced%20among%20Hub%20Transport%20servers%20by%20using%20round%20robin%2C%22%3CBR%20%2F%3E%3CBR%20%2F%3ESo%20nearly%20right!%20When%20a%20mailbox%20delivers%20to%20transport%20service%20it%20is%20ALWAYS%20version%20dependent.%20But%20when%20delivering%20cross%20AD%20site%2C%20it%20is%20NEVER%20version%20dependent.%3CBR%20%2F%3E%3CBR%20%2F%3EThat%20means%2C%20mailbox%202010%20to%20transport%20server%20initially%20will%20stay%202010.%20But%20when%20then%20delivering%20to%20another%20AD%20site%2C%20or%20receiving%20from%20another%20AD%20site%2C%20the%20sending%20transport%20service%20will%20round%20robin%20across%20all%20the%20transport%20servers%20that%20are%20online%20in%20the%20target%20site.%3CBR%20%2F%3E%3CBR%20%2F%3EBrian%20Reid%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-103331%22%20slang%3D%22en-US%22%3ERe%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103331%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Dan%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHere%20you%20can%20see%20how%20the%20Mail%20flow%20and%20transport%20work%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Faa996349(v%3Dexchg.160).aspx%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Faa996349(v%3Dexchg.160).aspx%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20mail%20routing%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Faa998825(v%3Dexchg.160).aspx%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Flibrary%2Faa998825(v%3Dexchg.160).aspx%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENote%3A%20If%20you%20need%20to%20change%20any%20o%20the%20Connectors%2C%20use%20Front%20End%20Transport%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-103330%22%20slang%3D%22en-US%22%3ERE%3A%20Exchange%202010%20and%202016%20coexistence%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103330%22%20slang%3D%22en-US%22%3ESo%20I'm%20going%20to%20try%20and%20answer%20my%20own%20question.%20If%20this%20is%20incorrect%20I'd%20lobe%20if%20someone%20could%20point%20me%20in%20the%20right%20direction%20From%20the%20%22Understanding%20Message%20Routing%22%20technet%20article%2C%20it%20advises%20that%20Exchange%202010%20generates%20a%20list%20of%20HT%20servers%20in%20the%20AD%20site.%20I%20assume%20that%20this%20list%20includes%20both%202013%2F2016%20servers.%20If%20the%20local%202010%20Mailbox%20server%20that%20generated%20the%20message%20isn't%20running%20the%20HT%20server%20role%2C%20notifications%20that%20a%20message%20is%20waiting%20are%20load%20balanced%20among%20Hub%20Transport%20servers%20by%20using%20round%20robin%2C%20thus%20the%20Server%202016%20servers%20can%20pick%20up%20the%20message.%20I%20just%20need%20to%20figure%20out%20why%202016%20was%20trying%20to%20send%20the%20mail%20back%20to%20a%202010%20HT%20server%20and%20not%20directly%20to%20the%202010%20MBX%20server%20that%20contained%20the%20user%3C%2FLINGO-BODY%3E
Highlighted
Frequent Contributor

We've just installed Exchange server 2016 in an existing Exchange server 2010 environment. We've had an issue where the Default receive connector on the HT servers has been configured to only receive mail from certain servers for some reason, and this was stopping some users from sending mail internally. We fixed this up, but I can't get my head around why the Exchange 2016 got involved in this internal mail flow in the first place. None of the namespace or mailflow cutover has occured yet, only the intitial install of the Exchange servers, so I would have thought that internal mail flow would have been through the Exchange 2010 servers only. If anyone can let me know what happens upon the intitial installation of Exchange 2016 that cuases it to be involved in the internal mail flow, that would be great. some Technet articles describing this would be prefect.

7 Replies
Highlighted
So I'm going to try and answer my own question. If this is incorrect I'd lobe if someone could point me in the right direction From the "Understanding Message Routing" technet article, it advises that Exchange 2010 generates a list of HT servers in the AD site. I assume that this list includes both 2013/2016 servers. If the local 2010 Mailbox server that generated the message isn't running the HT server role, notifications that a message is waiting are load balanced among Hub Transport servers by using round robin, thus the Server 2016 servers can pick up the message. I just need to figure out why 2016 was trying to send the mail back to a 2010 HT server and not directly to the 2010 MBX server that contained the user
Highlighted

Hi Dan,

 

Here you can see how the Mail flow and transport work https://technet.microsoft.com/en-us/library/aa996349(v=exchg.160).aspx

 

For mail routing https://technet.microsoft.com/en-us/library/aa998825(v=exchg.160).aspx

 

Note: If you need to change any o the Connectors, use Front End Transport

Highlighted
"isn't running the HT server role, notifications that a message is waiting are load balanced among Hub Transport servers by using round robin,"

So nearly right! When a mailbox delivers to transport service it is ALWAYS version dependent. But when delivering cross AD site, it is NEVER version dependent.

That means, mailbox 2010 to transport server initially will stay 2010. But when then delivering to another AD site, or receiving from another AD site, the sending transport service will round robin across all the transport servers that are online in the target site.

Brian Reid
Highlighted

Hi Brian,

 

That is not what we have just experienced. With Exchange 2010 and Exchange 2016 installed in the same site, Exchange 2016 servers were picking up internal to internal messages for local delivery from the Exchange 2010 servers. The only way we noticed this is that the client had played around with the default receive connectors on the Exchange 2010 servers and restricted the remote server IP range, so the new Exchange 2016 servers weren't included. This caused messages to queue on the Exchange 2016 servers until they were allowed on Exchange 2010 receive connectors.

Highlighted

I believe this is due to shadow queue in Exchange 2010, or Safety Net in Exchange 2016. Exchange will always route an email through another Exchange transport server in the same site to create another copy of the message for backfill if necessary. See https://technet.microsoft.com/en-us/library/dd351027(v=exchg.141).aspx

Highlighted
Solution
To see what is happening get the message headers and post them to exrca.com. This will show things like 2010 mapi to 2010 transport (as I described above) and later the last hop being to 2010. As the mailbox is on 2010, the transport service must deliver it to a Hub Transport role. 2016 cannot deliver to a 2010 mailbox. 2016 can deliver to 2010 transport but only 2010 transport can deliver to 2010 mailbox (as transport to transport is not version dependant but transport to and from mailbox is version dependant)
Highlighted

This was exactly the answer I needed. Thanks so much Brian!!!