Функционал сервера удаленных рабочих столов (сервера терминалов) для клиентских операционных систем Windows появился еще с XP. Дело в том, что при тестировании Windows XP SP2 beta не было ограничений на использование удалённых рабочих столов. Именно с беты умные люди и выдернули необходимую библиотеку, благодаря чему XP SP2 приобрел функционал сервера терминалов. Ограничение на 10 одновременных подключений в XP также обошли путём патча библиотеки tcpip.sys. В итоге, получился достаточно “лёгкий” продукт, который многие используют до сих пор из-за своей простоты и малой ресурсоёмкости.
Ситуацию с удалёнными рабочими столами в Widows Vista рассматривать не будем. Ибо уже не актуально. На данный момент самой современной клиентской ОС является Widows 7. На ней и остановимся. Как повысить её функционал до многопользовательского сервера терминалов, думаю не стоит особо расказывать. Всё делается аналогично старой доброй XP, а именно заменой на пропатченный termsrv.dll.
Настройка RemoteApp. Запуск удаленных приложений через терминальную сессию.
Об этом можно почитать в гугле. Информацию, откуда он появился для Windows 7 мне никто не предоставил. Но добившись функций сервера терминалов в семёрке, я продолжил исследования. Тем более, что аналогичное решение уже есть для windows xp – то использование “тяжелой” 7-ки для не совсем осмысленно.
Раз уж современные серверные ОС Windows Server 2008 и 2008 R2 позволяют предоставлять помимо обычных терминальных сессий еще и приложения сквозь бесшовный терминал (TS RemoteApp), то данный функционал явно присутствует в современной Windows 7. Приложение в терминале – вещь еще более интересная, чем удалённый десктоп. Зачем пользователю видеть удалённый рабочий стол, кнопки “Пуск” итд, тратить на это дополнительный трафик?
А чтобы ограничить пользователя и урезать ему функционал – настраивать множественные групповые политики? Раз уж удалённому пользователю необходимо только приложение, то пусть оно откроется как обычное (как при запуске с его компьютера) и покажет только окно самой программы. Пользователю будед комфортно, а администратору спокойней. Полагаю, что непрофессионал (читай – девачка, которая ходит “фкантакти” и никогда не догадается, что жесткий диск — это винчестер) даже не отличит – разницу в том, терминальная ли это сессия или приложение запущено локально. Выдать может только медленная загрузка приложения (например, при низкой скорости соединения или загруженности сервера), но опять же данные вещи можно списать на “тормоза” компа или глюки виндус
В общем задача:
сделать из Windows 7 терминальный сервер удалённых приложений (Terminal Server RemoteApp) для доставки оных в любую точку земного шара пользователям стандартной Windows XP SP3.
Решение. Патчим termsrv.dll (подчеркну dll-ки разные на x86 и x64), создаем максимальное количество одновременных подключений. Проверяем работоспособность удалённого рабочего стола. Если всё ОК – переходим к активации функционала TS RemoteApp. Делается это – правкой одного(!) ключа реестра.
Как исправить «Не удается открыть приложение». Не работают Ножницы в Windows 11
Открывает regedit, ищем “TSAppAllowList”, в нём правим значение ключа с нуля на еденицу.
Теперь добавляем необходимое приложение, которое будед запускаться в бесшовном терминале. Создаём раздел внутри TSAppAllowList. Название произвольное. Внутри раздела прописываем имя приложения и путь к нему. Каждый раздел будед посвящен отдельному приложению.
Возьмём для примера – стандартный виндовый калькулятор. В разделе создаём строковые параметры Name и Path. Полагаю, что их смысл понятен из приложенной ниже картинки. В некоторых англоязычных источниках предлагается в разделе TSAppAllowList создавать раздел Application, а уже в нём создавать разделы удалённых программ. Но в моём варианте всё и так заработало.
Всё! Windows 7 TS RemoteApp edition готов к боевым испытаниям! Осталось донастроить для данных целей Windows XP SP3 (не знаю у кого как, но у меня со всеми последними обновлениями, скачивающимися через встроенный автообновлятор). Так что если что-то незаработает – обновляйтесь. Возможно есть путь проще при помощи возможных визардов, но я делал следующим образом.
Кстати, для Windows XP SP3 существует обновление для поддержки RemoteApp. Скачать его можно здесь (не забываем выбрать language вашей ОС), но у меня работало всё и без него.
Открываем в XP SP3 в Пуск => Программы => Стандартные = “Подключение к удалённому рабочему столу”. Прописываем IP сервера (вашего псевдо TS RemoteApp на базе Windows 7), куда будем подключаться. Затем жмём внизу окна “Сохранить как”.
Выбираем путь куда будем сохранять файл подключения *.RDP. Сохраняем. Идём туда, куда сохраняли – открываем блокнотом наш RDP-файл. Находим следующие значения (если таковые уже имеются – заменяем):
[code]remoteapplicationmode:i:1
remoteapplicationprogram:s:calc
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe[/code]
Замечу, что основной параметр приложения это “remoteapplicationprogram:s:” после него БЕЗ ПРОБЕЛОВ прописывается имя приложения или путь/имя приложения. Тут мои эксперименты продолжились. Для калькулятора можно прописать calc, calc.exe или C:windowssystem32calc.exe (путь в удалённой ОС). Я подставил вместо calc – Notepad (Блокнот) и на удивление всё заработало. Даже без прописывания в реестре Windows 7 приложений.
Помните что такое “Переменные среды”, чтобы не пытаться запустить без пути то, чего в “переменных средах” нет. То есть если вам нужно какое-то конкретное приложение, а не стандартное виндовое, то пишите полный путь к нему. Если приложение будет прописано в реестре Windows 7, а в параметрах RDP – только имя, то соответственно, если приложения не будет в “переменных средах”, то будет выдана ошибка, что приложение не найдено и терминальная сессия закроется.
Еще одним правилом будет то, что у вас (вернее у того пользователя под которым вы зайдете в терминал) также должны быть права на запуск приложения и права на доступ к той директории, в которой находится данное приложение.
Итак… Запускаем наш “ярлык”.
Удалённый сервер попросит Имя пользователя и Пароль. Вводим и подключаемся. Приложение в бесшовном терминале – доставлено.
Источник: 13g.ru
RemoteApp 1C и модальные окна. Решено
После долгих поисков в каком режиме работать с 1с, был выбран RemoteApp. Не будем углубляться в правильность выбора, статья не про это.
Вначале все было хорошо и все радовались. Потом у одного пользователя, с его слов: “зависает 1С, и весь компьютер”. При осмотре выяснилось, что RemoteApp образует прозрачный фон и соответственно куда не кликайте, ощущение зависшего компьютера.
Немного изучив вопрос, стало ясно, что проблема с фокусом модального окна RemoteApp.
Продолжали работать.
После очередного обновления, еще у одного пользователя перестал корректно работать RemoteApp. Причем работать стало практически нереально.
Стал копать глубже.
Как оказалось проблема стара как мир, а решения нормального нет.
Оффицеално:
- 1С говорить, что виноват microsoft;
- microsoft утверждает, что проблема в 1С;
И нет этому спору конца….как спору «Что появилось раньше — курица или яйцо?»
Есть много всяких рекомендаций, обновлений, фичей. но все они, лично мне, не помогли.
Наблюдается эта проблемма с разными версиями Windows. В моем случаи это был Windows 10 у пользователя и Windows server 2008R2.
Годы идут, а проблема перетекает из версии в версию. Вроде и Windows обновился и 1С обновилась, а проблемы остались.
- Первая стоящая статья, которую я нашел на одном из блогов, говорила о том, что человеку помогло перейти с Win7 на Win8 и вроде как все заработает. Конечно столь кардинальных мер не хотелось, но курс был задан.
- Второй момент, который меня насторожил, это то, что проблемы у второго пользователя начались после очередного обновления Win10.
- Третье, мы знаем, что за RemoteApp по факту отвечает mstsc.exe
Сложив эти три факта воедино, родилась идея, что виноват все таки microsoft в лице mstsc.exe.
Было решено откатить mstsc.exe до рабочей версии. Ничего умнее как взять mstsc.exe с компа где все работает и перенести его на комп с “глюками”, в голову мне не пришло.
Итак порядок Действий(для компов с одной версией Windows, в моем случаи Windows 10 pro 64x ):
- диагностика. В моем случаи уже при старке RemoteApp, было видно, что что-то пошло не так.
Как должен выглядеть RemoteApp при старте
Как выглядел RemoteApp на проблемных машинах
Проверяем версии mstsc.exe, скоре всего у проблемных машин они будут одинаковые и отличаться от версий на нормально работающих компах.
- Если все, выше описанное, верно. Идем за копм где все работает, заходим в папку где храниться mstsc.exe, по умолчанию C:WindowsSystem32
копируем два файла:
идем за компьютер где глючит RemoteApp и заменяем соответствующие файлы mstsc.exe и mstscax.dll на скопированные ранее. (старые mstsc.exe и mstscax.dll лучше переименовать или скопировать, вообщем бекап наше все )
- После замены проверяем версию. Если все сделано правильно, версия измениться на рабочею.
Теперь 1с должна корректно работать через RemoteApp.
- Главное найти корректно работающею версию mstsc.exe для своей ОС
Я для Windows 10 pro 64x использовал версию 10.0.14393 скачать
- Как посмотреть версию mstsc.exe читаем тут
- Файлы mstsc.exe и mstscax.dll легко переименовать с помощью Unlocker1.9.2
Источник: www.vtemme.ru
Ошибка RDP: Удаленному рабочему столу не удалось найти компьютер
В этой статье мы рассмотрим базовые приемы диагностики проблемы с RDP подключением к удаленному рабочему столу. К примеру, при попытке установить подключение к рабочему столу удаленного сервера с помощью стандартного клиента mstsc.exe (Remote Desktop Connection), появляется строка «Инициализация удаленного подключения…», а затем пользователь получает ошибку:
Удаленному рабочему столу не удалось найти компьютер %PCName%». Это может означать, что %PCName% не принадлежит указанной сети. Проверьте имя и домен компьютера, к которому выполняется подключение.
Remote Desktop Can’t Find the computer %PCName%. This might mean that %PCName% does not belong to the specified network. Verify the computer name and domain that you are trying to connect to.
В большинстве случае эта ошибка свидетельствует о том, что имеются проблемы с вашим DNS сервером, из-за которых ваш компьютер не может отрезолвить указанное имя.
В первую очередь убедитесь, что вы правильно указали имя удалённого RDP хоста в клиенте RDP в поле Компьютер .
Попробуйте подключиться к RDP серверу по IP адресу вместо DNS имени.
Затем попробуйте выяснить, знает ли ваш DNS сервер FQDN имя RDP сервера, к которому вы подключаетесь (%rdpserver%). Откройте командную строку с правами администратора и выполните команду:
Убедитесь, что команда вернула IP адрес сервера, например:
В том случае, если команда вернула некорректную запись, попробуйте на клиенте сбросить кэш DNS ( ipconfig /flushdns ) и разрешить имя вашего RDP сервера с помощью nslookup еще раз.
В том случае, если команда Nslookup по прежнему возвращает неверную запись, откройте файл hosts комадой:
В том случае, если в файле отсутствуют статические записи для вашего RDP сервера (это, в общем-то, правильно), вы можете попробовать добавить их вручную (тем самым вы сможете обойти некорректные записи, которые возвращает ваш DNS сервер). Нужно добавить строку формата:
Если проблема при этом решится — виноват ваш DNS сервер, вам нужно проверить записи на нем, либо сообщить о проблеме администратору DNS.
Проверьте доступность RDP сервера с помощью команды ping:
Затем следует проверить, что с клиента на сервере доступен RDP порт 3389 (это порт для RDP подключения по-умолчанию). Проще всего проверить доступность порта с помощью PowerShell команды:
Test-NetConnection rdpserver -port 3389
В том случае, если команда Test-NetConnection вернула TcpTestSucceeded : False, это означает что RDP служба на удаленном компьютере не включена, либо подключение блокируется файерволом на стороне клиента, сервера или на межсетевых экранах или маршрутизаторах между ними.
Несколько советов, которые стоит проверить, при невозможности подключиться к удаленному RDP хосту:
- Попробуйте обновить версию вашего RDP клиента (особенно это актуально, если вы используете Windows XP, Windows 7 или 8.1).
- Попробуйте использовать альтернативный rdp клиент — Remote Desktop Manager.
- Временно отключите антивирус и файервол на стороне клиента и сервера и проверьте RDP подключение.
- В том случае, если вы подключаетесь с клиента Windows XP, а на стороне сервера включена функция NLA (Network Level Authentication — проверка подлинности на уровне сети ), то на стороне клиента XP можно включить поддержку NLA только через реестр.
- Удаленное RDP подключение не возможно, если для учетной записи пользователя, под которым вы подключаетесь, не задан пароль.
Если ошибка «Удаленному рабочему столу не удалось найти компьютер» возникает при выполнении удаленного RDP подключения со страницы RD Web Access, попробуйте в настройках RDP подключения вручную указать правильный адрес сервера RD Gateway (подключение через RDWebAccess выполняется не через стандартный порт 3389, а через 443 порт HTTPS ) и попробовать подключиться. Если подключение успешно установится, значит у вас неправильно настроен сервер RDWebAccess.
Чтобы исправить проблему, откройте консоль IIS на сервере RD Web Access. Перейдите в раздел Sites –> Default Web Site -> RDWeb -> Pages. Откройте раздел Application Settings и в параметре DefaultTSGateway укажите внешнее DNS имя вашего сервера RD Gateway, под которым он должен быть доступен внешним клиентам.
Источник: vmblog.ru