1

We currently have a single Windows 2008 R2 Active Directory domain controller, and an Exchange 2010 server. We are in the process of adding a child domain on a second Active Directory server for an offsite office location for a subdivision of our company. The two locations will be connected via VPN.

Currently users (approx 20) exist on the root domain with Exchange accounts who will be moving to the new offsite company/location. We would like to be able to move these user accounts to the child domain while maintaining their existing Exchange mailboxes and email addresses (they will continue to share one Exchange server). Is this possible, and if so how would we do it?

It is being setup as a new child domain for the offsite location - the new location is an independent company (partially owned by the parent location/company) and they want an indepdent login domain. Ie. if the corp headquarters logs in with domain ACME\ (ACME.local) then the new office wants to login as FOOBAR\ (FOOBAR.ACME.local) and not ACME. The only shared resource will be the Exchange server (in root domain ACME).

FYI I followed the reasoning and process decribed here for creating an AD child domain: http://blog.pluralsight.com/server-2008-active-directory-adding-a-child-domain

(Note: serverfault is not allowing me to add comments below - clicking the "add comment" link generates a JavaScript error in Chrome). It would certainly be helpful if some of the people criticizing this approach could explain why they think it is not the best approach and why an alternate approach would work better.

Note: the remote office needs the ability for a local staff member to be able to reset users passwords for users in that office, but not in the parent company office.

***Thank you very much for the advice and sorry that I can't comment properly!!

  • Child domain or trusted domain?...just making sure. – TheCleaner Nov 22 '13 at 14:39
  • 1
    Why are you doing this as a new domain? You can keep your administrative burden lower by keeping these users in the same domain, especially since they're going to be in the same forest and exchange org. – mfinni Nov 22 '13 at 14:45
  • 1
    +100 for @mfinni - You don't need a child domain for this location. You're creating needless makework. It doesn't matter that they're a separate, independent company. If you need them to really be separate then they need a separate forest. A child domain is just an illusion and doesn't actually make them separate. They most certainly will "share" resources (in the form of the Global Catalog) with the root domain, whether you like it or not. If you don't really need separation just use your room domain and be done with it. – Evan Anderson Nov 22 '13 at 15:11
  • That article you just linked is full of bad advice and you should ignore it. The global catalog still gets replicated across domains, and a simple DC in the remote office (in the same domain) will keep logins fast. Delegating access doesn't need to be done, there will only be 20 users at the remote location. – mfinni Nov 22 '13 at 15:35
  • social.technet.microsoft.com/Forums/windowsserver/en-US/… -multiple schemas, regulatory or other isolation requirements, or inability to split administration duties and access. None of those apply to the situation you described, so you will be best with one domain. You're talking to experts here on this site - you should absolutely do your own reading to verify our assertions, but please understand we want to keep you out of trouble and misery. – mfinni Nov 22 '13 at 15:38
4

Don't do this. You can keep your administrative burden lower by keeping these users in the same domain, especially since they're going to be in the same forest and exchange org. Per this link

http://social.technet.microsoft.com/Forums/windowsserver/en-US/064aa5c9-f040-45b6-b36a-38d1823c16a1/active-directory-design-multiple-domains-or-organizational-units?forum=winserverDS

the big reasons for multiple domains are multiple schemas, regulatory or other isolation requirements, or inability to split administration duties and access. None of those apply to the situation you described, so you will be best with one domain.

"Note: the remote office needs the ability for a local staff member to be able to reset users passwords for users in that office, but not in the parent company office."

That can be done very simply with putting those users in their own OU (which is a great idea) and delegating password reset ability in that OU to the remote support person

For appearances : You can assign the remote users a different UPN and have them use that as their login - user@foobar.com, and make it the same as their email address. This will be a highly-visible reminder that they think they're separate. –

  • 1
    Actually, there's one Schema per forest. There are even fewer reasons for multiple domains. It's really just a management boundary at this point which is unnecessary in almost all cases. – MDMarra Nov 23 '13 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.