PST Ingestion – Stage 4 of the FlightDeck Approach
Last week we took a look at the necessary processing that needs to be applied to the centralized PST files before ingestion into the new target. This week, we see how our Advanced Ingestion Protocol helps to provide a faster and safer ingestion to new platforms such as Office 365.
Recently Microsoft announced its own solution to PST ingestion, but this has been met with many questions over its limitations, especially in regards to being applied to enterprise-level projects. It’s important to remember that ingestion is just one factor in a complicated procedure. For more information on this, you can find links to the earlier parts of our blog series below.
When ingesting into Exchange or Office 365, it can be assigned as to whether data should be ingested to either the primary or archive mailbox. Remember that ingesting to the primary mailbox would result in resync of the data back to the client, as the content is cached in the OST-File on the client. QUADROtech is using its unique Advanced Ingestion Protocol instead of traditional MAPI or EWS approaches.
AIP converts a bunch of messages from a PST file into Exchange’s internal storage format at the same time and streams this binary BLOB to the CAS Server over a HTTP/S connection. This results in a lighter load on the CAS Servers or Array, as conversion is no longer required, which would have been typically done by the CAS Servers. The CAS forwards the stream immediately to the Mailbox server to be stored in the Exchange Database. The typical speed benefit is 400-500% more throughput, with less load on Exchange, than traditional EWS. Especially in Office 365 ingestions, it results in far less throttling by Microsoft.
Typically the ingestion is writing to a configurable subfolder (e.g. “Legacy-PST-Data”) in the Mailbox-Root of the user, keeping the folder structure underneath this folder intact.
Alongside the speed benefit of AIP, is heightened safety for the migrated items. Approaches such as EWS for example, work by requiring the application to create a new item in the mailbox folder, and then setting the properties on those items. Unfortunately, not all properties can be preserved, such as the date it as created. It will change to the time of the migration which can’t be prevented. Some other properties which are “read/only” can also not be set via EWS. This means the ingested item is no longer the “original” item, which could leave some organizations with concerns over Chain of Custody preservation.
Next week we wrap up our blog series with a look at how FlightDeck takes care of tasks such as shortcut rehydration post-migration.