Завершающие этапы миграции с Windows Server 2003

Некоторые специалисты обеспокоены тем, что разработчики Microsoft, увлеченные внедрением «облака», забудут о локальных серверах или вовсе откажутся от них. Сомневаюсь, что это так. Место для локальных серверов будет всегда. «Облако» может оказаться хорошей заменой для многих локальных рабочих нагрузок с технической и финансовой точек зрения, но из этого не следует, что все организации внезапно прекратят размещать свои рабочие нагрузки локально. Достаточно взглянуть на число компаний, предпочитающих «облаку» переход с Server 2003 на Server 2012 R2 (см. врезку «60% отстающих»), чтобы понять: «облако» — удачное решение для многих, но не идеальное для всех.

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

Если вы хотите узнать, какие обстоятельства могут помешать переходу в «облако», особенно если вы живете за пределами США, ознакомьтесь с интервью Джона Оливера, взятым у Эрика Сноудена.

Существуют рабочие нагрузки, такие как файловые службы и инфраструктурные службы, например DHCP, DNS и Active Directory, которые почти всегда требуется размещать локально. Следующая версия Windows Server, как и предшествующие, будет превосходно приспособлена для локального размещения. Даже при недавно обнаружившемся интересе Microsoft к Linux ни при каких обстоятельствах компания не передаст роли размещения локальных файловых серверов, серверов DHCP, серверов DNS на компьютеры с операционными системами Red Hat или CentOS из-за отсутствия желания выпускать Windows Server или в попытке загнать всех в «облако».

Нельзя отрицать, что в последнее время известия о Windows Server были довольно скудными, и некоторые спешат заполнить информационный вакуум собственными размышлениями (как я в этой статье). Надеюсь, что после завершения эксплуатации Server 2003 и проведения мероприятий Build и Ignite ИТ-сообщество и Microsoft начнут осмысленный диалог о будущем Windows Server.

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

Среда тестирования миграции

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

Предположим, вы можете перенести определенные рабочие нагрузки в виртуальную среду и получить представление об аппаратных возможностях. Но вот вы запускаете тест рабочей нагрузки после переноса и обнаруживаете, что ваши предположения не соответствуют действительности. Обдумывая миграцию тестовой среды, не забывайте, что вы можете выполнять тестирование «по частям». В большинстве случаев вы переносите за один раз с Server 2003 на Server 2012 или Server 2012 R2 более одной нагрузки. Это означает скорее возможность единовременной проверки одной рабочей нагрузки, нежели тестирования всех аспектов миграции разом.

Итак, что создает хорошее окружение для тестирования миграции?

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

Например, вы обдумываете развертывание восьми узлов отказоустойчивого кластера Hyper-V для размещения перенесенных производственных нагрузок, где каждый узел имеет много оперативной памяти и неограниченную емкость диска. Не нужно развертывать восемь узлов отказоустойчивого кластера Hyper-V для окружения тестирования. Чтобы проверить механизм отказоустойчивости, достаточно двух узлов.

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

Миграция службы сертификатов

Прежде чем приступить к миграции служб сертификатов с Server 2003 на Server 2012 R2, необходимо понять, как выглядит текущее развертывание служб сертификатов. Первый вопрос, на который нужно ответить: какие серверы сертификатов имеются в вашей организации?

Существует четыре разновидности серверов сертификатов, работающих на Windows Server 2003.

• Корневой удостоверяющий центр предприятия. Он должен быть установлен на компьютере, присоединенном к домену. Если имеется только один удостоверяющий центр и вы регистрируете и управляете сертификатами автоматически с использованием Active Directory, то, скорее всего, это корневой удостоверяющий центр предприятия.
• Подчиненный удостоверяющий центр предприятия. Он также должен быть установлен на компьютере, присоединенном к домену. Если у вас имеется два или несколько удостоверяющих центров и вы регистрируете или обновляете сертификаты с использованием Active Directory, то, скорее всего, ваши сертификаты выдаются подчиненным удостоверяющим центром предприятия.
• Автономный корневой удостоверяющий центр. Автономный корневой удостоверяющий центр может быть установлен на компьютере, присоединенном к домену, или на компьютере, который не присоединен к нему. Компании, которые серьезно относятся к безопасности удостоверяющего центра, используют так называемый «автономный корневой удостоверяющий центр», представляющий собой отдельный корневой удостоверяющий центр, отключенный большую часть времени (потому что трудно взломать нечто, не подключенное к сети). Автономные корневые удостоверяющие центры подключаются к сети, только чтобы выдать новые сертификаты для подписи подчиненным удостоверяющим центрам. Недостаток автономного удостоверяющего центра состоит в невозможности настроить его для автоматической выдачи сертификатов на основе групповой политики.
• Автономный подчиненный удостоверяющий центр. Автономные подчиненные удостоверяющие центры могут быть установлены на компьютерах, как присоединенных, так и не присоединенных к домену. Выдача сертификатов производится вручную. Такие удостоверяющие центры часто размещаются на периметре сети.

После того как определены особенности развертывания существующих служб сертификатов, нужно разобраться с точками распространения списков отзыва сертификатов (CRL). В зависимости от среды они могут быть внутри Active Directory (для удостоверяющего центра предприятия), сохранены на веб-сайтах или файловых ресурсах общего доступа. Если клиенты не могут установить связь с точками распространения CRL для получения сведений об отзыве, то они отвергнут сертификаты как недействительные. Далее я расскажу о миграции всех аспектов служб сертификации, в том числе важных особенностях перемещения точек распространения CRL.

Факторы, имеющие значение для миграции служб сертификации

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

Перечислим некоторые из них:

• что делать с корневым удостоверяющим центром организации;
• что делать с точками распространения CRL;
• что делать с существующими сертификатами.

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

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

Миграция корневого центра сертификации

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

Обычно при миграции рабочей нагрузки вы переходите с ServerA на ServerB. При обновлении вы заменяете программное обеспечение ServerA на новую версию. В большинстве случаев, которые рассматривались в данной серии статей, рабочие нагрузки переносились с ServerA на ServerB. Это объясняется тем, что выполнить прямое обновление Windows Server 2003 до Windows Server 2012 R2 невозможно.

Теоретически можно составить цепочку обновлений от Server 2003 до 2008, а затем до 2008 R2 и 2012 или новой версии. Но это чрезвычайно трудоемкий путь, и развертывание Windows Server 2003 выполняется, как правило, на платформе x86. Все версии, начиная с Server 2008 R2, рассчитаны на платформу x64. Невозможно выполнить обновление на месте от x86 до x64, поэтому такой путь закрыт для всех, кроме немногочисленных пользователей, развернувших Server 2003 на аппаратном обеспечении формата x64.

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

На высоком уровне для этого следует выполнить:

• резервное копирование базы данных удостоверяющего центра и закрытого ключа на корневом удостоверяющем центре 2003;
• резервное копирование параметров реестра удостоверяющего центра на корневом удостоверяющем центре 2003;
• резервное копирование CAPolicy.inf на корневом удостоверяющем центре 2003;
• удаление роли удостоверяющего центра из корневого удостоверяющего центра 2003;
• удаление корневого удостоверяющего центра 2003 из домена (при необходимости);
• построение сервера 2012 R2 с тем же именем;
• присоединение нового сервера 2012 R2 к домену (при необходимости);
• добавление роли удостоверяющего центра к серверу 2012 R2;
• восстановление базы данных и параметров удостоверяющего центра на сервере 2012 R2 (в том числе некоторых параметров реестра, при необходимости);
• настройку контейнеров AIA и CDP.

Вы можете составить более полное представление о процедуре, обратившись на сайт по адресу: technet.microsoft.com/en-us/library/ee126140%28v=ws.10%29.aspx. А я перехожу к следующему вопросу миграции с Server 2003, переносу сценариев регистрации и предпочтений групповой политики.

Сценарии регистрации и предпочтения групповой политики

Предпочтения групповой политики — одна из многих технологий, появившихся вместе с Windows Server 2008. Трудность для администраторов, все еще работающих с Windows Server 2003, но желающих перейти на Windows Server 2012 R2, заключается в том, что в 2015 году большая часть информации, которую легко собрать при поверхностном обращении в Интернет, относится к новшествам Windows Server 2012 R2. Существует несколько интересных технологий, реализованных в Windows Server 2008 и Windows Server 2008 R2, которые по-прежнему присутствуют в операционной системе, но, поскольку в них не произошло серьезных изменений за последние 7 лет, о них больше не пишут.

Сценарии регистрации доставляют массу неприятностей многим администраторам из-за тенденции со временем увеличиваться в размере. Вместо того чтобы переписывать их заново по мере изменения ситуации, администраторы предпочитают изменять их в соответствии с обстоятельствами. Мне приходилось видеть длиннейшие сценарии регистрации, предназначенные для выполнения вполне тривиальных задач. Администраторы, унаследовавшие их от своих предшественников, просто добавляли новые элементы, вместо того чтобы попытаться понять логику сценария — шаг, который необходимо выполнить перед переписыванием всего сценария с нуля.

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

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

Перечислим некоторые возможности предпочтений групповой политики, а затем разберемся с тем, как управлять этими параметрами с учетом свойств компьютера. Рекомендую первым делом взглянуть на параметры, доступные в разделе предпочтений групповой политики объекта GPO, размещенного на контроллере домена функционального уровня Windows Server 2012 R2.

С помощью предпочтений групповой политики можно выполнить следующие операции:

• установка переменных среды;
• создание, замена, обновление и удаление определенных файлов;
• создание, замена, обновление и удаление определенных папок;
• создание, замена, обновление и удаление конкретных INI-файлов;
• изменение конкретных настроек реестра;
• предпочтения групповой политики гарантируют наличие определенных общих сетевых ресурсов;
• предпочтения групповой политики гарантируют наличие определенных ярлыков;
• настройка источников данных;
• предпочтения групповой политики указывают, включены или выключены определенные устройства в зависимости от их класса;
• настройка параметров папок;
• настройка параметров Интернета;
• обеспечивается присутствие или удаление определенных локальных пользователей и групп;
• настройка сетевых параметров;
• настройка параметров электропитания;
• настройка принтеров;
• настройка региональных параметров;
• управление назначенными заданиями;
• настройка меню «Пуск».

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

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

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

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

• наличие батареи;
• имя компьютера;
• быстродействие центрального процессора;
• совпадение даты;
• пространство на диске;
• домен;
• переменная среды;
• совпадение файлов;
• диапазон IP-адресов;
• язык;
• запрос LDAP;
• диапазон MAC-адресов;
• запрос MSI;
• сетевое подключение;
• операционная система;
• организационная единица;
• наличие слота PCMCIA;
• портативный компьютер;
• режим обработки;
• оперативная память;
• совпадение реестров;
• группа безопасности;
• сайт;
• терминальный сеанс;
• временной диапазон;
• пользователь;
• запрос WMI.

Редактор нацеливания располагает графическим интерфейсом. Выбрав один из перечисленных выше элементов, вы переходите к настройке конкретных его свойств. Например, если выбран диапазон IP-адресов, то выводится диалоговое окно для ввода диапазона. Конечно, воспользоваться этим способом гораздо проще, чем помнить имя переменной и синтаксис для разнообразных элементов.

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

Альтернатива групповой политике

15 лет назад, когда групповые политики начали применяться, большинство компьютеров в компаниях неподвижно стояли на рабочих столах. Современные компьютеры — другие, отличаются, в частности, и способы, применяемые в компаниях для управления их настройками. Сегодня компьютеры чаще переносные, чем привязанные к рабочему месту, не все они работают с Windows, а среди располагающих этой операционной системой не все присоединены к домену. Современным ИТ-подразделениям приходится управлять параметрами самых разнообразных устройств. Эти устройства могут быть подключены к корпоративной сети или обращаться только к корпоративным ресурсам через подключение удаленного доступа. Для управления параметрами этих устройств, как правило, необходимо решение с возможностями, превышающими те, что обеспечиваются групповой политикой.

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

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

Теперь я расскажу о технологиях Microsoft, которые можно задействовать для управления параметрами устройств с Windows и другими операционными системами, как подключенных к корпоративной сети, так и связанных только через средства удаленного доступа.

Выше мы рассуждали о том, почему групповая политика, решение для настройки, в начале 2000?х идеальное для компаний с единственной операционной системой, развернутой преимущественно на компьютерах, привязанных к рабочему месту, вряд ли будет удачным для компании с несколькими типами мобильных компьютеров с разнообразными операционными системами в середине второго десятилетия века.

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

System Center Configuration Manager обеспечивает локальное управление настройками клиентов, а также располагает функциями для управления клиентами через Интернет. Служба Windows Intune, которая может применяться отдельно или совместно с Configuration Manager, также пригодна для управления параметрами клиентских систем на мобильных устройствах.

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

В недалекой перспективе заслуживает внимания служба настройки требуемого состояния (DSC). Пока этот инструмент на основе PowerShell находится в ранней стадии развития. Сейчас он используется для настройки серверов и, в сущности, не предназначен для управления параметрами клиентов. Однако не исключено, что позднее его функции будут расширены, и DSC превратится в полезный и надежный инструмент управления настройками клиентов. Это лишь мои предположения, но, по мере реализации заявленной цели метода DevOpsy — «настройка как кодирование», эта цель естественным образом превратится в «настройку клиентских компьютеров как кодирование».

Среди сторонних инструментов можно выделить PolicyPak Cloud (www.policypak.com), с помощью которого можно управлять присоединенными к домену, не присоединенными к домену и удаленными компьютерами с использованием большинства средств, доступных в групповой политике (в том числе административные шаблоны, настройки, параметры безопасности и параметры приложения). В будущем я напишу о PolicyPak подробнее, а сейчас вы можете получить представление о принципах работы программы по адресу: http://www.policypak.com/products/policypak-suite-cloud-edition.html. Компании, уходящие от управления компьютерами Windows XP с использованием групповой политики, размещенной на серверах с операционной системой Windows Server 2003, найдут для себя много интересного в развивающейся вычислительной среде с динамическими рабочими местами.

Теперь я коснусь вкратце вопроса управления и сделаю небольшое отступление. На мой взгляд, само по себе отсутствие локального графического интерфейса — не препятствие для удаленного управления. Одним из недостатков варианта установки Server Core администраторы серверов нередко считают сложность управления. В ответ на просьбу прокомментировать свою позицию они говорят, что открыть сеанс удаленного рабочего стола, чтобы использовать командную строку для выполнения административных задач, гораздо более трудоемкое дело, нежели открыть сеанс удаленного рабочего стола с помощью графического интерфейса.

Я согласен с тем, что одна из привлекательных сторон работы администратора сервера — возможность найти удобный для себя способ выполнения задачи. Но иногда администраторы выбирают избыточно сложные пути. Это обстоятельство привлекло к себе мое внимание после недавнего объявления о появлении в Windows Server Technical Preview варианта установки Nano Server. На момент написания статьи я не располагал полными сведениями о Nano Server и не успел воспользоваться дополнительной информацией с мероприятий BUILD и Ignite, на которых была предоставлена для испытаний новая ознакомительная техническая версия. Пока могу сообщить следующее (цитирую сообщение из журнала по адресу: http://blogs.technet.com/b/windowsserver/archive/2015/04/08/microsoft-announces-nano-server-for-modern-apps-and-cloud.aspx?WT.mc_id=Blog_ServerCloud_Announce_TTD):

«Отсутствует поддержка локальной регистрации или удаленного рабочего стола. Все управление осуществляется удаленно через WMI и PowerShell. Мы добавляем роли Windows Server и функциональные возможности с использованием компонентов Windows по требованию и системы обслуживания образов развертывания (DISM). Усовершенствованы функции удаленного управления через PowerShell благодаря службе настройки требуемого состояния, а также удаленной передачи файлов, удаленной разработки и отладки скриптов. Мы работаем над набором новых веб-инструментов управления для замены инструментов управления».

Похоже, администраторы, использующие удаленный рабочий стол для соединения с Server Core, не понимают, что лучше всего управлять Server Core удаленно (протокол RDP псевдо локален; он «переносит» вас на сервер). Одна рабочая станция управляет многими серверами — не через многочисленные сеансы удаленного рабочего стола, но с использованием сценариев, команд и консолей, таких как консоль Server Manager, подключаемая ко многим серверам. Не нужно запускать Server Manager на 100 серверах. Достаточно запустить диспетчер серверов на одном компьютере и использовать одну консоль для управления 100 серверами.

Единственная ситуация, когда локальный доступ к системе Server Core действительно необходим, — в ходе начальной установки. Благодаря новым технологиям вам не нужно (а в случае с Nano Server, похоже, и невозможно) напрямую выполнять регистрацию для настройки в процессе установки и после нее. На первый взгляд это сложно, но в действительности процесс, скорее всего, будет очень простым. Цель — добиться, чтобы потребители использовали Nano Server в ситуациях, когда это целесообразно. Но если для развертывания данной версии Windows Server потребуется такой же полет фантазии, как в произведениях современных художников, никто не захочет браться за такую задачу.

Я с нетерпением жду новых сведений о Nano Server. Очень интересно, можно ли будет довести традиционную установку до Nano Server и как можно преобразовать версию Windows Server 2012 R2 с графическим интерфейсом в Server Core (или наоборот, расширить версию, добавляя нужные компоненты по мере надобности). Но пока давайте вернемся к теме статьи и поговорим о миграции служб удаленного доступа Windows Server 2003.

Миграция удаленного доступа Server 2003

Для большинства компаний переход от Server 2003 к Server 2012 R2 мало отражается на удаленном доступе. Причина простая: большинство компаний с инфраструктурой удаленного доступа используют для удаленного доступа выделенные аппаратные средства. Сейчас удаленный доступ уже не означает коммутируемый канал связи. Это почти всегда виртуальная частная сеть (VPN). Windows Server 2003 поддерживает VPN на основе протоколов PPTP и L2 TP/IPsec, но не более новые технологии, такие как SSTP и IKEv2, или даже шлюз удаленных рабочих столов Remote Desktop Gateway.

Поэтому, обдумывая миграцию инфраструктуры удаленного доступа, в первую очередь следует задать вопрос, каким образом пользователи выполняют удаленные подключения, а затем узнать, какова роль Windows Server 2003 в этом процессе.

В большинстве случаев функция Windows Server 2003 при удаленном доступе — обеспечить проверку подлинности для аппаратного устройства, поддерживающего RADIUS. Аппаратное устройство обращается к Windows Server 2003, чтобы определить, имеет ли пользователь полномочия для работы с VPN. Если вас все устраивает, можете перейти на новый сервер с операционной системой Windows Server 2012 R2, чтобы безо всяких хлопот получить такую же услугу.

В некоторых реализациях удаленного доступа Windows Server 2003 размещается в периферийной сети, и ее внешний интерфейс приходится на завершение входящих соединений VPN. Далее мы рассмотрим шаги, которые необходимо предпринять при переходе от Windows Server 2003 как части инфраструктуры удаленного доступа к использованию Windows Server 2012 R2.

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

Если вы используете Windows Server 2003 в качестве сервера удаленного доступа, то можно принимать подключения от клиентов, работающих с протоколами PPTP и L2 TP/IPsec. Если заменить сервер удаленного доступа на Windows Server 2012 R2 и задействовать клиенты Windows 7, то можно устанавливать и соединения SSTP и IKEv2. Кроме того, есть варианты, которые нельзя назвать настоящей VPN, но пригодные для удаленного доступа, на основе DirectAccess и шлюза удаленных рабочих столов.

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

• SSTP: VPN over HTTPS. Преиму­щество этого протокола в том, что он работает через большинство брандмауэров.
• IKEv2. Этот протокол обеспечивает автоматическое восстановление соединения VPN без повторной проверки подлинности. Его преимущество — в допустимости прерываний связи длительностью до 8 часов. При использовании VPN с протоколом IKEv2 можно переключать сетевые соединения, сохраняя соединение VPN. Например, безупречно выполняется переключение с узла доступа WiFi в зале ожидания аэропорта на сотовую сеть.
• DirectAccess. Это «постоянно действующая проверка подлинности VPN IPv6». Преимущество DirectAccess в том, что удаленный доступ обеспечивается без необходимости проверки подлинности вручную. Подключение DirectAccess устанавливается сразу же, как только компьютер распознает интернет-соединение. Если вы располагаете только соединением IPv4, то формируется туннель IPv6 через IPv4.
• Шлюз удаленных рабочих столов. Это не традиционное подключение удаленного доступа. Шлюз удаленных рабочих столов может применяться для организации соединений с рабочим столом для компьютера во внутренней сети благодаря шлюзу в сети периметра.

Несмотря на все перечисленные возможности, многие компании предпочтут использовать специализированные аппаратные устройства для организации VPN-соединений. Если на Windows Server 2003 возложена функция проверки подлинности для пограничного аппаратного устройства, совместимого с протоколом RADIUS, то следует перенести роль сервера проверки подлинности в Интернете (IAS) с компьютера Server 2003 на компьютер с ролью сервера сетевых политик (NPS) и операционной системой Windows Server 2012 R2. Специалисты Microsoft представили соответствующие технические рекомендации в статье TechNet по адресу: https://technet.microsoft.com/en-au/library/hh831652.aspx.