Re-Archiving entire mailbox

[sandrine_goetha]

Hello,

I just got this question from Management.

First our environment :EV for Exchange 2010/2016 , EV 11.0.1.5 planned to migrate to 12.1.1

We archive without shortcut ....just a copy is made in the vault Stores

From The vault Store it was decided ( by management for cost reasons) to use disk whithout any back-up possibilities.

Now they are thinking at using EV as back-up of Exchange.

I know this is not the optimum settings and a lot of you wouldn't do it this way but it was management decisions for cost and acceptance reasons.

I was asked in case we lose our stores is there a way to rearchive entore mailboxes ( as it is highly improbable that we loose both EV and Exchange at the same time ).Unfortunately I don't know any does any of you has an idea ?

Thanks

Sandrine

[VirgilDobos]

Hi Sandrine,

That is not possible. Typically, when an email is archived, after it is securely stored in EV, it is deleted from the mailbox and replaced with a shortcut. When a user tries to open an archived email by clicking on the shortcut, the actual email is retrieved from EV as it is no longer in Exchange. 

If an archive is accidently deleted or full vault store lost, you have 1 or 2 options;

1. Recover the EV vault stores from backup (EV vault store backup)
2. Recover the mailboxes from backup (Exchange backup) - this is not very practical as you will need to recover from multiple backups

Hence both EV and Exchange backups are critical. Let me know if you have any queries, and I'll elaborate further.

[GertjanA]

Hello Sandrine, Virgil,

I think the key remark from Sandrine is "We archive without shortcut ....just a copy is made in the vault Stores"

This means (afaik) that items from the mailbox do sit in the archives, but there are no shortcuts. If Sandrine means'"can we rearchive mailboxes if EV stores fail", the answer would be yes, but.... If a user has cleaned up the mailbox, or there is an Exchange management policy running delting items, or user moves items to PST, these will not be rearchived. I do believe you need to test, as it might be the messages in the mailbox that have been archived have a setting like 'don't archive again'.

[sandrine_goetha]

Hello Gertjan, Virgil,

Thank  to both of you for your answers.

I'm well aware of the " normal" procedure but my question was just to know waht we could do in our setting  should a problem arrise.I'm also aware it would only rearchive items present in the mailbox at time of re-archiving.

The problem is , as Gertjan pointed out, the MAPI property of the message in mailbox  : archived date.

I already tested and if I delete this I can rearchive without problem BUT I can do this for a few items but not for full mailboxes and especially not for 30 GB mailboxes. Perhaps if somehwere a sript would exist to delete this MAPI property.

Thanky

Sandrine

[ChrisLangevin]

Sandrine,

First things first: this is a lousy idea and you should not use EV this way. EV is not a backup product, and attempting to use it as a backup product will inevitably end in wailing and gnashing of teeth. Since it sounds like you know this and your management is insisting that you do it anyway, here is what you need to know to implement this lousy idea.

You are correct that the ArchivedDate MAPI property is the key here. EV's tasks will skip items that have this property set, to prevent creation of duplicate archived items in situations where shortcuts are not created and the original item is left in the mailbox. Removing it causes EV to see the item as "new" and it will be processed again.

You certainly could script the removal of this property, but there is an easier way:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Agents

DWORD: IgnoreEVDates

0 - Off
1 - Ignore Archived date
2 - Ignore Restored date
3 - Ignore both Archived and Restored date

Set this value to 1 or 3 in the Registry, restart the tasks, and they should proceed as if the ArchivedDate MAPI property were not present, and you should be able to re-archive a mailbox. Of course, this setting will affect all mailboxes processed by all tasks on the EV server where you set it, so make sure you are careful which mailboxes are archived with this setting in place, or you will end up with a lot of duplicate items in the archive.

Here is an article that discusses a use case for this setting which may or may not be similar to your situation.

Once again, I sincerely hope you do not do this.

--Chris

[sandrine_goetha]

Chris,

First thank you for your time.

First as you said it I for sure know that It is not the best way to use EV but in this I have nothing to say , I can advise as much as I want if management doesn't follow my advises....

About the tech note of course I saw it and it just doesn't work :(

By design this setting will not apply to non-shortcut type items such as: calendar, contacts, tasks, etc. 

Sandrine

[ChrisLangevin]

Sandrine,

A couple thoughts on IgnoreEVDates, after some more research into your claims:

1) The issue where non-shortcut items were not affected by IgnoreEVDates was fixed in EV 10.0.4, so that should no longer be the case on your system.

2) IgnoreEVDates only works when the task's archiving run is initiated manually (i.e., right-click, Run Now). It is not honored during scheduled archiving runs. This is kind of documented, in the sense that we include instructions like "After you set these values, use Run Now to run the archiving task..." but the documentation doesn't make explicit that the setting is only honored by Run Now archiving.

3) IgnoreEVDates only works (for Exchange) if you also set the IgnoreEVDatesEnd value as well. See the Registry Values.PDF in your documentation folder, which explains this dependency. Based on the source code in this area, it looks like you should see a Warning in the Event Viewer if you enable IgnoreEVDates but forget IgnoreEVDatesEnd.

4) IgnoreEVDates only works if the Exchange Mailbox Policy is set to delete the original message. This is to prevent duplication of items in the vault. This is probably going to be the biggest sticking point given the use case you described.

As far as I can tell, points 2) and 3) were not true of versions prior to EV 12, which is why some of our older articles don't include that information.

--Chris