I know I'm not the first one who has problems in retrieving archived attachments, but I have not found a similar constellation.
In our case we are centralizing different IT departments of several companies.
So we have a partner side with Exchange 2010 and EV10 and on our central side we got as well Exchange 2010 and EV10
Unfortunately we will not directly migrate the archives to the central Vault. For sure I have adjusted the desktop policies for Outlook and entered the corresponding weburl of the old EV site.
Migrated users can open all old archived messages, but the attachments are not within.
They get the well known error message in the grey bar that "there was an error loading this item" with the name of the attachment in arrow brackets.
Opening the archived messages with attachment in Browser Search works.
Have you got any idea, where to start the investigation?
What version of Outlook? This happens for all migrated users on different workstations?
If you click on the banner does the pop-up provide a further error code?
Set logging to Maximum and grab a client trace: How to perform a client trace for Enterprise Vault (EV) within Outlook: http://www.symantec.com/docs/TECH38096
I have now fetched a client trace. I can only find in it that the archived item from the link will be downloaded, but I see no hint that it tries to fetch the attachment. Perhaps you can see more in it?
We have migrated with Quest Migration Manager. So I hope that it contains the necessary hidden message.
As the mailbox was enabled before and has been enabled now in the new environment again, should I find two hidden messages?
How can I check this?
Like mentioned it affects all migrated users, so zapping for all would be a mess.
The attachment side of things will be seen in a Dtrace, you wont really see it in a client trace.
What you really want to do is grab a Dtrace and client trace (both running at the same time) at the time of recalling one of these problem items.
How to Dtrace (Look for 'Command Line') - http://www.symantec.com/docs/TECH38122
Processes to Dtrace will be:-
Find the line in the Client Trace starting with 'Downloading', here you will find the Saveset, take the LAST part of the saveset (known as the TransactionId) and search the Dtrace log for that TransactionID, from that you should be able to follow the recall process through from there to see what is happening.
I have been very busy, but today I was able to do the client trace and the Dtrace for StorageOnlineOpns and the W3wp.
I could find the events in the client trace and compared them to the serverside.
From my understanding the problem is that the newsite and the centralsite got the same vault site alias.
On the newsite the vault site alias and the server dns alias are even the same with "archive"
For the centrasite vault site alias is as well "alias" but the server dns alias differs.
So as I already have entered the WebAppURL for the newsite, but it as the alias is the same, EV tries to lookup in the own site where the alias is matching, but it does not find the savesets.
Is it possible to establish a workarround for this, rather then migrating the all the archives to the centralsite?
not sure how you ended up with two identically named aliases since DNS wouldn't allow that but a temporary workaround could be a hosts file entry on the workstation
Like I said before we are consolidating different sub companies. Not all of them belong to the same AD forest. So this newsite got it its own (trusted) forest. So there is no general issue in DNS.
But we are talking here about the vault site alias anyway which must not be similar to the server DNS alias... and in the squared brackets the vault site alias should be set, right?
So on our central side a shortcut link looks like this.
On the newsite like this:
unfortunately we did no proper checks and afterwards it turned out, that both Vault sites are called "archive".
I know the issue could be fixed by migrating with third party tools. Is there a possibility to use the move archive feature,
although the sites alias are the same?