locked
ADMT 3.2 ERR2:7711 Unable to retrieve the DNS hostname for the migrated computer The ADSI property cannot be found in the property cache. RRS feed

  • Question

  • Hi,

    I'm testing the migration of test objects from source to target domain (interforest), so far the steps below have been succesfull

    - Migrated test Global Group
    - Migrated test user (disabled in target)
    - Translate Profile (Replace mode)

    When i try to do the next step which is migrating the test computer i get the below error

    ERR2:7711 Unable to retrieve the DNS hostname for the migrated computer '####-DT10732.##########################. The ADSI property cannot be found in the property cache.


     
         
    Migration000017.log
         



    Current Setup

    - ADMT Service Account created in the source domain
    - ADMT service Account, member of domain admin in target domain and member of Administrators in source domain
    - Running ADMT from Target DC logged on as ADMT Service account
    - Logged on as ADMT Service Account, can access the test machines ADMIN$ share
    - Trust Relationship in place between forests
    - DNS configured with conditional forwarders
    - Source domian configured to allow file and printer sharing exception through GPO
    - Auditing enabled in both forests
    - SID History configured in both forest
    - PSE configured
    - Firewall disabled on test computer
    - Test machine has static ip address with Preffered DNS pointing to Target domain DC
    - Remote Registry service running on test machine
    - Server service running on test machine
    - DNS suffix search list GPO configured on Target domain
    - Client computers are Win XP SP3

    Any help will be appreciated as it's doing my head in : )

    Cheers
    Wednesday, March 16, 2011 4:22 AM

Answers

  • This is a DNS issue.

    Make sure that you are using the correct DNS server.

    Use nslookup to check that.



    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Microsoft Student Partner
    Microsoft Certified Professional
    Microsoft Certified Systems Administrator: Security
    Microsoft Certified Systems Engineer: Security
    Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration

    • Marked as answer by Miles Zhang Monday, April 4, 2011 1:15 AM
    Wednesday, March 16, 2011 4:45 PM

All replies

  • This is a DNS issue.

    Make sure that you are using the correct DNS server.

    Use nslookup to check that.



    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Microsoft Student Partner
    Microsoft Certified Professional
    Microsoft Certified Systems Administrator: Security
    Microsoft Certified Systems Engineer: Security
    Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration
    Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration

    • Marked as answer by Miles Zhang Monday, April 4, 2011 1:15 AM
    Wednesday, March 16, 2011 4:45 PM
  • Sounds like a name resolution issue. From the ADMT server, can you access \\workstation\admin$ share?

    Please review and verify the items described in my Computer Migration - Things to Consider blog:  http://www.sivarajan.com/cm.html

     


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX

    Blogs - http://blogs.sivarajan.com/
    Articles - http://www.sivarajan.com/publications.html
    Twitter: @santhosh_sivara - http://twitter.com/santhosh_sivara

    This posting is provided AS IS with no warranties, and confers no rights.
    Sunday, March 20, 2011 2:59 PM
  • I've seen multiple things cause this issue, check the following:

    1. Workstation and ADMT server are using the same DNS and WINS (Yes WINS is required) servers
    2. Domain Controllers GPO setting for [Computer Configuration\Policies\Administrative Templates\System\Net Logon\Allow cryptography algorithms compatible with Windows NT 4.0] set to enabled in target domain (See KB942564 for more details)
    3. The following service are running on the Workstation: Remote Registry, Server, Workstation, & Netlogon

    Also see this great post: Computer Migration - Things to Consider


    If this post helps to resolve your issue, please click the "Propose as Answer" If you find it helpful , mark it as helpful by clicking on "Vote as Helpful" button at the top of this message. By marking a post as Answered, or Helpful you help others find the answer faster. If you need an expert migration consultant to assist your organization feel free to contact me directly.

    Jason Sherry | Blog | Hire Me | Twitter: @JasonSherry
    Microsoft Infrastructure Architect, MCSE: M, MCTIP, Microsoft Exchange MVP

    • Proposed as answer by Jason Sherry Sunday, April 15, 2012 6:26 PM
    Sunday, April 15, 2012 6:26 PM
  • I got the same issue and tried possible solutions posted here. Please check the attached file and below description if you can point out any possible solution then it would be really great.

    https://docs.google.com/drawings/d/1HmO-a5fkYHsOn4e-jdSglQqIyCuBAdRVd_ZIGEvrQHA/edit?usp=sharing


    Using ADMT 3.2 (revised for 2012R2)

    Config-

    Host - DC01
    OS: 2012R2 (Lab uses eval license)
    Services-
    Domain Controller - EXO.com
    ADDS
    DNS - Configured with reverse lookup and Stub zones (also tried conditional forwarders)
    DHCP - Configured for both subnets
    RAS - Routing service

    Network Hosted on DC01 -
    3 Nic's

    1. 192.168.1.0 - Original Subnet for EXO.com
    2. 127.0.0.1 - Host IP for DC01
    3. 192.168.2.0  - Subnet for Tree domain POS.EXO.com
      Host - POSDC01
      OS: 2012R2 (Lab uses eval license)
      Services -
      Domain controller -POS.EXO.com
      ADDS
      DNS -configured with reverse lookup and Stub zones. (also tried conditional forwarders)


      --------------------------------------------------------------------------------------
      Account configuration:
      EXO.Com -
      Administrator (Enterprise Admin, Schema Admin, Domain Admin)

      POS.Exo.com-
      Administrator: (Domain Admin)

      Notes:  
      I’ve tried both ways with each Administrator configured with all givable permissions to each domain and configured group policy to set each admin with local admin rights to all client computers.

      Configured both domain’s group policy for searching both domains as well.
      --------------------------------------------------------------------------------------
      Preliminary:
      When migrating users and groups I have no issues.

      Problem:
      When Migrating computer accounts from Forest Root Exo.com to sub domain POS.Exo.com I receive an error stating:

      ADMT 3.2 ERR2:7711 Unable to retrieve the DNS hostname for the migrated computer The ADSI property cannot be found in the property cache.


    Tuesday, November 4, 2014 6:15 PM
  • Me too having the same issue??

    ADMT log error : ERR2:7711 Unable to retrieve the DNS Hostname for the migrated computer. 'computerfqdn'. The ADSI property can not be found in the property catce (hr=0x8000500d)

    Client login issue :- 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.

    Still the issue is not resolved ....

    Thursday, May 26, 2016 10:01 AM
  • Hwy Sntsh, I'm facing the same DNS issue with an Intra-forest migration and still looking for the resolution as our DNS replication is slow and that might be affecting ADMT ability to resolve the computer on the new domain. I want to test having both computers pointing to the same DNS master service.

    Regarding the login issue it's related to the missing SPNs for the replicated account.

    Microsoft implemented in Windows 2012 R2 a restriction for duplicate SPNs within the same forest (KB3070083) and that affects the ability of ADMT migrating correctly the account.

    Creating manually the 'Service Principal Name' values should fix your login issue, however you would like to have ADMT to that automatically.

    Wednesday, June 22, 2016 11:24 PM
  • Hello did anyone find a fix for this ? I am having the exact same error on the post. I have all the GPOs in place. I have to do manual reboot for the A record to appear but the post fails and I am able to login it to the new domain.

    ADMT 3.2 ERR2:7711 Unable to retrieve the DNS hostname for the migrated computer The ADSI property cannot be found in the property cache.

    Monday, February 5, 2018 7:19 PM
  • We set Computer > Administrative Templates > Network > DNS Client > Primary DNS suffix to not configured on the source domains.

    This was causing the trust relationship to fail on first boot of the migrated computer account. If you rebooted all as well but this added complexity to the process. I assume the first boot of the computer required the new GPO on the target domain to change the Primary DNS suffix, however it wasn't able to do it in time for the ADMT computer migration process to work properly.

    Hope this helps someone.



    • Edited by Amayacitta Tuesday, January 22, 2019 12:58 PM
    Tuesday, January 22, 2019 12:57 PM