Using SMB shares with Hyper-V Replica

Using SMB shares with Hyper-V Replica

  • Comments 5
  • Likes

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 ( 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:

001 base architecture

Scenario #1: Single Replica server with SMB share

The building blocks

  • A single Hyper-V server ( on the Replica site
  • A single server ( hosting an SMB share \\aashish-server3\Replica-Site that will be used to store the Replica VMs.
  • A single remote management server (

Setting up the infrastructure

To start with, we will try using the Hyper-V Manager UI. On the management node (, 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:

002 single server UI failure


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.

Fixing the error

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.

  1. Remote into aashish-server directly as set up the Replica server – this eliminate the hop that causes problems. With just one server to configure, this will be the simplest solution for your needs.
  2. Use CredSSP and PowerShell to delegate credentials and set up the Replica server, and we will be exploring this later in the blog post. This is an excellent option for users where:
    1. No domain controller access is possible.
    2. No Remote access is possible.
    3. The Windows Server UI is not present on any node other than the management node.
  3. Set up constrained delegation in your domain controller. This option has been explored extensively by others and there is ample material on this available online.

Scenario #2: Multiple Replica servers (unclustered) with SMB share

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.

Scenario #3: Replica cluster with SMB share

The building blocks

  • A failover cluster (AAR-130612) on the Replica site having the domain. This consists of two servers (aashish-s1, aashish-s2), and a Replica Broker (AARBrk-130612). The broker can be present on either node, but in this example we will assume that it resides on aashish-s2.
  • A single server ( hosting an SMB share \\aashish-server3\Replica-Site that will be used to store the Replica VMs.
  • A single remote management server (

003 cluster

Setting up the infrastructure

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.

004 replicabroker failure

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

Fixing the error

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:

  1. Remote into the server on which the Replica Broker is running (aashish-s2 in this case), use the Failover Cluster UI and directly set up the Replica – eliminate the hop that is causing problems. In most cases, the replication configuration is a one-time operation, so this could be the simplest solution for your needs.
  2. Remote into any server in the cluster and use the PowerShell command-let Set-VMReplicationServer. There is no need to use –ComputerName in the parameters as the command-let itself is cluster-aware.
  3. Use CredSSP and PowerShell to delegate credentials and set this up if options 1 and 2 are not for you.
  4. Set up constrained delegation in your domain controller.


Using CredSSP and PowerShell

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:

  • Enable-WSManCredSSP –Role Client –DelegateComputer
  • Invoke-Command –ComputerName –ScriptBlock { Enable-WSManCredSSP –Role Server }

Once this is done, you follow-up with Set-VMReplicationServer but run on the cluster host that you have just delegated to:

  • Invoke-Command –ComputerName –Authentication Credssp –Credential DOMAIN1\user1 –ScriptBlock { Set-VMReplicationServer …}

where DOMAIN1 and user1 are authenticated on Note that you do not need to use –ComputerName with the Set-VMReplicationServer command because it is cluster aware!


Adding a node to this cluster

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.


Concluding note

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!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 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)

  • Hi Mike,

    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.


  • this help t me

  • Hi Simon, Refer to this link: