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 |
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.
- MigrationWiz is frequently used in scenarios where there are no trusts or physical links to the Source AD, making it independent of trusts. As a result, the SIDHistory field in the Target AD might not be populated in most cases, making its value less important.
- 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 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.
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.
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.