1. BitTitan Help Center
  2. Perform a Migration
  3. Migration Planning

Azure for MigrationWiz

Several migration types require that you have an Azure account. These include Google Vault, PST, file server file share, and file server home directory migrations. In these migrations, data moves to Microsoft Azure Blob storage, then MigrationWiz transfers the data to the destination.

The following guide covers some of the commonly asked questions about using Azure with MigrationWiz. It also provides links to external Microsoft documentation to assist in the setup and management of Azure. 

The following questions are not a comprehensive guide to using Azure for MigrationWiz. The migration guide for your scenario will tell you whether or not you need to use Azure, and will provide specific steps and details for your migration. 

Resources

Microsoft Azure website (to purchase a subscription): Microsoft Azure website

Estimating storage costs: Microsoft Azure Pricing Calculator 

Retention Policies

BitTitan storage is meant to be used for small migration projects only; it is a free service that is provided as a convenience when you do not have your own Azure storage account. There is a limit of 100GB per customer account.
 
The following retention policies are in place:
  • Your files will be purged from BitTitan storage after 30 days.
  • Your oldest file(s) may also be purged when you are attempting to upload a new file and have reached the 100GB limit.

Choosing Azure storage

You can use either your own storage, or the BitTitan Azure storage. 

Important: IP lock down will not work for your custom Azure Storage unless Microsoft server IPs are included as well. For more details on Microsoft endpoints, refer to URL & IP address ranges.

Your own Azure storage:

  • If you use your own Azure storage, there will be no storage limitations.
  • You can read the data in your Azure storage containers.
  • You can upload the PST files into your Azure storage using your favorite upload tool (or even drive ship to Microsoft).

BitTitan storage:

  • With BitTitan Storage, you do not need to have your own Azure storage. Instead, you can upload your PSTs to our cloud storage account, but there are some limitations.
  • For security, you will have to use our specialized tool, UploaderWiz, to upload your PSTs to our storage.  This will securely upload your PSTs to an isolated container that no one else has access to.  Once you upload the PST, you will not be able to read it.  Only MigrationWiz will be able to read it in order to migrate the data into your MigrationWiz project dashboard.
  • Bittitan storage has a maximum of 100GB set per customer. If the total of your PST files is larger than this, we recommend purchasing your own Microsoft Azure storage instead, and using that for your migration project.

BitTitan Azure storage

BitTitan has its own Azure storage, which can be used by Partners for temporary storage on Azure during those migrations which require Azure storage.

Certain migration scenarios follow a two-step process whereby files are uploaded to an Azure container or containers first, before being discovered and used by MigrationWiz during the migration. Examples of migration scenarios that require Azure storage include Google Vault, File Server and PST migrations. (OneDrive, SharePoint and Teams migrations are not supported)

If a Partner or their customer already has an Azure subscription, they should use this during the upload process. However, if a Partner, or their customer, do not have an Azure subscription, they can use the BitTitan Azure storage to store their files on a temporary basis.

More details about BitTitan storage are listed below:

  • BitTitan storage has a limitation of 100GB per customer. If you require more than 100GB, you will need to purchase your own Azure subscription. Please read the Purchase Microsoft Azure Subscription article for more details.
  • For security, you will have to use the BitTitan specialized tool, UploaderWiz, to upload your PSTs to BitTitan Azure Storage.  This will securely upload your files to an isolated container that no one else has access to.  Once you upload the files, you will not be able to read them from the Azure container.  Only MigrationWiz will be able to read the files in order to retrieve the data from the Azure container into your MigrationWiz project dashboard.
BitTitan storage is meant to be used for small migration projects only; it is a free service that is provided as a convenience when you do not have your own Azure storage account. There is a limit of 100GB per customer account.
The following retention policies are in place:
  • Your files will be purged from BitTitan storage after 30 days.
  • Your oldest file(s) may also be purged when you are attempting to upload a new file and have reached the 100GB limit.

Storage Account vs. Bucket

A Storage Account is what owns the containers where your data resides or will reside. The name of the Storage Account can be found by logging in to your Azure portal and navigating to Storage Accounts. The Storage Account name is entered when first setting up your Endpoint in MigrationWiz. 

A Bucket Name is the name of the logical container found within the Storage Account. The Bucket Name can be found by clicking Containers under the heading BLOB SERVICE when viewing the details of your Storage Account. You must enter this in the project's Advanced Options, either under Source or Destination, depending on the migration scenario.

Create an Azure storage account

Using the new Azure Portal (unless specified, leave settings as default):

  1. Visit ​https://portal.az​ure.com​ 
  2. Click Storage accounts​
  3. Click Storage Create​
  4. Select the subscription in which you want to create the new storage account.
  5. Select your Resource group.​ Create new if one doesn't exist.
  6. Enter a name for your storage account.​
  7. Choose your datacenter Location.
  8. Choose Blob storage for the Account kind with Standard performance
    1. ​​If you are using the OneDrive for Business, SharePoint, or SharePoint Online endpoint for a document migration, do NOT select Blob Storage. Select STORAGEV2 (general purpose v2) with Standard performance.
  9. In the Replication field, select Locally Redundant Storage (LRS).
  10. Click Review + create.
  11. Click Create
  12. Then go to Resource
  13. Select Access keys under Settings
  14. Copy the Storage account name and the key 1.
  15. The Storage account name and one key 1 will be added to the destination endpoint of the MigrationWiz project.

When creating the container within MigrationWiz:

  • We recommend creating a container named "migrationwiz" and uploading the PST files into this container. If you name the container something else, it will be necessary to enter the Advanced Options for the MigrationWiz archive project and set the bucket name to be exactly the same as the Azure storage container name. If the container name is created as "migrationwiz", then this step is not required, since the default expected bucket name for migration is preset to be "migrationwiz".
  • If the container is created with a name other than "migrationwiz", and the MigrationWiz Advanced Option bucket name is not changed, the migration will fail.

Estimating Azure Costs

Using Azure for your migration will incur a fee from Microsoft only for the Azure storage. Data transfer fees are only incurred with cross-region, and total egress, from Azure traffic. As explained below, there should be no outbound data transfer fees for this migration, because your Azure storage needs to be in the same region as the Destination tenant, for the migration.

If Office 365 is the destination, then MigrationWiz includes logic which checks for the region of the Destination tenant, and will then utilize migration workers only from that same region.

Important:

  • If your Azure storage is in the same region as the tenant, then there will be no outbound storage fees, regardless of the number of transfers per project.

When does MigrationWiz transfer data more than once?

Under certain conditions, MigrationWiz will transfer data more than one time. These are some of the scenarios in which MigrationWiz will transfer data from your blob storage more than one time:

  • Restarting a migration after the maximum error count is reached
  • Restarting a migration after the maximum license consumption is reached
  • Both of the above limits are set in the project's Advanced Options screen.
  • Restarting a migration after a failed pass
  • Restarting a migration after pausing it

In each of these scenarios, when you restart the migration, MigrationWiz starts from the beginning. 

Storage Keys

Get a key

A storage access key is used to to authenticate an Azure Blob storage account in a migration project.

Follow the steps below to view the storage access keys for an Azure Blob storage account:

  1. Sign in to the  Azure dashboard .
  2. In the navigation pane, click All Resources.
  3. Choose the desired storage account.
  4. Click the  key   icon  to view the access keys for the storage account.
  5. Each storage account has two storage access keys. Copy both. 
  6. To copy a storage access key, click the copy icon next to the key you want to copy.

Delete a storage key after migration

Regenerate the Azure Blob storage access key once the migration project is complete if you don’t plan on reusing the access key. This ensures the storage access key cannot be used to access the Azure Blob storage account when the migration project is complete.

Follow the steps below to regenerate the storage access key for an Azure Blob storage account:

  1. Sign in to the Azure dashboard.
  2. In the navigation pane, choose  All Resources .
  3. Choose the desired storage account.
  4. Click on the  Key  icon to view the access keys for the storage account. Each storage account has two storage access keys.
  5. Click on  Regenerate  for the desired storage access key.

Regenerating your access keys affects virtual machines, media services, and any applications that are dependent on the storage account. All clients that use the access key to access the storage account must be updated to use the new key.​

Adding Files

Uploading files

There are several options available. If metadata information or permissions are needed from an On-Premises environment, like FileServer, use the BitTitan UploaderWiz tool.

Use BitTitan's UploaderWiz tool to upload data to your own Azure storage account in a public blob container. This blob must be a block blob.

When uploading PST files, you could also use UploaderWiz to place them into the BitTitan Azure storage account, but this is limited to 100GB. Use a utility such as Azure Storage Explorer. Or use a preferred third-party uploader utility. Upload the files into the public blob container that was previously created.

Use the Microsoft Azure Import/Export Service to transfer data to the public blob storage.

Create and use your own PowerShell scripts to upload files.

Use a utility such as AZcopy. More information on how to use this with Azure can be found here.

Importing files

Once you have files in either BitTitan storage or your own Azure storage account, you can add them to your MigrationWiz project by following these steps:

From your project dashboard:

Choose Quick Add to manually add the names of the files that have been uploaded into Azure into your project. If using Quick Add, define the full path to your files (filename included), for example: Filename.pst or Foldername/filename.pst.

  • Do not include the URL from BitTitan storage.
  • File names in Azure are case-sensitive.

Or

Click on the AutoDiscover Items green bar to AutoDiscover, and import the names of the files from BitTitan storage.  AutoDiscover is the recommended and easiest option to choose.

  • Click on the blue Start Auto Discovery bar in the left-hand panel.
  • Once the PST files have been discovered, click on the green + Import Items button.

Now choose the Destination to ingest each file into. For example, for PST migrations you will edit the Destination mailbox. To do this, follow the directions here. For OneDrive migrations, you will choose the Office 365 account to ingest into.

Synchronizing Azure Active Directory Objects

Use this article from Microsoft for the most up-to-date information: Set up Directory Synchronization

If the local Active Directory (AD) schema has not been extended to support Exchange, then the steps above to set msExchGuid attribute to null are not needed. Synchronization can be run in the normal manner.

If you have previously used DirSync from an environment where the local AD supports Exchange, you cannot set the msExchangeMailboxGUID to null, because this is not supported by DirSync. Therefore, we recommend that you instead use AAD Sync or AAD Connect to rectify this problem, by following the steps outlined above.

If you do not set the msExchMailboxGuid to null, before running a synchronization from an environment where the local AD supports Exchange, all of the On-Premises Exchange attributes for each user will be synchronized, including the MailboxGuid attribute. If users are created in this state on Office 365, an Exchange Online license cannot be activated unless Mailbox Replication Services (MRS) is used to perform the mailbox move, or the steps above are followed to rectify this problem.

Once the users have been created on Office 365, and the licenses have been activated, then you can start using DirSync, AAD Sync, or AAD Connect in the normal manner. The problem is limited to the user creation and license enablement (when the local AD supports Exchange).

If the mailboxes are on an Exchange Server in the local AD, Office 365 accounts can be created using one of the following methodologies. Licenses will also need to be assigned to the users, once they have been created.

    • AAD Sync or AAD Connect. Follow the instructions detailed in the recommended approach above.

    • Manually, one at a time.

    • By bulk import, via CSV file.

    • BitTitan DirSync tool.

Filtering objects using Azure Active Direct (AAD) Connect

The steps below will set a filter, using AAD Connect, that will clear the msExchMailboxGuid to allow objects to be synchronized between environments.

Important:
  • If you are using AAD Sync, instead of AAD Connect, as your synchronization tool, the steps will be very similar to the ones detailed below.
  • If you are using DirSync, the steps will not be similar enough. In this case, we recommend that you upgrade to either AAD Sync or AAD Connect.

The following are example use cases where filtering objects from the synchronization could be advantageous:

  • Some users are already using Office 365 as a production platform. You would want to filter out all objects except those user objects that are already using Office 365. This way only those objects would be included in the synchronization.
  • You are planning a batch migration to Office 365. You would then want to filter out all objects except those user objects that are part of the batch, or any previous batch. This way only those objects would be included in the synchronization.
  • You do not have the required Exchange Online licenses to assign to all the users. This would be useful so that you can then assign licenses to all synchronized accounts.
  • Enabling the Exchange Online license will cause an error.

Important: 

In all of the scenarios above, you would still want to synchronize all the objects using AAD Connect in order to have a complete Global Address List (GAL) on Office 365. This will allow users to send email to the on-premises users, after mail routing has been enabled on Office 365.

Summary explanation:

The filter, based on a specific attribute, will clear the msExchMailboxGuid for the synchronized objects, and thus avoid any service disruption for those users already using Office 365.

Follow the steps below to guide you through the process of creating a new rule on AAD Connect, and filtering objects based on one extensionAttribute (called customAttribute on Exchange, and extensionAttribute on Active Directory Schema).

  • Before you start, it is very important that you are familiar with AAD Connect and PowerShell syntax.

Pre-Migration Tasks

  1. Choose one extensionAttribute that can be populated with a customized tag. In our example, we will use extensionAttribute 5and the tag "BT - User Migrated".
  2. Populate the extensionAttribute of the users that you are planning to assign an Exchange Online license to, with the chosen Tag.
  3. This step can be executed in any of the following ways:
    1. Using Exchange Management Console (EMC):
    2. Using Exchange Management Shell (EMS) by executing the following script:
    3. Set-Mailbox <user_UPN> -customAttribute5 "BT - User Migrated"
    4. Bulk edit using EMS:
      1. Create a users.CSV file with the UPN of the users that you what to enable the Exchange Online.
      2. Execute the following PowerShell script: $UserList = Import-CSV '<Path Name>\Users.csv' foreach( $user in $UserList ) {Set-Mailbox $user.UPN -customAttribute5 "BT - User Migrated"}
  1. Search and select the rule.
    1. In Windows, search for the Synchronization Rules Editor, and open it. Note:The default location is C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe.
    2. Search and select the rule with the name In from AD - User Exchange and click Export. Also, take note of the lowest precedence number (in this example it is 80). You will need it below.
    3. A Notepad (or other text editor defined as a default) will open, with a random name and a .tmp extension.
      Important: Save the file and keep it in a safe location. The file will allow you to recreate the default rule without any customization if something goes wrong.
  2. After you save the file, create a duplicate, change the extension to .ps1, and edit the file.
  3. On the .ps1 file:
    1. Change the Name to identify that it is a customized rule.
    2. Change Precedence to a number lower than the number found in Step 4 (in our example, it was 80).
  1. Delete the lines identifier and ImmutableTag.
  2. Open a PowerShell with elevated privileges, navigate to the folder where you store the .ps1 file, and execute the script. After it finishes, scroll up and validate that no error appears. 
  3. Confirm that a new line was created in the Synchronization Rules Editor. There is no refresh, so you will need to close and reopen it to confirm that a new line was created:
  4. Now, edit the rules.
    1. Start with the customized synchronization rule.
    2. Highlight the rule and click Edit.
    3. Select Scoping filter and click the Add clause  This will create a new line. Choose the extensionAttribute used before. Under Operator, select EQUAL and populate the Value with "BT - User Migrated".  Then select Transformations.
    4. Scroll down until you find the msExchMailboxGuid attribute, and change it to the following:
    5. Flow Type: Expression
      Target Attribute: msExchMailboxGuid
      Source: NULL
    6. Merge Type: Update
  5. Click Save. The window will close automatically.
  6. Now, edit the original Synchronization rule.
    1. On the Scoping filter, click Add clause
    2. Add the extensionAttribute, NOTEQUAL,and BT - User Migrated.
  7. Perform a FULL Sync. A DeltaSync will not make the required changes. 
  8. An easy way to perform this step is to open a PowerShell on the computer where AAD Connect is running, and execute the following script:
    1. ​Import-Module ADSync
      Start-ADSyncSyncCycle -PolicyType Initial
  9. Enable the Exchange Online license for the required users.
  10. Using EMC, AD, or using PowerShell, remove the tag BT - User Migrated from the users. If you use PowerShell, replace BT -User Migrated with $null. 
  11. Perform a DeltaSync. An easy way to perform this step is to open a PowerShell on the computer where AAD Connect is running, and execute the following script:
    1. ​Import-Module ADSync
      Start-ADSyncSyncCycle -PolicyType Delta

Post-migration tasks

After you enable all the required Exchange licenses in Office 365, you can revert all the changes made on AAD Connect:

  1. Highlight and delete the customized synchronization rule.
  2. Remove the clause from the Scoping filter of the original rule.

Sensitive Data 

The Scan Sensitive Data option works in conjunction with Azure Audit Log Options so that all data, except for data converted via OCR, within migrated items is scanned for sensitive data, like credit card numbers and social security numbers.

The Scan Senstive Data option is located in Advanced Options in MigrationWiz.

 snagged2.png

When this option is checked, whenever any sensitive data is discovered during migration, MigrationWiz will still migrate the data, but will mark the instance of the sensitive data occurrence, and log that instance to the Azure SQL Database. The instance, but not the actual data, will be logged.

  • If the severity level has been set to either "Fatal" or "Error", the severity level will automatically be increased to "Warning".
  • If the severity level has been set to either "Warning", "Information", or "Trace", the severity level will remain the same.​​

When you have done a migration with sensitive data detection activated, you might want to retrieve the actual records.

  1. Use SQL Management Studio to connect to your SQL Azure.
  2. Go to the appropriate Database and Table.
  3. Use this statement to get the data back: SELECT * FROM [dbo].MyTable WHERE severity = 2 

Create an SQL Azure Database for BitTitan Audit Logging

This is a two-step process:

  1. Create SQL Database
  2. Configure Firewall Settings

1. Create SQL Database

  1. Follow the Microsoft guide on creating a SQL database: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-single-database-get-started?tabs=azure-portal
  2. Note: Under the Pricing tier field, select the pricing tier you require.  (Recommended setting is Standard S3: 100 DTU, 250GB.)

You may need to log out and log in again before your new SQL Database will show in your portal.

2. Configure Firewall Settings

  1. Select the Resource Group that you created the SQL database server in.
  2. Click on Overview.
  3. Click on the SQL database AuditEventLog, then click on Set Server Firewall at the top of the screen.
  4. Add the following IP address information
    • Under Rule name, enter ALL
    • Under Start IP address, enter 1.1.1.1
    • Under End IP address, enter: 255.255.255.255
  5. Make sure that Allow access to Azure services is set to ON.

This is a required configuration since, by default, no one has access.

You are now ready to enable audit logging within your MigrationWiz project.

Refer to What is the BitTitan Audit Logging Service and what parameters need to be set? for more information on how to enable audit logging within your MigrationWiz project Advanced Options. 

Was this article helpful?
0 out of 1 found this helpful

Articles in this section

See more