Unarchive journal

This thread is a bit old but thought I would provide some feedback.

At a high-level there are 2 major components to worry about the active journal process and the existing journaled data.

To move from your current configuration the low hanging fruit is re-pointing your journal process to a new storage target (ie. 3rd party storage, cloud storage, cloud provider, etc). The challenging part is migrating the existing journal data to the new target. For this you do have some options, like leaving it in place for access until the data reaches retention, exporting the data via DM (which can be painful) or using a 3rd party tool to migrate to your new storage target/service.

In my experience the answer to the 2nd part really depends on your requirements and budget.  I've had customers who found the investment to migrate a large repository of archived data to a new solution to be too expensive so they left it in place where it could continue to be accessed and searched. There have also been customers who had to get the data out to meet business requirements and we used 3rd party migration utilities to help move the data into cloud based archive solutions and/or back into Office 365/Exchange Online.

Hi, thanks very much for responding. You have summed up our situation perfectly, we have a new solution for retention going forward but are stuck with this legacy lump of data. I have been looking at third party services such as transvault to perform a migration. The question i'm going to need to answer to management is whether SourceOne can migrate the Journal data back to exchange without having to purchase another expensive product and any professional services alongside.

Is it even possible to setup an "unarchive" job of the entire Journal back to one or several Journal mailboxes? I fear that this would be the "cheap" option and may have a lot of risks associated with it

Thanks again

You are correct, there are a number of risks in doing a migration and you will need to assess what those risks are and what you are willing to accept for functionality.  Just to give you background reference, I work for a company that has specialized in SourceOne and the predecessor EmailXtender since before it was owned by DellEMC, I have been working in email archiving for over 17 years, and have been working with archive migrations for over 8,

If this is a small amount of data (less than a few TB), the SourceOne Restore may well work fine.  You will have to plan for a space consumption for the restored data going back into a native target if going back into Exchange.  Be aware that what you have stored in SourceOne when you look at the archive volumes in the S1 Admin console is single instanced and compressed.  If you have SourceOne Reporting turned on, you can get a better idea of what sizes could be coming out.  When extracting from an S1 Archive to native targets (be that Exchange, or even to PST) size of extraction target will need to be at least double, if not 4x or 5x of what you see stored inside S1.  You also need to know that a SourceOne Restore activity, while it will do the job, can take a good bit of time (i.e. a few GB per hour per mailbox, in this case per journal mailbox).  If you have a single journal and say 20+TB of data, you will be processing for quite some time and will need to split the job up and bracket it by date most likely.  You also will get a one shot approach, that while you can get a report of what does and does not fail to restore (with detail logging turned on) you will not get a "Retry" option.  You also do not get a report of what a mailbox by mailbox breakdown might look like for a migration (again unless you have S1 reports turned on and drill down into the mailbox detail for the users).  Customers that have taken the approach of using the Restore Historical activity have seen small amounts and small counts of users work, but if you have hundred or thousands of users with 10s/100s of millions/billions of messages, the restore activity will be overwhelming so be prepared for a lot of work and rework as you go through the restore.

Keep in mind, that while a migration solution (yes I have worked with TransVault for a number of our customers in addition to some other migration tools) can have a cost to do so, the cost is about the value of the data, not the cost of the box.  So you do need to look at the risk assessment of what the migration must achieve, and what the costs are of your time to do the work, as well as the costs or redoing work, proving the completeness of the migration, and probing what users got what data, and what did or did not succeed.

There are also other factors such as chain of custody, that dependent on the market segment your company serves, may well cost more than simply trying to go it alone.  If you company is subject to regulatory oversight, or has a pattern of being highly litigated, the real costs may not even be the actual migration, but the risk of losing data in the migration or risks from being fined or sued for losing critical data.  Part of your risk assessment can and should include the consideration of what would it take to simply maintain the S1 archive in place until the data in it has expired, this does mean operating a dual system for a period of time.

A migration solution will give you the option to do a pre-inventory of all data, including active and ex-employee, and archives and journals.  You can then decide who, and what (based on filters such as date) is to be migrated into the new archive (if that is where you are going) or back into Exchange or PST.  You can also direct ex-employee data to either a different user account, a corporate oversight account, or even elect to go external (such as to PST or MSGs) totally off-line if desired.  So have multiple potential destinations for the migration can be quite helpful if that is needed.  Depending on the new archive destination, you may well be able to do a direct migration from SourceOne into the new archive (such as if you are going to Office 365 and want to put data into the Archive of a user mailbox).

Leave a note if you wish to discuss further in detail with someone that has been where you are and helped other customers make this kind of change.

Thanks very much for taking the time to give such a detailed reply. There is definitely a lot of food for thought in there and I am awaiting some firm requirements before moving forward.

Regarding the allocation of space in Exchange compared to the size in SourceOne. I was under the impression (perhaps wrongly) that un-archiving back into an Exchange Journal mailbox would still benefit from Single instancing and therefore not require a drastic amount more space compared to the archive. From what you've said, is that not the case ?

You didn't mention which version of Exchange you're running but if it's 2010 or newer then the single-instance feature is no longer there...Microsoft deprecated it starting with version 2010.  Most archive solutions deduplicate the email data and when you push this data back into Exchange additional storage over what is in use in SourceOne will be required.

I also think Walt makes a number of good points in his response especially about the risks involved in attempting this process manually. If its a very small amount of data then using SourceOne to export may be an option but if your archive is in the TBs range I would advise against this.  Additionally I'm not sure if "unarchiving" the journal archive manually will return the message as a journal report...if it doesn't you may lose important metadata that is valuable for compliance and e-discovery.  Much of the risks and pain involved when moving out of an archive solution into a new platform are minimized by 3rd party tools designed for this specific activity.

Exchange will dedup within an information store (mailbox database) to a certain extent, more or less, but Exchange does not compress data as SourceOne does, so at the very least plan on storage at least doubling.  For a journal restore, most likely all of that data will go to a single DB/mailbox, but if for user mailboxes, consider the potential of how many stores you have and that there will be duplication across those stores.

The point above about the journal envelope, be aware of that issue as well.  If you are on Exchange 2007 or prior (which if you are, get off of it as soon as possible, you are on an unsupported platform) the restore process by SourceOne will restore the original message AND the ENVELOPE message.  In this situation, you will now have two messages (one with the enhanced sender/recipient metadata, one without) and that will double your journal mailbox.

A performance factor of the quantity of items in any particular folder in a mailbox will need to be consider in addition to the space consumption.  While later versions of Exchange have improved, when you get message counts into the 10s and 100s of thousands of messages in a single folder, when opening that folder or that mailbox, you will run into a longer amount of time to open it.  If you have shortcuts in place from the archive, this won't seem like much difference on the user front, but on the journal front, be aware of it.  Be aware of if restore to a user mailbox is being done, and you are using off-line cache, ALL of that off-line cache traffic will have to resynch to the users local cache, whether shortcuts in place or not, this will impact you either way you go.

No matter which direction you go, count on storage on Exchange expanding, count on folder enumeration impacting user experiences, and count on off-line cache for users likely being impacted in some way.