Update Rollup 6 for Exchange 2007 SP3

I just spotted that Exchange 2007 SP3 Rollup 6 has been released.  As many people will know, the Symantec Enterprise Vault QA and Certification teams don’t explicitly test and certify individual rollups, so please ensure that you test it in your environment before going through the upgrade on production machines.

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

 

LastPSTSearch

Following on from the discussions around Client Driven PST Migration is a policy setting which I visit quite often in my test environment.  The setting is shown below in the Vault Admin Console:

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.

Testing WMI

I looked at an issue the other day where it looked like WMI wasn’t working.  In order to test it, I used the following simple VBScript:

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.

PST Migrated Email

I have been looking into PST Migrations for the last couple of weeks, and one of the good things that I discovered was the fact that an email can be sent when a PST is successfully ingested into Enterprise Vault.

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.

A Single Line of Client Trace

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

Policy Assignment

A question which is asked quite often is how to find out which policies are assigned to a user.  It is quite easy to see this in the VAC, as follows:

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.

iBooks 2 – Life on Earth

 I am still waiting for the 51 pages, 965 Mb file to download!

 

 

Changing to SSL for EV

A question which arose a few weeks ago related to what needs to be done when changing Enterprise Vault from port 80 for the EV Virtual Directory to port 443, and SSL.  When it’s changed in the VAC, and in IIS, initially with Exchange Mailbox Archiving there isn’t anything particularly that needs to be done.

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.

Public Folder Referrals–and why they can be bad

A referral in Public Folder-land is when the client (eg Outlook, and the end-user) request a public folder which is not homed on the information store that Outlook is connected to.. it’s home public folder information store.

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.

RamMap

SysInternals tools are just plain and simply awesome.  A colleague of mine (Mr Juster!!) sent me a mail about this little tool called RamMap:

http://technet.microsoft.com/en-us/sysinternals/ff700229

As with most SysInternals tools the download is tiny at just 279 Kb.  When you run the tool, after a few seconds you’ll see a screen like this:

You can use the tool to monitor consumption over time, and you can also save (and load) snapshots of information for review and analysis.

I’ve tried it out on Windows 7 x64 and on an XP machine (though the information on the web site says it needs Vista and higher)

It’s also pretty useful to run on a server installation, to see what is consuming RAM.