Active Directory Migration – How to remove sidHistory after migration – Part 2

As mentioned in my previous blog post regarding SID history, SID history can be both, burden and blessing. The recommendation from Microsoft is to clean up sidHistory from your accounts when migration is finished and all your Windows network resources have been re-ACLed (permissions of source domain accounts SIDs have been replaced by permissions of target domain SIDs).

Although it is not possible to remove sidHistory values like many other attribute values in Active Directory by using ADSIEDIT, LDAP or ADUC, there are still several ways to achieve this goal.

Caution: There is a big difference in how the tools handle the cleanup. Since sidHistory is a multi-value attribute and contain several SIDs from prior migrations, you might want to delete only SIDs related to specific domains.

Some of the tools erase the complete sidHistory value, some provide the option to delete selectively if there are multiple SIDs in the sidHistory.

1.Option: Use VB Script from Microsoft Support


For a very long time, a VB script is available from Microsoft support, which can be used to remove sidHistory. The raw version of this script is not very comfortable. You might need to adjust the coding.

The script can be downloaded here:

Usage for ClearSidHistory.vbs is as follows:

cscript.exe ClearSidHistory.vbs -n=<name> [-o=<objectCategory>] [-c=<objectClass>]

-n=<name of the object you are looking for>

-o=<objectCategory of the object you are looking for>

-c=<objectClass of the object you are looking for>


cscript.exe ClearSidHistory.vbs -n=My Contact

cscript.exe ClearSidHistory.vbs -n=Computer1 -o=computer

cscript.exe ClearSidHistory.vbs -n=James Smith -o=Person -c=user


IT-Pro Arne Scherhag provides an extended version of this VB Script here:

2.Option: Use Microsoft Active Directory Module for Powershell


If you are used to the Active Directory Powershell commandlets, you can also delete sidHistory values programmatically.


Delete sidHistory values in all user objects of the domain:

Get-ADUser –filter ‘sidhistory –like “*”’ –searchbase “dc=name,dc=name” –searchscope subtree –properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

3.Option: Use Quest Active Roles Management Shell for Active Directory commandlets


If your scripting is based on Quest Active Directory Powershell extensions, you also can use the get-qaduser and get-qadgroup commands to erase the sidHistory values.


Get-QADUser “john wayne” | %{Set-QADUser $_ -ObjectAttributes @{sIDHistory=@{delete=$_[‘sIDHistory’]}}}

In Part 3 of this blog post, we will have a look at the tools which can selectively delete sidHistory.

Active Directory Migration – How to remove sidHistory after migration – Part 1

About sidHistory

In almost all Active Directory Inter-Forest migration scenarios the sidHistory functionality of Windows Server plays an important role to maintain resource access from migrated users to their not yet migrated Windows resources (e.g. file shares, Exchange mailbox etc.).

The sidHistory attribute of a migrated user in the target domain contains the SID of the original user from the source domain. When the user logs on with his/her account to the target Active Directory domain, the security token generated by the DC, contains both, the SID of the actively logged on target user account and the SID of the source user account of the source domain. If the user now accesses resources in the source domain, the target account and the source account SID are presented for ticket granting process. This ensures that the user can use his/her resources seamlessly, no matter if the resources are located in the source Forest or are migrated to target Forest already. An alternative to using sidHistory is the re-ACLing of the resources in the source Forest, which can be a large, long running task.

NOTE: SidHistory does not work in the following cases:

  • SID Filtering is enabled on the Forest Trust or Domain external Trust Relationship
  • For all permissions that are set by using well known SIDs (like Domain Users, Account Operators etc.). Those well-known SIDs are filtered out by default when accessing resources over the trust.

Disadvantages of sidHistory

Although sidHistory is a very big help in Inter-Forest Active Directory migration, it challenges all security considerations at the same time. A rogue administrator can add the SID of a given user account to his account’s sidHistory and thus gets access to the user’s resources. Another disadvantage is the blow up of the security token of a user account, since when using sidHistory, the token contains the SID of the account and the SIDs of all groups where the account is member of + the source account’s SID  and all SIDs of all the groups from source domain – assuming the groups have been migrated. There is a system limitation on token size which allows a maximum of 1015 groups. Using sidHistory for groups every group membership in a migrated group counts twice. If the source user is member of 550 groups in source domain and all groups have been migrated to target domain with sidHistory, the target account will most likely not be able to log on, because the security token is bloated. As long as the groups contain their sidHistory from before the migration, the group membership of users must be monitored constantly.

For Active Directory limits check here:


RECOMMENDATION: Taking into account the security and system related disadvantages of sidHistory, we recommend removing the sidHistory value after migration of accounts and resources.

In Part 2 of this thread we will show some ways to remove sidHistory values which is not possible via ADUC and ADSIEDIT and other LDAP based tools.

Quest Migration Manager(R) – Best practices for supportability, patching and upgrading – Part 1

Product Support Policy and Product Lifecycle Tables

Over the time of a long running Active Directory or Exchange migration project, Dell/Quest Software will usually publish various hotfixes to keep the most current versions of Quest Migration Manager up to date.  The purpose of the hotfixes can be:

  • supporting a new version, release, service pack of Windows server OS, Windows client OS, Exchange or Outlook
  • fixing program code in the components of Migration Manager for Active Directory or Migration Manager for Exchange

By default, the 2 most recent releases of Migration Manager are part of the ongoing patch management process. [Statement from Quest Support Website: “Quest Software’s usual support policy is to provide support on both the current (n) and prior (n-1) versions of our products.” 2013-01-02].

For each Quest Software product, you can find a product lifecycle table, which provides information whether the release of your product is in “Full Support”, “Limited Support” or “Discontinued” mode.

For Migration Manager for Exchange check here:

For Migration Manager for Active Directory check here:

RECOMMENDATION: If you expect Dell/Quest support to provide custom code changes, enhancement requests and “on time” Hotfixes, make sure that your installed product release is covered by “Full Support” mode. For a long running migration Project, check in advance by using the product LifeCycle table and plan a maintenance window for upgrade activities.


How to get up to date information regarding new updates and hotfixes

Our most favorite way of getting a quick overview which hotfixes and upgrades are available is to check the hotfix summary page for Quest Migration Manager which is published here:

This excellent summary provides both, most recent and historical information, which makes it easy to assess the patch level situation of the own Migration Manager infrastructure.

Another fancy way to get the latest information regarding hotfixes, product releases and KB articles is to read the RSS feed provided by Dell/Quest support. You can directly import the links below into your RSS reader:

For Migration Manager for Exchange use this xml file:

For Migration Manager for Active Directory use this xml file:

REMARK: Although you can see all the hotfix information on the public facing part of the Quest support site, you only will be able to access the software when you are having a running support contract.

No matter which method you will use to get the updated code, you still have to make the decision for yourself whether you are going to implement a specific upgrade or hotfix or not. We will provide some consideration regarding this question in Part 2 of this thread.