ADMT 3.2 SID History issues


  • Here is the situation.

    We have just setup a new child domain (call it child) and are trying to setup ADMT 3.2 so we can migrate from a domain in another forest (call it old).

    Now we have done a bunch of testing using ADMT with our parent domain (parent) and the “old” domain. These tests all worked great, no issues at all.

    Now that we have “” setup it has transitional trusts setup between “parent” and “old” and our DNS is configured to we can nslookup, ping, see each other in AD etc fine.

    Our domain level is currently running at the 2003 level, our new DC’s are running server 2012, and our ADMT box is a member server running 2008 R2.

    So here is the issue, when we run ADMT for the first time and go through a group migration from my reading and understanding this first migration should prompt to see if there is auditing enabled, and the [sourcedoamin]$$$ group exists, etc. now this does not ever happen.

    So we have enabled auditing via GPO as instructed and tested to make sure auditing is working on all of our DC’s both on “child” and “old”. We have created the [old]$$$ domain local group with no members in the users OU on “old”

    Our “admt user” account is a domain admin on “child” and a member of the built in administrators on “old”

    As you can see everything is setup 100% according to all the documentation I can find online, and like I pointed out earlier worked fine with our Parent domain.

    Our problem now is that any migration attempts that include the SID history error out with the following “Could not verify auditing and TcpipClinetSupport on domains.  Will not be able to migrate Sid’s.  Access is denied. “

    What exactly are we missing that’s could be causing this issue?


    Friday, May 02, 2014 10:39 PM


All replies

  • Hi,

    You can check if you have performed the below steps:

    1.Both sucess/failure auditing must be enabled:
     --> Policy -> Computer configuration -> windows settings -> security policy -> local policy -> auditing policy -> Audit Accountmanagement (failure and success):

    2. On the destination and the source DC the following group policy should be configured simmilar:
     --> Policy -> Computer configuration -> windows settings -> security policy -> local policy -> security options -> Network Security: LAN Manager  Authentication.

    3. Both Domain Admins should be member of the BuiltIn Group Administrators in the other domain.

    4. Set the registry key hkey_local_machine\system\currnetcontrolset\control\lsa\tcpipclientsupport to 1 on the source dc.source domain controller has been restarted after the registry change

    5. On the source DC create a local security group in the domain 
    --> Name: NetBiosNameoftheDomain$$$$ for example: Contoso$$$

    6. Run gpupdate /force on both domains

    7. Test the trust in AD Domains and Trusts

    You can also refer the similar discussion from below link


    Saturday, May 03, 2014 12:32 PM
  • We have already verified all of that.

    Auditing is enable on both domains and we have verified that we can see auditing events being created if we make changes, indicating that it is functioning correctly.

    We do have the tcpip registry value created

    We have the domain local user on the source domain [netbiosdomain]$$$

    Our user is a domain admin on the new target domain, and a member of the built in administrators group in the source domain.

    Trusts are in place and have been validated, now the target domain is a child domain so the trusts still go through the parent domain as well.

    we have gp-updated both networks but we still get this error migrating SID history.

    Hence why i opened this post to see why with every preq setup it still is not working. is there anything else that can cause this, 

    Monday, May 05, 2014 3:27 PM
  • Have you installed "Password Export Service" in the Source domain? If not, try following the steps mentioned in the below scenario.

    Source domain:

    Target domain:

    PES server helps to migrate password from the source domain to the target domain. It integrates into ADMT tool to perfom this operation. ADMT Key has to be generated at the target domain, and it has to be imported into the source forest PES Server.

    1. Installing and configuring PES (Password Export Server) on source forest DC;

    A. Generating ADMT Key at target domain
    This is to generate the ADMT encryption key, login to the ADMT server then start the command prompt by runas administrator and execute the below command. It prompts for the password, key in the password and again confirm the same.  This generates the encryption key file at the path “C:\Pes.pes” 
    admt key /option:create /sourcedomain:green /keyfile:PES /keypassword:*

    B. Installing and Configuring PES server at source forest 

    i. Login to the domain controller
    ii. Copy the file C:\pes.pes from the to root directory(C:\) of the server
    iii. Download the Password Export Server (PES) 3.1 into the server
    iv. Perform the default installation of the PES Server
    v. During the installation wizard , on Encryption file page, provide the encryption file path “c:\PES.pes” and click on “Next”
    vi. Input the password, which was used to generate the encryption key and click on “Next” to continue the installation. 
    vii. Install wizard will prompt to specify the service account to run the Password Export Server service. Input the service account “Blue\admtadmin” and the password, then click on “OK” to continue the installation. 
    viii. Reboot the server once the PES is installed successfully
    ix. On reboot of the server , login and start the windows services console. 
    x. Then start the service “Password Export Server Services”

    2. Configure Registry to allow Password export on source server

    Apart from configuring PES server, some registry settings need to be configured to allow the password to be copied from source to the target account.  

    i. Login on and start registry editor (regedit)
    ii. Navigate to  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 
    iii. Edit Dword “AllowPassworExport” and change the value from 0 to 1

    3. Disabling SID filtering on target domain

    It is the best practice to preserve the user’s access on the source forest once the AD account is migrated to the target forest. This is done by copying the SID from source account to the target account as SID History and it is performed using ADMT migration. SID history can be used for a roaming user profile access, certification authority access, software installation access, resource access etc. SID Filtering is enabled by default, while configuring two-way Trust between the forests and it needs to be disabled using the below steps:

    i. Login to blue domain and start the command prompt with runas administrator
    ii. Execute the below command to disable SID Filtering on
    Netdom trust  /domain:blue /quarantine:No /usero:administrator /passwordo:Password1


    Tuesday, May 06, 2014 7:05 AM
  • I can certainly try setting up the PES and see if it helps. 1 question I have thought about, does it matter if we have a trust setup directly from the target domain or the source domain, or is it fine if it's a transitional trust going from target domain to parent domain to source domain?
    Tuesday, May 06, 2014 3:26 PM
  • Hi,

    To migrate users and global groups, you must establish a one-way trust between the source domain and the target domain, so that the source domain trusts the target domain.


    Vivian Wang

    Friday, May 09, 2014 2:50 AM