The SID History (Bulk) option is used to add SID History to multiple objects which is used to support domain migrations. This function is based on the DsAddSidHistory API, this API has a list of requirements that must be in place before it can update the SID history attribute on the target objects. Details of these requirements can be found here. You need to successfully complete a validation of the details before the file import and run options are enabled.
Definitions
Source Domain: this is the domain that has the source objects
Target Domain: this is the domain where the SID from the source object, will be added to the SID History attribute of the target object.
NetTools needs to be run on the domain controller in the target domain. The validation details need to be entered and then click the Validate button.
This is the output of the validation test for a successful validation, if there are any issues, the details will be displayed. The validation test doesn't check for the audit requirements but will be reported as a error when you try to execute the change. Check the Microsoft article above for details of the audit requirements.
Validating Source Domain Information Uplevel Domain Source Domain: TARGET Source DC: dc03.target.net Source domain local group exists Source Domain Validation Complete Validating Target Domain Information Uplevel Domain Target Domain: NETTOOLS Target DC: dc01.nettools.net Target Domain Validation Complete Validating Target Domain SPN Bind Bound to target DC Validation complete
Once the validation is complete the Import file and execute buttons are enabled. The input file is a semi-comma separated list of source and target object names, the object names need to be based on the SamAccountName. Once the file has been imported the source and target objects pairs are displayed in the import pane. When the execute button is pressed, the result of the changes are displayed in the status column.
Side Note: I have completed numerous domain migrations, with and without SID history and while SID history does make the initial phase of the migration simpler, it does mean you move the remediation of permissions and the removal of SID History to the end of the migration\project. Usually this means that there limited time or appetite to complete this work, and as a result SID History never gets removed. This does have the side effect of increasing the size of the user's access token and while the introduction of Windows 2012, with larger access token buffers, which can reduced this impact, it can still cause intermittent authentication issues, especially with IIS. My advise is not to use SID History and complete the remediation of the permissions before migrating the users as this will ensure that you can identify and resolve issues earlier in the project timeline, which then removes the possibility of SID History issues waiting to bite you later.