Creating a new AD Domain
Posted by CaptainZhon@reddit | sysadmin | View on Reddit | 10 comments
It's not everyday one gets to create a new AD Domain. Our company was bought by PE and merging with another company. Our company has the better IT Stack - but they do not want to keep our domain name. We use Okta for 2fa and have a MS Tenant.
So question for those that have gone through this before and lessons learned - how would you create a net new domain? Really don't want to rename the AD Domain as I feel it could complicate things.
sryan2k1@reddit
Quest makes a migration tool that will help on the windows side. The cloud will be work. We paid CDW to help us the last time we went though it.
ambscout@reddit
I went through this starting a year and a half ago. It took right at a year to complete. We looked at Quest but it was outside our budget. Here's the overview of what we did:
Design - Determine OU structure, general GPOs, structure, etc.
Buildout - Build domain, DCs, GPOs, groups, DNS, Trust with old domains, etc.
Pre-migration - We used ADMT to create all the users and copy the user SIDs. We built out file share and application groups and assigned access.
3.1 Test migration - migrated IT staff and a couple of test users.
4.1 Infrastructure Migration - Migrate DNS, DHCP, etc.
KStieers@reddit
IIRC, if you had Exchange, you can't rename the domain...
As far as new goes deploy 2 new vms, remove from your old domain, dcpromo one into the first server in a new domain, then promote the other.
Then build a trust between them.
Migrate users, groups, and services.
When we did it, we created the same group structure in the new domain, added new groups to the old groups and added new users to the new groups. Moved workstations over. Then had users login using new login.... Then brought services over and re acl'd them with new groups as they came over.
YMMV, and it was 20+ years ago so I may be mis remembering it...
ajf8729@reddit
Deploy the two new VMs as manual builds, install the ISO yourself, and then create the domain on the first, and promote the second directly into the new domain as a DC from workgroup status. Do not build servers into an existing domain only to remove them to build a new domain, that’s just silly and trains your new domain from day zero.
Secret_Account07@reddit
Good answers here but keep in mind this would be a great opportunity to do some other stuff.
Want to clean up GPOs? Harden templates? Something you’ve wanted to do and now would be a good time?
I generally don’t advice multiple changes at once but if folks are expecting changes doesn’t hurt to tighten up security
CloudNCoffee@reddit
I’d avoid renaming the domain... it usually causes more issues than it solves. Spin up a new AD domain in parallel and do a staged migration (users, devices, apps). Since you have Okta + M365, that’ll help smooth the transition.
dude_named_will@reddit
This and you can set up a trust between the two domains.
Adam_Kearn@reddit
Spin up two new VMs and install the ADDS roles Create the domain and OU layout that you want.
If you have more than one email domain add the UPN suffix into the proprieties.
Setup all your GPOs and test on a few computers. Setup a trust between your existing domain(s)
Then slowly start migrating user and computer objects over.
——
One thing to look out for when doing this.
The domain you use (company.com) make sure your website has a www.company.com DNS record for the website.
You then setup a redirect on your webhosting provider to redirect company.com to www.company.com (if this is not already configured)
Then in the local windows DNS on your new domain controllers you need to make a “forward lookup zone” for www.company.com to use external DNS servers (8.8.8.8/1.1.1.1) for name resolution.
This is because if you call your AD domain the same as your website when users internally try to access the domain it will not know how to resolve it.
Doing it this way allows for it to redirect to the www. subdomain for websites resolution.
(There are loads of guides online explaining this process. Sounds more complicated than it really is)
The alternative is to call your AD domain ad.company.com which I’ve seen done at a few places but I don’t personally prefer.
SudoZenWizz@reddit
You can use in ad another upn suffix. This is also reccomended for entra sync. In the end, user will be able to login with user@new_upn.tld
Renaming the principal is a pain, not sure if fully possible without issues
tensorfish@reddit
Do the boring side-by-side migration. New forest/domain, trust it, then move users, devices and apps in waves. The part that eats months is not the DC build, it is every cert, service account, script, file permission and random app binding that hardcoded the old name. Okta and M365 help with sign-in, but they do not save you from that archaeology.