Наш клиент начал развертывание системы, которая требует использования веб-доступа к удаленному рабочему столу для их NOC.
Каждый сайт настроен для RDWA и имеет уникальный URI. При доступе к веб-интерфейсу конечным пользователям, как и ожидалось, предоставляется экран входа в систему [Рис. 1]. Они открываются, запускается компонент Active X RDWA [рисунок 2], и их просят войти на удаленный компьютер [рисунок 3], но затем появляется сообщение об ошибке [рисунок 4]
фигура 1
фигура 2
Рисунок 3
Рисунок 4
Эта проблема исчезнет, если попытаться установить одно соединение с браузером, работающим от имени администратора. Если браузер запускается от имени администратора. Рисунки 1 - 3 такие же, вы видите синий экран входа в систему, и все работает. Последующие соединения с запущенным браузером без учетные данные администратора в порядке.
Однако это работает только для каждого сайта и для каждого пользователя. В ближайшие пять лет у нас будет 700 сайтов, а в оперативном центре, которому нужен доступ, будет 40 пользователей, которые не сидят на одном месте каждый день. Конечно, разрешение доступа администратора конечным пользователям неприемлемо.
Раньше с этим не сталкивался.
Другие важные моменты.
Удаленная система - это готовое развертывание от третьей стороны, а не конфигурация, которую я могу контролировать. Они ответили, что «это работает для них», и проблема была локальной для рабочего стола, на котором запущен RDWA (как показано на примере использования локальных администраторов).
Удаленная система находится в отдельном домене, и между ними не существует доверительных отношений.
Удаленная система - 2008 R2
Сначала я подумал, что элемент Active X для RDWA не запускается. Чтобы решить эту проблему, я создал новый объект групповой политики, который поместил эти сайты в зону интрасети, а затем установил для всех элементов управления в этой зоне значение «Разрешить / принять», это не имело никакого эффекта (RSOP показывает успешное применение объекта групповой политики).
Похоже, что Active X является запускается, как показано на рисунке 2 выше. Однако теперь, похоже, есть следующий фрагмент сценария VB, который пытается выполнить локально, но я не могу определить, что это такое или что он может делать.
Кто-нибудь может предложить какие-либо мысли о том, какие шаги я могу предпринять, чтобы определить причину этой проблемы?
РЕДАКТИРОВАТЬ: В ответ на Drifter104.
Я наткнулся на упомянутый ключ реестра и протестировал его. Никакого эффекта. Похоже, что это устраняет ту же проблему для полнофункционального клиента RDP, но не влияет на клиент RDWA.
Повторный запуск от имени администратора не привел к повторному созданию ключа лицензирования MS на тестовой машине.
На данный момент у нас есть обходной путь (для HKCU \ Software \ Internet Explorer \ main \ TabProcGrowth установлено значение 0). Хотя производительность оставляет желать лучшего.
VB не имеет ничего общего с причиной ошибки.
Это распространенная ошибка вплоть до xp и обычно возникает из-за того, что режим лицензирования сервера, к которому вы подключаетесь, установлен для каждого устройства. Чтобы решить эту проблему, удалите следующий раздел реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing
Однако, если после удаления у вас все еще есть проблема, вам необходимо снова подключиться с помощью «Запуск от имени администратора». Я знаю, что вы не хотите этого делать, и полностью согласен с тем, почему. Однако это общепринятое решение проблемы.
Также стоит изменить режим лицензирования сервера на пользователя с устройства.