Export/Import Vault archives

[Korbyn]

I'm in a situation where I need to relocate an Enterprise Vault 9.0 system, and one of the steps I need to perform is an export of all the Mailbox Archives (not the data) and then use that list to create new, empty vaults on a new EV9 system.  I assume I would need to be using EVPM, but have never really mastered the tool, not even sure if that's the tool I would use to export a list out of the old system.

Any advice is greatly appreciated.

K.

[JesusWept3]

well is the new system going to be targeting the actual exchange mailboxes?
Reason i ask is that Enterprise Vault cannot create an Exchange Mailbox Archive without having an actual mailbox to enable, so for instance if you have say 10,000 Exchange Mailbox Archives, but 3,000 of them are users that have left and no longer in the company, you will only be able to create 7,000 archives based on enabling those exchange mailboxes

You could create a shared archive for those users that no longer have mailboxes any more, but then you would lose the ability to be structured (i.e. keeping all the folder structure, so email regardless of being in \inbox or \myFolder or \sent items, will all be placed in to one folder.)

The only way you can create an archive without an exchange mailbox being present would be to use Move Archive, but then you would have to have the ability for both EV Sites to talk to each other.

There maybe third party utilities that can do this (Archive shuttle? transvault etc? not sure).

If the new Enterprise Vault site can target the old exchange servers, you could just provision those users then enable them but don't archive anything, this will then create an archive for each user, then simply disable the tasks in the new site and re-sync them in the old site so the hidden message points to their old archive etc, but that method could become clumsy.

But simply put unfortunately, even with EVPM, you have to have a mailbox to enable against

[JesusWept3]

i could be completely wrong but im 100% sure that EVPM will not allow you to create an archive without a mailbox attached, use move archive if transvault is limited by this issue

[Korbyn]

We're transvaulting it, and yeah, been trying to figure out what to do with the 300-400 archives that are from deleted mailboxes.  Someone suggested that EVPM could provision the Vaults, even of the Vaults without mailboxes by using the info from the old EV server which still has the LegacyDN of the mailbox, kinda like faking it.

Thats going to be sucky stuffing the disconnected vaults into shared, unstructured Shared Vaults.

And yes, the New EV will target the same Exchange servers as the old.  SQL VS Database corrupted beyond reasonable repair, from what appears to be due to a mismatch of the collation language of the EV database and the Master/Temp DB's during an upgrade from 8.0 to 9.0.  EV db's were all the same before you say anything, but the speculation is that something's changed in 9.0 that processes through the master or temp that didn't before.  Seen two customers now, one apears repairable, the other, the one I'm working on now, lost the constraints on several dbo objects.  Can still retrieve data but can't archive anything.

fyi, Predeployment scanner markes the Collation of EV databases as Informational, but only if you scroll down do you see the red flags indicating the mismatch to the Master/Temp.  Potential for this exists if you've moved your EV database from one version of SQL to another.  I really wish MS would stop alternating their default collation languages of the Master/Temp DB's...

[AndrewB]

korbyn, the TV docs say "Create the Enterprise Vault Archives on the target using EVPM to create an ArchivePoint inside of EV, ready for later attachment to users" but doesnt give instructions for the ini file. you can email support@transvault.com and they could probably give you an example file.

the other method is like what JW said but since you no longer have the mailboxes that wouldn't work.

[Korbyn]

Read the same thing, but haven't heard back yet.  I had been doing some looking up, and things seem to align with JW, but here's hoping I hear some magic tomorrow morning.

[JesusWept3]

Move archive will work for archives without a mailbox

[AndrewB]

will his database issues get in the way of move archive?

[JesusWept3]

Well they said just archive only and no data right?? But to be honest I don't know what corruption korbyn is referring to, the transactional basis of SQL would make it unlikely a process has spun out of control to the point of where the db is irrepairable, and would doubt it's a collation issue, but who knows, corruption can mean anything

[Korbyn]

Users can still retrieve data, plus we can export to PST's still.  PoC with TransVault should prove that we should be able to mass move everyone's data into a new working system.

Support was having them run a script to rebuild the VS database, after 6 weeks of running, it was going to be another 100+ days to rebuild with the EVSVR tool, and their Exchange system will be out of space long before then.

It will be interesting if we have to move the dead vaults using an intersite move, and if that'll work.  My understanding that with the Archive Move process, must be capable of Deletes, which is also broken, but maybe with the intersite move it won't be important.

[JesusWept3]

Well that's the thing though , you don't care about data, you care about structure!! Anywho, MA doesn't delete items from the source

[Korbyn]

Weeks after the upgrade was complete and everything was working, the error messages below started showing up, and eventually degraded the VS database and some how the constraints on the VS database for the following tables we ALL missing, simply gone: DBO.Journal, DBO.JournalDelete and DBO.Vault..  I've seen another client with the errors below, but the constraints haven't disappeared, Support's hope there is to reset the EV DB's collation language to match the Master/temp again.  Hence my warning, scroll down to the Collation section of the Predeployment scanner regardless if it's showing just Informational or not.

Event Type:          Error
Event Source:       Enterprise Vault
Event Category:  Directory Service
Event ID:              13360
Date:                      4/5/2011
Time:                     9:55:00 PM
User:                       N/A
Computer:            CORP-EVAULT01
Description:
An error was detected while accessing the Vault Database 'EnterpriseVaultDirectory' (Internal reference: CADODataAccess::ExecuteSQLCommand .\ADODataAccess.cpp [lines {1393,1395,1410,1428}], built Nov 24 00:04:01 2010):

Description:
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 2.

 
SQL Command:
 UpdateArchiveFolder
 

Source:       Microsoft OLE DB Provider for SQL Server
Number:       0x80040e14
SQL State:    25000
Native Error: 00000266
HRESULT                            0x80040e14

Event Type:          Error
Event Source:       Enterprise Vault
Event Category:  Directory Service
Event ID:              13360
Date:                      4/5/2011
Time:                     9:55:00 PM
User:                       N/A
Computer:            CORP-EVAULT01
Description:
An error was detected while accessing the Vault Database 'EnterpriseVaultDirectory' (Internal reference: CADODataAccess::ExecuteSQLCommand .\ADODataAccess.cpp [lines {1393,1395,1410,1428}], built Nov 24 00:04:01 2010):

Description:
Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and "Latin1_General_CI_AS" in the equal to operation.

SQL Command:
 UpdateArchiveFolder

Additional Microsoft supplied information:

Source:       Microsoft OLE DB Provider for SQL Server
Number:       0x80040e14
SQL State:    42000
Native Error: 00000468
HRESULT                            0x80040e14

[MarkBarefoot · Accepted solution]

At a guess I would say the issue here was a failed upgrade/install that noted a collation mismatch? The reason for me saying that is I've seen a few cases when I was in Support that had databases with no constraints, indexes etc on them.

After looking into this, the problem happens when the collations script doesn't complete properly - but all this info is dumped into the SQL console window, and unless you read it, you "presume" that it's finished ok. As part of the process, the tables configs are copied, and then removed and changed then put back in - the problem is when the final "putting it as it was" doesn't happen..

I got the customers fixed in the end (one was easier as they had proper backups in place), but it is a major stumbling block that can cause problems in the future.

I realise this isn't what the thread is about, just referring to what may have caused your 13360 etc errors.