В данной статье пошагово со скриншотами рассмотрим самые базовые настройки Windows Server 2012 R2 (любых версий: Standard, Datacenter, Essentials). В них входит настройка AD, DNS, DHCP, а так же лицензирование терминального сервера (настройка сервера RDP). Эти настройки как правило подходят для большинства задач и являются стандартными для использования их в Windows Server.
С процессом установки и самой начальной настройки как активация сервера, и получение обновлений Windows Server 2012 R2 можете ознакомиться в нашей прошлой статье.
1) Итак, начнем. Для начала нам нужно задать имя сервера, чтобы оно было в последующем корректно указано в различных настройках для подключений. Зайдем в меню «Свойство системы» => Изменить параметры => Далее в окне «Имя компьютера» нажимаем кнопку «Изменить» => После в строке ввода «Имя сервера» задаем имя в произвольном порядке. У нас оно будет просто Server.
Чтобы настройки применились перезагрузите Ваш компьютер.
2) Следующая, тоже очень важная процедура — это задать локальный статический IP адрес серверу. Для быстроты переходим в меню «Пуск», далее в поиске вводим ncpa.cpl.
На Вашем основном сетевом адаптере щелкаем правой кнопкой мыши => Свойства
Выделяем протокол IPv4 и нажимаем «Свойства».
И задаете серверу статический IP адрес в зависимости от Вашей сети. (далее в статье рассмотрим настройку DHCP, чтобы Ваш сервер сам мог раздавать свой диапазон IP адресов). Чтобы посмотреть текущий локальный IP адрес и шлюз — Вам нужно открыть командную строку, в поиске введите «Cmd» => Далее введите команду «ipconfig». Как DNS сервера в предпочтительных можем оставить IP адрес Вашего шлюза (роутера, маршутизатора), а как альтернативный адрес Google — 8.8.8.8
После применяете настройки и проверяете Ваше соединение с интернетом, если все работает, значит Ваши настройки корректные.
3) С настройками IP адресов пока закончено, перейдем к добавлению ролей и компонентов. Заходим в диспетчер серверов. Меню «Панель мониторинга» => Добавить роли и компоненты
Переходим в пункт «Тип установки» и выбираем «Установка ролей или компонентов».
Выбираете Ваш сервер в меню выбора серверов.
В ролях сервера мы в данном случае выбираем самые стандартные роли, которые используются как правило в большинстве задач. Можете сделать так же.
В компонентах оставляем все по стандарту. За исключением того, если у Вас сервер будет работать по Wi-FI, т.е в нем будет какой-либо Wi-Fi адаптер, то без компонента «Службы беспроводной локальной сети» — беспроводное соединение работать не будет. Отмечаете галкой его, если Вам требуется такой функционал.
Далее доходим до меню «Службы ролей» для удаленных рабочих столов. Отмечаем галкой то, что нужно для работы с RDP.
В службах «Удаленный доступ» по желанию можете выбрать работу с приложением для смены IP-адреса и прокси-сервером, это как правило многим не нужно. На Ваш выбор.
Доходим до пункта «Подтверждение», отмечаем галкой автоматический перезапуск после установки и жмем «Установить». Ожидаем пока все установится.
4) Теперь переходим к настройкам тому, что мы только что устанавливали. В конкретном случае к настройкам DNS. Заходим снова в меню «Диспетчер серверов» => Нажимаем на флажок => И выбираем пункт «Повысить роль этого сервера до контроллера домена».
В конфигурации развертывания отмечаем пункт «Добавить новый лес» и придумываем имя корневого домена. В вашем случае это может быть абсолютно любое название, которое Вам понравится, мы назовем как пример «soft.com».
В параметрах контроллера придумываем Ваш пароль для Вашего домена и жмем «Далее».
Теперь можем дойти сразу до предварительной проверки всех настроек. Все будет корректно если у Вас будет в окне указано, что «Все проверки готовности к установке выполнены успешно …«. Нажимаем установить. После установки перезагружаем сервер.
После перезагрузки как будете вводить пароль администратора, Вы можете заметить, что Ваш сервер уже добавлен в домен.
Но это еще не все, нам нужно его до конца настроить. Снова переходим в «Диспетчер серверов» => меню «Свойства» => DNS
Мы перешли в «Диспетчер DNS». Разворачиваем дерево DNS => SERVER (Имя Вашего сервера) => Зоны обратного просмотра => Щелкаем правой кнопкой мыши и нажимаем на пункт «Создать новую зону».
Выбираем «Основная зона» и отмечаем галкой «Сохранять зону в Active Directory …«.
Следующим окном выбираем пункт «Для всех DNS-серверов, работающих на контроллерах домена в этом домене: «ваш домен»«.
Далее выбираем пункт с IPv4 соответственно.
В индефикаторе сети для данного DNS выбираем Ваш IP диапазон или имя зоны. Мы на примере выберем DNS по IP диапазону.
Разрешим динамические обновления, т.к это рекомендуемый параметр для настроек AD.
На этом все, нажимаем готово.
5) Теперь рассмотрим настройки DHCP (чтобы Ваш сервер мог раздавать свой диапазон IP адресов). Переходим в меню «Диспетчер серверов» и выбираем пункт «Завершение настройки DHCP».
В меню «Авторизация» для удобства выбираем пункт «Использовать учетные данные текущего пользователя«. И нажимаем «Фиксировать».
Теперь заходим в меню «Средства» => DHCP.
Разворачиваем дерево DHCP => «Имя вашего домена» => нажимаем на IPv4 правой кнопкой мыши => Создать область.
Задаем имя области, как пример «Basic», Вы можете задать любое название.
Теперь прописываем диапазон IP адресов, который будет раздавать Ваш сервер путем DHCP. Например 192.168.1.1/245. Диапазон задается по Вашему желанию.
В следующем окне можете исключить какой-либо диапазон, например определенные IP адреса. На примере мы его пропустим.
Задаем срок действия IP адреса для устройства, после которого динамически он сменится на другой. Можете задать любой срок в зависимости от Ваших задач, мы поставим 30 дней как пример.
Можете добавить Ваш маршутизатор в эту область, либо пропустить этот шаг.
Укажите имя Вашего домена как родительский.
6) Теперь Вам можно уже настроить удаленные рабочие столы для пользователей. Для этого на Вашем сервере нужно лицензировать сервер удаленных рабочих столов. С инструкцией как происходит настройка RDP на сервере можете ознакомиться в нашей прошлой статье на следующей странице. Приобрести ключ активации для лицензирования Windows Server User/Device CAL можете в нашем каталоге. Быстрая доставка ключа в течении нескольких часов на Вашу электронную почту.
7) Теперь, после того как Вы успешно лицензировали сервер удаленных рабочих столов, можно добавить первого пользователя для подключения по RDP. Заходим в «Диспетчер серверов» => Средства => Пользователи и компьютеры Active Directory.
Разворачиваем дерево «Пользователи и компьютеры» => Правой кнопкой мыши на название Вашего домена или просто имя сервера => Создать => Подразделение.
Чтобы было понятно, что за подразделение можете задать ему имя «Пользователи», или «Клиенты».
Далее в новом разделе «Пользователя» (в зависимости от того, как Вы назвали Ваше подразделение). Нажимаете на него правой кнопкой мыши => Создать => Пользователь.
Теперь в карточке пользователя задаем параметры для пользователя, его имя, фамилию, имя для входа на латинице.
Задаем пароль для входа пользователю на сервер. Так же, по желанию, можете запретить смену пароля пользователям (желательно), поставить неограниченный срой действия пароля, чтобы в дальнейшем заново не задавать его.
Добавление пользователя закончено. Теперь по RDP пользователь может подключиться к серверу со своими данными.
На этом все, мы закончили самую базовую настройку.
Время на прочтение6 мин
Количество просмотров291K
Всем добрый день. Хотелось бы рассказать о установке и конфигурировании Windows Server 2012 R2 Essentials. Эта статья не является призывом к повсеместной установке Windows или пропагандой продуктов Microsoft. Хотелось бы просто рассказать об интересном продукте и возможно кого-то данный продукт заинтересует и пригодится в работе. Статью я старался писать для неподготовленного читателя, поэтому минимум терминологии и максимум обобщения некоторых понятий.
Немножко о редакции Essentials
Windows Server 2012 R2 Essentials – это одна из редакция серверной операционной системы от компании Microsoft. Однако имеет множество отличий от редакций Standard и Datacenter. Что же умеет Essentials:
- Авторизация и аутентификация пользователей вашей сети (домен контроллер службы каталогов Active Directory)
- Файловое хранилище (роль файлового сервера)
- Удаленный доступ к корпоративной сети (VPN и DirectAccess сервер)
- Удаленный доступ к файловому хранилищу через Web-интерфейс (настроенный для этого IIS)
- Удаленный доступ к рабочем столам клиентских машин (шлюз удаленных рабочих столов)
- Резервное копирование клиентских машин (windows backup)
- Резервное копирование самого сервера (windows backup)
- Интеграция с облачными технологиями Microsoft (Office 365, Azure backup и т.д.)
- Консоль единой настройки Essentials, которая позволит настроить возможности описанные выше даже не подготовленному системному администратору.
Если обобщить, то редакция Essentials имеет большинство ролей Windows Server. Некоторые из этих ролей настроены, некоторые доступны в полном объеме, некоторые как например Hyper-V с серьезными ограничениями. Компенсацией за эти все ограничения является более низкая цена, включенных 25 клиентских лицензий, централизованная и простая настройка. Хочу так же отметить, что процесс лицензирования серьезно отличается. Вы можете использовать эту редакцию только для организаций, где число пользователей не превышает 25. Но повторюсь вам не нужно приобретать какие-либо клиентские лицензии.
Таким образом Essentials очень хорошо подходит для малых организаций, которые бы хотели пользоваться большинством современных решений для обеспечения безопасности корпоративной сети, хранения документов, удаленного доступа, возможно, почтовые системы. Для тех организаций, которые не хотели бы тратить много денег как на саму ИТ инфраструктуру, так и на работу высококвалифицированных системных администраторов.
Установка и первоначальная настройка
Установка данной ОС вполне стандартная процедура. Если вы хоть раз устанавливали Windows Vista /7/8/8.1, то вы без проблем установите и Essentials. Однако, если вы не устанавливали ни вышеперечисленных ОС ни любую из последних версий серверных ОС, то я рекомендую или довериться профессионалу или как минимум студенту второкурснику.
Единственное, что я бы рекомендовал в момент установки, если у вас один жёсткий диск, разбить его на два раздела. Т.е. сделать так чтобы после установки в системе был второй уже отформатированный жесткий диск. Безусловно это только рекомендация, вы сможете подготовить второй диск в последующем, однако придется переносить некоторые папки.
После первого входа в свежеустановленную ОС запустится мастер «Настройка Windows Server Essentials», который поможет произвести первоначальную настройку.
На первом шаге вам необходимо задать настройки даты и времени.
На втором шаге вам необходимо заполнить на английском языке название компании. Имя домена и имя сервера будут в таком случая сгенерированы автоматически, хотя конечно вы можете поменять их.
На следующем шаге вам необходимо заполнить имя администратора и задать его пароль.
На последнем шаге необходимо указать способ обновления операционной системы и нажать настроить
После этого запустится процесс, который произведет все необходимые первоначальные настройки. Это займет около 30 минут и потребует несколько перезагрузок. За это время ОС успеет в частности установить необходимые роли и настроить сервер в качестве домен контроллера для нового домена.
Настройка
Продукт весьма большой и обширный, я хотел бы рассказать о самых базовых возможностях настройки, такие как создание пользователей, настройка удаленного доступа, создание папок, подключение клиентов.
Вся настройка происходит в панели мониторинга, доступ к ней есть с рабочего стола, панели быстрого запуска и стартового экрана.
Создание пользователей
При первом запуске данной панели вам откроется вкладка установка, на которой можно выполнить ряд задач по настройке сервера.
Я начну с добавления пользователей. Щелкаем ссылку для добавления учетных записей.
Заполняем поля формы и нажимаем далее
Выбираем уровень доступа к общим папкам, которые были созданы. На начальном этапе существует лишь одна – Организация. В дальнейшем вы можете менять разрешения на доступ как из свойств пользователя, так и из свойств папки.
Далее устанавливаем, что будет доступно для пользователя удаленно. Про удаленный доступ расскажу чуть позже.
Учетная запись создана. Жмем закрыть.
Подобным образом можно создать множество учетных записей. Безусловно, Вы можете пользоваться и привычным и знакомым для вас интерфейсом Active Directory Users and Computers, но в таком случае выдавать разрешения на доступ вам придется ручками.
Добавление папок сервера
Для добавление папок существует другой мастер, который поможет и создать папку на диске, и общий доступ для нее настроить, и разрешения выдать. Для его запуска необходимо щелкнуть соответствующую ссылку в панели мониторинга.
В открывшемся окне мастера вводим название. Можно изменить расположение и добавить описание. Нажимаем далее.
На следующей странице указываем необходимые разрешения. При необходимости делаем ее недоступной при удаленном доступе.
С последнего шага данного мастера можно запустить мастер настройки архивации. Нажимаем закрыть.
Настройка удаленного доступа
Один, наверное, из самых сложных этапов настройки Windows Server 2012R2 Essentials. Настройка так же происходит с помощью мастера. Мастер традиционно запускается из панели мониторинга.
Первое что Вам необходимо настроить это ваш маршрутизатор – об этом Вам сообщает мастер. На самом деле Вам необходимо настроить перенаправление портов на маршрутизаторе. Для этого у маршрутизатора должен быть «белый» IP адрес. А на самом сервере лучше настроить статический IP адрес. Перенаправить нужно следующие порты 80, 443, 1723, 987 на IP адрес вашего сервера. В общем то процедуру настройки может выполнить и сам мастер, если ваш маршрутизатор поддерживает UPnP. Я делал настройку ручками, поэтому пропустил данный шаг.
После этого открывается новый мастер настройки доменного имени. Нажимаем далее.
Мастер предложит ввести имя внешнего домена или создать новый. Для собственного домена Вам понадобится сертификат, поэтому рассмотрим тут вариант настройки с использованием домена Microsoft. Выбираем другое имя домена и щелкаем далее.
Рассмотрим вариант с доменом компании Microsoft.
Тут попросит авторизоваться в Microsoft Account.
После авторизации принимаем заявление о конфиденциальности.
Вводим имя домена и проверяем доступность, жмем настроить.
Ну что с именем домена разобрались. Продолжаем — далее.
Выбираем какие именно возможности будут доступны.
Выбираем будет ли доступен удаленный доступ для текущих пользователей.
Ну вот и все можете попробовать зайти на сайт wiseguy.remoteweaccess.com.
C данного веб сайта есть возможность доступа к общим папкам и доступ к рабочим столам пользователей.
Подключение рабочих станций
Если мы и на этот раз откроем панель мониторинга и перейдем на страницу подключение компьютеров, то увидим там лишь инструкцию к действию
Следуя инструкции на клиенте в браузере открываем страничку http://<Имя сервера>/connect. Нажимаем ссылку для скачивания.
Выбираем выполнить.
Принимаем лицензию и ждем.
Вводим имя пользователя и пароль пользователя данного компьютера или администратора. Я вводил учетку пользователя.
Перезагружаем сервер.
Выбираем, кто будет пользоваться компьютером.
Вводим описание компьютера.
Параметры архивации.
Ура! Готово.
Заходим на компьютер под учетной записью пользователя.
Можно работать. На рабочем столе уже есть все необходимые ярлыки.
Post scriptum
Безусловно Windows Server 2012R2 Essentials – это не панацея. Автоматизировано в ней многое, но не все. Тем не менее для малых организаций, это весьма интересное решение и его необходимо рассмотреть. В этой статье я рассказал лишь о самых базовых настройках Essentials. Если вы желаете чуть ближе познакомиться с продуктом, вы можете посмотреть мои видеодоклады на сайте Techdays.ru .
Windows Server 2012 R2 Essentials первый взгляд: www.techdays.ru/videos/7351.html — тут можно внимательно изучить процесс инсталляции Essentials.
Windows Server 2012 R2 Essentials настройка: www.techdays.ru/videos/7370.html — рассмотрены настройка всех возможностей, показана настройка удаленного доступа для своего домена.
Windows Server 2012 R2 Essentials интеграция Office 365: www.techdays.ru/videos/7380.html — интеграция с облачным офисом от Microsoft.
Комментарии и вопросы приветствуются.
Теневое shadow подключение к RDP/RDS сеансам позволяет администраторам подключиться к сессии любого пользователя для просмотра рабочего стола пользователя и взаимодействия с ним. Режим Remote Desktop Shadowing (теневого подключения) работает во всех современных версиях Windows, начиная с Windows 2012 R2 и Windows 8.1 (кроме версии Windows Server 2012, в которой стек rdp перенесен из режима ядра в пользовательский режим). В этой статье мы рассмотрим, как настроить и использовать RDS Shadowing для подключения к RDP сессиям пользователей в Windows Server 2016 и Windows 10
Содержание:
- Использование Remote Desktop Shadow из графического GUI
- Групповые политики управления теневыми подключениями к RDS сессиям в Windows
- Теневое подключение RDS Shadow из PowerShell
- Как разрешить обычном пользователям использовать теневое подключение?
В Windows Server 2016/Windows 10 в стандартном RDP клиенте (mstsc.exe) есть несколько специальных параметров, которые можно использовать для удаленного теневого (RDS Shadow) подключения к RDP сессии любого пользователя:
Mstsc.exe [/shadow:sessionID [/v:Servername] [/control] [/noConsentPrompt] [/prompt]]
- /shadow:sessionID – подключиться к RDP сессии пользователя по ID;
- /v:servername – можно указать имя удаленного хоста (RDP/RDS терминального сервера). Если имя сервера не указано, выполняется подключение к локальным сеансам на текущем хосте;
- /control – включает возможность взаимодействия с сеансом (рабочим столом) пользователя. Администратор может управлять мышкой пользователя, вводить данные с клавиатуры. Если эта опция не указана, используется режим просмотра сессии пользователя;
- /noConsentPrompt – опция позволяет администратору принудительно подключиться к любой сессии, не запрашивая у пользователя подтверждение на подключение;
- /prompt – позволяет использовать для подключения другую учетную запись, отличную от текущей. Запрашивается имя и пароль пользователя для подключения к сеансу.
Теневые сеансы можно использовать для подключения к сессиям пользователей на компьютерах и серверах как в домене Active Directory, так и в рабочей группе. Кроме того, не обязательно обладать правами администратора на RDS хосте, на котором работает пользователь. Администраторы могут делегировать полномочия RDS Shadowing любым, даже не-административных учетным записям (об этом ниже).
Использование Remote Desktop Shadow из графического GUI
Подключиться к сессии пользователя можно с помощью утилиты mstsc.exe или графической консоли Server Manager. Для этого в консоли Server Manager на RDS сервере перейдите в раздел Remote Desktop Services -> выберите свою коллекцию, например QuickSessionCollection.
В списке справа будет перечислен список пользователей у которых имеются сессии на данном RDS сервере. Щелкните правой кнопкой по сессии нужно пользователя, выберите в контекстном меню Shadow (Теневая копия).
Вы можете подключиться только к активной сессии пользователя. Если сессия находится в состоянии Disconnected (отключена по таймауту), подключиться к такой сессии нельзя:
Shadow Error - The specified session is not connected.
Появится окно c параметрами теневого подключения. Возможен просмотр (View) и управление (Control) сессией. Кроме того, можно включить опцию Prompt for user consent (Запрашивать согласие пользователя на подключение к сессии).
Если выбрана опция «Запрашивать согласие пользователя», в сессии у пользователя появится запрос:
Запрос на удаленное наблюдение/ Remote Monitoring Request Winitpro\administrator запрашивает удаленный просмотр вашего сеанса. Вы принимаете этот запрос?
Winitpro\administrator is requesting to view your session remotely. Do you accept the request?
Если пользователь подтвердит подключение, то администратор увидит его рабочий стол в режиме просмотра, но не сможет взаимодействовать с ним.
Совет. Для отключения от сессии пользователя и выхода из shadow-режима, нужно нажать ALT+* на рабочей станции или Ctrl+* на RDS сервере (если не заданы альтернативные комбинации).
Если пользователь отклонил административное Shadow RDS подключение, появится окно:
Shadow Error: The operator or administrator has refused the request.
Если попытаться подключиться к сессии пользователя без запроса подтверждения, появится ошибка, сообщающая, что это запрещено групповой политикой:
Shadow Error: The Group Policy setting is configured to require the user’s consent. Verify the configuration of the policy settings.
Если вам нужно вести аудит RDS Shadow подключений к пользователям, используйте в качестве фильтра следующие события из журнала Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational:
- Event ID 20508: Shadow View Permission Granted
- Event ID 20503: Shadow View Session Started
- Event ID 20504: Shadow View Session Stopped
Групповые политики управления теневыми подключениями к RDS сессиям в Windows
Параметры удаленного управлениями RDS сессиями пользователя настраиваются отдельным параметром групповых политик — Set rules for remote control of Remote Desktop Services user sessions (Установить правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов). Данная настройка находится в разделе Policies -> Administrative Templates -> Windows components -> Remote Desktop Services -> Remote Session Host -> Connections (Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Подключения) в пользовательской и компьютерной секциях GPO. Данной политике соответствует DWORD параметр реестра Shadow в ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services (значения этого параметра, соответствующие параметрам политики указаны в скобках).
Этой политикой можно настроить следующие варианты теневого подключения RD Shadow:
- No remote control allowed — удаленное управление не разрешено (значение параметра реестра
Shadow = 0
); - Full Control with users’s permission — полный контроль сессии с разрешения пользователя (
1
); - Full Control without users’s permission — полный контроль без разрешения пользователя (
2
); - View Session with users’s permission – наблюдение за сеансом с разрешением пользователя (
3
); - View Session without users’s permission – наблюдение за сеансом без разрешения пользователя (
4
).
Вы можете настроить правила удаленного подключения в домене из консоли управления GPO
gpmc.msc
с помощью рассмотренного параметра политики, либо групповой политикой, вносящей изменения напрямую в реестр системы (последний вариант позволяет более тонко нацелить политику на компьютеры с помощью Group Policy Item Level Targeting).
Теневое подключение RDS Shadow из PowerShell
Воспользоваться функционалом теневого подключения к сессии пользователя через теневое подключение Remote Desktop Services можно и из Powershell.
В первую очередь нужно получить список пользовательских сессий на терминальном RDS сервере (сессии пользователей будут сгруппированы в группы в зависимости от их статуса):
Get-RDUserSession | ft Username, UnifiedSessionId, SessionState, HostServer, ApplicationType -GroupBy Sessionstate
На данном сервере мы обнаружили три активных RDP сессии пользователей. Чтобы подключиться к сессии пользователя с ID сессии 3, выполните команду:
Mstsc /shadow:3 /control /noConsentPrompt
Также для получения списка всех RDP сессии на сервере (или десктопной редакции Windows 10 к которой разрешены множественные RDP подключения) можно использовать команду:
quser
Или
qwinsta
На экране отобразится список RDP сессий, их ID и статус: активная сессия (Active) или отключенная (Disconnected).
Для получения списка сессий на удалённом сервере выполните команду:
query session /server:servername
Чтобы подключиться к сессии пользователя на удаленном сервере, используйте команду:
Mstsc /v:rdsh2:3389 /shadow:3 /control
Для более удобного теневого подключения к RDP сессиям пользователей можно использовать следующий скрипт. Скрипт предложит ввести имя удаленного компьютера и выведет список всех пользователей с активными RDP сеансами. Вам нужно будет указать ID сеанса, к которому нужно подключится через Shadow сессию:
shadow.bat
@echo off
set /P rcomp="Enter name or IP of a Remote PC: "
query session /server:%rcomp%
set /P rid="Enter RDP user ID: "
start mstsc /shadow:%rid% /v:%rcomp% /control
Можно поместить данный файл в каталог %Windir%\System32. В результате для теневого подключения к пользователю достаточно выполнить команду shadow.
Для подключения к консольной сессии можно использовать такой скрипт:
@echo off
set /P rcomp="Enter name or IP of a Remote PC: "
for /f "tokens=3 delims= " %%G in ('query session console /server:%rcomp%') do set rid=%%G
start mstsc /shadow:%rid% /v:%rcomp% /control
Также для теневого подключения можно использовать следующий PowerShell скрипт с простым графическим интерфейсом (rdp_shadow_connection.ps1):
Add-Type -assembly System.Windows.Forms
$Header = "SESSIONNAME", "USERNAME", "ID", "STATUS"
$dlgForm = New-Object System.Windows.Forms.Form
$dlgForm.Text ='Session Connect'
$dlgForm.Width = 400
$dlgForm.AutoSize = $true
$dlgBttn = New-Object System.Windows.Forms.Button
$dlgBttn.Text = 'Control'
$dlgBttn.Location = New-Object System.Drawing.Point(15,10)
$dlgForm.Controls.Add($dlgBttn)
$dlgList = New-Object System.Windows.Forms.ListView
$dlgList.Location = New-Object System.Drawing.Point(0,50)
$dlgList.Width = $dlgForm.ClientRectangle.Width
$dlgList.Height = $dlgForm.ClientRectangle.Height
$dlgList.Anchor = "Top, Left, Right, Bottom"
$dlgList.MultiSelect = $False
$dlgList.View = 'Details'
$dlgList.FullRowSelect = 1;
$dlgList.GridLines = 1
$dlgList.Scrollable = 1
$dlgForm.Controls.add($dlgList)
# Add columns to the ListView
foreach ($column in $Header){
$dlgList.Columns.Add($column) | Out-Null
}
$(qwinsta.exe | findstr "Active") -replace "^[\s>]" , "" -replace "\s+" , "," | ConvertFrom-Csv -Header $Header | ForEach-Object {
$dlgListItem = New-Object System.Windows.Forms.ListViewItem($_.SESSIONNAME)
$dlgListItem.Subitems.Add($_.USERNAME) | Out-Null
$dlgListItem.Subitems.Add($_.ID) | Out-Null
$dlgListItem.Subitems.Add($_.STATUS) | Out-Null
$dlgList.Items.Add($dlgListItem) | Out-Null
}
$dlgBttn.Add_Click(
{
$SelectedItem = $dlgList.SelectedItems[0]
if ($SelectedItem -eq $null){
[System.Windows.Forms.MessageBox]::Show("Выберите сессию для подключения")
}else{
$session_id = $SelectedItem.subitems[2].text
$(mstsc /shadow:$session_id /control)
#[System.Windows.Forms.MessageBox]::Show($session_id)
}
}
)
$dlgForm.ShowDialog()
Данный скрипт отобразить графическую форму со списком активных RDP сеансов на локальном сервере. Вам останется только выбрать учетную запись пользователя и нажать Connect.
Вы можете использовать теневое подключение к пользователю не только в Windows Server с ролью Remote Desktop Services, но и для подключения к рабочим столам пользователей на компьютерах с Windows 10 .
Как разрешить обычном пользователям использовать теневое подключение?
В рассмотренных выше примерах для использования теневого подключения к RDP сессиям пользователей необходимы права локального администратора на RDS сервере. Однако вы можете разрешить использовать теневое (shadow) подключение и для непривилегированных пользователей (не предоставляя им прав локального администратора на компьютере/сервере).
К примеру, вы хотите разрешить членам доменной группы AllowRDSShadow использовать теневое подключение к RDP сессиям. Выполните команду в cmd.exe с правами администратора:
wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName='RDP-Tcp') CALL AddAccount 'corp\AllowRDSShadow',2
В январе 2018 года после установки обновления KB4056898 (патч Windows против Meltdown и Spectre) пользователи столкнулись, что в Windows Server 2012 R2 перестал работать теневой доступ. При попытке выполнить теневое подключение к чужой сессии появляется сообщение «Неопознанная ошибка» (в логах присутствует ошибка
STATUS_BAD_IMPERSONATION_LEVEL
). Аналогичная проблема возникала и на RDS ферме на базе Windows Server 2016.
Для решения проблемы нужно установить отдельные обновления:
- для Windows Server 2016 — KB4057142 (от 17 января 2018)
- для Windows Server 2012 R2 — KB4057401 (от 17 января 2018)
Ранее мы уже писали об особенностях установки пакета Remote Server Administration Tools (RSAT) в Windows 10. Но время идёт и новые релизы Windows 10 вносят новые правила работы с этим пакетом. В этой заметке мы поговорим об особенностях автономной установки RSAT в актуальной версии Windows 10 1903.
Графический интерфейс «Параметры Windows» и UAC
В рассматриваемой нами версии Windows 10 активацию компонент RSAT можно выполнить через графический интерфейс Windows, пройдя последовательно в Параметры Windows > Приложения > Дополнительные возможности > Добавить компонент
Однако, если с помощью этого графического интерфейса мы попытаемся выполнить добавление компонент на системе, подключенной к локальному серверу WSUS/SCCM SUP, то может получиться так, что мы даже не сможем получить перечень доступных к установке компонент.
Эта проблема будет воспроизводится в том случае, если текущий пользователь системы не имеет прав локального администратора и доступ к интерфейсу добавления компонент выполняется с запросом повышения привилегий UAC. При этом, если войти в систему интерактивно с правами администратора, то список компонент в графическом интерфейсе мы всё же сможем увидеть.
Компоненты RSAT и PowerShell
В качестве альтернативного варианта получения списка опциональных компонент Windows можно использовать оболочку PowerShell, запущенную с правами администратора. Для получения компонент, относящихся к пакету RSAT можно выполнить команду:
Get-WindowsCapability -Name RSAT* -Online | Select-Object -Property State,Name,DisplayName | Format-Table -AutoSize
Установку той или иной компоненты можно выполнить командой типа:
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
Feature On Demand и проблема Offline-клиентов
Теперь нам понятно, что графический интерфейс Windows 10 1903 работает с UAC криво, а в PowerShell всё в этом плане хорошо. Однако, безотносительно способа установки, в том случае, если компьютер настроен на использование WSUS/SUP и не имеет прямого доступа в интернет, при попытке установки выбранной компоненты мы можем получить ошибку 0x800f0954.
И ошибка эта будет воспроизводиться как при использовании PowerShell, так и при использовании графического интерфейса. Правда, в графическом интерфейсе, опять же, это может быть не так очевидно.
Как я понял, связано это с тем, что для установки опциональных компонент требуется наличие доступа к комплекту пакетов установки Feature On Demand (FOD) для нашей «модной» версии Windows 1903. Именно в этот комплект включаются компоненты RSAT, начиная с обновления Windows 10 1809 от Октября 2018 года. Об этом, в частности, гласит примечание на странице загрузки Remote Server Administration Tools for Windows 10
Интересно то, что на этой же веб-странице имеется сноска о том, что пользователям, использующим WSUS/SUP, и получающим выше обозначенную ошибку 0x800f0954, для возможности установки компонент RSAT придётся настраивать прямой доступ на Windows Update, либо использовать метод с сетевым каталогом.
Known issues affecting various RSAT versions:
Issue: RSAT FOD installation fails with error code 0x800f0954
Impact: RSAT FODs on Windows 10 1809 (October 2018 Update) in WSUS/SCCM environments
Resolution: To install FODs on a domain-joined PC which receives updates through WSUS or SCCM, you will need to change a Group Policy setting to enable downloading FODs directly from Windows Update or a local share.
И в этой ситуации администраторы используют разные пути. Некоторые идут по пути наименьшего сопротивления, не заморачиваясь при этом вопросами удобства и безопасности, и отключают на время установки RSAT нацеливание клиента на WSUS с последующей организацией прямого доступа к Windows Update.
На мой взгляд, этот метод «так себе», так как далеко не всегда и не во всех ситуациях возможно, или даже временно допустимо, обеспечивать прямой доступ на внешние интернет-узлы. К тому же решение с временной правкой реестра и последующим перезапуском службы клиента Windows Update назвать удобным язык не повернётся. При этом ведь ещё нужно помнить про том, что нигде в групповых политиках не должно быть настроено явных запретов на до-загрузку контента Windows c Windows Update.
Feature On Demand и WSUS
А что же нам в этой ситуации может предложить наш локальный источник обновлений — WSUS? Если заглянуть в свойствах сервера WSUS в перечень продуктов, относящихся к Windows 10 (…интересно, в Microsoft сами ориентируются в этом списке?…), то мы увидим такую интересную позицию, как Windows 10 Feature On Demand.
Не найдя нигде в открытых источниках вменяемого развёрнутого описания этой позиции (…впрочем, как и многих других…) мы решили включить её и проверить, что она нам даст. По итогу могу сказать, что среди метаданных о более, чем тысячи обновлений, прилетевших после синхронизации WSUS с Windows Update, я увидел только некоторые компоненты FOD, большинство из которых применимы только для старых версий Windows 10. Ну и в придачу мы получили целый ворох языковых пакетов на всех мыслимых и немыслимых языках, невзирая на то, что в настройках сервера WSUS у нас включены только английский и русский языки. В общем и целом эта позиция на WSUS для нас оказалась бесполезной и даже вредительской.
Раздача Feature On Demand для Offline-клиентов
В результате проведённых экспериментов стало очевидно, что единственным приемлемым в нашей ситуации вариантом, позволяющим выполнять Offline-установку RSAT, является вариант с развёртыванием специального сетевого каталога с компонентами Feature On Demand с нацеливанием клиентов на этот каталог через групповые политики.
Для начала нам потребуется получить образы дисков с компонентами FOD для нашей версии Windows 10. Загрузить эти образы можно вручную с сайта Volume Licensing Service Center (VLSC)
Создаём на файловом сервере общедоступный сетевой ресурс для клиентских систем 64-bit и распаковываем в него всё содержимое образов SW_DVD9_NTRL_Win_10_1903_64Bit_MultiLang_FOD_.ISO. Рядом создаём аналогичный ресурс для систем 32-bit и распаковываем туда образы SW_DVD9_NTRL_Win_10_1903_W32_MultiLang_FOD_.ISO.
Распакованный контент будет представлять из себя множество *.cab файлов, среди которых есть и интересующие нас опциональные компоненты RSAT.
Теперь на любом Offline-клиенте c Windows 10 1903 мы можем попытаться выполнить установку компонент RSAT c помощью PowerShell, указывая в качестве источника получения подготовленный сетевой каталог:
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 -LimitAccess -Source \\holding.com\Installers\Windows-Feature-On-Demand\Win10-1903\64-bit
Имейте в виду, что командлет Add-WindowsCapability работает довольно специфично. То есть он может отработать без ошибки, но если в указанном источнике не будут найдены файлы, подходящие для данной системы, никакой установки на самом деле не произойдёт… Разумеется, «это не баг, а фича»… Поэтому после выполнения командлета установки всех нужных компонент, лучше повторно проверять установленные компоненты:
Get-WindowsCapability -Name RSAT* -Online | Select-Object -Property State,DisplayName | Where {$_.State -eq "Installed"} | Format-Table -AutoSize
После этого установленные компоненты RSAT можно будет видеть в уже «горячо полюбившейся» нам графической оболочке Windows 10 1903 в ранее упомянутом перечне дополнительных компонент Windows
И отсюда же их можно будет удалить при необходимости.
Таким образом все администраторы в организации смогут с помощью PowerShell вручную установить нужные им компоненты RSAT на свои системы Windows 10 1903, не имея прямого доступа в интернет. Однако Offline-установку можно сделать ещё удобней, если дополнительно настроить специальный параметр групповой политики, указывающий клиентам расположение сетевого каталога с компонентами FOD. Описан этот параметр GPO, например, в документе: How to make Features on Demand and language packs available when you’re using WSUS/SCCM.
Переходим в консоль управления групповыми политиками и в разделе политик Administrative Templates > System находим параметр «Specify settings for optional component installation and component repair«
Включаем этот параметр и указываем путь к сетевому каталогу с компонентами FOD в поле «Alternate source file path«.
Этот параметр групповой политики фактически принесёт на клиентские системы параметр реестра «LocalSourcePath» в ключе HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing
После этого Offline-установка компонент FOD станет доступна и через графический интерфейс Windows без использования танцев с PowerShell
Однако при этом стоит помнить про ранее обозначенный нюанс с пустым списком компонент в случае использования графического интерфейса в связке с UAC. То есть выполнять установку компонент FOD через графический интерфейс окна «Параметры Windows» нужно только при интерактивном входе в систему из под административной учётной записи. Если по какой-то причине заходить в систему администратором интерактивно нет желания/возможности, то можно использовать выше описанный метод с установкой через PowerShell.
При этом опять же стоит отметить то, что приятным плюсом использования настройки пути к компонентам FOD через групповую политику станет и то, что теперь при использовании PowerShell не потребуется явно указывать путь для установки нужных компонент:
И вроде бы теперь всё здорово, результат достигнут, то есть Offline-установка работает и через графический интерфейс и через PowerShell. Но дивные «фичи» на этом не кончаются.
Обработка «LocalSourcePath» с несколькими путями
Ещё одной странной штукой, которая была обнаружена при работе с выше обозначенным параметром групповой политики, это то, что, судя по описанию в GPO, значение опции «Alternate source file path» может принимать несколько путей с разделителем в виде точки с запятой. Однако практические эксперименты с Windows 10 1903 показали, что при считывании значения «LocalSourcePath» из реестра система заглядывает только в первый по счёту каталог (указанный до точки с запятой), а остальные игнорирует. Такое поведение вполне вписывается в рамки обработки значения ключа -Source командлета Add-WindowsCapability, в описании которого есть соответствующее примечание
If you specify multiple Source arguments, the files are gathered from the first location where they are found and the rest of the locations are ignored.
Вариантом выхода из этой ситуации может быть отказ от использования классического параметра из административных шаблонов GPO и настройка пути в реестре средствами Group Policy Preferences (GPP) с использованием таргетинга по версии и разрядности клиентской операционной системы.
По крайней мере именно на таком варианте мы и остановились, как на наиболее гибком и работоспособном.
Финиш
В итоге квест под названием «Выполнить Offline-установку RSAT в Windows 10 и не слететь с катушек» пройден, и теперь все административные пользователи, работающие на новой Windows 10 1903, могут устанавливать компоненты RSAT, как через графический интерфейс Windows, так и через PowerShell фактически в Offline-режиме и без дополнительных сложностей и манипуляций по аналогии с Online-клиентами.
PS: Никогда ещё установка RSAT в Windows у меня не была такой увлекательной и долгой. Чем больше смотрю на новые релизы Windows 10, тем становится интересней, во что же вся эта тенденция в итоге выльется. Коллега предположил, что в итоге получится, что-то вроде ранних выпусков Mandriva Linux – жутко красиво, но пользоваться этим без слёз невозможно
Описание задачи: Настраиваем терминальный сервер Windows 2012 R2 для возможности предоставления вычислительных ресурсов пользователям.
Шаг 1 — Настройка роли терминального сервера на windows 2012 R2
Авторизуйтесь в ОС под локальной учетной записью администратора и запустите Диспетчер серверов (Server Manager).
Запускаем мастер добавления ролей и компонентов, где выбираем тип установки «Установка ролей или компонентов»:
Рисунок 1 – Установка ролей и компонентов
Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В нашем случае это локальный сервер. Нажимаем «Далее».
Рисунок 2 – Выбор сервера из пула серверов
Отмечаем роль «Службы удаленных рабочих столов» в списке ролей и жмем «Далее».
Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее».
Рисунок 3 – Служба удаленных рабочих столов
Теперь необходимо выбрать устанавливаемые службы ролей. Выбираем «Лицензирование удаленных рабочих столов» и также соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» в появившемся мастере.
Рисунок 4 – Лицензирование удаленных рабочих столов
Также устанавливаем «Узел сеансов удаленных рабочих столов». Отметив необходимы службы ролей, нажимаем «Далее».
Рисунок 5 – Узел сеансов удаленных рабочих столов
Все параметры установки роли определены. Жмем «Далее».
На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется, нажимаем «Да» в появившемся окне и нажимаем «Установить» для запуска установки службы.
Если все прошло хорошо, после перезагрузки увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» для завершения работы мастера.
Шаг 2 – Определение сервера лицензирования для службы удаленных рабочих столов
Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов». Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства»— «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов».
Здесь мы видим, что доступных лицензий пока нет, т. к. не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов.
Рисунок 6 – Число доступных лицензий
Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду «gpedit.msc» в пункте меню Пуск – Выполнить.
Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:
«Конфигурация компьютера» – «Административные шаблоны» – «Компоненты Windows» – «Службы удаленных рабочих столов» – «Узел сеансов удаленных рабочих столов» – «Лицензирование»
Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов», кликнув 2 раза по соответствующей строке.
Рисунок 7 – Редактор локальной групповой политики
В окне редактирования параметров политики, переставим переключатель в «Включено». Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В нашем случае сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК».
Рисунок 8 – Назначения сервера лицензирования
Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов». Также устанавливаем переключатель в «Включено» и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта – «На пользователя» или «На устройство».
Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК».
Рисунок 9 – Выбор режима лицензирования
Изменив вышеперечисленные политики, закрываем редактор.
Рисунок 10 – Итоговый вид групповой политики
Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов». Найти его можно в диспетчере серверов, вкладка «Средства»— «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов».
Здесь найдем наш сервер лицензирования, со статусом «Не активирован». Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер».
Рисунок 11 – Активация сервера лицензирования
Запустится Мастер активации сервера. Жмем «Далее» на первой странице мастера. Затем выбираем метод подключения «Авто» и жмем «Далее».
Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее»
Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее»
Сервер лицензирования активирован.
Шаг 3 – Установка лицензий на сервер лицензирования службы удаленных рабочих столов
Теперь произведем установку лицензии на сервер лицензирования службы удаленных рабочих столов. Для этого нажимаем в окне «Лицензирования удаленных рабочих столов» на активированный сервер лицензирования и выбираем пункт «Установить лицензии».
Нажимаем «Далее» на начальной странице Мастера установки лицензий.
Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement». Жмем «Далее».
Рисунок 12 – Программа лицензирования
Вводим номер соглашения и нажимаем «Далее».
Рисунок 13 – Номер соглашения
Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее».
Рисунок 14 – Выбор версии продукта
Ждем завершения работы мастера установки лицензий с сообщением о том, что запрошенные лицензии успешно установлены. Жмем «Готово».
В диспетчере лицензирования убеждаемся, что сервер работает, а также видим общее и доступное число установленных лицензий.
Рисунок 15 – Просмотр лицензий
Возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов» и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.
На этом настройка сервера терминалов в Windows Server 2012 завершена.
Шаг 4 – Подключение к серверу терминалов
Для подключения к серверу терминалов можно использовать встроенный в Windows клиент «Подключение к удаленному рабочему столу».
Есть вопросы? Можете написать в чат для связи с нашим специалистом.