• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 7572
  • Last Modified:

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.

Hi Experts,

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
0
WeirdFishes
Asked:
WeirdFishes
1 Solution
 
Vishal PatelCommented:
I think you have a problem related to lookup.
You need to configure DNS in both the domains for both the domains. i.e. suppose you have domainA and domainB, then you need dns of domainA should be able to resolve arp or rarp of domainB and vice versa,
You can set forwareders in each DNS server for other domains.
0
 
WeirdFishesAuthor Commented:
both domain have the other configured as stub zones as below

source domain has a stub zone for target domain
target domain has a stub zone for source domain

target DNS had DC.source domain as a forwarder
just added dc.target as a forwarder in source DNS and issue still persist

thanks for the help in advanced....
0
 
RickSheikhCommented:
You seem to have covered all the steps/pre-reqs properly. I have seen this error in the post-check section of a computer migration in ADMT.

Is that where you are getting it ?
0
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

 
WeirdFishesAuthor Commented:
Yes, i receive the error at post-check in ADMT Tool Agent Dialog box.
0
 
RickSheikhCommented:
In my experience you can ignore it. If you take a look at the log that post check is still trying to do something against the source object which has the FQDN changed to reflect the target domain.
0
 
WeirdFishesAuthor Commented:
issue has been fixed.

the error msg is a bit vague from the admt console log (the one in the question subject) but when i checked further the issue by going to the agent logs files through windows explorer on the target DC where ADMT is installed i found another error msg which is more related to the cause of this issue, see below.

ERR3:7075 Failed to change domain affiliation, hr=800704f1   The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you

basically the issue is that the machine can't authenticate to the new 2008 R2 DC as it uses a weaker netlogon authentication algorithm wich is a feature rathan then an issue in Server 2008. to fix this issue you have to Allow cryptography algorithms compatible with Windows NT 4.0.

FIX
In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.

After these changes i was able to migrate machines.

0
 
WeirdFishesAuthor Commented:
Provided fix for the issue.
0
 
infoplateformCommented:
Hi Weired Fishes,

I Got same error but i am doing intraforest migration so do u think i will resolved my issue

for DNS i do stub zone settings ?


Regards,

Osama Mansoor
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

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