Hi all,

we are currently implementing a backup solution to back up our HyperV2012R2 Failover Cluster VM's. The VM's have their disks on a 2012 R2 StorageSpaces Server shared via SMB3. The 'file server vss agent' service is installed on the storage system.

The HyperV host has several nics.

-One 1Gbit nic for management. The Host is registered in AD with this nic and the DNS entry points to his DNS name 'server.domain.local'

- One 10Gbit nic for the SMB Storage traffic in another subnet. The storage machine has a second Name who points to the ip of the 10G nic 'storage.domain.local'

- Other nics for cluster communication and VM traffic

The VMs are configured with the 10G name of the storage server and everything works well with hyperv.

Everytime i try to back up a machine (via the Software or with the Shell on an Hyper-V Host via DISKSHADOW) there is the following error message:

--------

DISKSHADOW> add volume \\storage.domain.local\vms01\server01

The provider does not support volume shadow copies for this volume in this context.
You must either change the context or add a different volume.
Note that changing the context might cause existing volumes in the shadow copy set to become unsupported.

--------

When i use his AD DNS name it works:

--------

DISKSHADOW> add volume \\server.domain.local\vms01\server01

DISKSHADOW> create

....

--------

Am i missing something? Has anybody an idea what the problem could be? Do I have to register the second name or nic in the storage server system or in the VSS providers?

Thank you for any help!

Hi Sir,

>>One 10Gbit nic for the SMB Storage traffic in another subnet. The storage machine has a second Name who points to the ip of the 10G nic 'storage.domain.local'

"

Requirements and supported capabilities

VSS for SMB File Shares requires:

• Application server and file server must be running Windows Server 2012
• Application server and file server must be domain joined to the same Active Directory domain
• The File Server VSS Agent Service role service must be enabled on the file server
• The backup agent must run in a security context that has backup operators or administrators privileges on both application server and file server
• The backup agent/application must run in a security context that has at least READ permission on file share data that is being backed up.

"

http://blogs.technet.com/b/clausjor/archive/2012/06/14/vss-for-smb-file-shares.aspx

Best Regards,

Elton Ji

Hi,

thank you for your answer.

The Storage Machine (File Server) and the Hyper- Machines are in the same AD. I simply split the 10G Traffic from the Management Traffic to two NIC's.

It seems, that Windows can not do VSS on the Storage Volume, when i try to connect via the second NIC IP Adress. On the 1G Management NIC i can trigger the VSS Snapshot successfully.

Does anybody know, if it is possible to 'register' the second nic or the DNS alias Name in the AD or somewhere, that the system can VSS over other nics?

The log files from the backup System (VEEAM) tells me something like:

---------------

[19.03.2015 17:49:01] <  5528> SnapCreator|       Getting list of volumes to snapshot.
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528> SnapCreator|         - volume to snapshot '\\STORAGE\VMS01\', mount point '\\storage.domain.local\VMs01\'
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528>         This path \\storage.domain.local\VMs01 have not impersonation context
[19.03.2015 17:49:01] <  5528> SnapCreator|       The following volumes should be snapshotted:
[19.03.2015 17:49:01] <  5528> SnapCreator|           '\\storage.domain.local\VMs01\'. UniqueName: '\\STORAGE\VMS01\'
[19.03.2015 17:49:01] <  5528> SnapCreator|       Adding volumes to the snapshot set
[19.03.2015 17:49:01] <  5528> SnapCreator|   Snapshot provider is not specified for volume [\\storage.domain.local\VMs01\]. Default one will be used.
[19.03.2015 17:49:04] <  5528> SnapCreator|       Adding volumes to the snapshot set Failed.
[19.03.2015 17:49:04] <  5528> SnapCreator|       Clearing CSV backup state.
[19.03.2015 17:49:04] <  5528> SnapCreator|     Performing pre-backup steps. Failed.
[19.03.2015 17:49:04] <  5528> SnapCreator|   Performing VSS backup. Failed.
[19.03.2015 17:49:04] <  5528> SnapCreator| Entering in snapshot creation procedure. Failed.
[19.03.2015 17:49:04] <  5528> SnapCreator| ERR |Provider [{00000000-0000-0000-0000-000000000000}] does not support shadow copies of volume [\\STORAGE\VMS01\].
[19.03.2015 17:49:04] <  5528> SnapCreator| >>  |--tr:Failed to add volumes to the snapshot set.

---------------

Thank you

Chris

Hi Sir,

>>Application server and file server must be domain joined to the same Active Directory domain

Adding the server to domain  does not only means an A record was registered in DNS server , there are some objects need to be added in domain .

So , We can not use a non-existent computername to achieve that .

Best Regards,

Elton Ji

OK, now i have changed my whole infrastructure. 10GB NIC is now management AND storage traffic so the original name server.domain.local is registered in AD via the 10GB NIC and the HyperV Servers have their VM's on \\server.domain.local\SMB3Share\...

Same for the HyperV servers. VSS Snapshots are now possible. But i think this is not how it should be. You can find in every Guideline, that you should separate the management from the storage traffic. But currently it seems not to be possible to Trigger VSS Snapshots of VHDX files via a second NIC in another Subnet.

Thank you

Chris