Только мы успели разобраться с Windows 2000, а в Microsoft уже кипит работа над очередной версией Windows – Windows .NET Server (Whistler). Не беспокойтесь, Windows Server отличается от Windows 2000 Server значительно меньше, чем Windows 2000 Server от своего предшественника. Пожалуй, Windows .NET Server следует рассматривать как Windows 2000 1.1, в таком случае у нас имеются все основания, чтобы с нетерпением ожидать появления этого нового продукта.

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

Никаких ограничений в численности групп

Известно, что в AD Windows 2000 нельзя иметь группу, состоящую более чем из 5000 членов, при обычных обстоятельствах. Я сказал “при обычных обстоятельствах”, поскольку слышал (но не могу привести тому доказательств), что этот предел можно значительно расширить, если контроллеры доменов (DC) в сети имеют огромную оперативную память и очень мощные процессоры. Windows .NET Server, по-видимому, практически не будет иметь ограничений на число членов в группе.

Выборочная репликация

Репликация через множество доменов, имеющая место в AD, есть более гибкая возможность, нежели однодоменная репликация в Windows NT. Поскольку порцию новой информации (например, новую пользовательскую учетную запись или измененный пароль) может получить любой DC, Windows 2000 нужно указывать путь к этой информации так, чтобы независимо от того, какой именно DC получает новые данные, все остальные DC получали бы соответствующие копии. Windows 2000 имеет в своем составе достаточно много средств, которые делают возможной репликацию AD, и, кроме AD, пользу из работы средств репликации могут извлекать и другие службы.

Например, можно превратить зоны DNS в то, что в Microsoft называют зонами, интегрированными с AD (AD-integrated zones). Значение таких зон состоит в том, что изменения в DNS, которые во всех близких к стандартной конфигурациях DNS-серверов затрагивают единственный сервер на планете, теперь становятся многодоменными, то есть изменения одной зоны может получить не один сервер DNS. Серверы DNS, включенные в зоны, интегрированные с AD, решают проблему использования однодоменных продуктов для организации работы многодоменной репликации за счет механизмов репликации AD. Такое решение требует от AD сохранять целостность данных во время их перемещения.

В то же время ясно, что добавление DNS-информации в AD увеличивает количество данных, которые AD должна перемещать по сети. Вдобавок, ввиду того, что AD реплицирует данные своего домена на каждый DC в домене, каждый DC, даже если это не DNS-сервер, получает копию информации из DNS-зоны, при условии, что она является зоной, интегрированной с AD. Так, если у вас имеется 1000 DC, и только 150 из них являются серверами DNS, скорее всего, вы пожелаете иметь возможность выполнять репликацию DNS-зоны только на те 150 DC, которые являются серверами DNS. Другими словами, желательно иметь возможность частично сужать репликацию.

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

Однако рано радоваться: хоть я и привел в пример данные зоны DNS, показывая, что AD будет иметь возможность применять частичную репликацию, собственный контекст именования у DNS в Windows .NET Server, видимо, не появится. Но я убежден, что рано или поздно разработчики Microsoft захотят придать DNS собственный контекст именования.

Создание контроллера домена из резервной копии AD

Пользователи NT вечно сталкивались с трудностями при работе с инструментами многократного копирования. Например, вряд ли кто-то станет переносить образ Windows 2000 Professional или рабочей станции NT на тысячи других систем простым копированием, поскольку такое действие многократно воспроизводит SID, что в свою очередь может вызвать большие проблемы. Но, к счастью администраторов Windows 2000 и NT, специалисты Microsoft создали такой инструмент как утилита Windows 2000 Sysprep, и теперь, используя Ghost от Semantec, Drive Image Pro от PowerQuest или им подобные инструменты можно делать копии образов так же легко, как печь блины. И одними рабочими станциями дело не ограничивается – можно создавать и отражения серверов, правда, до тех пор, пока серверы не окажутся DC.

Резервные контроллеры домена (BDC) все еще доставляют немало хлопот (в Windows 2000 мы не называем второй или последующие DC “резервными контроллерами доменов ” – просто DC). Во время бета-тестирования Windows 2000 разработчики Microsoft называли такие DC реплицированными DC (replica DC), поскольку теоретически все DC в Windows 2000 равны. Но первый DC в домене обычно особенный, поскольку он выполняет несколько важных функций, называемых ролями мастера операций (Operation Master role). Если вы утратите этот DC, не переместив роли, могут возникнуть проблемы. К тому моменту, когда Windows 2000 появилась на рынке, термин «реплицированный DC» исчез. Но все еще требуется некий термин для обозначения “контроллера домена, который не содержит ролей мастера операций”. Пока такой термин не появится, я продолжу использовать понятие BDC. Наподобие NT 4.0 и NT 3.x, Windows 2000 для создания BDC требует режима установленного сетевого соединения с другим DC.

Это требование может заметно усложнить работу. Представьте, что вы администратор, которому нужно поехать в офис в Тмутаракань, чтобы настроить там локальный DC, а качество связи между тем офисом и вашим постоянным местом работы не превосходит скорости модема на 56 Кбит/с. В процессе создания нового DC с помощью утилиты Dcpromo эта утилита будет требовать постоянной связи с другим DC и выполнять репликацию базы данных AD в полном объеме через соединение со скоростью 56 Кбит/с. Подобная ситуация – прекрасный повод поработать сверхурочно, но ведь это не смешно.

В таком случае можно использовать несколько решений. Можно, например, создать новый контроллер домена в центральном офисе и выполнить первичную репликацию по локальной сети. Затем отвезти DC в Тмутаракань, включить, и пусть он время от времени соединяется с центральной машиной для репликации изменений AD вместо репликации всей базы данных домена. Но иногда такой подход неприменим – в Тмутаракани заплатили за компьютер и по каким-то неясным причинам не хотят везти его в центральный офис. Ну что ж, ничего не поделаешь, придется сидеть и ждать, когда закончится репликация по модему на 56 Кбит/с. Можете пока поиграть во FreeCell.

В Windows .NET Server новому BDC для подключения к другому контроллеру домена и репликации AD достаточно резервной копии AD. Я еще не видел пользовательского интерфейса этой функции, поэтому не могу описать подробностей решения задачи в Windows .NET Server. Но в Microsoft мне сказали, что пользователь сможет загружать резервную копию AD с CD-ROM, Zip-диска, или магнитной ленты. Возможно, копия AD на новом DC будет слегка устаревшей. Но такая версия AD не вызовет проблем: стоит только новому DC заработать, как он сможет соединиться с DC, имеющим самые новые данные, и выполнить репликацию только произведенных к данному моменту изменений, максимально обновляя копию AD.

Глобальный Каталог

Глобальный каталог (Global Catalog – GC) это подмножество данных AD, собранных со всех доменов леса. Он содержит немного информации о каждом пользователе. Одно из основных преимуществ GC состоит в упрощении процесса доступа в многодоменном лесу. Если у вас имеется лес с двумя или более доменами, то в рамках Windows 2000 вы не сможете включить компьютер, который “потерял” сервер GC. Работа в удаленном офисе, не имеющем сервера GC, может означать, что вы даже не сможете подключиться с рабочей станции Windows 2000 Pro, если удаленный офис временно утратил связь с GC-сервером другого офиса.

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

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

Предположим, например, что каждый домен AD содержит 100 порций информации о каждом пользователе, но GC для репликации нужны только 10 из них. Затем вы, или, что более вероятно, некая программа установки, добавляет в GC еще один элемент. В Windows 2000 сервер GC свяжется с контроллерами доменов по всему лесу и запросит репликацию всех 11 элементов. То есть сервер GC успешно забывает все, что он знает об имеющихся 10 элементах.

Иначе обстоит дело в Windows .NET Server: сервер GC сделает запрос только на новый элемент. Однако сначала вам придется с помощью ключа реестра перевести лес в режим Whistler Forest Mode, что соответствует факту модернизации всех DC до Windows .NET Server. Режим Whistler Forest Mode можно сравнить с естественным режимом в Windows 2000.

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

Марк Минаси - редактор Windows NT Magazine, имеет сертификат MCSE; является автором книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com.