locked
ADMT Computer Migration Failures RRS feed

  • Question

  • Please bear with my longevity; I wanted to give as many details as possible.  My goal is an Interforest migration but currently I am working in a test environment.  The source.com domain has a Windows Server 2003 DC and a Windows 2008 member server with Exchange 2007.  The target.com domain has a Windows Server 2008 DC (2003 functional level) and a Windows 2008 member server with Exchange 2007.  My trust between the two forests validates successfully and all servers and workstations involved can ping each other.  Initially I had my DC in the target.com domain a Windows Server 2003 DC and was using ADMT v3.0 but moved on to 2008 and ADMT v3.1 in hopes that would solve my computer migration problem.

     

    In both scenarios I have been able to migrate users and groups as well as move mailboxes between the two Exchange servers.  My hang up has continually been with migrating computers.  All the workstations are running Vista.  In my 2003 to 2003 ADMT v3.0 environment the process would get all the way through running the agent successfully on the computer in the source domain as well as running the post check and automatically rebooting the computer.  After reboot the login screen would have the old domain but choosing to Switch User would default to the new domain.  The problem was that my login attempts were greeted with a red X and The security database on the server does not have a computer account for this workstation trust relationship.  Logging in locally, leaving the domain and rejoining it worked but that wasn't a solution.  I couldn’t figure this out so I moved on and upgraded my DC to Server 2008 in my target.com domain and installed ADMT v3.1.

     

    Users and groups still migrate successfully but the computer migration is now failing during the agent part.  When the Agent Operation is performed it comes back with a “Completed with Errors” message and the post-check is not attempted.  At the bottom of the agent log I get:

     

    ERR3:7075 Failed to change domain affiliation, hr=80070005   Access is denied.

     

    My permissions are as follows:  I am running ADMT on the target DC and I am logging in with a user from the source domain (I have tried it with a domain admin in the target domain with equivalent permissions with the same results).  The source user is a domain admin.  There is redundancy here but the local administrator group on the source workstation has the domain admin group from the source and target domains, and the domain admin users that I have been using from both domains.  The builtin administrators group on the source DC and the target DC have the same setup, domain admin group from both domains and the two domain admin users.

     

    One step I am not completely clear about is delegating permission to the source user on the target domain’s OU’s.  I have been choosing “Create a custom task to delegate” and then Full Control which checks the boxes for all permissions.  I have had it multiple ways but at this point I have the IP address on the workstation manually set with DNS IPs of the DC’s in each domain.

     

    Please let me know if I can provide any more details and I appreciate any help anyone can offer.

     

    Thanks,

     

    Matt

    • Edited by Matt-PPI Friday, October 24, 2008 10:14 PM
    Friday, October 24, 2008 8:16 PM

Answers

  •  

    Hi,

     

    Do you have other DCs in your target domain? If so, please ensure to modify this group policy on them. In addition, this group policy setting will be reflected in the following registry on target domain DCs:

     

    HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes"

     

    Please open 'regedit' on target DCs, navigate this registry and make sure its value includes the following items:

     
    "COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, BROWSER, NETLOGON, Lsarpc, samr".

     

    After doing these, if this issue still continues, please send the error log of computer migration to me via tfwst@microsoft.com with the following two lines in the email body:

     

    ADMT Computer Migration Failures

    Morgan

     

    Thanks.

     

    • Marked as answer by Matt-PPI Friday, October 31, 2008 12:43 AM
    Thursday, October 30, 2008 9:22 AM

All replies

  •  

    Hi,

     

    As for "The security database on the server does not have a computer account for this workstation trust relationship" error message, it might be related to 'the failure of compute account migration'.   

     

    As for "7075 Failed to change domain affiliation, hr=80070005" error message, it's probably caused by the several factors. However, based on the situation that you have successfully migrated user and group accounts, I'd suggest performing the following steps to check the result:

     

    1)Disable firewall on the client PC that ADMT pushes agent to

     

    2)Explicitly add user account running ADMT into local administrators group of the client PC that you migrate

     

    3)double-check the following aspects:

     

    1.      TcpipClientSupport is enabled and set to 1 on the source DC.

     

    2.      Account Management Audit was enabled on either the source domain or the target domain.

     

    3.      The targetdomain$$$ local group was created in source domain

     

    If anything is unclear, please post back.

    Monday, October 27, 2008 7:55 AM
  • 1) The workstation does not have anti-virus installed but I disabled the Windows Firewall.

    2) The user I am logging in to the target server to run ADMT with is (was) in the local administrators group on the workstation.

    3)  I double-checked these and they were already set.  I had done the TcpipClientSupport entry myself and ADMT did 2 and 3.

    I tried it again with the only difference being disabling the Windows Firewall and it failed with the same domain affiliation change error.

    Anything else I should check?
    • Edited by Matt-PPI Monday, October 27, 2008 8:04 PM
    Monday, October 27, 2008 8:02 PM
  •  

    Hi,

     

    To further locate the reason, we should understand the main process of computer account migration at frist. I list this as the following:

     

    Analysis:

    ==========

    1. A computer account is staged in the target domain using the credentials of the ADMT

    operator

     

    2. ADMT agents are dispatched to the computer being migrated using the credentials of the

    ADMT operator

     

    3. ADMT agents changed the domain membership locally on the computer in system

    context

     

    4. ADMT agents sync the computer with the target domain using anonymous connections to the LSARPC and NETLOGON named pipes on the target domain's DC.

     

    Suggestion:

    =========

    From the error message, the problem may occur when ADMT agents try to sync the computer domain information. Since ADMT agents use anonymous security context to sync update information with the target domain, I'd like to suggest checking the following policy on target DC.

     

    Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options\

    NetWork Access: Named Pipes that can be accessed anonymously"

     

    Is it defined? If not, please define it and ensure the following services included in the list:

     

    "COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, BROWSER, NETLOGON, Lsarpc, samr"

     

    About more information about this policy, please visit:

    http://support.microsoft.com//kb/555340

     

    Let me know the result.

     

    Wednesday, October 29, 2008 9:22 AM
  • I went to the local Group Policy on the target domain controller and that policy was defined but only had "browser" as an entry.  I added the additional services you listed and rebooted the server.  I double-checked that the local Group Policy had retained the changes, which it did and attempted another computer migration with the same error result.
    Wednesday, October 29, 2008 4:19 PM
  •  

    Hi,

     

    Do you have other DCs in your target domain? If so, please ensure to modify this group policy on them. In addition, this group policy setting will be reflected in the following registry on target domain DCs:

     

    HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes"

     

    Please open 'regedit' on target DCs, navigate this registry and make sure its value includes the following items:

     
    "COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, BROWSER, NETLOGON, Lsarpc, samr".

     

    After doing these, if this issue still continues, please send the error log of computer migration to me via tfwst@microsoft.com with the following two lines in the email body:

     

    ADMT Computer Migration Failures

    Morgan

     

    Thanks.

     

    • Marked as answer by Matt-PPI Friday, October 31, 2008 12:43 AM
    Thursday, October 30, 2008 9:22 AM
  • That registry key ended up being the problem.  All those entries were there but they were each surrounded in quotations marks except for the first and last entries which were missing the quotes at the beginning and end respectively.  I got rid of all the quotation marks, rebooted the server, ran another computer migration and it was able to change the workstation's domain affiliation this time.  A second workstation was able to migrate successfully as well so I am calling this solved.  Thanks for all the help, Morgan.

    -Matt
    Friday, October 31, 2008 12:42 AM
  • Thanks for your responce. Have a good weekend!
    Friday, October 31, 2008 1:41 AM
  • Hi Morgan,

    I am receiving the above issue but the issue is still not resolved . I have done all the mentioned trouble shooting, But as stated above in point number 3 - "The targetdomain$$$ local group was created in source domain" d this is contradictory as one of the site says " In the source domain, create a local group called SourceDomain$$$, where SourceDomain is the NetBIOS name of your source domain." Pls confim.

    Reff : http://social.technet.microsoft.com/wiki/contents/articles/16621.interforest-migration-with-admt-3-2-part-3.aspx.

    Issue still persist. 

    Thursday, June 2, 2016 9:34 AM
  • Thanks Morgan, this solved my issue.
    Monday, February 12, 2018 12:45 PM