Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1802
  • Last Modified:

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\LSA
-checked and verified the HKLM\System\CCS\Control\LSA reg key for restrictanonymous=0

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

-

Open in new window

0
beargonefishing
Asked:
beargonefishing
  • 14
  • 10
1 Solution
 
Netman66Commented:
Delete the breck$$$ group on the source domain.  Make sure (if you have multiple DCs) that you allow for replication.

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.

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
Netman66Commented:
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.

0
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
Netman66Commented:
Test your Trusts again.

You should be able to add the Source\Domain Admins group to the Allow logon locally.

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
Also tested the two domains with nltest  /dcname:breck and I get
NetGetDCName failed: Status = 2453 0x995 NERR_DCNotFound
0
 
Netman66Commented:
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.

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
Netman66Commented:
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.

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
That didnt work with adding the fqdn as a conditional forwarder. Got the same error
0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
Netman66Commented:
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.

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
Netman66Commented:
No, I wouldn't think that would do anything for you.

Try nesting the Domain Admin group from the opposite domain in the local Admin group on your Root DCs.

I'm still thinking this is a resolution issue.

You may want to try the LMHOSTS entries as explained here:
http://support.microsoft.com/kb/180094
http://support.microsoft.com/kb/150800

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
Tried both of those ideas and neither worked. Still getting the error
0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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
0
 
Netman66Commented:
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.

0
 
Netman66Commented:
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.

0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
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.
0
 
beargonefishingDirector of Network InfrastructureAuthor Commented:
great response time. crucial to my testing and did not have wait for responses to my questions.
0
 
Netman66Commented:
Excellent.

Glad to assist.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

  • 14
  • 10
Tackle projects and never again get stuck behind a technical roadblock.
Join Now