Некоторые компании все еще не завершили развертывание Windows 2000, и у руководства нет ни времени, ни желания подумать о переходе на Windows .NET Server. Но, возможно, загруженным работой администраторам будет полезно познакомиться с преимуществами новой операционной системы: в Windows .NET Server нет таких принципиальных изменений, как в Windows 2000, но появились некоторые новшества, устраняющие недостатки Windows 2000. Полный перечень обновленных и исправленных функций Windows .NET Server велик, но основные из них, например изменения в Active Directory (AD), достаточно важны, чтобы переход на новую платформу был экономически оправданным.

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

64-разрядная Windows. Windows .NET Enterprise Server, Windows XP Professional Edition и Windows .NET Datacenter Server — первые полностью 64-разрядные операционные системы Microsoft. Особенно наглядно преимущества 64-разрядной архитектуры проявляются в поддержке и увеличении скорости работы крупных приложений, интенсивно использующих память. Адресуемая виртуальная память 32-разрядной Windows составляет 3 Гбайт, а 64-разрядная Windows обеспечивает адресацию 16 Тбайт (увеличение на 5000%). Поэтому в физической памяти 64-разрядной машины можно разместить гораздо больше данных и избежать подкачки из медленной дисковой подсистемы.

Переименование доменов. В Windows .NET Server заметно упрощена процедура переименования доменов AD, почти не выполнимая в Windows 2000 (тем не менее переименование доменов AD — рискованное мероприятие, не терпящее легкомыслия). Инструменту Domain Rename посвящен 28-страничный документ Microsoft, опубликованный по адресу: http://www.microsoft.com/windows2000/downloads/ tools/domainrename/default.asp. В этой статье описаны этапы процедуры переименования домена Windows .NET Server. Если компании необходимо менять имена доменов, то новая функциональность будет мощным стимулом для модернизации операционной системы.

Установка операционной системы с компакт-диска. Администраторы компаний, имеющих удаленные филиалы, испытывают затруднения при создании контроллера домена (DC) в небольшом офисе с медленным сетевым соединением. При преобразовании сервера Windows 2000 в контроллер домена новый DC копирует базу данных AD с другого DC — в головном офисе. Если других DC в офисе нет (частый случай в филиалах), то данные приходится копировать через каналы WAN, пропускная способность которых, как правило, ограничена. В процессе репликации производительность клиентских машин в сети может заметно снизиться.

С помощью утилиты Dcpromo операционной системы Windows .NET Server базу данных AD можно загрузить в новый DC с резервной копии снимка состояния системы (см. Экран 1). Сжатую копию системы можно записать на компакт-диск — копия размером 2 Гбайт сжимается примерно до 400 Мбайт — и разослать экспресс-почтой по локальным офисам для последующей установки на новый DC. Сотрудники офиса распаковывают сжатую копию во временной папке, восстанавливают ее с помощью утилиты Ntbackup в другой папке и импортируют данные AD на новый DC, используя команду Dcpromo /adv. Затем AD тиражирует данные с другого DC, чтобы учесть все изменения, которые произошли со времени создания копии системы.

Экран 1. Загрузка информации в новый DC с копии снимка состояния другого DC.

Функциональные уровни. Функциональные уровни — наследие собственного режима Windows 2000. Собственный режим Windows 2000 представляет собой механизм управления версиями, который обеспечивает полноценную функциональность AD во всем домене (если в домене нет контроллеров нижнего уровня, например Windows NT 4.0). Данная концепция получила развитие в функциональных уровнях и теперь распространяется не только на домен, но и на весь лес.

В Windows .NET Server реализованы два функциональных уровня: домена и леса. Функциональный уровень домена эквивалентен собственному режиму Windows 2000. Если повысить функциональный уровень домена с Windows 2000 до Windows .NET Server, то использование контроллеров нижнего уровня (Windows 2000 или более ранних версий) в домене исключается. Главный выигрыш от перевода доменов на функциональный уровень Windows .NET Server заключается в подготовке к последующему повышению функционального уровня леса.

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

Благодаря повышению функционального уровня AD увеличивается эффективность многих операций в масштабе всего леса (например, синхронизаци AD), которые будут описаны ниже. Чтобы изменить функциональный уровень, нужно обратиться к оснастке Active Directory Domains and Trusts консоли Microsoft Management Console (MMC), щелкнуть правой кнопкой мыши на Active Directory Domains and Trusts над контейнером домена и щелкнуть на кнопке Raise Forest Functionality для доступа к диалоговому окну, показанному на Экране 2.

Экран 2. Смена уровня функционирования леса.

Доверительные отношения в лесу. В качестве протокола аутентификации Windows 2000 используется Kerberos, более эффективный, чем протокол NT LAN Manager (NTLM) операционной системы NT 4.0. Но область аутентификации Kerberos в Windows 2000 ограничивается лесом. Если необходимо объединить ресурсы двух или нескольких лесов (например, рабочего и экспериментального) либо в случае, если предприятие поглощает другая компания, требуется установить доверительные отношения NTLM между всеми доменами в каждом лесу. Если лесов более двух, то структура доверительных отношений быстро становится неуправляемой, и она будет менее эффективна, чем доверительные отношения Kerberos внутри леса.

В лесах Windows .NET Server, функциональный уровень которых поднят до уровня леса, можно использовать новый тип доверительных отношений — между лесами. Доверительные отношения между лесами представляют собой одно- или двунаправленные транзитивные доверительные отношения Kerberos между корневыми доменами леса. Доверие полностью транзитивное, поэтому процедуры авторизации и аутентификации между связанными лесами прозрачны. Данная возможность Windows .NET Server особенно привлекательна, если необходимо объединить отдельные леса в федерацию лесов (организация двух или нескольких независимых лесов) или использовать один из лесов в качестве леса учетных записей (расширенный вариант домена учетных записей NT 4.0) для реализации процедуры единого входа (single sign-on, SSO) в масштабе компании.

Групповая политика Netlogon. Microsoft значительно расширила групповые политики Windows .NET Server. Особый интерес для администратора инфраструктуры представляет набор политик, размещенный в папке Administrative TemplatesSystemNet Logon. Эти политики заменяют некоторые параметры Netlogon, которые приходится настраивать в реестре каждого DC. Например, на Экране 3 показана новая политика, с помощью которой можно регулировать процесс подстраховки контроллера в удаленном офисе, — полезная функция, если нужно обеспечить отказоустойчивость DC в офисе с единственным локальным контроллером домена.

Экран 3. Одна из новых политик Windows .NET Server.

Еще одна важная особенность Windows .NET Server — исчерпывающая система подсказок, к которой можно обратиться непосредственно из выбранной оснастки, в политике Administrative Templates. К сожалению, новая информация доступна только из Administrative Templates, но не из других областей Group Policy, в которых она могла бы быть не менее полезной.

Если при запуске DC обнаруживается, что в соседнем сайте нет контроллеров домена, происходит «перекрытие» сайтов. DC регистрирует свои SRV-записи в DNS собственного сайта и сайта, не имеющего контроллера домена. В результате клиентам сайта-«сироты» кажется, что такой DC находится в их сайте, а не просто подстраховывает его. Клиенты могут пройти аутентификацию на DC, удаленном на сравнительно небольшое расстояние. По умолчанию, «перекрытие» бывает лишь на сайтах, в которых нет DC, но не в тех случаях, когда единственный DC вышел из строя.

Чтобы подстраховать DC в случае аварии, администратор должен дополнить реестр разделом, который заставит соседний DC зарегистрироваться на сайте с единственным контроллером. Но если число контроллеров доменов на предприятии велико, то конфигурирование вручную потребует много времени. С помощью этой политики в сочетании с объектом групповой политики (GPO) сайта можно сократить масштаб изменений в реестрах отдельных DC.

Нет предела совершенству

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

Кэширование членства в Universal Group. Чтобы понять, насколько это важно, нужно иметь представление о процессе проектирования филиалов в среде Windows 2000. В NT 4.0 задача упрощается благодаря локальному контроллеру домена, в котором пользователи могут зарегистрироваться, не обращаясь к обычно низкоскоростным каналам WAN. Тот же механизм действует и в Windows 2000, но глобальный каталог (Global Catalog, GC) вносит новую особенность. GC содержит все объекты леса AD, правда, лишь часть атрибутов объектов. Кроме того, универсальные группы могут размещаться в любом домене леса (их членами могут быть пользователи любого домена леса), поэтому серверы GC — единственные серверы, располагающие списком всех универсальных групп (в том числе и их членов) в лесу. Когда пользователи входят в систему, локальный DC, на который возложена задача аутентификации, не знает обо всех универсальных группах, к которой принадлежит учетная запись пользователя, так как контроллеры домена, не содержащие GC, располагают информацией только о собственном домене. Поэтому в процессе аутентификации Windows 2000 пользователи должны обратиться к серверу GC и получить список универсальных групп, к которым они принадлежат.

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

Метод кэширования членства в универсальных группах (Universal Group Membership Caching) позволяет настроить конфигурацию сайта таким образом, чтобы все его DC кэшировали информацию о членах универсальных групп. Поэтому контроллеры домена филиалов не нуждаются в собственном сервере GC и устойчивы к отказам соединений с WAN. Пользователи сайта должны установить связь с сервером GC в ходе процедуры первой регистрации. Затем DC сайта, осуществляющего аутентификацию, записывает в кэш информацию об универсальной группе пользователей. В результате сотрудникам офиса не приходится обращаться к GC в ходе следующих процедур входа. В целях безопасности через регулярные промежутки времени кэш обновляется (с выбранного администратором сайта). На Экране 4 показан активизированный режим Universal Group Membership Caching для офиса продаж в г. Фриско. Кэш сайта обновляется из главного офиса в г. Остин.

Экран 4. Кэширование информации о членах глобальной группы.

Генератор межсайтовой топологии. Intersite Topology Generator (ISTG) — важный, но малоизвестный элемент репликации AD — входит в состав Knowledge Consistency Checker (KCC), процесса AD, который определяет топологию репликации между контроллерами доменов. KCC, расположенный на каждом DC сайта, вычисляет оптимальную топологию репликации внутри сайта. В расширенном варианте данного процесса, реализованного в Windows .NET Server, один DC (именуемый сервером ISTG) в каждом сайте работает совместно с серверами ISTG других сайтов, чтобы определить оптимальную топологию репликации между сайтами.

В чем преимущества усовершенствованных функций ISTG? Если в лесу AD существует множество сайтов, то KCC системы Windows 2000 контролирует вычисления на каждом процессоре серверов ISTG, чтобы ускорить определение топологии репликации для сайтов. Например, если существует один домен и больше 1000 сайтов, то обработка ISTG может занять более 15 мин (промежуток времени для пересчета топологии), поэтому синхронизировать топологию никогда не удастся. В усовершенствованном механизме ISTG для Windows .NET Server используется алгоритм, скорость которого примерно в 200 раз выше, чем в версии Windows 2000, что позволяет быстро рассчитывать топологии для самых сложных сайтов. Более подробная информация о серверах ISTG приведена в статье Microsoft «How to Optimize Active Directory Replication in a Large Network» по адресу: http://support.microsoft.com/default.aspx?scid=kb;en-us;q244368.

Усовершенствованные функции синхронизации AD. Если компания планирует развернуть Microsoft Exchange 2000 Server или другое AD-совместимое приложение, в этом случае могут пригодиться усовершенствованные функции синхронизации AD, появившиеся в Windows .NET Server. Но сначала необходимо понять, что затрудняет синхронизацию AD в Windows 2000.

Из-за особенностей наполнения GC (все объекты и некоторые атрибуты) глобальный каталог обычно занимает значительную часть файла данных AD (\%systemroot% tds tds.dit). Если проводить репликацию всех дополнительных данных внутри леса, то полностью синхронизировать GC можно только ценой резкого увеличения интенсивности трафика AD в сетевых каналах.

В оснастке AD Schema консоли MMC, через которую можно обратиться к списку свойств атрибута, есть флажок Replicate this attribute to the Global Catalog. Он определяет наполнение GC. Собрание всех атрибутов, для которых установлен этот флажок, называется частичным набором атрибутов (Partial Attribute Set, PAS). Если администратор Windows 2000 изменяет наполнение PAS, устанавливая или сбрасывая этот флажок для любого атрибута, то все данные GC синхронизируются по всему лесу. Это крупное сетевое событие происходит при добавлении в лес почти любого AD-совместимого приложения, так как такие программы часто вводят в AD объекты, к которым нужно обеспечить доступ в масштабах всего леса. Данная функция в Windows .NET Server усовершенствована следующим образом: при изменении наполнения Windows .NET Server PAS не происходит полной синхронизации GC — в лесу тиражируется лишь изменение.

Терминальные службы. Мощные Terminal Services с выпуском Windows .NET Server тоже изменились к лучшему. В частности, появилась возможность масштабировать массивы серверов Terminal Services; на одном из терминальных серверов массива сервер Session Directory запоминает пользовательские сеансы. Кроме того, реализован параметр командной строки (/console), который можно применять на клиенте Terminal Services. С его помощью можно запустить на сервере сеанс, как это делает локальный оператор, и выполнить такие операции, как дистанционная установка программ (например, антивирусных пакетов, которые необходимо устанавливать с локальной консоли). Можно получить доступ к диалоговым окнам, выводимым только на консоль. В результате у служб Terminal Services наконец появляется полнофункциональная программа диспетчер удаленных соединений.

Экран 5. Новая оснастка Group Policy Management Console.

Консоль управления групповой политикой. The Group Policy Management Console (GPMC) — новая оснастка MMC для управления групповыми политиками всего предприятия (см. Экран 5). В состав инструмента входит набор настраиваемых интерфейсов, с помощью которых можно централизованно управлять любыми параметрами групповой политики. Чтобы устранить некоторые неудобства в работе с Group Policy в Windows 2000, в GPMC внесены следующие изменения.

  • В основу интерфейса пользователя положены методы, используемые администраторами для управления Group Policy, а не архитектура Microsoft для данной технологии.
  • Возможность создавать резервные копии, восстанавливать, импортировать и экспортировать, копировать и вставлять объекты групповой политики (GPO).
  • Сбор данных о GPO и RSoP (Resultant Set of Policies - результирующий набор политик). Пользователи Windows .NET Server (в отличие от Windows 2000), имеющие право чтения, могут задействовать GPMC для просмотра объектов GPO.
  • Подготовка сценариев обработки GPO в GPMC (с помощью сценариев изменить параметры GPO нельзя).

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

Для работы GPMC не нужна инфраструктура .NET, поэтому наличие данного инструмента нельзя считать стимулом для перехода на Windows .NET Server. Microsoft выпустит бесплатный инструмент GPMC вскоре после Windows .NET Server, как отдельный продукт со своим циклом подготовки. Утилита совместима с инфраструктурами Windows 2000 и .NET, но на клиенте должен быть установлен пакет XP Service Pack 1 (SP1) или Windows .NET Server.

Новшества в Windows .NET Server не ограничиваются усовершенствованиями, о которых рассказано в данной статье. Заслуживают внимания и такие функции, как RSoP, новый инструментарий командной строки, деактивация классов объектов и атрибутов в схеме, репликация изменений в универсальной группе и режимы запуска приложений. Windows .NET Server считается промежуточной версией, но благодаря простоте модернизации и многочисленным новшествам операционная система заслуживает самого пристального внимания.

Шон Дьюби — старший системный инженер компании Intel. Занимается вопросами использования Windows 2000 и NT Server в крупномасштабных проектах. Автор книги «Windows 2000 Server: Planning and Migration». С ним можно связаться по адресу: spdeuby@mail.com.