Настройка кэша «только для чтения» в клиенте App-V Client (RDS). Windows server 2018 rds настройка

Настройка кэша «только для чтения» в клиенте App-V Client (RDS)

Эта документация перемещена в архив и не поддерживается.

Обновлено: Ноябрь 2012 г.

Назначение: Application Virtualization 4.6 SP1

Важно!

Для выполнения этой процедуры требуется App-V версии 4.6 с пакетом обновления 1 (SP1).

Для развертывания клиента App-V можно использовать общий кэш, заполненный всеми приложениями, необходимыми для всех пользователей. Затем необходимо настроить клиенты App-V Remote Desktop Services (RDS) для использования одного файла кэша. Для предоставления пользователям доступа к определенным приложениям используется процесс публикации App-V. Поскольку в кэш предварительно загружены все приложения, при запуске приложения пользователем оно не будет передаваться в потоковом режиме. Однако пакеты, используемые для предварительного заполнения кэша, должны быть размещены на сервере App-V, который поддерживает потоковую передачу по протоколу RTSP и предоставляет разрешения на доступ клиентам App-V Client. Если для публикации приложений используется сервер App-V Management Server, его можно использовать для выполнения функции потоковой передачи.

Примечание

Данные, которые приводятся в этих процедурах, предназначены только для примера. Существуют различные методы выполнения всего процесса.

Развертывание клиента App-V Client в сценарии RDS

Процесс развертывания включает четыре основные задачи:

создание и заполнение файла главного общего кэша;
копирование файла общего кэша в хранилище сервера;
Настройка клиентского программного обеспечения App-V
управление циклом развертывания обновлений для файла общего кэша после первоначального развертывания.

Эти задачи требуют тщательного планирования. Рекомендуется подготовить и задокументировать систематизированный воспроизводимый процесс, который будет применяться в организации. Это особенно важно для подготовки и развертывания файла главного общего кэша, а также для управления обновлениями приложений, каждое из которых требует обновления главного общего кэша. Используйте следующие процедуры для выполнения основных задач.

Примечание

Хотя существует несколько различных методов публикации приложений, в описанных ниже процедурах для публикации используется сервер App-V Management Server.

Настройка кэша, доступного только для чтения, для первоначального развертывания

Установите и настройте App-V Management Server для поддержки проверки подлинности пользователей и публикации.
Заполните папку Content на этом сервере Management Server всеми пакетами приложений, необходимыми для всех пользователей.

Настройте промежуточный компьютер с установленным клиентом App-V Client. Войдите на промежуточный компьютер, используя учетную запись, которая имеет доступ ко всем приложениям, чтобы на компьютере был опубликован полный набор приложений, а затем выполните потоковую передачу приложений в кэш, чтобы они были полностью загружены.

Важно!

На промежуточном компьютере должен использоваться тот же тип операционной системы и та же системная архитектура, что и на ВМ, на которых будет запускаться клиент App-V Client.

Перезапустите промежуточный сервер в безопасном режиме, чтобы гарантировать, что драйверы не запущены (это привело бы к блокировке файла кэша).

Примечание

Можно также остановить и отключить службу Application Virtualization, а затем перезагрузить компьютер. После того как файл будет скопирован, не забудьте снова включить и запустить службу.

Скопируйте файл кэша Sftfs.fsd в хранилище SAN, где он будет доступен для всех серверов RDS (например, в общую папку). Установите следующие разрешения на доступ к папке: «Только чтение» для группы «Все» и «Полный доступ» для администраторов, которые будут управлять обновлениями файла кэша. Расположение файла кэша можно получить из раздела реестра AppFS\FileName.

Важно!

FSD-файл необходимо разместить в таком месте, которое по времени отклика и надежности соответствует производительности локального хранилища, например в хранилище SAN.

Установите клиент App-V RDS Client на всех серверах RDS и настройте его для работы с кэшем «только для чтения», добавив указанные ниже значения в раздел реестра AppFS на компьютерах клиента. Ключ AppFS для 32-разрядных версий расположен по адресу HKEY_LOCAL_MACHINE\SOFTWARE\]Microsoft\SoftGrid\4.5\Client\AppFS, а для 64-разрядных версий по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS.

Раздел Тип Значение Назначение

FileName	Строка	Путь к файлу FSD	Путь к файлу общего кэша, например \\имя_сервера_RDS\общая_папка\SFTFS.FSD (обязательный параметр).
ReadOnlyFSD	DWORD	1	Настройка клиента для работы в режиме «только для чтения». Клиент не будет предпринимать попытку потоковой передачи обновлений в кэш пакетов. (Обязательный.)
ErrorLogLocation	Строка	Путь к файлу журнала ошибок (.etl)	Запись, используемая для указания пути к журналу ошибок. (Обязательный. Используйте локальный путь, например C:\Logs\Sftfs.etl.)

Настройте все серверы RDS в ферме для использования сервера публикации и обновления публикации при входе пользователей. Когда пользователи входят в систему сервера RDS, выполняется цикл обновления публикации, в рамках которого публикуются все приложения, на работу с которыми у учетной записи пользователя есть права. Эти приложения запускаются из общего кэша.

Настройка клиента RDS для обновления пакетов

Выполните обновление и тестирование пакета приложения.
Обновите пакет на сервере App-V. Затем опубликуйте новую версию приложений для клиента на промежуточном компьютере и выполните их потоковую передачу. Приложения должны быть полностью загружены в кэш.

Перезапустите промежуточный компьютер в безопасном режиме, чтобы гарантировать, что драйверы не запущены.

Примечание

Можно также остановить и отключить службу Application Virtualization в оснастке Services.msc, а затем перезагрузить компьютер. После того как файл будет скопирован, не забудьте снова включить и запустить службу.

Скопируйте файл кэша Sftfs.fsd в хранилище SAN, где он будет доступен для всех серверов RDS (например, в общую папку). Можно использовать другое имя файла, например SFTFS_V2.FSD, чтобы выделить новую версию.
Чтобы настроить клиент App-V RDS Client на всех серверах RDS фермы для использования обновленного файла общего кэша, измените значение FILENAME раздела реестра AppFS в соответствии с расположением обновленного файла (например, \\Имя_сервера_RDS\Общая_папка\SFTFS_V2.FSD). Это действие обеспечит получение каждым сервером RDS обновленной копии кэша при перезапуске драйверов клиента App-V.

Важно!
Для использования обновленного файла общего кэша необходимо перезапустить серверы RDS.

Использование символических ссылок при обновлении кэша

Вместо изменения значения FILENAME раздела AppFS при каждом развертывании нового файла кэша, содержащего новые или обновленные пакеты, можно воспользоваться символической ссылкой в следующих операционных системах: Windows Vista, Windows 7 и Windows Server 2008. Дополнительные сведения о символических ссылках см. на странице Symbolic Links (Символические ссылки) (http://go.microsoft.com/fwlink/?LinkId=157626). В отличие от этих операционных систем, Windows XP не поддерживает использование символических ссылок. Вместо них следует использовать точки соединения. Дополнительные сведения о точках соединения см. в статье 205524 базы знаний Майкрософт (http://go.microsoft.com/fwlink/?LinkId=182553), а также в описании программы Junction 1.05 (http://go.microsoft.com/fwlink/?LinkId=182554).

Настройка символической ссылки на кэш

Во время первоначального развертывания откройте окно командной строки в ОС сервера RDS, используя учетную запись локального администратора.
Создайте символическую ссылку с помощью команды MKLINK, а затем свяжите ее с файлом Sftfs.fsd.

mklink symlinkname \\сервер_узла_rds\общая_папка\sftfs.fsd

На главном образе ВМ VDI откройте окно командной строки с параметром Запуск от имени администратора и предоставьте разрешения удаленной ссылки, чтобы обеспечить доступ ВМ к символической ссылке в ОС сервера VDI. По умолчанию разрешения удаленной ссылки отключены.

fsutil behavior set SymlinkEvaluation R2R:1

Примечание

На сервере хранилища должны быть включены соответствующие разрешения ссылки. В зависимости от расположения ссылки и файла Sftfs.fsd могут использоваться разрешения L2L:1, L2R:1, R2L:1 или R2R:1.

При настройке клиента App-V RDS Client установите значение FILENAME раздела AppFS в соответствии с UNC-путем к FSD-файлу, который использует символическую ссылку. Например, задайте для имени файла значение \\Сервер_узла_VDI\Symlinkname. Когда клиент App-V впервые обращается к кэшу, символическая ссылка передает ему дескриптор файла кэша. Клиент продолжает использовать этот дескриптор до завершения текущего сеанса. Значение символической ссылки можно безопасно обновить, даже если существующими клиентами открыт старый общий кэш.
Когда потребуется обновление или добавление пакета в кэш, выполните шаги 1–4 процедуры обновления. Затем удалите символическую ссылку и заново создайте ее для новой версии файла общего кэша. Это действие обеспечит получение каждым сервером RDS обновленной копии кэша при перезапуске драйверов клиента App-V. При перезапуске сервера RDS клиент App-V получает дескриптор обновленной копии кэша, поскольку клиент использует путь, содержащий обновленную символическую ссылку. После этого пользователи получат доступ к новым и обновленным приложениям.

См. также

-----

Чтобы получить дополнительные сведения о пакете MDOP, воспользуйтесь

библиотекой TechNet Library

: выполните поиск статей по устранению неполадок на

вики-сайте TechNet

или подпишитесь на наши страницы в

Facebook

или

Twitter

. Отправляйте свои предложения и комментарии относительно документации MDOP по адресу

[email protected].

technet.microsoft.com

Windows Server 2012R2 RDS и Azure RemoteApp / Блог компании МУК / Хабр

На основе технического вебинара сделан обзор решений 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 (по Киеву). Для регистрации просьба отправить заявку на [email protected].

Дистрибуция решений MicrosoftУчебные курсы Microsoft

МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание

habr.com

System Engineering - Настройка RDS 2012 для пользователей

Для настройки терминального сервера Windows Server 2012 перед публикацией его для приема сессий пользователей необходимо настроить рабочий стол сервера, чтобы пользователи не смогли:- изменить конфигурацию сервера,- запустить ненужные программы,- загрузить сервер непрофильными задачами,- замусорить диск сервера,- и тому подобное.

Региональные настройки

Для начала необходимо настроить часовой пояс сервера, например установить Московский часовой пояс (UTC+3:00)

Далее необходимо настроить языки. Обычно я выбираю русский язык как дополнительный, а английский (США) по умолчанию.

Так же я рекомендую выставить дополнительные языковые параметры- "разный метод ввода для каждого приложения" - то есть поставить галочку "Let me set a different input method for each app window",- "показывать языковую панель" - то есть поставить галочку "Use the desktop language bar when it's available".

Сочетание клавиш для переключения языка нужно выставить такое же, какое обычно установлено на пользовательских компьютерах. В моем примере это CTRL+SHIFT.

Региональные настройки рекомендуется выставить российские.

Расположение - Россия.

Язык для не-юникодовых программ - Русский.

Когда все региональные параметры установлены, а сервер перезагружен, то необходимо скопировать выставленные параметры для пользователя по умолчанию, чтобы все новые пользователи терминального сервера получали только что сконфигурированные параметры локализации.

Групповые политики

Следующим разделом настройки терминального сервера идет настройка групповых политик, которые ограничивают доступ к настройкам сервера со стороны пользователей.

Групповые политики ветки Computer configuration \ Policies \ Administrative templates накладываются на систему, то есть устанавливают настройки для всех пользователей.

Путь	Параметр	Состояние	Значение
Настройка учетной записи пользователей
Control Panel\User Accounts	Apply the default user logon picture to all users	Enabled
Настройка применения политики к пользователям
System\Group Policy	User Group Policy loopback processing mode	Enabled	Replace
Настройка службы удаленного рабочего стола
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections	Restrict Remote Desktop Services users to a single Remote Desktop Services session	Enabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Allow audio and video playback redirection	Disabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Allow audio recording redirection	Disabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Do not allow clipboard redirection	Disabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Do not allow COM port redirection	Disabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Do not allow drive redirection	Enabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Do not allow LPT port redirection	Enabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection	Do not allow supported Plug and Play device redirection	Enabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Printer Redirection	Redirect only the default client printer	Enabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Temporary folders	Do not delete temp folder upon exit	Disabled
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Temporary folders	Do not use temporary folders per session	Disabled

Групповые политики ветки User configuration \ Policies \ Administrative templates накладываются на пользователя, входящего на компьютер, на который наложена данная политика, при условии, что параметр User Group Policy loopback processing mode включен.

Путь	Параметр	Состояние	Значение
Настройка панели управления
Control Panel	Prohibit access to the Control Panel	Disabled
Control Panel	Show only specified Control Panel items	Enabled	Internet OptionsLanguageRegionDevices and Printers
Control Panel\Personalization	Prevent changing desktop background	Enabled
Control Panel\Personalization	Prevent changing screen saver	Enabled
Control Panel\Printers	Prevent addition of printers	Enabled
Control Panel\Printers	Prevent deletion of printers	Enabled
Настройка рабочего стола
Desktop	Do not add shares of recently opened documents to Network Locations	Enabled
Desktop	Hide Network Locations icon on desktop	Enabled
Desktop	Prevent adding, dragging, dropping and closing the Taskbar's toolbars	Enabled
Desktop	Prohibit adjusting desktop toolbars	Enabled
Desktop	Prohibit User from manually redirecting Profile Folders	Enabled
Desktop	Remove Properties from the Computer icon context menu	Enabled
Desktop	Remove Recycle Bin icon from desktop	Enabled
Desktop	Remove the Desktop Cleanup Wizard	Enabled
Настрока меню Пуск и Панели задач
Start Menu and Taskbar	Add Logoff to the Start Menu	Enabled
Start Menu and Taskbar	Prevent changes to Taskbar and Start Menu Settings	Enabled
Start Menu and Taskbar	Prevent grouping of taskbar items	Enabled
Start Menu and Taskbar	Remove access to the context menus for the taskbar	Enabled
Start Menu and Taskbar	Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands	Enabled
Start Menu and Taskbar	Remove Clock from the system notification area	Disabled
Start Menu and Taskbar	Remove drag-and-drop and context menus on the Start Menu	Enabled
Start Menu and Taskbar	Remove Favorites menu from Start Menu	Enabled
Start Menu and Taskbar	Remove Games link from Start Menu	Enabled
Start Menu and Taskbar	Remove Help menu from Start Menu	Enabled
Start Menu and Taskbar	Remove links and access to Windows Update	Enabled
Start Menu and Taskbar	Remove Network Connections from Start Menu	Enabled
Start Menu and Taskbar	Remove Recent Items menu from Start Menu	Enabled
Start Menu and Taskbar	Remove Run menu from Start Menu	Enabled
Start Menu and Taskbar	Remove Search link from Start Menu	Enabled
Start Menu and Taskbar	Turn off personalized menus	Enabled
Настройка Диспетчера задач
System\Ctrl+Alt+Del Options	Remove Task Manager	Enabled
Настройка браузера Internet Explorer
Windows Components\Internet Explorer\Internet Control Panel	Disable the Advanced page	Enabled
Windows Components\Internet Explorer\Internet Control Panel	Disable the Content page	Enabled
Windows Components\Internet Explorer\Internet Control Panel	Disable the Privacy page	Enabled
Windows Components\Internet Explorer\Internet Control Panel	Disable the Programs page	Enabled
Настройка использования остасток
Windows Components\Microsoft Management Console\Restricted/Permitted snap-ins	Computer Management	Enabled
Настройка создания сетевых папок
Windows Components\Network Sharing	Prevent users from sharing files within their profile.	Enabled
Настройка службы удаленного рабочего стола
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits	Set time limit for active but idle Remote Desktop Services sessions	Enabled	2 hours
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits	Set time limit for active Remote Desktop Services sessions	Enabled	Never
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits	Set time limit for disconnected sessions	Enabled	15 minutes
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits	Set time limit for logoff of RemoteApp sessions	Enabled	5 munutes
Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits	Terminate session when time limits are reached	Enabled
Настройка Проводника Windows
Windows Components\Windows Explorer	Do not move deleted files to the Recycle Bin	Enabled
Windows Components\Windows Explorer	Hide these specified drives in My Computer	Enabled	Restrict all except G, H, I, J, K
Windows Components\Windows Explorer	Hides the Manage item on the Windows Explorer context menu	Enabled
Windows Components\Windows Explorer	No Computers Near Me in Network Locations	Enabled
Windows Components\Windows Explorer	No Entire Network in Network Locations	Enabled
Windows Components\Windows Explorer	Remove "Map Network Drive" and "Disconnect Network Drive"	Enabled
Windows Components\Windows Explorer	Remove Shared Documents from My Computer	Enabled
Windows Components\Windows Explorer	Remove Windows Explorer's default context menu	Enabled
Windows Components\Windows Explorer	Turn off Windows+X hotkeys	Enabled

Для того, чтобы ограничения для пользователей не накладывались на администраторов сервера, в настройках безопасности политики необходимо выставить запрет на применение политики для группы администраторов.

Скрипты

Следующим пунктом настройки терминального сервера является создание логон-скриптов для пользователей.

Эти скрипты будут настраивать меню Пуск, Панель задач и вид папок Проводника.

По умолчанию профиль пользователя содержит набор папок Контакты, Загрузки, Видео и т.п. Так как на сервере пользователь не должен пользоваться этими папками, то предлагается скрыть их, установив на них атрибуты "скрытый" и "системный". Для того, чтобы скрыть папки я использую следующий скрипт, который помещен в групповую политику в раздел User configuration \ Policies \ Windows Settings \ Scripts.

Set oShell = CreateObject("WScript.Shell") Set oFSO = CreateObject("Scripting.FileSystemObject") vRootFolder = "C:\Users" vUserName = oShell.ExpandEnvironmentStrings("%USERNAME%") arrSubFolders = Array("AppData", "Contacts", "Downloads", "Favorites", "Links","Music", "Pictures", _ "Saved Games", "Searches", "Videos" ) For i = LBound(arrSubFolders) to UBound(arrSubFolders) vPath = vRootFolder + "\" + vUserName + "\" + arrSubFolders(i) If oFSO.FolderExists(vPath) Then Set objFolder = oFSO.GetFolder(vPath) If ((objFolder.Attributes AND 2) = 0) Then ' Folder is Not Hidden now objFolder.Attributes = objFolder.Attributes + 2 End If If ((objFolder.Attributes AND 4) = 0) Then ' Folder is Not System now objFolder.Attributes = objFolder.Attributes + 4 End If End If Next

В этом скрипте в параметре arrSubFolders нужно указать имена папок, которые нужно скрыть. Так как выставляются сразу 2 параметра: "скрытый" и "системный", то проводник не будет показывать папки, так как по умолчанию в настройках проводника установлен параметр "Скрывать защищенные системные файлы".

В моем примере для пользователя остаются доступными только Рабочий стол и Мои Документы, а остальные папки скрыты от использования, но доступ к ним можно получить, написав полный путь к нужной папке.

Для того, чтобы настроить Панель задач для всех пользователей, нужно сделать шаблонную настройку Панели задач на одном пользователе и скопировать ее остальным. То есть конфигурация Панели задач проводится в несколько этапов:1. У текущего пользователя создается шаблонная Панель задач, на которой создаются и закрепляются необходимые ярлыки.2. Экспортируется содержание папки %APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar текущего пользователя.3. Экспортируется ветка реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband текущего пользователя.4. Логон-скриптом в профиль пользователя копируются ярлыки Панели задач, экспортированные ранее.5. В групповую политику добавляется экспортированные ранее ключи реестра.

Этот скрипт удаляет ярлыки Панели задач из профиля пользователя и копирует в него шаблонные ярлыки, которые сохранены в подпапке Taskband из папки скрипта.

On error resume next

Set oShell = CreateObject("WScript.Shell")' Source foldermWorkDir = Left(WScript.ScriptFullName,Len(WScript.ScriptFullName)-Len(WScript.ScriptName))mTaskbandSource = mWorkDir & "Taskband"' Destination foldermUsersFolder = "C:\Users"mUserName = oShell.ExpandEnvironmentStrings("%USERNAME%")mTaskbarDestination = mUsersFolder & "\" & mUserName & _"\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar"' Deleting old filesoShell.Run "cmd.exe /C del /S /F /Q """ & mTaskbarDestination & "\*""", 0, True' Copying new filesoShell.Run "cmd.exe /C xcopy.exe """ & mTaskbandSource & """ """ _& mTaskbarDestination & """ /R /Y /I", 0, True

Эта политика конфигруриует Панель задач, внося в профиль пользователя шаблонные значения реестра. Значения параметров ключей реестра нужно брать из экспортированного ранее файла.

Для того, чтобы настроить меню Пуск для всех пользователей, нужно сделать шаблонную настройку меню Пуск у одного пользователя и скопировать ее остальным. То есть конфигурация меню Пуск проводится в несколько этапов:1. У текущего пользователя создается шаблонное меню Пуск.2. Экспортируется файл appsFolder.itemdata-ms из папки %USERPROFILE%\AppData\Local\Microsoft\Windows текущего пользователя.3. Логон-скриптом в профиль пользователя копируются файл appsFolder.itemdata-ms, экспортированный ранее.

Примечание. Если у шаблонного файла appsFolder.itemdata-ms выставить атрибут "только чтение", то пользователь не сможет изменить меню Пуск. Хотя эта функция неактульна ввиду того, что при каждом входе в систему файл appsFolder.itemdata-ms в профиле пользователя перезаписывается шаблонным, и меню Пуск опять становится стандартным.

Этот скрипт перезаписывает файл appsFolder.itemdata-ms в профиле пользователя, используя шаблонный файл, который сохранен в подпапке StartScreen из папки скрипта. В этом скрипте используется утилита xcopy.exe, чтобы форсировать перезапись системных файлов и файлов только для чтения.

On error resume next

Set oShell = CreateObject("WScript.Shell")' Source foldermWorkDir = Left(WScript.ScriptFullName,Len(WScript.ScriptFullName)-Len(WScript.ScriptName))mStartScreenSource = mWorkDir & "StartScreen"' Destination foldermUsersFolder = "C:\Users"mUserName = oShell.ExpandEnvironmentStrings("%USERNAME%")mStartScreenDestination = mUsersFolder & "\" & mUserName & _"\AppData\Local\Microsoft\Windows"' Copying new filesoShell.Run "cmd.exe /C xcopy.exe """ & mStartScreenSource & """ """ _& mStartScreenDestination & """ /R /Y /I", 0, True

Ключи реестра

Для того, чтобы убрать из проводника ненужные секции Избранное, Библиотеки, Сеть, нужно внести следующие изменения в реестр сервера (для того, чтобы изменить нижеприведенные ключи реестра, нужно дать администратору права на изменение реестра).

Избранное:

[HKEY_CLASSES_ROOT\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolder] "Attributes"=DWORD:A9400100

Библиотеки:

[HKEY_CLASSES_ROOT\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}\ShellFolder] "Attributes"=DWORD:B090010D

Сеть:

[HKEY_CLASSES_ROOT\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolder] "Attributes"=DWORD:B0940064

Другой вариант скрытия ненужных секций проводника - это груповые политики для пользователя (для этих ключей не нужно изменять права доступа к секциям реестра):

Сеть:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\NonEnum] "{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}"=DWORD:00000001

Библиотеки:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\NonEnum] "{031E4825-7B94-4dc3-B131-E946B44C8DD5}"=DWORD:00000001

Избранное:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\NonEnum] "{D34A6CA6-62C2-4C34-8A7C-14709C1AD938}"=DWORD:00000001

Помимо ненужных секций Проводника, рекомендуется так же внести изменения в следующие параметры:

Отключить визуальные эффекты для улучшения быстродействия сервера и быстрой передачи упрощенной графики по сети:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects] "VisualFXSetting"=DWORD:00000002

Показывать расширения файлов:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] "HideFileExt"=DWORD:00000000

Отображать элементы Панели управления в виде маленьких значков, а не группами:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel] "AllItemsIconView"=DWORD:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel] "StartupPage"=DWORD:00000001

Отключить группировку программ на Панели задач:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] "TaskbarGlomLevel"=DWORD:00000001

Сетевые диски

Для работы с файлами рекомендуется использовать сетевые диски с файлового сервера вместо профиля на терминальном сервере, поэтому рекомендуется подключить сетевые диски через групповую политику.

Примечание. При подключении сетевых дисков через групповую политику нужно учесть ньюанс, что диск надо подключать с правами пользователя, то есть на вкладке свойств сетевого диска нужно установить параметр "Run in logged-on use's security contex"

Логотип компании

Последней настрокой рабочего пространства терминального сервера будет установка логотипа компании в качестве значка пользователя.

Для того, чтобы всем пользователям терминального сервера установить логотип компании в качестве значка пользователя, нужно создать 4 файла с логотипом компании со следующими именами и свойствами.

Имя файла	Размер файла
user.bmp	448 x 448
user.png	448 x 448
user-200.png	200 x 200
user-40.png	40 x 40

Готовые файлы логотипов нужно скопировать на терминальный сервер в папку %ProgramData%\Microsoft\User Account Pictures.

Чтобы установленные картинки применились для учетных записей пользователей, нужно в групповой политике компьютера задать следующий параметр Control Panel\User Accounts\Apply the default user logon picture to all users (этот параметр был сконфигурирован выше по тексту в таблице настроек политик компьютера).

Тест

После того, как- групповая политика создана,- в ней применены все вышеописанные настройки,- эта политика наложена на контейнер, где расположен терминальный сервер,- сервер получил групповую политику и был перезагружен,можно считать, что задача по настройке рабочего стола сервера Windows Server 2012 для конечных пользователей завершена.

При входе в систему обычного пользователя экран приветствия будет выглядеть следующим образом - будет отображаться логотип компании и информаци о процессе входа в систему.

Меню Пуск для всех пользователей будет стандартно и выглядеть как у шаблонного пользователя. Если пользователь изменит меню Пуск, то при следующем входе на сервер ему скопируется шаблонное меню, и настройки опять будут стандартными.

Панель задач и Проводник так же будут выглядеть одинаково для всех пользователей. А вот Рабочий стол будет индивидуальным для каждого пользователя за исключением файлов, которые расположены в папке %PUBLIC%\Desktop. Файлы и ярлыки из этой папки будут опубликованы для всех пользователей без возможности изменения.

Настройка и тест сервера закончены.

www.sysengineering.ru

Настройка терминальной фермы RDS с RD Connection Broker

Remote Desktop Connection Broker (RD Connection Broker), ранее известный под именем Terminal Services Session Broker (TS Session Broker), — это роль сервера Windows 2008 R2, предоставляющая следующий функционал:

Позволяет пользователям переподключаться к своим текущим сессиям в ферме серверов RD Session Host (терминальные сервера Windows). Тем самым предотвращается создание новых пользовательских подключений на других серверах фермы при наличии подключения в состоянии «disconnected».
Позволяет равномерно распределить нагрузку между серверами терминальной фермы RD.

RD Connection Broker отслеживает все сессии пользователей в ферме терминальных серверов Windows Server 2008 R2. База данных RD Connection Broker хранит сессионную информацию, включая имена серверов RD Session Host, на которых находятся сессии пользователя, идентификатор сессии (session ID) и имя пользователя, ассоциированное с сессией. Служба RD Connection Broker использует эту информацию для перенаправления пользователя, уже имеющего активную терминальную сессию на тот сервер, на котором она запущена.

В том случае, если пользователь отключился (disconnect) от своей сессии (из-за сетевого сбоя или осознанно), все приложения, которые он запустил на сервере продолжают работать. И когда пользователь пытается вновь подключиться к ферме терминалов, Connection Broker определяет сервер, на котором уже имеется сессия пользователя и перенаправляет подключение пользователя именно туда.

Балансировка нагрузки RD Connection Broker Load Balancing, позволяет при подключении пользователя (предполагается, что у него не осталось подключений в состоянии disconnect) к ферме, перенаправить его на наименее загруженный сервер фермы (с наименьшим количеством пользовательских сессий). Чтобы более гибко управлять балансировкой нагрузки в ферме терминальных серверов, администратор может в зависимости от вычислительных мощностей серверов фермы назначить каждому из них относительный вес.

Компоненты RD Connection Broker

Для построения фермы терминальных серверов с балансировкой нагрузки нужны два компонента:

Сервер RD Connection Broker. Это сервер с запущенной службой Remote Desktop Connection Broker, который отслеживает сессии пользователей и осуществляет балансировку нагрузки между членами фермы RD. Существует имя сервера RD Connection Broker, с помощью которого можно отнести конкретный терминальный сервер к той или иной ферме.

Сервера RD Session Host, настроенные на использование Connection Broker. Это рядовые члены терминальной фермы. Для того, чтобы являться членом фермы под управление RD Connection Broker, терминальный сервер должен соответствовать следующим критериям:

На сервере должна быть установлена роль RD Session Host.
Сервер должен быть членом домена Active Directory.
Сервер должен входить в локальную группу «Session Broker Computers» на сервере с ролью RD Connection Broker.

Последовательность настройки терминальной фермы RD Connection Broker с балансировкой нагрузки:

Установите роль RD Connection Broker на сервере (это может быть выделенный сервер, или один из членов будущей фермы).
Добавьте все терминальные сервера в локальную группу безопасности «Session Broker Computers» на сервере с ролью RD Connection Broker.
Настройте всех членов фермы на использование сервера RD Connection Broker
Настройте записи DNS для реализация механизма «DNS round robin»

Шаг 1 : Установка роли Connection Broker

Если роль Remote Desktop Services уже установлена:

Разверните роль Remote Desktop Services.
Нажмите кнопку Add Role Services.
На странице служб роли выберите Remote Desktop Connection Broker и нажмите Next

В моем стенде 2 сервера, настроенных следующим образом:

RDS01

RDS02

Шаг 2 : Добавляем сервера RD Session Host в локальную группу Session Broker Computers.

Для этого на сервер с установленной ролью RD Connection Broker:

Нажмите Start -> Administrative Tools -> Computer Management.
В левой панели разверните узел Local Users and Groups, и выберите Groups.
Найдите локальную группу Session Broker Computers , и выберите пункт Properties.
На вкладке General, нажмите Add.
В окне выбора нажмите кнопку Object Types.
Отметьте пункт Computers, и нажмите OK.
Последовательно укажите и добавьте имена всех серверов, которые будут участвовать в терминальной ферме
Нажмите OK.

На RDS01

Шаг 3 : Включаем сервера RD Session Host в ферму RD Connection Broker, настраиваем балансировку нагрузки

На каждом из терминальных серверов RD Session Host выполните следующее:

На сервер RD Session Host откройте консоль Remote Desktop Session Host Configuration (Start ->Administrative Tools->Remote Desktop Services -> Remote Desktop Session Host Configuration).
В разделе Edit settings, щелкните по полю Member of farm in RD Connection Broker.
На вкладке RD Connection Broker нажмите кнопку Change Settings.
В окне RD Connection Broker Settings выберите Farm member.
Введите имя сервера с ролью RD Connection Broker.
В окне Farm name, укажите имя создаваемой фермы.
Чтобы активировать балансировку нагрузки в ферме RD Connection Broker отметьте опцию Participate in Connection Broker Load-Balancing.
В случае необходимости можно настроить относительный вес каждого из серверов в ферме (Server weight). Значение по умолчанию — 100. В том случае, если вы зададите вес одного сервера 100, а другого 50, это будет означать, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
По умолчанию используется перенаправление по IP адресу (IP address redirection), также можно использовать перенаправление по токену (Use token redirection).

Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02

Task 4 : Настройка DNS round robin

Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.

Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.

Откройте оснастку DNS (Start->Administrative Tools-> DNS).
Разверните сервер, и в зонах прямого просмотра (Forward Lookup Zones), разверните ветку с именем вашего домена.
Щелкните по зоне и выберите New Host (A or AAAA).
В поле Name укажите имя фермы (именно фермы, а не конкретного сервера в ней), а в поле IP address укажите ip адрес первого сервера в ферме.

Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)

Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.winitpro.ru)

Теперь в дереве RD Connection Broker появится новая терминальная ферма!

winitpro.ru

Что нового в Windows Server 2016 RDS. Часть 1

Автор статьи — Роман Левченко (www.rlevchenko.com), MVP — Cloud and Datacenter Management

Выход Windows Server 2016 всё ближе и ближе, и мы продолжаем рассматривать самые главные нововведения очередного релиза. Речь сегодня пойдет об одной из наиболее востребованных ролей – службы удаленных рабочих столов или RDS (Remote Desktop Services).Прежде чем погружаться в мир нового, рекомендую ознакомиться со списком тех возможностей, которые предоставляют Windows Server 2012/2012 R2. Если все в теме, то вернемся к главному и подробно рассмотрим непосредственно WS 2016 RDS.

Службы Multipoint

MultiPoint-сервер (MPS) является технологией и решением на базе Windows Server и служб RDS для предоставления базовой функциональности удаленных рабочих столов. Позиционируется для использования в учебных классах или учреждениях, где нет больших требований к нагрузке и масштабируемости. Особенность заключается в том, что пользовательские станции могут состоять только из монитора, клавиатуры и мыши («нулевые» клиенты) и подключаться непосредственно к серверу MPS через USB-хабы, видео-кабели или LAN (RDP-over-LAN, если клиентом является, к примеру, ноутбук или тонкий клиент). В итоге, конечный потребитель получает low-cost решение для предоставления функциональности рабочих столов с абсолютно минимальными затратами на пользовательские конечные станции.

Первая версия MPS, выпущенная в феврале 2010-го, имела возможность подключать станции только через специализированные USB-хабы и видео-порты.

Привычная нам всем возможность подключения через RDP была добавлена только в следующей версии MPS 2011, релиз которой состоялся в марте 2011. Помимо RDP-over-LAN, MPS 2011 обновился следующим образом:

Поддержка RemoteFX
Поддержка виртуализации
Проецирование рабочего стола от одной станции другой (к примеру, рабочий стол тренера или преподавателя дублируется на пользовательские станции)
Возможность ограничения Интернет-доступа на базе фильтров
Удаленный запуск приложений, блокировка периферии (клавиатуры, мышь) на подключенных станциях

В следующей и, на данный момент, последней версии MPS 2012 были добавлены:

Новая консоль для централизованного управления столами
Защита системного раздела от нежелательных изменений
Клиент MPS Connector для мониторинга и управления станций, включая планшеты

Лицензирование напоминает полноценный RDS. Всё так же требуется лицензировать каждую конечную станцию и иметь серверные лицензии MPS, которые отличаются редакциями:

Наименование редакции Standard Premium

Кол-во подключенных станций	До 10	До 20
Виртуализация	Нет	Да
Количество CPU (Sockets)	1	2
Макс. память	32 ГБ	Неограниченно
Подключение к домену	Нет	Да

Основные типы станций MultiPoint Services

Как уже было сказано выше, MPS поддерживает не только классический RDP, но и даёт возможность подключать «нулевые» клиенты (примером может служить Wyse 1000) следующими способами:

Прямое подключение к видеокарте головной станции
На рисунке к главной станции подключаются напрямую 4 клиентские станции через USB и, к примеру, VGA-порты. Очевидно, что подобный тип подключения подразумевает соответствующие требования к аппаратной конфигурации головной станции и в некоторых сценариях не применим (масштабы, расстояние, мобильность)
Подключение через USB
На рисунке ниже показано взаимодействие первичной станции (станция, которая подключена напрямую к MPS и используется для первичной конфигурации вне зависимости от сценария) и двух «нулевых» клиентов, подключенных через USB-хабы (пример: Wise 1000). В отличии от первого способа, нам не нужно дополнительно рассчитывать конфигурацию видео-подсистемы сервера MPS для формирования требуемого количества видеовыходов. Но из-за ограничения по расстоянию между станциями и MPS (для Dell Wise 1000 ~ 5 метров) рекомендуется использовать в малых комнатах при небольшом количестве конечных пользователей.
Использование USB-Over-Ethernet
Более масштабируемый тип подключения. Вместо USB-to-USB используется проброс USB через LAN, тем самым предоставляется возможность построения системы MPS в больших по размеру помещениях (пример клиента: Wise 1003)

А что же в Windows Server 2016?

Описанная выше функциональность полностью перенесена в Windows Server 2016 (на данный момент Technical Preview 4). MultiPoint Server является теперь новым типом развертывания служб RDS.

Данных по лицензированию подобной схемы развертывания в рамках 2016 пока нет. Подразумеваю, что схема лицензирования MPS 2012 будет частично перенесена и в WS 2016, а редакции MPS будут упразднены.

Процесс развертывания

Опытным инженерам или администраторам, которые уже знакомы с процедурой конфигурации RDS в рамках VDI или Session-Based решений, процесс настройки и использования MPS покажется более простым и быстрым. Это тоже является плюсом, если учитывать целевую аудиторию MPS.

Существует три способа установить MultiPoint Services: через Server Manager (role-based), Powershell и через RDS Installation.

Бегло пройдемся по первым двум и потом перейдем к процессу базовой настройки MPS.

Используя Server Manager и установку ролей, выберите MultiPoint Services, согласитесь с установкой дополнительных компонент и перейдите к следующему шагу.
Можно почитать ещё раз, что такое MPS. Стоит отметить, что RD Licensing нужно будет активировать после конфигурации MPS.
Вместе с основной службой MPS дополнительно разворачиваются службы Print and Document Services, предназначение которых всем, я надеюсь, известно. Ничего интересного, идем далее.
Оставляем всё по умолчанию.
- Print Server – необходим для управления «множеством» принтеров
- Distributed Scan Server – управление и предоставление доступа к сканерам, поддерживающим Distributed Scan Management
- Internet Printing – веб-доступ к printer jobs с возможностью отправки документов на печать через Internet Printing Protocol
- LPD Service — служба Line Printer Daemon предоставляет возможность UNIX-клиентам, используя службу Line Printer Remote, отправлять задачи на печать доступным принтерам.
Полноценный RDS нам не нужен, поэтому оставляем предлагаемые по умолчанию значения.
После подтверждения сервер отправится на перезагрузку и, используя первичную станцию, необходимо будет произвести требуемую конфигурацию при первом старте MPS. В момент запуска будет предложено произвести идентификацию первичной станции (путем нажатия клавиши “B”), после чего сервер перейдет в режим конфигурации служб RDS/MPS.

MPS добавит учетную запись WmsShell для поддержки работы в multi-station режиме и создаст группу WmsOperators для формирования доступа к консоли управления (Dashboard).

Все 6 пунктов можно “сжать” до 1 команды в PowerShell:

Перейдем в диспетчер управления MPS (MPS Manager)

Со своей удаленной станции я хочу настроить доступ к MPS через RDP-over-LAN. Для этого добавим новую учетную запись пользователя MPS

С точки зрения MPS существует 3 вида пользователей: стандартный пользователь для доступа к MPS, пользователь для управления пользовательскими сессиями и администратор. По сути, это имитация полноценного RBAC (Role Based Access Control).

Итак, пользователь добавлен. Проверим подключение. Используя MSTSC и возможности RDP, я подключаюсь к серверу MPS с помощью выше обозначенной учетной записи. При первом подключении каждого пользователя к MPS будет выведено сообщение: «To assist you with your usage of this computer, your activities may be monitored by your system administrator / Для помощи в использовании данного компьютера ваши действия будут отслеживаться системным администратором».

После подтверждения будет создана новая терминальная сессия для пользователя, при этом администратор сможет управлять пользовательской сессией в интерактивном режиме, используя MPS Dashboard.

Перейдем к MPS Dashboard (отдельная консоль). Основную часть консоли будут занимать динамически меняющиеся мини-экраны пользовательских сессий. Мне это чем-то напоминает экран службы безопасности для мониторинга видеосигналов с камер, но MPS позволяет нам не только наблюдать за тем, что происходит в пользовательских сессиях, но и реально управлять и изменять их (забирать управление, блокировать станции или инициировать log off, отправлять IM выбранным пользователям, блокировать USB-устройства или удаленно запускать/закрывать приложения).

К примеру, с каждой пользовательской станцией и её сессией мы можем сделать следующее:

разблокировать/заблокировать станцию и вывести на экран конкретной станции сообщение;
ограничить веб-доступ путем определения списка разрешенных или запрещенных URLs;
проецировать свой рабочий стол на клиентские станции;

Если вернуться обратно в MPS Manager, то можно увидеть, что подключенная станция отображается во вкладе Stations, где можно дополнительно управлять выбранными станциями.

Настройки самого MPS располагаются на стартовой вкладе Home. Мы можем, к примеру, отключить оповещения о том, что сессия не является приватной, чтобы у пользователей не возникало дополнительных вопросов :)

Multi-Session режим несет некоторые риски, связанные с безопасностью, поэтому предоставляется возможность защитить системный диск от нежелательных изменений. Для включения функции Disk Protection достаточно одно клика и подтверждения.

Если имеется приложение, которое требует клиентскую среду, в некоторых случаях изолированную, то в MPS это достигается за счет включения Virtual Desktops. Принцип работы схож с pooled-коллекцией в полноценном VDI. Каждая «виртуализированная станция» будет создаваться из шаблона и делать откат изменений после каждого выхода пользователя из системы. Как видим, полноценная функциональность VDI не достигается, но всё же само наличие подобной возможности расширяет область применения MPS.

FAQ

Как корректно удалить службы MPS?

Удалите роль через Server Manager, перезапустите сервер и запустите скрипт.

Что насчет модуля PowerShell для MPS?

На данный момент отдельного модуля нет. На мой взгляд, обновится уже имеющийся модуль для RDS с целью поддержки управления MPS.

Выводы

Перемещение функциональности MultiPoint Server в Windows Server 2016 довольно интересное и полезное решение, которое должно оживить применяемость MPS именно в тех сценариях, в которых его рекомендуется использовать. Помимо стандартных учебных классов MPS может применяться так же и партнерами для обеспечения демо-стендов или шоу-румов, независимыми тренерами и другими профессионалами, целью которых является грамотно донести информацию до слушателей или заказчиков.

Спасибо за внимание!

Автор: Microsoft

Источник

www.pvsm.ru

Ошибка: Не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов

При настройке нового узла RDS фермы на базе Windows Server 2012 R2 столкнулся с тем, что в трее стало появляться предупреждение:

Licensing mode for the Remote Desktop Session Host is not configured.

Remote Desktop Service will stop working in xxx days.

Не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов. Служба удаленных рабочих столов перестанет работать через xxx дней.

Т.е. очевидно, что служба RDS Host запущена в режиме льготного периода лицензирования (похожую проблему я уже описывал, но тут оказалось немного другое).

Для более точной диагностики проблемы нужно запустить RD Licensing Diagnoser (Средство диагностики лицензирования удаленных рабочих столов). В окне утилиты будет отображаться такая ошибка:

Не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов

В английской версии Windows Server ошибка выглядит так:

Licensing mode for the Remote Desktop Session Host is not configured

Как вы видите, на самом деле доступных клиентам лицензий нет, т.к. режим лицензирования не задан.

Все это говорит о том, что администратором не выбран сервер лицензирования RDS и / или режим лицензирования. Это несмотря на то, что при развертывании RDS уже был указан тип лицензирования.

Проверить, задан ли сервер лицензирования можно с помощью следующих команд:

$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting$obj.GetSpecifiedLicenseServerList()

Примечание. Командлет Get-RDLicenseConfiguration при этом может выводить совершенно другие, ошибочные данные.

Если сервер лицензирования не задан, его можно указать командой:$obj. SetSpecifiedLicenseServerList("rdslic1.winitpro.ru")

Принудительно выставить режим лицензирования можно несколькими способами.

Через реестр:

В ветке HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core нужно изменить значение DWORD параметра с именем LicensingMode с 5 на

2 — если используется лицензирование по устройствам (Per Device)
4 — при использовании RDS лицензирования по пользователям (Per User)

После внесения изменений нужно перезагрузить сервер.

Параметры сервера лицензирования RDS также можно задать через GPO (локальную или доменную политику).

Допустим, сервер не в домене. Воспользуемся локальным редактором gpedit.msc. Перейдите в раздел Конфигурация компьютера -> Компоненты Windows ->Службы удаленных рабочих столов ->Узел сеансов удаленных рабочих столов ->Лицензирование (Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host\ Licensing).

Нас интересуют две политики

Использовать указанные серверы лицензирования удаленных рабочих столов (Use the specified Remote Desktop license servers) — включите политику и укажите адрес сервера лицензирования RDS, если сервер лицензий запушен на этом же сервере, укажите 127.0.0.1
Задать режим лицензирования удаленных рабочих столов (Set the Remote Desktop licensing mode) – выберите нужный режим лицензирования. В нашем примере Per User.

После перезагрузки сервера открываем средство диагностики лицензирования RDS и видим количество доступных лицензий и выбранный режим лицензирования

Примечание. Если ваш RDS сервер находится в рабочей группе, то отчет по лицензиям не формируется, хотя сами терминальные лицензии выдаются клиентам/устройствам корректно. Следить за количеством оставшихся лицензий придется самостоятельно.

winitpro.ru

терминальный сервер windows 2012 -

Обновлено июль 2014

План настройки:

Различные варианты архитектуры решений MS RDS (тут)
Описание MS RDS в Windows server 2012 и плана моей настройки (эта статья)
Настройка домена в Windows server 2012 R2: Active Directory, DNS, DHCP
Настройка дублирующих служб Active Directory, DNS, DHCP
Развертывание RDS и создание кластера NLB
Развертывание DFS для хранения данных пользователей
Настройка премещаемых профилей и перенаправленных папок

Remote Desktop Services (RDS)

В 2012 сервере терминальные службы объединены со службами виртуальных рабочих столов VDI и называются RDS – remote desktop services. Попробую объяснить целесообразность использования этих технологий.Современные стандарты информационных технологий призывают отказаться от стационарных компьютеров, когда у каждого пользователя есть собственный системный блок, в нем запускается операционная система и программы. А еще 10 лет назад, когда уже существовал терминальный сервер и Citrix XenApp такой повсеместной тенденции не было, ведь основной ресурс, который потребляют службы терминалов (сеансы пользователей) – это оперативная память. Вспомните, раньше купить сервер, поддерживающий 32Гб оперативной памяти, было уже большой удачей. Выходило, что дешевле было использовать стационарные компьютеры, а в терминальном режиме запускали только 1С, в котором работать из филиалов по-другому было невозможно.

Сейчас вычислительные мощности значительно опережают программные требования, эра виртуализации, запуск десятков виртуальных серверов на одном физическом. Терминальный сервер на 30+ пользователей сейчас будет дешевле, чем покупка им стационарных компьютеров. Я по роду своей деятельности, часто сталкиваюсь с руководителями ИТ отделов, которые не воспринимают терминальные службы, как замену стандартному подходу, до тех пор, пока они наглядно не увидят их возможности. Приходится показывать и убеждать.

Парадоксальная ситуация складывается с VDI (как известно все движется по спирали) и сейчас индивидуальные рабочие столы для каждого пользователя дороже, чем покупка компьютеров и дороже, чем терминальный сервер. VDI решения очень требовательны к вычислительным ресурсам, оно и понятно, для каждого пользователя запускается отдельный экземпляр операционной системы.Я наблюдаю следующую картину, т.к. тема очень модная, о ней говорят в новостях, на форумах и конференциях, руководители ИТ служб жаждут посмотреть на эти технологии в деле. Но маркетинговые лозунги разбиваются о стоимость решения, когда люди узнают, что за одно рабочее место придется заплатить 1000+$, запал пропадает, огонек в глазах гаснет. Сейчас в России активно внедряют у себя виртуализацию рабочих мест только государственные компании, которые черпают деньги из бюджета.Но цены на вычислительные мощности (серверы) неумолимо снижаются, еще совсем недавно покупали планки памяти по 4Гб, сейчас я уже в предложения вставляю 16Гб. Количество ядер в процессорах растет, их производительность тоже. И в конце концов, VDI повторит судьбу терминального сервера и цена за одно рабочее место в виртуальной среде будет ниже, чем покупка стационарного компьютера. Еще бы Microsoft пошел навстречу и изменил политику лицензирования VDA (Virtual Desktop Access), а то 120$ в год слишком дорого. Но это в будущем, а пока терминальный сервер.

Терминальный сервер (RDS session) — клиент получает доступ к рабочему столу Windows 2008-2012 server, либо в бесшовном окне открывается окно с опубликованным приложением (RemoteApp). До сотни пользователей может работать на одном терминальном сервере и не знать об этом, причем для каждого будет открыт свой собственный сеанс. Такой подход помогает значительно экономить серверные ресурсы выделяемые на одного пользователя, если сравнить с тем же VDI, и достичь максимальной плотности размещения.

VDI RDS – virtual desktop infrastructure – клиент получает доступ к своей виртуальной машине Windows 7-8, если не говорить сотруднику, что он работает не в своем системном блоке, а на сервере в ВМ, то он, скорее всего, ничего не заметит. Хотя часто пользователи, чувствуют, что все работает быстрее и не тормозит (это из личного опыта). К сожалению VDI от Microsoft не является 100% корпоративном решением, т.к. из-за ограничений системы не рекомендуется размещение более чем 500 VDI машин.

План настройки терминального сервера MS RDS

В первой статье цикла я рассмотрел возможные архитектурные схемы, по которым можно настраивать терминальный сервер. Поразмыслив, какую из них настроить на тестовом стенде, остановился на этой:

Но Connection Broker в моей настройке не будет точкой отказа, хоть и будет установлен в единственном экземпляре, и сейчас объясню почему.

У пользователя в качестве точки входа будет указано доменное имя NLB кластера, который в свою очередь будет настроен так, что в приоритетном порядке будет перенаправлять подключения на Connection Broker, а если он вдруг окажется не доступен, то начнет распределять их по терминальным серверам. На мой взгляд, неплохое бюджетное решение с хорошей отказоустойчивостью.

Данные пользователя будут храниться в распределенной файловой системе DFS, репликация будет происходить синхронно. Для управления данными я настрою перемещаемые профили и перенаправленные папки.

Доменные службы также будут дублироваться на отдельной виртуальной машине.

itsave.ru