cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

Mailbox not vaulting

dorlow1
Level 3

I have one user that I am attempting to vault.  When I first received the request, I added the user to the Windows sercurity provisioning group that added user to be provisioned for EV.  I then synced the mailbox and started the forced archive.  When the request came in, the user's mailbox was close to 100 GB!  The mailbox is now down to 30 GB and 59 GB is in the vault.  But the policy the user is assigned to moves all IPM.Note items older than 60 days to the Vault.  I impersonated his mailbox in OWA and he still has many items older than 60 days in his mailbox.  I've forced vaulted him many times.  Nothing more is moving to the Vault.  Earlier today, I disabled him for Vault, zapped both the archive and his mailbox and re-enabled him.  Still nothing moving to vault.  

I've followed this link.

https://vox.veritas.com/t5/Articles/Troubleshootin...

The user is still part of our 60 day provisioning group.  (I uploaded an image showing he is...)

His mailbox is not hidden in the GAL or disabled in AD.

He is not disabled for archiving.  I check that by attempting to disable someone.  If they're not provisioned at all, I can't find them to enable or disable.  But if I can disable someone, I know they're enabled.  (I then just cancel out of the disable user wizard.)

The user is still on the same mailbox server as then the ticket came in.

About this entry...

Wrong mix of policy settings?

Sometimes in a purely quota based archiving situation it might seem like items are not being archived, but really that might be perfectly normal.

We don't have quotas, so this is not it.  We don't have Symantec support anymore.  But Symantec used to always focus in on the quota for a user and I'd have to overly disprove them that there are no quotas.  They'd pull out the dtrace and say, the user does have a quota because dtrace shows it.  I'd show them over and over, no they don't.  After an hour or so, they'd drop it and we'd find the problem elsewhere.  But here's the proof...

[PS] C:\Windows\system32>get-mailbox user | fl *database*,*quota*

Database                     : DAG02DB10
UseDatabaseRetentionDefaults : False
UseDatabaseQuotaDefaults     : True
ArchiveDatabase              :
DisabledArchiveDatabase      :
ProhibitSendQuota            : unlimited
ProhibitSendReceiveQuota     : unlimited
RecoverableItemsQuota        : unlimited
RecoverableItemsWarningQuota : unlimited
UseDatabaseQuotaDefaults     : True
IssueWarningQuota            : unlimited
RulesQuota                   : 64 KB (65,536 bytes)
ArchiveQuota                 : unlimited
ArchiveWarningQuota          : unlimited

[PS] C:\Windows\system32>get-mailboxdatabase dag02db10 | fl *quota*

ProhibitSendReceiveQuota     : unlimited
ProhibitSendQuota            : unlimited
RecoverableItemsQuota        : 30 GB (32,212,254,720 bytes)
RecoverableItemsWarningQuota : 20 GB (21,474,836,480 bytes)
QuotaNotificationSchedule    : {Sun.1:00 AM-Sun.1:15 AM, Mon.1:00 AM-Mon.1:15 AM, Tue.1:00 AM-Tue.1:15 AM, Wed.1:00 AM-
                               Wed.1:15 AM, Thu.1:00 AM-Thu.1:15 AM, Fri.1:00 AM-Fri.1:15 AM, Sat.1:00 AM-Sat.1:15 AM}
IssueWarningQuota            : unlimited

Below is a snippet of a dtrace on archivetask. (I doctored it up removing our company name and other identifiable information of the innocent...)

24254    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    FindExchServerDn - Exchange Server Found. DN: CN=TN001WEXMBX004,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xxx Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xxx,DC=net
24255    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    {GetExchangeServerValues:#4291} Exchange DN: [CN=TN001WEXMBX004,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xxx Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xxx,DC=net]|Exchange AD search path: [GC://TN001WGC11.US.xxx.net]|Exchange FQDN: [US.xxx.NET]
24256    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {CExchangePolicyCache::GetDefaultPolicy:#270} Default policy is [13C154C35E01BC147B294FA9B593FFEAF1012700EVSARCHIVE01 (Default Exchange Mailbox Policy)]
24257    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:H    {CArchivingAgent::ProcessUserEx:#18105} Beginning processing of mbx [], mode [RN_ARCHIVING, RN_SCPROCESSING (0x3)], report mode [False]...
24258    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    CMailboxUsage::SetMailboxInUse - Adding MbxDN to List:[/O=xxx EXCHANGE/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=USERNAME]
24259    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {CArchivingAgent::Initialise} (Entry)
24260    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {MigratedDominoItems::Reset} (Entry)
24261    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {MigratedDominoItems::Reset} (Exit)
24262    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    CPrioritizedItemTable::InitialiseTable(Age) - Setting up the table.  Size: [1000]
24263    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    CPrioritizedItemTable::InitialiseTable(Quota) - Setting up the table.  Size: [1000]
24264    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {CArchivingAgent::Initialise} (Exit) Status: [Success]
24265    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    CAA::PUEX() - Calling FindUser()|LegacyMbxDn = /o=xxx Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username|ExchangeFQDN = US.xxx.NET|ExchSearchPath = GC://TN001WGC11.US.xxx.net
24266    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    SanitizeUserName() - Sanitized username '/o=xxx Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username' to '/o=xxx Exchange/ou=Exchange Administrative Group \28FYDIBOHF23SPDLT\29/cn=Recipients/cn=username'
24267    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    FindUser() - Using searchbase GC://TN001WGC11.US.xxx.net
24268    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    FindUser() - Search filter: (&(objectCategory=user)(legacyExchangeDN=/o=xxx Exchange/ou=Exchange Administrative Group \28FYDIBOHF23SPDLT\29/cn=Recipients/cn=username))
24269    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    FindUser() - [homeMDB] = CN=DAG02DB10,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xxx Exchange,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xxx,DC=net
24270    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    FindUser() - [distinguishedName] = CN=username,OU=Users,OU=Corporate,DC=US,DC=xxx,DC=net
24271    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    :CArchivingAgent::ProcessUser() |Getting a MAPI session from the session pool |
24272    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    CMAPISession::GetMapiSessionFromPoolEx(AdditionalFlags = 0)
24273    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    CMAPISession::GetMapiSessionFromPoolEx: Exit status: 0x0
24274    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {CPolicyTargetGroupCache::GetUsersPolicyTargetGroup:#225} Found entry for user [/o=xxx Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username] in cache.
24275    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {CPolicyTargetGroupCache::GetUsersPolicyTargetGroup:#250} User [/o=xxx Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username] maps to policy [13D7DA27F340B0E4FBB432CC08A52C4591012p00EVSARCHIVE01] [xxx EVS Users]
24276    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    {CExchangePolicyCache::GetPolicy:#243} Returning policy: [13C154C35E01BC147B294FA9B593FFEAF1012700EVSARCHIVE01 (Default Exchange Mailbox Policy)]
24277    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    CAA::GUP() - /o=xxx Exchange/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username is using Policy : Default Exchange Mailbox Policy
24278    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:L    :CArchivingAgent::ProcessUser() |Creating the Entry ID of user mailbox to be processed |
24279    09:36:50.631     [8272]    (ArchiveTask)    <9252>    EV:M    :CArchivingAgent::ProcessUser() |Open users message store |
24280    09:36:50.756     [8272]    (ArchiveTask)    <9252>    EV:L    :CArchivingAgent::ProcessUser() |Getting the entry ID of the mailbox wastebasket or deleted items folder |
24281    09:36:50.756     [8272]    (ArchiveTask)    <9252>    EV:L    {CFolderHelper::GetSpecialFolders:#2060} Getting special folder Ids (Wastebasket, Outbox, Sent Items &c.), attempt [1] of [4]
24282    09:36:50.771     [8272]    (ArchiveTask)    <9252>    EV:L    {CArchivingAgent::ProcessOWARestoredItems()} (Entry)
24283    09:36:50.771     [8272]    (ArchiveTask)    <9252>    EV:M    ProcessOWARestoredItems: OWARestoredItemTimeout: 120 minutes
24284    09:36:50.771     [8272]    (ArchiveTask)    <9252>    EV:M    ProcessOWARestoredItems: Deleting item(s) restored on or before: 13:36:50 10/02/2017

 

I just opened the user's mailbox via Outlook and checked the types of emails that are old and verified they are mostly IPM.Note.  None are pending or any types of messages that are filtered out by the archiving policy.

9 REPLIES 9

CConsult
Moderator
Moderator
Partner    VIP   

what does the archiving report say?

WhichE EV version?

Running EV 9.0.2.  There is no "report" tab in the vault task that I hear the newer versions have.  The report log in the log folder I've never found to be useful.  The dtrace is way more useful.

I just checked.  The <ev install location>\Reports\Exchange Mailbox Archive\ folder hasn't created a log in about 8 months.  I've asked that question to EV support before we lost support and they didn't know why our servers weren't creating log files on some of the servers.  But they never troubleshot it.  They would just create a dtrace to fix the problem at hand.

Right now, I am getting messages to move to the vault, but at a snails pace.  If I force vault and specify only around 100, usually the 100 move to the vault.  But then to do this again, I have to restart the admin service and empty out the msmq storage queue.  The last one, I force vaulted 200 items. Only 120 moved over.  But at least somthing has moved over.  I hadn't gotten anything to go to vault for about 4 days until now.

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

I believe in 9 you only get a report when you run the task in report-mode.. The archiving reports are only available in EV10 and up.

Does this mailbox perhaps has some extremely large items, or very many items in general?

It might be this archiving task is overloaded, and cannot cope properly. It might be there is somethign amiss with the mailbox itself. It might be an idea (if you have multiple Exchange servers that is) to disable archiving for this mailbox, move the mailbox to another server, move it back, then reenable. The moving should align the mailbox again.

If that does not help, you might want to disable archiving again, export mailbox to PST, delete mailbox. Create new mailbox, import PST. enable mailbox, make sure to select the existing archive. Try again.

If possible, upgrade to 9.04 (latest 9 version)

Regards. Gertjan

I'm not sure of exactly what's in his mailbox.  I can't imagine it's anything different than the average user.  We have 46,000 users vaulted.  One user having this problem that I'm aware of right now.  I'll try your two suggestions.  They look pretty low risk and not too difficult.

Well, maybe I won't do those steps yet. Yesterday's forced vault moved 6 GB to the vault.  Granted, on most forced vaults, that would be to expected.  But for this mailbox, that's the biggest gain I've had in weeks.  The mailbox is down to 21 GB.  But I'm still sure more should've had moved.  I just impersonated his mailbox and he still has quite a few messages older than 60 days (which is the policy) in his Inbox alone.  He has one message back to 1/1/16.  I'll attempt another forced vault. 

One other thing, when I am having issues with the vault servers, I look closely at memory.  Our servers have 12 GB of RAM.  Vault support recommends 16 GB minimum.  I doubt the 4 GB extra would make a difference.  As soon as I start force vaulting, memory quickly within a half hour or so from 50% utilization to 100%.  Once it gets close, I've noticed I usually have about a 0% chance of vaulting a mailbox.  Sometimes it's our backup team running a process to backup the server.  The vault servers vault all night.  So, the backups take off right after the night vaults finish and run most of the day putting the vault stores in backup mode.  So annoying.  The whole vault farm was designed wrong. I wasn't here at the time.. granted if I would've been, I can't say I would've done it different.  Using them for the last year, I've figured out what they did right (very little) and what they did wrong (a lot of it..).  For how many exchange servers and Vaulted mailboxes, we have 160,000 mailboxes and 46,000 of them are vaulted.  But we have 2 exchange servers to 1 vault server.  I think they should be 1:1.  Then the night vaults could finish in half the time and the backups could finish in half the time and not put the vault stores in backup mode half of the day while users are using them.  But, the company isn't spending any more on a dying product they just want to get rid of as soon as they can.

 

But, it seems like this particular server the user is provisioned on has an issue where as soon as I force vault, the memory spikes and once that happens, it's over.  I've tried to follow all the high memory processes to the services and restarting the services and I get minimal gains.  I'll kill the backup process (backup team hasn't yelled at me yet.)  Then I restart the admin service because most of the EV processes are high on usage.  But the memory will free up by maybe 10%.  If I restart the server, it will be back at 50% utilization.

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

21 GB... that explains probably. I assume lots of items too? If EV is going to archive a mailbox, it first builds a list of items that might be eligeble for archiving. That can take (for a large mailbox) a while, and yes will spike memory.

EV is as far as I know not really a dying product... EV profits from CPU and RAM, if possible, add RAM. A 1:1 relationship is best indeed.

Good luck with this. Been there, done that.

 

Regards. Gertjan

A 21 GB mailbox in our environment is pretty typical.  When I started vaulting this mailbox, it was 96 GB which is one of the larger mailboxes I've vaulted (but not the biggest...)