No. of failed updates

[Lennnnny]

Hi all,

Keep seeing numbers in the "No. of failed updates" column in the MovedItemsUpdateSummary report. Systems are working fine. Is this an issue. How is this resolved or tested?

6- Exchange 2003

3 - EV 8.5

Outlook 7.5

[JesusWept3]

On the EV server, if you go to your install dir and the \Reports\MoveArchive\ folder, can you find the report and see what errors its giving for the failed items?

[Lennnnny]

I would but there is no such folder...."E:\Enterprise Vault\Reports\Exchange Mailbox Archiving" is where the report resides. There is no error just instead of a zero there are number indication that the move update has failed....

[JesusWept3]

Check the source server, so you are probably looking at the destination servers reports, the others for the move and the verification should be the source server (the server it moved from)

However it could just be that the shortcuts it was looking to update don't exist anymore or there were genuinely some errors updating them, but you would see some kind of events in the event log

[CFreeX]

Failed to update items will get poison pilled after # of retries. It means that shortcut location in user mailbox and Archive Explorer will be different. Check the a6 in MSMQ, did you purge the queue recently? If you see a large # of failed item count for all mailboxes in report continuously then you should open a case with support to troubleshoot. 

[Lennnnny]

Ok, found the folder (\Reports\MoveArchive)  that JesusWept2 mentioned on the "source server" it was completely empty? Also, I only have one "move archive task" in my site is the normal?

A6 in MSMQ is empry on all 3 EV servers.

[JesusWept3]

Typically you have one move Archvie Task for each server you are moving from but it only gets created when a user is queued for that server

So for instance lets say you have

SiteA
 - EVServer1
 - EVServer2
 - EVServer3

SiteB
 - EVServer1
 - EVServer2
 - EVServer3

If you moved users from EVServer1.SiteA.com to EVServer1.SiteB.com
you would have just the one Move Archive Task on EVServer1, the rest of the servers in SiteA and SiteB would not have a move Archive Task

If you moved users from EVServer1.SiteA.com to EVServer2.SiteB.com
And EVServer2.SiteA.com to EVServer2.SiteB.com, you would have the Move Archive task on EVServer1 and EVServer2 in SiteA only.

In this circumstance you would typically have 2 text files on the source server, one for the move, and one for the verification.

So lets say you move an archive from EVServer1.siteA.com -> EVServer2.siteB.com

Step 1:  Copy the items
First thing that would happen is that the Move Archive task would use the ECM API to start moving items across to the archive that you selected in the destination site, it would also make sure that the SQL Records in the new site match whats in the old site.

Step 2: Waiting to Update Shortcuts
Updating shortcuts is typically what makes the Move Archive task take so long, because the Archiving Task for the user in the destination site has to process the mailbox to update the shortcuts.

So typically you move the archive throughout the day, and then at night when they regular archiving schedule kicks in, the task will see that it has to update the shortcuts and once done will mark it as complete.

So this is not the Move Archive Task that performs this, but the actual archiving task.
The Move Archive Task however will check every 30 minutes to see whether its completed.
So if you start the Move Archive at 9am, it takes an hour to copy, you will then see the following every 30 minutes to check if the shortcuts are being updated

15/02/2012 14:43:23 Step 2 of 5 - Waiting to update shortcuts.
15/02/2012 14:43:23 Entered a sleep state for 30 minutes. Reason: Waiting for shortcut processing. This will occur during the next scheduled or manual run of the archiving task on the destination server.
15/02/2012 14:43:23 Stopped Processing

15/02/2012 15:14:02 Started Processing
15/02/2012 15:14:33 Step 2 of 5 - Waiting to update shortcuts.
15/02/2012 15:14:37 Entered a sleep state for 30 minutes. Reason: Waiting for shortcut processing. This will occur during the next scheduled or manual run of the archiving task on the destination server.
15/02/2012 15:14:38 Stopped Processing

Once the task has run and updated the shortcuts, it will then be flagged in the source archives as updating.

Step 3: Updating Shortcuts
If the Move Archive Task detects that the shortcuts are still being updated then it will simply wait, but will post this message so you know that things are at least happening, its all up to the source server to continue and complete before the move archive task can move on

15/02/2012 15:43:57 Started Processing
15/02/2012 15:44:06 Step 3 of 5 - Updating shortcuts.
15/02/2012 15:44:06 Entered a sleep state for 30 minutes. Reason: Shortcuts are being updated.
15/02/2012 15:44:06 Stopped Processing

After this has been completed and the Move Archive Task wakes to check the status again, it will then post the following event in the move text file:

15/02/2012 16:15:33 Started Processing
15/02/2012 16:15:39 Shortcut update summary: Total shortcuts to be updated: 500. Updated shortcuts: 500. Errors: 0.
15/02/2012 16:15:39 Step 3 of 5 - Updating shortcuts - has completed successfully.

If there is an actual error, it would look like this in the main log file

14/01/2012 10:00:53 Total errors of the Step 3 of 5 - Updating shortcuts: 1186.
14/01/2012 10:00:53 First 100 errors of the Step 3 of 5 - Updating shortcuts will be reported in the error report file.
14/01/2012 10:00:53 For information on any errors encountered during this run of Move Archive, see the following file in the “Reports\Move Archive” folder:
MoveArchive_TestUser2_20120114100053_Errors.txt

Step 4: Awaiting Backup
Depending on how the MoveArchiveTask.exe.config is configured, you can choose to wait for your items to be fully secured and backed up in the destination archive, so that when its done, you can safely delete the source archive knowing that the new archive has been backed up properly.

So if you went ahead and deleted the source archive and then suddenly the destinations disks died completely and you had to go to last nights backup, you would have lost that data, you'd have to restore your source site to get the data back then perform the move archive again.

In my config file I don't tell it to wait for the backup so this event is posted immediately after step 3 completes.

15/02/2012 16:15:40 Step 4 of 5 - Waiting for destination backup - completed.

Step 5: Verification
This step will basically go through the source and destination archives and make sure that everything matches up, that it doesn't have to copy anything or fix anything up, typically its a fairly quick process and is performed by the Move Archive Task

15/02/2012 16:15:42 Step 5 of 5 - Verifying moved items.
15/02/2012 16:16:37 Verification summary: Total items: 547. Items verified successfully: 547. Verification failures: 0. Item re-copies: 0. Items already deleted from destination archive: 0.
15/02/2012 16:16:37 Move Archive task has completed successfully.
15/02/2012 16:16:37 Stopped Processing

Note that the Verification process writes out to the same \Reports\Move Archive directory in a file called
MoveArchive_[archiveName]_yyyyMMddHHmmss_Verification_0001.log

i.e. : MoveArchive_testUser1_20120215161637_Verification_0001.log

The contents typically look like this:

#Move Archive Verification Log (For more information about the contents of this log file, see the following technical note on the Enterprise Vault support web site: http://entsupport.symantec.com/docs/338002)
#Version: 9.0.3.0
#Source Archive: TestUser1 (1B0AB32614C80F844AE363D032D37364A1110000siteA)
#Destination Archive: TestUser1 (1D52A6556019377429DB8196CF3F155021110000siteB)

Date Score Threshold or Maximum Score Type Source value Destination value Comment
2012-02-15T16:15:42-05:00   Open   Logging Level:Failures Max Log Size:1024KB
2012-02-15T16:16:37-05:00   Close   Number of entries processed - Failure entries: 0 Pass entries: 547

The Errors log file is a very large and complex log file and some sample outputs would look like this:

#Move Archive Error Log (For more information about the contents of this log file, see the following technical note on the Enterprise Vault support web site: http://entsupport.symantec.com/docs/338002)

Move Archive subtask 174E69EDEC50D7F468324720152AF96F01013700siteB- 01/14/2012 10:00:53 AM
Phase Item ID Source saveset ID Destination saveset ID Processing  error? Error code Error description Extended error code Extended error description Destination item deleted? Destination item deletion reason Source item deleted? Source item deletion reason Verification failure? Item subject Item folder path Item sent/delivery time Source item retrieval Destination item retrieval Source item URL Destination item URL 
Updating shortcuts 201201148198127~201106081940020000~Z~21460DE852208FC665957AC0A5A2ABF1 - - Yes - Could not retrieve new item properties from destination archive. - - No - - - No *** ***** ******** **** ****** \subFolder1 2011-06-08T19:40:02.000Z - - - - 
Updating shortcuts 201201147507557~201105311322220000~Z~3009AC615FBFD19D6E59947BBD24CE51 - - Yes - Could not retrieve new item properties from destination archive. - - No - - - No *** ***** ******** ******** ********** \SubFolder1 2011-05-31T13:22:22.000Z - - - - 

[Chris_Warren]

JW2 - alot of good Move Archive info there, but it is sounding like to me that we are looking at an issue regarding the nightly shortcut update processing of the mailboxes, which CareFree discussed.  I would suggest a Dtrace of ArchiveTask and perform a Run Now on the Archive Task in question against one of the users from the failure logs, using the Shortcut Processing option. 

Then also monitor the A6 queue to confirm that items get added and process out.

Dtrace should tell us something.

For the most part, the only thing I'd be concerned about if the shortcuts are not 'synching' with the database (Archive Explorer viewing), is if you utilize Retention Folders (using EVPM, you can set different retentions on folders).  If shortcuts are being moved, say, from Inbox using a default retention of 1 year, to folder "5 Year Retention which had a 5 Year retention configured, then the items will change to have the new retention.  If the Moved Items function is not working, then these items will not change in the database, potentially allowing these items to expire sooner than expected.

I hope this helps.

[JesusWept3]

wow i really need to learn to read

[Prone2Typos]

Hey I just wanted to follow up to see if you were able to identify what the cause of this was. If you were could you share and flag it as resolved please.

Many thanks

[Lennnnny · Accepted solution]

I will follow-up shortly when I hear back...Thank you for all your assistance

[Prone2Typos]

Hey Lennnnnny ... how did the case go. Was this resolved? If so will you share the resolution and mark it as such? Thanks in advanced for sharing.