Active Directory Migration Tool V3 Error
I am in the process of testing an inter-forest migration between the 2000 source domain (breck) and a 2003 target domain (keystone). The end result will be to consolidate the 2000 domain and the 2003 domain so there is just the one domain, keystone. Anyway, each time i run the tool and try to migrate sid history, it bombs out. I get the error "Could not verify auditing and tcpipclientsupport on domains, will not be able to migrate sids, access is denied. Here is what I have done so far:
-created same account in source and target domain and added to domain admins and admins group
-with the account setup two-way trust between keystone and breck domains from the target domain
-verified the trust through AD domains and trusts
-but could not verify the trust by using netdom trust command
-disbaled sid filtering on keystone target domain
-enabled sid history migration on keystone domain
-created local group breck$$$ on source domain controller to allow for sid history
-added TcpipClientSupport reg entry to HKLM\System\CCS\Control\LS
-checked and verified the HKLM\System\CCS\Control\LS
anyone have any ideas? I have tried running ADMT from the PDC emulator on the target domain and ended up with the same reult. TIA
-
-created same account in source and target domain and added to domain admins and admins group
-with the account setup two-way trust between keystone and breck domains from the target domain
-verified the trust through AD domains and trusts
-but could not verify the trust by using netdom trust command
-disbaled sid filtering on keystone target domain
-enabled sid history migration on keystone domain
-created local group breck$$$ on source domain controller to allow for sid history
-added TcpipClientSupport reg entry to HKLM\System\CCS\Control\LS
-checked and verified the HKLM\System\CCS\Control\LS
anyone have any ideas? I have tried running ADMT from the PDC emulator on the target domain and ended up with the same reult. TIA
-
ASKER
Tried deleting the breck$$$ group and ran the tool again. Same error. I also tried logging into the Target DC with DA account from the source domain, same result. But just to clarify, do you mean logging into the target domain as breck\username. Does it matter if I am using the acct that I set up the trust with which is the exact same account in both domains.
Yes, log onto the target domain with SOURCE\Domain Admin.
Did you get prompted to allow ADMT to re-create the Breck$$$ group? You should have.
Did you get prompted to allow ADMT to re-create the Breck$$$ group? You should have.
ASKER
When I tried to log into the target domain with the above credentials, i get the local policy of this system does not permit you to logon interactively. So then i tried to add the account from the source domain to the default domain policy on the target domain it bombs out. Would this indicate a problem with the AD structure on the source domain and if so is it repairable by dcpromo.
Test your Trusts again.
You should be able to add the Source\Domain Admins group to the Allow logon locally.
You should be able to add the Source\Domain Admins group to the Allow logon locally.
ASKER
The trusts verify just fine throught the AD domains and trusts gui. But interestingly enough, when I try to verify by using netdom trust command it fails.
ASKER
Also tested the two domains with nltest /dcname:breck and I get
NetGetDCName failed: Status = 2453 0x995 NERR_DCNotFound
NetGetDCName failed: Status = 2453 0x995 NERR_DCNotFound
Ok, so this is likely DNS related.
Make sure (on each domain) you setup Conditional Forwarding for the other domain.
You may also need to add entries in LMHOSTS for the other domain - but try the DNS thing first.
Make sure to refer to the opposite domain by FQDN so it can use DNS to locate.
Make sure (on each domain) you setup Conditional Forwarding for the other domain.
You may also need to add entries in LMHOSTS for the other domain - but try the DNS thing first.
Make sure to refer to the opposite domain by FQDN so it can use DNS to locate.
ASKER
Should i setup conditional forwarding if i already have a zone for the source domain and can successfully ping the other dc in the source domain.
If your zone doesn't contain the SRV records then (because it's locally Authoritive) the tendency is to NACK the client for those lookups.
In this instance, it's likely better to remove the locally hosted zone and put in Conditional Forwarding so that ANY query for the opposite domain gets sent to the proper SOA.
In this instance, it's likely better to remove the locally hosted zone and put in Conditional Forwarding so that ANY query for the opposite domain gets sent to the proper SOA.
ASKER
Ok i will try that. Unfort I do not have a test lab that I can actually test on so I am having to test on the production servers using test accts which i have created. That being said, will configuring conditional forwarding have any effect on my keystone users when they go to query dns. I dont necessarily want my clients querying the DNS servers in breck and vice versa.
ASKER
That didnt work with adding the fqdn as a conditional forwarder. Got the same error
ASKER
Would it have any bearing with using the tool if the breck domain also has a trust setup with a NT domain. The breck domain was in mixed mode and I have recently changed it to native.
It shouldn't.
Adding the Conditional Forwarders while still hosting the zones won't work. As long as the zones remain hosted it won't ever forward.
Adding the Conditional Forwarders while still hosting the zones won't work. As long as the zones remain hosted it won't ever forward.
ASKER
Tried to setup forwarders in each domain and still no joy. Get the same error every time. Would demoting one of the DC's and then repromoting it in the source doman help clear this up.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Tried both of those ideas and neither worked. Still getting the error
ASKER
Just tried removing the trust again betweek the Keystone and Breck domain and readding it. When I went to verify the trust I got this new error message "The secure channel reset on domain controller failed with error. access is denied." Maybe this is part of my problem. I tried to reset the trust passwords after the error but to no avail
So you put the #PRE entry in for the other DC in the opposite domain? You need to reboot to get it registered.
I'm at a loss here - we've looked at pretty much everything. We're missing something simple.
What results do you get when running nslookup from each domain for the opposite domain? You should get proper responses if resolution is working.
I'm at a loss here - we've looked at pretty much everything. We're missing something simple.
What results do you get when running nslookup from each domain for the opposite domain? You should get proper responses if resolution is working.
Let's cover some basics before we go in circles.
1) Target domain must be Windows 2000 Native or Windows 2003 Functional level.
2) It isn't necessary to change from default the RestrictAnonymous registry key. I think the value needs to be 2. Zero is used for NT4 migrations.
1) Target domain must be Windows 2000 Native or Windows 2003 Functional level.
2) It isn't necessary to change from default the RestrictAnonymous registry key. I think the value needs to be 2. Zero is used for NT4 migrations.
ASKER
1)Target Domain is 2003 Native in 2003 Forest
2)Source Domain is 2000 Native-it was mixed before the testing but I raised it
3)Restrict Anonymous key is set to the default of 2
The secure channel reset error when I was verifying trusts seems like it could be related to this issue.
2)Source Domain is 2000 Native-it was mixed before the testing but I raised it
3)Restrict Anonymous key is set to the default of 2
The secure channel reset error when I was verifying trusts seems like it could be related to this issue.
ASKER
Netman-
I appreciate all your help. I finally got it fixed. Not certain what exactly fixed it, maybe a combination of things. But what I have done since we last spoke, created a new user acct that was the same on the source and target domains, deleted and recreated the trust with this new user acct, then I nested the user acct with the admins group in the target domain. Ran a couple of nltests to be sure that the secure channel verified and that I could see the other dc in the source domain. Then everything started to work and the local group$$$ was created successfully. Thanks for all your suggestions. They helped steer me in the right direction.
I appreciate all your help. I finally got it fixed. Not certain what exactly fixed it, maybe a combination of things. But what I have done since we last spoke, created a new user acct that was the same on the source and target domains, deleted and recreated the trust with this new user acct, then I nested the user acct with the admins group in the target domain. Ran a couple of nltests to be sure that the secure channel verified and that I could see the other dc in the source domain. Then everything started to work and the local group$$$ was created successfully. Thanks for all your suggestions. They helped steer me in the right direction.
ASKER
great response time. crucial to my testing and did not have wait for responses to my questions.
Excellent.
Glad to assist.
Glad to assist.
Run the tool again. You should be prompted to allow ADMT to create this group for you if it's missing. This will guarantee the group is correct.
If you still get the error, then log into the Target DC with the Source DA account and rerun the tool.