.ost files delted when AAP is enabled

[frankive]

i have pretty new bug for you, perhaps..

After upgrading a client with 2 vms to a new physical server (from 2012 hyper-v to 2016 hyper-v) we run all the updates etc. in the guest os. Everything fine.
We thought.

It seems that there terminalserver (2008 R2 + Outlook 2010) started to create a new outlook profile every morning.
Ok.
We started to do some test, log off the user in the middle in the day and log in again.
The .ost file was still there.
Ok.
We then started to check if the nightly reboot of the server was the cause and prevented the daily reboot for a week.
Still; a new outlook profile was created since the .ost was goona.
Ok.

The only thing left; lets look at the .ost files at some kind of database, perhaps Veeam is hitting it somehow with the Application Aware processing?
We disabled the AAP for that particular VM, and..
Seek and you will find; the .ost was there and no new outlook profile was created!

We turned the AAP the next day, and whooops, the outlook profile gets created again!

We turn it off, and behold; the .ost is just and the profile is like it was the day before.

Bug?

[Mike Resseler]

Frank,

The way you describe it seems indeed like a bug. Maybe it is a combination of Veeam using AAP and the OS thinking it needs to recreate a profile but I don't think this is expected.

Do you have a support ID (and post it here + the follow-up). I believe this certainly needs to be investigated

Thanks
Mike

[frankive]

# 02100949

[frankive]

trying to turn of hyper-v quisence and see how tht will affect. Suggesteion from Veeam.
Will report back tomorrow to see if that is touching the .ost files.

[frankive]

the .ost files get deleted after enabling hyper-v qisence..

[Mike Resseler]

Thanks for the update Frank

Please continue to work with our engineer.

[frankive]

will do, i post here so other user can see the process

I have seen this behavior when i clone harddrive in laptops etc. Outlook will seems to reindex the .ost and download email again.
I guess these clone software also uses microsoft vss engine, perhaps an issue with Outlook 2010 and vss in some cases.
Intereseting.

[frankive]

Veeam means since its affected while doing a hyper-v quiencse backup its not something Veeam can help for, it must be a Microsoft issue.

[frankive]

a backup with windows server 2016 native tool went smooth, so Microsoft Backup didnt have this issue..
performed a backup with AAP enabled and performed a process monitor by Veeams suggestion.

the result from veeam engineer.

The vssvc.exe service performs next action with the file:
"SetDispositionInformationFile" with "Delete:True" indicates that the file will be deleted when it is closed. The files will be removed after the file is closed. So it means that Microsoft Shadow Copy service marks the file for deletion. It is kind of MS VSS logic to remove the file.


Have sent the latest logfile from inside guest os to Veeam not, hopefully we are seeing an conclusion to this soon. So far it seems like a Microsoft issue, but only trigged when Veeam Backup is running and not Microsoft Backup.

[frankive]

Veeam have no idea so far, seems like vssc.exe is marking the .ost files for deletion during AAP backup. .ost files should normally be excluded from tradiotioanl vss snapshots as far as I know?
Windows server backup is still the rescue so far.

[Dima P.]

Hi Frank,

Please check if ost is listed under this regestry hive on the affected machine: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot

[frankive]

yes it is.

[mmaster]

Exactly the same issue here with Server 2008R2 and Office 2016.

Also the Regkey exists here.

Is there any update on this existing case yet?

[mmaster]

After investigating my solution was to use a GPO to change the reg key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot (The OST one) to an other path as the files where deleted when the reg key pointed to them. An other solution is: change the OST location with GPO or registry key.

Hope this helps.

[scootrz32]

What did you change the key to? Just a random temp folder?

[stoal76]

Did Veeam ever have a solution for this problem, as we have just had it happen after moving a remote desktop server to a server 2016 Hyper-V host, and we have application aware processing enabled and are excluding OST files.

[foggy]

Hi Shane, as far as I can get from the support case notes, the recommendation given to OP was to contact MS with this. The case itself was closed due to no response from the customer, so I cannot check the outcome and recommend you to open your own case for verification.

[stoal76]

I have had the same response from the Veeam support ticket I created, I'm not sure I want to pay Microsoft for a support case when the issue is only occurring while we are using Veeam to backup the remote desktop server.

I would have thought Veeam support should be raising a case with Microsoft on this?

[foggy]

As far as I know, you do not have to pay for the case if it finds out that the issue is on their side (which is likely, as far as I can get).

[gmele]

Hi,
we are having the same problem but context is a little different. We're running on a 2012 R2 Hyper-V virtual machine. We're using Outlook 365 and at approx 06:30 PM right after an SQL Server backup of all databases all user's cached Outlook data files (.OST) disappear. This means that the next morning there's going to be massive downloads of Outlook .OST files which will slow down the system for the entire morning.
During the night we run Veeam Agent for Windows 2.0 backups of our virtual machine (from within the VM). I checked registry settings for key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToSnapshot\OutlookOst and I also have the following value: "$UserProfile$\AppData\Local\Microsoft\Outlook\*.ost".

Extensive Google searches have not yielded anyone else except Veeam users as having this issue. This leads me to suspect that just maybe Veeam is somehow modifying VSS behaviour and consequently provoking the deletion of the cached Outlook .OST files.

Any comments are welcome.

Thanks.