Attributes Supported
The following objects are part of the migration process, please review them carefully.
The user objects contain the most data. However, some fields are writable. All of the schema objects relevant to this project are listed here:
| Schema Object | Description | Sample Data | Editable |
| accountExpires | Account Expires | System.ComObject | Yes |
| badPasswordTime | Last Bad Password | System.ComObject | |
| badPwdCound | Bad Password Count | 0 | |
| c | Country | US | Yes |
| cn | Canonical Name | Bob Jones | Yes |
| co | Country | United States | Yes |
| codePage | Code Page | 0 | |
| company | Company | Widgets, Inc. | Yes |
| countryCode | Country Code | 1 | Yes |
| department | Department | IT | Yes |
| description | Description | Yes | |
| displayName | Display Name | Bob Jones | Yes |
| distinguishedName | Distinguished Name |
CN=Bob Jones, CN=Users, DC=widgetsinc, DC=com |
|
| division | Division | Engineers | Yes |
| dSCorePropagationData | DS Core Prop Data | 8/15/2021 8:15:00PM | |
| givenName | First Name | Bob | Yes |
| homePhone | Home Phone | 801-123-4567 | Yes |
| instanceType | Instance Type | 4 | |
| l | Location | Alaska | Yes |
| lastLogoff | Last Log off Time | System.ComObject | |
| lastLogon | Last Log on Time | System.ComObject | |
| lockoutTime | Lock Out Time | System.ComObject | |
| logonCount | Logon Count | 10 | |
| bob@widgetsinc.com | Yes | ||
| managedObjects | Managed Objects | CN=Test1, OU=Groups, DC=widgetsinc, DC=com | |
| manager | Manager | CN=TheBoss, OU=Users, DC=widgetsinc, DC=com | Yes |
| memberOf | Group Membership | CN=Test1, OU=Groups, DC=widgetsinc, DC=com | Yes |
| msTSProperty01 | Terminal Services Property | 123 | Yes |
| msTSWorkDirectory | Terminal Services Dir | \\server\share | Yes |
| name | Name | Bob Jones | Yes |
| ntSecurityDescriptor | NT Security Descriptor | System.ComObject | |
| objectCategory | Object Category | CN=Person, CN=Schema, CN=Configuration, DC=widgetsinc, DC=com | |
| objectClass | Object Class | user / top / person | |
| objectGUID | Object GUID | System.Byte | |
| objectSid | Object SID | System.Byte | |
| physicalDeliveryOfficeName | Address | Alaska, AK | Yes |
| postalCode | Postal Code / ZIP | 12345 | Yes |
| primaryGroupID | Primary Group ID | 513 | Yes |
| pwdLastSet | Password Last Set | System.ComObject | |
| sAMAccountName | SAM Account Name | bjones | Yes |
| sAMAccountType | SAM Account Type | 805306368 | |
| sn | Lastname | Jones | Yes |
| st | State | UT | Yes |
| street | Street | Short St | Yes |
| streetAddress | Address | 1 Short St | Yes |
| telephoneNumber | Phone | 123-456-7890 | Yes |
| title | Job Title | Engineer | Yes |
| unixUserPassword | Unix User Password | System.Byte | Yes |
| url | URL | widgetsinc.com | Yes |
| useAccountControl | Use Account Control | 66048 | |
| userPassword | Password | System.Byte | Yes |
| userPrincipalName | UPN | bob.jones@widgetsinc.com |
Yes (read-only and cannot be edited when accessed through LDAP) |
| userWorkstations | User Workstations | ABC123 | Yes |
| uSNChanged | uSN Changed | System.ComObject | |
| uSNCreated | uSN Created Date | System.ComObject | |
| whenChanged | Date Changed | 8/15/2023 8:15:00PM | |
| whenCreated | Date Created | 8/9/2023 8:15:00PM | |
| wwwHomePage | WWWHomePage | www.widgetsinc.com | Yes |
The Group Objects’ layout and fundamentals are similar to User Object but contain much less data. You can identify them by the same type of CN, DN, and ObjectGUIDs.
Keep in mind, when creating groups, the principal editable data is the only requirement since the rest of the information will self-populate in the Active Directory.
Important
The most important function is Membership, the Member field keeps it in a single System.Byte[] array.
Find the schema items related to the project in the table below:
| Schema Object | Description | Sample Data | Editable |
| cn | Canonical Name | Testing Group | Yes |
| description | Descriptions | This is the Group Description | Yes |
| distinguishedName | Distinguished Name |
CN=Test1, OU=Groups, DC=widgetsinc, DC=com |
|
| dSCorePropagationData | DS Core Prop Data | 8/15/2021 8:15:00PM | |
| groupType | Group Type | -2147483646 | |
| info | Info | This is the information field | Yes |
| instanceType | Instance Type | 4 | |
| testgroup@widgetsinc.com | |||
| managedBy | Managed By | CN=BobJones, CN=User, DC=widgetsinc, DC=com | Yes |
| member | Member | List of Member in CN Format | Yes |
| name | Name | Testing Group | Yes |
| nTSecurityDescriptor | NTSecurityDescripiton | System.ComObject | |
| objectCategory | Object Category | CN=Group, CN=Schema, CN=Configuration, DC=widgetsinc, DC=com | |
| objectGUID | Object GUID | System.Byte | |
| objectSid | Object SID | System.Byte | |
| sAMAccountName | SAM Account Name | mrochester | Yes |
| sAMAccountType | SAM Account Type | 805306368 | |
| uSNChanged | uSN Changed | System.ComObject | |
| uSNCreated | uSN Created Date | System.ComObject | |
| whenChanged | Date Changed | 8/15/2023 8:15:00PM | |
| whenCreated | Date Created | 8/9/2023 8:15:00PM |
You can create the OU through the AD Agent by providing the Name field and the Distinguished Name. The rest of the data will self-populate from the Active Directory.
Find the schema items related to the project in the table below:
| Schema Object | Description | Sample Data | Editable |
| distinguishedName | Distinguished Name |
OU=Employees, OU=Groups, DC=widgetsinc, DC=com |
|
| dSCorePropagationData | DS Core Prop Data | 8/15/2021 8:15:00PM | |
| instanceType | Instance Type | 4 | |
| name | Name | Testing Group | Yes |
| nTSecurityDescriptor | NTSecurityDescripiton | System.ComObject | |
| ou | Top Level OU | Users | |
| objectCategory | Object Category | CN=Organizational-Unit, CN=Schema, CN=Configuration, DC=widgetsinc, DC=com | |
| objectGUID | Object GUID | System.Byte | |
| uSNChanged | uSN Changed | System.ComObject | |
| uSNCreated | uSN Created Date | System.ComObject | |
| whenChanged | Date Changed | 8/15/2023 8:15:00PM | |
| whenCreated | Date Created | 8/9/2023 8:15:00PM |
Considerations
Please consider the following information about some of the attributes mentioned above.
- You can migrate the ObjectGUID attribute through AD migrations.
- The ObjectGUID is unique to the Active Directory (AD) where it was created.
- When an object is created in the Target AD, it receives a new ObjectGUID.
- The ObjectGUID often populates from the Source AD the SIDHistory field in the Target AD. Currently, sIDHistory is not populated in the Target AD environment. This will be fixed in subsequent releases and updates to the product.
- SID History may can only be migrated if a working trust has been set up between the source AD and the destination AD. Details for migrating SID History can be found in the On-Premise to On-Premise Active Directory Migration Guide.
- MigrationsWiz does not migrate MsDs and Immutable ID attributes. They are created and placed where the Target AD object is synced to the appropriate tenant through Cloud Connect or Cloud Connect Sync.
- MsDs and Immutable ID values are new values based on the newly created object. Consider they must be created in new environments.
AD Settings
AD Agent
The local AD Agent connects the DC and performs the AD migration.
Currently, the agent itself is required to be installed on a Domain Controller in both the source and destination environments.
Ports
AD Agent performs all of the transactions over port 443, and these transactions are ‘outbound initiated’.
It is important to note that the MigrationWiz backend never contacts the agent at any point, it is always based on the AD Agent ‘asking’ the backend for the work it needs to perform.
Policies
Currently, MigrationWiz does not fully support Group Policies migrations, it only migrates objects themselves.
Security
Keep in mind that MigrationWiz stores data in the MW database, replicating the storage mechanism of other MW products. You can use your own Azure SQL storage.
MigrationWiz AD Migrations allows performing IP Lockdown feature, as any other MW migration.
Important
IP LockDown does not work with BitTitan Autodiscover using MigrationWiz. To add Users to the project, use Bulk Add via a CSV file or add them manually.For more information on BitTitan's security, refer to BitTitan's Security and Compliance article.
Domain
When selecting the domain for the Target AD Agent, choose the Distinguished Name of the top-level AD you are writing to. The format should be like this
DC=planeium, DC=com
It can be read from the target AD by looking at the Attribute Editor in the AD properties section as the image below.
AD Migrations FAQs
How does licensing work?
- Licensing is per user.
- If you migrated with MigrationWiz and have an associated computer to migrate, the computer migration is included with the user’s migration license.
- To migrate an end-user computer, the user must first be migrated with MigrationWiz.
- Groups and Active Directory Printer objects do not require a migration license.
- Once a user has synchronized data, deleting the user from the project will remove the consumed migration license. Adding the user back to the project will require an additional migration license to sync the user again.
Does random password generation affect the destination policy?
No. A random password is assigned during the migration; however, MigrationWiz does not store or log this password. Administrators must manually reset the password for the destination user after migration to ensure they can access their account securely.
Are source passwords longer than 10 characters synced to the destination?
Yes, unless there is a policy that restricts password length in the destination. If you use the random password option, it should be set in the destination with a max length of 10 characters.
What happens if there is an issue with the destination user SID history after migration?
It is recommended to delete the destination user object from the destination Active Directory and migrate the user again with SID History enabled in the Advanced Options of the project.
Is Group SiD History Migrated?
No, only user SiD History is supported at this time.
Can I transform attributes besides UPN?
Yes, you can do it after you import the project using the Edit User feature. For more information, refer to Editing Line Items in the On-Premise to On-Premise Active Directory Migration Guide.
Is offline domain join supported?
No.
When enabling password sync, can I apply it to specific users, or must it be enabled for all users?
Password sync is a global project setting. While it is enabled, MigrationWiz will sync the user password from the source to the destination for all users with a syncing status in the project.
How do I stop the destination agent from importing changes to the destination user?
- Select the user in the project.
- Select stop in the toolbar. This will stop any changes uploaded for the source user object from being imported to the destination user object.
- To continue syncing the user, select the user in the project and start the sync.
Can I include or exclude specific attributes or properties in the project?
Attribute/property filtering is currently not supported.
AD Computer Move Migrations FAQs
How are servers handled?
The migration of server objects is not supported. Only end-user computers and Active Directory printer objects are supported for machines with MigrationWiz.
Can MigrationWiz migrate computers for users already in the destination that were not migrated using MigrationWiz?
No. To migrate an end-user computer, the corresponding user must first be migrated with MigrationWiz.
Note
Migrating computers for users created in a destination other than by MigrationWiz is not supported.Troubleshooting
Password Sync
Important
The table below details the needed packages to be installed for the Source and Target agent to function correctly. Although the agent will prompt for the Windows Desktop Runtime as part of the loading process if it is not installed, it is a preference to install these three before running the agent.
Once installed, the three schema object packages should show up in programs as follows:
| Schema Object | Description |
| Visual C++ Redistributable 2015-2022 | https://aka.ms/vs/17/release/vc_redist.x64.exe |
| Windows Desktop Runtime .Net - v6.0.28 | |
| Microsoft .Net 6.0 Runtime - v6.0.28 |
https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-6.0.28-windows-x64-installer |
Matching Failure – The account exists in Target AD already
In some cases, items cannot be created if they do not match the specified criteria and already exist.
If we take an example of this, we have a user, John Smith in the Migration Frog domain with the following details.
| UPN | james.ibarra@migrationfrog.com |
| Alias | james.ibarra |
| CN | migrationfrog.com/MIGFROG/Users/UK/James Ibarra |
| EmployeeID | 123456 |
In the Target AD environment, the details are set to:
| UPN | james.ibarra@planeium.com |
| Alias | james.ibarra |
| CN | planeium.com/MigrationFrog/Users/UK/James Ibarra |
| EmployeeID | 987654 |
The matching criteria are set to EmployeeID. Now when this object runs through the process it will pick up an error like this.
This means that the system could not match the EmployeeID, thinking that now the EmployeeID for James is unique. Therefore, it will attempt to create a new AD object for James in the target with the details it has, transposed to suit the target.
This will fail because there is already a James Ibarra using the UPN, the Alias, and the CN in the target.
Until this conflict is fixed, the object will not be written. It could be that they are the same person and the EmployeeID entry is incorrect, or they are two different people. Either way, the Target Agent will not make that determination and will throw out the exception error.
The best course of action would be to investigate the failures and choose appropriate solutions, as shown below.
First of all, you have to decide if they are the same person and then update the EmployeeID accordingly. In the following tabs, you can find some workarounds.
If EmployeeIDs are different and the change of the SAMAccountName in the source is possible, then the Source AD object requires an update of the SAM Account Name or Alias to allow it to be written inside the target AD.
When it is updated on the source AD, rerun the Source Agent scan. As a result, it will be updated in the source and written correctly.
If they are different and changing the SAMAccountName/Alias on the source environment is not possible then the other option is to manually pre-stage a single item in the Target AD environment.
To do so, place the details of the UPN, etc. with a number as the prefix, i.e. James Ibarra 2.
Remember to place the correct EmployeeID in the object so that it matches. When the account is written, it will match the EmployeeID but the SAMAccountName cannot be updated and will stay the same.
This way all the details will come over into the placeholder account. This can be achieved with any matching criteria, like a custom attribute or field.
In summary, if a placeholder exists with a valid CN, UPN, and SAMAccountName then it will match the other criteria and update the record but keep the identifier of SAMAccountName set to the new value.