Развертывание рабочего стола на основе сеанса в Windows Server 2012, опыт на данный момент (часть 1)

Введение

Теперь, когда Windows Server 2012 стала общедоступной в течение некоторого времени, самое время оглянуться на прошедшие несколько месяцев и посмотреть, что нам принесла Windows Server 2012 и, в частности, развертывание рабочих столов на основе сеансов на базе RDS. В этой статье я поделюсь своим опытом запуска развертывания рабочих столов на основе сеансов в рабочей среде на базе Windows Server 2012. Мы обсудим общий процесс установки и новый способ управления средой развертывания рабочих столов на основе сеансов, а также работает. Это 1 часть из серии из (как минимум) 2х частей.

Прежде чем мы начнем

Прежде чем мы начнем, давайте разберемся с соглашением об именах. Общее название Windows Server 2012 — «Инфраструктура виртуальных рабочих столов на базе служб удаленных рабочих столов». VDI теперь состоит из двух разновидностей; есть развертывание рабочего стола на основе сеанса, которое мы ранее называли службами терминалов, и есть развертывание рабочего стола на основе виртуальной машины, которое мы ранее называли инфраструктурой виртуального рабочего стола. К этому соглашению об именах, вероятно, потребуется некоторое время, чтобы привыкнуть к нему. В течение долгого времени многие, вероятно, все еще будут говорить о RDS, когда они на самом деле имеют в виду развертывание рабочего стола на основе сеанса (на основе RDS), точно так же, как после смены имени в Windows Server 2008 R2 многие все еще ссылаются на службы терминалов, когда они имеют в виду удаленный рабочий стол. Услуги. В Windows Server 2012 были объединены две разновидности RDS. Они используют многие одинаковые роли и компоненты RDS и управляются из единого интерфейса диспетчера серверов (RDMS), что, как мне кажется, оправдывает изменение названия.

Развертывание

В Windows Server 2012 новый способ первоначального развертывания различных ролей, составляющих службы удаленных рабочих столов, называется развертыванием на основе сценария. Хотя на самом деле мастер диспетчера серверов использует имя «Установка служб удаленных рабочих столов». Перед выпуском бета-версии, когда этот выпуск все еще назывался Windows Server 8, мастер называл этот тип установки установкой на основе сценария, но это имя изменилось в общедоступном выпуске. Поэтому, если вы видите, что я упоминаю о сценарии, я имею в виду установку служб удаленных рабочих столов. Таким образом, этот новый способ развертывания изменился по сравнению с предыдущими выпусками, такими как, например, в Windows Server 2008 R2, где вы по-прежнему выполняли развертывание на основе ролей.

За последние месяцы я выполнил несколько развертываний Session-Based Desktop Deployment. Новый способ развертывания определенно экономит время, поскольку три основные роли: посредник подключений к удаленному рабочему столу, веб-доступ к удаленному рабочему столу и узел сеансов удаленного рабочего стола могут быть установлены удаленно с помощью одного мастера. Если вы реализовали RDS в Windows Server 2008 (R2), вы, вероятно, помните, что вам приходилось заполнять такие группы, как компьютеры TS Web Access, компьютеры Session Broker и т. д., и настраивать различные оснастки MMC.

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

С Windows Server 2012 у нас также есть гораздо более широкая поддержка для развертывания и настройки RDS с помощью PowerShell. Дополнительные сведения об этом см. в моих предыдущих статьях Использование PowerShell для управления RDS в Windows Server 2012 (часть 1) и Использование PowerShell для управления RDS в Windows Server 2012 (часть 2).

Конфигурация

Как я упоминал ранее, в Windows Server 2012 все управление может осуществляться централизованно из консоли диспетчера серверов. Для служб удаленных рабочих столов это называется службами управления удаленными рабочими столами (RDMS). По моему опыту, с помощью RDMS определенно легко добавить дополнительные роли на серверы. Однако есть две роли, которые по-прежнему требуют открытия традиционной оснастки MMC. Это шлюз удаленных рабочих столов и лицензирование удаленных рабочих столов. Эти две роли можно установить удаленно с помощью RDMS, однако для настройки вам все равно придется переключиться на другие консоли. Надеюсь, это будет улучшено в будущем. Во время реализации производственных сред я столкнулся с некоторыми параметрами, которые отсутствуют в RDMS. Например, возможность настроить имя фермы, к которому подключаются пользователи. Как вы, возможно, знаете, в Windows Server 2012 посредник подключений к удаленному рабочему столу теперь также служит начальным подключением (подумайте об этом как о режиме выделенного перенаправителя). Поэтому по умолчанию опубликованные приложения и рабочие столы будут подключаться к имени хоста посредника подключений к удаленному рабочему столу. Это имя нельзя изменить с помощью RDMS. Чтобы иметь возможность изменить имя исходного подключения, необходимо подготовить посредник подключений к удаленному рабочему столу для обеспечения высокой доступности. Во время этой подготовки вы можете указать DNS-имя посредника подключений к удаленному рабочему столу. С другой стороны, во всех производственных развертываниях, которые я выполнял до сих пор, я использовал посредника подключений к удаленному рабочему столу с высокой доступностью (или, по крайней мере, был подготовлен для высокой доступности) для создания высокой доступности. Шаги по созданию высокой доступности посредника подключений к удаленному рабочему столу значительно улучшились по сравнению с Windows Server 2008 R2, и настройка высокой доступности теперь также активна-активна, и это здорово. Поскольку посредник подключений к удаленному рабочему столу играет гораздо более важную роль в Windows Server 2012 (в принципе, без него вы вряд ли сможете обойтись), я бы посоветовал всегда настраивать высокую доступность посредника подключений к удаленному рабочему столу, если это возможно. Учтите, однако, что для этого требуется экземпляр SQL Server не ниже версии 2008 R2.

Если вы привыкли управлять своей средой RDS на Windows Server 2008 R2 и впервые перешли на Windows Server 2012, первое, что вы заметите при настройке, это тот факт, что большинство оснасток MMC для удаленного рабочего стола ушли. Там, где мы раньше работали, например, с конфигурацией узла сеансов удаленного рабочего стола, диспетчером подключений к удаленному рабочему столу и диспетчером удаленных приложений, теперь мы можем выполнять большинство этих действий в RDMS. Что, по моему опыту, отлично работает, так это тот факт, что теперь вы можете централизованно публиковать свои удаленные приложения. Раньше вам приходилось публиковать их на всех серверах узла сеансов удаленных рабочих столов либо вручную, либо с помощью функции импорта/экспорта. Что меня также очень порадовало, так это тот факт, что теперь вы можете публиковать полный рабочий стол как удаленное приложение, которое указывает на вашу ферму. Раньше при использовании RemoteApp Manager у вас была опция «Показать подключение к удаленному рабочему столу к серверу узла сеансов удаленных рабочих столов в веб-доступе к удаленным рабочим столам». Недостатком здесь было то, что, как следует из названия, он указывал на один узел сеансов удаленных рабочих столов, а не на ферму. В Windows Server 2012 теперь вы можете опубликовать полный рабочий стол в веб-доступе к удаленным рабочим столам, который указывает на вашу ферму (и полностью поддерживает единый вход), создав коллекцию сеансов типа «Удаленный рабочий стол». Недостатком, с которым я здесь столкнулся, является то, что, поскольку вам нужно поместить коллекцию сеансов в тип «Удаленный рабочий стол», вы не можете публиковать как полноэкранные, так и удаленные приложения внутри одной коллекции сеансов. Для этого вам потребуется создать дополнительную коллекцию сеансов, в том числе дополнительный (набор) серверов узлов сеансов удаленных рабочих столов.

Одной из функций RDS в Windows Server 2008 R2, которая также изменилась в Windows Server 2012, является способ распространения удаленных приложений или рабочих столов. Раньше вы могли использовать RemoteApp Manager и создавать файлы.RDP и.MSI для распространения удаленных приложений или рабочих столов, которые вы хотели опубликовать. Функция создания этих файлов отсутствует в RDS на Windows Server 2012. Лучший способ публикации удаленных приложений и рабочих столов сейчас — использовать URL-адрес веб-канала, который можно настроить с помощью корпоративного адреса электронной почты. Лично я не создавал файлы.RDP или.MSI во многих случаях, поэтому мне не очень не хватает этой функциональности. Но если вы часто использовали его в прошлом, имейте в виду, что этой функции больше не существует. Конечно, есть относительно простые способы получения файлов.RDP. Дополнительные сведения об этом см. в разделе Распространение удаленных приложений и рабочих столов в Windows Server 2012. По моему опыту, функциональность URL-адреса веб-канала очень хорошо работает как в традиционном клиенте удаленного рабочего стола (mstsc), так и в клиенте удаленного рабочего стола с современным интерфейсом.

Вывод

На этом заканчивается часть I этой серии. Не стесняйтесь поделиться своим опытом, добавив комментарий к этой статье или отправив мне электронное письмо. Во второй части я расскажу о своем опыте развертывания рабочего стола на основе сеансов в Windows Server 2012. Некоторые из тем, которые я буду обсуждать во второй части, — это диски профилей пользователей, новый начальный экран современного пользовательского интерфейса., клиент удаленного рабочего стола с современным пользовательским интерфейсом и удаленное управление.