Welcome back my trusted Exchange consultant! So by now you would’ve read my previous blog “The Mother of All Cross Forest Migrations” and after you finished running laps around the office in pure joy that you now have a way to migrate your finance department from your source to target forests, along comes me again with blog post numero dos to explain how you can get mail flow between the two forests operational…Wait…What?
And you thought cross forest migrations were meant to be straight forward! Remember my scenario from the last blog…CROSS FOREST, MULTI TENANT…oh and let’s not forget the key word…Draconian! Say that 5 times in your sleep and you’ll probably start seeing visions of Draco legislating some now cross forest migration law!
Never fear, the pure awesomeness that is me (so I keep telling myself) is here to help you. I’ve put this blog together to help fellow consultants, just like yourself, get a better understanding of just what is involved with completing these types of migrations, whilst still allowing you to get some beauty sleep.
QUICK REFRESH
If you recall from the last blog, I ran you through the prerequisites and steps involved with preparing identities and moving mailboxes from your source forest to your target forest as linked mailboxes. After familiarising yourself with the 4000 word cmdlets required to be run just to prepare the identities and then another 4000 word cmdlet to move the mailboxes, we come to the next phase of our journey…what do you do if you need to migrate your entire organization, consisting of, let’s say 2000 hardworking individuals, across to the target Exchange platform? Choose one of the answers below:
- Chug down those Red Bulls, grow some wings and hammer away at PowerShell throughout Friday, Saturday and Sunday migrating mailboxes whilst your friends are out watching the next blockbuster created by the genius that is Stan Lee
- Run out of the office and don’t look back
- Trust pure awesomeness to help deliver your desired outcome
- Read On
- C & D
Good. You chose E. Buckle up!
ACCEPTED DOMAINS
Whenever a new Exchange organization is implemented and new Exchange servers provisioned, Accepted Domains need to be configured so that the Exchange organization knows to send and receive emails to these domains.
Accepted Domains come in 3 types:
- Authoritative
- Internal Relay
- External Relay
I know what you’re thinking; as if the shenanigans of dealing with cross forest, multi-tenant Exchange migrations wasn’t enough, you now must try and distinguish between not 1, but 3 types of Accepted Domains (queue “physical gesture of placing one’s hand across one’s face or lowering one’s face into one’s hand or hands, covering or closing one’s eyes, otherwise known as the face palm)
So, what’s the meaning of each domain and what has this got to do with these migrations I hear you ask? Keep your eyes glued to this blog and read on.
Authoritative
Basically, The Godfather, the capo di tutti capi, or the boss of all bosses. In other words, domains are considered authoritative when the Exchange organization hosts mailboxes for recipients with this SMTP domain. So, in my scenario, my source Exchange 2007 server has several mailboxes with the SMTP domain of @forestA.com.au. This means that forestA.com.au is configured as an Authoritative domain in this Exchange organization.
Internal Relay
Not as high ranking as an Authoritative domain, but nonetheless, just as important. When internal relay domains are configured, some or all the recipients in this domain don’t have mailboxes. In other words, forestA.com.au needs to exist in both source and target forests and users somehow still need to email one another and receive emails. What kind of sorcery is this!
External Relay
The ugly duckling of the Accepted Domain world. We shall not speak of this one. Carry on.
Based on my scenario, I needed to configure Internal Relay domains. But that’s not enough to get the mail flow working. As with anything in this industry, one task is always followed by another…and another…and one more task just to seal the deal!
Next up…Send Connectors.
SEND CONNECTORS
In a nutshell, without a Send Connector, your Exchange organization has no chance of ever getting that email with the subject line “Crazy Cat Lady from The Simpsons” to its intended recipient on the other side of the world. When Exchange deployments are simple enough, you generally have a single Send Connector configured to send everything outbound from your Exchange server, across the big band world of the internet and then land in the intended recipient’s Inbox. Add a dollop of cross forest, seasoned with internal relay and you now have the need for another Send Connector. Happy Happy Joy Joy! (for anyone who remembers The Ren & Stimpy Show)
When a domain is configured as an Internal Relay, Exchange will see that the intended recipient is part of this domain and then find the Send Connector that best matches the domain address space for your internal relay domain and voila! Crazy Cat Lady email sent!
OK I get it Hambik, internal relays, accepted domains, connectors. How did all this work in your scenario? Thought you’d never ask!
So, in my scenario with migrating users from Exchange 2007 in the source forest to Exchange 2013 in the target forest, I needed to set up mail flow, so I could stage the mailbox moves. Here’s what I did:
Step 1
Remember my domain, forestA.com.au? Well this was already set up in the Exchange 2007 organization as an Authoritative domain so quite simply, from the Exchange Control Panel, the domain was changed from Authoritative to Internal Relay.
Step 2
You got it! Send Connectors. I created a new Send Connector and called it Cross Forest Send Connector so I could easily distinguish the connector from the others.
The SMTP Address Space was configured with the domain forestA.com.au. Traditionally, if a Send Connector is used to send everything out via the internet, the Address Space would include a wildcard character (*). By specifying the domain, the Exchange 2007 organization then knows to send mail destined for forestA.com.au recipients using this connector because of the internal relay setup.
The Cost value of the connector can be the same (typically 1) or can be a value anywhere between 1 – 100. In my scenario, setting the cost the same as the internet bound connector worked just fine.
Next, you also want to set the Hub Transport server. Basically, this is the transport server that your Send Connector is going to use to send the mail. In my scenario, because I’m setting this up in my source forest, the transport server will be the Exchange 2007 server.
Step 3
With all these configurations set in my source forest, it was time to test. In the Exchange 2007 forest, I had the following user accounts:
Following the steps in my previous blog, I moved userA from the source to the target Exchange forest, but now userB needed to email userA. In Outlook, UserB compiles the email and hits Send. Exchange 2007 then sees that userA doesn’t have a mailbox in the organization, looks up the domain and sees that it is an Internal Relay. At this point, the little minions working away in the background wanting to deliver this mail then look at the Send Connectors and see that mail destined for the forestA.com.au address space needs to be sent from the Cross Forest Send Connector.
Mail is sent. UserA in the target forest confirms that they have received the email and just like that, cross-forest mail flow was achieved.
What if UserA wants to reply to this email? If they attempt to reply, UserA will receive the dreaded Non-Delivery Report. This is what us Exchange consultants compare to the Blue Screen of Death in Windows. When these types of reports are received, it means something, somewhere in your precious mail platform isn’t working! (queue irregular heartbeat)
An easy fix to this. Repeat steps 1 and 2, but in the target forest. Set up forestA.com.au as an Internal Relay in the target Exchange forest and create a new cross-forest Send Connector, except this time, the transport servers to send the mail will be the Exchange 2013 servers.
There you have it, folks, …cross-forest, mail flow, using different types of domains and send connectors. By having this in place will allow you to stage mailbox moves and still have time to go see Black Panther.
Had enough of cross-forest shenanigans yet? No? Good! I may have some more blogs coming soon. Subscribe to Insentragram now and I may just write up another one just for you!
