Как расшарить USB-ключ защиты 1С для использования в виртуальной машине Hyper-V?

Есть физический сервер с базами 1С, лицензия привязана к USB-ключу, который подключён напрямую к железу. Нужно было выполнить P2V‑миграцию на существующий Hyper‑V; учту, что виртуальные машины Hyper‑V напрямую не видят подключённые к хосту устройства. Я создал VHDX, клонировал сервер на него и поднял виртуальную машину. Для проброса USB‑ключа 1С использовал VirtualHere (сервер на хосте и клиент в VM); пробная версия VirtualHere позволяет постоянно подключать одно USB‑устройство. Сначала всё работало — базы открывались, ошибки лицензии не было. На следующий день, при проверке, процессы VirtualHere (сервер и клиент) были запущены, подключение к «расшаренному» USB‑ключу не прерывалось, но 1С выдал «лицензия не найдена». Перезапуск VirtualHere не помог — 1С перестала видеть ключ. В чём могут быть причины такой проблемы и обязательно ли покупать платную лицензию VirtualHere/другой софт, чтобы избежать этого?
  • 23 марта 2026 г. 7:00
Ответы на вопрос 4
Короткий ответ: причина, скорее всего, не в «магии 1С», а в том, что аппаратные «ключи защиты» (HASP/Hasp-like, RuToken и т.п.) очень чувствительны к способу доступа: если USB‑ключ проброшен по сети (VirtualHere/USB‑over‑IP), то при любом ресете/пере‑энумерации/смене владельца/контекста драйвера 1С может перестать его видеть. Платная версия VirtualHere не является единственно возможным решением, но в боевой эксплуатации её (или другой стабильный USB‑over‑IP продукт) часто берут именно ради надёжности и поддержки. Ниже — причины, как диагностировать и что можно сделать (включая бесплатные альтернативы).

Возможные причины падения видимости ключа
- Ресет USB‑устройства/контроллера на хосте или сеть‑скачок — виртуальная пере‑энумерация ключа, 1С «потеряла» постоянную привязку.  
- VirtualHere/клиент запущен в пользовательском сеансе, а 1С работает как служба под SYSTEM — устройство доступно не в тому контексте.  
- Драйвер ключа (Sentinel, RuToken и т.д.) установлен/занят на хосте или конфликтует в виртуальной машине.  
- Проброс не был «исключительным» (уже держится другим процессом/хостом).  
- VirtualHere trial/ограничение: поведение демо/бесплатной версии иногда неудобно при рестартах; также возможны баги в конкретной версии.  
- Сетевые/таймауты: некоторые ключи делают низкоуровневые проверки времени и отклика — сетевой ретрансфера может нарушить.  
- 1С кэширует информацию о ключе, а при смене устройства нужен перезапуск сервера 1С/службы фоновой проверки.

Как диагностировать (порядок действий)
1. Посмотреть логи VirtualHere (и на сервере, и на клиенте) — там видно attach/detach/ошибки.  
2. В VM открыть Диспетчер устройств — виден ли ключ? Если нет — проблема на уровне проброса/драйвера.  
3. Проверить, в каком контексте запущен VirtualHere‑клиент: как пользователь или сервис? И в каком контексте работает 1С (приложение/служба).  
4. Проверить, не видит ли хост ключ локально (и не пытается ли его удержать).  
5. Перезапустить службу/процесс 1С после подключения ключа — иногда помогает.  
6. Посмотреть события в Event Viewer, а также логи драйвера HASP/Token (если есть).  
7. Попробовать вручную detach/attach в VirtualHere и снова открыть базу — есть ли реакция.

Что можно попробовать оперативно (без покупки)
- Установить VirtualHere‑server как сервис на хосте и VirtualHere client как сервис в VM (чтобы устройства были доступны в системном контексте). В документации VirtualHere есть инструкции по установке как сервиса.  
- Отключить «USB selective suspend» и энергосбережение USB на хосте и в VM.  
- Обновить VirtualHere до последней версии (иногда баги исправлены).  
- Переустановить драйвер ключа (Sentinel/другой) в VM, затем снова подключить устройство.  
- Использовать usbip/usbipd‑win (открытый проект) для теста — бесплатно; но совместимость с конкретным ключом не гарантирована.  
- Если есть возможность, подключить ключ в другую машину тестово (чтобы исключить аппаратную ошибку ключа).  
- Перезапуск 1С (службы/пользовательского процесса) после проброса — временное решение.

Альтернативы и долгосрочные решения
- Купить платную лицензию VirtualHere или другой коммерческий USB‑over‑IP продукт (USB Network Gate, Donglify и т.п.). Платные решения обычно дают более стабильную работу, поддержку и функции (например, автопереподключение, сервисный режим, устранение ограничений демо). Это часто самый простой путь для стабильной эксплуатации.  
- Использовать usbipd‑win (Windows USB/IP) — бесплатный, но стабильность с аппаратными ключами может быть хуже. Стоит протестировать.  
- Discrete Device Assignment (DDA) — пробросить физический USB‑контроллер целиком в VM (требует поддержки серверного железа и аккуратной настройки). При правильном выполнении VM получает «реальный» контроллер и ключ виден как локальный — очень стабильно, но сложно в настройке и не всегда применимо.  
- Запросить у поставщика 1С сетевую/плавающую лицензию или дополнительный ключ/репликацию — иногда проще и официально правильно.  
- Физически подключать ключ к серверу лицензий (выделенному ПК/сервису) и использовать сетевой режим лицензирования, если 1С и ключи поддерживают.

Рекомендация
1. Для быстрого восстановления: проверьте логи VirtualHere и Device Manager, установите клиент и сервер как сервисы, перезапустите 1С после прикрепления ключа.  
2. Если хотите надёжное и долгосрочное решение для продакшна — либо настройте DDA (если инфраструктура позволяет), либо купите коммерческий USB‑over‑IP продукт и тестируйте в штатном режиме. Также обсудите с вашим поставщиком 1С возможность перехода на сетевую лицензию — это часто самый корректный путь.

Если хотите — пришлите:
- логи VirtualHere (сервер + клиент),  
- скриншот/вытянутое состояние в Device Manager в VM,  
- как запущены сервер/клиент (пользователь/служба),  
и я помогу пошагово диагностировать и предложить более конкретное решение.
у триалки virtualhere, есть проблемы с запуском как службы насколько я помню. <br/> Я запускал её из планировщика, но это требует некоторых вещей. У пользователя должны быть права на запуск как пакетного задания. И у него должен быть живой сеанс пользователя, возможно у вас стоят ограничение на жизнь сессии. <br/> Ну и из сессии пользователя можно посмотреть как там вообще цепляется ключ. Но это все такое, весьма не надежное. Рассмотрите возможность перехода на ESXI, или аналогичный гиппервизор, который позволяет прокидывать USB устройства. Либо купите usb hub сетевой, который позволяет прокидывать usb ключи по сети. <br/> Если же речь идет о эмуляторе.. то лучше бы вам купить лицуху.
У меня когда-то давно была в чем-то похожая проблема с проброской реальных физических ключей в линуксовом сервере на виртуалку с виндой. Сервер мог день проработать и все хорошо, а потом в какой-то момент всех выбрасовало - нет лицензий. <br/> <br/> В конце-концов оказалось, что у физических ключей VendorID и DeviceID идентичны, а потому виртуальная машина видела два ключа как один. Переделал на уникальные айдишники, которые выдавал линух, и все заработало. <br/> <br/> <blockquote>Пробная лицензия позволяет без ограничений по времени подключать одно usb устройство. </blockquote> <br/> А у вас тут изначально всего один ключик - то ли серверный без которого на винде кластер не стартует, то ли клиентские лицензии без которых всех будет выбрасывать. Важны оба!
Смените технологию виртуализации, например virtualbox позволяет пробрасывать usb устройства (осторожно с лицензированием, oracle накладывает какие то ограничения на использования не для личного использования). <br/> <br/> Под windows qemu вроде бы умеет пробрасывать usb, когда то я очень давно проводил эксперименты, они были не успешные... так же есть открытая реализация передачи usb по сети <a href="https://github.com/vadimgrn/usbip-win2" rel="nofollow">https://github.com/vadimgrn/usbip-win2</a> (я просто нагуглил, по названию пакета, это какой то третий уровень форка от оригинального, который уже лет 10 не поддерживается) <br/> <br/> В идеале, сменить хост операционную систему на linux и использовать либо самостоятельно qemu/kvm/virtualbox либо через какой-нибудь менеджер типа proxmox/libvirt/... <br/> <br/> Если будете пользоваться linux, то наилучшие результаты получите пробросом не отдельного usb устройства по VendorID/DeviceID а целиком usb контроллер (можно даже приобрести дополнительный, если не хватает портов на материнской плате, к тому же на дешевых может быть только один контроллер). При пробросе целиком контроллера будет корректно обрабатываться инициализация драйверов устройства в гостевой машине. <br/> p.s. по уму на windows server так же можно настроить проброс контроллера целиком - Discrete Device Assignment <br/> <br/> Если же использовать простой проброс по id, то настоятельно рекомендую сначала на хост машине отключить в udev автоматическую инициализацию устройства, если для обычных флешек это не фатально, то для более сложных устройств может быть критично. <br/> <br/>
Похожие вопросы