ChocolateRain
asked on
ADMT 3.2 & PES 3.1: Unable to establish a session with the password export server. Access is denied.
I am trying to migrate my domain and am encountering a problem with the ADMT PES account migration. When I try to migrate a user password it fails with the above listed message. I have the PES server on a different DC than the one I'm targetting for migration, and i have my ADMT server on a different server than the 1 DC in our target domain. Everything is virtualized with ESX 4.0.
When I skip the PES password migration to see if I can migrate without bringing over the password it gives me a different error on the "Account Transition Options" page saying "Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate SIDs. Access is denied."
I can ping FQDNs and host names via each server involved in this process. This is a Inter-Forest migration (between 2 seperate forests) and the trust is setup already and is working. I have a user called PES that is a Domain Admin in the source domain and a member of the built-in Administrators group in the target domain. I have an ADMT user that is in the Domain Admins of the target domain and is a member of the built-in Administrators group of the source domain. The trust is working. Auditing has been enabled and is showing up on the servers it should be when I run rsop.msc. The following registry keys have been updated to show the following: On PES: HKEY_LOCAL_MACHINE\System\
On Target DC: HKEY_LOCAL_MACHINE\System\
Any ideas as to why this might not still be working?
When I skip the PES password migration to see if I can migrate without bringing over the password it gives me a different error on the "Account Transition Options" page saying "Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate SIDs. Access is denied."
I can ping FQDNs and host names via each server involved in this process. This is a Inter-Forest migration (between 2 seperate forests) and the trust is setup already and is working. I have a user called PES that is a Domain Admin in the source domain and a member of the built-in Administrators group in the target domain. I have an ADMT user that is in the Domain Admins of the target domain and is a member of the built-in Administrators group of the source domain. The trust is working. Auditing has been enabled and is showing up on the servers it should be when I run rsop.msc. The following registry keys have been updated to show the following: On PES: HKEY_LOCAL_MACHINE\System\
On Target DC: HKEY_LOCAL_MACHINE\System\
Any ideas as to why this might not still be working?
ADMT is free and therefore, a major PITA to set up. I've found that if you miss any one of the steps in the ADMT set up, it will fail. Run through the ADMT/PES checklist again and execute them in the exact order as it instructs. Also, use the same server for the PES as the target migration DC.
ASKER
Thanks for the advice. The book I've finished reading "Mastering Windows Server 2008 R2" from Sybex said the same thing: "ADMT is a nightmare".
I've been through the steps so many times I'm blue in the face. I emailed Microsoft and am now working on it with them. If I get an answer specifically as to why it wasn't working I'll post it here.
I've been through the steps so many times I'm blue in the face. I emailed Microsoft and am now working on it with them. If I get an answer specifically as to why it wasn't working I'll post it here.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.