cancel
Showing results for 
Search instead for 
Did you mean: 

How to remove users from vault processing that do not have AD account or Mailbox

Sploinker
Level 2

Noticed many warnings in vault system log that vault was failing to connect to many mailboxes. Upon research discovered these users accounts are gone completly from Active Directory, Exchange (no mbx), and Vault (no archive box). Clearly something in sql is trying to process them but they just dont exist. Is there a process to clean these "dead" entries up?

 

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions

Ben_Watts
Level 6
Employee Accredited

Removing the entries from the ExchangeMailboxEntry table wont have that sort of effect on SQL, it wont blow it up or bring it to its knees.


If you wanted to limit it to just those entries in the error messages to be more surgical (nothing wrong with that) then just change or add to the WHERE clause in the query as per below:-

USE EnterpriseVaultDirectory
DELETE FROM ExchangeMailboxEntry
WHERE ExchangeMbxType = '1'
AND LegacyMbxDN IN (
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User1',
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User2',
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User3',
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User4'
)

Obviously change the LegacyDNs as needed.

 

Or as Tony says, try the regkey and see if that helps.

 

View solution in original post

6 REPLIES 6

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

What version of EV are you? Also, what is the event id? This seems like it might be your issue:

 

Event ID 41133 is generated during a Exchange Provisioning Task run. Mailboxes are not part of a provisioning group or deleted from Exchange.

http://www.symantec.com/docs/TECH53096

Ben_Watts
Level 6
Employee Accredited

Use something along the lines of:-

USE EnterpriseVaultDirectory
DELETE FROM ExchangeMailboxEntry
WHERE ExchangeMbxType = '1'
 

You will then need to run the Provisioning Task to repopulate that table with the live AD Objects again.

The above query will only remove normal user mailboxes, it wont touch Journal Mailboxes or System Mailbox entries in the table.

Be aware that if your environment is large it may take a little bit of time to fully repopulate the table again.

Sploinker
Level 2

Sorry, we are on 10.0.4.1333

Event ID is 3420

"Failed to open mailbox. This mailbox will not be synchronized on this run. The problem may be temporary, in which case the mailbox will be correctly synchronized on the next run.

Task: Exchange Mailbox Archiving Task for XXXXXX

Mailbox: CN=XXXXX  XXXXX,OU=XXXX, etc."

For more information, see Help and Support Center at http://entced.symantec.com/entt?product=ev&language=english&version=10.0.4.0&build=10.0.4.1189&error=V-437-3420

Following another thread I can in fact find them in SQL DB but these users do NOT have an Exchange mailbox and they do NOT have an Archive mailbox and they do NOT have an AD account in the system. So following that thread SQL indicate they all have code 0 which implies they are listed as normal accounts and not hidden.

Provisioning gets this info from Active Directory.
admbxflags = 0 ...  normal
admbxflags = 1 ... mailbox is hidden
admbxflags = 2 ...  AD account is disabled
admbxflags = 3 .. mailbox is hidden and AD account is disabled

These users are all quick turnovers during the hiring process for sales positions so I imagine replication issue here where the account is created and then when they drop from our sales training onboarding the accounts get disabled before everything is complete. I just want to get the dead entries out of SQL but obviously dont want to blow SQL up.

 

Thanks!

 

 

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

The good news is they aren't hurting anything, but I do understand the desire to have a clean Event Log. 

You could look for them via their mailbox or username you could remove them that way.  Alternatively, you could try this:

By default deleted mailboxes are not set as deleted in the ExchangeMailboxEntry table until they have not been syncíd for 14 days.

You can use a reg key to change this time frame:

Under the registry key HKEY_LOCAL_MACHINE\Software\KVS\Enterprise Vault\Agents create a DWORD value called 'MarkAsDeletedAfterXDays' to a number greater than 0.  Run the test again, this time you should see in the event log that mailboxes with be marked as deleted after the registry setting rather than the default of 14 days.

I am not 100% sure it is still a valid key though. 

Ben_Watts
Level 6
Employee Accredited

Removing the entries from the ExchangeMailboxEntry table wont have that sort of effect on SQL, it wont blow it up or bring it to its knees.


If you wanted to limit it to just those entries in the error messages to be more surgical (nothing wrong with that) then just change or add to the WHERE clause in the query as per below:-

USE EnterpriseVaultDirectory
DELETE FROM ExchangeMailboxEntry
WHERE ExchangeMbxType = '1'
AND LegacyMbxDN IN (
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User1',
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User2',
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User3',
'/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User4'
)

Obviously change the LegacyDNs as needed.

 

Or as Tony says, try the regkey and see if that helps.

 

Sploinker
Level 2

Thanks folks!

Ben put me on the right track. I just wanted to make sure I could delete them from SQL. I hooked up with my SQL Admin and performed it this way which seemed to work the best:

USE EnterpriseVaultDirectory

DELETE FROM ExchangeMailboxEntry

WHERE MbxAlias = 'XXXXX' or MbxAlias = 'XXXXX', etc.

My primary goal was to stop the attempted connections from taking up my MAPI connections which is effecting my PST Migrations. Long story there!