decommision resource forest and install Exchange 2016 in account domain with existing hybrid

Not applicable

Following situation at a customer:

- Account and Resource forest

- Office 365 tenant

- Azure AD Connect  machine running in Account forest, syncing both directories

- ADFS in Account forest

- Exchange 2010 in Resource forest with Hybrid setup



What we want:

- decommision resource forest/domain and Exhange 2010

- install Exchange 2016 in account forest

- make 2016 the hybrid


I was wondering which steps we had to take. We are now already migrating user to Exchange Online. For a new user we create a user with Linked Mailbox in Resource domain. We ADMT it to the Account forest, we trigger ADSync. A mailuser is made in Office 365 and we iniate a mailbox move.

Then in the resource forest we have a Mail Contact in Ex2010 and a disabled account in AD.


1- How can we get rid off these migrated users?

2- When can we install 2016 in the account forest, can it do any harm when we install it next to Ex 2010 which is in the other forest(ofcourse we have  a trust)

3- How to move on from here?


Thanks for your support!

(sorry, I also posted this by accident in the Office 365 community. I realized later it should be here?)

25 Replies

Hi Olaf,


Based on my expierience doing a lot of account/resource forest migrations when hybrid is already in place: Do first the consolidation within your forests and then go hybrid to your tenant before moving any users to Exchange Online.


Another possible solution is to migrate all users to Exchange Online, decomissioning Exchange 2010 and configure Exchange 2016 for hybrid and offboard users if necessary.


The problem with already migrated users from Exchange 2010 to Office 365: you "must" normallly use Prepare-MoveRequest prior migration users to Exchange Online to create a MEU object in the new Exchange 2016 forest. It is not supported to write Exchange attributes with ADSIEDIT or other tools without using Exchange.


If you setup the Exchange 2016 hybrid environment, your already migrated users will be a "RemoteMailbox, Privisioned". Your currently migrated mailboxes from Exchange 2010 are "RemoteMailbox, Migrated". And, if you want to offboard users during "reversy hybrid" you have to export the MailboxGUID from the Exchange Online mailboxes to your on-premise MEU object.


Long speak short: firest consolidate your on-premise Forests with a cross-forest migration and then go hybrid to your tenant. This is the "supported" and easiest kind of migration. Of course, you can copy all Exchange attributes with PowerShell or FIM (except some attributes like HomeMDB, ExchangeVersion, etc.) after your hybrid switch to the Exchange 2016 forest, but this requires a lot of planning and some other tools for the attribute flow between the forests.




Thanks Dominik. Although I have null experience in this, this is also what I thought would be the best approach. But unfortunately, the customer has already setup a hybrid with Ex2010 in their Resource domain, setup Azure AD Connect in the Account forest and migrated already users to EOL.

So, we need to do in this config, like described:

- Ex2010 in resource forest, Azure AD Connect in Account forest, Hybrid on Ex 2010 and already users migrated to EOL.


So the question, what global steps do I take to decommission the Resource forest? Thanks for helping me in advance!

The problem is that you should have been provisioned the migrated users to the Exchange 2016 resource forest prior migrate it to Exchange Online. You can't to this for Exchange Online mailboxes anymore.


1. Export all attributes from the Exchange Online migrated users from your on-premises Active Directory in the Exchange 2010 resource forest.

2. Migrate Cross-Premise to Exchange 2016.

3. Import the Exchange attributes in the new Exchange 2016 user account (except those which were moved with prepare moverequest, like homemdb, exchangeversion, etc.)

4. Stop AAD Connect.

5. Decomission hybrid:

5. Run AAD Connect in the new Forest

6. Set up hybrid


But this is not a overall supported solution, just my personal experience. And, of course, it is a very low level list which tasks must be performed.

I am working on a similar project with what sounds like an almost identical setup with the user/resoure forest and mailboxes have already been migrated to Office 365. We havent got to the stage yet where Exchange 2016 is installed in the user forest. My thoughts around the steps involved were as below:


1. Install EX2016 in user forest - Set SCP to null to prevent any Autodiscover funnys

2. Add Office 365 mail routing domain as remote domain in EX2016

3. Export Exchange attributes from resource forest account

4. Stop AAD connect

5. Remove resource forest acccount from AAD connect scope so it only syncs from user forest account

6. Import Exchange attributes to user forest account and run the new-remotemailbox command

7. Start AAD connect

8. Decommission hybrid from resource forest

9. Configure hybrid in user forest


I am plannnig to validate this process on a batch of test accounts first to see if any issues occur.  




Thanks guys. I will look at this and will discuss this hopefully this week or next week and will define the proper scenario for us.

Not the exact solution, should be similar to what the final goal is without the offboarding part.


Also worth a read




One more question. You mentioned in step 1 to set the SCP to $null. Why is that? If I install Ex 2016 in the other forest, there is no SCP record yet, so this cannot be overwritten by the Ex2016 install. Why set it to $null? The SCP records (every CAS server has one) in the resource forest cannot be overwritten by the install in the other forest.


Thanks again!

Hi Olaf,


I agree with you, prior to the installation of EX2016 in the user forest there will be no SCP record and the work shouldnt affect the existing deployment in the other forest.

My plan was to set the SCP to null once the installation of EX2016 was completed, this was more of a precaution than anything else as all the Autodiscover DNS entries already point to exchange online. I am planning on doing some work this week on installing EX2016 so will report back if there are any issues.



Thanks for the confirmation ;) We are planning to do the whole migration before the end of October. I am now at the moment that I need to install Ex2016. Just got the machine prepared, so ready to do the adprep's.

One more thing. All the preps are done and I am about to install Exchange 2016 on this machine now. Just to be cautious; are there any things that might influence the current Ex2010/EOL Hybrid environment or traffic? Just to be sure I have retrieved the current autodiscover settings and created a little script to re-set the autodiscover settings back to their original values, just in case they might be adjusted.

Thanks again!



Be sure to establish mail flow in your new environment prior decomissiong Exchange 2010 hybrid. Or queue the mails from on-premises <-> EXO during the time you configure the new hybrid organization.


- Dominik

Thanks. I sure will. Just for now, the basis installation, so prior to run the setup.exe now, I was wondering if anything else can be 'broken'. I can't think of any, since these are two complete different forests (they do have a trust of course).


Configure mailflow, new hybrid etc. will be done later.

An issue I encountered was the following. I ran the setup to install Ex2016 and also added the /OrganizatioName qualifier to it with the name of the company. Now the setup fails with the error that this Organization already exists! I didn't expect this, since this is a different forest. Before I remove the /OrganizationName qualifier, can I ignore this error? How can it 'see'  the existing Exchange organization in the other forest?

Have you run the /PrepareAD switch prior to running the EX2016 setup as that requires you to specify the /OrganizationName value? You should be able to look in ADSI Edit under Configuration/Services/Microsoft Exchange to see what the org name is.

Yes, that was run by an other colleague, but without the OrganizationName parameter. The screenshots he took, show no error and the operation was succesful. Also ran /prepareschema first, then preparead and then preparedomain. All succesful!

Has the schema/ad been prepared for a previous version of Exchange, that's what it sounds like?

I think that the customer already ran this prep once. Maybe for the AzureADconnect, ADMT or Hybrid ? Don't know. But I think so. I have checked with ADSIEDIT and in the Administrative Groups under Servers, it was all empty. So I don't think anything previous can conflict here and I now run the setup without the /OrganizationName. Thanks for thinking with me!

That makes sense, hopefully the installation goes fine from here.