Отказ соединиться с загадочным сообщением об ошибке: “учетная запись пользователя не может получить доступ к видео машины”
Если Вы настаиваете на том, чтобы управлять bandwith для каждой компании затем, (или Ваш ISP) необходимо поместить маршрутизатор в местоположение с формированием QoS трафика.
Следующий шаг является брандмауэром. Существуют различные варианты для выбора из:
- 4 различных физических брандмауэра (лучшая безопасность и сегрегация)
- 1 физический брандмауэр, 4 контекста защиты (виртуальные брандмауэры)
- 1 физический брандмауэр, 5 интерфейсов (снаружи, компания A, компания B и т.д.)
Последняя опция могла дать Вам формирование трафика на уровне брандмауэра, но намного более опасно, если каждая компания имеет их собственного администратора, который хочет управлять брандмауэром.
Внутренне Вы будете или нуждаться в абсолютно отдельной физической сети для каждой компании или использовать VLAN для логичного разделения сетей.
Это почти наверняка звучит как изменение делегированного администрирования для Hyper-V. Я' м предполагая, что вы не администратор задействованных серверов? Что ж, разрешения для Hyper-V могут быть доступны администратору, запустив консоль управления Microsoft (mmc.exe) и добавив оснастку для диспетчера авторизации или проблемы с брандмауэром, DCOM или WMI.
К счастью, вы или администратор не должны знать, как выполнять все эти шаги . Существует инструмент HVRemote , который позаботится обо всем за вас: http://code.msdn.microsoft.com/windowsdesktop/Hyper-V-Remote-Management-26d127c6
Он доступен только в виде файла сценария Windows, поэтому вы можете изучить его внутреннюю структуру и увидеть, как он работает. Но администратору нужно просто запустить hvremote /add:DOMAIN.EXAMPLE.COM\Username на целевом сервере. В него также встроены некоторые диагностические инструменты, чтобы помочь вам выяснить, почему вы не можете получить доступ к цели.
Однако , почему вы используете подключение к виртуальной машине для доступа к «своей» виртуальной машине? Если ваши администраторы не предоставляют вам доступ к удаленному рабочему столу, они почти наверняка делают это неправильно (или жалко, чтобы избежать лицензирования удаленного рабочего стола?), И это не идеально, и, возможно, нарушает правила лицензирования для Windows или Windows Сервер. Просто знайте, что есть определенно лучшие, более поддерживаемые способы безопасного доступа к виртуальным машинам, чем то, что вы делаете. Например, одна проблема с использованием подключения виртуальной машины вместо удаленного рабочего стола заключается в том, что он не подлежит аудиту, если администратор подключается к консоли машины, когда вы вошли в систему. Есть и другие проблемы. В общем, подключение к виртуальной машине - плохой способ подключиться к машине.
Сегодня я столкнулся с этой проблемой на Server 2008 R2, и инструмент HVRemote, а также другие приведенные выше рекомендации не помогли ее решить.
У нас есть пара хостов Hyper-V, которые не кластеризованы или не присоединены к домену, на которых размещено несколько виртуальных машин Windows. Хосты работали почти месяц, и никаких изменений через диспетчер авторизации не вносилось.
Мы начали получать «учетная запись пользователя не может получить доступ к видео машины» утром на одном хосте, а затем начали получать ее позже, что в тот же день на другом хосте. Оба этих хоста были созданы примерно в одно время.
Мы сделали 3 вещи, чтобы решить эту проблему:
- Вручную добавили соответствующего пользователя к назначению ролей в AzMan. Хотя группа пользователя (в нашем случае «администраторы»)было уже участник, добавив пользователя непосредственно в роль, решил это на один хозяин. И удаление этого пользователя из ручного назначения ролей оставило его работающим.
- Отключите и снова включите «разрешить сохранение учетных данных», это исправило его на другом хосте.
- Эти исправления были предприняты независимо на каждом сервере, в каждом В случае выхода пользователя из системы и повторного включения оба сервера имели длительные сеансы, которые также могли способствовать возникновению проблемы.
Перед тем, как попробовать описанное выше, мы также попытались создать новую учетную запись пользователя в группе администраторов с соответствующими назначение ролей через их локальную группу (не непосредственно в назначении ролей) безуспешно.
У меня есть подозрение, что проблема вызвана тем, что назначения ролей, возможно, были повреждены или "истекли" через некоторое время, поскольку оба сервера столкнулись эта проблема одинакова, и оба они не присоединены к домену, и их хранилища авторизации хранятся локально.