What did 2011 bring us for Enterprise Vault?

Of course there is a multitude of things that were done to the product during the year which were released to customers, as well as a lot of work in the background for future service packs, and major product releases yet to be shipped. 

Every person you speak to will probably have their own memories of EV during 2011.  This is just a few of the highlights that stick in my mind:

EV 9.0.2
Improvements to EVSVR

EV 9.0.3
IPv6
FIPS
Backtrace
All the post 9.0.2 client hotfixes, including the ability now for indexing on a workstation when Windows and Outlook versions are different bitness

EV 10.0
Many, many improvements, most notable is the 64 bit indexing engine, cloud storagee and FSA filter point.  For the client people amongst us, there is also support for Office 2011 on the Mac.

That concludes my list.  What is there that stood out for you or for your organisation?

And for 2012?

I am not really allowed to go into the details, but we should be seeing at least service packs for EV 9 and EV 10. 

Of course if any issues are found, then they can be discussed on the Connect forums, and worked through Symantec Support.

What this setting does is dictate at what interval the Outlook Add-in will scan for new PSTs.  It is the number of days between scans.

Assuming that the client has never scanned for PSTs when the Outlook Add-in starts, a few minutes later will see the PST Migration thread begin a scan of the machine.  This can either be the whole machine, or just folders underneath this users ‘Documents and Settings’ location.  When that scan is complete, the registry key LastPSTSearch is added, to the workstation, and the value is set to the current date.

Each time the PST Thread checks for work to do, it will also check the value of this particular registry key and if it’s further in the past than the policy setting, it will perform another scan for PSTs.

What this means to end users is that if they add a PST to their Outlook profile, either a new one, or one they’ve copied down from another location, then it might not start to get migrated for up to 7 days (by default).  That period can be adjusted by changing the policy, but you have to remember that scanning the machines file system can be a slow process so you probably don’t want to do it too often.

On error resume next

serverDnsName = "exch1.ev.local"

for each objOS in GetObject("winmgmts:\\" + serverDNSName + "\root\cimv2").InstancesOf ("Win32_OperatingSystem")

            wscript.echo "Name = " & objOS.Caption & " Version = " & objOS.Version

next

if err <> 0 then

            wscript.echo err.number

            wscript.echo err.Description

            err.clear

end if

The output will look something like this:

C:\temp>cscript wmi.vbs

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Name = Microsoft(R) Windows(R) Server 2003, Enterprise Edition Version = 5.2.3790

It might be useful to keep handy, in case you want or need to test it too.

If you recall there are several methods of ingesting PSTs:

* Server Wizard (just from in the VAC)

* Server Driven (locate, collect, migrate)

* Client Driven

* EVPM (i.e. scripted)

All of these take advantage of the ability to send out an email at the end of the ingest of the PST data.  The email is based on a template called : PSTMigrated.msg.  As an administrator you have to put that in the Enterprise Vault program folder, and you can customise it.

The message is sent for each of the migration methods provided the option to put shortcuts in the mailbox has been selected.

Just the other day I was writing a section of a new uber-Client-Tracing-Technote, when it was pointed out to me by one of the lead developers that I should explain what a simple, single line of Client Trace means. 

I wrote the section, and added it to the technote, but here it is outside of that, because it’s important.  Here is a single line of client trace:

16/12/2011 14:19:08.881[3368][L]: AddinStartup::MainStartup

16/12/2011 14:19:08.881
The date and time of the trace.  The date and time are logged in UTC.  So if the end-user workstation is in a different timezone, the trace files will always be constant.

[3368]
The thread ID of the thread logging the trace (ie performing the action).  The thread ID is recorded in the trace in decimal, and is in square brackets.  It is worth remembering that it is in decimal, as when reviewing a user dump of Outlook with WinDBG for example, the thread IDs are in hexadecimal. 

At the beginning of the trace you will observe the thread termed the ‘main thread’.  As the Add-in starts up, other threads will be spawned to do specific tasks and will add trace to the trace file as necessary.

[L]
The next part is the level of verbositity. 

AddinStartup::MainStartup
The ‘line’ of trace, function name, descriptive text, etc.

Some trace also logs the result-code being returned from a function eg:

16/12/2011 14:19:08.560[3368][L]: CDesktop::FinalConstruct: 0×0

15/12/2011 11:21:26.855[3284][H]: A COM error occurred: 0×80040205

0×0 means a successful result.  Error results tend to be like : 0x8nnnnnnn, or 0xCnnnnnnn.  If a function does return an error you may see it logged in several places in the client trace as a low level function logs it, and the same error is then logged by the next level function, and so on, until at some level the error condition is hopefully handled.

It is also worth noting that the presence of an ‘error’ result like this does not necessarily mean that an error occurred.  For example the above ‘error’ can be logged when a retrieval/view of an archived item takes place with Vault Cache enabled.  The Outlook Add-in knows that this condition exists because the item is not in the content cache, and proceeds to handle that condition (by downloading the item, and inserting it into the content cache for future retrievals)

Photo Credit, schoschie

1. Expand the Site node
2. Expand the Targets node
3. Right click on Exchange, and choose ‘Display Policies Assigned to Mailboxes’
4. Filtering can then be done and a search performed. The results will be shown as per the screenshot below:

Note: It is possible to see the Mailbox Archiving Policy associated with each mailbox by running the Archiving Task in report mode, and reviewing the resultant report, but that doesn’t show the other policies, and incurs the overhead of having to scan the mailboxes.

Unless…

The caveat is that if you include a links to attachments in the shortcut that is created by mailbox archiving then that link will now not work.  You need to use the RestoreShortcutBody registry key as outlined in:

http://www.symantec.com/business/support/index?page=content&id=TECH47364

I tested this out just recently on a test mailbox, and the important things to note are:

• It *is* server intensive, and if you have collections enabled, Centera’s and that sort of thing, plan the operation carefully.
• You change the shortcut body in a report mode run against the mailbox (so you could do a handful of mailboxes at a time during the day, or weekend)
• It does not rebuild missing shortcuts.  Put another way the source is the Exchange mailbox, and the archiving task runs through the contents of that mailbox, all existing shortcuts in the mailbox are processed (as opposed to looking through the archive and going ‘that way’)

Prior to the change you can see:

I have hovered over the link to the attachments, and you can see it is http

After the change you can see the new shortcut:

Finally, if you DTRACE the Archiving Task whilst it performs this operation you will see entries like:

447 08:19:39.632 [7604] (ArchiveTask) <7188> EV:M CArchivingAgent::RestoreShortcutBody – Exchange shortcut found

In other words, if you see that happening in a trace…  and the EV Administrator says “Archiving is slow”…  the likely culprit is the registry key has been left in place with the value of it set to 1.

This referral happens automatically.  The referral is a redirection to a public folder server/information store which does contain a replica of the folder which is being requested.

The issue here is when that ‘user’ is the Vault Service Account, and, that is operating unlike a regular end-user as it is going to be getting these referrals during archiving runs, with multiple threads, and heavy amounts of activity to the public folders.

When the Public Folder Archiving Task starts to process targets it checks to see whether a referral/redirection is going to take place, and if it is going to, then the following is logged:

Event Type:    Warning
Event Source:    Enterprise Vault
Event Category:    Public Folder Task
Event ID:    3369
Date:        30/11/2010
Time:        08:59:00
User:        N/A
Computer:    evserver
Description:

 

Public folder redirection has been detected. This configuration can adversely affect performance and reliability. This redirection could be either of the following:

 

-The mailbox that is being used to connect to Exchange Server is being redirected to another Exchange Server.

-The Public Folder store is not homed locally on the target Exchange Server

 

Exchange Server: MAPLE

Public Folder Task: Public Folder Task For MAPLE

Redirected to Server: EXCH2003

This was first discovered with Enterprise Vault 2007.  The limits observed during the implementation of the event log warning was that you were allowed 5 referrals in 10 seconds. The sixth connection would result in MAPI_E_NETWORK_FAILURE.