We are looking to decommision EV.
I have restored an archive back to a mailbox. This completed successfully.
The emails did not go back into the correct folder structure though. A new folder was created with a blank name, and all subfolders were created in there:
Is this normal behavior?
Which version of EV do you have? In general, the restore to mailbox should take in account the folderstructure, but it might be the structure as known in EV is corrupt. You then see what you are experiencing. How does the Archive Explorer for this specific archive look like. Do you see an empty 'root', or is the folder structure as expected.
As remark, if you're looking at restoring a massive amount of archives, you might be better off using a 3rd party migration tool. Quadrotech ArchiveShuttle, or TransVault do a good job in migrating archives back to mailboxes.
No, it's not normal. You didn't mention what version of EV you're running, but if it's 11.0.1 then it's probably this known issue.
Edit: While I was posting, you did reply with the version. Not surprised it's 11.0.1. See the article for the steps to prevent it from happening again and then to correct the existing affected folders.
Thanks. That looks like the problem.
I will update to CH3.
Is there a way to update all affected users in one go, rather than one by one?
Sure, you would just remove the parts of the WHERE clause that limit it to one archive. So step 2 becomes this SQL:
USE EnterpriseVaultDirectory SELECT DATALENGTH(FolderPath) AS "Folder Path Data Length", LEN(CAST(FolderPath AS NVARCHAR(MAX))) AS "Folder Path Character Length",FolderPath, ArchiveVEID FROM ArchiveFolderView WHERE CAST(FolderPath AS NVARCHAR(MAX)) LIKE '%Inbox'
And step 3 becomes:
USE EnterpriseVaultDirectory UPDATE dbo.ArchiveFolderView SET FolderPath=LTRIM(CAST(FolderPath AS NVARCHAR(MAX))) WHERE FolderName = 'Inbox'
Note that this may take a long time because you're removing leading spaces from every inbox folder instead of just the ones you know are affected. Those that don't have any leading spaces won't end up being changed by the LTRIM function, but it still takes the time to evaluate them all. Even more so if you apply it to all folders and not just the inbox, as in the note at the end of the article.
Another alternative would be to run step 2 without the ArchiveID condition, in order to identify the affected archives, and then use the list of ArchiveIDs that are returned to limit step 3 with a clause like
WHERE ArchiveVEID IN ('ArchiveVEID1', 'ArchiveVEID2', 'ArchiveVEID3')
Feel free to open a support case if you want some hands-on assistance fixing this.
I have updated to CH5, updated the DB, ran the SQL commands which successfully updated the entries, and re-ran the export job, but they still go into the blank folder.
Any other ideas?