Deleted mailboxes are not getting cleared after synchronizing

[Barbara_Gargone]

We are running EV 6.0 SP2 with EX 2003 SP2. When an Exchange mailbox is deleted from IS (through purging), Evault still shows the deleted mailbox after running synchronization. I zapped all permissions to the associated vault (and added new perms) for future use incase the employee comes back. I want to test how to associate an existing vault with a 'returned' employee after their mailbox has been deleted and re-created.

I found an EV article "How to clear deleted Mailboxes after syncrhonizing", and added the registry DWORD "MarkAsDeletedAfterXDays value to 1 forcing VAC to mark this mailbox as deleted after 1 day (in hopes that it would remove the mailbox after synchronization) but this didn't work. I also receive an error "this mailbox cannot be synchronized" after manually selecting it. Which I would expect to see as it no longer exists on the Exchange server, but I'm not sure why VAC still shows it within the synchronization tab.

Is anyone else experiencing issues with synchronizing deleted mailboxes?

Any help is greatly appreciated.

Thanks,

gargoneb

[Shane_Seagreen]

To be honest you may find it more useful to leave the archive in place, its not taking up that much room, and you may get in an instance like I had the other day where a user required access to someones email from a year ago. Luckily we run a zero day policy on leavers, so all mail is stored in the vault, so rather than do a ful mailbox restore, I simply had to re-assign permissions to the user who needed access.

[Barbara_Gargone]

Thank you for your reply. Yes, that's correct, we want to keep the archive in tack incase the employee ever comes back. We can then just re-associate the vault with the new mailbox. My issue has to do with the synchronization of deleted Exchange mailboxes. Once the account is deleted from AD/Exchange, the mailbox should be removed from the "list of mailboxes" that are displayed after synchronization, but unfortunately the account is still visible.

[W_Wintermute]

The reason the account is still visible when you synchronize is that it is listed in the ExchangeMailboxEntry table in the EnterpriseVaultDirectory database.

If you go into this table and remove that user, then they will no longer show up when you perform a synchronization.

[Shane_Seagreen]

This seems to be a bit of an in-efficient way to clean this up, what if you are deleting a couple of hundred users every week? Surely there must be a better way to force this sync to occur properly? I checked my sync too, and Barbara is right, Ive got 100's showing, and we delete almost a 100 users every week. Surely I cant be expected to manually delete these out the sql table every week??

[Barbara_Gargone]

Thank you....How do I delete the account from the ExchangeMailboxEntry? The only option available is to export or import. Do I export it to a spreadsheet, remove the mailbox and then import? If so, can this be done while all EV and SQL services are running?

In regards to Shane's reply, I think there are certain steps that need to be taken before deleting the mailbox so that it is removed from the database correctly. I was able to test the deletion of another mailbox and ran synchronization immediately thereafter, and the account was removed. As soon as I validate the procedure I will post a reply with the process that worked for me.

Barb

[W_Wintermute]

Go into SQL EnterpriseManager.
Expand the EntepriseVaultDirectory database
Right-click on the ExchangeMailboxEntry table
Open Table/Return all Rows
Delete the line for your specific user

If there are too many users in the list, click the SQL button on the toolbar and perform a query like:

SELECT *
FROM ExchangeMailboxEntry
WHERE (MbxAlias = 'youruser')

Replace youruser with your user name.

Highlight the result and delete

Now that deleted user should not appear in the Synchronization list.

[Barbara_Gargone]

Can I delete the user name from the SQL database while SQL and EV services are running, or should I do this offline?

Thanks for steps.

Barb

[W_Wintermute]

Either way

[Barbara_Gargone]

Thanks - Deleting this entry from the directory database removed it from the synchronization list. But now for the big question that started this thread....

I am testing a scenario when a user leaves the company and then returns a year later, how do we re-associate their previous vault to their new mailbox?

These are the steps I took, and then the issue I ran into, which I'm hoping you may know the answer to:

- Before deleting the account, archive all mail
- Zap the mailbox & synch (to disassociate and remove hidden message)
- This removes the account from synch list (attempted to synch, no mailbox found)
- Delete/purge mailbox & synchronize again. (mailbox still removed from synch list)
- Re-create new mailbox using same name as deleted one (recreated a day later)
- Manually enable mailbox and clicked "Select Archive" to associate it with the existing archive.

This is where I get the warning or error: "You cannot choose "mailboxname" because it is already the archive for "mailboxname".

I would have thought by zapping the mailbox before deleting it in step 2 above, this would have also cleared the Archive ID associated with the vault, but it appears the vault is still flagged with the Archive ID from the previous deleted account, therefore preventing it from being re-assigned.

So how does EV expect us to associate an existing vault with a new mailbox if the original Archive ID doesn't get cleared or reset when disassociating and deleting the mailbox.

Thanks again for all your help.

[W_Wintermute]

I looked at this a bit today and this is how I found it to work on my test box.

Zapping a user's mailbox did not remove it's entry from the ExchangeMailboxEntry table for me.

1) Entries in the ExchangeMailboxEntry table have a DefaultVaultid. The DefaultVaultid is tied to their archive.

2) You can also see this DefaultVaultID in the Advanced Tab of the Archive within the Vault Administration Console (though it's called Archive ID there)

3) In the ExchangeMailboxEntry table, let's say that you have the following:

UserY DefaultVaultID YYY --------- which is tied to -------- ArchiveY

You delete UserY, but UserY is still listed in the ExchangeMailboxEntry table with the DefaultVaultID for ArchiveY.

If you enable UserX and try and select ArchiveY for him, it will fail with the same message you mentioned above.

"You cannot choose "mailboxname" because it is already the archive for "mailboxname".

Why? Because there's an DefaultVaultID entry in the ExchangeMailboxEntry table that's still tied to Archive Y.

If you delete UserY's entry in the ExchangeMailboxEntry table that contains the DefaultVaultID tied to ArchiveY, then you can now associate UserX with ArchiveY.

On the Archive that you cannot associate another user with, I would look in the Advanced Properties of that archive and find the ArchiveID.

11C5F0EF4C296D34582C8E094F7C8B6C81110000EVSite.tech-support.local

I would then run a query against the ExchangeMailboxEntry table:

SELECT *
FROM ExchangeMailboxEntry
WHERE (DefaultVaultId = '11C5F0EF4C296D34582C8E094F7C8B6C81110000EVSite.tech-support.local')

and see if you find an entry with that DefaultVaultID in the table.

[Barbara_Gargone]

I figured it had something to do with deleting the ExchangeMailboxEntry for that Archive ID. Thanks, your instructions worked which allowed me to associate the new mailbox with the existing vault.

So with that said....Do you know what the purpose of Zap is other than to remove the hidden message from the mailbox, making it appear as if it was never enabled. It obviously doesn't have any affect with removing the Archive ID from the vault within SQL, so I'm wondering if I can just skip Zap altogether.

Thanks

[W_Wintermute]

Yes, zapping the mailbox to delete the hidden message is just used in certain, isolated troubleshooting scenerios.