Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

MbxArchivingState and MbxExchangeState not updated

Created: 26 Nov 2012 • Updated: 18 Jan 2013 | 9 comments
This issue has been solved. See solution.

 

I want to search for archives that belong to deleted mailboxes. According to various other threads these archives should have MbxExchangeState = 2 in ExchangeMailboxEntry.

However, this is not the case in my system. There are few correct entries, but for most archives associated with deleted mailboxes the table says MbxExchangeState = 0 and MbxArchivingState = 1 (which means that mailbox exists and is enabled for archiving).

The provisioning jobs are running normal and I couldn't see any configuration error.

Comments 9 CommentsJump to latest comment

ZeRoC00L's picture

Did you check these two technotes:

http://www.symantec.com/business/support/index?page=content&id=TECH47252 and

http://www.symantec.com/business/support/index?page=content&id=TECH76587

By default EV does not synchronize hidden and disabled accounts. If you don't modify the registry keys of the two above technotes, the state will not change.

If this response answers your concern, please mark it as a "solution"

stephan.vanhelden@uponor.com's picture

Thanks! Unfortunately it didn't really help. After applying both modifications, I can enable and archive hidden mailboxes as well as mailboxes of disabled users. But mailboxes that do no longer exist (and users are disabled) do still have MbxExchangeState = 0 and MbxArchivingState = 1.

JesusWept3's picture

You culd run a search against the ExchangeMailboxEntry table i suppose
something like

SELECT ArchiveName
FROM Archives
WHERE ArchiveName NOT IN (SELECT MbxDisplayName FROM ExchangeMailboxEntry)

The issue with that though is that it will search for archives that have no ExchangeMailboxEntry, which could simply be that the user is no longer provisioned as opposed to not having an existant mailbox

You could also use the Usage.asp I believe, and do show by Billing Account, if the Billing Account has Unknown and a SID instead of an account name like MYDOMAIN\UserA ...then that means that the AD account has been deleted and EV cannot resolve the SID to an account name

 

stephan.vanhelden@uponor.com's picture

That doesn't help because the mailboxes ARE listed in ExchangeMailboxEntry, though they don't exist anymore.

TypoProne's picture

the ExchangeMailboxEntry table holds onto the data and they do not get purged despite no longer being in AD or Exchange. I belive that unless a row is updated with data... it is never really naturally deleted from this table.

 

For your issue I would be currious what errors you are getting when running provisioning or a synch of the applicable archive task associated with these. If this data is not updated... most likely there is a message telling you of some issue that can be attributed to it. Are these users in the Provisioning report? 

 

are the accounts actually deleted or are they hidden/disabled?

stephan.vanhelden@uponor.com's picture

The AD accounts are disabled, and the mailboxes don't exist anymore (they have been "disabled" from Exchange Management Console which means that their Exchange-related attributes have been removed from AD).

I found that some of these users are listed in the provisioning report under "Mailboxes on Exchange Server that have entries in the Enterprise Vault database but which are not in any provisioning group" while others are not mentioned in the provisioning report at all.

 
JesusWept3's picture

The do a DELETE FROM ExchangeMailboxEntry
Re-Run your provisioning, the only mailboxes that will come back are those that are supposed to be provisioned and exist in the AD...after that re-run the query i posted above

stephan.vanhelden@uponor.com's picture

Well .. this isn't quite what I wanted to achieve. My original goal was to use the EV database to FIND archives for mailboxes that don't exist. Whether these are included in the ExchangeMailboxEntry table with wrong attributes or not included at all doesn't matter.

 

JesusWept3's picture

but thats exactly what it would do
If an archive is a mailbox type archive (as opposed to journal, shared, domino, FSA etc) and it doesn't exist in the ExchangeMailboxEntry table any more, then it is an archive with a non existant mailbox, or at least aren't provisioned anymore

Another thing you could do is
SELECT * FROM ExchangeMailboxEntry WHERE PolicyTargetGroupEntryId IS NULL

That will return all archives that exist in the directory database but no longer have a provisioning group (i.e. possibly deleted)

You could do something like

SELECT A.ArchiveName, EME.LegacyMbxDN
FROM Archive A, ExchangeMailboxEntry EME
WHERE A.ArchiveName = EME.MbxDisplayName
AND EME.PolicyTargetGroupEntryId IS NULL

That will match archives that exist to uesrs that were once provisioned but no longer provisioned (possibly because of a delete)

You could connect SQL to active directory and do an LDAP query based on the LegacyMbxDN matching AD's LegacyExchangeDN

SOLUTION