The following ports must be open for communication between PST Flight Deck and its dependencies.
Source |
Destination |
Port |
Description |
---|---|---|---|
Workstation |
PST Flight Deck Server |
80/443 |
Agent communication |
PST Flight Deck Core |
SQL Server |
1433 |
SQL access |
Module Node |
PST Flight Deck Core |
80/443, 445 (SMB) |
Module to core communication |
Ingest Node |
PST Flight Deck Core, and target system |
80/443, 445 (SMB) |
Module to core communication |
Workstation |
Upload location server |
81/444 |
File transfer (BITS)* |
* In addition to the Default Web Site, PST Flight Deck uses a separate PST Flight Deck BITS Website. The Default Web Sites communication passes via port 80/443, whereas the BITS website is preconfigured to use port 81/444. Having this as separate website makes it possible to limit bandwidth immediately when the server is in OFF STATE (because of a full disk for upload) while communication to the Default Web Site continues. All ports can be changed manually, if needed.
PST Flight Deck has a highly extendable architecture. As this is the case, the requirements per deployment may change. The following section stipulates the additional requirements needed for supplemental components used within a deployment.
Two types of accounts are required in PST Flight Deck when ingesting. Any account used for these targets will need to be assigned application impersonation rights. To use some of the advanced functionality available to Exchange or Office 365 targets,
To migrate data for people who have left the organization to an Office 365 target, an account with additional permissions is required. In addition to having application impersonation rights assigned, the Exchange Administrator and User Management Administrator roles are also required in order to apply the licenses necessary for this type of migration.
If the intended target system of a PST migration is Enterprise Vault, additional requirements are needed to accomplish the ingestion.
The current Enterprise Vault Service Account is required for installation and to run the services responsible for any Enterprise Vault related function.
The API associated with version of Enterprise Vault being ingested to is also required. This is typically included in the Enterprise Vault installation media (e.g. X:\Symantec Enterprise Vault\API Runtime\ where X:\ is the drive letter of the Enterprise Vault installation media). Frequently, customers choose to install the Enterprise Vault Admin Console instead of the API. this is an acceptable and supported configuration.
For migrations requiring Enterprise Vault shortcut creation, the account running the shortcut module will require Application Impersonation rights in the target Exchange environment.
© ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center