Vault Cache & Virtual vault not getting enabled

[AKL]

Hello

This one is probably going to be an easy one - I am feeling I am missing something small whcih is causing this issue.

We've vault cache enabled in our Enterprise vault 9.0.1.1073 environment for a group of users using Desktop policy. Yesterday I felt like testing virtual vault for a sub-group of those users so...

1. I configured a provisioning group for 4 users 2 of which had vault cache enabled & 2 didn't. Ranked this PG as 1.

2., Configured a desktop policy with vault cache & virtual vault enabled for above mentioned provisioning group.

3. Ran provisioning task in normal mode. Made sure the 4 users were showing to get the new desktop policy in provisioning task reports.

4. Manually synced the mailboxes.

Now the 2 users who had vault cache still have vault cache but the new 2 users haven't got vault cache options on thier side yet. And neither of 4 have any option for virtual vault on the client side.

I've attached a quick screen-shot of settings for reference.

Anything I could be missing here? (This should've been pretty straight forward effort)

Thanks in advance.

[JesusWept3]

Have you set it to show the wizard or to just automatically enable?
Also is the user in cached mode or not?

I take it if you go to the vault cache properties manually on the users desktop it comes up with the set up wizard, or does that not show either?

[AKL]

I've configured the policy to show wizard to end user on first time and user is in cached mode.

And for 2 users who do not have vault cache, it doesn't shows vault cache properties option itself in toolbar. (So I guess it is does'nt show either)

I am trying to reset vault cache on one of the remaining 2 user who have vault cache to see if it helps anything.

[JesusWept3 · Accepted solution]

try running a scanOST, i've seen it happen before where the Outlook doesn't download the updated EV hidden message, and also i'm guessing they have the correct EV Addin?

[JesusWept3]

oh and i know this may be highly unlikely, but they're not in Outlook Anywhere (RPC Over HTTP mode) and its set to disable the vault cache/virtual vault functions right? thats also in the desktop policy under advanced

[AKL]

Thanks Jesus

I am running ScanOST now and no we don't leverage RPC/HTTP features in our environment (disabled on CAS Servers itself)

Next steps would be I guess to rebuild OST or try to disable mailbox for archiving - zap - re-enable.

[AKL]

For troubleshooting purposes I am ok but is it normal behaviour?

Considering it is just 4 users atm (out of which 1 is myself ;) - We're on safe side but if on some later date we need to roll out to some 1000 users, I am not sure if all steps will be feasible or right approach that time.

[AKL]

So I disabled archives for the 4 users - Zapped their mailboxes to remove old EV system message - Enabled their mailboxes again.

Now i see things as i should've been in first place.

So question remains - what if we configure this for 1000+ users - Should we be expecting same behaviour?

[Tremaine]

This behavior is not the norm. It does sound as though the hidden EV message failed to be updated. Would be worthwhile testing to see if this occurs again and then getting some trace to investigate further.

[AKL]

I will try to enable virtual vault in similar fashion for some more mailboxes. Any particular component we're looking to log on from backend (thinking to run DTrace simply on Provisioning issue {Exchange} via Admin console)? or client log will be needed here?

[Chris_Warren]

If it is a situation where the hidden message isn't being updated, I believe it could be one of two things:

a. The hidden message was updated server-side, but there was an issue with it updating in the local OST.
- If this happens again, try setting up the user on another box, or recreate the Outlook profile to see. If it does show the updated version of the hidden message, then it seems to be an issue between Exchange and Outlook.

If the hidden message is not updated on the server level, then perhaps it may be some permissions issue on the mailbox present on the server.

Hope this helps.

[AKL]

Given it was tested for 4 users on 4 different workstations, I tend to go with server side issue.

Any particular permission I should be looking for here?

[AKL]

I tried with few more users and different desktop policies - Still the same result.

Provisioning report shows correct/updated desktop policy and has a result of Updated Mailbox along side with it but users do not change on their side.

It seems like an environmental issue now - But I cannot nail down where/why. Any thoughts?

[AKL]

34724 14:23:43.374  [3652] (EvExchangePolicySyncTask) <11020> EV:L CBaseDirectoryServiceWrapper::CreateDirectoryService() - Successfully communicated with an EV Directory Service on the local machine
34725 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-M {ExchangePolicySynchronization.ProcessSearchResults} Processing search result [LDAP://SERVER-DC01.contoso.com/CN=Duck\, Donald,OU=Users,DC=contoso,DC=com]
34726 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} JrnlSearch: 7 email addresses to compare
34727 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-L {ADObjProperties..ctor} Loaded properties for 'User' object [LDAP://SERVER-DC01.contoso.com/CN=Duck\, Donald,OU=Users,DC=contoso,DC=com]:|objectCategory = [CN=Person,CN=Schema,CN=Configuration,DC=com]|distinguishedName = [CN=Duck\, Donald,OU=Users,DC=contoso,DC=com]|displayName = [Duck, Donald]|legacyExchangeDN = [/o=Contoso/cn=Recipients/cn=dduck]|proxyAddresses = [X500:/o=Contoso/cn=Recipients/cn=dduck]|mailNickname = [dduck]|msExchMailboxGuid = [System.Byte[]]|whenCreated = [3/1/2006 4:26:09 PM]|msExchUserAccountControl = [0]|msExchHideFromAddressLists = []|homeMDB = [CN=Database01,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=com]|l = [Contoso]]|company = [ -]|c = [US]|co = [United States]|countryCode = [0]|department = []|employeeType = []|givenName = [Donald]|sn = [Duck]|physicalDeliveryOfficeName = []|title = []|msExchMasterAccountSid = []|mDBUseDefaults = [False]|mDBStorageQuota = [946617]|mDBOverQuotaLimit = [1049017]|mDBOverHardQuotaLimit = [1099193]
34728 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: 7 email addresses to compare
34729 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-M {UserProperties.LoadProperties} [SR] Added SMTP address: dduck@contoso.com
34731 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: Looking up address minie.mouse@contoso.com
34732 14:23:43.390  [3652] (EvExchangePolicySyncTask) <4132> EV-M {ExchangePolicySynchronization.UpdateMailboxEntry} Updated record for mbx [/o=Contoso/cn=Recipients/cn=goofy]
34733 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-M {UserProperties.LoadProperties} [SR] Added SMTP address: dduck@contoso.com
34734 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5248> EV:M CBaseDirectoryServiceWrapper::CreateDirectoryService() - Entry [m_nNumTries = 40]
34735 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: Looking up address
34736 14:23:43.390  [3652] (EvExchangePolicySyncTask) <4132> EV-H {ExchangePolicySynchronization.UpdateMailboxEntry} Leaving
34737 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-H {ExchangePolicySynchronization.UserAlreadyFailedProcessing} Entering
34739 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: Looking up address
34740 14:23:43.390  [3652] (EvExchangePolicySyncTask) <4132> EV-H {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} Leaving
34741 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-H {ExchangePolicySynchronization.UserAlreadyFailedProcessing} Leaving
34742 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: Looking up address
34743 14:23:43.390  [3652] (EvExchangePolicySyncTask) <4132> EV-H {ExchangePolicySyncTaskProcessor.CheckControlEvents} Entering...
34744 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-H {ExchangePolicySynchronization.QueueUser} Entering..
34745 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: Looking up address
34746 14:23:43.390  [3652] (EvExchangePolicySyncTask) <4132> EV-H {ExchangePolicySyncTaskProcessor.CheckControlEvents} Leaving...
34747 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-H {ExchangePolicySynchronization.ProcessMbxStore} Entering
34748 14:23:43.390  [3652] (EvExchangePolicySyncTask) <6728> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} EVSystemMailboxSearch: Looking up address
34749 14:23:43.390  [3652] (EvExchangePolicySyncTask) <4132> EV-M {ExchangePolicySynchronization.ProcessCreateOrUpdateMailboxEntry} Processing user [CN=Mouse\, Mickey,OU= Users,DC=contoso,DC=com] with legacyExchDN [/o=Contoso/cn=Recipients/cn=MMouse]
34750 14:23:43.390  [3652] (EvExchangePolicySyncTask) <5772> EV-H {ExchangePolicySynchronization.ProcessMbxStore} Leaving