Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Active Directory Migration Tool V3 Error

Posted on 2007-12-06
24
Medium Priority
?
1,789 Views
Last Modified: 2012-06-27
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
Comment
Question by:beargonefishing
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 14
  • 10
24 Comments
 
LVL 51

Expert Comment

by:Netman66
ID: 20425210
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
 

Author Comment

by:beargonefishing
ID: 20425403
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
 
LVL 51

Expert Comment

by:Netman66
ID: 20427808
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
Fill in the form and get your FREE NFR key NOW!

Veeam® is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 

Author Comment

by:beargonefishing
ID: 20428279
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
 
LVL 51

Expert Comment

by:Netman66
ID: 20428391
Test your Trusts again.

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

0
 

Author Comment

by:beargonefishing
ID: 20428444
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
 

Author Comment

by:beargonefishing
ID: 20428517
Also tested the two domains with nltest  /dcname:breck and I get
NetGetDCName failed: Status = 2453 0x995 NERR_DCNotFound
0
 
LVL 51

Expert Comment

by:Netman66
ID: 20428537
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
 

Author Comment

by:beargonefishing
ID: 20428708
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
 
LVL 51

Expert Comment

by:Netman66
ID: 20429301
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
 

Author Comment

by:beargonefishing
ID: 20429759
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
 

Author Comment

by:beargonefishing
ID: 20429851
That didnt work with adding the fqdn as a conditional forwarder. Got the same error
0
 

Author Comment

by:beargonefishing
ID: 20429949
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
 
LVL 51

Expert Comment

by:Netman66
ID: 20433989
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
 

Author Comment

by:beargonefishing
ID: 20434989
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
 
LVL 51

Accepted Solution

by:
Netman66 earned 2000 total points
ID: 20435307
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
 

Author Comment

by:beargonefishing
ID: 20438832
Tried both of those ideas and neither worked. Still getting the error
0
 

Author Comment

by:beargonefishing
ID: 20439257
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
 
LVL 51

Expert Comment

by:Netman66
ID: 20439267
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
 
LVL 51

Expert Comment

by:Netman66
ID: 20439389
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
 

Author Comment

by:beargonefishing
ID: 20441196
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
 

Author Comment

by:beargonefishing
ID: 20442901
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
 

Author Closing Comment

by:beargonefishing
ID: 31413332
great response time. crucial to my testing and did not have wait for responses to my questions.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 20443726
Excellent.

Glad to assist.
0

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
After seeing many questions for JRNL_WRAP_ERROR for replication failure, I thought it would be useful to write this article.
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Suggested Courses

688 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question