What is DomainPrep and Why DomainPrep the Root Domain?


What is DomainPrep? Why does Exchange recommend running DomainPrep on the Root Domain if there are no Exchange servers or users in that domain?

I have been asked these questions so frequently I thought I’d do a post on it. I know DomainPrep is a little mysterious to many people so let me quickly explain what DomainPrep is and does.

DomainPrep does all the tasks for Exchange Setup which require Domain Admin rights to accomplish. These tasks are:

  • Create two groups; The Exchange Enterprise Servers group (EES) and the Exchange Domain Servers group (EDS)
  • Create the Microsoft Exchange System Objects container (also known as the Domain Proxy Container) in the Active Directory
  • Add permissions (mainly for the EES and EDS) to the Domain, AdminSDHolder, and MS Exchange System Objects containers
  • Add permissions to the EES, EDS, and the Pre-Windows 2000 Compatible Access Group
  • Add the EES to the local security policy “Manage auditing and security log” on every Domain Controller in the domain

Note: The Recipient Update Service (RUS) will keep these permissions up to date when Exchange is installed in new domains and when new Exchange Full Administrators are delegated.

Thus running DomainPrep requires an account that has Domain Admin level permissions, but does NOT require any Exchange Admin permissions. This way you don’t have to give your email administrator Domain Admin permissions in order to install the first Exchange in a given domain.

That’s it. 2 groups, an object, and some permissions for the groups. That’s all DomainPrep is. It doesn’t create any directories, install any binaries, or add any regkeys. It’s actually very lightweight and runs in seconds.

So then why do I need to run DomainPrep is my Root (or Parent) Domain if I’m not going to have any Exchange servers or users with Exchange mailboxes in that domain? The short answer is “Because that’s usually where the GC is”.

The main issue has to do with DSAccess. DSAccess is what Exchange services use to access information in the Active Directory. In order for it to find the correct information, DSAccess needs to talk to Global Catalog servers, even if those servers are not in a domain where Exchange is installed. DSAccess will only talk to GCs that it has rights to. It will check to see if it has rights to that GC by checking if it has privileges to the Security Access Control List (SACL) on the GC. These rights are only propagated by the Recipient Update Service (RUS) and you can only create a RUS for domains that have been DomainPrepped.

If you follow this chain, you’ll see that it comes down to “DSAccess needs to be able to talk to a GC”, and in order to do that the GC has to be in a domain which has been DomainPrep’d and has a RUS pointed at it.

So if you have a parent-child domain configuration, with Exchange only in the child domain, and GCs in the parent domain, you will have to run DomainPrep in the parent domain AND create a new RUS on an Exchange server in the child domain and point that RUS at the parent domain.

Now I know you’re all asking the question “What if you don’t have a GC, or Exchange servers, or users getting Exchange mailboxes in the parent domain?” The answer is: “Then you don’t need to DomainPrep the parent domain.”

So if all your GCs are in the child domain, and none are in the parent domain, and there are never going to be any Exchange resources in the in the parent domain, then you don’t need to DomainPrep it or create a RUS for it. But that configuration doesn’t happen very often and the consequences for not DomainPreping the parent are bad enough (like the Exchange Information Store service won’t start) that we tell everyone to always domainprep the parent domain.

“Berg”


Comments (13)
  1. Dillon TenBrink says:

    Nice article, thanks for the writeup. Now if only we could move those Exchange groups into a different OU/Container than ‘Users’. :)

  2. Anonymous says:

    Exchange-faq.dk – Din portal til Microsoft Exchange Server information

  3. Dung Hoang says:

    Thanks for the writeup. It makes a lot of sense.

    I have some questions though:

    a)Does the RUS re-apply the Exchange GPO to assign specific rights to the Enterprise servers group, every time it runs?

    b) How can I identify which DC/GC that is currently used by an Exchange server?

    Thanks

    /Dung

  4. bergberg says:

    Good Questions and I don’t know the answers because that’s a little out of my area. However I do know someone who wrote part of that code so I asked him (one of the benefits of working here at MS). Here is his reply:

    a. No, it only applies policies when the objects change.

    b. Look at the Enterprise RUS properties. If that DC is gone, the RUS will log a message saying so and pick a random DC. I’m not sure what the event id is.

  5. Graham McIntyre says:

    A question came up on whether this applies to all domains that have GCs in them, not just the root domain.

    The more precise answer is “All GCs in the same Windows site as an Exchange Server should be prepped”. Since DSAccess uses the site boundary (not domain) for choosing local GCs, all in-site GCs should be accessible.

  6. Agpiah says:

    Nice artice thanks,

    When I ran domainprep I got the error that my mail server was not in the exchange domain server group – adding the mail server to this group soon solved the problem but ……..

    What can cause domainprep to run without error but not add the server into this group ?

  7. bergberg says:

    DomainPrep does not add any servers to the Exchange Domain Servers group. It can’t because at the time DomainPrep is run there are no Exchange servers (of the same Exchange version) in that domain because you can’t install an Exchange server without first running DomainPrep. Plus DomainPrep can be run from any server in the domain, whether or not you plan on installing Exchange on that particular server, so there’s no way for DomainPrep to know what machine account to add to the group.

    The Exchange Domain Servers (EDS) group gets populated with the Exchange server’s machine account when Exchange is installed on that server. Only Exchange Full Administrators at the Org level can install an Exchange Server and add the machine account to the EDS automatically because they have been granted this permission during DomainPrep or by the Delegation Wizard.

    If you run Exchange Setup using an account that has Exchange Full Administrator rights at the Administrative Group level (not the Org) then you will get a prereq message saying you need to fist manually add the machine account to the EDS before continuing. Without being able to see your Exchange Server Setup Progress log, I’m going to guess the error you’re seeing is really this prereq.

  8. Agpiah says:

    Thanks for the quick response.

    Just to tie up the loose ends I was installing Exch 2003 via the CD "steps" – after running domainprep it asks you to run orgprepcheck which gives you the above error in the log file it creates.

    If the account is placed there during exchange setup then this part of the orgprepcheck is a little early and will always cause an error ?

  9. bergberg says:

    Ah yes, the OrgPrepCheck tool. That explains it.

    Yes, the OrgPrepCheck tool runs a number of tests and one of them is to see if the local server is joined to the local domain’s Exchange Domain Servers group. That particular test is, as you pointed out, too early and will always have this warning. However, in the logs there is a little disclaimer that says "If the local computer is not running Exchange Server 2003, this is not a problem". So as long as you don’t have Exchange Server installed on that server yet, you can safely ignore this warning in the OrgPrepCheck tool.

    If you run OrgPrepCheck after installing Exchange on the server and you are still getting the error, then there would be a problem because the server wouldn’t be getting added to the EDS as expected. Just be sure you are pointing OrgPrepCheck at the Domain this Server is joined to, prior to running the tool.

  10. Tarek says:

    I had one question.. what if Exchange server was installed without running domainprep?? what would that cause?? and is it ok to run domainprep now on the DC after exchange has been iistalled?

  11. Nino Bilic says:

    Tarek,

    If you do not run the /domainprep separately, the Setup will actually run it for you as Exchange will not work if /domainprep was not run in it’s local domain. The reason we recommend to run them separately is to let the AD replication to stabilize before running the full setup (which could be a problem in large environments) and because running separate steps is easier to troubleshoot in cases of problems. But – if your Exchange setup completed – it also /domainprepped the domain.

  12. Marcus says:

    Hello Tarek,

    if you run Exchange setup routine and you are able to finish installation succesfully and mail flow, calendaring, … works without problems, you can be sure that domainprep was executed in the background.

    You should in a new install first run setup /forestprep, then setup /domainprep and in big environments start the installation of Exchange on the next day.

    You can also check if the group Exchange Domain Servers is a member of Exchange Enterprise Servers and if Exchange Enterprise Servers has Read to f. ex. Domain users, …

    Yes, you can rerun domainprep. Take a look at:
    http://support.microsoft.com/default.aspx?scid=kb;en-us;262068

    Kind Regards,

  13. Anonymous says:

    After my session at the TechNet roadshow yesterday, I  promised I’d make available all the links…

Comments are closed.