Domain – Parent Domain can’t access Child Domain A/D but can ping & access files

You can place the users from the "parent" domain into a global group in the parent domain, then nest that global group into the "Administrators" domain local group in the "child" domain. That will give you the functionality you're looking for (assuming a stock set of AD permissions on the child domain). "Administrators" gets named with the same rights as "Domain Admins" in all the permissions on the AD.

As far as permissions on shares and such that you've created-- that's your problem. >smile<

Edit:

The "BUILTIN\Administrators" group in the child domain does have the same rights to Active Directory as the "Domain Admins" group in the Active Directory. You're not talking about rights to Active Directory in your comment-- you're talking about a default group nesting that gets performed on the Local Users and Groups on member computers. The kind of thing you commented on is what I mean when I said "that's your problem". It's an easy one to fix, too.

This is a job for "Restricted Groups" policy!

So, let's say that you want to modify the behaviour of the local "Administrators" group nesting domain-wide in the child domain.

• Create and link a GPO at the root of the child domain (actually, link it to a sub-OU with a test computer in it first, then when you know it's working, link it to the root of the domain).
• In that GPO, open "Computer Settings", then "Windows Settings", "Security Settings", and "Restricted Groups".
• Right-click "Restricted Groups" and do an "Add Group".
• Click "Browse" in the "Add Group" dialog, key in "Administrators" (not "Domain Admins" or anything else), and click "Check Name" and "OK". Click "OK" to dismiss the "Add Group" dialog.
• In the "Administrators Properties" dialog, click the "Add" button at the top, beside the "Members of this Group" list-box.
• Click "Browse" in the "Add Member" dialog and key in "Domain Admins" and click "Check Name" and "OK". In the "Add Member" dialog, you'll see "CHILDDOMAINNETBIOSNAME\Domain Admins" listed. Click "OK".
• In the "Administrators Properties" dialog, click the "Add" button at the top, beside the "Members of this Group" list-box again.
• Click "Browse" in the "Add Member" dialog and key in the name of the global group in the parent domain that you created to hold users who are getting "Administrator" rights in the child domain. Before you click "Check Name", click "Locations" and choose your parent domain in the "Locations" dialog and click "OK". Then click "Check Name" and "OK". In the "Add Member" dialog, you'll see "PARENTDOMAINNETBIOSNAME\Group name you created" listed. Click "OK".

When this GPO applies to computers, their local "Administrators" group will get the groups "CHILDDOMAINNETBIOSNAME\Domain Admins" and "PARENTDOMAINNETBIOSNAME\Group name you created" nested into it automatically.

You'll definitely want to use the ADMT for this process. The version you use will be dependent on what systems you need to migrate. For example, if you need to migrate Windows 7/ or server 2008 R2 machines, you will need to run ADMT v3.2 which can only be run on a Server 2008 R2 install. If you have no Server 2008 / 2008 R2 / Windows vista / Windows 7 machines, you can use ADMT v3.0 which can be installed on Server 2003.

As Mark pointed out you can't use ADMT to migrate a DC. You'll want to start out your migrations by DCpromo'ing out one DC at the site you are migrating. When that is completed and fully replicate throughout your topology (replmon.exe is good for checking this), you can then use ADMT to migrate the server. Once it has completed migrating, you can then DCpromo it into the Root Domain.

DNS should be installed on the DCs, if not already, and AD will replicate your AD-I zones (root domain zone) to the DCs added to your root domain. You will need to re-authorize you DHCP servers once they are migrated over to the root domain (needs an account with Enterprise admin privileges).

I have found the following migration order to work well for me:

1. Migrate Groups
2. Migrate Users (rename the conflicts before migrating, it will save you a hassle)
3. ADMT will set your users to change password at next log on after migrating
   4. If you don't want them to have to change the passwords, set each user to not have to change.
4. DCpromo out one DC, Migrate, DCPromo into new Domain
5. Migrate any other File, and Application servers (be sure to plan for the impact on applications and verify with Vendors on changes that need to be made).
6. Migrate PCs
7. DCpromo out 2nd DC, migrate, DCpromo into new Domain

With proper planning the impact on users should be extremely minimal. I have done migrations of full sites of 100+ PCs, and servers in a maintenance window of around 6-8 hours.

There are other things that you will need to consider like using the Password Export Service to migrate passwords.