В одной из предыдущих статей я делилась опытом тестирования смешанной среды Windows 2000 и Windows NT 4.0. [«Могут ли сосуществовать Windows 2000 и Windows NT 4.0?», журнал Windows 2000 Magazine/RE, №5(8) 2000 - прим. ред.] Напомню, что я была приятно удивлена слаженной совместной работой двух технологий. В этой статье я хочу рассмотреть некоторые причины, побуждающие администратора к миграции, а также показать основные различия в использовании этих платформ.
Зачем переходить на Windows 2000?
Существует три причины, побуждающие нас вводить в сеть компьютеры с ОС Windows 2000. Первая - и самая очевидная - состоит в том, что в этой среде проще разворачивать структуру распределенного предприятия, для которого не существует ни политических, ни культурных, ни языковых границ. Реализованная в Windows 2000 гибкая и расширяемая служба каталогов Active Directory (AD) в сочетании с организационными единицами (organizational units, OU), а также возможность делегирования административных по всей сети позволяют снять большую часть ограничений, свойственных одноранговой модели Windows NT 4.0.
Второй аргумент в пользу перехода на Windows 2000 - это более надежные средства сетевой защиты. Усовершенствования механизмов безопасности коснулись всех компонентов систе-мы - достаточно упомянуть хотя бы о сложной объектной модели безопасности службы AD. Windows 2000 позволяет администраторам назначать права с большей степенью детализации, что достигается с помощью групповых политик безопасности, дополнительных параметров защиты для файлов и каталогов, шифрования файлов по запросу, использования протокола IPSec для соединений с локальной или удаленной сетью, собственной системы работы с сертификатами и других средств.
Наконец, третья причина - нужно избавляться от компьютеров, работающих под Windows 9x. Различия между Windows 2000 Professional и Windows 9x очень велики, особенно в том, что касается набора функциональных возможностей, надежности и устойчивости. Систему Windows 2000 Pro отличают значительно усовершенствованные процедуры установки и конфигурирования, возможность создавать новые установочные комплекты, включающие последнюю версию пакета исправлений (slipstream installation) и множество собственных средств диагностики. Ну, а если говорить об удобстве использования, надо отметить, что интерфейс Windows 2000 хорошо знаком пользователям Windows.
Варианты перехода
Существует три сценария перехода к системе Windows 2000 (см. Рисунок 1). Можно создать «чистый» домен Windows 2000, который будет обслуживать работающие под управлением этой ОС настольные системы и серверы. Когда пользователям нового домена понадобится обратиться к ресурсам существующего домена NT 4.0, можно без особых хлопот установить доверительные отношения для выполнения междоменной аутентификации учетных записей. При таком подходе новая технология изолируется от старой и отпадает необходимость в параллельном управлении механизмами, по-разному реализованными в двух платформах - такими, как профили пользователей, системные и групповые политики. Соответственно, значительно сокращается объем работ.
 |
| Рисунок 1. Варианты сосуществования двух ОС. |
Но есть и другой путь: создать гибридный домен Windows 2000, в котором будут представлены контроллеры доменов (domain controllers, DCs), настольные системы и серверы на базе как Windows 2000, так и NT 4.0. В этом случае переход на новую ОС начинается, как правило, с модернизации существующего основного контроллера домена NT 4.0 до уровня контроллера домена Windows 2000. С моей точки зрения, это самый неудачный вариант. Дело в том, что модернизацию упомянутого контроллера домена приходится осуществлять на ходу, при этом работа сети может быть нарушена. Переход к системе Windows 2000 через гибридный домен Windows 2000 сопряжен с рядом сложностей, возникающих на этапе преобразования учетных записей и групп Windows NT 4.0 в формат AD и трансформации алгоритмов управления системами в эквивалентные групповые политики. К тому же в этом случае могут возникать проблемы, связанные с синхронизацией контроллеров доменов разных платформ и тиражированием файлов (так, в Windows 2000 не предусмотрена репликация файлов средствами NT LAN Manager, NTLM). Начинать миграцию с гибридного домена Windows 2000 - значит взваливать на себя такие задачи, как изучение и использование на практике особенностей реализации профилей пользователей в Windows 2000 и NT 4.0, а также выявление тех функций Windows 2000 Group Policy, которые применяются и не применяются к клиентам.
Наконец, третий вариант перехода на новую ОС предполагает использование гибридного домена Windows NT 4.0. Чтобы создать такой домен, нужно к существующей сети добавить настольные системы Windows 2000 и автономные серверы Windows 2000. Этот сценарий позволяет в полной мере задействовать новые возможности настольных систем Windows 2000 и автономных серверов Windows 2000 (в последнем случае можно говорить о значительных изменениях - достаточно упомянуть средства RRAS, CA и IPSec). В отличие от первых двух вариантов перехода, миграция через гибридный домен NT 4.0 не разрушает существующую инфраструктуру и почти не требует обучения персонала. Это простой метод внедрения новой технологии, связанный с минимальным риском. Однако при использовании такого сценария миграции, как и в случае с гибридным доменом Windows 2000, придется учитывать различия в поддержке настольных систем. Кроме того, предстоит определить, какие компоненты системы управления на базе NT 4.0 можно использовать применительно к системам Windows 2000, а какие нет.
Межплатформенные различия
Независимо от того, какой метод перехода к Windows 2000 выбран, следует тщательно изучить различия между двумя платформами. При выполнении таких операций, как установка, конфигурирование, формирование профилей пользователей, системных политик, а также публикация и поиск разделяемых ресурсов, эти различия придется учитывать - как на этапе планирования, так и в процессе администрирования.
Перед тем как углубиться в технические детали, мне хотелось бы сделать несколько важных замечаний. Чтобы две ОС могли мирно сосуществовать, следует использовать пакет исправлений для NT 4.0 только начиная с пятой версии. Но даже Service Pack 5 (SP5) - это не оптимальное решение. Гораздо лучше использовать SP6a с соответствующими модулями оперативных исправлений (hotfixes). В системе Windows 2000 нужно начинать с SP1 плюс необходимые модули из 75 вышедших впоследствии оперативных исправлений, позволяющих устранять проблемы совместимости. Планируя процесс миграции, следует помнить о том, что NT 4.0 не оснащается службой AD, не выполняет аутентификации по протоколу Kerberos, не совместима с динамической службой DNS (DDNS) и не обеспечивает синхронизацию времени по протоколу Network Time Protocol (NTP). В системе Windows 2000, скорее всего, понадобятся обновленные версии драйверов для видео- и звуковых плат. Нужно иметь в виду, что механизм plug-and-play (PnP) иногда дает сбой, устройства и драйверы USB тоже могут создавать неожиданные проблемы, от которых порой просто опускаются руки, а ошибки в Internet Explorer (IE) приводят к нарушениям правил доступа.
Службы WINS, DNS и DDNS системы Windows 2000. При использовании службы DNS на NT 4.0 в системах Windows 2000 придется вводить полные адреса для серверов DNS и WINS (не забывайте при этом о суффиксах DNS: скажем, win2000mag.com). Иначе Windows 2000 не сможет обнаружить контроллер домена NT 4.0. Соответственно если нет сервера WINS, который зарегистрировал бы имя системы Windows 2000, то компьютеры с этой ОС в списке просмотра не появятся.
При установке автономных серверов Windows 2000 в домене NT 4.0 необходимо убедиться в том, что каждая система имеет корректный DNS-суффикс. В противном случае она не сможет обеспечить разрешение имен и будет не в состоянии отыскать контроллер домена NT 4.0 по расширению.
В программе инсталляции ОС Windows 2000 не предусмотрено автоматическое формирование DNS-суффикса при установке автономного сервера Windows 2000. При желании и впредь использовать службы DNS и WINS на базе NT 4.0 следует иметь в виду, что в процессе установки Windows 2000 Advanced Server локальные службы DNS и WINS устанавливаются по умолчанию. Если автономные серверы будут взаимодействовать с прежними системами, следует убрать флажки установки этих служб в Windows 2000.
В процессе модернизации системы Windows NT 4.0 до уровня Windows 2000 может возникнуть проблема в разделе Adapters файла setup.inf. В результате программа установки отменит статические параметры TCP/IP и преобразует систему в клиента DHCP. Чтобы отменить статус клиента DHCP для системы и присвоить ей статический адрес TCP/IP, нужно завершить процесс установки и после перезапуска системы сменить адрес. Если попытаться заменить динамический адрес статическим в ходе установки, программа установки может зависнуть. После окончательной инициализации системы следует убедиться, что результат - наличие статического или динамического адреса - соответствует ожидаемому. Для этого нужно проверить конфигурацию TCP/IP.
Динамическая регистрация имен по умолчанию обеспечивается всеми версиями Windows 2000, тогда как в DNS-серверах NT 4.0 такая регистрация имен не предусмотрена. Чтобы избежать лавины сообщений об ошибках DNS-сервера NT 4.0, нужно отключить функцию динамической регистрации имен, сбросив флажок Register this connection`s addresses in DNS на вкладке DNS окна Advanced TCP/IP Settings для сетевого адаптера, как показано на Экране 1. Эту функцию можно отключить как в процессе установки Windows 2000, так и после запуска и регистрации системы в сети.
 |
| Экран 1. Отключение динамической регистрации. |
Изменение имени компьютера Windows 2000. Важно помнить, что в процессе перехода от Windows NT 4.0 к Windows 2000 изменить имя системы невозможно. Если все-таки это сделать нужно, следует модернизировать машину NT 4.0 до уровня автономного сервера Windows 2000, изменить имя после завершения установки и присвоить системе статус контроллера домена Windows 2000. Чтобы изменить имя после того, как система установлена и выполняет роль контроллера домена Windows 2000, нужно освободить ее от этого нового статуса с помощью утилиты Dcpromo, изменить ее имя и вновь запустить Dcpromo, чтобы вернуть системе статус контроллера домена.
Кстати, возможность изменения имени сервера Windows 2000, на котором устанавливается система раздачи сертификатов (CA), не предусмотрена. При предоставлении сертификатов с системы, на которой выполняется служба CA, и при дальнейшей необходимости изменить имя этой системы придется экспортировать и импортировать все сертификаты, созданные до изменения имени компьютера с CA. Чтобы не тратить время на эту титаническую работу, а также избежать случайного удаления сертификатов, позаботьтесь о том, чтобы имя сервера не изменялось в течение длительного времени после установки службы CA.
Проблемы регистрации систем Windows 2000
Чтобы обеспечить успешную регистрацию системы Windows 2000 в домене Windows NT 4.0, необходимо с помощью модуля Server Manager в NT 4.0 создать учетные записи компьютеров для всех новых систем Windows 2000. Учетную запись компьютера можно создавать до установки Windows 2000 или в процессе установки, имея привилегии администратора. Windows 2000 сможет обнаружить контроллер домена NT 4.0 лишь в том случае, если в системе установлен компонент Client for Microsoft Networks (по умолчанию). Этот компонент обеспечивает разрешение имен NetBIOS в системе Windows 2000, а без использования NetBIOS Windows 2000 не в состоянии обнаруживать унаследованные от старой системы разделяемые ресурсы. Если предполагается, что клиенты Windows 2000 будут регистрироваться и в домене Windows 2000, а этот домен имеет особый адрес DNS, необходимо выставить флажок, обеспечивающий изменение DNS-суффикса системы Windows 2000 при изменении имени домена. Для этого нужно выбрать пункт Properties во вкладке Network Identification свойств системы и щелкнуть на кнопке More.
Некоторые ограничения, связанные с регистрацией в системе Windows NT 4.0, могут помешать пользователям обращаться к разделяемым ресурсам Windows 2000. Предположим, что у нас имеется старая сеть NT 4.0 и главный контроллер домена NT 4.0, а пользователи обращаются к разделяемым ресурсам, размещенным на серверах Windows 2000. В домене NT 4.0 нужно указать время, в течение которого пользователи могут регистрироваться в системе, и активизировать функцию Forcibly disconnect remote users from server when logon hours expire. Однако теперь пользователи, не имеющие привилегий администратора и регистрирующиеся в системах NT 4.0 в установленное время, не смогут получить доступ к разделяемым ресурсам систем Windows 2000. Чтобы это стало возможным, потребуется получить новую версию файла srv.sys в Microsoft Support.
Локальная регистрация в системе Windows 2000
При попытке зарегистрироваться в домене Windows 2000 или NT 4.0 с системы Windows 2000, компьютер может не обнаружить контроллер домена, и Windows 2000 выполнит регистрацию на локальной машине, используя при этом кэшированные имя пользователя и пароль. Такая регистрация с применением кэшированных данных возможна еще при подключении по коммутируемым линиям средствами служб RAS или RRAS, а также при соединении по VPN. А ведь когда пользователь регистрируется на локальной системе, он не считается членом домена и не может обращаться к сценариям регистрации, системным политикам, перемещаемым профилям и даже к своему домашнему каталогу. Иными словами, такой пользователь оказывается в непривычной среде и не имеет доступа к сети.
Но и это еще не все. Система Windows 2000 не информирует пользователя о том, что зарегистрировала его на основе кэшированных данных. Если после такой регистрации выйти из системы и посмотреть на экран регистрации, то вместо имени локальной системы там будет имя домена, куда, собственно, и хотел попасть пользователь. Единственная возможность определить тип регистрации, выполненной системой Windows 2000, состоит в том, чтобы исследовать переменную окружения LOGONSERVER. Чтобы вызвать эту переменную, нужно ввести в командной строке:
echo %logonserver%
Если LOGONSERVER указывает на имя компьютера, значит, регистрация производилась на основе кэшированных данных; если же эта переменная указывает на имя контроллера домена, то в домене.
К сожалению, изменить такую реакцию системы нельзя, однако можно сделать так, чтобы при регистрации с кэшированными данными на экран выводилось соответствующее сообщение. Для этого в каждой системе, где требуется такое предупреждение, следует внести в реестр два изменения. Одно будет касаться конфигурации локальной системы, а другое - каждого пользователя, для которого необходимо выводить на экран сообщение: «logged on with cached credentials.»
Запустите редактор реестра и выберите раздел HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionWinlogon. Затем нужно добавить в него параметр Re-portControllerMissing типа REG_SZ и присвоить ему значение TRUE (будьте внимательны: слово TRUE должно быть напечатано прописными буквами). Чтобы внести в реестр изменение, касающееся конкретного пользователя, следует выбрать раздел HKEY_CURRENT_USERSOFTWAREMicrosoft WindowsNTCurrentVersionWinlogon, добавить параметр ReportDC типа REG_DWORD и установить его значение равным 1. Для первой записи Winlogon вводится строковое значение, а для второй, касающейся конкретного пользователя, цифровое.
Синхронизация времени в системе Windows 2000
Вскоре после установки системы Windows 2000 в домене NT 4.0 обнаружится, что в журнале регистрации системных событий Windows 2000 постоянно появляются предупреждения с упоминанием W32Time и Event ID 64. Кроме того, будет выведено следующее сообщение: «Because of repeated network problems, the time service has not been able to find a domain controller to synchronize with for a long time.» Чтобы определить точное время, каждая система Windows 2000 обращается к контроллеру домена Windows 2000. И приведенное выше сообщение появляется на экране всякий раз, когда сервер времени не обнаружен или источник времени недоступен.
Проблема поддержки службы времени для системы Windows 2000 в домене NT 4.0 решается несколькими способами. Можно сконфигурировать оснащенный средствами NTP маршрутизатор таким образом, чтобы он указывал время из внешнего источника, а все системы Windows 2000 - так, чтобы они адресовали запросы на получение времени именно этому маршрутизатору. Можно также установить в локальной сети собственный сервер времени на базе протокола NTP (о том, как установить NTP-сервер времени NT 4.0, речь пойдет ниже). Или же можно сконфигурировать каждую систему Windows 2000 таким образом, чтобы она синхронизировала время с внешним источником времени независимо. При наличии внешнего источника времени нужно сделать так, чтобы ОС обращалась за временем к указанному источнику времени NTP, и для этого ввести с консоли Windows 2000 следующие команды:
net time /settsntp: | net time /querysntp w32tm /s
Эти три команды позволяют, соответственно, задать источник времени NTP, вывести источник времени NTP и синхронизировать время после того, как источник времени указан.
Дополнительную информацию о службе времени в Windows 2000 можно найти в статье Тао Чжоу «Windows 2000 и Windows NT: сравнение методов временной синхронизации», опубликованной в электронном приложении «Профессионалам Windows NT/2000», №02/2000 по адресу: http://www.osp.ru/win2000/worknt/ 2000/02/002.htm.
Переустановка службы времени Windows 2000
При переводе системы Windows 2000 из домена Windows NT 4.0 в домен Windows 2000 система не будет синхронизировать данные с контроллером домена Windows 2000 до тех пор, пока служба времени не будет переведена в принятый по умолчанию режим функционирования. Рабочие параметры службы W32Time хранятся в разделе реестра HKEY_LOCAL_MACHINESYSTEM CurrentControlSet ServicesW32TimeParameters (см. Экран 2). Более подробная информация обо всех элементах реестра, касающихся службы W32Time, содержится в статье Microsoft Q223184 «Registry Entries for the W32Time Service» - http://support.microsoft.com/support/ kb/articles/Q223/1/84.asp. Когда администратор вручную определяет источник времени NTP, служба времени добавляет в реестр параметр Ntpserver типа REG_SZ со значением либо (если источник времени определен по имени), либо (если источник времени определен по адресу). Кроме того, служба времени изменяет вторую запись, Type, типа REG_SZ и значение NTP.
 |
| Экран 2. Параметры реестра для службы W32Time. |
Чтобы перевести Windows 2000 в режим, принятый по умолчанию, нужно удалить параметр Ntpserver, поменять значение параметра Type на nt5DS и заново выполнить синхронизацию службы времени в домене Windows 2000, дабы убедиться в том, что внесенные в реестр изменения не содержат ошибок. Можно установить, с какой частотой служба времени должна выполнять синхронизацию; для этого нужно ввести параметр Period типа REG_DWORD и присвоить ему одно из значений, указанных в статье Microsoft Q223184. Интервалы могут быть такими: раз в два дня, раз в три дня, раз в неделю или каждые 45 мин до тех пор, пока три попытки не дадут точного совпадения, после чего синхронизация будет осуществляться один или три раза в день. Кроме того, значение интервала можно устанавливать таким образом, чтобы синхронизация выполнялась определенное число раз в течение каждого 24-часового цикла.
Установка NTP-сервера времени NT 4.0
Установив утилиту w32time.exe из комплекта Windows NT 4.0 Server Resource Kit, можно превратить одну из систем NT 4.0 в сервер времени NTP. Затем системы Windows 2000 можно легко настроить таким образом, чтобы они «сверяли свои часы» с NTP-сервером времени NT 4.0. Чтобы это сделать, требуется загрузить обновленную версию утилиты w32time.exe с FTP-узла Microsoft (ftp://ftp.microsoft.com/reskit/y2kfix/x86/w32time). Дело в том, что в версию утилиты, представленную в Resource Kit, не включены расширения, без которых служба W32Time не сможет обеспечить функционирование сервера времени NTP.
Чтобы точно настроить службу W32Time в NT 4.0, необходимо модифицировать файл w32time.ini. Для этого нужно открыть его в текстовом редакторе и установить значение LocalNTP=yes, а затем отключить службу времени NT 4.0, дать ей команду считать .in-файл и запустить ее вновь. Для выполнения этих операций введите следующие команды:
net stop w32time w32time - update net start w32time
NetBIOS в Windows 2000 и совместное использование файлов
Windows NT 4.0 публикует и отыскивает разделяемые ресурсы по имени NetBIOS каждого из них. Разработчики Windows 2000, в частности, стремились устранить зависимость пользователей от протокола NetBIOS. Поэтому для создания разделяемых ресурсов и для подключения к ним в Windows 2000 используется протокол Server Message Block (SMB). В домене Windows 2000 можно просто отключить протокол NetBIOS, и это не вызовет никаких отрицательных последствий. В сущности, деактивация NetBIOS приводит к снижению сетевого трафика, поскольку в этом случае пакеты регистрации имен NetBIOS и пакеты разрешения имен уже не передаются.
Однако в тех случаях, когда нужно, чтобы компьютер с установленной на нем Windows 2000 имел доступ к ресурсам сети или чтобы унаследованные системы, такие, как NT 4.0 или Win9x, имели доступ к разделяемым ресурсам Windows 2000, приходится устанавливать протокол NetBIOS и привязывать его к сетевому адаптеру. В общем, использование протокола NetBIOS не должно вызывать проблем, если только не изменены принимаемые по умолчанию установки Windows 2000. Напомню, что эта ОС устанавливает компонент Client for Microsoft Networks по умолчанию (как показано на Экране 3) и привязывает его ко всем сетевым адаптерам. Но когда речь идет о системе Windows 2000 с несколькими сетевыми платами, имеющей соединение с Internet, нужно заблокировать широковещательную передачу имен NetBIOS по межсетевым каналам. А для этого необходимо отменить привязки компонентов Client for Microsoft Networks и File and Print sharing.
 |
| Экран 3. Привязки, подлежащие отключению. |
Завершая этот раздел, я хотела бы сказать несколько слов об организации защиты томов и разделяемых ресурсов в системе Windows 2000. Как и в NT 4.0, доступ к томам и вновь определяемым общим ресурсам по умолчанию устанавливается как Everyone: Full Control. Чтобы обеспечить базовый уровень безопасности, администратор должен ввести соответствующие параметры доступа.
Управление профилями пользователей в неоднородных доменах
Как известно, при новой установке Windows 2000 система кэширует локальные профили под соответствующими именами в папке Documents and Settings. Но наверняка не все знают, что при переходе с NT 4.0 на Windows 2000 система сохраняет существующий каталог профилей в системном каталоге. Таким образом, может случиться, что профили будут сохранены в двух разных местах, в зависимости от того, совершается ли переход от NT 4.0 к Windows 2000 или просто устанавливается Windows 2000.
Администратор может изменить место хранения профилей пользователей Windows 2000 по умолчанию в процессе установки ОС, если установка выполняется в автоматическом режиме. При установке Windows 2000 с использованием команды
winnt / unattend
или
winnt32.exe / unattend
программа инсталляции ищет данные о конфигурации Windows 2000 в файле unattend.txt. Если вместо папки Documents and Settings используется другой адрес, следует дополнить файл unattend.txt следующим разделом:
[GuiUNattended] ProfilesDir = z:foldername
В статье Microsoft «Cannot Move or Rename the Docu-ments and Settings Folder» (http://support.microsoft.com/support/ kb/articles/Q236/6/21.asp) документируются две дополнительные процедуры, с помощью которых можно переместить индивидуальный профиль или весь каталог Documents and Settings.
Дублированные профили. В NT 4.0 и Windows 2000 проблема дублированных профилей решается по-разному. Так, в NT 4.0 к первому дублированному локальному профилю добавляется численный суффикс .000. Когда в системе регистрируется еще один пользователь с именем, для которого уже сформирован профиль, NT 4.0 увеличивает численный суффикс на единицу. Если же пользователь с дублированным профилем регистрируется в среде Windows 2000, добавляемый к профилю суффикс представляет собой либо имя компьютера, если пользователь зарегистрировался в локальной системе, либо имя домена, если он зарегистрировался в домене. В случае возникновения третьего конфликта Windows 2000 добавляет к профилю цифровой суффикс, который функционально идентичен суффиксу NT 4.0: он тоже сначала имеет вид .000 и далее каждый раз увеличивается на единицу. На Экране 4 показано, как Win-dows 2000 кэширует локальные профили в случаях, когда пользователь регистрируется с одним и тем же именем на локальной рабочей станции и в других доменах. Это различие нужно иметь в виду, когда приходится удалять локальную копию пользовательского профиля Windows 2000: непременно проверьте домен пользователя, иначе можно ненароком удалить не тот профиль.
 |
| Экран 4. Кэширование локальных профелей. |
Обновление профилей. При добавлении нового пользователя в среде Windows 2000 или NT 4.0 администратор обычно определяет ресурс совместного доступа, где расположен каталог с перемещаемым профилем пользователя. Если в сети имеются системы Windows 2000 и машины NT 4.0, каталоги профилей можно хранить как на тех, так и на других. Но важно помнить об одном обстоятельстве: для успешного обновления профиля в каждой среде требуется принять свои меры безопасности. Когда профиль обновляется в среде Windows 2000, пользователю требуется разрешение Full Control на совместный ресурс, а если та же операция выполняется в среде NT 4.0, необходимо всего лишь разрешение Change.
Если не расширить полномочия пользователя на совместно используемый каталог с профилями до уровня Full Control, NT 4.0 успешно обновит профиль. Однако, если то же лицо зарегистрируется на рабочей станции Windows 2000 и затем выйдет из системы, процедура обновления профиля Windows 2000 будет прервана, и на экране появится сообщение об ошибке: «Windows cannot update your roaming profile. Contact your network administrator. Detaile - Access is denied.» Поэтому при хранении профиля в системе Windows 2000 пользователю следует предоставить права доступа List Folder Contents, Read and Write.
Удаление профилей. Еще одно важное различие в управлении профилями связано с их удалением. При удалении локального профиля в среде NT 4.0 фактически удаляются только установки реестра, определяющие среду компьютера и рабочего стола пользователя. Но если экземпляр локального пользовательского профиля удаляется в Windows 2000, удаляется и весь каталог пользователя в папке Documents and Settings, а сюда входят все файлы, папки и ярлыки, хранящиеся вместе с профилем. Другими словами, если не сохранить файлы в другой папке, то в процессе удаления локального профиля можно потерять пользовательские документы и файлы данных.
Системная политика и групповая политика
«Генеральную линию» в отношении групповой политики Windows 2000 и системной политики NT 4.0, куда могут входить наборы правил для ком-пьютеров и пользователей, можно сформулировать следующим образом: системы Windows 2000 и NT 4.0 применяют политику, заданную в том домене, в котором создана соответствующая учетная запись. В самом простом случае, если компьютер и учетная запись пользователя принадлежат домену NT 4.0, клиенты, функционирующие под управлением любой из двух ОС, используют для компьютера и пользователя те параметры, которые зафиксированы в файле системной политики NT 4.0, именуемом ntconfig.pol. Когда же учетные записи компьютера и пользователя принадлежат домену Windows 2000, в отношении компьютера и пользователя применяются соответствующие установки групповой политики. Если же учетная запись компьютера зарегистрирована в домене NT 4.0, а учетная запись пользователя - в домене Windows 2000, то для компьютера действуют правила из файла ntconfig.pol, а для пользователя - из групповой политики Windows 2000. В обратной ситуации, когда учетная запись компьютера зарегистрирована в домене Windows 2000, а пользователь - в домене NT 4.0, параметры компьютера используются из групповой политики Windows 2000, и параметры пользователя - из системной политики NT 4.0.
Многим наверняка приходилось сталкиваться с такой ситуацией: определив системную политику и войдя в систему, к которой эта политика должна применяться, обнаруживаешь, что политика попросту не загружается. По-видимому, некоторые OEM-изготовители поставляют системы Windows 2000 и NT 4.0, предварительно заблокировав применение системной политики. В таких случаях параметру реестра UpdateMode в разделе HKEY_LOCAL_MACHINESYSTEM CurrentControlSet ControlUpdate присвоено значение 0. Если задать параметру UpdateMode новое значение, равное 1 (автоматический режим), система будет искать файл системной политики ntconfig.pol в ресурсе общего доступа Netlogon сервера. При установке значения параметра UpdateMode равным 2 (режим ручного ввода) система будет искать файл системной политики в каталоге, указанном в параметре реестра NetworkPath.
Системная политика, которую нельзя перенести на другую платформу. Из соображений безопасности администраторы часто формируют системную политику NT 4.0 таким образом, чтобы имя пользователя, зарегистрировавшегося в системе последним, не отображалось на экране. Такую функцию можно включить и в среде Win-dows 2000, но, поскольку ОС хранят этот параметр в различных частях реестра, Windows 2000 не может получить его из системной политики NT 4.0. Чтобы заблокировать отображение имени последнего зарегистрировавшегося пользователя в среде Windows 2000, необходимо вручную модифицировать реестр каждой системы. Как показано на Экране 5, в Windows 2000 этот параметр находится в разделе HKEY_LOCAL_MACHINESOFTWARE Microsoft WindowsCurrentVersionpoliciessystem. Искомый параметр реестра - DontDisplayLastUser-Name типа REG_DWORD. Если присвоить ему значение, равное 0, Win-dows 2000 будет отображать имя последнего зарегистрировавшегося пользователя, а если значение равно 1, то функция отображения подавляется.
 |
| Экран 5. Параметр, отвечающий за вывод имени при регистрации. |
Указанная установка исчезает и в тех случаях, когда система NT 4.0 модернизируется до уровня Windows 2000. Средства подавления можно задействовать вновь, внеся изменения в реестр, как это показано выше, или модифицировав политику локальной системы. Запустите Microsoft Management Console (MMC) и добавьте оснастку Group Policy. В тех случаях, когда эта оснастка загружается на рабочую станцию или на сервер, не являющийся контроллером домена, MMC заменяет ее оснасткой Local Computer Policy. Нужно выбрать раздел Security Options (Windows SettingsLocal Policies) и прокручивать экран вниз в правой панели, пока не появится запись: «do not display last username in logon screen.» На ней следует щелкнуть правой кнопкой мыши и выставить флажок Enable. Затем нужно перезагрузить систему, после чего внесенное изменение вступит в действие.
Оснастка Group Policy в Windows 2000 и контроль параметров среды пользователя. В системе NT 4.0 проблемы настройки окружения пользователя можно решать с помощью отладочной версии модуля userrenv.dll. Но это не очень удобно, поскольку для того, чтобы активизировать средства настройки, пользователь вынужден отключать и вновь запускать систему. Последовательно разбираться в изменениях, вносимых правилами для компьютера, пользователя и сценариями регистрации, - дело хлопотное. В Windows 2000 предусмотрен более приемлемый метод решения проблем, связанных с конфигурацией.
Дело в том, что система Windows 2000 оснащена встроенными средствами отладки окружения; чтобы воспользоваться ими, достаточно ввести новый раздел и определить несколько значений. Эта функция может пригодиться при диагностике проблем локальной или доменной групповой политики, касающихся компьютеров или пользователей, дистанционной загрузки, управления прикладными программами, правил использования протокола IPSec и т. п.
Сначала нужно запустить редактор реестра, перейти в раздел HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindows NT CurrentVersion и ввести новый раздел Diagnostics (по умолчанию в реестр он не вносится). Получив соответствующее приглашение, поле класса раздела следует оставить незаполненным. В раздел Diagnostics можно поместить четыре параметра. Один дает системе Windows 2000 команду регистрировать все действия пользователя, связанные с окружением, другой - только события, имеющие отношение к групповой политике, третий - фиксировать действия, связанные с дистанционной загрузкой, и четвертый предписывает операционной системе ограничиться регистрацией событий, касающихся управления прикладными программами.
Чтобы каждый установленный в среде Windows 2000 параметр окружения пользователя и каждый параметр политики регистрировались всякий раз при входе пользователя в систему, нужно добавить в раздел Diagnostics параметр RunDiagnosticLoggingGlobal типа REG_DWORD и присвоить ему значение 1. На Экране 6 представлен параметр реестра, который нужно ввести для того, чтобы система осуществляла отладку всех событий. Для регистрации событий Group Policy следует ввести параметр Run-DiagnositcLoggingGroupPolicy типа REG_DWORD и присвоить ему значение 1. Чтобы обеспечить регистрацию действий, связанных с удаленной загрузкой, следует ввести параметр RunDiagnosticLoggingIntelli-Mirror типа REG_DWORD со значением 1, а для регистрации событий управления прикладными программами - параметр RunDiagnosticLoggingAppDeploy типа REG_DWORD со значением 1.
 |
| Экран 6. Параметр реестра, включающий отладку. |
Теперь требуется выйти из системы, зарегистрироваться заново и проверить, нет ли проблем с выполнением прикладных программ; для этого придется прочитать все записи в журнале Application event log. Выяснив причину неполадок, нужно обязательно удалить раздел Diagnostics. Иначе журнал регистрации Application log будет заполнен ненужными сообщениями об отладке.
Итак, получив представление о ряде различий, с которыми придется столкнуться при управлении сетью, включающей системы Windows 2000 и NT 4.0, можно приступать к планированию сети с учетом этих различий. Решение будет зависеть от выбранного метода миграции.
Паула Шерик - редактор Windows 2000 Magazine и консультант по вопросам планирования, реализации и взаимодействия сетей. Ее адрес: paula@win2000mag.com.