I was involved in a inter-forest Active Directory migration recently using the ADMT 3.2 and PES 3.1 tools and came across a wierd issue which really puzzled me for a few days.
Everything was setup correctly, the trust, the migration account, the permission, the DNS, the firewall is off. Looking at the migration agent log file, it said it was successful. Everything seems to be working except when I tried to logon to the workstation in the new forest root domain after the workstation migration using ADMT 3.2. I got the message "The Security database on the server does not have a computer account for this workstation trust relationship" I was like... "What the ..."
After some investigation, I realized that the Service Principal Name (SPN) was not set correctly after the migration. You can look at the workstation SPNs in "Advance View" of the Active Directory Users and Computers. Looking at the "servicePrincipalName" attribute, the property was empty. That's wierd. To temporarily resolve this issue, you can insert the following entries in the SPN and you will be able to logon to domain on the workstation (Reference: http://virtualcurtis.wordpress.com/2011/03/02/fix-the-security-database-on-the-server-does-not-have-a-computer-account-for-this-workstation-trust-relationship/)
HOST/ComputerNetBIOSName
HOST/ComputerFQDN
However, that's not what we want.. we need to find out the root cause of this problem. After some thorough investigation, I think I found the culprit. Well, I at least when I corrected this problem, the problem went away.
In the source domain, one of the GPOs has the "Primary Domain Suffix" defined in Computer Configuration\Administrative Templates\Network\Dns Client. It was pointing to the source domain. Luckily this blog points me to the right direction. During the migration, the agent was not able to update the workstations or their A records in the DNS and therefore the SPN property was empty and not allowing logon to the domain. I removed the GPO entry and everything started to work perfectly.
