After you run the Computer Migration Wizard and move a computer from the source to the target domain, the following errors are logged in the agent logs:
ERR2:7709 Post-check failed on the computer ‘Computer.domain.name’.
ERR2:7675 Unable to verify the migrated computer belongs to the domain. Access is denied. (hr=0x80070005)
In the Agent Dialog you see that the Post-check for the computer Failed, and the Message is Unable to verify the migrated computer belongs to the domain.
It’s only ERR2:7675 that really gives you any information here.
If you try to browse to the Admin$ share on the migrated computer account you get the following error
A Little Background
I’m using ADMT V3.2 to move users and computers between a single forest source, into 5 target domains, distributed between 2 target forests.
This detail may be slightly irrelevant, but it will explain the options I chose in setting up the migration environment that contribute to the error.
I set up a migration account in the source domain and made it a member of the Domain Admins group.
On each of the target domains, I logged in to a target DC’s as the source domain account, and installed SQL and ADMT.
I created two way forest trusts, and disabled SID filtering.
I created the Domain$$$ group in the source domain only.
Almost everything works really well.
The biggest cosmetic headache I have on this project with this configuration is the post-check failure, the ERR2:7675
The users, password, groups and computers all migrate really well. We have the odd issue, ADMT doesn’t get at the insides of a SQL database so these need some work, and laptops migrate better when wired than over WiFi, but this may be peculiar to Dell laptops.
But the post check fails every time, and ERR2:7675 is in the logs.
The issue here is simply that the ADMT leaves the source computer object behind after it joins the computer to the target domain and Kerberos doesn’t like this at all
Have a look at the System Event logs, filtered for the Security-Kerberos event ID 4
There is one of these for each migrated computer object in the domain.
It’s the last two lines of the descriptions that tell you what the problem is in this case.
If the server name is not fully qualified, and the target domain is different from the client domain, check if there are identically name accounts in these two domains.
Will with ADMT there are, because it doesn’t clean up the source computer objects.
It’s an issue in my case because the ADMT migration account is running in the source domain.
If I delete the source account post migration after the “Completed with Errors” or “Successful” message, during the Post-check “Waiting for Reboot” stage, or during the retry interval, the post-check will pass.
Had I set up ADMT to use a target account, I could have avoided the post-check ERR2:7675, but I would have had other issues getting my multiple target migration accounts access to local administrators on the source domain computers.