Networkless Guest Processing in vSphere Environments
When working with vSphere environments, it is possible for Veeam Backup & Replication to use a network-less connection method (VIX) if direct communication fails. This method uses VMware VIX/vSphere Web Services to push the runtime components into the machine and manage them. If the VM being protected is in a DMZ or other network-isolated configuration, it may not be possible to get RPC working and require that connectivity via VIX be investigated. Reference: https://www.veeam.com/kb1788.
Forcing VMware VIX in Isolated Environments
If Veeam Backup & Replication will be operating in a vSphere environment where the Veeam server and its components will never have direct network connectivity to the Guest OS of the Virtual Machines, it is possible to force network-less guest processing connection (VIX) to be attempted first.
For all Veeam Backup & Replication Versions:
Create the following registry value on the Veeam Backup & Replication server:
Key Location: HKLMSOFTWAREVeeamVeeam Backup and Replication
Value Name: InverseVssProtocolOrder
Value Type: DWORD (32-Bit) Value
Value Data: 1
0 = Try RPC (admin$ share) first, then failover to VIX. (Default behavior)
1 = Try VIX first, then failover to RPC (admin$ share)
Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.
For Veeam Backup & Replication versions 9.x through 10a:
For older versions, the registry value must also be created on each Guest Interaction Proxy that the Backup Job will use.
Note that the Key Location is different.
Key Location: HKLMSOFTWAREWow6432NodeVeeamVeeam Backup and Replication
Value Name: InverseVssProtocolOrder
Value Type: DWORD (32-Bit) Value
Value Data: 1
0 = Try RPC (admin$ share) first, then failover to VIX. (Default behavior)
1 = Try VIX first, then failover to RPC (admin$ share)
Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.
Networkless Guest Processing in Hyper-V Environments
When working with Hyper-V environments, it is possible for Veeam Backup & Replication to use a network-less connection method (PS Direct) if direct RPC communication fails. This method uses PowerShell Direct to push the guest processing runtime components into the machine and manage them.
Forcing PowerShell Direct in Isolated Environments
If Veeam Backup & Replication will be operating in a Hyper-V environment where the Veeam server and its components will never have direct network connectivity to the Guest OS of the Virtual Machines, it is possible to force network-less guest processing connection (PS Direct) to be attempted first.
For all Veeam Backup & Replication Versions:
Create the following registry value on the Veeam Backup & Replication server:
Key Location: HKLMSOFTWAREVeeamVeeam Backup and Replication
Value Name: HvVssPowerShellDirectPriorityOverNetwork
Value Type: DWORD (32-Bit) Value
Value Data: 1
0 = Try RPC (admin$ share) first, then failover to PowerShell Direct. (Default behavior)
1 = Try PowerShell Direct first, then failover to RPC (admin$ share).
Note: Veeam Services do not need to be restarted. The registry setting will go into effect on the next job run.
Challenge
When using Veeam Backup & Replication with a VMware environment the following error may be seen when using the Guest Credentials Test or when processing a VM that is in a DMZ or Isolated environment.
In this example, two attempts can be seen. The first is a failure to connect directly because the VM is in a different network. The second is the VIX-related failure due to «Access is denied.»
Log File Examples
Task.<vmname>.<morefid>.log in C:ProgramDataVeeamBackup<job_name> on Veeam Server
VeeamVixProxy_ddmmyyyy.log in C:ProgramDataVeeamBackup of Guest OS
Cause
Veeam Backup & Replication uses the VIX API as a network-less connection method to perform Guest Processing when a VM cannot be contacted directly via RPC. Due to the way VIX operates, it is blocked by Windows User Account Controls. Also, because VIX relies on VMware Tools, if VMware Tools is out of date, issues may occur.
Solution
In VMware environments, Veeam Backup & Replication can use two methods to connect to a guest: RPC or VIX. If RPC is testing successfully, it is generally acceptable for the VIX test to fail as it will not likely be used.
Ensure the correct account is used
To use VIX for Guest Processing, one of the two following accounts must be specified for Guest Processing:
- The Built-in Administrator (i.e., hostnameAdministrator)
Note: This must be the original Built-in Administrator who has a SID that ends in -500. This user is unique and has the ability to bypass Windows User Account Controls. Even if the account was renamed, it will work.
- The Domain Administrator (i.e, domainAdministrator)
Troubleshoot VMware Tools
- If issues with VIX connectivity persist, confirm that VMware Tools is up-to-date for the VM to be protected.
For information regarding issues when upgrading VMware tools, please reference: https://kb.vmware.com/kb/1001354 - Uninstall VMware Tools, and reinstall VMware Tools.
For information regarding uninstalling VMware tools from the command line: https://kb.vmware.com/kb/2010137
Note: If the Veeam Server, which acts as the default Guest Interaction Proxy, is in an isolated network, separate from the production VMs, RPC will fail. In such a situation, building a dedicated Guest Interaction Proxy
that sits in both the isolated and production networks may be preferable to allow for RPC-based Guest Processing.
More Information
If none of the provided account options are viable, it is possible to disable UAC. This will allow all accounts to be used for VIX-based networkless guest processing. This option should be considered a last resort as it involves disabling a major Microsoft Windows OS security feature.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
С ошибкой 53 «не найден сетевой путь» можно столкнуться при попытке получить доступ к общим папкам и файлам по локальной сети. Узнаем подробнее, как ее исправить?
Содержание
- 1 Чем вызвана ошибка?
- 2 Подключение с помощью командной строки
- 3 Проверка ping
- 4 Отключение антивирусной программы
- 5 Включение общего доступа
Чем вызвана ошибка?
Сбой при подключении по указанному сетевому пути может произойти по следующим причинам:
- Установка соединения по сети блокируется брандмауэром или антивирусной программой.
- Подключение ограничено фоновым процессом, который вмешивается в работу компонентов сети.
- Отключен общий доступ к содержимому на удаленном компьютере.
Подключение с помощью командной строки
Если пытаетесь получить доступ через командную строку, проверьте правильность написания команды. Она должна отображать адрес сервера и папки, удаленного компьютера.
Откройте командную строку от имени администратора с помощью системного поиска.
В консоли введите команду, придерживаясь следующего формата:
net use F: «\servershare»
Где server – имя компьютера, share – наименование общей папки.
Проверка ping
Чтобы узнать, правильно ли работает сетевой сервер, запустите ping тест и проверьте, есть ли ответ. Кроме того, с помощью этого теста можно проверить, есть ли потери пакетов, что также приводит к ошибке 53. Для его запуска выполните указанные шаги.
В строке системного поиска наберите cmd, при отображении искомого результата щелкните на запуск от имени администратора.
В консоли запустите команду для проверки связи с сервером или компьютером:
ping (IP-адрес сервера)
Если команда возвращает все пакеты без их потери, это значит, что сеть настроена правильно. В противном случае проверьте настройки сети.
Отключение антивирусной программы
Если ping возвращает все пакеты, попробуйте отключить антивирусную программу, чтобы узнать, причастна ли она к этой ошибке 53. Есть много случаев, когда антивирус препятствует подключению к папке по сети. Поэтому временно отключите его и посмотрите, установлено ли соединение между устройствами.
Включение общего доступа
Иногда совместное использование файлов может быть отключено с Панели управления. Для включения, выполните следующие шаги.
Откройте Панель управления командой control из окна «Выполнить» (Win + R).
Переключите режим просмотра в правом верхнем углу на крупные значки и перейдите в раздел «Центра управления сетями и общим доступом».
На левой панели щелкните на вкладку «Изменить дополнительные параметры общего доступа».
Разверните профили «Домашний и рабочий» и «Общий». Отметьте флажками опции «Включить сетевое обнаружение» и «Включить общий доступ к файлам и принтерам» обоих профилей.
Сохраните изменения на «Применить», закройте окно. Попробуйте подключиться к общему ресурсу, к которому ранее не удавалось из-за ошибки 53.
Если по-прежнему не удается подключиться по сети, попробуйте это сделать из режима чистой загрузки. Если в этом режиме ошибка не препятствует получению доступа, то причина в стороннем фоновом процессе. Для его поиска включайте одно за другим приложения, пока не обнаружите то, которое вызывает ошибку 53.