03-08-2017 05:30 AM
We are moving archives away from Centera to a new storage device, as we are going to decommission the Centera device. While I was moving archives and deleting the old ones when finished, I noticed that the archives are stuck in deletion. I figured out that the Centera retention class for those archives was set to 10 years. Hence the messages popping up in dtrace:
262á760 13:26:46.054 [49á556] (StorageDelete) <26512> EV:M CVaultStoreEMCCentera::ClipGetExpiryDateCenteraCollection -- Clip-Id: 88PRQ8LUUIQ3JeCOEQR9F1D17IVG418H8CEQUQ0A9VTB8H166IT1G, Expiry date: 0.000000
262á764 13:26:46.054 [49á556] (StorageDelete) <26512> EV:M CVaultStoreEMCCentera::ClipGetExpiryDate -- Clip-Id: 88PRQ8LUUIQ3JeCOEQR9F1D17IVG418H8CEQUQ0A9VTB8H166IT1G, Expiry date: 45340.812847
262á786 13:26:46.054 [49á556] (StorageDelete) <26512> EV:M The deletion of the item is not currently permitted. The item is on a compliance device with a retention period that prevents it from being deleted.
Are there any way of removing the old archives from EV before the Expiry date? I am not concerned about the data on Centera once all moves are completed. I just want to remove any references to the old archives and items once we have moved everything away from Centera.
How do I calculate the Expiry date in dtrace?
When trying to delete about 18TB of data in retention, will that bog down the EV server as it tries to delete the items over and over again?
Thanks!
Solved! Go to Solution.
03-08-2017 06:30 AM
EV will not be able to delete the item data from the Centera until the Retention Period has expired. It is possible to remove the references from EV's databases (effectively orphaning the Centera data) but you will need to open a support case to have this done, as it's not trivial.
The expiry date shown in the dtrace is recorded as a DATE type. This means that the number you see in the trace represents the number of days since December 30, 1899, with time of day represented by the fractional part. In the case of the example you posted, adding 45340.812847 days to December 30, 1899 yields an expiry date for this item of February 18, 2024.
To convert in PowerShell, use this formulation:
([datetime]"12-30-1899").AddDays(<DATE value>)
Example using the value you posted:
PS> ([datetime]"12-30-1899").AddDays(45340.812847) Sunday, February 18, 2024 7:30:29 PM
03-08-2017 06:07 AM
Hello, probably due to Centera being in Compliance mode, these errors will be there until the 10 year retention is valid. You can change the Archivestatus for the mailboxes in 'delete' status, so they become available again. this will stop the deletion. You might need to talk to EMC to figure out if it is possible to change the Compliance mode to less restrictive (i.e. allow deletions despite the retention is not passed yet)
To reset the status:
1.Within SQL Management Studio run the following:
USE EnterpriseVaultDirectory
SELECT * FROM Archive
WHERE ArchiveStatus = 4
This will generate a list of all of the Archives set for Deletion.
1.Check the results and make sure that the ArchiveName column contains the Archive/s in question. Take note of the RootIdentity for each Archive.
1.Within SQL run the following SQL query to change the status back to Available:
USE EnterpriseVaultDirectory
UPDATE Archive
SET ArchiveStatus = 1
WHERE ArchiveStatus = 4 AND RootIdentity = 'RootIdentity taken from step2'
1.Refresh the view in the VAC and make sure that the vault status for the archive/s have changed from Marked for Deletion to Available.
03-08-2017 06:30 AM
EV will not be able to delete the item data from the Centera until the Retention Period has expired. It is possible to remove the references from EV's databases (effectively orphaning the Centera data) but you will need to open a support case to have this done, as it's not trivial.
The expiry date shown in the dtrace is recorded as a DATE type. This means that the number you see in the trace represents the number of days since December 30, 1899, with time of day represented by the fractional part. In the case of the example you posted, adding 45340.812847 days to December 30, 1899 yields an expiry date for this item of February 18, 2024.
To convert in PowerShell, use this formulation:
([datetime]"12-30-1899").AddDays(<DATE value>)
Example using the value you posted:
PS> ([datetime]"12-30-1899").AddDays(45340.812847) Sunday, February 18, 2024 7:30:29 PM
03-08-2017 06:50 AM
Thank you for the answer! I thought this was support case material, I just wanted to make sure there were no easy way outs.
I have estimated the move will be completed in 6 months with the current speed (Centera is the bottleneck). Do you reccomend I wait until everything is finished, or should we do deletions with more frequent intervals?
03-08-2017 06:59 AM
Will they be re-associated with the user mailbox at the next run of provisioning? Because the reason why I delete them in the first case, is that the old archives are confusing the end users when visible in archive explorer.
Are there any other ways than marking them for deletion to remove the old archive from the user account? May I just remove the rights, or are they still in sync with exchange?
03-08-2017 07:00 AM
I would wait until everything is finished migrating and you have confirmed it's all working in the new spot. While you could delete this first batch of 1,000, then this next batch of 1,000, and keep track of what has been deleted so far the whole time, it is a lot easier if you just wait until the end and delete them all. Also keeps us from having to drag out a support case over 6 months, which isn't anyone's idea of a good time.
03-08-2017 07:09 AM
Only one archive can be associated with a mailbox, so if the users have new archives that are associated to their mailbox, then the old ones will not be re-associated.
If you remove the users' rights to the old archives, then they should stop showing in Search/Archive Explorer. And if the old archives are no longer associated to the mailboxes, then their rights will not sync from Exchange anymore, so the rights should stay removed.
You may still want to delete the old archives if they are truly duplicative, just to keep your admin console and your SQL tables cleaner.
03-09-2017 12:56 AM
I completed one without marking it for deletion. I ran provisioning and synchronization, and still, the closed archive has inherited the rights from Exchange. I cannot manually remove the rights, I have to set deny. So I think I will keep on marking the archives for deletion, if that doesn't reduce the overall performance.
If I have two archives with the same name, same billing account and everything seems similar in the console. How can I tell which one is the one connected to the mailbox? We have quite a few of those, after users have gotten new usernames, but kept the mailbox. When I'm moving, it's easier, because the old one is renamed and the new one is on the new Vaultstore.
03-09-2017 06:08 AM - edited 03-09-2017 06:10 AM
There is not an easy way to distinguish between identically named archives in the VAC. You can use the following SQL query to generate a list of which archives are assigned to whom.
SELECT av.ArchiveName , av.VaultEntryId , av.ArchiveDescription , ISNULL(eme.MbxDisplayName,'Not assigned') AS AssignedToUser FROM ArchiveView av LEFT JOIN ExchangeMailboxEntry eme ON eme.DefaultVaultId = av.VaultEntryId WHERE av.Type = 9 -- Just Exchange Mailbox Archives
If you want to make this information visible in the VAC, the following query will update your archives' description field, which is visible in the VAC.
UPDATE ArchiveView SET ArchiveDescription = CASE WHEN eme.MbxDisplayName IS NOT NULL THEN 'Active archive for ' + eme.MbxDisplayName ELSE 'Inactive archive' END FROM ArchiveView av LEFT JOIN ExchangeMailboxEntry eme ON eme.DefaultVaultId = av.VaultEntryId WHERE av.Type = 9 -- Just Exchange Mailbox Archives
(Both queries are run against the EnterpriseVaultDirectory database.)
Hope that helps.
--Chris
03-14-2017 04:08 AM
Had to add USE Enterprisevaultdirectory, then it worked! (I am not very experienced in sql, so please forgive if this is obvious).
Still, I got this (username obfuscated), for some users that were migrated from Company 1 to Company 2 (same exchange/ev, but new usernames.) Mailbox was disconnected and reconnected to the new user id, before I could suggest anything. Resulting in two archives. Displayname is actually "Name of user (Name of Company)". Both archives have the new alias in the access list. The old one is gone.
Username 1 (Company 2) | 12C77B7CA494C1549B9FE1E813818DB721110000evmbx01 | Default for Username 1 (Company 1) | Username 1 (Company 2) |
Username 1 (Company 2) | 1BFF68AF8777E134F8F5D598A284A5A8B1110000evmbx01 | Default for Username 1 (Company 2) | Username 1 (Company 2) |
So the question is which archive is the active archive for this user? Can I safely move one of the archives to the other, merging them, when migrating to the new vault store?
03-14-2017 06:09 AM
That's interesting. You should be able to add the LegacyMbxDN column from ExchangeMailboxEntry to see which is the active archive. (If LegacyMbxDN is NULL, then it is not the active archive.)
SELECT av.ArchiveName , av.VaultEntryId , av.ArchiveDescription , ISNULL(eme.MbxDisplayName,'Not assigned') AS AssignedToUser , eme.LegacyMbxDN FROM ArchiveView av LEFT JOIN ExchangeMailboxEntry eme ON eme.DefaultVaultId = av.VaultEntryId WHERE av.Type = 9 -- Just Exchange Mailbox Archives
If that still doesn't sort it out for you, then you should probably open a support case and someone can take a closer look.
--Chris
03-14-2017 07:59 AM
That did the trick! I could match the LegacyExchangeDN with the one in exchange. The correct one had "first administrative group" probably because the user has been migrated from older versions of Exchange. And the other one had "Exchange Administrative Group (FYDIBOHF23SPDLT)" as the new user was created recently on Exchange 2010. The usermailbox was moved from the old user object to the new one. That's probably is the reason why this mix things up with EV. I have to check if it archives twice from the mailbox as well.
Thanks a lot for the help!
03-14-2017 08:30 AM
Yeah, EV uses this LegacyMbxDN value (copied from the "legacyExchangeDN" attribute on the AD user object) as its unique identifier for an Exchange Mailbox. So even if the alias and display name are identical, if the LegacyMbxDN is different, EV considers this a different mailbox and gives it its own new row in the ExchangeMailboxEntry table.
For future reference, see this article for the proper method to move archive-enabled mailboxes to a new Exchange server while preserving the link to their existing archives.
--Chris
03-15-2017 02:31 AM
Thank you!
I went through the reports, and the archive that is not connected to a mailbox, is empty. So I marked it for deletion after verifying by a search that it indeed had 0 items. And if I migrate some of the others in the same situation, it will not be a problem. Only that the user sees two archives in archive explorer. But that, I can clean up later.