cancel
Showing results for 
Search instead for 
Did you mean: 

How to delete archives stored on Centera with 10 years of retention

TorInge
Level 3

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!

1 ACCEPTED SOLUTION

Accepted Solutions

ChrisLangevin
Level 6
Employee

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

View solution in original post

13 REPLIES 13

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

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.

Regards. Gertjan

ChrisLangevin
Level 6
Employee

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

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?

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?

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.

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.

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.

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

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)12C77B7CA494C1549B9FE1E813818DB721110000evmbx01Default for Username 1 (Company 1)Username 1 (Company 2)
Username 1 (Company 2)1BFF68AF8777E134F8F5D598A284A5A8B1110000evmbx01Default 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?

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

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!

 

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

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.