Active Directory Server 2016 user migrated with ADMT - SID History issues


  • Hello,

    actually I migrate a child domain to a new root domain.

    All Servers and Services are migrated, Exchange etc. works fine.

    The User were migrated with ADMT and SID History.

    Today I migrated some test computers with ADMT.

    If the User logs in again, after a few minutes the Explorer.exe, the Snipping Tool and the Networkinterfaces wont work.Error: Explorer : To the path or file can not access. You have no permission

    Snipping: The Snipping Tool dont work at the moment. Try to restart

    Shared Folder access is not possible.

    I can readjust this issues if I made an gpresult /r - then the errors begin.

    Same Computer (Win7 64 bit SP1):

    With a completly new Domain User from the new Domain - everything works

    With a migrated User from the old to the new Domain without SID History - everthing works

    With a migrated User with SID History - problems..

    - I try it too with delete the User from all User Group memberships and all GPOs disabled.

    - rejoin the computer from the domain does not change anything

    Has anyone a idea?


    • Edited by alpina27 Monday, March 6, 2017 8:02 PM
    • Moved by nzpcmad1 Tuesday, March 7, 2017 5:46 PM From ADFS
    Monday, March 6, 2017 7:59 PM

All replies

  • Update:

    I tested this in my Demo Lab, with target domain on Server 2016, source domain 2008R2, and win7 and have the same errors.

    only difference : gpresult /r tells: access denied.

    Monday, March 6, 2017 8:56 PM
  • Update 2: I delete the sid history from the User in the Productivity Domain and then everything works without Problems. gpresult has no erros... @Microsoft MVP is this maybe an bug? Regards
    Tuesday, March 7, 2017 12:14 PM
  • Hi,
    SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you migrate users into the target domain you will have the option to migrate the users SID to the target domain. This becomes the sIDHistory attribute under the new user object.
    Resources within the source and target domains resolve their access control lists (ACLs) to SIDs and then check for matches between their ACLs and the access token when granting or denying access. If the SID or the SID history matches, access to the resource is granted or denied, according to the access specified in the ACL.
    However, based on my research, it seems that there is no such information regarding the similar problem about gpresult and SID history, I would suggest you open up a case with Microsoft Technical Support to see if they could get more information from product team and check if it is a bug:
    As far as I know, if Microsoft Technical Support confirm the issue as a bug, the money would be returned back.
    Thank you for the understanding.
    Best regards,

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Wednesday, March 8, 2017 7:33 AM
  • Hello Wendy,

    I tested this now in my demo lab with Windows Server 2012R2 AD DS and the same doing like my customer or my Server 2016 Demo Lab.

    -> There is no problem with SID History, if I migrate the PC and logon with an migrated User.


    Saturday, March 11, 2017 10:32 PM
  • Hi,

    Appreciate for your test and update, maybe, as I suggested, we could contact Microsoft Technical Support to see if it is a known problem.

    Best regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, March 14, 2017 1:52 AM
  • We have the exact same problem at two of our customers.

    Removing the SID History for pilot users will solve the problem. Also shutting down the Server 2016 domain controllers (DC) in a mixed domain environment will solve the problem.

    Both of our customers are using a Matrix42 software deployment / management tool. Do you also use a Matrix42 software?

    Best regards

    Wednesday, March 29, 2017 4:17 PM
  • Hi Alpina27. Any progress with this issue?
    Thursday, March 30, 2017 4:10 PM
  • Hi all.

    We also have exactly the same problem at two customer environments.

    Just on W7 Clients, on W10 not.
    +Matrix42 Software deployment.
    Problem since one DC 2016 was joined.

    I noticed an extended eventlog Folder "Matrix42" (or similar) on the Client (W7), which logs "SID resolve Errors" with red-crit events. Using psgetsid I can resolve an "Userobject" in the cmd, so the userobject with SID history seems to be available and working (on the Client). But we've got 3-7 minutes W7 "Explorer.exe errors"

    Pretty sure it depends on "who is my logonserver today".

    But we need an solution for that compatibility problem.

    Removing SID-H on the userobject works (=timeouts on re-logon are no more), but the customers are actually using SID-H in production.


    Monday, April 3, 2017 6:46 AM
  • Hello,

    no my customer dont use Matrix42.

    I dont open an ticket at Mircosoft Premier Support, cause my customer dont really need the SID history, so we could delete them from all migrated user and then everythin works fine.

    So I dont know what the problem realy is.. Bug?


    Wednesday, April 12, 2017 9:32 PM
  • Hi,

    We have found a workaround for this issue.
    The environment: Windows 2016 Domain controllers with Windows 2008R2 member servers or Windows 7 clients. 

    The issue came along with RES Workspace Manager. When a user is migrated from Windows 2012R2 source domain to the new W2016 domain with SID history the same issues arise as described in the first post only it started instantly after logon.

    We found out that this has something to do with the LookupAccountSidW function that is called from advapi32.dll. On W7 / 2008R2 this functions adds the user SID history sid to the returned tokenGroups. It looks like this causes a corruption for the LSA sid cache. It looks like it only affects W2008/W7, when we tested on w2016 member server we had no problems.

    To work around this issue see the setting in the following link:
    Disable LsaLookupCache

    Regards, Marco

    • Edited by Marco_01 Thursday, June 15, 2017 6:09 PM
    Thursday, June 15, 2017 6:15 AM
  • We also had this issue, and while the workaround is good, if the user is offline (not on the corporate LAN), then they experience the same issue when offline if the cache lookup is disabled.

    However, the issue has now been resolved by Microsoft in KB4022715; "Addressed an issue where users on Windows 7 SP1 clients connecting to a Windows Server 2016 based domain controller cannot run applications such as Internet Explorer for a period of approximately 10 minutes after logging on. This issue occurs after upgrading the enterprise domain controllers to Windows Server 2016."

    We installed the update on our 2016 DCs and it fixes the problem.

    Wednesday, July 5, 2017 11:02 AM
  • sIDHistory migration requires the following additional dependencies

    • Success and failure auditing of account management for both source and target domains.
    • Windows NT 4.0 source domains call this user and group management auditing.
    • An empty local group in the source domain that is named {SourceNetBIOSDom}$$$.
    • The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupportregistry key must be set to 1 on the source domain primary domain controller.
    • You must restart the source domain primary domain controller after the registry configuration.

    You can refer to the link given below

    Tuesday, July 11, 2017 6:51 AM