Step 3 of 5 - Updating shortcuts - has failed with a fatal error.

[Richard67]

Hi,

The Enterprise Vault move Archive wizard gives the following error message after copying User Archive from an EV 9.02 to EV 10 server. 

28/11/2011 15:25:48 Started Processing
28/11/2011 15:25:49 Step 1 of 5 - Copying.
28/11/2011 15:41:46 Progress Statistics: Total items: 11461. Items processed: 11461. Errors: 0.
28/11/2011 15:41:57 Step 3 of 5 - Updating shortcuts - has failed with a fatal error.
28/11/2011 15:41:57 Could not determine the shortcut update task for the destination archive. Enterprise Vault will try again later unless the retry count has been reached. Exception: The specified sub task record does not exist.
28/11/2011 15:41:57 Move Archive task has failed with fatal error.
28/11/2011 15:41:57 Stopped Processing
 

All the users are using virtual vault.

So there are no shortcuts to upgrade.

Richard.

[Percy_Vere]

So I assume your mailbox policy is set to not create a shortcut - is that correct? 

Is the mailbox archiving task running on the destination server? I suggest a dtrace of movearchive whilst repeating the move and then post the log here.

[Richard67]

Percy,

Yes the policy is set to not create a shortcut.

And yes there is running a archiving task running on the destination server.

I will see if a can run a dtrace on this.

Richard.

[JesusWept3]

i dont suppose you did a restore of the destinations EnterpriseVaultDirectory database recently did you?

The way it should work is when you submit a Move Archive it creates a job in the Source sites EnterpriseVaultDirectory database in the subtask table, it indicates where the archive is moving to and all of the information as well as some counters or what not.

When it gets to the shortcut update part, it creates a SubTask entry in the Destination sites Directory database, and that subtask is simply update these shortcuts and then in the ExchangeMailboxEntry table, there is a column which links the mailbox to the newly created SubTask

So what sounds like might have happened is it got to that point, the users EME entry has the SubTaskID assigned to it, but when it does a lookup of that ID in the SubTask table, it doesn't exist.

You can run this query to make sure this is indeed the case

1. Open up a SQL Management Studio and connect to your destination SQL Server
2. Run the following query and note the 'MoveArchiveShortcutSubTask'
(It will look something like '1A4EC19212B3736418286F518A28466CB1013700evsite')

USE EnterpriseVaultDirectory
SELECT MbxDisplayName, MoveArchiveShortcutSubTask FROM ExchangeMailboxEntry WHERE MoveArchiveShortcutSubTask IS NOT NULL
 

3. Run the following query and see if you get any results

SELECT * FROM SubTask WHERE SubTaskEntryId = ''1A4EC19212B3736418286F518A28466CB1013700evsite'


 

[Richard67]

Hi, JesusWept2

The destination EV server is a brand new Enterprise Vault 10 installation.

This enterprise vault server is using another SQL server for his databases. (new)

The destination ev server is running in a other domain with a two way trust to the domain where the old ev server is installed.

Richard.

[Percy_Vere]

So does the subtask get created in SQL on the new SQL server as per JesusWept2?. As it's new then it's worth checking the EV service account has DBcreator role. 

Can you move an archive in the opposite direction successfully?

What version of EV are you moving the archive from? 

[Richard67]

Yes the ev user have the dbcreater rights on the destination ev server.

The archive seems to work fine when the user opens an achived item or search inside the vault store.

The source ev is version 9.02

and the destination 10

Can you take a look at the picture please.

The move wizard gives the error that both mailboxes have another GUID.

Richard.

[JesusWept3 · Accepted solution]

Ahhhh ok yeah this is a known issue that I've had in my environment as well So when you selected the archive and the destination to move it to, it didnt find the user in question right? And you manually had to select it? If that's the case, you have to start over again and edit the source sites ExchaneMailboxEntry table and change the mbxGUID so that it matches the destination site We have to do this only on a rare occasion, it should be fixed in an upcoming service pack though (not ev9 sp3)

[Richard67]

Hi JesusWept2,

The wizard is selecting the right mailbox on the destination ev server.

We don't need to select this manually.

Do you have another tip to fix this.

Richard.