SIRIS, ALTO, and NAS: Virtualize via Hypervisor for Hyper-V environments



This article describes how to connect a Datto SIRIS to a Hyper-V hypervisor and run a virtualization via hypervisor offload. These instructions apply to virtual and physical SIRIS appliances.

For vSphere instructions, see SIRIS, ALTO, and NAS: Virtualize via Hypervisor for VMware environments.


  • Datto SIRIS
  • Microsoft Hyper-V
  • Windows Server 2012R2
  • Windows Server 2016
  • Windows Server 2019



Datto SIRIS appliances can establish connections to Hyper-V environments to offload screenshot and disaster recovery virtualizations to the hypervisor. This connection allows the virtualizations to take advantage of the expanded system resources available on the Hyper-V host, delivering increased virtual machine performance, while decreasing overhead on your Datto appliance.

Datto SIRIS does not support taking agentless backups through the Hyper-V connection. Support for agentless pairings is limited to VMware environments only.

Technical Notes

  • The platforms listed in the Environment field of this article all support Hyper-V integration.
  • SIRIS Hyper-V virtualizations are Hyper-V Generation 1 virtual machines.
  • SIRIS shares out backup images for Hyper-V restores via iSCSI.
  • Datto appliances do not currently support Hyper-V Shared Live Migration.
  • iSCSI targets containing underscores (such as backup_device) are not supported.
  • Virtualizations and screenshots offloaded to Hyper-V rely on virtual IDE controllers, which limits virtualizations to the boot volume and a maximum of three attached disks.
  • To prevent blocked connection attempts between your Datto appliance and the target hypervisor, create any necessary network exceptions in your antivirus and firewall solutions before attempting this procedure.
  • To prevent blocked connection attempts between your Datto appliance and the protected system If your hypervisor is using Webroot anti-malware software, you will also need to create an exception for %systemdrive%\Windows\winexesvc.exe 

Configuring Hyper-V

Depending on the configuration of your Hyper-V host, you may need to make changes to allow your SIRIS to connect to the hypervisor.

First, attempt the steps described in the Auto-configuration through the Remote Service Management rule section of this article. If following the steps do not result in a successful hypervisor connection, follow the steps in the Enabling and configuring winrm and Windows Firewall section.

Auto-configuration through the Remote Service Management rule

Enabling this rule in Windows Firewall will allow your SIRIS to connect and create a hypervisor connection for screenshots and hypervisor virtualizations:

1. On the host, open the Windows Firewall with Advanced Security program.

2. Select Inbound Rules, and navigate to the Remote Service Management (NP-In) rule.

Figure 1: Remote Service Management (NP-In) (click to enlarge)

3. In the Actions sidebar, click Enable Rule.

Figure 2: Enable Rule (click to enlarge)

4. Proceed to the Setting up the Hypervisor Connection section of this article. If the setup fails, follow the steps in the Enabling and configuring winrm and Windows Firewall section.

Enabling and configuring winrm and Windows Firewall

Run the following commands directly on the host. You must use an elevated command prompt as they will not run properly in Windows PowerShell.

Setting up and configuring Hyper-V requires local administrator rights. To set up Hyper-V as a domain account, follow this procedure, simulating local admin permissions.

1. From an elevated Command Prompt session, run the winrm quickconfig command to enable remote management.

Figure 3: Enabling remote management (click to enlarge)

2. Enable basic authentication: winrm set winrm/config/service/auth @{Basic="true"}

Figure 4: Enabling basic authentication (click to enlarge)

3. Enable transfer of unencrypted data on the WinRM service:

Enabling this feature will allow the transmission of authentication information over HTTP.

winrm set winrm/config/service @{AllowUnencrypted="true"}

Figure 5: Enabling unencrypted data transfer (click to enlarge)

4. Create a new Inbound rule to allow TCP ports 139, 445, 5985, 5986, and 3260 through the Windows Firewall. These ports are for Samba, WinRM, and iSCSI.

5. Launch the Windows Firewall with Advanced Security control panel, and select Inbound Rules → New Rule. In the New Inbound Rule Wizard, select Port and click Next.

connect.jpgFigure 6: New Inbound Rule Wizard (click to enlarge)

6. Select TCP, and then select Specific local ports. Specify ports 13944559855986, and 3260 for the forwarding rule, and click Next.

Figure 7: Configuring ports (click to enlarge)

7. Select Allow the connection on the Action tab, and click Next.

Figure 8: Allow the connection (click to enlarge)

8 Select Domain, Private, and Public on the Profile tab, and click Next.

Figure 9: Applying rule locations (click to enlarge)

9. Select a name for the new firewall rule, and Finish.

7_-_Windows_Firewall_-_Name_Firewall_Rule.pngFigure 10: Rule name and description (click to enlarge)



When running the winrm quickconfig -q command, you receive output similar to the following:

C:\Users\ottad>winrm quickconfig -q
WinRM service is already running on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:
Configure LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.
    Message = Access is denied.
Error number:  -2147024891 0x80070005
Access is denied. 


According to Microsoft, local Administrator accounts other than the built-in Administrator account may not have the rights to manage a server remotely, even if the production machine has remote management enabled.

You will need to configure the Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting to allow local Administrator accounts to manage the server remotely.

To disable these restrictions, follow the below steps.

You may need to reboot the production machine for these changes to take effect.

1. In the Windows Registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, and change the value of the LocalAccountTokenFilterPolicy key to 1.

2. If the LocalAccountTokenFilterPolicy entry does not exist, create a new DWORD Value called LocalAccountTokenFilterPolicy. Change the key's value to 1.


You are unable to add a Hyper-V connection to the Datto appliance using domain credentials, but you can add it without issue using local credentials.


This issue indicates that the domain administrator account does not have the correct permissions to manage Hyper-V hosts with Hyper-V Manager remotely. See Remotely manage Hyper-V hosts with Hyper-V Manager (external link) for information about configuring a domain administrator account with Remote Management permissions.

Setting up the Hypervisor Connection

1. Access the GUI of your SIRIS over your LAN or through a Remote Web connection.

2. From the Datto appliance's Overview page, click Configure → Hypervisor Connections.

3. Click Add Connection.

Hypervisor_1.PNGFigure 11: Hypervisor connections screen (click to enlarge)

4. Enter a unique name for the new hypervisor connection, and the IP address, hostname, or FQDN of the Hyper-V host that the Datto appliance needs to connect to. Select Hyper-V from the Hypervisor Type menu.

H-V-address.PNGFigure 12: Connection Name tab (click to enlarge)

5. On the Hypervisor Login tab, enter the credentials for a user that has the appropriate permissions to configure and control Hyper-V on your host. You will need the username and password, as well as the domain for the user (if applicable).

H-V-login-creds.PNGFigure 13: Hypervisor Login tab (click to enlarge)

If you receive an error message stating "Failed to execute command on host," review the Technical Notes section of this article to ensure that your Hyper-V configuration meets the specified requirements.

X_-_Hypervisor_Failed_-_Check_Requirements.pngFigure 14: Failed to execute command on host (click to enlarge)

6. If the wizard does not report any errors, click Finish to exit the Hypervisor Connection wizard.

Figure 15: Successful connection (click to enlarge)

The Datto appliance will return you to the Hypervisor Connections screen, where you will see the newly-added connection listed in the HyperV Connections pane. Click the radio button under Use for Screenshots if you would like the agent to use the resources of your hypervisor during screenshot verification.

Figure 16: Hyper-V screenshot offload option (click to enlarge)

If you need to update the hypervisor credentials for an existing connection, delete the old one, and then replace it using the *original* connection name and the new credentials. You will not lose data.

Performing a Hyper-V Restore

When you create a hypervisor connection to your host, you can use it to restore systems that are protected by your SIRIS appliance. To start, click the Restore tab at the top of the Datto appliance's GUI.

Figure 17: Restore tab (click to enlarge)

1. On the Restore tab, select the protected system that you want to restore to your Hyper-V server, and then select Virtualize via Hypervisor. Select the Recovery Point and the Hypervisor connection for the restore, then click Start Virtualization.

H-V-Recovery-Point.PNGFigure 18: Restore from a Backup (click to enlarge)

2. The virtualization settings page will load, and the Datto appliance will automatically allocate the virtual machine's resources based on the OS type detected. You can make resource adjustments or add network adapters to the Virtual Machine directly from the Hyper-V Manager on your server.

For Hyper-V virtualizations, there is no view of the virtual machine's console in the SIRIS UI. For direct console access to the VM, use Hyper-V Manager on the Hyper-V host to connect to the console.

Figure 19: Virtualization settings page (click to enlarge)

3. If you need to modify the virtual machine, Datto recommends gracefully powering off the virtual machine from within the guest operating system. It is possible to stop the VM directly from the SIRIS UI, but this would be equivalent to a hard power-off instead of a graceful shutdown.

Figure 20: Shutting down a VM in Hyper-V (click to enlarge)

4. After making the resource changes, use Hyper-V Manager or the SIRIS UI to power the VM back on. In Figure 18, a technician increased the virtualization's core count from 1 to 4, provisioned 4 GB of RAM, and added a network adapter.

Manual resource changes made in Hyper-V Manager do not reflect in the SIRIS UI at this time.

Figure 21: Modifying VM settings through Hyper-V (click to enlarge)

5. When you are finished using your restore, return to the SIRIS Restore tab and select Stop and Unmount. Note that this will destroy the Hyper-V virtualization, along with all changes made to it since the VM was first booted. If the virtual machine was in production, make sure you back up your changes before unmounting it.

Do not destroy the Virtual Machine directly from Hyper-V Manager on the Hyper-V host. Doing this will result in a hung restore on your SIRIS, which will require assistance from Datto Technical Support to resolve. 

Additional Resources

Was this article helpful?

4 out of 5 found this helpful

You must sign in before voting on this article.

Want to talk about it? Have a feature request?

Head on over to our Datto Community Forum or the Datto Community Online.

For more Business Management resources, see the Datto RMM Online Help and the Autotask PSA Online Help .

Still have questions? Get live help.

Datto Homepage