This guide is intended as a reference in the management, use, and understanding of PST Flight Deck. This document was written for a technical audience whom are anticipating a base deployment of a PST Flight Deck environment. It is intended to provide an overview and high-level understanding of the product. Large, complex, or constrained migrations should engage a PST Flight Deck Architect to take the circumstances of your project into consideration.
Where to Get More Information
There is additional information about PST Flight Deck on our website:
You may also contact a Quadrotech support representative by email:
PST Flight Deck is a scalable enterprise capable solution designed to address the issue of decades of unmanaged PST file creation, utilization, and proliferation throughout an organization. The objective of this solution is to identify and migrate the content of Personal Storage Table (PST) files into a target environment in order to permit the content to be subject to regulatory, retention, and organizational requirements. Upon ingestion, it can also be used to eliminate PST files identified throughout the organization.
PST files were initially introduced to help Administrators manage data on Exchange 4.0 mail servers. Their availability was expanded to support the use by Outlook to archive or store mail items locally. Expensive and limited mailbox store data on early versions of Exchange made PST files popular with organizations. PST files permitted the expanded use of a mail system without dramatically increasing the perceived cost, downtime, or expense of an Exchange environment. Mailbox quotas began to shrink to ensure the stability and availability of mail servers and PST files were now the target of the exponential growth in data use to facilitate the increased use of email systems within an organization.
PST files are a problem within most organizations today. When introduced to users, there were few guidelines as to how or when to use them. Some users began to route all their Exchange mail directly to their local storage, removing the administration and defensible deletion of mail content. Other users took this as an opportunity to save and store everything; began abusing the intent of the system by using it more as a file server than a mail server. Departments began using the storage containers for projects or departmental data on network shares where they were unsupported and more prone to corruption. The data stored within the files frequently fell outside of organizational compliance, retention, and discovery requirements. Data began being lost to poor management practices from the users of these files, corruption, or hardware changes. This PST file life-cycle continued for over a decade in several organizations, resulting in an enormous body of data completely unmanaged, decentralized, and with limited accessibility to those needing it most.
As time progressed, Exchange was able to restructure its storage to accommodate less expensive disks and more redundancy. The server could now accommodate the level of storage being used at a reasonable price without the same concerns of older server versions. While in the wild, PST files had become a problem. A big problem. The longer the use of PST files was permitted, the harder the problem was to resolve. Until the recent versions of Outlook, users were still permitted to store all Exchange mailbox data directly to a PST file on their system and remove all their messages from the centrally managed Exchange servers.
Manual attempts to eliminate PST files by IT departments proved to require a high level of messaging expertise, be very costly, and have an ever-expanding project duration. When things went well, a migration project was time consuming, labour intensive, and was challenging to track the progress of. The limited visibility made it challenging to accurately communicate the expected experience to the users impacted and groups intended to support them. Help desks became flooded with frustrated users wanting access to their critical data and was unable to provide any insight or accurate time-lines as to when their data would become available to them again. Engineers had to request personal passwords, be challenged with old PST file formats, duplicate items within PST files, files that were erroneous duplicated, files that were made as a backup, and file corruption of the PST files. When things went poorly, the effort frequently just failed after much expense and little progress.
The PST Flight Deck Solution
PST Flight Deck is a feature-rich, enterprise grade solution designed to reduce the time and level of effort required migrate PST files to a desired target. PST Flight Deck is designed to minimize many of the issues that plague PST migration projects. PST Flight Deck is able to discover, associate, centralize, process, ingest, and eliminate PST files automatically.
With PST Flight Deck, modules are run prior to the ingestion that are designed to prepare a PST file for quick delivery to the target system. These “pre-flight checks” are initially configured, then executed on every PST file that runs through PST Flight Deck. This process reduces the effort of an overall PST file migration by automating many of the tasks that would be performed reactively by skilled professionals, whom likely have several other responsibilities.
PST Flight Deck is built on a modular framework that permits a nearly infinite number of solution design options. The architectural components of PST Flight Deck can be summarized as those that are required for a functional environment and those that provide expanded and supplemental functionality to the solution.
In its most basic configuration, PST Flight Deck requires at least one server, a SQL database, and Migration Agents deployed. The actual requirements for a given project are dependent on the scope and limitations of the project. For a properly scaled environment, please consult a qualified PST Flight Deck architect to review your environment and it’s needs as it pertains to a PST Flight Deck deployment.
Below is a diagram showing a high-level architecture of the required components for PST Flight Deck and how they interact in a production environment.
The Core server is responsible for several aspects required for a functional PST Flight Deck system. In a typical configuration, the Core server hosts the PST Flight Deck Core service, the Internet Information Services (IIS) instance hosting PST Flight Deck files, the Background Intelligent Transfer Service (BITS) upload directory, and any number of modules.
The Core service is responsible for communication with the PST Flight Deck system database and execution of scheduled operations. All deployed agents also check-in and update the system through the Core server. Essentially, the Core service acts as the conductor of the entire solution.
A typical deployment of PST Flight Deck begins with the installation of a Core server. In most environments, more than one PST Flight Deck server is used, however for non-production installs it is possible to install all the components on a single server. Supplemental components may also be installed on the Core server, either from the Core installer itself or independent installers.
In PST Flight Deck, a module refers to one of the components of the solution that run against successfully uploaded user data to a defined and centralized location. It is possible to categorize the PST Flight Deck modules in three categories: pre-ingestion, ingestion, and post-ingestion modules. Although workflow order is configurable, the following categorization is based on a default installation with no modification in the workflow’s order.
Pre-ingestion modules are those that are configured to run prior to the ingestion module. Sometimes referred to as the “pre-flight checks,” pre-ingestion modules are designed to prepare and safeguard PST data for ingestion into a desired target. The following table discusses the pre-ingestion modules available for enablement.
|Local Upload||Checks if the PST file is present in the BITS upload location|
|Park||Moves ownerless files to an alternate storage location until ownership is defined|
|Backup||Copies a PST file to a designated location until operator deletion|
|Repair||Executes a repair on a PST file|
|Extraction||Filters and extracts PST files to disk to enable streamlined processing and delivery to the target|
|Deduplication||Reviews the PST file content to identify duplicated messages and removes them|
In most configurations, Extraction and Repair modules should be local to the Uploads directory frequently configured on the Core server.
Ingestion modules are typically chosen at the point of installation. These are the modules responsible for the PST Flight Deck actions taken to ingest a PST file’s contents into the desired target. As the first item ingesting successfully completes, the migrated content should be immediately available in the target system. Once a PST file has been successfully ingested or ingestion of the file is not required, PST Flight Deck considers the file as “completed.”
Rate of ingestion is frequently a point of bottleneck in a migration and can be monitored in the Management Console, Admin Console, or via the PST Flight Deck Portal. Tuning an ingestion for performance requires the PST Flight Deck Admin Console and an account with sufficient rights. The net ingestion rate may be constrained by limitations of the environment and increasing its work capabilities may result in a decrease of performance. In general, ingestion tuning is performed while closely monitoring the entire environment and until a suitable rate has been achieved or a resource is excessively constrained. If resource constraint occurs, the last known good configuration should be evaluated for resource constraint and selected as the “best tuned” configuration at that point in time.
PST Flight Deck still has some wrapping up to do after the ingestion has completed for a file. Post-ingestion modules are those modules that are responsible for the tasks necessary to clean up after a file has been migrated. The following table discusses the post-ingestion modules available for enablement.
|Legacy Viewer||Provides a web-based view into the original PST file contents and structure|
|CleanUp||Removes processed content from the BITS upload directory|
|Source File Remover||Queues request for Agents to delete the original file in its original location|
|PowerShell||Permits the execution of PowerShell scripts as part of the workflow of a PST file. PowerShell scripts can also be used in the pre-ingestion workflow.|
PST Flight Deck leverages a component installed on end-user Windows workstations called the Migration Agent. This agent is critical for discovering PST files, providing meta-data to help determine PST file ownership, managing the user interaction with the migration process, and uploading PST files to a centralized location throughout a migration project. The Migration Agent has a lightweight footprint and is supported on many client operating systems. The Windows version of the Migration Agent has 64 and 32-bit versions. The version of agent that will be installed will coincide with the architecture of Outlook that is installed.
PST Flight Deck has several features that are not required for a basic configuration but provide an enhanced, more robust, or more customizable experience. The features that are required for any given deployment will vary wildly and it is encouraged to discuss your needs with a qualified PST Flight Deck Architect to determine which components are appropriate for you.
PST Flight Deck permits the flexibility to support any size of organization. Smaller organizations may be well suited in utilizing a single configuration for all its users. A larger enterprise often has several conditions which make a “one configuration fits all” approach impractical. PST Flight Deck is able to support the smallest branch offices while managing multiple large campuses within a single environment. To begin to support an enterprise’s level of complexity, PST Flight Deck permits the customization of configuration settings within its environment via profile and location designation.
Profiles are the initial building block of the ability for a PST Flight Deck to have the level of customizable configuration needed to support today’s enterprise. Profiles are used to permit an alternate configuration for users assigned to them. Examples where profiles may be of use are:
- Support complex network topology and limitations
- Support multiple locations
- Support site specific uploads and processing
- Support alternate configurations for different user types (e.g. Executives, road warriors, factory employees)
Profiles enable the assignment of unique File Scanner, Agent, Language, and Location configurations.
Locations permit work to be assigned into geographically appropriate groupings without the overhead of deployment and management of independent migration environments. This enables an organization to centralize and process PST files in data centres close to the users and their data. Enabling the ability to support multiple locations can reduce overall environmental network consumption and the time for project completion.
PST Flight Deck permits the ability to scale out an environment to offload the burden on any given system in the environment. For small and mid-sized projects with no special requirements, a standard deployment may be sufficient. For larger environments or projects with tight time requirements, processing modules may be distributed over several machines to scale the system to match the environment’s needs or reduce bottlenecks in the workflow. These computers with module components of PST Flight Deck installed are referred to as “nodes”.
When considering the scalability of your PST Flight Deck environment there are many factors to consider. Please consult a qualified PST Flight Deck Architect prior to scaling out an environment.
Part of the flexibility of PST Flight Deck is the modular approach that is taken within its architecture. The functions required to perform a migration can be run over multiple nodes. This permits many of the same modules to be run in parallel or assigned to specific locations.
Module Nodes are servers with PST Flight Deck modules installed on them. They encompass all PST Flight Deck servers containing modules and not included in another node type. Module nodes can be used to scale processing of any module workload to permit rapid processing of items uploaded.
Most Module Nodes do not have any special considerations outside of resource availability and the ability to communicate to the Core. Extraction and repair nodes have high disk requirements and are typically located on the machine with the highspeed disks used for the BITS upload directory.
Ingestion Nodes are Module Nodes that include an Ingestion module. They are typically deployed to support geographically distributed resource allocation within PST Flight Deck. Multiple ingestion nodes may also be leveraged to expedite the timeline to project completion when appropriate.
An Azure Node is a special node used in migrations to cloud based targets. Azure nodes can be used in a migration by itself or in support of geographically centric resource allocation for a multi-site organization. Azure Nodes are nodes deployed to Microsoft’s Azure service to act as the intended centralization target, processing, and ingestion nodes for a configured location. Azure Nodes can be used to minimize the footprint required to scale an environment out or to enable small businesses to leverage PST Flight Deck by reducing the initial hardware requirements of the solution.
One of the largest challenges in PST migration projects is accurately determining ownership of a PST file. Most PST files have ownership identified within the Discovery process for PST Flight Deck. PST files identified by a Share Scanner, or by a user as not belonging to them, require some special analysis. PST Flight Deck’s Content Scanner is used to scan PST files marked as “Ownerless,” or those files located on specific fileservers. It can provide more information to help determine ownership association based on the contents of the file. Files processed by the Content Scanner can have the most common sender and most common recipient recorded and taken into consideration when determining PST file ownership. This attribute is also evaluated against a user’s proxy addresses to ensure account migration history is taken into consideration when evaluating ownership.
The Central Upload Agent (CUA) is a component frequently utilized in a PST Flight Deck environment. The primary role of the CUA is to upload files stored on centralized repositories more rapidly without having to use a workstation’s Migration Agent.
In a traditional migration situation without a CUA, remotely stored PST files would be queued for BITS transfer using a user’s Migration Agent to facilitate the upload request.
When a CUA is deployed, and the environment is appropriately configured, files on remote file servers are uploaded by a nearby CUA rather than connecting back through the workstation.
If an environment has a CUA installed, configured, and running with sufficient permissions, it can be used to facilitate Forced Migration requests. A Forced Migration utilizes the CUA to connect to a user’s local machine and copy the eligible PST file over the administrative share on their local system. This enables a user to have their files uploaded without having to go through BITS or even a Migration Agent. This feature is useful for Migration Agents struggling to complete an upload or as a means to migrate users who are rarely connected to the domain.
Support for Application Streaming
The PST Flight Deck Application Streaming Wrapper (ASW) is designed for environments that utilize virtual application streaming to provide Outlook to users. Due to the way application streaming is performed, a typical agent approach cannot be used.
The ASW works as a wrapper for Outlook on an application streaming solution. Upon launch, it checks to see if a user is enabled for migration. If they are enabled, it quickly closes open connections to PST files associated with the user’s Outlook profile during that streaming session. Once that has completed, it launches Outlook and maintains the standard user experience without any of the PST files connected. There is no interaction required from users streaming Outlook but their experience will be impacted as PST files will no longer be attached to their streamed Outlook instance. The ASW is frequently used in conjunction with a Share Scanner and Central Upload Agent to enable discovered files to be uploaded from shared resources without the use of a traditional Migration Agent.
A PST Flight Deck environment can be globally distributed and centrally managed by a single Core server. Administration and operation of the environment can be performed remotely. The PST Flight Deck Management Console is available to those needing the ability to manage a PST Flight Deck migration without the need to edit the settings of the migration solution. The ability to install a console on an Operator’s workstation enables them to perform their duties without the need to grant remote access to the server hosting. The core services and Administration Console.
PST Flight Deck has a choice of user interfaces to interact with the product. To some extent the interface utilized depends on the role being performed. PST Flight Deck is scalable not just in processing power, but also in its ability to adapt to any size of team associated with the migration project.
PST Flight Deck consoles are applications that run from the server or an Administrator, Architect, or Operator’s workstation. They permit the most control over a PST Flight Deck environment. There are two consoles available: The PST Flight Deck Administrator Console and the PST Flight Deck Management Console.
The PST Flight Deck Administrator Console (Admin Console) provides the most access to configure a PST Flight Deck environment. It is typically available on the Core server and is installed as an available feature by the Core installer. Access to the Admin Console is required during the initial install, setup, pilot, and ramp-up of your project, but is not typically required for the duration of your project. Alternatively, a project can be entirely managed from the Admin Console if desired.
The PST Flight Deck Management Console (Management Console) is intended to provide operators a client to use on their local workstations. The Management Console provides the options necessary to perform the daily operations of a PST Flight Deck migration without requiring access to a PST Flight Deck server. The primary difference between the two consoles is the Management Console does not have the option for the “Settings” menu as the Admin Console does.
With the exception of the above, both interfaces are the same. The remainder of this section will refer to both as the Console.
In general, navigation within the Console is similar no matter where you are in the Console. The core of a Console has a Ribbon Panel, Navigation panel, and the body of the console, where the selected data is displayed.
The top of the Console contains several features and is seen below:
|1||File Options||Provides the ability to display general information, launch a help file, or exit the Console|
|2||Info||Provides information related to the product, version, and license|
|3||Ribbon||Provides options related to the visible or selected items within the interface. Changes depending on location and selection within the Console|
The left side of the Console is used for navigation. The following is an example of the options available within the navigation pane of the console:
|1||Navigation Control||Collapses the navigation panel|
|2||Navigation sub-menus||Options that are exposed based on the navigation menu selected|
|3||Navigation sizing||Slider to permit you to resize the navigation pane|
|4||Navigation menus||Parent navigation options that expose contextual options for a given area|
The navigation pane has menus at the bottom that act as parent containers for related options within. Selecting one of these menus will expose relevant sub-menus in the navigation pane above. The menus available are Manage, Reports, and Settings.
Managing Console Data
The Consoles have a powerful interface that permits the filtering of live data to return data you are seeking. Many areas of PST Flight Deck return a lot of data that can be too much to be useful without the ability to refine the results. The information below discusses several approaches to managing the data being returned within the grid of several options within the Console.
Additional data columns can be added to many of the grids in PST Flight Deck.
To access the additional columns of data:
- Right-click on an existing column heading
- Select “Column Chooser”
A list of available data columns will be shown. You can drag and drop from the list of columns on to the appropriate part of the user-list.
The column headings can be clicked to change the sort order, a subsequent click on the same column heading will change the direction of the sort. Most columns support “drag and drop” functionality to change their position relative to the other data columns. This can make the data more presentable and readable. A data column can be removed if required by right-clicking on the column and choosing the “Remove this Column” option.
It is possible to access the data filtering features in most of the Console’s grids in these ways:
- Right click on the appropriate column heading and choose the option “Filter Editor”
- Hover near the right hand corner of a column heading until the small filter icon becomes visible, and then click on it
- By default, the filter entry row is displayed underneath the column headings. A value can be entered into any of the columns in this row and the data list will automatically be filtered according to your input. Operations can be selected by clicking the small icon (filter hint). This will show this popup
Simply click on the desired operator and it will be entered.
After a filter has been applied, an option to “Edit Filter” is presented in the lower right corner of a console. This can be selected to access the advanced editor for the currently applied filter, which will permit you to perform very complex queries to return specific data within a Console.
The list of users can be grouped by one or more columns as follows:
- Right click on an appropriate column heading and choose the option “Group By This Column”
- Right click on a column heading and choose the option “Show Group By Box”
Filtering can be used to reduce the overall list, but sometimes it is necessary to search for data within a given column. You can search for particular data within a grid by right-clicking on a column heading and selecting the option “Show Find Panel.” Previously used searches can be selected from the dropdown list.
Saving a Layout
If you identify a filter that is useful for your migration it is possible to save it for later use. To store the customized grid click on “Save” in the “Layout” ribbon. Each saved layout can be given a unique name. Previously saved layouts can be retrieved by clicking on “Load” in the “Layout” ribbon bar. The current data list can be reset to the defaults by clicking on “Reset” in the “Layout” ribbon bar. Saved layouts can be retrieved and executed by selecting “Load” on the PST Flight Deck “Layout” ribbon and selecting the name assigned to the saved layout. You can also select “Overwrite” to save over a pre-existing layout or “Delete” to remove the saved layout.
The “Manage” menu is the most commonly accessed area during a migration. Most of the functionality required for an Operator to manage the PST Flight Deck migration can be found in this section. Options are grouped into sub-menus and are described below:
|Progress||Provides high-level statistics and trends about the current status of a migration|
|Operations||Provides information of interest in the daily operation of a system including performance trends and current backlog information|
|Resources||Provides information about CPU, memory and disk performance|
|Users||Provides information and options to manage the end-users in the environment|
|Files||Provides information and options to manage the files discovered in the environment|
|Events||A filterable list of events produced within the PST Flight Deck environment during a migration|
|Owners||Permits ownership review and management during a migration|
|Schedule groups||Permits the scheduling of enabled batches|
Some key combinations have been included to assist in the navigation of the Manage section of the console. The areas affected are frequently navigated between during a migration project. Use of these hotkeys can enable quicker daily navigation.
|ALT + U||Navigates to the last view of the Manage > User section|
|ALT + F||Navigates to the last view of the Manage > File section|
|ALT + O||Navigates to the last view of the Manage > Owners section|
Additionally, there are shortcut keys associated with specific popup dialog boxes.
This view provides an overview of the project as a whole. The following are its features:
|User||Table showing statistics related to uses and their status within the migration|
|Project Statistics||Graphs showing the status and trends of files and users over the past days, weeks, or months|
|File||Table showing statistics related to discovered files and their status within the migration|
A section designed to enable an Operator to quickly be able to tell the current health of a migration in a graphical display. The following are its features:
|Alerts||Drillable badges displaying the number of actions needed or unacknowledged events|
|Last 24 hour BITS activity||Shows hourly activity reported for files being centralized from the Agents to PST Flight Deck for the past 24 hours|
|Module Backlog||Drillable bar graph showing the size or count of data backlogged per PST Flight Deck module|
|Last 24 hour Ingest activity||Shows hourly ingest rates over the past 24 hours|
|BITS size last 14 days||Line graph showing daily rates of centralized data over the past two weeks|
|Ingest activity last 14 days||Line graph showing daily rates of ingestion over the past two weeks|
This section permits centralized observation of resource consumption of servers running Modules within a specified location. The focus of this is to provide a point in time review of resource consumption and not a comprehensive performance monitor for the PST Flight Deck environment. Displayed is graphical output for CPU, RAM, and disk usage.
This section of the Console is where most actions against users are taken. Assignment of user types, profiles, and priorities are all performed within this section. This sub-menu is where a lot of the migration monitoring and management takes place.
The grid returned under the “Users” sub-menu is comprised of two portions. Initially presented is a display of user information and general statistics about all the users in an AD environment. Each user who has discovered files can be expanded by clicking the plus sign (+) at the left of its row. The resultant sub-table has the same characteristics as the “Files” section and will be described in detail in a succeeding section of this guide. The ribbon and right-click options change depending on which section your selection is located.
The home ribbon when “Users” is selected has options impacting the selected user (with one exception). These options and a description of their functionality are as follows:
|Refresh||Refresh||Refreshes data in the grid|
|Enable Users||Manage Users||Permits the ability to set migration and email priority assignments to enable users for email communication or migration|
|Actions||Manage Users||Contains a dropdown list of several available actions. The contents of the list are also available when right-clicking a selection in the grid|
|Reset User||Manage Users||Removes all database entries for files associated with the selected user or group of users|
|Assign Profile||Manage Users||Permits profile assignments to users for specialized settings|
|Request Client Log File||Manage Users||Queues a request delivered at the next agent polling period for a selected user to return the PST Flight Deck Migration Agent client logs to the server for review|
|Import Attributes||Manage Users||Allows importing of a specifically formatted text file, or XLSX, to assign values to fields for specific users|
|Edit Attributes||Manage Users||Allows manual assignment of “User Custom Field” values|
|User Log||Manage Users||Provides information regarding events, errors, and actions taken against the selected user through the duration of the project|
|Progress||Information||Provides Active Directory information about the selected user and the status of all PST files for that user by number, volume, and current progress|
|Inactive Users||Information||Provides the ability to identify users who have historically returned discovery results but have been inactive for a specified number of days|
|Add||Comments||Enabled Operator to create a new comment on a user or file depending on the selection|
|Show||Comments||Shows all comments associated with the selection|
|Close All Comments||Comments||Closes all comments associated with the selection|
The “Action” menu has several options for selection. As with the home ribbon under the “Users” sub-menu, these options are related to the presently selected object in the grid, and changes depending on if that selection is one or many files or users. These options are also available when right-clicking on selection within the grid. The following is a list and description of the options available under the “Action” menu when a user is the selected object:
|Clear Postponement||During an interactive migration, permits a reset of a user’s request to postpone the migration of their files|
|Mark files for Migration||Operators option to migrate a user’s files|
|Mark files for Deletion||Operators option to delete a user’s files|
|Change User Type||Operators option to specify a non-default user type for an account|
|Manage User’s Files||Shows a filtered redirection to the owner management portion of the console showing the selected users files|
|Set Unauthorized for Migration||Marks a user not authorised for migration, even though they may be enabled|
|Watch/Stop processing||Flags or un-flags a user for watching|
|Show user’s workstations||Shows workstations that a given user has logged into|
The type of user designated by the “Change User Type” option can dictate the way the features of the product affect a given user. Below is a list of available types and their description:
|User Account||Default type assigned to all users|
|Service Account||Type to identify service accounts that may be discovering data erroneously|
|Admin Account||Type to identify accounts with elevated permissions that may be discovering data erroneously|
|Group Mailbox Account||Type to identify mailboxes belonging to a department or other group|
|Operator||Designated type for all PST Flight Deck Operators|
|Leaver||Designation for an account belonging to someone who has left the organization|
|Helpdesk||Designation for member of the help desk team|
|Not in AD||Designation for local accounts logged into workstations with a Migration Agent installed|
|Mac OS user||Designation for users running a version of Apple’s workstation operating system|
|Cloud||Designation for a user that is in Office 365 with an email address different from the one in Active Directory|
The “Files” section of the console is also very commonly accessed while managing a migration. Like the “Users” section, it provides a lot of functionality to determine status and granular details of a migration. Actions can be executed on specific files when appropriate. The options available in the “Files” sub-menu’s home ribbon are as follows:
|Refresh||Refresh||Refreshes the data in the grid|
|Actions||Manage PSTs||Contains a dropdown list of several available actions available to take about the selection in the grid|
|Reprocess Module||Manage PSTs||Opens a window to allow for removing and reprocessing modules for the selected file|
|Reset Upload||Manage PSTs||Removes upload status and queues eligible files to be uploaded|
|Import File Attributes||Manage PSTs||Allows importing of a specifically formatted text file, or XLSX, to assign values to fields for specific files|
|Migration Statistics||Information||Shows statistics for the ingestion of a PST file|
|Progress||Information||Shows the details for all modules run against a selected file|
|Show Discovery||Information||Shows information on instances of discovery for a selected file|
|Show Events||Information||Shows all events logged that are related to a file|
|User log||Information||Provides information regarding events, errors, and actions taken against the user associated with the selected file through the duration of the project|
|Add||Comments||Enables creation of a new comment on the selected file|
|Show||Comments||Shows all comments associated with the selection|
|Close All Comments||Comments||Closes all comments associated with the selection|
|Continue/Delete||Operations||Change status of selected file or files to ‘Deleting’ and removes applicable failed module|
|Repair||Operations||Changes status of selected file or files to ‘File corrupt’ and removes applicable failed module|
|Continue/Unblock||Operations||Removed ‘Ingestion blocked’ or “Partial extraction’ status on selected files|
|Reingest||Operations||Queues a file or its contents to be copied from the configured ‘re-ingestion’ location to the configured ‘upload location’ and sets the file to be reprocessed|
|Continue/Migration||Operations||Changes status of the selected file or files to ‘Migrating’ and removes applicable failed module|
|Skip Module||Operations||Forces the current module to be skipped and permits a file to move on to the next phase of the workflow|
The “Action” menu has several options for selection. These options are also available when right-clicking on a file within the grid. The following is a list and description of the options available:
|Show User||Changes console navigation to the Users section filtered by the user associated with the selection|
|Change Owner||Launches a window to specify the owner of selected file or files|
|Change Status||Launches a window to change the migration status of selected file or files|
|Request Client Log File||Queues a request to be delivered at the next agent polling period of a specific user to return the PST Flight Deck client lots to the server for review|
|Reset Agent||Queues a request delivered at the next agent polling period for the agent to be exited and launched again|
|Disconnect File||Removes the selected file from the users PST profile resulting in the file being disconnected from Outlook when next launched|
|Scan Content||Flags a file for the Content Scanner to review|
|Show Workstation Files||Change console navigation to a filtered ‘owners’ section showing all files located on the same machine as the selections original location|
|Collect Orphaned||Permits users to receive a request to secure and transfer a PST file for centralization|
|Report Module Stats||Redirects view to Reports > PostProcess Stats with filter for the selected PSTFileEntryID|
|Remove File Entry||Removes record of the selected file from the database|
|Re-Ingest||Re-ingest a file|
|Watch/Stop Watching||Flags or un-flags a file for watching|
The Watched items section shows all files and users that have been flagged for watching. This provides a consolidate view of key items. The home ribbon for this sub-menu and each action menu changes depending what is selected, a user or a file. The ribbons and action menu options are the same as their respective
The Events section shows all unacknowledged events that have occurred on the system since deployed. The default view of the Events grid shows the Type, Source, Event details, a count of the occurrences of the events, the level of severity of the event, and the last logged time for the event. The home ribbon for this sub-menu has the following options:
|Refresh||Refreshes the data appearing in the grid with the latest information from the system database|
|Acknowledge||Marks the selected event as acknowledged resulting in its removal from the view upon refresh|
|Search||Permits searching events using values in specified fields|
|Add||Enables creation of a new comment on a selected event|
|Show||Show all comments associated with the selection|
|Close All Comments||Closes all comments for the selected event(s)|
Managing owners is a critical part of a successful migration. The Owners section shows the results of our owner identification efforts; including owner conflicts, warning levels, all ownership related metadata, the probability that ownership has been identified, who a presently is the owner of a file, and who PST Flight Deck thinks should be the owner.
In some migrations, a lot of effort is required in the Owners section to ensure the data discovered is going where it is expected to go. Upon discovery, ownership management can begin and drastically reduce the level of effort required towards the middle and end of a migration. Owner management can also be delayed until later in the migration. If file ownership is not addressed early in the project, the files could be blocked from ingestion due to not meeting the minimum ownership probability threshold.
The options on the home ribbon for the Owners sub-menu are as follows:
|Refresh||Refreshes the data|
|Recalculate Ownership||Calculates ownership probability and conflict warning of the selection|
|Accept Suggest User||Assigns ownership of the selection to the user suggested|
|Clear Operator Override||Removes Operator assigned ownership of the selection|
|Set Owner||Produces window to assign ownership of the selection from a list of users|
|Import Owners||Option to import specifically formatted CSV file to make ownership decisions|
|Unblock||Enables file where ingestion has been blocked, to proceed|
|Mark for Deletion||Change status of selection to ‘Deleting’ status|
|Add||Enables creation of a new comment on a selected file|
|Show||Shows all comments associated with the selection|
|Close All Comments||Close all comments for the selected files(s)|
|Details||Shows key pieces of information for a specific file|
Schedule groups allows an operator to schedule batches to be enable at a certain time/date, with a specific migration priority. Settings are available that can limit the number of people and/or volume for a given batch.
At the specified date/time, the users in a given batch are set to the specified migration priority as long the following conditions are met:
- Optionally, the user has an Office 365 mailbox
- Optionally, the mailbox is licensed
- Optionally, size of discovered PST’s is smaller than the free space in the mailbox
- Optionally, uploads is not in a limited or stopped state.
Office 365 mailbox information is obtained from the Office 365 user synchronization task. The options on the home ribbon for the Schedule groups sub-menu are as follows:
|Refresh||Refreshes the data|
|Add||Adds a scheduled batch configuration|
|Edit||Edits an existing scheduled batch configuration|
|Delete||Deletes an existing scheduled batch configuration|
|Import||Allows importing of a specifically formatted text file, or XLSX, to assign values to the fields associated with batch schedules|
|Set notifications||Allows setting an email address to receive notifications when scheduled group is not enabled|
The Reports menu of the console is where an Operator or Administrator would go to get information related to the migration. Some of the content seen in this section is similar to data available through the Manage menu and is provided with alternate options in the ribbon. The following is a list of sub-menus for the Reports menu and a description of their functionality:
|Summary||Provides data within the console showing the overall summary of the current migration status|
|Users||Grid showing information related to users with Active Directory and the PST files associated with them|
|Files||Grid showing details about PST files discovered on the system|
|Module Stats||Provides stats on a per file basis related to the number of items within a PST file that were processed by a module, how many came out, and what the difference between the figures is|
|Ingestion Stats||Provides stats on the number of items failed or migrated by the ingestion task|
|Workstations||Provides a listing of users and the workstations they were seen on throughout the discovery process|
|Comments||Provides a report of all comments made in any part of the product|
|Finalized Users||Provides a report of all completed users, the time of their first upload, time of their last successful ingestion, and a summer of the data migrated|
|Batches||Provides report showing migration statistics groups by the migration priority presently set|
|Failed Items||Reports on the items that failed ingestion. The list is generated when the Post-Processing – Items Details Report step in the workflow runs|
|Schedule Groups||Shows configured scheduled batch groups|
Many reports in this section can also be exported to an alternate format for distribution or use outside of the product. All exporting options are available in the home ribbon of the console window and includes the ability to export to a number of formats. Selection of an export format will prompt you for where to save the file and show you the progress of the export.
Discovery collection is an optional feature that provides legal personnel the ability to select files to be collected for a case. PST files are collected with a six-step workflow.
- Case is defined with legal and technical owners.
- Select users the PSTs are to be collected from
- Select the search criteria for the files
- Confirm the files to be collected
- Files are copied to the uploads directory
- File are moved from the uploads directory to another repository
The options on the home ribbon for the Discovery Collection sub-menu are as follows:
|Refresh||Refreshes the data|
|Add new case||Adds a case configuration|
|Delete case||Deletes an existing case|
|Reprocess case||Reprocesses the case after correcting failure|
The Settings section is not available in the Management Console and can only be accessed by the Admin Console. The options under the Settings section are mostly designed to be configured prior to the start of a production migration and left unchanged through the migration. Changing settings in this section after Migration Agents have been deployed can negatively impact your environment. It is important to understand the impact of any change you make. If you are unfamiliar with the impact a change may have, please contact support for assistance.
The options on the home ribbon for Environment are as follows:
|Refresh||Refreshes the data|
|Save||Saves all configuration data|
|Export configuration||Exports PST Flight Deck configuration to an XLSX file|
Settings for the environment are grouped into several submenus, described as follows:
|Environment||Contains global configuration settings for the PST Flight Deck system|
|Windows Migration Agent||Contains settings for configuration and customization of the Windows Migration Agent in the environment|
|Mac OS Migration Agent||Contains settings for configuration and customisation of Apple’s workstation operating system agent|
|Locations||Contains listing and configuration and options for management of locations|
|Modules||Permits location assignment and customizable configuration options for all modules|
|Workflow||Provides options to enable, disable, re-order and modify execution parameters for a module|
|Profiles||Contains listing and configuration options for management of user profiles|
|Module Editor||Module specific configuration options|
|Scheduled Tasks||Provides management of scheduled tasks used to facilitate a migration|
|Computers||Contains a grid showing all computers and their types identified during discovery, installation and use of the product. Permits assignment of central servers, content scanning targets, and locations for computers identified|
|Provides user and team communication templates and configuration|
|Leavers||Configuration required to migrate users to Office 365 who have left the organization|
The Environment sub-menu contains global parameters for the migration. Some of these values can be adjusted by more granular settings within the product. The Environment sub-menu consists of five sections: General, Advanced, Ownership, Groups, and Roles. These values are discussed in greater detail in the followings sections of this documentation.
The General tab contains three configuration settings. Below is their description and if they are required in a migration:
|Highest priority||Yes||Values used to set the highest migration priority that can be set and have a user still considered to be ‘enabled’ for migration|
|Convert Time to Local Server Time||No||PST Flight Deck maintains UTC time internally, and by default, displays all times in UTC. This option allows times to be displayed based on server time|
|Settings Mode||yes||Allows the changing of module settings based on mode of operation. The modes of operation are Demo, Default, and Self-Adjustment|
The Advanced tab contains general system configuration parameters required for a functional PST Flight Deck environment. The descriptions of the options available and the sections they are contained in are found below:
|Scan Domains||Advanced Mode||Values to narrow scope of an environment to a single or a series of semi-colon separated domains|
|Concurrent Uploads||Advanced Mode||Number of concurrent uploads that can be performed by all Migration Agents|
|Maximum Upload Size||Advanced Mode||Total size of concurrent uploads that can be performed by all Migration Agents|
|Use Regular Expression||Advanced Mode||Option to enable regular expression in ‘Scan Domain’ value|
|Dedupe Timeout||Advanced Mode||Period of time in hours configured to have the Deduplication Module ignore the ‘Wait for All PSTs’ option|
|Discovery Expiration||Advanced Mode||Period of time in days prior to marking discovered PSTs in a ‘Discovery Expiration’ status|
|Failed Item Threshold Warning||Extraction||Number of items permitted to fail extraction prior to a warning being logged and the file status changed to ‘Partially Extracted’|
|Check owner before ingestion||Ingestion||Option to block the ingestion of PST files that have failed to meet the configured ownership threshold criteria but are otherwise prepared for ingestion into the target|
|Failed Item Threshold||Ingestion||Number of items permitted to fail ingestion prior to warning being logged and the file status being changed to ‘Partially ingested’|
|Failback Subject||Ingestion||The subject used for messages created by the Failback feature|
|Failback Body||Ingestion||The body used for messages created by the Failback feature|
|Disable Failback ingest||Ingestion||Option to disable failback messages|
|EV SQL instance||Ingestion||The SQL Server or instance containing the Enterprise Vault Directory database|
|Enable Central Upload||Migration Agent Behaviour||Option to enable the use of the Central Upload Agent|
|Force Migration Status||Migration Agent Behaviour||Optional status that permits central upload|
|Reset Hanging Uploads||Migration Agent Behaviour||Time in hours prior to retrying a file reported to be getting uploaded by BITS|
|Upload PSTs marked for deletion||Migration Agent Behaviour||Option to permit centralisation of files marked as ‘Deleted’|
|Upload PSTs marked ‘Not Owner’||Migration Agent Behaviour||Option to permit centralisation of files with no owner|
|Upload PSTs marked as shared||Migration Agent Behaviour||Option to permite centalization of files marked as shared|
|Re-Queue Deletions||Migration Agent Behaviour||Setting for time delay to delete files when current set user is not logged into a computer but another user is|
|Disk Space Threshold (On, Limited, Off)||Uploads Monitor||Setting a range of options to lessen the risk of an upload directory running out of space|
|Migration Priority||Active Directory Provisioning||The AD group distinguished name of the AD group that controls migration priority when AD provisioning is used|
|Email Priority||Active Directory Provisioning||The AD group distinguished name of the AD group that controls email priority when AD provisioning is used|
|Value||Active Directory Provisioning||Priority assigned to each group|
|Allow self enable||Self Enablement||Option to allow self enablement via the web portal|
|Check mailbox exists||Self Enablement||Option to check if a user has a mailbox|
|Check Size||Self Enablement||Option to check if a user’s mailbox is big enough for the PST data|
|Check License||Self Enablement||Option to check if a user has an Office 365 license|
|Check uploads||Self Enablement||Option to check if uploads is healthy|
|Enabled users count||Self Enablement||Setting that limits the number of users that can be enabled|
|Queue Size||Self Enablement||Setting that limits the number of users that can be queued for enablement|
|Batch Size||Batch migration scheduling||Setting that limits the number of users that can be enabled in a given scheduled batch|
|Check mailbox||Batch migration scheduling||Option to check if a user has a mailbox|
|Batch volume||Batch migration scheduling||Setting that limits the total size of PSTs in a given batch|
|Check uploads||Batch migration scheduling||Option to check if uploads is healthy|
|Default Language||Languages||The default language to be used for all mail communication sent from the product|
|Override Language||Languages||Override all languages regardless of the language specified on the workstation|
|Enable Mailing||Selection to enable SMTP server to be used for project based user communication, notifications, alerts and any other automatically generated email communication|
|SMTP Server||Name of the SMTP server|
|Port Number||Port of the SMTP server|
|Sender||SMTP Address used to send all messages|
|User Name||Optional user name filed for authentication to SMTP server|
|Password||Optional password for authentication|
|Migration Priority and Value||Active Directory Provisioning||Configuration options to enable users through AD group membership|
|Email Priority and Value||Active Directory Provisioning||Configuration options to enable user communication through AD group membership|
The shared scanner tab provides for the management of multiple central file scanner servers. This allows from a centralized location for the management of the file scanner configurations and scheduling. The options on the home ribbon for the shared scanner sub-menu are as follows:
|Refresh||Refreshes the data|
|Save||Save all configuration data|
|Add shared scanner||Presents a list of discovered computers and allow the selection of a shared file scanner|
|Deleted shared scanner||Deletes a configured shared file scanner|
|Export configuration||Exports the shared scanner configuration to a XLSX file|
The Ownership tab is used to define criteria for file ownership determination. There are two main components to the Ownership tab: Weight Table and User In Path.
The Weight Table defines the weights and threshold used in determining PST file ownership. The descriptions of the criteria available and their descriptions are seen below:
|File Owner||The value populating the Owner attribute of the file on disk|
|Scanned Owner||The user running the Discovery Agent at the point(s) of file identification|
|User Name in Path||The sAMAccountName identified in the path where the file is located|
|Most Common Sender||The sAMAccountName seen most commonly as the sender of messages within the PST file|
|Most Common Receiver||The sAMAccountName seen most commonly as the receiver of messages within the PST file|
|Attached to Outlook Profile||The user associated with the Outlook. instance where the PST file was at one point attached|
|Operator Override||Used to define the percentage assigned to manual assignment of ownership within the product|
|Threshold||The percentage value required for a PST file to avoid being blocked prior to ingestion|
|Computer Owner||The owner of a computer where the PST file was identified|
|Custom Owner Property||An attribute that can be associated to an owner and is also present in the metadata returned by the product|
Computer Owner and Custom Owner Property are values that are able to be manually imported so they may be able to be taken into consideration in determining the ownership of a file. As every organization is different, the threshold and weight of the criteria are suggested to be tuned to meet the needs of an organization and project. Generally speaking, a file should require a minimum of three criteria matching a single user until ingesting into that user’s account.
The User in Path section of the tab allows creation of a Regular Expression used to identify a common location of user account names in discovered file paths. Default values are common. Identification of a user’s name in a path can be a good indication of file ownership.
Role Based Web Portal
Groups and Roles enable role based configuration for access to the PST Flight Deck Portal (Portal).
The Roles tab contains two main panes: the Role settings and Current Roles.
Current Roles shows a listing of the currently configured roles in a grid showing its name, the priority assigned to that role, and a description of the role. It includes the ability to edit or delete an existing role as well as to Add a new role.
The Role settings page is where a selected role is configured. Options to configure all that is displayed for the Current role section are available as well as a list of actions that can be associated with a Role. Each action corresponds to a section within the Portal. The Actions presently available, their corresponding section in the Portal, and a description are as follows:
|AccessHelpdeskSection||User Search||Permits the ability to search for a user and returns the details of the current status of their migration|
|AccessReportsSection||Project Status||Provides high level information in several reports summarising the project, the progress over the past day, and the progress of total users|
|AccessProjectManagersSection||Enabled Users||List of enabled users, their name, and the status of their migration|
|AccessIncidentSecftion||Support Tickets||Interface for non-operators to identify, update, and review issues related to the migration|
|AccessBusinessOperationsSection||File Action||Outstanding actions required for the progress of one or more PST files|
|AccessImportUsersSection||Import||Interface for non-operators to import lists of users for association to groups|
Any number of Roles can be created to accommodate an organization’s needs.
Groups are used to associate AD groups to roles and locations. The Groups tab contains two main sections: Group settings and Current groups.
Current groups display a grid showing the currently configured AD Group Name, the Role type associated to that group, and a description for the entry. There are options Edit or delete an existing group, or to add a new group.
The Group Settings section of the tab permits you to configure the entry under Current groups. In addition to the values displayed in the Current groups pane, you can also associate a configured group with a location, and an email for notifications.
Changing the settings in any Role or Group requires the changes to be confirmed and the appropriate section to be saved. Settings will be applied after restarting IIS.
The Admin console has two levels of access – Expert and non-expert. Users are given access via this feature.
Windows Migration Agent
The Windows Migration Agent sub-menu provides configuration options for the settings sent out to all the workstation’s running the Migration Agent for Windows in an environment. Configuration settings are able to be applied to all Windows based Agents or can be customized to suit the needs of an organization by creating several specialized configurations. There are three tabbed menus within the Migration Agent sub menu, all containing a drop down permitting the editing of specific configurations.
The File Scanner tab controls the behaviour of the Discovery Agent portion of the Migration Agent. This section is where you will configure the locations you wish an agent to scan, as well as what you want it to skip. The options available in this tab are as follows:
|Scan Delay||Period of time in hours establishing a range used to determine a random time that a Migration Agent will wait prior to scanning a system|
|Last Scan||Period of time in minutes that must pass prior to initiating another discovery scan on a specific workstation|
|Resident Discovery||Option to enable the Discovery Agent to stay in memory after a scan completes|
|Scan Attached||Enabled attached files, outside of the configuration locations for scanning, to be included in the discovery results|
|Folder Exclues||List of locations where Discovery results should ignored|
|File Name Excludes||List of files where Discovery results should be ignored|
|Path||List of locations configured for scanning by Migration Agents|
Additional configuration options are available when creating or editing a location for scanning. Scanning location specific folder and file exclusions are available to enable a granular level of exclusions. Options to scan removable media and substituted Paths are also available on a per location basis.
The Agent tab contains configuration options related to the Agent portion of Migration Agent running on Windows workstations. This component of the Migration Agent is responsible for querying the PST Flight Deck Core service and getting information back from it. It is also responsible for managing the user experience during a migration by providing pop-up menus to engage a user in their data’s migration. The Agent also reports attached PST files that are not in a configured scanning location to the server and disconnecting PST files from profiles when appropriate.
The “General” section of this tab permits you to choose if a migration will be performed in Snapshot or in Disconnect Mode. Also in this section is the configuration for the “Polling Interval”. This value should be set as is appropriate for the number of Migration Agents deployed in an environment. The larger number of agents reporting to a server, the longer a polling interval should be set to.
The “System Tray” section contains customization on how you would like the Agent to be represented on a user’s workstation. The options available for selection/deselection are as follows:
|Disconnect / Snapshot mode||General||Select disconnect or snapshot mode|
|Silent Migration||General||Option to enable silent mode for the migration|
|Pop Postpone Delay||General||The time in days before a user who postponed their migration will natively wait before being prompted for action by the agent again|
|Max Postpone||General||The maximum number of days a user can postpone|
|Polling Interval||General||The number of minutes for polling|
|Suppress Complete Pop Up||General||Option to prohibit Migration Agents from reporting when PST files have completed processing|
|Complete Pop Up Once Finished||General||Option to report a final pop-up once all identified PST files for a user have completed processing|
|Show Password Protected Info||General||Shows password protection information in the agent pop-up|
|Show in System Tray||System Tray||Enable display of Migration Agent in a system’s notification area|
|Progress||System Tray||Shows upload progress of PST files|
|Manual Select||System Tray||Permits a user to manually select and start the upload of PST files|
|Send Log||System Tray||Enables option to permit users to initiate a request to send local log files to the server for review|
|Mail Log||System Tray||Enables options to permit users to create a new mail message with log files attached to it|
|Show Log||System Tray||Enables option to open the Migration Agent log file|
|Exit||System Tray||Enabled option to exit from Migration Agent via the icon in the notification tray.|
The Advanced section of the Agent tab has additional options governing some functionality within the Migration Agent. Some of these settings aid to manage the user experience during a migration. The options available under the advanced section and a description of their function are as follows:
|Auto Update||Enable push of updated Migration Agent to workstations|
|Update Version||Specification of the version to be pushed to the Migration Agent|
|Snapshot Speed||Enables the ability to limit the speed a snapshot is created on a workstation|
|Initial Sleep||Value representing the delay of time for Agent actions to be initiated after user log on|
|Agent Sets Registry Keys||Enables the ability to set required registry keys for a user on a workstation once they are enabled for migration|
|Disable users using PST files||Enables the ability to disable the use of PST files for a user on a workstation once they are enabled for migration|
|Disable Completed Users using PST files||Enables the ability to disable the use of PST files for a user on a workstation once they have completed migration|
|Display User Action for Initial Status Only||Display user action only for files that are discovered|
The Duplicate Files section of the Agent tab has settings that control processing for duplicate files. Likely duplicate files are defined as files that have the same last modified date and the same name. Options available under the advanced section and a description of their function are as follows:
|Resolved Likely Duplicate Files||Process only one file if duplicates are found|
|Delete Duplicates without Uploading||By default, duplicate files are uploaded and deleted from the source. This option prevents the uploading|
The Upload Limitations section of the Agent tab has settings that aid in determining if uploads are being attempted over a slow network connection, eg, a VPN. Options available under the advanced section and a description of their function are as follows:
|Minimum Adapter Speed||Uploads pause if the adapter speed is lower than the set value|
|Minimum Upload Speed||Uploads pause if the uploads speed is lower than the set value|
|VPN adapter description||Uploads will pause if the VPN adapter description contains the text in the setting|
The Language tab permits customization of the language, contents, and options contained within the prompts displayed on user workstations. This permits better support for customers with multi-lingual or compartmentalized organizations. It is recommended to copy all contents in the edit window prior to changing the defaults.
The Bandwidth limitations tab provides for the management of upload bandwidth limitations, which are defined by IP address. If a workstation has an IP address within a range that has a limitation, the BITS bandwidth utilization is limited to the set bandwidth. The constraint can also be limited to certain times of the day. For example, an office may require low speed BITS uploads during the day but can have higher speeds at night. The options on the home ribbon for the Bandwidth limitations sub-menu are as follows:
|Refresh||Refreshes the data|
|Save||Saves all configuration data|
|Add limitation||Adds a bandwidth limitation configuration|
|Delete limitation||Deletes a configured bandwidth limitation|
Mac OS Migration Agent
The Mac OS Migration Agent sub-menu provides configuration options for the settings sent out to all the workstation’s running the Migration Agent for Mac in an environment. Configuration settings are able to be applied to all Mac based Agents or can be customized to suit the needs of an organization by creating several specialized configurations.
The options on the home ribbon for the Mac OS Migration Agent sub-menu are as follows:
|Refresh||Refreshes the data|
|Save||Save all configuration data|
|Create Config||Creates a new configuration file|
|Edit XML||Edits existing configuration file|
|User Licenses||Display the status of the workstation license|
|Manage Users||Wizard to allow matching Mac users with AD users|
|Work item interval||How often in minutes the agent will look for work to do|
|Config Interval||How often in minutes the agent will look for configuration changes|
|Scan Files Interval||How often in minutes the agent will scan for new data to process|
|Silent Migration||Option to enable silent mode for the migration|
|Max Postponement||The maximum number of days a user can postpone once they are enabled for migration|
|AllowExit||Option to show Exit option on workstation|
|Registration Key||Unique key required to process Mac data|
|Path Excludes||Includes the paths to exclude from file scanning|
|Search Paths||Includes the path to scan for files|
The Locations sub-menu offers the ability to manage complicated migration environments. They permit work to be assigned into geographically appropriate groupings.
The options on the home ribbon for the Locations sub-menu are as follows:
|Refresh||Refreshes the data|
|Add||Adds a new location|
|Edit||Edits an existing location|
|Transparent Central Upload||Configures transparent central upload|
Options available during Location creation or modification are as follows:
|Name||Desired name of location|
|Description||Brief description of the location|
|BITS Upload URL||URL path, including port number, used by agents to centralise PST files over BITS|
|Upload Location||UNC path used by modules to access content from the share associated with the BITS upload URL|
|Re-ingest Location||Path or Azure storage connection string specified for the Re-ingest process to obtain content for consecutive modules|
|Unpark Location||Path where ownerless PST files are located when parked|
|Concurrent Uploads||The number of simultaneous uploads that can be performed by all Migration Agents|
|Maximum Upload Size||The total size of concurrent uploads that can be performed by all Migration Agents|
Each location can be configured to specify a peak and limited rate for Concurrent Uploads based on disk availability. These values are designed to reduce the risk of consuming all available space on the upload location.
Locations enable an organization to centralize and process PST files in data centres close to the users, their data, and their target system.
Transparent Central Upload
Transparent Central Upload is a feature to enable better integration for the Central Upload Agent (CUA) with transparent migrations. Unlike an Agent running locally, the CUA has no ability to detach and snapshot files presently accessed by a user.
Enabling Transparent Central Upload ensures that all active Agents on the user’s workstations have validated the existence of the required registry keys or has set them prior to permitting the CUA to upload data on a remote resource. Transparent Central Upload also has the capability to schedule the period of time where it will attempt to centralize targeted files. This enables an administrator to schedule centralization of these files during a time when they will be less likely to be accessed.
Provides a list of all registered modules in the environment and the last time they checked into the server. Data is returned in a grid format with selectable and filterable results. Where appropriate, location specific configurations can be used to accommodate the needs of that location.
The options on the home ribbon for the Modules sub-menu are as follows:
|Refresh||Refreshes the data|
|Set Location||Permits assignment of a module to a location|
|Add Server||Permits the ability to add and configure the type of Central Upload Agent identified|
|Delete Server||Permits the ability to remove the configuration of Central Upload Agents identified|
|Log Level||Changes the logging details|
The Workflow sub-menu permits the enablement and order that the PST Flight Deck modules will be processed. The configurations can be made per location, selectable by the drop down at the top of the grid. This area permits you to enable or disable modules, permit certain modules to be skipped if a file fails successful processing by that module, how long to wait prior a file being eligible for processing by that module, or if processing should begin after all the files have been successfully queued for that task.
The options on the home ribbon for the Workflow sub-menu are as follows:
|Refresh||Refreshes the data|
|Up||Moves a workflow step up|
|Down||Moves a workflow step down|
|Edit||Edit the settings for a given step in the workflow|
|Clone||Clones an existing workflow|
When Edit is selected a popup will appear that has the following options/settings:
|Skip if Failed||Option to allow the workflow to continue if a given step fails|
|Enabled||Enables the workflow step|
|Wait for All Files||Option to wait for all files to complete a certain step before moving on to the next step in the workflow. This is used mostly for deduplication|
|Don’t check for Location||Option to ignore location information for a given step. Used mostly for source file remover|
|Delay in minutes||How long the step waits before it is executed. Used mostly for the source file remover|
|Timeout in minutes||Length of time the steps waits for completion for a given file. The step is restarted for a given file after this timeout.|
|File is attached||Option to process a file if it is attached to Outlook or not|
|File types to process||Options to select the types of files to process in a given step|
The Profiles sub-menu offers the ability to add and configure assignable user profiles. They are used to permit an alternate configuration for users associated with them and enable the assignment of unique File Scanner, Agent, Language, and Location configurations. Not all migrations require additional profiles but they are provided to enable support of complex environments where a migration project is taking place.
The options on the home ribbon for the Profiles sub-menu are as follows:
|Refresh||Refreshes the data|
|Add||Creates a new profile|
|Edit||Edits an existing profile|
|Delete||Deletes an existing profile|
Options available during profile creation are as follows:
|Name||Desired name of profile|
|Description||Brief description of the profile|
|File Config||File scanner configuration associated with the profile|
|Windows Agent Config||Windows agent configuration associated with the profile|
|Agent Language||Language configuration associated with the profile|
|Location Name||Location associated with the profile|
|Workflow||Workflow associated with the profile|
|Mac OS Agent Config||Mac agent configuration associated with the profile|
The Module Editor permits module specific configuration to be set down to a location level. Locations are specified by a drop box at the top of a tabbed interface. All modules enabled have configuration options exposed in each of the tabs. Configuration settings assigned here can be overridden using the Custom Settings option in the Module Settings sub-menu.
There are several settings which are seen over most or all of the modules within PST Flight Deck. The following table provides a description of these configuration options:
|Location||Drop-down at the top permitting selection of location for the site specific module configuration defaults|
|Number of Threads||Number of instances of the modules functionality which are configured to run simultaneously|
|Update Interval||Time the module waits between queries to the core for more work items|
|Number of work items||The total number of requests for work a service will queue at a time|
|Storage Locations||Specification of the storage area used by the module|
Some modules also permit the ability to assign a cloud connection string for a storage location to support Azure nodes.
Some modules have configuration options that are specific to them. The following section discusses these options.
To ensure maximum efficiency of the Repair module, it is recommended that it be installed on the same machine as the Extraction module and the BITS upload location. When the Repair module is on a location local to the BITS upload location, there is special configuration required to enable the repair request to use the local path rather than a UNC path. Enabling this configuration has shown to produce a substantial performance gain for the repair module.
The extraction module is a powerful module that performs several tasks during the extraction process. This functionality requires many additional configuration options that are specific to it. The following table provides a description of these options:
|Generic Filter||Enables filter criteria to be provided that applies to all items in the PST file|
|Notes Filter||Enables filter criteria to be provided that applies to email based message classes|
|Appointment Filter||Enables filter criteria to be provided that applies to appointment based message classes|
|Filter Deleted Items||Option to filter items in the Deleted Items folder|
|Enable Replace||Permits the ability to convert message classes of an item during extraction|
|Keep Items only in IPM Root||Enabled ability to remove items in an area of the PST which is inaccessible in target systems|
|Source Type||Original message class desired for conversion|
|Destination Type||Message class intended for the value specified in ‘Source Type’ to be converted into|
|Enable Content Scanning||Enables the ability to identify most common sender and recipient in extracted PST files for better owner recognition|
|Encoding for ANSI files||Selects regional ANSI encoding|
|Skip Password Protected||Option to skip extraction for password protected files|
The Extraction module is also able to filter data from PST files when that content is not desired or known to be unsupported in a target system. Filtering items will remove items based on how they match the specified criteria and these items will not be migrated to the target system. Filters will be applied to the scope of the area they are placed. For example, filters placed in the “Appointment Filter” filed will only apply to message classes associated with Appointments.
Filtered content is written to the specified “Filter Location”. The following is a list and description of properties PST files can be filtered by:
|MessageClass||Property of a message which identifies the type of message it is|
|Created||The creation date of a message|
|Subject||The subject of a message|
|ReceivedBy||The name, email address, or distinguished name of the user who received the message|
|Sender||The name, email address, or distinguished name of the sender of a message|
|ModificationDate||The last modified date of a message|
|Size||The size of a message|
Filters are case sensitive when applied. Its syntax can be built using the properties above and standard C# string methods. These methods are appended to a property and applied against the value of that property. If you wanted to find a property containing the value of “xyz” you would append .Contains(“xyz”) to the name of the property.
For more information on C# string methods and the options available for filtering, please refer to the MSDN site on the topic.
The following example on how to filter messages types by message class can be used if Enterprise Vault shortcuts are desired to be excluded from a migration:
The following example shows how to exclude all items older than a year from being migrated:
item.Created < DateTime.UtcNow.AddMonths(-13)
This final example shows a filter designed to remove items larger than 25 MB from being migrated:
This tab contains configuration settings for the duplication function. By default, Dedup examines, and dedupes, mails items within a PST and mail items between multiple PSTs. The settings unique to this tab are described as follows:
|Hash Storage Location||The drive path of where the calculated hash values are stored|
|Limit to other Files only||Allow deduplication only between files|
Office 365 / Exchange
This tab contains configuration settings for the ingestion into Microsoft targets such as Office 365 and Exchange servers. PST Flight Deck uses the Advanced Ingestion Protocol (AIP) as a primary ingestion method into Microsoft targets. The settings in this tab control the behavior of this module and permit the ability to tune these settings to get the best performance possible. The settings unique to this tab are described as follows:
|User Sync||Permits Office 365 user synchronisation in multi-tenant environments|
|Subfolder name||The location created or used in the target mailbox where all content migrated is placed into|
|Unique subfolder names||Enables files with the same display name to have unique folders created for each PST file ingested|
|Ingest by Age Filter||Set a date filter for ingestion|
|Autodiscover Override||The URL that should be resolved by a proper functioning Audodiscover system|
|Exchange Version||Enables specification of the version of Exchange the EWS API is expecting to communicate with, as required in early API versions|
|Disable Certificate Validation||Permits use of unsigned and untrusted SSL certificates when communicating over HTTPS to the target system|
|Disable Past Reminders||Removes reminders for meetings and calendar items that occurred in the past|
|Tracking Information||Applies hidden metadata about the migration to items written to the target system|
|Folder Types||List folder types of tasks, calendar, and contact|
|Update Retention||Enables the ability to set a retention policy tag in the target system at the Top Folder level or on all items|
|Retention Policy Tag||The policy in the target system that is expected to be applied to migrated content|
This tab contains configuration settings for the ingestion into Enterprise Vault targets. PST Flight Deck uses the Enterprise Vault API as an ingestion method into Enterprise Vault targets. The settings in this tab control the behaviour of this module and permit the ability to tune these settings for the desired results. The settings Unique to this tab are described as follows:
|Retention Category||The ID or name of the Retention Category content is to be stored under|
|Subfolder name||The location created or used in the target mailbox where all content migrated is placed into|
|Unique subfolder name||Enables files with the same display name to have unique folders created for each PST file ingested|
|Ingest by Age Filter||Sets a date filter for ingestion|
|Tracking Information||Applies hidden metadata about the migration to items written into the target system|
|Create Shortcuts||Enables the ability to create Enterprise Vault shortcuts in Exchange targets for migrated content|
|Shortcut Filter||Option to filter shortcuts that are created. Create shortcuts must be enabled.|
EV Shortcut Rehydration
This tab contains configuration settings for the identification and restoration of Enterprise Vault shortcuts identified within PST files. The settings in this tab control the behaviour of this module and permit the ability to tune these settings for the desired result. There is only one unique value in this tab. The Item Ingest Parallelism is used to determine the number of items requested for rehydration per pass per thread of a running module.
This tab contains configuration settings for the cleanup module. The settings in this tab control the behaviour of this module and permit the ability to tune these settings for the desired result.
|Move Location||Select local or cloud storage|
|Local Location||Sets the local storage path for cleanup data|
|File Statuses to Delete||Sets the status codes of files to be deleted during cleanup. The default value is status 2400 (Deleting)|
This tab contains configuration settings for the Leftover module. The Leftover module copies non-ingested data to a file share or OneDrive. The settings in this tab control the behaviour of this module and permit the ability to tune these settings for the desired result.
|Destination||Select share (eg c:\, e:\ or UNC path) or OneDrive|
|Subfolder name||Creates a subfolder in the destination|
|Flat Structure||If checked, all leftover data is saved in the destination with no folder structure|
|Unzip||If checked, individual leftover mail items will be stored. If unchecked, zipped items will be stored|
Scheduled tasks sub-menu permits review and management of regular activities required in a migration. The interface shows all tasks available to the system and the time they are last run. You can execute the tasks now or you can change the configuration of a given task to run at specified times. Tasks can also be scheduled to execute on a regular interval and run continually.
The Scheduled Reports sub-menu permits management of schedule report configurations. Scheduled reports are run periodically and are made available through the web portal to users who subscribe to the report. The reports are created by running defined SQL scripts and are saved as CSV files. Subscribed reports are emailed to the subscriber as ZIPed files.
The options on the home ribbon for the Scheduled Reports sub-menu are as follows:
|Add||Creates a new report definition|
|Delete||Deletes an existing report definition|
|Edit||Edits an existing report definition|
The options available in the report configuration are:
|Name||The name of the report|
|Description||Description of the report|
|Mail Template||The name of the email template used for emailing subscribed reports|
|SQL query||SQL script to generate the report|
|Schedule||Schedule for executing the query|
|Day of Month||Select day of month for monthly reports|
|Report Enabled||Option to enable/disable the report|
The Computers sub-menu provides a grid of data showing all machines seen in the environment. The data returned also includes all computers where content was discovered. Computers can be assigned to specific locations, be designated as “Central Servers” so the Central Upload Agent uploads the content on it, and can be flagged to have the content of the files identified on that machine scanned for sender and recipient information. Should it be appropriate, comments can be added, displayed, or managed for computers identified within the environment.
The options on the home ribbon for the Computers sub-menu are as follows:
|Refresh||Refreshes the data|
|Set||Central Servers||Sets servers to act as a central upload server|
|Unset||Central Servers||Unsets servers acting as a central upload server|
|Set||Content Scanner||Sets servers to act as a content scanner|
|Unset||Content Scanner||Unsets servers acting as a content scanner|
|Add||Comments||Add comments for a selected computer|
|Show||Comments||Shows comments for a selected computer|
|Close All Comments||Comments||Close all the comments for a selected computer|
|Set Location||Location||Assigns a computer to a specific location|
|Import Owners||Computer||Imports CSV file of computer owner information to be used in ownership calculations|
|Admin File Scan||Computer||Forces a file scan on a computer using the agent service to find files that the logged in user doesn’t have rights to|
The Email sub-menu contains templates and configuration related to all email messages sent from the PST Flight Deck environment. These messages include templates for the various stages of a migration project a user goes through, as well as notification emails that are sent to PST Flight Deck team members responsible for portions of the migration. The grid seen in this section displays the template names and the type of email communication they are. All templates can be tested by selecting the applicable message, hitting the Test button on the ribbon, and providing the requested information.
There are two types of email communication in PST Flight Deck. The first type is “Batch” email messages. Batch Email messages are triggered manually by the PST Flight Deck Administrator by highlighting the applicable message and selecting the Batch Mail button on the ribbon. The resultant window will ask the email priority range that you would like to send the message to and have a button to send the messages. This will queue messages for delivery during the next scheduled send.
Automatic templates are sent when conditions for a user have been met. They can be configured to only be sent after a specific time and have a robust rules system that can be used to develop the conditions under each mail being sent. After enabling a template, the rules are evaluated regularly upon execution of a scheduled task. When the conditions match, the message is queued for delivery during the next scheduled sending of content within the queue; then is logged as having been sent. Automatic templates can also be configured to only be sent once.
Templates can be edited within the XML initially provided after launching the Edit button, or can be edited using the WYSIWYG button to launch a rich text graphical editor. If using the graphical editor and the communication requires images to be included, special consideration is required. After editing a template, it is encouraged to test the message prior to using it in production.
The options on the home ribbon for the Email sub-menu are as follows:
|Refresh||Refreshes the data|
|Add||Templates||Adds a new email template|
|Edit||Templates||Edits an existing email template|
|Delete||Templates||Deletes an existing email template. Only user defined templates can be deleted|
|Batch Mail||Templates||Queues email for batch delivery|
|Test||Templates||Sends a test email for a selected template|
The Leavers O365 sub-menu contains the configuration required to leverage PST Flight Deck to add orphaned PST files into your target system for compliance or legal search. The grid of this tab shows the licenses available for the environment and permits the designation of the number of licenses that will be used to facilitate this functionality. The options available help to define what the naming convention used to create new archives in the target will be, the usage location, email domain associated with the tenant, and the ability to set and configure legal holds against the migrated content.
Event rules engine
The Event rules engine option provides for the development and maintenance of workflows that define how various events are processed. Each event processed is given a threshold for the number of times an event happens before the action steps are taken. With this engine, you can define actions to take and notifications to be sent. Automatic actions such as agent reset can also be configured.
The steps to create an evet rule are:
- Add workflow
- Add a rule that triggers the workflow
- Add steps to be taken once the rule is satisfied
The options on the home ribbon for the Event rules engine sub-menu are as follows:
|Refresh||Refreshes the data|
|Add workflow||Workflow settings||Adds a new rules workflow|
|Edit workflow||Workflow settings||Edits an existing rules workflow|
|Delete workflow||Workflow settings||Deletes an existing rules workflow|
|Edit rule||Workflow settings||Edit existing rule within a workflow|
|Add step||Workflow settings||Adds a step to an existing rule|
PST Flight Deck has a role based web interface designed to deliver information or decision-making authority to those in the organization who require it. The PST Flight Deck Portal (Portal) empowers the PST Flight Deck team to be able to do what they need to, when they need to, without requiring Operators, Administrators, or Architects to intervene. The result is a streamlined migration project with the proper team members being enabled and notified when appropriate for them to resolve the present issue. Throughout the Portal, selecting the Help icon can provide contextually relevant information to you when needed.
Actions, Roles, and Groups
Actions are used delegate access to specific roles. Each action correlates with a feature of the Portal. Actions can be used to grant as much access is necessary to a given role.
Roles can be created as are required and be built to suit the needs of the project. For a smaller project where limited resources are engaged throughout the entire project, one role for all the actions may be sufficient. Larger organizations may wish to create more roles for a higher degree of permission segmentation. For example, an organization may permit a help desk role to see details about a user’s progress, but not wish for them to see information related to the project as a whole. Roles can be prioritized to resolve rights assignment when a user is a member of multiple roles.
Groups are used to associate AD groups with Roles and Locations configured. This enables the ability to create project groups of users that are managed within AD and associate them with the role types created. Groups also have the ability to associate an email address for the product to email the group it is affiliated with when action items are required.
The combination of these three components creates the security configuration for the role based Portal administration.
There are several Portal components associated with an Action and available for assignment. Each Portal component is created with the goal to resolve a project need. The following discusses the functions of each of the available components of the Portal.
This component provides a handy utility to search for a user or account name and return information about the current status of that user. This utility is frequently helpful for a help desk or equivalent group who receives initial calls from an organization’s users for questions concerning the migration project. The interface can provide information on the user and each of the PST files associated with the users. Initially, it provides an overview of that user’s migration. Details can be obtained by drilling into the info button against the user or any of their files. The User Search is associated with the AccessHelpdeskSection Action under Settings > Environment > Roles of the Admin Console.
The user search is also leveraged as a resource for users to see the progress of their personal migration. Appending “SelfService” to the UserSearch page will return the user page for the authenticated user. This portal may be included in project FAQ’s or communication to the user as a method to keep users informed as to the progress of their migration, while lessening the burden on teams supporting the migration. There is no Action associated with this function, but any user from the domain scanned by the product can view their migration’s status and progression by accessing the Self-service portal.
An example of the URL used to access this page is as follows:
This component of the Portal is about empowering the proper team members be able to resolve issues related to the migration without requiring the PST Flight Deck Administrator or Operator’s engagement. PST migrations are complicated projects that involve many groups of the business to get the job done. The File Action component of the Portal presents issue specific web wizards to walk users through remediation of an issue with a file.
Take the following example. A file is being migrated that is presently destined for UserA’s archive, but the product has not been able to gather sufficient information to ensure that the file belongs to that user. PST Flight Deck has a configurable ownership certainty threshold and the ability to block files from being ingested which do not meet that minimum criteria. UserA’s file was blocked from ingestion while someone manually approves the ingestion. If a file is blocked because of such an issue, the help desk could call the user to confirm that the data is theirs and they would like it migrated. Rather than communicating the decision back to the PST Flight Deck Administrator or Operator, the help desk personnel could resolve the issue themselves via the File Action feature of the portal.
The File Action component of the Portal is associated with the AccessBusinessOperationsSection Action under Settings > Environment > Roles of the Admin Console.
PST Flight Deck has the ability to create, manage, track, and update project related support tickets for a specific user, file, host, or event. This feature enables Operators or other team members to be able to address the largest concerns of a migration, as well as track progress against problematic files. This product feature enables project management groups to streamline the troubleshooting and issue resolution associated with the project for a reduced impact to its end users. The Support Ticket portion of the portal is associated with the AccessIncidentsSection Action under Settings > Environment > Roles of the Admin Console.
The project status reports are a series of reports designed to enable appropriate team members access to the data that is important to them. An Operator may wish to know what the progress day over day is while the Project Manager may want to see an overview of the entire project. There are three reports provided over the Portal to help to determine the status of a project.
The “Project Overview” report provides a high-level progress report on the number or volume of files Completed, failed, and remaining over a configurable period of time. This is a good measure to determine the current progress of the project and how far into it a migration team is.
The “Daily Progress” is a useful report to determine at a glance that everything is working as expected. It provides daily ingestion rate information for the past 24 hours. This can help you determine if more users need to be enabled and if you are maintaining the anticipated rate of ingestion through each day.
The “User Progress” report provides metrics on the number of Users with PST files identified and statistics related to them and their progress through the migration work-flow. These charts help to understand the nature of the PST problem identified and what the product is doing to resolve it.
The Project Status portal reports availability is controlled by the AccessReportsSection Action under Settings > Environment > Roles of the Admin Console.
The “Enabled Users” report provides a list of all the users enabled for migration. It provides some high- level information related to their current status and progress, and a link back to the User Search page for that user. Its access is governed by the AccessProjectManagersSection Action under Settings > Environment > Roles of the Admin Console.
The import feature empowers an Operator to delegate the creation of waves to project managers or other members of the business without the requirement of granting access to a Console. The feature’s accessibility is controlled by the AccessImportUsers Action under Settings > Environment > Roles of the Admin Console.
The operation of a PST Flight Deck environment is something that requires daily effort and monitoring to ensure optimal throughput. Rate of centralization, rate of upload, size of available disk space, and module backlogs are just a small number of the areas of concern for a PST Flight Deck operator. A failure to perform near daily operation activities could result in a large backlog of work to be performed.
Operational activities can begin at the point of agent deployment when the Discovery process begins and information related to ownership and scope of the PST problem an organization is facing begins to become clear.
After a PST Flight Deck system is installed, there are some common steps that are taken through a project. For information related to the requirements or deployment of a PST Flight Deck system, please refer to the appropriate guide. A PST Flight Deck system must be configured and tuned appropriately. Best practices to maintain a computer operating system and a SQL database are recommended. Insufficient or contention for available resources will negatively impact the entire PST Flight Deck environment. A common area neglected in a deployment is the SQL database.
In a freshly deployed environment that has a limited number of controlled agents, PST Flight Deck can be configured to expedite testing. Once appropriate, an end to end test is recommended to ensure all components of the system are properly functioning.
Typically, an initial end to end test is done with the default configuration options enabled. Once confirmed to have been successfully completed, the system should be configured to the design of the project and consecutive testing performed. Changing settings once the Migration Agents are deployed may have undesired results.
After end to end testing is completed, it is important to evaluate and configure acceptable threshold values for extraction and ingestion failures. Doing so will prevent the review of every PST with one or two failures and permit an Operator to focus on larger areas of concern.
Once configuration and testing have been completed, the Migration Agent will need to be packaged and tested for deployment. This is frequently done on a small group of users close to the PST Flight Deck team. If the deployment installation went as expected and the workstations can be seen reporting back to the PST Flight Deck server, the system will need to be less aggressively configured to accommodate the added communication from the agents.
At this point you can begin the deployment of the agents to the remaining workstations in an environment. The business pilot will consist of the users who tested the agent package deployment and will provide an opportunity to begin to see bottlenecks within the environment. Tuning the system to a balance of resource consumption and performance is frequently initiated during the business pilot because it is the first time in a project that the system could be busy enough to maximize the performance of the system. Other pilots may wish to be performed depending on the results of initial pilot attempts.
Discovery and Owner Management
After deployment of the Agent to the remaining workstations occurs, the discovery of PST files begins. It is suggested to let this process run until the number of discovered PSTs starts to level out. In smaller projects this may take three or more weeks. Larger projects may take longer.
During the discovery process and through its completion, it is suggested that Operators focus their efforts on ownership identification through the options within Manage > Owners. Accurate and complete ownership identification is one of the challenges in PST migration projects. PST Flight Deck is able to provide suggestions as to ownerships immediately following the initial discovery results being returned. Aggressively managing ownership of files during the discovery phase of a project will drastically reduce the challenges and time needed to manage file ownership at later phases of the project.
The number and volume of PST files may continue to grow as your migration continues, but when discovery is nearing the end, consistently sustained growth can be seen week over week. At this point waves of users can start being prepared for migration. Typically, this initially involves ensuring communication has gone out to impacted users and enablement groups have been defined for the migration.
The Ramp-up phase implies growing the wave sizes until waves are keeping the system busy with available disk space and mostly completing them in the desired wave interval. Setting the Migration Priority for a wave of users enables them for migration. Commonly, a unique priority value would be set per migration wave. Daily monitoring is required at this point of the migration. Monitoring should consist of the environment, the active wave(s), and those users’ files until mostly completed. Remediation and reprocessing of some PST files or items may be required for the wave to fully complete. In addition, module tuning to achieve more performance within the limitations of the environment should also be performed during the initial monitoring and growth of migration waves.
You do not have to wait for a wave to be entirely completed prior to starting the next wave. The goal of an efficient migration project should be to minimize backlog but ensure enough work to have the environment persistently working. This typical bottleneck in a migration work flow is typically the extraction module but could be other areas if certain environmental factors dictate it. Keeping a system busy requires persistent uploads and consistent ingestion to ensure there is enough work to keep the system working at its fullest capacity without running out of available disk space.
As users complete, an Operator may choose to move their migration priority to a disabled value. This permits control over future discoveries for the user. Backup files are frequently kept for a determined period of time after a user has completed the migration. This location, and all other module’s storage locations will need to have content removed when appropriate. When a user or the migration completes, it is recommended that those users have the DisablePST registry key set on their workstations to reduce the re-introduction of PST files after a user’s source files have been removed.
Stages of a Migration
During a migration, both users and files are progressing through a workflow. Each stage of the process has specific results indicating what has happened to the file. Stages are used to describe the phases of this process so that an individual can tell the status of a user or a file at a glance.
The user workflow stage is complex and are calculated by the server on an hourly schedule. The displayed status may not correctly reflect the current status of the user. This is normally not an issue as the status of a user does not change that fast. Below is a list of stages used to describe the status of a user:
|0||No actions have been taken against the user or the user has a disable ‘Migration Priority’ set|
|1||User is enabled for migration|
|2||All of an enabled users files have had expired discovery conditions met or have had actions taken against them|
|3||User has started uploading PST files to the server|
|4||All files in scope are in a completed status|
|5||All of a users PST files have fully completed the workflow|
File stages are current, up to the minute, for a specific file. The following are the stages of file processing:
|0||File has been discovered but no actions against that file have been taken yet|
|1||Owning user is enabled for migration and is eligible for actions to be taken against the file|
|2||An action has been taken against the file|
|3||File has been queued by the agent for centralization|
|4||File has been centralised to the desired location and is ready to be processed by the modules|
|5||Modules have begun to process the file|
|6||The file is ingested into the target|
|7||All workflow operations have completed for this file|
The primary goal of a PST Flight Deck is to move PST files from a dispersed location and ingest them into a centralized location. Files are considered “Complete” when the need to ingest the file has been satisfied. This is most commonly due to complementing a successful ingestion of a file, however can also be achieved by a file being in a status that does not get ingested (Deleting, Not a PST File…..). Files or users can be considered “Complete” but still have modules in the workflow that have not competed.
Issues do happen! When they do it is important to be able to identify that a problem did occur, the nature of the problem, and what actions need to be taken to remediate the problem. While investigating, it is encouraged to note the steps of your investigation through the PST Flight Deck comment system. This will enable you to easily see when an issue with a file is recurring and the approach being taken will need to be reviewed.
There are many difficulties that can happen in PST migration projects. Being able to identify when a problem is happening at the client vs. the server or which module a failure took place in can expedite the ability to identify the problem and promptly resolve it.
Monitoring the migration is a common way issues are identified. When migration priorities are set for a group of users, a certain expectation of their progress accompanies their enablement. As users or files begin to lag behind the remaining users or files, an Operator will look into why. Frequently this is where issues, the point of their failure, and steps for remediation are identified. Quickly reviewing the appropriate grid can tell you if a user is not logging on, if the upload has completed, if a specific process has failed for a file, or if the user has fully completed their migration. Without monitoring your system, some issues may just not be found.
Most issues log entries in a console under Manage > Events. For most migrations, it is suggested to use this window as a sort of running tally of outstanding areas to investigate in a migration. Most events imply an issue which requires some actionable correction. Acknowledging events whose investigation has completed or have been resolved permits an Operator to have an easy view into what is wrong and what still needs resolution or investigation. Many issues identified by monitoring and review of exceptions can more easily be identified through the Events sub-menu.
Exceptions are instances of failures of some functionality within the product. Mostly identified via monitoring or event review, some level of exceptions occurs in every migration. The details of the exception provide a reason why the exception occurred. If you are able to identify a specific exception, review of the events, Console, or logs will help to better understand the nature of the failure. Log excerpts and collection are typically required for support tickets involving exceptions.
Backlogs are mostly identified by review of the Operations or Files sub-menus. Backlogs can indicate an issue with the environment’s tuning, exceptions, or services which are not running. Backlogs take place after a file has been centralized and it is already located on the local machine. The modules responsible for processing these files may have more work than they are able to process in the time allocated. Additional sizing or tuning may be required to eliminate the bottleneck and get the system caught up again. Bottlenecks not investigated or resolved are likely to recur as the migration continues.
Point of Failure
When discussing details about an issue, a common area of interest is the “point of failure”. This is the exact point in time that the issue occurs, where it occurs, and under what conditions. The idea of determining the point of failure is to ultimately find a means by which to reproduce the issue being observed. Once any issue can be reproduced on demand, it is infinitely easier to work towards a solution. For troubleshooting, the identification of a point of failure means that we are able to reproduce the issue, collect applicable logs, sample items, and make assessments on if the issue is environmental or not. In most instances, we can collect samples that are provided to our Support team for analysis. This frequently expedites the troubleshooting of an issue and results in a drastically shortened time to resolution.
PST Flight Deck has very robust logging features that enable administrators to effectively troubleshoot problems. There are two categories of logs – agent logs and server logs. Agent logs are generated by the Migration Agent and are stored on a user’s computer. Agent logging is enabled by default. Server logs are generated by the various PST Flight Deck modules and the Core. Server logging is disabled by default. To learn how to enable logging in PST Flight Deck please visit use this on the topic.
The Windows Migration Agent has two components, the discovery agent and the migration agent, and both components generate logs. The logs are stored in %temp%\Quadrotech\. Both logs can be retrieved from a workstation using the Request Client Logs feature in the Admin Console. If enabled, a user can elect to send logs to the server using the Send Log feature of the Migration Agent.
The Discovery Agent log is written to a file named FileScanner_hostname.log. The log will not be created if there are no warning levels. There is rarely a need to change the logging level but you may be directed by Quadrotech support to change it for troubleshooting.
The migration log is updated every time the agent polls or every ten minutes when the agent checks for configuration changes and its name is MigrationAgent.log The Migration Agent log records items such as routine polling results, user enablement status, error conditions, work items to be processed, etc.
Server logs are used to log all routine work and errors conditions. They are extremely important for troubleshooting problems that occur with modules, consoles, the portal, and all client/server interactions. There is a log for every running PST Flight Deck service, the Admin console on the core server, and the web interface. Each log has a maximum size of 100MB, at which point the new log is created and the original one renamed to include “archive” and a number in its name. These logs are stored in c:\program files (x86)\Quadrotech\logs\. The various server log descriptions are in the following table. The directory where logs are stored can be changed during installation.
|Core||Shows all activity related to the PST Flight Deck Core|
|Active Directory||Shows all activity of the Active Directory module|
|Backup||Shows all activity of the Backup module|
|Deduplication||Shows all activity of the deduplication module|
|Extraction Service and Worker||The service log shows the overall work of the extraction module and the worker log shows the details for individually extracted items|
|Park||Shows all activity of the park module|
|Repair||Shows all activity of the repair module|
|Content Scanner||Shows all activity of the content scanner module|
|Clean Up||Shows all activity of the Clean Up module|
|Office 365 Service and worker||The service log shows the overall work of the Office 365 module and the worker log shows the details for individually extracted items. This log applies to Exchange migrations as well|
|PowerShell||Shows all activity of the PowerShell modules|
|Hosted||The hosted logs show activity of IIS while PST Flight Deck is processing. There are tow logs, one for the PST Flight Deck core and one for the Helpdesk web interface|
If you experience an issue while using our product, please use this guide to attempt to gather as much information as possible about the nature of the issue. Identification of the point of failure of an issue and collecting the appropriate logs when starting a ticket will aid the support process and ultimately, the resolution of the issue you are experiencing. When you have an issue that you are unable to address yourself, you may also contact a Quadrotech support representative by email:
If you have a question on how to use a feature of the product, sizing, or any product related questions regarding the use of the product, then please contact your Field Enablement representative for further guidance.