Windows 2012 R2 DC fails to boot in Sure Backup

[foggy]

I can see your case has been escalated and investigation is underway, so hope you're getting proper treatment with it. Thanks.

[cffit]

Yes, I was escalated to a developer in Russia and after an hour or so with him the issue is resolved. Yesterday I went back and forth with first level support and they were having me try things that I'm always asked to do in previous incidents for this issue. I probably have a few hours invested into it this time. I'm frustrated, but I appreciate your help foggy in getting me escalated, so thank you.

For anyone else coming across this, there are two different issues with SureBackup and domain controllers not coming up. One has to do with VSS and one has to do with some registry issues which are ultimately a Windows OS issue although VEEAM can get around it with a dll change. The VSS issue was fixed in patch/update 2 for v8. The other issue was not. For my scenario, the second issue with the registry has always been the issue. This is due to our VEEAM server being Windows 2008 R2 and the domain controller being Windows 2012 R2. Development literally created the dll I needed while on the phone and he sent it to me and now I'm good. If anyone on v8 with patch/update 2 has the same issue I have, call support and reference my case number to get the dll that fixes this. The case number is 00911043. Even if you are on older versions, this issue has been around for quite some time and I would mention this case.

I hope this post is helpful to others. I appreciate the answers that VEEAM employees give in these forums and I appreciate the attention that they get me with support. I think VEEAM makes a superior product and I would never use anything else for our backups. That said, I am really disappointed with this particular issue and all the time and frustration I've gone through over the last year. Please make sure this issue is addressed in the next update so I don't have to go through this a 5th time.

[foggy]

Thank you for your kind words. This turned out to be another issue (though also a known one, that's why you were rapidly given the fix) caused by some differences in Windows registry implementations between Windows 2008 R2 and Windows 2012 R2. Chances are the fix will be included in the next update, though most likely in the form of the registry value (I will make a reminder to update this thread with the instructions on its deployment).

That said, migrating Veeam B&R management server to Windows 2012/2012 R2 should save you from running into this again.

[cffit]

Well, I put on the v8 patch 2b yesterday and now for the fifth update/upgrade in a row covering over a year, my DC SureBackups are broke yet again for a fifth time with the same issue. Why is this so hard to fix after all these incidents? Once I call support and go through the same process which takes up time for everyone, and once this issue is submitted to a developer there, it's fixed pretty quick. Why then can't it just be included in the patch? I'm so frustrated with this issue and its never-ending haunting me every single time I upgrade or put on a patch.

[Gostev]

I will find out.

[cffit]

I understand this, but this has caused issues for updates through patches on 7, the upgrade to 8, and now all the patches on 8 so far. Each time it has taken up time, especially the first few. Now I just reference old cases and say "this is happening again after installing the latest patch".

Also, if they are aware of it but not going to include it in the patches, why then isn't a hotfix ready at the time of the patch release? I always have to open a case and then wait for it to get escalated to a point where a developer writes up the fix and then eventually I get it. Sometimes that's been weeks, sometimes days.

As stated numerous times in this thread, I love VEEAM products and I'm one of your biggest fans, but this issue that has impacted me so many times over such a long period of time takes some of that away.

My new case number is 00953402.

[Gostev]

Yes, I am sorry, but at first I simply did not notices the previous two pages of this topic, so I have deleted my original response shortly after I posted it... but I guessed it got cached somewhere. The issue is clearly different in this case, so my original answer to you simply does not apply. I am checking with all stakeholders now, as this is unexpected.

[foggy]

Including the fix under the registry key is scheduled for the next major update/release. It was decided not to include it into Update 2b, which was intended to fix just specific issues with the largest base of potentially affected users. This time your case will be escalated and you will get the hotfix shortly.

[Gostev]

After discussing with the devs, this fix looks to be a workaround for a Windows issue, and QC feels it is simply too dangerous to roll out to the entire customer base. Basically, there is no guarantee it will behave well in every environment, even if it works well for you. It may potentially bring more problems than it fixes. Which is why this behavior will not be a default one even when we finally include this into the base product code, and will have to be enabled via a registry key. Thanks!

[cffit]

So in the case where someone is booting a DC that is Windows 2012 and their VEEAM server is Windows 2008, this issue is a factor. Are there so few of the 150,000 customers that have this scenario that it isn't considered to affect enough people? It seems like it would be a very common issue.

[foggy]

It does not show up on every similar installation, so we actually do not have many cases regarding that.

[cffit]

I thought that the issue was due to the VEEAM server being of a different OS than the DC that is being booted in the SB environment. If that is not the case, can you explain what the issue is and how our environment is of such a different variation than other customers? If there is a way to correct this on my end without having to upgrade our VEEAM server to Windows 2012 I am all ears.

This issue has caused me many, many hours of time over the last year. Every time I upgrade or patch VEEAM I now expect things to break. I know VEEAM takes pride in their solid QA testing and releasing solid products and upgrades/patches. This is really a problem for me.

[foggy]

I thought that the issue was due to the VEEAM server being of a different OS than the DC that is being booted in the SB environment.

Well, this is not a necessary and sufficient condition. What is happening, is that during guest processing of the DC, while enabling authoritative restore, Veeam B&R tries to register one of its components. Due to some unknown reasons, Windows sometimes stops processing registry log files and applying latest changes (including information about our component). This results in inability to start the component and perform authoritative restore. The nature of the issue is pretty random and we were not able to define any consistent criteria so far.

[cffit]

I received the fix and am back working. Anyone else experiencing this can reference my case to get the fix.

[Gostev]

Just wanted to let everyone know that this fix was included into v8 Update 3, but is disabled by default (still needs to be enabled via a registry key). Thanks!

[cffit]

Thanks Gostev. Can you post the registry key here so when people are looking through the forums with this issue they will know what key to update?

[Vitaliy S.]

Usually, we do not post registry keys on the forums, so that users apply them only after verifying (through our support team) that they have exactly the same issue as it is described in the topic. Hope this makes sense.

[Gostev]

Especially since we consider this particular behavior modifier potentially dangerous, as per my earlier posts... definitely not something you want to enable in all environments (otherwise, we would just make it a default behavior). Thanks!