No Exchange log truncation with DPM host Backup when guest OS is Windows Server 2016 RRS feed

  • Question

  • Hello!

    The Problem:
    No Exchange LOG truncation after full backup of an Server 2016 VM. We use Exchange 2016.

    But it only is a problem within VMs where the guest OS is Windows Server 2016.
    We use DPM 2016 to backup multiple exchange Servers from an Hyper-V Cluster.
    We take full backups from the VM. Every Exchange Server is in an different Domain.
    The backup integration service was activated and updated.
    It works perfect on every 2012R2 server. On 2016 server, not matter which updates or cu we use. Also the latest DPM Update did not help.
    The problem also occurs on fresh installations of Windows 2016 + Exchange 2016.
    When I install the same configuration on an fresh Windows 2012R2 it does works instantly.
    When I check the exchange 2016 database on the Windows 2016 server there I no date in “last full backup”. 
    Dirty workaround:
    ADD VOLUME “Database Volume”

    When I use this workaround, exchange starts the log truncation and I also see an date in “last full backup”.
    I contacted the Microsoft support multiple times and was pushed from DPM to Exchange to Windows to DPM. All the way around and around. Microsoft support asks me the same question 100 times and gives me useless "try this, try that" support calls. I also had multiple occasions of excellent support. Not on this problem.

    There is no problem when I use “VSSSADMIN LIST PROVIDERS/WRITERS”.
    I don´t see any relating problems the eventlog.
    For me one thing is clear, it must have something todo with the integrations service. Something has changed here but I can´t find the missing link…

    I also did a technet topic in the German forum… no replies there.
    Hopefully you can help me.

    Sunday, November 25, 2018 8:07 AM

All replies

  • Hello,

    Do you still have the ticket open with Microsoft? Seems rather strange that they haven't gotten any further with this.

    You didn't mention a few things so I wanted to take them up, just to make sure.

    1. Have you changed the Recovery model from Simple to Full without removing and then adding the DB's to the DPM? DPM doesn't really realize when changing the Recovery model on SQL without re-adding the DB's to the protection group.

    2. Also make sure that the there is more space available on the drive that the backup requires.
    If the SQL Transaction Log is 10 GB then it's necessary you have a minimum of 10 GB of free space on the same drive before the DPM can truncate the logs.

    Best regards,

    Blog: LinkedIn:

    Sunday, November 25, 2018 9:53 PM
  • Hello, thanks for the response.
    No the last case has been closed. The last Information i got was thy think it´s not an DPM related problem. They think it´s something their windows department has to resolve. But they can´t forward this support case beaucse they currenty don´t accept no new internal support cases. It was something like that. I´m relly pissed off because i already wasted hours of talking and then i have to completly reopen the case. Back to sqaure 1 again... and i already talked to so many peopel there which want me to try the same thing over and over again.

    I´m a bit confused now. I am talking about Microsoft Exchange Server 2016. As far as i know there are no simple or full recovery models in exchange server. It seem like you talking about SQL. So i guess you got something mixed up here. ;-)
    Monday, November 26, 2018 6:51 AM
  • Apologies, I did mix these up... I was not thinking straight last night..

    Do you see any clues in the Application log regarding the database log truncation?

    Also check the DPM server for the MSDPMCurr.errlog log (found under C:\Program Files\Microsoft System Center\DPM\DPM\Temp), as well as the DPMRACurr.log on the protected server.

    Blog: LinkedIn:

    Monday, November 26, 2018 8:05 AM
  • No Problem, i´m glad sombody tries to help me out.
    I´m sorry to say that i can´t find absolutley no clues in any logs. Everything seems perfect.
    I even build an new lab enviroement with 2016... same problem.
    Then i rebuild the exact same lab but with the exchange server on an 2012R2 guest os... problem gone.

    Currently it looks like that the hostbackup byepasses the integration service. Or it does an copy backup?
    I don´t know because i got not a single clue. I also do not find anythinmg within dpm to change.
    At the end the exchange server does not start truncation because from the excahnger server point of view no backup happend...

    Tuesday, November 27, 2018 7:33 AM
  • This is a strange behavior indeed, have you tried setting the synchronization frequency for the protection group containing Exchange to: Just before a recovery point to see whether there is any change?

    In addition, how does the Integration Services settings look like on both Windows Server 2012 R2 & Windows Server 2016 Hyper-V virtual machines (VMs)?

    Blog: LinkedIn:

    Tuesday, November 27, 2018 9:37 AM
  • Here we go again. I´m sorry for not replying but i got tired of explaining and checking and explaining the same things repeatedly to many different people. After really losing interest in solving this ***** i finally got a new “clue”.

    It seem like I found the root cause.
    Every server that works "right" shows an ESE Evenlog entry with ID 2005 witch states that a Shadowcopy startedand “This will be a Full shadow copy.”
    Every server with the problem shows an ESE Eventlog entry with ID 2009 witch states that a Shadowcopy started and “This will be a Copy shadow copy.”

    Reason unknown. I can find an differnce in this servers. They are almost identical. Some Exchange Servers start an “Full shadow copy” and some an “Copy shadow copy”. After some reading the way the VM is backed up in DPM should always trigger an “This will be a Full shadow copy.” This is how it should work with the only available option “express full backup” from DPM. But it does not, even when frehsly readd the Server in DPM. It makes so sense at all.
    So I tried it with Windows Server Backup. I did choose an FULL VSS Backup and the eventlog shows “This will be a Full shadow copy.” With ID 2005 an an server that has the problem. So the problem only occurs with DPM. Maybe someone can help me from here.
    I´m still clueless how to solve this.

    Wednesday, March 6, 2019 12:20 PM
  • Are these Exchange servers members of a DAG?

    Blog: LinkedIn:

    Wednesday, March 6, 2019 1:44 PM
  • I finally found the real cause: Resilient change tracking or RCT!
    Every Exchange Server that utilizes the Resilient change tracking has this problem.
    It does not matter if it,s Exchange 2013 or 2016. It does not matter which CU Update is installed. And it does not matter if its Server 2012R2 or 2016.

    It only seemed like that because new servers automatically utilized the resilient change-tracking feature. Older ones did not. I just tested it with an LAB VM. I updated the LAB VM to Version 8 and readded it to DPM. It now uses resilient change tracking and shows the exact same behavior. No log truncation with Resilient change tracking.
    I still don´t have a solution but i´m pretty sure I identified the real root cause.

    Now i need to find a way how to solve this. 
    Wednesday, March 6, 2019 2:54 PM
  • Good find indeed! It didn't cross my mind to think about the RCT (Resilient Change Tracking).

    As this is a native feature I don't think it can be disabled.

    For now, if you don't want DPM to use RCT then I'm afraid your only option would be to keep your Exchange virtual machines on Windows Server 2012 R2 virtual machines with an older configuration version.

    You could report this feedback to the DPM feedback forum below:

    Blog: LinkedIn:

    Wednesday, March 6, 2019 3:48 PM