Video Screencast Help

Automatic archiving of Hidden & AD-Disabled mailboxes

Created: 01 Mar 2013 • Updated: 05 Mar 2013 | 21 comments
This issue has been solved. See solution.

Hello. As a part of our outtake process, we disable leavers' AD accounts, hide their address from the GAL and move their mailbox to a special OU.

For years, I have been using the ProcessHiddenMailboxes = 1 and ExcludeDisabledADAccounts = 0 values in the EV server's registry.

AND I have a SQL Update query that runs every hour and changes the MbxExchangeState field to 0. 

(And I even have recently added one more Update query to change ADMbxFlags to 0)

The problem is that these hidden/disabled users are NEVER archived automatically when the archiving task runs on schedule.

I always have to manually right-click on the archiving task and do Run Now and select the leavers to be archived.

After doing this for about 7 years it is kind of getting old.   Is there ANY way to make this work automatically?

Comments 21 CommentsJump to latest comment

Rob.Wilcox's picture

What version of EV server are running?  And the ProcessHiddenMailboxes should be all you need if that's all that has happened (ie their mailbox has been hidden)


Version 9 SP2

The hidden/disabled mailboxes get synchronized automatically no problem.

But I never see them getting archived automatically.


Easy. Their mailbox archiving policy is "zero-day". So I should be able to see whether their messages start turning into archive pending shortcuts. But they are not.

When I go and check what policy is assigned to their mailbox - it shows the correct zero day policy.

TonySterling's picture

So your run now archives items from the mailbox but scheduled doesn't?

Very strange indeed.  Are there any events in the EV app log during the archive run, in particularly warnings about those mailboxes?


A manual Run Now archives then like a charm, but scheduled doesn't.

Been looking for event log warnings or errors related to these mailboxes, but found nothing.

Chau Tran's picture

After you run the SQL to make the changes, does the Provisioning Task run before or after the scheduled archiving run?

When the Provisioning Task runs it resets the SQL changes back to Hidden and Disabled again as stated in the technote below:

I guess what I would like toknow is all the stages of your changes from first to last e.g.

SQL changes.

Provisioning task run.

Scheduled archive run.


Chau Tran



The SQL query runs every hour to zeroes out the necessary fields.

Chau Tran's picture

does the Archiving Task get restarted after each SQL changes?


Chau Tran



not after each. The SQL update query runs every hour

The Archive Task gets restarted a couple of times per day during the backup operations.

Rob.Wilcox's picture

I think the bit that you might be breaking then is the SQL updates.  You're asking EV to process hidden mailboxes, but you're setting the flag to say that it's a 'normal' mailbox, but they're not.

Have a look at:

Further to that on my Exchange 2003, EV 10.0.3 system I just simply set the registry key for processing hidden mailboxes, and restarted my EV servics, then hid a mailbox [whilst I was logged into it from Outlook]...  ran provisioning...

Mailbox now shows as: 

MbxArchivingState = 1

MbxExchangeState = 2

ADMbxflags = 1

.. in the ExchangeMailboxEntry table in the Directory Database.

.. and then ran the mailbox archiving task at it's scheduled time (ie no 'run now').

It processed the mailbox fine.

So to summarise.. set the registry keys.. and that's all.  (No SQL stuff)

I'd suggest that running the SQL queries is affecting the scheduled task (but that run now is happy to override the values).

Also if you want to process company leavers take a look at the QUADROtech Archive Leavers tool.

By the way, do you have the flag on the policy set to archive unread items? Maybe that's the bit that is confusing things?

If doing those things doesn't work, then maybe a DTRACE would shed some light on things.  You could add a filter (so as not to have an enormous DTRACE file) using some of the bits of this perhaps...

1006525 16:50:29.378  [3164] (ArchiveTask) <916> EV:H {CMailboxUsage::SetMailboxInUse:#196} Added [/O=EV TRAINING/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=JEFF1] to list of mailboxes to be processed. List now contains [5] mailboxes.

1006526 16:50:29.378  [3164] (ArchiveTask) <916> EV:L {CExchangePolicyCache::GetDefaultPolicy:#272} Default policy is [17E238F3AE05910489026E797A80524A61012700ev1a.EV.Local (Default Exchange Mailbox Policy)]

1006527 16:50:29.378  [3164] (ArchiveTask) <916> EV:L {CPolicyTargetGroupCache::GetUsersPolicyTargetGroup:#225} Found entry for user [/o=EV Training/ou=First Administrative Group/cn=Recipients/cn=jeff1] in cache.

1006528 16:50:29.378  [3164] (ArchiveTask) <916> EV:L {CPolicyTargetGroupCache::GetUsersPolicyTargetGroup:#250} User [/o=EV Training/ou=First Administrative Group/cn=Recipients/cn=jeff1] maps to policy [1B123E86FDAD5CE41B5D46E4BEAABCD731012p00ev1a.EV.Local] [prov1]

1006529 16:50:29.378  [3164] (ArchiveTask) <916> EV:L {CExchangePolicyCache::GetPolicy:#245} Returning policy: [17E238F3AE05910489026E797A80524A61012700ev1a.EV.Local (Default Exchange Mailbox Policy)]

1006530 16:50:29.378  [3164] (ArchiveTask) <916> EV:H {CArchivingAgent::SetPolicy:#23365} [/o=EV Training/ou=First Administrative Group/cn=Recipients/cn=jeff1] is using policy [Default Exchange Mailbox Policy].

1006531 16:50:29.378  [3164] (ArchiveTask) <916> EV:M {CArchivingAgent::ProcessMovedItemsInFolder:#25944} processing moved items in folder [\Inbox\1000 items] for user [/o=EV Training/ou=First Administrative Group/cn=Recipients/cn=jeff1]

1006532 16:50:29.378  [3164] (ArchiveTask) <916> EV:M {CArchivingAgent::ProcessMovedItemsInFolder:#25946} archive id for user [14CE58529509B8546ACC5E8948B254CDF1110000ev1a.EV.Local]

1006533 16:50:29.378  [3164] (ArchiveTask) <916> EV:M {CArchivingAgent::ProcessMovedItemsInFolder:#25947} archive folder id for folder [17A0BDE0AC188DC44A69790D34C71C2F51110000ev1a.EV.Local]

1006534 16:50:29.378  [3164] (ArchiveTask) <916> EV:M {CArchivingAgent::ProcessMovedItemsInFolder:#25948} retention category for folder [10223FE2A4886AF448B794B63BEAB80A21b10000ev1a.EV.Local]

1006535 16:50:29.378  [3164] (ArchiveTask) <916> EV:M {CArchivingAgent::ProcessMovedItemsInFolder:#25950} getting hold of a mapi session and opening the user message store

Yep, we archive Unread items.

About the SQL field value... the only way EV knows that a mailbox is hidden is because the provisioning task "sees" that in AD and sets the SQL field.  If I subsequently change SQL field to 0, then EV "thinks" that it's a normal mailbox.

I have always been under impression that the SQL fields had to be zeroed out on a regular basis. Based on this:

IMPORTANT: Each time the Provisioning Task is run (EV7 and later versions) or theSynchronization process is executed (EV6 and earlier versions), the MbxExchangeState value of all hidden mailbox records is changed back to "2".  Therefore, each time you wish to enable newly hidden mailboxes, it will be necessary to repeat step 2.  The Provisioning Task and Synchronization process usually run twice a day at noon and midnight according to schedule.

Rob.Wilcox's picture

As I said .. my opinion... don't monkey around with SQL there is no need.

Hide the mailbox from the GAL..

Provisioning task runs..

Scheduled run should pick up the mailbox.

I am (reasonably) sure that the SQL stuff is interferring with the scheduled run .. and the 'run now' is overriding things.


But then if I have to do an occasional Run Now, without monkeying with SQL I don't see the mailboxes that I want to manually archive.  :)

TonySterling's picture

I think what Rob is trying to point out is that you just need to run the sql to enable the mailboxes.  Once the mailboxes are enabled it doesn't matter what their state is in SQL because you have the registry key set.


I see... makes sense, kind of  :)

But then on the other hand if I Don't zero out the SQL field, I am risking that some users would never get EV-enabled.

Most of our users are EV enabled while they are with the company.  But there are some that aren't because the local IT forgot to add them to an AD group that feeds into a provisioning group.   Or some are not EV enabled intentionally because of their VIP status (don't ask).

But when someone leaves the company, they must be Zero-day archived.  So for some users this is the only chance to be EV-enabled - on the way out.

TonySterling's picture

I understand, so does the leavers provisioning group auto-enable?


Yep. The outtake provisioning group feeds from the special OU where we move all the leavers, and it is set to auto-enable.


OK, thanks guys.

I stopped tinkering with SQL and let the things take their natural course after the provisioning task ran.

HIdden/Disabled mailboxes started to be automatically archived when the Archival task runs on schedule.

That's good.

But on the flip side I can no longer manually archive hidden/disabled mailboxes - they don't show up in the Run Now dialog (unless I tinker with SQL again).

And also I am pretty sure that if I have a hidden/disabled mailbox that has never been EV-enabled, it will not be automatically EV-enabled.

TonySterling's picture

Good deal, for the mailboxes that have not been enabled you will need to run the sql script for them to be enabled.  Once they are enabled they will be processed.