Table ExchangeMailboxEntry and its content

[Peable]

Hi everybody,

my research started out with a customer on EV 8.0.3, who follows the article Tip...How to configure a EV Mailbox Policy for Leaving Users. When "all of the items have been archived the user can be disabled in Enterprise Vault and removed from Active Directory".

• The users get disabled.
• The provisioning task is run or is not run (we tested both with the same outcome).
• User is being deleted in AD.
• The provisioning task is run.

At this point, there are no errors in the Event Log, but we still receive the error in the Provisioning Log:

 Mailboxes on Exchange Server [xxx] that have entries in the Enterprise Vault database but which are not in any provisioning group:
/o=company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user (state = disabled) 

Deleting the affected users from the Table "ExchangeMailboxEntry" obviously helps.

Wayne describes here the different states for the MbxArchivingState and the MbxExchangeState.

• For the customer, the disabled users' state changes from MbxArchivingState = 0 to 2 when disabling the user in EV.
• For the customer, the deleted users' state stays at MbxExchangeState = 0.

My questions are as follows:

1. Shouldn't the Provisioning Task realize that a user is not in the Provisioing Group and the user is deleted and just do nothing?
2. When/what process changes entry for MbxExchangeState from e.g. 0 to 2? I assume changing this entry will not delete the user in EV?
3. When deleting the content of the ExchangeMailboxEntry, the active users are added by running the Provisioning Group again. I know that helps. But is this the only workaround or what is going wrong?

Thanks and best regards,
Jochen.

[MichelZ · Accepted solution]

Jochen

This entry in the Provisioning Log is not an error, it is more a warning/information, as ideed the user is not in any provisioning group (because the user does not exist anymore, of course)

To your questions:

1. This is probably dangerous, as there could be issues with AD and stuff and the User never gets into a provisioning group.

2. The entry is changed on either a provisioning run, or when you enable/disable a mailbox

3. yes, this is correct, as the provisioning log is only a warning/information, no error

[Nick_White]

>>Shouldn't the Provisioning Task realize that a user is not in the Provisioing Group and the user is deleted and just do nothing?

This warning was deliberately put in to show administrators that there may be mailboxes which will never be archived as they are not a part of a valid provisioning group. We felt it would be better to warn about this than have something happening silently in the background

>>When/what process changes entry for MbxExchangeState from e.g. 0 to 2? I assume changing this entry will not delete the user in EV?

To change the status you disable the mailbox from archiving in the Admin Console. This keeps all the archived data intact and the user can still search for archived items and recall them from shortcuts. If you subsequently enable the mailbox again then the same archive is used again

>>When deleting the content of the ExchangeMailboxEntry, the active users are added by running the Provisioning Group again. I know that helps. But is this the only workaround or what is going wrong?

You shouldn't need to delete anything from the ExchangeMailboxEntry table. The warning will appear again after provisioning and there is currently no way to suppress it

[MichelZ]

I disagree, the warning will not come up again, as the Account in ActiveDirectory has been deleted (hence it will no get into ExchangeMailboxEntry again)

[Nick_White]

I missed the part about the account being deleted... Having one of those days ;)

[Peable]

Hi MichelZ and Nick,

thanks for the feedback... I see this is only information. So, I understand as long as there are no errors logged at the same time in the event log, nothing to worry about.

I've seen many cases where there are accounts mentioned and the provisioning tasks logged errors... until now, I deemed this not just information. Again, I've learned something.

Many thanks,
Jochen.