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.

Contents of this guide:

 

Prerequisites

To enable the audit logging service, you first need to create the SQL Azure database. Read the Create an SQL Azure database for the BitTitan Audit Logging Service article for more information.

 

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 the URL listed below:

    https://manage.bittitan.com/
  2. Select the appropriate workgroup.
  3. Click Go To Projects in the Getting Started page.
  4. Click the name of the project for which you want to enable audit logging.
  5. Click Edit Project in the top menu bar, and then click 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 logs information, warning, error, and fatal information.

        Note: Severity levels with greater value 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.

      Note: 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: Server name.
    • Database: 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 name that you wish to give to the table.
  7. Click Save.

 

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. Read the What is the Scan Sensitive Data option? article for more information.
  • 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 sub folder, 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.

Note: 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 sub folders (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


    Note: 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?
1 out of 1 found this helpful