BE 2014 won't backup VMs on Hyper-V 2012 R2

[it_jccap]

Hi all.

The Backup Server is running Server 2008 R2 Standard with Backup Exec 2014 installed. All updates have been applied from live update.

I'm trying to backup VMs on a server running Hyper-V 2012 R2, but I continue to receive a "Final error: 0xa0009679 - A failure occurred querying the Writer status for a Hyper-V virtual machine" error. Running VSS Admin List results in a "Retryable Error" for the Microsoft Hyper-V VSS Writer. I have tried restarting the server already and that didn't help. Any tips?

Event Viewer also gives me this at the time of the backup failure:

1) Application and Service Logs > Microsoft > Windows > Hyper_V-VMMS > Admin:

Failed to fix-up absolute VHD paths in configuration of virtual machine 'VM Name': Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced. (0x8007052F). (Virtual machine ID AEB2B426-05DD-4C4F-AC8F-330B0D57B8D4)

2) Windows Logs > Application:

A VSS writer has rejected an event with error 0x800423f3, The writer experienced a transient error.  If the backup process is retried,
the error may not reoccur.
. Changes that the writer made to the writer components while handling the event will not be available to the requester. Check the event log for related events from the application hosting the VSS writer.

Other details: The Hyper-V 2012 R2 OS has been separated from the VMs on the HD. OS is on C and the VMs are on D. VM backups continue to run perfectly fine from a Hyper-V 2008 R2 server. All servers mentioned are using the same storage device.

Any help will be much appreciated. Thanks everyone.

[JonathanK]

Yes, I finally got everything working about a week ago after working with Symantec Tech Support for well over a month.

I had already checked or addressed all of the issues that are fairly well documented, including these, before starting with tech support, but the GRT-enabled backups still did not work:

• Integration Services up to date with host (my VMs were built on the host)
• No duplicate drive IDs (an issue on some of my Server 2008 R2 VMs)
• Add a SCSI Controller to the VM, even if nothing will be using it

What we finally found was touched on in a reference in a post above: http://www.symantec.com/business/support/index?page=content&id=TECH216944

See Issue #2, and run that 3-line PS script as Admin.  Run it from the host server, and put each VM name that is giving you issues in the first line.  I was getting the {No Contact} issue on my Exchange VM that I was attempting to do a GRT-enabled backup on, and also on another server that had SQL Server on it, but I was not attempting a GRT-enabled backup on that server(I purposedly did not have the SQL Server GRT option on for that host, but BE still recognized that there was a GRT-enabled application on the VM).  Both VMs would throw exceptions in BE every day, with the Exchange VM being my biggest concern.

The causes listed at the beginning of Issue #2 were not relevant, and none of the suggested issues at the end were relevant.  In my case, rebooting the VM actually causes the issue, contrary to the suggestion of rebooting the VM to solve it.

Re-start the Hyper-V Volume Shadow Copy Requestor service on each server reporting {No Contact}, and it should change to {OK}.  I did that, and the BE Exceptions on both VMs went away, and I verified that I have a full GRT-enabled backup of my Exchange VM.

I just verified last night that rebooting puts these two VMs back in {No Contact} mode and the BE Exceptions return.  I attempted (just now) to set the Hyper-V Volume Shadow Copy Requestor service to Delayed Start, but that's not allowed for that service (apparently because it's part of a group), so I'm not sure of an automated was to resolve the issue after a reboot.  That does also indicate that the issue really is an OS issue, as it shouldn't be switching to {No Contact} on boot.  FYI, both of my VMs with this issue are Windows Server 2008 R2 running on Windows Server 2012 R2 hosts (two different hosts).

Hope that helps.

Jonathan