Exchange 2013 installatiion error in child domain


I am trying to install Exchange 2013 in a child domain within the following environment.

-1 root domain/2 child domains
-Forest/Domain level - 2008 R2
-Exchange 2010 servers still exist in child domain i'm installing into

-AD preparation has previously been performed and multiple Exchange servers have been installed in the other child domain successfully
-Install is the same CU level as other EX2013 servers (CU18)

The installation always fails at the Mailbox role: Transport service stage with the following error.

The following error was generated when "$error.Clear();
          if (($RoleIsDatacenter -eq $false) -and ($RoleIsDatacenterDedicated -eq $false))
            $delegatedRoleGroupGuid = [Microsoft.Exchange.Data.Directory.Management.RoleGroup]::DelegatedSetup_InitInfo.WellKnownGuid;
            $delegatedSetupRG = Get-RoleGroup $delegatedRoleGroupGuid;
            add-ExchangeAdministrator -role ServerAdmin -Identity $delegatedSetupRG.Identity -Scope $RoleNetBIOSName;
        " was run: "System.InvalidOperationException: You can't add or remove user or group ' Exchange Security Groups/Delegated Setup' because the ServerAdmin security group doesn't exist or can't be found.
   at Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
   at Microsoft.Exchange.Management.RecipientTasks.DelegateTask.PrepareDataObject()
   at Microsoft.Exchange.Configuration.Tasks.SetTaskBase`1.InternalValidate()
   at Microsoft.Exchange.Configuration.Tasks.RecipientObjectActionTask`2.InternalValidate()
   at Microsoft.Exchange.Management.RecipientTasks.DelegateTask.InternalValidate()
   at Microsoft.Exchange.Management.RecipientTasks.AddDelegate.InternalValidate()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
   at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".

Looking in ADSI edit you can see the Exchange server object has been created, permissions assigned to the Delegated Setup group look different from other servers although not sure if this is a consequence of the installation failing.  Cant see any reference to the 'ServerAdmin' group anywhere, I have looked at other Exchange setup log files and the section after this normally assigns ACL entries but it fails before this.

[03/21/2018 09:37:04.0454] [2] Adding the access control entry on the object CN=server,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CNxxxCN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ad,DC=xxx,DC=xxx,DC=xx: S-1-5-21-2802793933-296545649-555512808-1113; Allow; GenericAll; ContainerInheritAll.

What I've checked and tried so far.

-Delegated Setup group does exist in the root domain along with other Exchange security groups
-Install account was already in Org Management and has been added to Enterprise Admin to rule out permissions
-Rerun the /Preparedomain in the child domain
-Windows FW turned off on server
-DC communication appears to be fine
-Instllation user has also been added to delegated setup Exchange group

Anyone seen this before or got any ideas?

Richard InnesSenior IT ConsultantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

timgreen7077Exchange EngineerCommented:
adprep and schema prep needs to be run at the root level, not child domain level. once AD prep and schema performed then you can install at child level
You can just move the fsmo schema owner role in the child domain, make sure your user ha got correct privileges and run setup again.
Procedure and needed privs:
Double check every priv and step.
Richard InnesSenior IT ConsultantAuthor Commented:

Just to clarify, the AD preparation has been carried out a while back as there are other Exchange 2013 servers in a different child domain within the forest.

I wouldn't expect that I would need to run the AD preparation again to add an additional server within the child domain however I was thinking it might be worth getting the forest root admins to run the /preparealldomains switch again just in case it fixes anything.  It does seem to be some sort of permission issue however can't quite work out what's going on.

Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Exactly, you need to prepare the child domain you're installing exchange in .
Richard InnesSenior IT ConsultantAuthor Commented:
Hi Michelangelo,

I can confirm that this has already been performed and the object version shows the correct value. I've seen in the past where you sometimes require to rerun this but doesn't appear to be the issue.

Child domain object version
*) Be advised that if later builds run the same schema versions as its predecessor, that does not necessarily mean you do not need prepare Active Directory (/PrepareAD). Preparing Active Directory may also introduce changes in the Role-Based Access Control configuration, for example. Consult the KB article of the update for guidance.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Richard InnesSenior IT ConsultantAuthor Commented:
I know what your saying but I would expect their to have been issues when EX2013 CU18 was installed successfully in the other child domain of the Forest.  I don't have administrative control over the other child domain so I'm trying to gather some further information on when the AD preparation work was carried out.
I had a similar issue when preparing a second child domain, and was solved when I ran a /prepareAD /PrepareAllDomain. Exchange objects and versions were all correct. My 2 cents
Richard InnesSenior IT ConsultantAuthor Commented:
I would like to rerun both commands from the root domain, unfortunately I don't have full admin control over the environment and it contains around 15,000 users/mailboxes. I have raised a call with MS and if they say the same about re-running ADprep then I can make this suggestion to the IT team that have control of root and other child domain. Thanks for your suggestions.
Many a people believe they do not need to re-run forest and domain preparation before installing a new CU and run in issues such as the one described by OP. This answer (a42527992)explains you have to.
Richard InnesSenior IT ConsultantAuthor Commented:
Just to close this off.  When the AD admin of the root domain attempted to run /PrepareAD at the top level there was an error received about an issue with the one of the well known objects (Screenshot attached). Followed the article below to remove the referenced deleted entry -

We were then able to successfully run the /PrepareAD command and install the Exchange 2013 server without error.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.