Приложения RemoteApp представляют собой программы, удалённый доступ к которым предоставляется с помощью служб удалённых рабочих столов, но выглядят они так, будто это локальные приложения. Проще говоря, приложение RemoteApp представляет собой доступ к удалённому рабочему столу, ограниченному одним приложением. Однако, несмотря на формулировку выше, пользователь может запускать несколько приложений или несколько экземпляров одного и того же приложения в одном сеансе.
Использование приложений RemoteApp выглядит хорошей альтернативой традиционным удалённым рабочим столам, поскольку это приносит для системного администратора целый ряд преимуществ. Эти выгоды связанных с тем, что пользователю более не доступен рабочий стол полностью и его действия ограничены границами запускаемого приложения. А как известно, что чем меньше у пользователя возможностей крутить и настраивать, тем надёжнее и безопаснее работает система. Пользователям так же удобно использовать приложения RemoteApp, поскольку они выглядят так же как и любое локально установленное приложение, что значительно упрощает работу.
В этой статье будут рассмотрены следующие моменты:
- Процесс публикации приложений RemoteApp
- Проверка работоспособности приложений RemoteApp
- Изменение параметров опубликованных приложений RemoteApp
- Отмена публикации приложений RemoteApp
Публикация приложений RemoteApp
Для того, чтобы опубликовать какое-либо приложение RemoteApp нужно открыть Диспетчер задач, перейти в Службы удалённых рабочих столов и там перейти по ссылке с именем коллекции сеансов. В окне коллекции сеансов нажимаем на ссылку Публикация удалённых приложений RemoteApp. В том случае, если уже имеются опубликованные приложения, необходимо нажать на кнопку Задачи и в открывшемся меню выбрать Опубликовать удалённые приложения RemoteApp.
Следует помнить, что публикация хотя-бы одного приложения приведет к отмене публикации удалённого рабочего стола. Это означает, что в одной коллекции могут быть либо удалённый рабочий стол полностью либо некий набор отдельных приложений RemoteApp.
Публиковать можно как предустановленные приложения так и свои собственные. Попробуем опубликовать одно предустановленное (Калькулятор) и одно собственное приложение (Foxit Reader). Для того, чтобы опубликовать встроенное приложение необходимо отметить его и нажать кнопку Далее.
С приложениями, которых нет в списке несколько сложнее. Тут требуется соблюсти одно важное условие — необходимо чтобы публикуемое приложение размещалось по одному и тому же пути на все серверах узлов сеансов. Если это так, то нажимаем кнопку Добавить и указываем необходимое приложение.
Как видно на рисунке, указание приложения, в данном случае, происходит на сервере RDSH2.
После того, как все приложения отмечены нажимаем кнопку Далее.
В следующем окне подтверждаем свой выбор нажав кнопку Опубликовать.
После публикации приложений RemoteApp, будет отображено окно в котором показано состояние приложений и ошибки, возникшие при установке. Если же ошибок не возникло, то нажимаем кнопку Закрыть, для завершения процесса публикации.
Проверка публикации программ RemoteApp
После успешной публикации удалённых приложений RemoteApp, проверим корректность их работы. Для этого осуществим веб-доступ к RDS с одной из рабочих станций домена. Напомню, что для того чтобы получить веб-доступ к службам удалённых рабочих столов необходимо перейти по специальной ссылке вида https://servername/rdweb. В рассматриваемом случае, это ссылка https://rdwh.domain.local/rdweb.
Как мы видим, приложения успешно опубликовались и можно попробовать получить к ним доступ. Запустим Foxit Reader.
Приложение успешно запустилось и готово к использованию. О том, что это приложение RemoteApp говорит иконка с изображением двух направленных друг к другу стрелок рядом с иконкой основного приложения.
Посмотрим, как отобразилось подключение на серверной стороне. Зайдем в свойства коллекции сеансов и посмотрим на панель Подключения.
На скриншоте выше отображено осуществлённое подключение. Как видим, несмотря на то, что путь к программе Foxit Reader мы указывали на сервере RDSH2, подключение было выполнено к серверу узлов сеансов RDSH1.
Изменение параметров приложений RemoteApp
Каждое приложение RemoteApp имеет ряд ключевых опций, которые можно изменить в соответствии с требованиями. Для того, чтобы зайти в меню настроек приложения достаточно в окне коллекции сеансов (в данном случае в окне Коллекция сеансов RDS) на панели Удалённые приложения RemoteApp вызвать контекстное меню приложения, параметры которого необходимо изменить, и там выбрать единственный пункт Изменить свойства.
На вкладке Общие окна свойств приложения доступны следующие настройки:
- Имя удалённого приложения RemoteApp. Позволяет задать произвольное имя для опубликованного приложения.
- Показывать удалённое приложение в службе веб-доступа к удалённым рабочим столам. Если выбрать пункт Нет, то приложение не будет отображаться списке приложений на странице веб-доступа и не будет доступно пользователям, хотя будет установлено на серверах узлов сеансов и будет иметь статус опубликованного.
- Папка удалённого приложения RemoteApp. Этот параметр позволяет упорядочивать приложения RemoteApp, раскладывая их по папкам.
Кроме настроек, в данном окне отображается информация о пути размещения приложения, его псевдониме и иконке.
Папку удалённого приложения RemoteApp можно либо задать вручную, написав в соответствующем поле желаемое имя папки, либо выбрав из существующего списка, если папки были созданы ранее. Поместим приложение Foxit Reader в папку Офисные приложения и посмотрим, что произойдет со страницей веб-доступа.
Как видим, выбранное приложение Foxit Reader было успешно помещено в папку Офисные приложения.
На вкладке Параметры можно задать параметры командной строки для приложения. Именно здесь можно разрешить использовать любые параметры командной строки или вообще запретить их использование. Помимо этого можно задать принудительное использование заранее заданных параметров. В целом ряде случаев, последний параметр очень выручает.
Свойства вкладки Назначение пользователей позволяют настроить видимость приложения в системе веб-доступа для заданных пользователей или групп пользователей. Поскольку по умолчанию все пользователи коллекции сеансов имеют доступ ко всем опубликованным в ней приложениям, данная вкладка позволяет гибко настроить доступ пользователей к приложениям RemoteApp внутри самой коллекции.
На вкладке Сопоставление типов файлов можно задать типы файлов, которые автоматически будут открываться с помощью выбранного приложения RemoteApp.
Следует помнить об одном очень важном ограничении — данная опция не работает в случае веб-доступа к приложениям.
Отмена публикации приложений RemoteApp
В случае, когда удалённое приложение больше не используется, целесообразно отменить его публикацию. Рассмотрим выполнение этой операции на примере приложения Калькулятор.
Для того, чтобы вызвать мастер отмены публикации удалённых приложений RemoteApp нужно выбрать пункт Отменить публикацию удалённых приложений RemoteApp в меню Задачи на панели Удалённые приложения RemoteApp.
На первом шаге мастера выбираем из списка опубликованных приложений RemoteApp приложение, публикацию которого необходимо отменить. Можно выбрать все приложения и в таком случае после отмены их публикации станет возможен доступ к удалённому рабочему столу полностью.
В окне с подтверждением выбора предлагается проверить правильность выбранных приложений и нажать кнопку Отменить публикацию.
После успешного выполнения операции отмены публикации отобразится окно, сообщающее об этом.
***
Как видим, процессы добавления, удаления и настройки удалённых приложений RemoteApp довольно быстро и удобно осуществляются из единой панели Удалённые приложения RemoteApp на вкладке коллекции сеансов.
Прочитано:
24 516
Итого как я начал свое изучение работы системы Server 2012 R2 Std меня пока многое не радует, а именно то что вроде как сложнее стало использование RemoteAPP и разворачивание терминального сервера на этой оси, но отступать ни в коем случае нельзя. Хоть и не удобно работать пока во всяком случае, а изучать нужно — это и повышение квалификации и новые требования к соискателям, да и переходить на новый функционал также необходимо или по крайней мере иметь ввиду. Вот сейчас я для себя разберу как создать свое приложение на терминальном сервере и опубликовать его во всех шагах с которыми мне пришлось столкнуться.
По правильному все нужно настраивать самим чтобы быть уверенным в используемом конечно если Вы такой же как и я ответственный системный администратор.
Как Вы уже помните в прошлой заметке когда я знакомился с RemoteAPP по умолчанию для всех пользователей домена создана коллекция с дефолтным именование: QuickSessionCollections, так вот ее нужно будет удалить.
Запускаю оснастку «Server Manager» — Win + X → Control Panel — Administrative Tools, после переходу в апплет Remote Desktop Services — Collections и в правой части через выделение дефолтной коллекции по правом клику нажимаем Remove Collection — Yes
Вот теперь уже лучше ничего дефолтного нет, начну пожалуй с создания своей собственной коллекции. Все также находясь в апплете Remote Desktop Services — Collections — TASKS — Create Session Collection и передвигаюсь за мастером настройки по шагам:
Before You Begin, Next
Collection Name:
- Name: → polygon
- Description: → кто как хочет я же люблю чтобы все было подписано.
И нажимаю Next
RD Session Host:
выделяю текущий сервер и нажатием по стрелочке предопределяю что система выбрана в пуле;
И нажимаю Next
User Groups: нужно указать на кого будет распространена новая коллекция, либо на пользователя и/или же на группу, либо на всех пользователей домена. Лучше будет если только тем кому надо предоставлен доступ, так правильнее.
Add… — ввожу alektest (и себя не забываю ekzorchik) нажимаю Check Names после OK, конечный результат данного шага выглядит так:
И нажимаю Next
User Profile Disks: можно указать местонахождение профиля пользователя и его размер, в моей задачи это пока не требуется, а потому я снимаю галочку Enable user profile disks
И нажимаю Next
Confirmation: проверяю по результирующему выводу настройки сделанные выше и если все OK, то нажимаю Create
Ожидаю когда моя коллекция — polygon создастся
И нажимаю Close
Теперь когда коллекция создана пора переходить к созданию приложения.
Запускаю оснастку «Server Manager» — Win + X → Control Panel — Administrative Tools, после переходу в апплет Remote Desktop Services — Collections — Polygon — Tasks (RemoteAPP Programs) — Publish RemoteApp Programs и идем по шагам за мастером:
RemoteApp Programs: в правой части будут указаны все приложения которые установлены на данном терминальном сервере если же в списке не оказало того которое необходимо его можно добавить — Add…
(Установил клиент 1С на терминальный сервер версию клиента 8.2.19.121)
у меня при указании местонахождения исполняемого файла 1С => 1cv8.exe сработал аларм о не возможности :
Дело в том, что я указал путь просто: C:Program Files (x86)1cv828.2.19.121bin1cv8.exe (как я думал наивно что это: 1C Enterprise 8 (thin client), а это не правильный формат об этом как раз ошибка и говорит, нужно указать путь вот в таком вот формате:
\srv-serv.polygon.localc$Program Files (x86)1cv82common1cestart.exe
добавленное приложение будет отмечено в списке как показано на представленном ниже скриншоте
И нажимаю Next
Confirmation: проверяю и после нажимаю Publish
Completion: если Вы как и Я видите надпись: The selected RemoteApp programs were published successfully for the polygon collection, то значит Вы только что опубликовали свое первое приложение.
И нажимаю Close
Теперь проверяю с клиентской станции собственно как выглядит подключение к рабочей области (об это я уже говорил в прошлой заметке) и запуск опубликованного приложения в виде 1С клиента):
Windows 7 Professional SP1 (user&pass: alektest&Aa1234567)— IE — https://srv-serv.polygon.local/rdweb после ввода логина и пароля в рабочую область получаем гордо одинокое приложение клиента 1С доступное этому пользователю:
Когда мы запускаем приложение, то в правом нижнем углу экрана возле часов появляется пиктограмма указывающая, что сейчас мы работаем на удаленном терминальном сервере:
И вот оно долгожданное окно первого запуска клиента 1с, раз первый раз пользователь alektest запускает клиент то он не настроен ни на какой кластер 1с, настроив раз больше уже не понадобиться.
Настроив клиент и авторизовавшись при подключении у кластера 1С получаем запущенное приложение как будто бы оно было запущено локально за одним лишь исключение, что ресурсов на терминальном сервере много больше чем на рабочей станции.
На заметку: первый раз потребуется ввести доменные административные идентификационные данные дабы на сервер прописались ключи и файлы защиты для этого будет выведено специальное окно ввода логина и пароля.
Пример запущенного клиента 1С — он ничем не отличается от локального запуска:
Это конечно все хорошо, а как быть на других рабочих местах, что каждый раз заходить по URL ссылке и оттуда запускать, вот бы как ранее экспортировать приложение в виде rdp или msi файла. Загвоздка вот в чем, в оснастке Server Manager на терминальном сервере данная функциональная возможность не предусмотрена, а потому дальнейшие шаги проделываем на самом сервере:
Win + X — Control Panel — RemoteApp and Desktop Connections — Access RemoteApp and desktops — указываю URL подключения вида:
Email address or connection URL: https://srv-serv.polygon.local/RDWeb/Feed/WebFeed.aspx
и нажимаем Next, Next вот только не все так просто как кажется на первый взляд, удаленный компьютер отверг мое подключение:
Исправляюсь: — создаю самоподписанный сертификат для текущего сервера:
Запускаю оснастку «Server Manager» — Win + X → Control Panel — Administrative Tools, после переходу в апплет Remote Desktop Services — Collections — TASKS — Edit Deployment Properties — Certificates — выделяю RD Web Access — Create new certificate…
- Certificate name: srv-serv.polygon.local
- Password: 712mbddr@
Allow the certificate to be added to the Trusted Root Certification Authorities certificate store on the destination computers отмечаю галочкой
Store this certificate: Отмечаю галочкой и указываю путь где куда его нужно сохранить на сервере дабы потом распространить на рабочие станции
Certificate path: c:srv-serv.pfx
По такому же принципу можно создать сертификаты и для остальных ролей сервисов RD
И нажимаю OK — Apply
И нажимаю OK
Win + X — Command Prompt (Admin) — mmc — File — Add/Remove Snap-in… — находим оснастку Certificates — нажимаем Add Computer Account — Next — Finish и OK, здесь нужно перенести текущий сертификат сервера srv-serv.polygon.local из Personal в Trusted Root Certification AuthoritiesCertificates
Далее повторяем шаги по подключению через Панель управления на самом сервере к RemoteAPP (Control Panel — RemoteApp and Desktop Connections) и вот уже другое разнообразие запрашивается
И вуаля все проходит успешно
Нажимаю Finish
И вот к чему я так стремился:
После того, как было настроено удаленное подключение к RemoteAPP в системе становится доступным следующий каталог:
Вот собственно и всё по шагам которые нужно сделать, что опубликовать свое собственное приложение целью которого будет организовать в последствии терминальный сервер с собственным набором приложений которые используют ресурсы самого сервера, а не ресурсы рабочих станций. Да и управлять единым способом намного удобнее чем каждый раз бегать и вручную что-то проделывать. Да интересно, но когда одну и туже операцию проделываешь не один десяток раз хочется добавить в свою жизнь автоматизации. Пока я подведу черту в этой заметке она работоспособна и практична. На этом я прощаюсь и до новых встреч, с уважением автор блога — ekzorchik.
Publishing RemoteApps in Windows Server 2012
This Wiki is about publishing RemoteApps
in Windows Server 2012. More info on the Distribution of those Remote Apps and desktops can be found in this wiki:
http://social.technet.microsoft.com/wiki/contents/articles/14488.distribution-of-remote-apps-and-desktops-in-windows-server-2012.aspx
The RD WebAccess role in Windows Server 2012 can be deployed using one of the new Scenario Based Deployments (Quick or Standard deployment) or can be deploying using the traditional Role Based Deployment. After doing either of these deployments Remote Apps
can be published using the Server Manager Console.
We open up the Server Manager and select Remote Desktop Services from the left pane. Assuming that we already created the Session Collection to host our RemoteApps we select
that Session Collection. Here we have the ability to centrally publish and unpublish RemoteApps. Note that a Session Collection can be two different types. When no Remote Apps are published, the Session Collection is of type «Remote Desktop» which basically
means that only full desktop is published. As soon as you have successfully published your first Remote App, the Session Collection is changes to type «Remote App Programs» and the full desktop is no longer published, as a mix in one Session
Collection is not supported.
We now either select “Publish RemoteApp programs to this collection” or select “Publish RemoteApp programs” from the TASKS dropdown menu.A wizard will be launched that will scan the RD Session Host Servers involved in this Session Collection to retrieve a list of installed applications that you might want
to publish. We can select one of these applications (or multiple) or we can click “Add another program” which will launch a second dialog in which we are able to browse the Session Host in order to select an application of choice.
After selecting one or more applications, we click Next and confirm the chosen applications to be published to the RD WebAccess server(s).After the wizard is finished, we have the RemoteApps available in RD WebAccess. By default, all RemoteApps will be made available in the root of the RD WebAccess page. To
create hierarchy and folders please follow Adding
folders in RD WebAccess in Windows Server 2012.If desired we can edit the properties of the RemoteApps from the server manager by right clicking and choosing edit.Here we can change the name, icon and desired folder.
In the parameters tab we can set the desired command line parameters we wish to use.
In the user assignment screen, we can certain users or groups that we would like to allow explicit access to certain applications. By doing so, the application in question
will only be available to users specified here (either by user or group membership).
In the File type and associations screen we are able to construct a certain association to a RemoteApp Program. Please note however, that this association only applies to
Remote App and Connections and not to user connecting through the RD WebAccess page or a separate .RDP file.
Comments
-
6 Feb 2013 1:32 PM
Hi Jonathan,
Thanks, good catch! I’ll update the Wiki with the info you supplied!
-
13 Feb 2013 6:09 AM
Glad I could help. I kept finding on the web about batch files and I figured there had to be another way. Once I stumbled on it, I had to share!
-
11 Apr 2013 11:05 AM
Nice wiki. This is a bit off-topic but maybe someone can help. I published the remoteapps and can run them on my debian clients (using rdesktop) gracefully, but drive redirection won’t work. Is there any policy restricting redirection turned on by default? If yes, what is it?
-
1 Jul 2013 1:36 PM
Microsoft was stupid for removing the MSI method. Seriously what user wants to go to some other website for their app!! Morons I tell you. You can’t get easier than clicking an icon on the desktop and that is what users want, that is truly a seamless experience.
-
10 Oct 2013 11:20 AM
If you configure the default RemoteApp URL group policy for users who get their desktop from a remote desktop deployment published desktop, it doesn’t work and you get a warning in the RemoteApp event log:
The installation of the default connection has been cancelled. A default connection cannot be used on a system that is part of a Remote Desktop Services deployment.
What’s going on here? Why should this be the case? Seems to make no sense that I can only use this automated method of distributing RemoteApps to users on regular PC desktops, and not published desktops.
remoteapp в 2012 R2 без домена — начну с главного: всё нормально и быстро настраивается. Опубликовать remoteapp в 2012 R2 без домена не получится, но это и не нужно.
При обновлении 2008 R2 до 2012 R2 на этапе проверки совместимости, установка попросила удалить роль Удаленных рабочих столов. Удивился. Ладно.. После обновления стало понятно, Microsoft в очередной раз перехитрила саму себя: теперь нормально работать с RDP можно лишь в составе домена.
Зачем.. Если у меня сервер 1С на 5 бухгалтеров, зачем мне роль AD DS? Думаю я не одинок в этом вопросе. Почитал в интернете, решение есть! Кто-то ставил роль контроллера домена, в виртуалке поднимал ещё один сервер, вводил в домен и на нём уже удаленные рабочие столы. Всё проще. Солюшенов несколько, решил собрать воедино.
Сервер
Установка роли
Службы удаленных рабочих столов (Remote Desktop Services), Далее, отмечаем чекбоксы: Лицензирование удаленных рабочих столов (Remote Desktop Licensing), Узел сеансов удаленных рабочих столов (Remote Desktop Session Host), со всем соглашаемся, установка, перезагрузка.
В Диспетчере серверов, в пункте меню Средства, появилась закладка Terminal Services (или Remote Desktop Services для 2016).
Настройка параметров RDP
Настройка всех параметров RDP теперь в групповых политиках. Отдельной графической оснастки, как было раньше, нет:
Win+R - gpedit.msc - Конфигурация компьютера (Computer Configuration);Административные шаблоны (Administrative Templates) -;
Компоненты Windows (Windows Components)Службы удаленных рабочих столов (Remote Desktop Services) -.
Узел сеансов удаленных рабочих столов (Remote Desktop Session Host) - Лицензирование (Licensing)
Редактируем два параметра:
Использовать указанные серверы лицензирования удаленных рабочих столов (Use the specified Remote Desktop license servers)— включено — указываем имя сервера;Задать режим лицензирования удаленных рабочих столов (Set the Remote licensing mode)— включено — на пользователя.
В соседних ветках настраиваются все параметры подключения клиентов.
Далее: Диспетчер серверов - Службы удалённых рабочих столов (Terminal Services) - правой кнопкой на сервере - Диспетчер лицензирования удаленных рабочих столов (Remote Desktop Licensing Manager) - Активировать сервер. Сведения об организации: обязательно нужно заполнить первую страницу, вторую можно оставить пустой.
После активации запускается Мастер установки лицензий:
- Выбираем
Enterprise Agreement— Далее (бессмысленный набор цифр ищем в интернете, ищется легко, буквально вторая/третья ссылка) — вводим номер — Далее — выбираем число лицензий и тип на пользователя. ЗаходимДиспетчер серверов - Все серверы - правой кнопкой на сервере - Средство диагностики лицензирования удалённых рабочих столов, проверяем, что нет ошибок.
Создаем файл RDP
На примере 1С предприятия: открываем блокнот и помещаем туда следующую информацию, заменяя имя_сервера на действительное имя сервера или IP:
redirectclipboard:i:1 redirectposdevices:i:0 redirectprinters:i:1 redirectcomports:i:1 redirectsmartcards:i:1 devicestoredirect:s:* drivestoredirect:s:* redirectdrives:i:1 session bpp:i:32 prompt for credentials on client:i:1 span monitors:i:1 use multimon:i:1 remoteapplicationmode:i:1 server port:i:3389 allow font smoothing:i:1 promptcredentialonce:i:1 authentication level:i:2 gatewayusagemethod:i:2 gatewayprofileusagemethod:i:0 gatewaycredentialssource:i:0 full address:s:имя_сервера alternate shell:s:||1cestart remoteapplicationprogram:s:||1cestart gatewayhostname:s: remoteapplicationname:s:1C Предприятие remoteapplicationcmdline:s:
Сохраняем файл, меняем расширение на .rdp, раздаём пользователям.
Реестр
Главный шаг, от которого будет зависеть заработает или нет. Правим реестр на сервере через блокнот:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart] "CommandLineSetting"=dword:00000000 "RequiredCommandLine"="" "Name"="1C Предприятие" "Path"="C:Program Files (x86)1cv8common1cestart.exe" "ShortPath"="C:PROGRA~21cv8common1cestart.exe" "ShowInTSWA"=dword:00000001 "SecurityDescriptor"=""
Проверяем правильность путей, сохраняем с раcширением .reg, закидываем в реестр. Проверяем. Если не работает, смотрим ветку 1cestart. Значения из reg-файла должны перенестись. И на всякий пожарный ветку TSAppAllowList там же, у меня это:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowList] "LicenseServers"=hex(7):00,00 "CertificateIssuedBy"="" "LicensingType"=dword:00000005 "fHasCertificate"=dword:00000000 "CertificateExpiresOn"="0" "CentralLicensing"=dword:00000000 "fDisabledAllowList"=dword:00000000 "CertificateIssuedTo"="" "CustomRDPSettings"="authentication level:i:2"
Возможные проблемы
Когда недавно делал по своей же инструкции, то получил сообщение, что приложения 1С нет в списке разрешенных.
Или вот такое ещё может быть:
Посмотрел на сервере ветку 1cestart:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart
Она пустая. При копировании текста с сайта могут неправильно переноситься кавычки, ещё что-то. Поэтому нужно подправить/проверить вручную.
Path— для 1С 8.3 будет1cv8common1cestart.exe, для 1С 8.21cv82common1cestart.exeShortPathто же самое.
Подключение через интернет
В файлике rdp вместо имя_сервера, можно использовать IP-адрес (или даже IP-адрес с портом через двоеточие, или же указать порт в соответствующей строке). Это позволяет подключать клиентов через интернет и NAT:
- Пробросить на роутере рандомный внешний порт на внутренний 3389 сервера;
- Вбить в файлик внешний реальник офиса с портом.
Конструкцию с RD Gateway считаю излишней. Тем более если делается с пробросом 443 порта на внутренний ресурс, тем более что RD Gateway требует установки роли Web Server, то есть потребляет ресурсы. Чем проще, тем надежнее. После настройки роли RDP и проверки работоспособности смело можно удалить даже фичи для администрирования RDP, они больше не нужны.
Клиенты
Клиенты MAC
Добавляем клиентов MAC OS X:
- Обновляем встроенный в MAC OS X RDP-клиент от MS на последнюю версию;
- Отключаем проверку подлинности.
Если режим remoteapp не нужен, то на этом всё. Если нужен, берём файл rdp, созданный по описанию выше для Windows, меняем имя_сервера на IP-адрес, закидываем на мак и всё работает.
Клиенты Windows XP
Добавляем клиентов Windows XP:
- SP3 должен быть установлен;
- Включаем проверку подлинности на уровне сети (NLA). Тут обновляем RDP-клиент, потом включаем NLA. Сначала КB969084, ребут, потом FixIt. Скачать.
Клиенты Android
Наверное последнее, что нужно сказать по этой теме, для Андроида тоже есть RD Client от MS. Функционирует он штатно и нормально. Приложение бесплатное, загружается через Play Market. Как и для Mac’а файл rdp, закинутый на Андроид, запустится с помощью этого приложения, но логин и пароль при этом сохранить невозможно, а нужно вводить каждый раз.
Связана такая ситуация, с тем, что в новых версиях RDP учетные данные не сохраняются в самом файле rdp, а хранятся в отдельной базе данных. На компьютере эти данные можно посмотреть в Панель управленияУчетные записи пользователейДиспетчер учетных данных, либо Выполнить: control userpasswords2, что тоже самое.
Где искать в Андроиде? Не знаю, да и не очень интересно, так как remoteapp для телефонов и планшетов больше блажь, чем реальная потребность. Обычная RDP-сессия работает? — Работает. Этого достаточно.
Три способа повысить защиту RDP
- Уровень безопасности SSL;
- Уровень шифрования FIPS-совместимый;
- Подключения принимаются только от клиентов с NLA.
Траблшутинг
Залипания
Если возникают на 1 клиентском компьютере, нужно проверить сам компьютер и такие вещи как драйвера на видеокарту, количество свободных ресурсов, потому как залипание может происходить в моменты, когда жесткий диск свопит изо всех сил и даже мышку. Была курьёзная ситуация (несвязанная с данной проблемой), что при нажатии на кнопку мыши щелчок есть, а фактически нажатия нет, поменяли мышку, всё работает.
Если же залипание массовое и с ресурсами сервера всё в порядке, то проблема 90% сетевая. В 2012 R2 для RDP используется как TCP, так и UDP или только TCP. Нужно проверить, что UDP используется. Статья в помощь. Сайт MS. Таже нужно просмотреть политики.
Область применения
Статейка написана давно, более чем 2 года назад, тогда Windows Server 2012 R2 был ещё относительно свежим и хотелось разобраться как же это всё настроить. Был накидан рабочий черновик, вот эта заметка и ни на какую полноту она не претендует. С тех пор поднято несколько серверов в данном режиме, которые работают так по сей день.
Тема исчерпана, но вопросы идут и некоторые люди не понимают нишу использования remoteapp, зачем такой режим, почему именно для 1C, какой тут смысл и в чём заключается выигрыш. Вещи-то очевидные, но раз так, то надо сказать пару слов.
remoteapp не панацея
В общем и целом remoteapp решение нищебродское, если уж по честному. Плюсом есть очень толстые минусы как RDP, так и remoteapp:
- Каждый раз когда пользователь хочет сохранить файл, ему открываются диски удалённой машины. Есть варианты, но это неудобно в работе;
- Далеко не все пользователи продвинутые и с компьютером «на ты», многие очень тяжело воспринимают
remoteapp, они путаются где какой диск, сложно и затратно по времени растолковать им данный режим работы; - Для запуска
remoteappнужно время, так как на сервере должен загрузиться пользовательский сеанс; - При закрытии приложения сеанс отключается и нужно ждать его завершения (минимум 1 минута), если в сеансе открыт конкретный фал, он будет блокирован на запись. Можно разрешить множественные сеансы для пользователя или можно убрать ограничения для отключенного сеанса, тогда возникают другие проблемы;
- В зависимости от версии Windows Server могут возникать различные глюки, связанные с временными задержками (не помню точно в какой версии сервера, но загружается сеанс и его нельзя завершить ~30 секунд сразу после загрузки, было такое);
- Каждое запущенное приложение — отдельный сеанс и отдельная нагрузка на сервер;
- Сам сервер и лицензии для RDP стоят приличных денег, этот вопрос всплывёт рано или поздно.
Может что-то даже упустил из виду, хотя и так немало. Поэтому использовать remoteapp нужно тогда, когда это действительно необходимо.
Примечание. Очень хороший пример когда не нужно использовать remoteapp — Word и Excel.
Зачем 1С remoteapp?
Схема применения 1С может варьироваться в очень широких пределах от локальной однопользовательской базы до сотен пользователей и кластера серверов. Возьмем классический вариант: многопользовательская база на 5-15 пользователей. Работа с такой базой, даже на 5 человек, генерирует большой сетевой трафик и сама база требует серьёзной вычислительной мощности. Вот отсюда и два варианта применения remoteapp для 1С:
- Если чистый файловый вариант базы и как раз 5-6 человек, потому как больше такая схема не потянет, тогда весь обсчёт на клиентах — для того чтобы перенести обсчёт с клиентов на сервер. Это позволяет увеличить число клиентов и одновременно значительно повысить скорость работы без внедрения СУБД;
- Удаленная работа через медленные либо лимитные каналы связи как в файловом варианте, так и в клиент-серверном — передавать изображение намного выгоднее по объёму трафика, чем трафик 1С.
remoteapp vs классический RDP
Обычно в случае 1С база на сервере, а вот документы для работы на локальном компьютере. Всё время сворачивать и разворачивать окно RDP неудобно, remoteapp тут гораздо комфортнее.
Исключения
- Если все клиентские машины достаточно мощные (Core i3 и выше), баз мало (1-2-3), базы файловые, сеть локальная гигабитная, пользователей не больше, скажем, 5 и работа с базой не слишком интенсивная, тут даже сервер не нужен. Подойдёт любой компьютер с гигабитной сетевой картой и быстрым диском. Важный момент, что все машины мощные, так как 1 слабый компьютер станет узким местом и скорость работы будет равняться по нему;
- При удалённой работе есть альтернатива
remoteapp— веб публикация 1С. У каждого из этих решений свои плюсы и минусы; - Используется СУБД и тонкие/веб клиенты. Тогда ничего не надо, стандартные корпоративные каналы достаточно широкие сейчас чтобы переварить такой трафик. Открыть для 1С
TCP 1540, 1541, 1560-1591на FW и вперёд.
Почему 2012 R2
C чистой 2012 без R2 встретиться в работе не удалось и ничего про неё не скажу. Но если сравнивать 2008 R2 и 2012 R2, то последняя имеет значительно перелопаченный код, как следствие быстрее работает на том же самом железе, а сетевой стек до 30% быстрее.
Поддержка самого железа, особенно различных RAID-контроллеров, тоже лучше. И если на 2008 R2 драйвер при установке нужно подпихивать, то в 2012 R2 он скорее всего уже встроен, сталкивался несколько раз. Поддержка RDP 8.1.
Windows Server 2016 уже тоже в продакшене, имеет ряд преимуществ над 2012 R2, но для новых плюшек, таких как вложенная виртуализация, требует современного железа. По этой причине 2012 R2 более универсален.
Windows 2016
Эта статья получила довольно таки широкое распространение. Чего там говорить, вот да.. И как-то однажды, давно, где-то там на форуме, уже не вспомню каком, читал человек пишет: ставил по этой статье с этого сайта (с моего, отсюда) и на 2016 не работает. Дальше обсуждение на n-страниц. Как всегда. Ну не работает и не работает, мож даже и к лучшему. 🙂 Но тут меня недавно (22.04.2021) спросили конкретно здесь, в комментариях: почему не работает с 2016?
Что делать.. заставляете тряхнуть стариной. Уже не ставил этих серверных виндовс пару лет, 1С ещё дольше. Почти всё подзабыл, так что сильно не ругайте, если что-то не то скажу. Итак, нашёл образ, установил в виртуальную машину VMware, поставил все обновы:
Получилось так:
Дальше стал проверять по тексту. И всё в общем-то то же самое. Один в один. Если есть какие-то изменения, то минимум. Почему же не работает? Не знаю, должно работать. И кроме этого всё должно настроится точно по тексту без каких-либо ошибок.
Какие тут были ещё замечания
Первое. Служба Сервера 1C Предприятие не хотела стартовать от текущего пользователя при установке дистрибутива. Пришлось выбрать Создать нового пользователя и всё успешно запустилось. Второе. Сам дистрибутив 1С 8.3.17.1549 и он чисто x64. То есть ставится в папку C:Program Files, а не в папку C:Program Files (x86). Соответственно в reg-файлике нужно сделать изменения:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications1cestart] "CommandLineSetting"=dword:00000000 "RequiredCommandLine"="" "Name"="1C Предприятие" "Path"="C:Program Files1cv8common1cestart.exe" "ShortPath"="C:PROGRA~11cv8common1cestart.exe" "ShowInTSWA"=dword:00000001 "SecurityDescriptor"=""
И как уже говорил нужно контролировать что там добавилось в реестр. И добавилось ли вообще. Ветка TSAppAllowList:
Ветка 1cestart:
В rdp-файлике прописывал не имя сервера, а IP. Потому что мой компьютер не знает какое там имя у виртуальной машины. Прописывать в файл hosts мне было лень.
Запускаю файлик с домашнего компа и вуа-ля:
Другой дистрибутив
Может образ какой-то не тот? Хорошо, скачиваю оценочный образ с Microsoft.
14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_RU-RU.ISO
Опять мега долго ставлю обновления.
Версия после обновлений та же самая, что логично.
Скачиваю платформу 1С, версия 8.3.17.1549, но уже x86+x64. Сначала ставлю x86. Проверяю, не работает. Ищу где ошибка. При экспорте reg-файла не создаются ключи Path и ShortPath. Вообще никак. Добавляю руками (смотри картинку выше). Работает.
Теперь x64. Прям в реестре правлю параметры Path и ShortPath. Накатываю дистрибутив прям поверх x86. Проверяю, работает.
Так что в случае проблем припоминай не было ли каких-то варнингов, ошибок, проверяй всё по второму кругу. Должно работать.
В ЭТОЙ СТАТЬЕ БУДУТ РАССМОТРЕНЫ СЛЕДУЮЩИЕ МОМЕНТЫ:
- Процесс публикации приложений RemoteApp
- Проверка работоспособности приложений RemoteApp
- Изменение параметров опубликованных приложений RemoteApp
- Отмена публикации приложений RemoteApp
ПУБЛИКАЦИЯ ПРИЛОЖЕНИЙ REMOTEAPP
Для того, чтобы опубликовать какое-либо приложение RemoteApp нужно открытьДиспетчер задач, перейти в Службы удалённых рабочих столов и там перейти по ссылке с именем коллекции сеансов. В окне коллекции сеансов нажимаем на ссылку Публикация удалённых приложений RemoteApp. В том случае, если уже имеются опубликованные приложения, необходимо нажать на кнопку Задачи и в открывшемся меню выбрать Опубликовать удалённые приложения RemoteApp.
Следует помнить, что публикация хотя-бы одного приложения приведет к отмене публикации удалённого рабочего стола. Это означает, что в одной коллекции могут быть либо удалённый рабочий стол полностью либо некий набор отдельных приложений RemoteApp.
Публиковать можно как предустановленные приложения так и свои собственные. Попробуем опубликовать одно предустановленное (Калькулятор) и одно собственное приложение (Foxit Reader). Для того, чтобы опубликовать встроенное приложение необходимо отметить его и нажать кнопку Далее.
С приложениями, которых нет в списке несколько сложнее. Тут требуется соблюсти одно важное условие — необходимо чтобы публикуемое приложение размещалось по одному и тому же пути на все серверах узлов сеансов. Если это так, то нажимаем кнопку Добавить и указываем необходимое приложение.
Рис.3 — Указание пути к публикуемому приложению RemoteApp
Как видно на рисунке, указание приложения, в данном случае, происходит на сервере RDSH2.
После того, как все приложения отмечены нажимаем кнопку Далее.
Рис.4 — Выбор публикуемых приложений RemoteApp
В следующем окне подтверждаем свой выбор нажав кнопку Опубликовать.
После публикации приложений RemoteApp, будет отображено окно в котором показано состояние приложений и ошибки, возникшие при установке. Если же ошибок не возникло, то нажимаем кнопку Закрыть, для завершения процесса публикации.
Рис.6 — Отчёт о публикации приложений RemoteApp
ПРОВЕРКА ПУБЛИКАЦИИ ПРОГРАММ REMOTE APP
После успешной публикации удалённых приложений RemoteApp, проверим корректность их работы. Для этого осуществим веб-доступ к RDS с одной из рабочих станций домена. Напомню, что для того чтобы получить веб-доступ к службам удалённых рабочих столов необходимо перейти по специальной ссылке вида https://servername/rdweb. В рассматриваемом случае, это ссылкаhttps://rdwh.domain.local/rdweb.
Рис.7 — Веб-доступ к приложениям RemoteApp
Как мы видим, приложения успешно опубликовались и можно попробовать получить к ним доступ. Запустим Foxit Reader.
Приложение успешно запустилось и готово к использованию. О том, что это приложение RemoteApp говорит иконка с изображением двух направленных друг к другу стрелок рядом с иконкой основного приложения.
Посмотрим, как отобразилось подключение на серверной стороне. Зайдем в свойства коллекции сеансов и посмотрим на панель Подключения.
На скриншоте выше отображено осуществлённое подключение. Как видим, несмотря на то, что путь к программе Foxit Reader мы указывали на сервере RDSH2, подключение было выполнено к серверу узлов сеансов RDSH1.
ИЗМЕНЕНИЕ ПАРАМЕТРОВ ПРИЛОЖЕНИЙ REMOTEAPP
Каждое приложение RemoteApp имеет ряд ключевых опций, которые можно изменить в соответствии с требованиями. Для того, чтобы зайти в меню настроек приложения достаточно в окне коллекции сеансов (в данном случае в окне Коллекция сеансов RDS) на панели Удалённые приложения RemoteApp вызвать контекстное меню приложения, параметры которого необходимо изменить, и там выбрать единственный пункт Изменить свойства.
На вкладке Общие окна свойств приложения доступны следующие настройки:
- Имя удалённого приложения RemoteApp. Позволяет задать произвольное имя для опубликованного приложения.
- Показывать удалённое приложение в службе веб-доступа к удалённым рабочим столам. Если выбрать пункт Нет, то приложение не будет отображаться списке приложений на странице веб-доступа и не будет доступно пользователям, хотя будет установлено на серверах узлов сеансов и будет иметь статус опубликованного.
- Папка удалённого приложения RemoteApp. Этот параметр позволяет упорядочивать приложения RemoteApp, раскладывая их по папкам.
Кроме настроек, в данном окне отображается информация о пути размещения приложения, его псевдониме и иконке.
Папку удалённого приложения RemoteApp можно либо задать вручную, написав в соответствующем поле желаемое имя папки, либо выбрав из существующего списка, если папки были созданы ранее. Поместим приложение Foxit Reader в папку Офисные приложения и посмотрим, что произойдет со страницей веб-доступа.
Как видим, выбранное приложение Foxit Reader было успешно помещено в папку Офисные приложения.
Здесь также можно скачать ярлык на любое из опубликованных приложений или воспользоваться альтернативными методами создания ярлыка RemoteApp
На вкладке Параметры можно задать параметры командной строки для приложения. Именно здесь можно разрешить использовать любые параметры командной строки или вообще запретить их использование. Помимо этого можно задать принудительное использование заранее заданных параметров. В целом ряде случаев, последний параметр очень выручает.
Свойства вкладки Назначение пользователей позволяют настроить видимость приложения в системе веб-доступа для заданных пользователей или групп пользователей. Поскольку по умолчанию все пользователи коллекции сеансов имеют доступ ко всем опубликованным в ней приложениям, данная вкладка позволяет гибко настроить доступ пользователей к приложениям RemoteApp внутри самой коллекции.
На вкладке Сопоставление типов файлов можно задать типы файлов, которые автоматически будут открываться с помощью выбранного приложения RemoteApp.
Следует помнить об одном очень важном ограничении — данная опция не работает в случае веб-доступа к приложениям.
ОТМЕНА ПУБЛИКАЦИИ ПРИЛОЖЕНИЙ REMOTEAPP
В случае, когда удалённое приложение больше не используется, целесообразно отменить его публикацию. Рассмотрим выполнение этой операции на примере приложения Калькулятор.
Для того, чтобы вызвать мастер отмены публикации удалённых приложений RemoteApp нужно выбрать пункт Отменить публикацию удалённых приложений RemoteApp в меню Задачи на панели Удалённые приложения RemoteApp.
На первом шаге мастера выбираем из списка опубликованных приложений RemoteApp приложение, публикацию которого необходимо отменить. Можно выбрать все приложения и в таком случае после отмены их публикации станет возможен доступ к удалённому рабочему столу полностью.
В окне с подтверждением выбора предлагается проверить правильность выбранных приложений и нажать кнопку Отменить публикацию.
После успешного выполнения операции отмены публикации отобразится окно, сообщающее об этом.
Как видим, процессы добавления, удаления и настройки удалённых приложений RemoteApp довольно быстро и удобно осуществляются из единой панели Удалённые приложения RemoteApp на вкладке коллекции сеансов.
В Windows Server 2012 консоль Server Manager работает таким образом, что при попытке публикации приложения RemoteApp, для которого выбран исполняемый файл расположенный на общем сетевом ресурсе, возникает грозное уведомление о том, что мы можем выбирать исполняемые файлы расположенные только на каком-то конкретном сервере RD Session Host (RDSH)…
На самом деле это не так, и мы вполне можем выполнить публикацию исполняемого файла расположенного в сети с помощью командлетов PowerShell из модуля RemoteDesktop…
Рассмотрим публикацию приложения RemoteApp с помощью PowerShell на примере КонсультантПлюс. Но сначала сделаем небольшое отступление в сторону описания особенностей использования КонсультантПлюс в распределённой многопользовательской среде. В нашем примере исполняемый файл этого приложения (cons.exe) расположен вместе с файлами правовых баз данных в общем сетевом каталоге. Нам нужно опубликовать это приложение для пользователей фермы RDS состоящей из нескольких серверов. В ферме RDS используется механизм перемещаемых профилей Roaming User Profiles. Наше приложение для сохранения пользовательских настроек использует специальные служебные каталоги ConsUserData. Поэтому, учитывая нашу специфику перемещаемых профилей, создадим специальный ярлык (*.lnk) для запуска КонсультантПлюс в ферме RDS в режиме RemoteApp.
Дадим ярлыку имя, например CONS_RemoteApp.lnk и разместим его в той-же сетевой папке, где расположен сам исполняемый файл приложения. В качестве рабочей папки обязательно укажем значение ссылающееся на переменную %AppData% которая указывает на часть пользовательского профиля, которая обрабатывается механизмом Roaming User Profiles (это позволит нам добиться того, что при входе на любой сервер фермы RDS, пользователь будет иметь одни и те же настройки в КонсультантПлюс)
Так как с свойствах ярлыка мы указали каталог (%AppData%ConsUserData), которого не существует для вновь создаваемых профилей пользователей, нам придётся позаботиться о его создании, например с помощью Group Policy Preferences (GPP). Создадим в групповой политике применяемой к пользователям на серверах RDS соответствующую настройку GPP в разделе
User ConfigurationPreferencesWindows SettingsFolders
Теперь всё что нам остаётся сделать, это опубликовать созданный ярлык с помощью PowerShell:
Import-Module RemoteDesktop New-RDRemoteApp -Alias ConsultantPlus ` -DisplayName "Консультант Плюс" ` -FilePath "\FileServerConsultantPlusCONS_RemoteApp.lnk" ` -IconPath "\FileServerConsultantPluscons.exe" -IconIndex 0` -ShowInWebAccess 1` -collectionname "KOM-AD01-RDCOLL"` -ConnectionBroker "KOM-AD01-RDS21.holding.com"
Если мы включаем признак публикации приложения на веб-странице RD Web Access и при этом там используются папки, то указать папку в которую нужно разместить ярлык можно добавив к команде ключ:
-FolderName "Бизнес приложения"
Если необходимо ограничить доступ к публикуемому приложению, то к команде можно добавить ключ определяющий перечень доменных групп безопасности:
-UserGroups @("KOMAccountants","KOMLawyers")
Практика показывает, что на текущий момент, опубликованное таким образом приложения отображаются в консоли Server Manager , но при попытке сохранить изменение их свойств возникает ошибка…
Поэтому, если потребуется изменить свойства такого RemoteApp приложения, путь один – PowerShell.
Для того, чтобы дать возможность клиентам работать с базой данных на сервере, но не давать допуск до полноценного RDP-сеанса на удалённом сервере (Windows Server 2012 R2) мы настроим RemoteApp на примере программы «Microinvest Склад Про». Цель этой технологии – ограничить подключение пользователя до рабочего стола и разрешить ему запуск только определенной программы. RemoteApp реализуется с помощью встроенных средств Windows Server, но с помощью стороннего приложения RemoteApp Tool (http://www.kimknight.net/remoteapptool) это можно сделать гораздо быстрее и проще. Рассмотрим способы:
1. Публикация приложения на сервере
Способ №1 (ручное добавление новой ветки в реестр)
- Перейти в редактор реестра (Win+R, regedit)
- Перейти в реестра к ветке HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications
- Cоздать в ней новый раздел с названием нашей программы.
В созданной нами ветке создать несколько параметров:
Name: "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" // Полный путь до .exe файла программы Path: "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" // Полный путь до .exe файла программы VPath: "C:Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" // Полный путь до .exe файла программы RequiredCommandLine: "" CommandLineSetting: 0x00000001 IconPath: "C:Program Files (x86)MicroinvestWarehouse ProWarehouse.exe"IconIndex: 0x00000000ShowInTSWA: 0x00000000
Способ №2 (создание файла .reg)
- Создать и запустить файл с расширением .reg со следующим содержимым:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplicationsMicroinvest Warehouse Pro] "Name" = "Microinvest Warehouse Pro" "Path" = "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" ""VPath" = "C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" ""RequiredCommandLine" = "" ""CommandLineSetting"= dword:00000001 ""IconPath"="C:\Program Files (x86)MicroinvestWarehouse ProWarehouse.exe" ""IconIndex"= dword:00000000 ""ShowInTSWA"= dword:00000000
Создание ярлыка для подключения к RemoteApp
- Создать текстовый файл с именем «ProgramName.rdp» со следующим содержимым:
allow desktop composition:i:1 allow font smoothing:i:1 alternate full address:s:192.168.0.100:3389 alternate shell:s:rdpinit.exe devicestoredirect:s:* disableremoteappcapscheck:i:1 drivestoredirect:s:* full address:s:192.168.0.100:3389 prompt for credentials on client:i:1 promptcredentialonce:i:0 redirectcomports:i:1 redirectdrives:i:1 remoteapplicationmode:i:1 remoteapplicationname:s:Microinvest Warehouse Pro remoteapplicationprogram:s:|| Microinvest Warehouse Pro span monitors:i:1 use multimon:i:1
Использование программы RemoteApp Tool
Создание RemoteApp подключения с помощью этой программы происходит гораздо проще и быстрее.
- После установки и запуска программы в стартовом окне нажимаем на «+» в левом нижнем углу
- В следующем окне указываем путь до исполняемого файла exe файла нужной нам программы и нажимаем «Открыть» в правом нижнем углу.
- После этого в стартовом пространстве появится ярлык выбранного нами файла, выделим его и нажмем «Create Client Connection» для начала создания протокола подключения RemoteApp
- Далее откроется окно создания RDP файла, здесь можно изменить настройки подключения или оставить по умолчанию, далее нажимаем «Create» в правом нижнем углу окна.
- Выберем директорию, где будет сохранен файл и укажем для него название и нажмём «Сохранить» в правом нижнем углу
После создания файла подключения любым из способов его нужно передать удобным способом на клиентские компьютеры, с которых будут происходить подключения.
- Запускаем файл и вводим учётные данные пользователя удаленной машины для подключения, нажимаем «Ок»
- после чего запустится указанное приложение, в нашем случае: Microinvest Склад Про
Процесс использования приложений через RemoteApp создает впечатление того, что пользователь работает на своём пк, а не на удаленной машине. Таким образом мы обезопасим сервер от человеческих факторов, приводящих к повреждению системы и неработоспособности машины.
Время прочтения
11 мин
Просмотры 84K
На основе технического вебинара сделан обзор решений Microsoft для удаленных пользователей, рассмотрены следующие темы:
• Построение терминальной службы на базе Windows Server 2012R2.
• Построение и использование системы виртуальных рабочих столов.
• Построение и использование системы виртуальных рабочих столов на базе Azure RemoteApp.
Расшифровка и запись вебинара под катом.
Сегодня с вами мы поговорим о такой штуке, как удаленная работа пользователей. В Windows Server 2012 есть такая технология RDS, о ней мы поговорим сегодня подробно, а также рассмотрим функционал в Azure RemoteApp.
План нашего мероприятия. Мы поговорим о лицензировании, о тех бизнес-задачах, которые можно решить с помощью уделенных сессий, поговорим на какой базе все это строится, как все этим управлять, что такое RemoteApp. Ответим на вопрос чем RDS отличается от VDI и посмотрим в живую на те технологии, о которых мы будем говорит.
Итак, Windows Server 2012 и его серверная роль RDS. Лицензирование — RDS включен в 2 редакции как стандарт так и в датацентр. Как мы знаем Microsoft сделал абсолютно идентичными по функционалу, отличаются они по работе с виртуализацией.
Что нам необходимо для RDS? Прежде всего лицензии Server Standart или Datacenter. Не забываем также, что количество процессоров учитывается, сейчас на каждую лицензию по 2 физических процессора. А также нам нужны лицензии Call для пользователей, а также лицензии RDS, для возможности подключения терминальных сессий к терминальному серверу. Кроме того, я здесь не указал, очень часто получаю вопросы: некоторые люди строят архитектуру терминального сервера, таким образом, что на терминальный сервер ставится одна версия офиса, и администратор считает, что этого достаточно, чтобы подключить всех пользователей организации. На самом деле это не так, это большая ошибка. Да, офис ставится в одном экземпляре, но лицензий нужно купить столько лицензий, столько пользователей или устройств планируется подключать к нашему серверу. RDS – новое поколение терминальных серверов, в старых версиях ОС, технология называлась «терминальный сервер», сейчас это называется RDS – Remote Desktop Services.
Бизнес- задачи. Основная идея – это подготовить платформу, благодаря которой будет предоставляться доступ либо к рабочему столу, либо к приложениям, для всех пользователей нашей организации. Чаще всего как это выглядит. Мне не раз приходилось устанавливать данный сервер в разных организациях – наиболее это популярно в банках и госструктурах, потому что когда мы, например, разворачиваем какой-то филиал, где-то в глубинке, устанавливаем какое-то отделение. То там не идет речь о максимальных мощностях. Речь идет о том, чтобы люди вовремя и качественно выполняли свою задачу. И для этого, как показывает практика, достаточно иметь такое устройство как тонкий клиент. Благодаря чему пользователей подключается к RDS, устанавливаем терминальную сессию, заходит на сервер и работает на его мощностях, выполняет свои бизнес-задачи. Тоже самое касается и госучреждений, где у нас находится отделение, за пределами крупных городов, там тоже речь о высоких мощностях не идет, поэтому данное решение очень распространено.
Что такое RDS? Он позволяет нам централизованно управлять ресурсами, централизованно и контролировано предоставлять приложения и данные для пользователей. Кроме того, технология RDS подразумевает под собой 2 возможных реализации. Мы посмотрим на примере, когда будем ставить, я покажу где ставится эта роль.
1 тип – технология на базе сессий. Когда пользователь подключается к данному серверу, открывает удаленный рабочий стол и заходит под своей сессией, под своим пользователем.
2 тип – технология виртуальных рабочих столов, то есть по технологии VDI/
Это 2 части одного сервера. Кроме того, RDS может обеспечить быстрый доступ к рабочему месту. Почему? Мы не привязаны к устройству. Мы можем подключится к порталу, подключится к серверу и выполнять свою работу. Есть возможность обеспечить непрерывную работу пользователя – неважно где он находится: на своем рабочем месте в офисе, в командировке, или даже в отпуске.
Какие же новинки у нас появляются? Обновленная работа с технологией RomoteFX, то есть в RDS сервере 2012 и 2012R2 обновлена работа с графикой. У нас оптимизирована потоковая передача данных, кроме того осуществляется поддержка DirectX 11. Кому этот аспект важен — это все уже работает. Как мы знаем именно эти вещи были негативными отзывами по предыдущим версиям системы.
Благодаря использованию RDS получаем единую точку входа. Пользователь залогинился к нам в домен, и получает доступ ко всем нашим ресурсам. В RDS реализовано перенаправление USB, причем USB как на устройстве, на котором мы осуществляем сессию, так и к серверу.
Как мы знаем, Windows сервер 2012 и 2012R2 прекрасно работает с протоколом SMB 3.0. RDS сервера точно так же это коснулось, и мы можем осуществлять хранение дисков для хранения данных пользователей на протоколах SMB и RGCDSun. Кроме того, так как эта технология реализована в server 2012 и 2012R2, данный сервис легко управляем. То есть в менеджере у нас есть закладка, мы с вами рассматривали когда-то, благодаря которой, управление сервером RDS становится интуитивно понятным, впрочем, как и все инструменты, реализованные в winserver 2012.
Ну и конечно же, этот сервис предоставляет возможности высокой доступности, когда работа наших пользователей не будет зависеть от работы только одного сервера.
На базе чего строится RDS? Он строится на базе нескольких ролей, настройку которых можно осуществлять как на разных серверах, так и выбрать простую установку в момент установки, установив большинство ролей на одном сервере.
Какие основные роли мы здесь можем выделить?
Посредник подключения к удаленному рабочему столу. Он занимается подключением клиентского устройства к удаленным приложениям RemoteApp а также рабочим столам на базе сеансов, либо к виртуальным рабочим столам, зависит от того на базе какой технологии мы RDS построили.
Кроме того, у нас есть роль, которая обеспечивает веб-доступ к удаленным рабочим столам. Ее задача – предоставление ресурсов через веб-браузер. Кроме того у нас есть узел сеансов удаленных рабочих столов – данная роль позволяет размещать на сервере удаленным приложения, или основанные на сеансах рабочие столы. У нас есть узел виртуализации удаленных рабочих столов. На данном узле, это у нас сервер Hyper-V, на котором у нас разворачиваются все виртуальные машины, доступ к которым получат все пользователи, использую технологию VDI.
Последнее – это шлюз удаленных рабочих столов, это посредник между клиентами из внешней сети и коллекции сеансов во внутренней сети и приложений. Шлюз – это безопасность, сервис у нас абсолютно безопасный. И благодаря тому что RDS в 2012 и 2012R2 становится более гибким, проработаны абсолютно все недочеты, которые были раньше. Сейчас этот сервис легко реализуем для огромных, масштабных проектов, для больших корпораций. Раньше возникали некоторые вопросы.
Итак, когда мы подключаемся пользователем, к нашему серверу RDS, у нас часто возникало несколько вопросов. Прежде всего: как этим всем управлять? Я вам покажу управление, оно здесь очень простое и интуитивно понятное для любого пользователя. Здесь нет никаких сложностей, но можно было бы выделить такие параметры, которые позволят администраторам прежде всего экономить ресурсы и обеспечить качественную работу своих пользователей.
Мы можем ограничить, установить время окончания разъединённого сеанса. Данный параметр указывает время, спустя которое сервер завершит разъединенную сессию. Если пользователь у нас отключился по какой-то причине, чаще всего это применимо в местах, где связь нестабильна. Если в течении указанного времени пользователь подключился обратно, он попадает в свою же сессию, то есть все ресурсы, с которыми он работает, они активны, он подключится и будет работать дальше. Если же время истекло, то сервер удаляет все временные файлы пользователя и аннулирует всю сессию.
Кроме того, мы можем ограничивать активность, длительность сеанса. Зачем это нужно? Сейчас распространена тенденция, когда компании борются с тем, что пользователи работают слишком долго, «работа должна быть на работе» и т.д. Если этот принцип соблюдается, то очень легко это можно установить правилами: мы ставим максимальное время работы пользователя на сервере RDS. Чаще всего это время ставят немного больше.
Ограничение бездействующего сеанса. Если за какое-то время пользователь не выполнил никаких действий, то проводится его отключение. Полезная вещь: очень часто сталкиваются с тем, что висят сессии, пользователь о них забыл, а нагрузка на сервер идет, и другим пользователям не хватает мощности.
При установке все этих настроек необходимо помнить о том, что пользователям очень не нравится, когда их сессия прерывается. Поэтому желательно провести анализ, аудит, собрать все пожелания, и исходя из этого устанавливать все эти параметры.
RDS сервер позволяет сейчас предоставлять отдельный диск для пользователя. То есть в настройках RDS сервера, в параметрах вы можете указать место, где будет хранится виртуальный диск для каждого пользователя.
Виртуальный диск – это новая «фича», которая призвана исключить устаревший сервис удаленных профилей, перемещаемых профилей. Здесь для каждого пользователя есть возможность создать ограниченный VHDD-диск, будет размещен по тому пути, который вы укажете. Этот диск будет подключаться к пользователю, используя свои настройки. Используя перенаправляемый профиль, перенаправление папок, мы можем реализовать для каждого пользователя его собственные настройки, его профиль.
Лично я во всех своих проектах рекомендую при разворачивании системы ИТ-инфраструктуры реализовывать файловый сервер. Это позволяет создать папку Home для всех пользователей, и эту папку мы можем подключать как диск при входе пользователей используя групповые политики. Это как еще один вариант предоставление диска для пользователей.
Мы рассмотрели первую возможность, когда пользователь входит отдельным сеансом соединяясь со своим удаленным рабочим столом, и использую сервер как свою рабочую машину. То что стоит у него на рабочем столе он использует только как устройство для подключения.
Вторая реализация RDS сервера. Удаленные приложения. Это портал, на который пользователь заходит и видит те приложения, которые ему доступны, с которыми он может работать.
Очень часто мне приходилось слышать вопрос: чем RDS отличается VDI?
Вопрос был корректным до того момента, пока у нас не появляется Windows Server 2012 и 2012R2, где VDI включен в RDS. Если мы говорим о разнице подключений на уровне сессий и виртуальных рабочих столов, то в первом случае мы подключаемся устройствами непосредственно к серверу, заходим как удаленный пользователь на удаленный рабочий стол, работаем на сервере просто каждый со своим профилем. Какие могут быть опасности? В случае получения прав администратора пользователем, никто от этого не застрахован, есть возможность заражение сервера, либо принесение вреда всей организации, всем пользователям.
При использовании VDI – каждый пользователь работает на своей виртуальной машине. Следовательно, нанесение любого вреда будет только конкретной виртуальной машине, с помощью технологии VDI, мы сможем быстро поднять «упавшую» виртуальную машину. При этом мы не приносим вреда нашей организации, и все пользователи продолжают работу. RDS – является критичным сервером, поэтому к планированию его использования нужно подходить очень внимательно. Есть много компаний, где это реализовано, компаний, которые могут вам дать совет о его реализации.
Мы будем двигаться от локальных сервисов, к тому, что у нас есть сейчас в облаках.
Рассмотрим как технология RDS реализована сейчас в облачных инфраструктурах. Конечно же, мы поговорим о Microsoft Azure – это облако Microsoft. Одной из его функций является предоставление доступа к удаленным приложениям. Azure – это бизнес-конструктор. Вы кладете депозит на портале, на личный счет, и при использовании той или иной технологии, нужна она вам или нет – решаете вы, и с вашего счета снимаются деньги за использование сервисов. Как вы помните, там есть калькулятор – он покажет стоимость всех использованных ресурсов, и вы можете прикинуть бюджет еще до начала использования.
Кроме того, есть возможность использовать триальную версию. Вы можете уже использовать сервисы, посмотреть как они работают, еще до их приобретения. Вы можете посмотреть на все функции абсолютно бесплатно.
Мы сейчас посмотрим Microsoft Azure RemoteApp. Предоставляет универсальный доступ ко всем приложениям, безопасный доступ, и, что самое интересное, это будет доступ из любой точки земного шара.
Эта технология позволяет использовать как шаблоны, которые уже есть – это наиболее частые приложение, которые мы используем через терминальную сессию: офисные приложения + какие-то вещи, которые есть у нас на сервере, может быть калькулятор, графический редактор и т.д.
Как это выглядит?
Тот сервер RDS, с которым мы будем работать, находится в виртуальной инфраструктуре. Это к вопросу о том, можно ли реализовать сервер RDS в виртуальной инфраструктуре? – да можно. Подключимся к серверу RDS. В сервер-менеджере есть очень простое управление.
У меня данный сервер реализован на базе сессий. Здесь все очень просто, я могу посмотреть настройку всех моих ролей: как они реализованы, на базе чего они реализованы, какой сервер отвечает за каждую роль и т.д. Я могу добавить с помощью 1-2 кликов новый сервер, если мне это необходимо. У меня есть коллекции на базе сессий. У меня открыто, опубликовано несколько приложений.
Могу предоставить доступ к коллекции приложений определенным группам пользователей. Здесь есть те параметры по управлению, о которых мы говорили, здесь они легко настраиваются: путь к диску, задержки в отключении сессий, условия отключения сессий и т.д. Публиковать я могу те приложения, которые мне нужны, выбрав их галочками.
Теперь демонстрация(с 24 минуты в записи)
Посмотрим вариант с сессиями. Если я подключись к данной сессии, с помощью разных пользователей, то я могу настраивать этим пользователям их права, то, как они будут видеть сам сервер, настройки самого сервера для них, те приложения, с которыми они будут работать. Я могу настроить безопасность так, как это необходимо мне. Все параметры: приложения по умолчанию, рабочий стол, мы все это сможем сделать. Также мы видим второго пользователя, у которого, например, нет прав даже увидеть меню пуск, если у него, к примеру, есть такое ограничение в правах. Этим я хотел показать, что у администратора есть возможность гибко настроить терминальные сессии под разных пользователей. Сделать это просто и максимально безопасно, чтобы юзер пользовался только тем, что ему нужно для работы.
Посмотрим реализацию RemoteApp. Я ввожу строку для веб-доступа, ее мы можем взять либо по имени, либо по IP адресу. Мы попадаем на портал, выглядит он стандартно для всех. На нем опубликованы те приложения, которые пользователь может запустить на своей локальной рабочей станции. После того, как мы открываем список приложений, установленных на сервере, мы можем выделить те, которые мы хотим опубликовать для пользователя. Таким образом, мы можем публиковать различные группы приложений для разных пользователей, для разных групп пользователей: для разных департаментов, например. И вообще не заморачиваться установкой каких-то локальных приложений. Один раз развернули – и все пользователи получают доступ. Эта практика очень широко применяется особенно в интернациональных компаниях, когда офисы, находящие в разных странах заходят по VPN, получают доступ к главному офису, главному ЦОДу, и работают с нужными программами через терминальные сервера.
Теперь посмотрим на Azure. Заходим на портал azure.microsoft.com. Преимущества использования RemoteApp через Azure. Мы не тратим ресурсы на публикацию, на поддержку работы наших приложений: все реализуется в облаке. Доступ отовсюду, главное чтобы был интернет. При заходе на портал вы видите все службы что есть. Сегодня нам необходима служба RemoteAPР. В левом нижнем углу есть кнопка «создать» и здесь легко и просто создать коллекцию, достаточно ввести имя нашей коллекции и выбрать тип шаблона, который у нас есть. По умолчанию у нас есть 2 типа шаблонов: офис и приложения, которые у нас есть на сервере. Но кроме того, у нас есть возможность загружать сюда свои темплейты, чтобы разворачивать свои собственные приложения — для этого нужно azure подключить к своей сети.
По управлению. У меня развернуто 2 коллекции: офис и windows. Их доступ пользователям можно настроить через соответствующую вкладку, где мне нужно указать просто имя пользователя. Точно так же как и в локальном RDS сервере у нас есть возможность публикации приложений, либо можно убрать ту публикацию, которая есть. Все работает также как и в локальном RDS сервере.
В отношении работы с данным сервисом. Чтобы его использовать нужно установить агент. Он нам позволит подключаться к сервису Azure RemoteApp и использовать те программы, которые мы уже имеем. На портале, напротив каждой из моих коллекций, моих темплейтов, будет находится ссылочка на портал, где мне будет предложено скачать агент, чтобы использовать Azure RemoteApp в своей локальной инфраструктуре.
Azure RemoteApp – это приложение для локального доступа пользователям к приложениям. Я могу установить это приложение сразу все пользователям, которым нужны приложения.
Тот функционал, который нужен большинству компаний для полноценной работы уже реализован в Azure – мы уже можем пользоваться этим бизнес-инструментом.
У нас реализован терминальный сервер в облаке. Для разворачивания нового филиала стоит попробовать этот инструмент. Так как у нас в этом случае:
— нет необходимости выделять свои вычислительные мощности,
— не нужно выделять администраторов для поддержки и настройки.
Мы всего лишь создаем коллекции приложений, и добавляем в них пользователей, которым будут доступны эти приложения.
По опыту использования заказчиков – они довольны этим решением, я пока никаких негативных отзывов не слышал. Призываю вас использовать эти новые возможности. Или хотя бы попробовать их, если вы используете ваши терминальные сервера.
Увидев работу Windows Server 2012 и 2012R2 – мы увидели насколько все стало проще, интуитивно понятно и доступно. Сейчас нет никаких сложностей в реализации этого решения – это возможно сделать за один день для одной организации.
Думаю что Azure RemoteApp достаточно интересен. В дальнейшем, если будет интерес, мы загрузим свои темплейты и покажем гибридную реализацию, когда мы сможем использовать как одни так и другие ресурсы, показав насколько востребовано это приложение.
Спасибо за внимание, ожидаю вас на следующих наших вебинарах. Также вы можете озвучивать свои пожелания, темы, которые мы не учли и вы хотели бы более подробно на них остановится.
Запись вебинара.
Приглашаем 29 мая на следующий бесплатный вебинар из этой серии, тема: «Office 365. Обзор. Работа пользователей SharepointOnline. Yammer». С 09.30 до 11.00 (по Киеву). Для регистрации просьба отправить заявку на training@muk.com.ua.
Дистрибуция решений Microsoft
Учебные курсы Microsoft
МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание
Applies to: Windows Server 2012 and 2012 R2
In a previous article, we went through the steps of deploying a 2012 / 2012R2 Remote Desktop Services (RDS) farm. Now with the farm built, let’s take a look at the changes and the process of publishing RemoteApp programs and session-based desktops in Server 2012 / 2012 R2.
Let’s open Server Manager and look at our farm. On the left column you will see a new node called Collections. Collections give you the ability to group a set of RD Session Host servers with a common set of applications and publish them to users. These can be RemoteApp programs or Session Host and VDI desktops. So think of collections as something similar to an application silo. For instance, let’s say we had a group of 5 RD session host servers which all have Office 2013 installed and are configured the same way. If we wanted to publish the Office applications across the 5 RD session host servers, we would first create a collection that included all 5 servers and publish the Office apps accordingly. This is the same if you wanted to provide users with a session host desktop. You would simply create a new collection, add the servers which will be providing the session desktop and publish them to the proper user group(s). One thing to note is you cannot publish a desktop to an existing collection which has already been configured for RemoteApps. The published desktop will require its own collection.
In the following steps, we will go through the process of creating a new collection and publishing some RemoteApp programs.
Highlight “Collections”, then on the right hand side, click on the “tasks” drop down and select the option “Create Session collection”.
On the Before you Begin screen, click next.
On the next screen, we will name the new collection. Here we named it DemoLab Office Apps. Click next.
On the Specify RD Session Host servers screen, we can add RD session host servers which will be part of our collection. For this example, we will be adding RDSH01. Hit next.
We will now need to add the user group(s) which will have access to the collection. To make things easy, it defaults to Domain users. As a good practice, a specific security group should be created and assigned for each of the collections. For this example, you can leave domain users. Since I’ve already created a specific security group for this collection, we will go ahead and add the group. The group is called demolabRemoteApp Office Apps. Click next.
On the User Profile Disks screen, we can enable and configure Profile Disks for the collection. For this example we will disable Profile Disks. Uncheck the Enable user Profile Disks checkbox and hit next.
Stay tuned for an upcoming article on Profile Disks.
On the confirmation screen, confirm your settings and click create.
Once completed, click close.
Back in Server Manager, we now see our collection. Go ahead and highlight the new collection and let’s take a look at our options. In the Properties section we can view and edit the properties of the collections. Since we just created this collection, it defaults to Remote Desktop for the resource type. This means it is servicing a desktop for users should they log into the RD Web Access site. So if you were publishing a session-host desktop, your job is done.
In the RemoteApp Programs section, we can publish RemoteApp programs for users. Once we start publishing RemoteApps, the servers in the collection will no longer serve a desktop connection to users.
In the Host Servers section, we can see the list of session host servers which are part of the collection. This is where we can also add new RD Session Host servers as well as remove them. A session host server can only be a member of single collection.
In the Connections section, we can see a list of users connected to the servers in the collection. Here we can complete common tasks such as resetting or logging off user sessions.
Now that we are familiar with Collections, lets publish some RempoteApp programs. In the RemoteApp Programs section, click the Tasks dropdown and select Publish RemoteApp Programs or just click the text in blue that says “Publish RemoteApp Programs”
A wizard will appear and begin examining the registered applications on the session host servers in the collection. Once completed, it will list the registered applications. Here we can simply select the applications we wish to publish by checking the box next to the application. I will select a few Office and non-Office applications and hit next. In the event your application does not appear in the list you can hit the ADD button to browse for the application manually.
On the Confirmation screen check your settings and hit publish.
Once it is completed, click on close.
We now have RemoteApps available for users and can log into our RD Web Access page to see the published applications.
Let’s go ahead and take a look at the properties of the individual RemoteApps programs. Back in Server Manager within our collection, we now see the list of apps we published.
Right-click on Excel 2013 and select the option “Edit Properties”.
Here we can edit properties for an individual RemoteApp program. On the General section, we can edit a few things for our application such as changing the name of the app, modifying the icon, removing it from RD Web Access or we can organize it in a folder for users when they log into the RD Web Access site. For this example, I’ve set a RemoteApp program folder called DemoLab MISC Apps.
On the parameters screen we can modify any command line parameters should the application require it.
By default, any RemoteApp program in a collection will be available to the security group which was assigned to the collection. On the User Assignment screen, we can change that. Here, we can specify a single user or a different user group other than the group assigned to the collection who will have access to the individual application. In order for this to work, the user must also be a member of the security group which is assigned to the collection.
For the File Type Association section, we can assign certain file types which can be associated to the RemoteApp program. When this option is used, should a user launch a file with one of the associated file types on their client device, it will open the file with the designated RemoteApp program.
Now that we have modified the RemoteApp program folder for Excel 2013, when the user logs back into the RD Web Access site, it will look like the following:
As you can see, Microsoft has really made vast improvements to the publishing of RemoteApps and session based desktops. Not only are we able manage and configure everything from a single console, we now have the ability to organize the published resources appropriately using Collections.
© 2014 Eddie Kwasnik “the Wolf” All Rights Reserved
This entry was posted on February 10, 2014, 4:14 pm and is filed under MICROSOFT. You can follow any responses to this entry through RSS 2.0.
You can leave a response, or trackback from your own site.