BitTitan Audit Logging Service Parameters

The BitTitan Audit Logging Service provides a detailed audit trail and log of all the actions taken during a migration. The audit log includes entries for actions performed against items, such as item read at the Source, item skipped, item created at the Destination, item-level errors that occurred during migration, etc. These are logged to a SQL Azure database that you create and own. You are then able to build on top of the data by creating customized reports that provide the transparency necessary for security and compliance. 

 

IMPORTANT: The Audit Logging Service logs items as they are being actively migrated, so it must be setup and functional before migrating any data in the project. It will not generate any logs for data already migrated.

Prerequisites

First, you must create the SQL Azure database to enable the audit logging service. 

Enable Audit Logging

After you have created the SQL Azure database, you are ready to enable the audit logging service for your migration.

Follow these steps:

  1. Sign in to MSPComplete at https://manage.bittitan.com/
  2. Select the appropriate workgroup.
  3. Click Go To Projects on the Getting Started page.
  4. Click the project name for which you want to enable audit logging.
  5. Click Edit Project in the top menu bar, then Advanced Options.
  6. In the Audit Log Options section, set the following values:
    • Audit log type: SQL Azure
    • Severity: Choose one of the log options listed.
      • Fatal (0): Logs issues that will cause your migration to stop and fail, such as failed credentials.
      • Error (1): Logs errors returned from the Source or Destination environment. Also logs fatal information.
      • Warning (2): Logs warnings, such as for skipped unsupported items. Also logs errors and fatal information.
      • Information (3): Logs information actions. Also logs warnings, errors, and fatal information.
      • Trace (4): Logs all simple actions that are not one of the above (1 through 4). Also information, warning, error, and fatal information logs.

        Important

        Severity levels with greater values include logs of those from lower values For example, the “warnings” log includes “warning”, “error”, and “fatal” severity data. The “trace” log includes all the values listed above.
    • Number of items to hold in the log queue: The number of items to hold in the log queue before flushing to the database. The queue will flush either when it reaches the buffer size, or every minute, whichever comes first. Choose a small buffer size to ensure your data is written to the database as soon as possible. However, too small of a buffer size may cause a data bottleneck.
    • Server Name
    • Database Name: AuditEventLog
    • Username
    • Password
    • Connection time out
    • Table name: The table and schema will be generated by the audit log service, but you must specify the table name.
  7. Click Validate.

Database Structure

When you start the migration, MigrationWiz creates a single table in the Azure SQL database with the values listed below. Each row in the database represents an action performed by MigrationWiz.

Value

Description

Severity

The importance of the data logged for the item:

  • Fatal: An issue that will cause your migration to stop and fail, such as failed credentials.
  • Error: An error returned from the Source or Destination environment.
  • Warning: A warning, such as for skipped items was skipped because it was unsupported.
  • Information: Informational action, such as item read at the Source.
  • Trace: All simple actions that are not one of the above.

MailboxConnectorId

The migration project ID (in MigrationWiz) that the item pertains to.

MailboxId

The mailbox ID (in MigrationWiz) that the item pertains to.

MigrationId

The migration pass/run ID (in MigrationWiz) that the item pertains to.

MailboxConnectorName

The name of the project (in MigrationWiz) that the item pertains to.

ExportEmailAddress

The Source email address that the item pertains to.

ImportEmailAddress

The Destination email address that the item pertains to.

Description

Description (testing credentials passed, item successfully read, etc.) for the action performed.

Action

Action performed.

  • 0 (Item read): The item was successfully read at the Source, but not yet migrated.
  • 1 (Item created): The item was successfully migrated to the Destination.
  • 2 (Item skipped): The item from the Source was not migrated to the Destination. Items are typically skipped if they’re unsupported.
  • 3 (Property skipped): An item property from the Source was not set at the Destination.
  • 4 (Property transformed): An item property from the Source was changed at the Destination.
  • 5 (Migration event): A generic action was performed for the item, such as tested credentials, downloaded files, etc.
  • 6 (Sensitive data found): The item contains sensitive data.
  • 7 (Item updated): The item was subsequently updated at the Destination from a previous migration pass.

ItemType

The item type.

  • 0 (None)
  • 1 (Contact)
  • 2 (Calendar)
  • 4 (Mail)
  • 8 (Journal)
  • 16 (Note)
  • 32 (Task)
  • 64 (Folder)
  • 128 (Rule)
  • 256 (Conversation)
  • 512 (Contact group)
  • 1024 (Document File)
  • 2048 (Database item)
  • 4096 (Song)
  • 8192 (Security Group)
  • 16384 (Permission Levels)
  • 32768 (Document Library Permissions)
  • 65536 (Permissions)
  • 131072 (Archive slices)
  • 262144 (Archive email addresses)
  • 524288 (Archive email)
  • 1048576 (Archive file)
  • 2097152 (EAM Extraction Item)
  • 4194304 (Archive file)
  • 8388608 (Lists)

ItemPath

Path for the item at the Destination, such as the mailbox subfolder, or document directory.

ItemName

Item subject, such as the email subject or file name.

ItemId

The item ID.

EventTimestamp

Date and time for the action performed.

Hash

MigrationWiz hash for the action performed.

The size of the database depends on the size of the migration. A large migration will generate a larger database.

Next Steps

Use the audit log data to compare the number of items read at the Source, against the number of migrated items at the Destination. Be aware that some items may have duplicate “1 (Item created)” entries in the database. This happens, for example, when MigrationWiz migrates emails from G Suite that have multiple labels by duplicating them and migrating them into separate subfolders (one for each label) in the Destination Exchange mailbox. Run this SQL query to confirm the total number of unique items migrated to the Destination:
select ExportEmailAddress,count(distinct ItemId)
from [AuditEventLog]
where [ExportEmailAddress] = '<user’s email address>'
and (Action= 1 or Action=2)
group by ExportEmailAddress
Replace <user’s email address> with the user's email address. Review the items with a fatal, error, or warning severity level to determine the impact at the Destination. Search our Knowledge Base for error lookup articles to resolve the issues.

Was this article helpful?
2 out of 3 found this helpful