Exchange 2013 Upgrade in a Child Domain

Recently working on an Exchange 2013 upgrade project where the forest had both a Root and Child domain, I came across a couple of points that I thought would be worth noting for future reference.

On Exchange projects you make the necessary Request for Change (RFC), to enable the upgrade of the Active Directory (AD) Forest and Domains, and the installation of Exchange 2013. Sometimes I come across where the client wants to prepare the AD Forest and Domains separate from the Exchange installation, to allow for the schema upgrade to replicate. In these scenarios you find that the groups "Schema Admins", "Enterprise Admins" and "Domain Admins" are more tightly controlled (As they should be…) not to allow inappropriate or temporary accounts in these groups just for installation.

The necessary Exchange binary files and commands for the Schema and Domain extension were passed to the AD team.

• Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
• Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
• Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Note: /PrepareAllDomains was used due to there being a root and child domain

These commands prepared the Schema and Domains for Exchange 2013 installation, as these commands were run by another team and wasn't visible to myself I double checked the Schema objects.

$RootDSE = ([ADSI]"").distinguishedName
$ForestRangeUpper = ([ADSI]"LDAP://CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,$RootDSE").rangeUpper
$ForestObjectVersion = ([ADSI]"LDAP://cn=<ExhangeOrg>,cn=Microsoft Exchange,cn=Services,cn=Configuration,$RootDSE").objectVersion
$DomainObjectVersion = ([ADSI]"LDAP://CN=Microsoft Exchange System Objects,$RootDSE").objectVersion
$DisplayVersions = @()
$DisplayVersions += "Exchange Forest (rangeUpper) = " + "$ForestRangeUpper"
$DisplayVersions += "Exchange Forest (ObjectVersion) = " + "$ForestObjectVersion"
$DisplayVersions += "Domain (ObjectVersion) = " + "$DomainObjectVersion"
$DisplayVersions

Note: You need to add the "Exchange Organisation" name on the '$ForestObjectVersion' line, this will return three numbers on the Root Domain and only the '$DomainObjectVersion' on the Child Domain.

Forest:










Child Domain:

Exchange 2013 Schema and Domain Versions:

Exchange	Forest (rangeUpper)	Forest (objectVersion)	Domain (objectVersion)
2013 RTM	15137	15449	13236
2013 CU1	15254	15614	13236
2013 CU2	15281	15688	13236
2013 CU3	15283	15763	13236
2013 SP1	15292	15844	13236
2013 CU5	15300	15870	13236
2013 CU6	15303	15965	13236

This confirmed the Schema and Domains had successfully been prepared. The next stage was to install the first Exchange 2013 server into the infrastructure, I misinterpreted the requirements to install the first Exchange 2013 server…

From TechNet (Exchange 2013): - http://technet.microsoft.com/en-us/library/bb124778(v=exchg.150).aspx

• You must ensure the account you use is delegated membership in the Schema Admins group if you haven't previously prepared the Active Directory schema. If you're installing the first Exchange 2013 server in the organization, the account you use must have membership in the Enterprise Admins group. If you've already prepared the schema and aren't installing the first Exchange 2013 server in the organization, the account you use must be a member of the Exchange 2013 Organization Management role group.

From TechNet (Exchange 2010):- http://technet.microsoft.com/en-us/library/bb124778(v=exchg.141).aspx

• If you're installing the first Exchange 2010 server in the organization, and the Active Directory preparation steps have not been performed, the account you use must have membership in the Enterprise Administrators group. If you haven't previously prepared the Active Directory schema, the account must also be a member of the Schema Admins group. For more information about preparing Active Directory for Exchange 2010, see Prepare Active Directory and Domains. If you have already performed the schema and Active Directory preparation steps, the account you use must be a member of the Delegated Setup management role group or the Organization Management role group.

I was a member of the Child Domains "Domain Admins" and a member of "Organization Management" and stated to install the first Exchange 2013 server, strangely enough as much as the setup process has improved over the years and warning when a step or prerequisite has been missed, or not in the correct groups etc. The setup did not pick up that I wasn't a member of "Enterprise Admin" and that this was the first Exchange 2013 server being installed. If this was Exchange 2010 installation all would have be ok, but as this was an Exchange 2013 installation there is the extra requirement of "If you're installing the first Exchange 2013 server in the organization, the account you use must have membership in the Enterprise Admins group". Needless to say the Exchange 2013 installed failed at (Step 8 I think) the reason being I was not a member of "Enterprise Admins".

My account was added to the "Enterprise Admins" group and setup was rerun to complete the installation of the server.

Exchange RBAC Groups and Arbitration Mailboxes… 
 

Just to finish a quick note about the Roll Based Access Control groups (RBAC), these groups are used to help manage Exchange. In a Root and Child Domain deployment, these groups will be in the Root Domain in the AD forest. The Arbitration and Discovery mailboxes will also be in the Root domain even if the Exchange servers are only installed in the child domain. As discovered when I wanted to move these too highly available mailbox. When I ran the follow command:

• Get-Mailbox –Arbitration  

The Exchange Management Shell (EMS) returns no mailboxes??? We all know they are there, so why are they not showing in the EMS? The reason is by default is the EMS session will have an AD scope set to the domain you're logged into. To change the AD scope run the follow command:

• Set-ADServerSettings –ViewEntireForest:$true  

And then retry the previous command again:

• Get-Mailbox –Arbitration

I hope this helps someone in the future and saves them some time.

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.