Что касается вопроса, может ли NT загружаться с расширенного раздела, то каталог \winnt размещаться в расширенном разделе может. Этот раздел называется загрузочным разделом NT (NT boot partition). Однако системный раздел (т.е. раздел, с которого грузятся компьютеры архитектуры x86) должен всегда располагаться в активном основном разделе, который последовательно располагается в первых 4 Гбайт жесткого диска (т.е. на первых 1024 логических цилиндрах диска). За дополнительной информацией об ограничениях, накладываемых программой инсталляции NT на раздел жесткого диска, обращайтесь к статьям Microsoft "Boot Partition Created During Setup Limited to 4 Gigabytes" (http://support.microsoft.com/support/kb/articles/q119/4/97.asp) и "Windows NT Partitioning Rules During Setup" (http://support.microsoft.com/support/kb/articles/q138/3/64.asp).
Один из доменов нашей компании содержит несколько BDC (Backup Domain Controller), которые мы хотели бы перенести в другой домен. Однако на этих серверах установлено несколько приложений, и мы не хотели бы переустанавливать эти машины. Можем ли мы перенести серверы в новый домен без реинсталляции?До сих пор моим ответом на этот популярный вопрос был стандартный ответ Microsoft: Вы должны реинсталлировать сервер контроллера домена, для того чтобы включить его в другой домен. Однако недавно я нашел новую утилиту, которая может изменить мой ответ и обнадежить в подобной ситуации. Microsoft не поддерживает нижеследующую процедуру, которая в какой-то степени подвергает систему риску. Поэтому убедитесь, что есть полная резервная копия системы, перед тем как выполнять данную процедуру.
В течение некоторого времени Systems Internals выпускает утилиту модификации SID под названием NewSID. Эта утилита позволяет изменить SID компьютера на машинах, которые клонируются с помощью программного обеспечения дублирования дисков. Последняя версия этой утилиты, NewSID 3.0 , имеет интересную особенность: в ней предусмотрена возможность копирования SID машины, расположенной в сети, на локальный компьютер.
В отличие от рабочих станций и отдельных серверов домена (member servers) все контроллеры внутри домена разделяют один и тот же SID (который представляет собой SID домена). Так как NewSID, диалоговое окно которой показано на Рисунке 1, позволяет синхронизировать SID локальной машины с SID удаленной системы, то можно перенести BDC в другой домен, просто синхронизировав его SID с SID любого контроллера домена в домене назначения. Использование этой возможности способно привести к неожиданным последствиям для работы некоторых приложений, но может быть и стоит попробовать, если вас пугает перспектива реинсталляции BDC. Необходимо будет протестировать каждое приложение, для того чтобы убедиться в корректности его поведения. NewSID можно загрузить с Web-сайта Systems Internals (http://www.sysinternals.com/newsid.htm).
Если есть сомнения по поводу использования такого радикального инструмента, рассмотрите вариант с утилитой DC Mover от Fastlane Technologies (http://www.fastlane.com). DC Mover, которая является частью DM/Manager фирмы Fastlane, позволяет сохранить важные системные конфигурационные данные контроллера домена (например, информацию о файловых и принтерных разделяемых ресурсах) перед процессом миграции, а затем восстановить эти конфигурационные данные на сервере после его переустановки в новом домене. Хотя эта утилита поможет сохранить время и силы, ее применение с целью переноса контроллера домена из одного домена в другой по-прежнему требует переустановки NT и всех серверных приложений на данном компьютере.
На протяжении последних нескольких лет наша компания использует Symantec`s Norton Ghost для развертывания клиентов Windows NT Workstation 4.0. Однако мы не используем сопровождающую утилиту Ghost Walker для изменения SID машины после дублирования. Данная ситуация демонстрирует очевидную проблему безопасности – дублирование SID компьютеров и пользователей. Как можно узнать SID системы NT на наших компьютерах для того, чтобы обнаружить дубликаты? Я пытался использовать утилиту getsid.exe из пакета Microsoft Windows NT Server 4.0 Resource Kit, но смог получить результаты только по пользователям, а по компьютерам – нет. Можете ли Вы мне помочь?
Как вы упомянули, утилита getsid.exe определяет SID пользователя, а не SID машины. (Whoami.exe – другая утилита из пакета resource kit, которая позволяет определить SID пользователя, когда применяется с переключателем /sid). Ваш вопрос подтолкнул меня к поискам в Internet утилиты, которая могла бы решить задачу, но я ничего не нашел.
Чтобы определить SID локальной машины, можно просмотреть реестр, но это не очень удобный метод. SID компьютера находится в разделе реестра HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account. Так как, по умолчанию, просмотреть содержимое улья SECURITY (даже будучи администратором) нельзя, то необходимо «обмануть» NT, чтобы она позволила просмотреть эти данные.
Для того чтобы это сделать, просто воспользуйтесь командой NT At или утилитой Soon или WinAt из resource kit, для того чтобы запустить сессию Registry editor по расписанию. Убедитесь, что задача в расписании указана как Интерактивная (Interactive) и что служба Scheduler выполняется с учетной записью LocalSystem, потому что эта учетная запись имеет право на просмотр кустов SAM и SECURITY. Искомый раздел содержит два параметра: F и V. На Рисунке 2 показан пример сессии редактора реестра, который показывает эти значения. Параметр V имеет значения типа REG_BINARY, в нем и хранится SID компьютера.
Однако так как эти данные находятся в двоичном формате, их трудно читать. Для того чтобы эта информация была полезной, необходимо знать формат хранения SID машины в NT 4.0: трем 32-разрядным дополнительным полям защиты(subauthorities) предшествуют три 32-разрядных основных поля защиты(authority). Сравнивая значения V на разных компьютерах, вы можете определить, имеют ли машины одинаковые SID.
Такой метод получения информации о SID машины меня не устроил, поэтому я спросил редактора Windows 2000 Magazine Марка Русиновича, не встречал ли он подходящих утилит. Марк написал утилиту NewSID, имеющую отношение к SID, которую я обсуждал в предыдущем вопросе, поэтому я решил, что он может помочь с утилитой анализа SID.
Марк не смог порекомендовать какой-либо инструмент, но, основываясь на вашем вопросе и на подобных недавних запросах на утилиту такого типа, решил написать свою версию утилиты getsid.exe. GetSID не только определяет SID локальной машины, но также может запрашивать SID удаленного компьютера. Ее можно получить по адресу http://www.sysinternals.com.
У сотрудников нашей компании периодически возникают проблемы с портативными компьютерами, которые используют DHCP. Мы используем модемы для подключения к сети и «дозвона» до серверов RAS. По какой-то причине портативный компьютер вдруг не принимает адрес от DHCP сервера. Технически опытные пользователи могут освободить и получить заново (renew) IP-адрес компьютера (например, используя утилиту Winipcfg), но на портативных компьютерах с ограниченными полномочиями пользователи сначала должны войти в систему, перед тем как они смогут что-то сделать. Войти же они не могут до тех пор, пока не освободят и не получат IP-адрес заново. Я использовал исправления Windows 95 Dial-Up Network 1.3, но это не помогло. Можете ли Вы подсказать решение этой проблемы?
Проблема, которую вы описываете, имеет, как минимум, три возможные причины. Во-первых, в Control Panel в модуле Network в закладке Bindings для RAS-сервера можно обнаружить, что сначала идет привязка Microsoft DHCP Server к RAS, а потом к сетевой карте. Для корректной работы DHCP и других служб (например, WINS) следует всегда проверять, что в системе привязка к RAS следует за привязкой к сетевой карте.
Во-вторых, может быть исчерпан диапазон адресов (scope) DHCP, поэтому у вас нет больше адресов, которые можно предоставить клиентам RAS. После того как вручную освобождается адрес на клиенте, какой-нибудь адрес становится доступным и клиент может затем получить его. Если диапазон адресов DHCP исчерпан, рассмотрите вопрос расширения диапазона на необходимые сегменты или сократите интервал аренды адресов (lease lengths) на сервере DHCP.
И последнее, какое-нибудь устройство сети, такое как маршрутизатор или мост, может конфликтовать с работой DHCP. Например, мне известны случаи, когда параметр DHCP spoofing на некоторых маршрутизаторах вносил сбой в работу DHCP сервера Windows NT. (В одном случае это послужило причиной того, что DHCP-сервер отдавал свой собственный адрес). Поэтому вам надо удостовериться, что параметр установки DHCP spoofing на любом подобном оборудовании не включен, и что в сети нет конкурирующих DHCP-серверов. Также убедитесь, что на DHCP и RAS-серверы установлен пакет исправлений Service Pack 5 (SP5) или более поздний, предпочтительнее SP6a. Эти пакеты обеспечивают большую стабильность работы данных служб, чем предыдущие версии.
Наша компания локально поддерживает свой собственный DNS, но наш ISP недавно обнаружил проблемы в конфигурации файла DNS-зоны, который поддерживает наше доменное имя. ISP сообщил, что нам не стоит использовать псевдонимы (CNAME) для двух наших DNS серверов. В текущей настройке мы используем CNAME для двух DNS серверов - ns1 и ns2. Я не думаю, что у нас есть проблемы с распознаванием имен, поэтому сообщение ISP меня смущает. Вы можете прояснить эту ситуацию?
Запись Name Server (NS) в файле зоны DNS обычно не должна ссылаться на CNAME, так же, как и запись почтового сервера (MX) не должна ссылаться на CNAME. Хотя использование CNAME в записи NS допускается, это не лучшее решение. Основная причина, по которой следует избегать применения записей CNAME в записях типа MX, NS и Source of Authority (SOA) - это производительность. Узлы Internet часто направляют запросы к этим записям, поэтому вам желательно, чтобы обработка этих запросов занимала как можно меньше времени и ресурсов. Если вы будете ссылаться на CNAME, то этим породите дополнительные запросы, которые могут ухудшить производительность. Вместо этого продумайте другую стратегию.
Первое, для каждого DNS сервера можно создать две адресные записи (А), которые указывают на один и тот же IP-адрес данного сервера. Одна запись типа А является именем, которое используется в записях типа SOA и NS (например, ns1.ntsol.com), а другая запись - это реальное или наглядное имя сервера (например, calvin.win2kinfo.com). Эти различные записи типа A связывают IP-адрес с именами, которые используются для данного узла. Такой подход необходим только в том случае, если нужно присвоить DNS-серверу более одного имени – например, одно имя для указания сервера имен в записях типа NS или SOA в файле зоны (например, ns1), а другое имя (например, Calvin) - для пользователей.
Второе, вы можете просто использовать одно имя для каждого сервера в файле зоны, включая ссылки в записях типа A, NS, и SOA. Такое решение не потребует дополнительных обращений к основным записям типа A, при разрешении имен в записях типа CNAME. Записи типа CNAME можно использовать для создания псевдонимов узлов, при этом следует помнить, что в записях типа MX, NS и SOA необходимо ссылаться только на записи типа A. На Рисунке 3 показан пример такого подхода.
Шон Дейли - один из редакторов журнала Windows NT Magazine и президент компании iNTellinet Solutions, занимающейся консалтингом и сетевой интеграцией. Имеет сертификат MCSE. Последней из его книг была «Optimizing Windows NT», выпущенная издательством IDG Books. С ним можно связаться по адресу: sean@ntsol.com.