Information and announcements from Program Managers, Product Managers, Developers and Testers in the Microsoft Virtualization team.
SMB is getting a lot of attention with Windows Server 2012, and we’ve had questions from a few customers regarding the inter-play between SMB shares and Hyper-V Replica. In this post we’ll share our experience around setting up and using various configurations involving SMB shares and Hyper-V Replica. The issue we were expecting to run into is the apparent lack of authorization to use the SMB share, when using remote management.
In all the scenarios that are investigated, we will start from a remote management node (mgmtnode.contoso.com). We will try to set up the scenario from this management node, and work through the errors encountered. In order to visualize what this means, all the scenarios will look roughly like this:
To start with, we will try using the Hyper-V Manager UI. On the management node (mgmtnode.contoso.com), open the Hyper-V Manager UI and add the server aashish-server on the left-side pane using “Connect to Server…”. Now enable aashish-server as a Replica server using the Hyper-V Settings on the right-side pane. As expected, we run into an error:
The error encountered is “Failed to add authorization entry. Unable to open specified location to store Replica files ‘\\aashish-server3\Replica-Site\’. Error: 0x80070005 (General access denied error).”, and it is not a very helpful error message. Hopefully this blog can help alleviate that situation.
While the standard answer to fixing this error will be to setup constrained delegation, this is not something that is always optimal. Yes, the core issue is around delegation of credentials when there is an additional hop (mgmtnode –> aashish-server –> aashish-server3). However, depending on your setup and how often you plan to change the Replica server settings, there are simpler solutions.
For all practical purposes this is like the single Replica server scenario discussed above, except that you will have to remote into each server and setup replication. At even 5 servers, this is a painful exercise. Constrained Delegation starts to look like an increasingly attractive option. Yet, without access to the domain controller perhaps the realistic route is that of CredSSP and PowerShell – and that will be something we will cover in detail in this post.
As with the non-clustered scenarios, you will run into the General access denied error when you use the Failover Cluster UI to change the replication settings.
Trying this through PowerShell will give you a similar error:
Set-VMReplicationServer : Failed to add authorization entry. Unable to open specified location to store Replica files '\\aashish-server3\Replica-Site'. Error: 0x80070005 (General access denied error). You do not have permission to perform the operation. Contact your administrator if you believe you should have permission to perform this operation. At line:1 char:1 + Set-VMReplicationServer -ComputerName AARBrk-130612 -AllowedAuthenticationType ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (Microsoft.HyperV.PowerShell.VMTask:VMTask) [Set-VMReplicationServer], VirtualizationOperationFailedException + FullyQualifiedErrorId : AccessDenied,Microsoft.HyperV.PowerShell.Commands.SetReplicationServerCommand
Although the cluster has multiple nodes, the scenario is similar to that of a single Replica server. When using clusters, it is sufficient to make the changes to the Hyper-V Replica Broker (AARBrk-130612 in this case), and the replication settings will be propagated to the rest of the cluster nodes. So depending on your setup and how often you plan to change the Replica Broker settings, there are a few options to consider:
This option is interesting from many angles. The big attraction is PowerShell; with administrators increasingly moving to PowerShell to automate and manage their infrastructure, getting things done through PowerShell is sometimes more important than through a UI. Just as important is the fact that remoting into a Replica server is not always feasible or advisable – and hence the management node from where all actions are performed. The CredSSP-based solution fits neatly into such a scenario.
For enabling the delegation of credentials, run the following commands on the management node:
Once this is done, you follow-up with Set-VMReplicationServer but run on the cluster host that you have just delegated to:
where DOMAIN1 and user1 are authenticated on aashish-s1.contoso.com. Note that you do not need to use –ComputerName with the Set-VMReplicationServer command because it is cluster aware!
So what happens if you add a new node to this Replica cluster? No worries! The replication settings are propagated to this node also with no additional steps on your part. If you need to change the replication settings, you can use the same steps outlined without worrying about the new server.
Hopefully this will set you back on track with Hyper-V Replica and SMB shares. Give this a go and share your experience with us – we would love to hear your feedback!
This process does not work for me. All commands above have been run on my cluster host, but I am unable to replicate a vm from a cluster node to the standalone hyperv replica server. I receive the following errors:
Hyper-V suspended replication for virtual machine 'WSCOMP' due to a non-recoverable failure. (Virtual Machine ID 3E0CC292-5757-488B-B795-DE2440E7076F). Resume replication after correcting the failure.
Hyper-V could not replicate changes for virtual machine 'WSCOMP': General access denied error (0x80070005). (Virtual Machine ID 3E0CC292-5757-488B-B795-DE2440E7076F)
Based on the information you have provided, it looks like replication has been enabled for the virtual machine WSCOMP. Suspend replication is possible only on an existing replication relationship. Was this working before? As a test, I would create a VM (with an empty dynamic vhdx - the default options) and try to replicate it.
Just to close on some other possibilities:
1. Is an SMB share being used - either with the primary cluster or with the standalone replica? The reason I ask this is because the "General access denied" error that is called out in this blog will be encountered at the time of enabling Hyper-V Replica on the standalone server.
2. It seems that the error occurred on the standalone replica server. The event viewer logs should have more details available.
Can you walk us through your setup and the steps that you carried out - on the cluster and on the standalone server?
What are the permissions required for the share that I am replicating to? Currently I can only get replication to succeed if I give "everyone" full permission to the replication folder/share. I am sure this is not the requirement but as of right now this is the only setting that works. I have tried giving the replica server, the hyper-v node and the cluster identity full permissions but this has not worked. Any help would be appreciated.