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 storage or the BitTitan Azure storage. 

Important

IP lockdown 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 BitTitan Storage

When using your own Azure storage:

  • There are 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 Azure storage

BitTitan has its own Azure storage, which can be used by Partners for temporary storage on Azure during those migrations that 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. Otherwise, they can use the BitTitan Azure storage to store their files temporarily.

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 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 a new one if one does not 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.

    Important

    ​​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 and go to Resource.
  12. Select Access keys under Settings.
  13. Copy the Storage account name and the key 1.
  14. 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 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 that 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 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 Microsoft Entra Objects

For more information regarding this topic, refer to Azure Identity Considerations KB. Also, you can use this article from Microsoft for the most up-to-date information: Set up Directory Synchronization.

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 Sensitive 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 migrated 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

To create a SQL Database, follow the Microsoft guide on creating a SQL database

Important

Under the Pricing tier field, select the pricing tier you require.  The 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 in which you created the SQL database server.
  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