FFS won't synchronise Outlook Exchange data

[matthes650]

Hi Zenju,

first I wan't to thank you for the great work done with FFS, have been using it for backup for quite some time.

Unfortunately, I ran into a problem with my new computer, sporting Windows 7 and Outlook 2007 with Microsoft Exchange. I sheduled a batch job for FFS to sync my personal folders and my outlook0.ost data to the backup drive (with admin rights), just as I've done it with the other computers before. But when Outlook is running during the backup, it fails to sync it through VSS and gives out the following error (in German, I can translate it into english if needed):

=============================

Die Datei
'\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy10\Users\Matt\AppData\Local\Microsoft\Outlook\outlook0.ost' kann nicht nach
'X:\Backup\Matt\Outlook\outlook0.ost.ffs_tmp' kopiert werden.

Fehlercode 2: Das System kann die angegebene Datei nicht finden. (CopyFileEx)

=============================

Funny thing being, it was working with other computers before without Microsoft Exchange. Have tried to restart VSS, but that didn't work as expected. Obviously FFS or VSS have a problem copying the data in use, do you have an idea how to fix this or maybe a workaround? Thanks in advance

Best regards
Matt

[Zenju]

This looks like the problem that Peter Krabshuis has nicely analyzed here:
viewtopic.php?t=1372&p=5874#p5874

[matthes650]

Thanks for the fast reply, have tested this, but without success. The Command Prompt states the network drive is working in normal mode as well as in admin mode.

I also tried to delete the network drive via "net use /delete" both in normal and admin mode. Checking with "net use" again, there was no network drive registered, so clean start. Then I ran FFS again in admin mode, and it fails with the same error as above. Checked with net use again, the netword drive was reregistered in admin mode and statet as OK.

Funny thing being, I have two computers of the exact same specification here, one is from me and one from my collegue. With my collegues computer everything works just fine (and net use says "no connections" for normal mode and a working connection to the backup drive in admin mode). After performing the actions I mentioned above, net use gives me the same info on my computer, but my FFS still gets the error.

Is there anything else I can check for?

[matthes650]

One addition: FFS is able to sync every data just fine, exept for the outlook0.ost. This is for running FFS in normal mode as well as with admin rights (sheduled backup is done with highest privileges).

Does FFS only use the admin rights when copying locked files? Is there a way to test if its a general problem with locked files or only with outlook-data?

[Zenju]

You could test syncing with UNC syntax instead of the mapped network share in order to find out if the problem is related to network share mapping.

[matthes650]

Hi Zenju, if you mean by UNC syntax using `"\\Backupcomputer\Backupdirectory"` instead of `"X:\Backupdirectory"`, unfortunately it makes no difference. I have also tried it with the IP-adress instead, same problem. It starts syncronizing just fine, copies files just fine, then it gets to the outlook0.ost, tries to create a shadowcopy with VSS, fails and gives out the error mentioned in the first post.

[Zenju]

Then it looks like a different problem. Can you get a Process Monitor trace of the failed copy operation?

[matthes650]

You mean with this one?

https://technet.microsoft.com/de-de/sysinternals/bb896645.aspx

[Zenju]

yes

[matthes650]

Hi, I'm not exactly sure if this is the trace needed because I haven't used Process Monitor before, but here it is (Attachment).

I have filtered for Freefilesync and have excluded the events with results "success" and "no more files", so now there should be the logs for the failed operations. Let me know if you need any additional info.

[Zenju]

Thanks, but I can't find entries related to "outlook0.ost". Can you start the trace before synchronization and stop it after it failed with the original error message above? Also, don't filter the trace, the "success" messages may also contain important context information.

[matthes650]

Hi, heres the trace again, without any filters, so the attachment is quite big.

[Zenju]

The trace looks normal up to the point where CopyFileEx tries to read the shadow copy. So it's not a network share mapping problem of volume "X:".

The question is why is `outlook0.ost`` not found on the shadow copy? There are two things you can check:

`1.` Try synchronizing again, when the error comes up, don't dismiss the error dialog or exit the sync, but instead open a parallel session of FreeFileSync, start a new config, and enter the VSS path except for the file name as a single folder. Leave the second folder empty.

E.g. When the error message complains about not finding
`\Device\HarddiskVolumeShadowCopy15\Users\Brueggemann\AppData\Local\Microsoft\Outlook\outlook0.ost` open a second FFS session and scan folder `\Device\HarddiskVolumeShadowCopy15\Users\Brueggemann\AppData\Local\Microsoft\Outlook`.
Now you can check directly if the file is available on the VSS volume or not.

`2.` Some theory: it's possible to exclude specific files from VSS, e.g. http://otori-braindump.blogspot.de/2010/08/vss-exclude-files-and-folders-from.html

Is this something that could apply to you?

[Zenju]

It seems 2 is indeed the culprit:

[Zenju]

Some more info:
http://blogs.technet.com/b/filecab/archive/2007/01/24/why-completepc-backup-does-not-include-ost-files-in-the-backup-image.aspx

[matthes650]

Zenju, you're great. Deleting the registry entry did the trick.

And it also explains why it backuped the data of my collegue (with the .ost located in \Appdata\ROAMING\Microsoft\Outlook) and it refused to backup mine (with the .ost located in \appdata\LOCAL\Microsoft\Outlook).

Some questions are remaining: In the articles you posted it was said the .ost isn't included in VSS due to performance issues, and it would not be necessary to backup it because it can be restored via the microsoft servers.

1. Doesn't VSS only kick in when needed (so the .ost is copied once FFS starts to backup)? So this way the perfomance lag wouldn't be much of a problem, would it?

2. Or is the VSS constantly "mirroring" all data, so that FFS can read it when needed? In this case the harddrive would have to copy it all the time, because Outlook (and the .ost) is running and changing all the time.

So this leads to: Do you think a backup of an .ost is nessesary or should I put the registry entry back in and just exclude Outlook from the backup?

[Zenju]

> 1 and 2

FFS creates shadow copies on demand. The performance argument of the article however does not apply to FFS, since it does not create persistent snapshots.

> Do you think a backup of an .ost is nessesary

I don't know if this particular file type is necessary for backup, but from FFS's perspective the question is if the current behavior is okay: There is no reason why .ost, or any other file type, should not be included in a vss snapshot set. Unfortunately the .ost exclusion via registry is the default on Windows 7. Users should not be required to modify their registry or even learn about these low-level VSS details. Therefore the best solution would be if FFS just "found these files" in first place without further action from end users. I'll see if I can find a technical solution to implement in FFS.

[Zenju]

I've disabled the VSS optimization that removes the file types as specified in the registry key above. FFS should now work as expected without registry modifications. If the *.ost files are not needed, they should be excluded via the FFS filter, but now they can be copied without error if required:

[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.21_beta_Windows_Setup.exe]

[matthes650]

Hi, thanks again for the effort and the insight on backup systems. Very good work, problem solved.