Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Alt26.Alt16. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве

Возможные проблемы:

• Сеть работает, но в “Сетевом окружении” не все или вообще нет компьютеров.
• Компьютер пингуется, но при попытке обратиться к нему по имени выдаётся ошибка “Нет доступа” или “Не найден сетевой путь”.
• Периодически пропадают компьютеры из “Сетевого окружения”.
• Тормоза при просмотре “Сетевого окружения”.

Кроме того, проблемы могут возникать на мультихомных (multihomed) серверах и клиентах – компьютерах с несколькими сетевыми интерфейсами или работающей службой RAS.

Для формирования списка компьютеров и доменов в сетях Windows применяется механизм Browsing. Его общий смысл заключается в том, что определённые компьютеры сети выполняют роль браузеров (browser) – хранят и распространяют список имён присутствующих в данный момент в сети компьютеров. Служба браузинга использует в своей работе NetBIOS, поэтому работать браузинг будет только в сети, где на компьютерах установлен и включён NetBIOS. Каждый компьютер с установленной службой доступа к файлам и принтерам сетей Microsoft сообщает о себе при загрузке Windows.

Любой компьютер с Windows может выполнять следующие роли:

• Nonbrowser – не является браузером
• Potential browsers – не действует, как браузер, но может им стать
• Master Browser – формирует список компьютеров в данной подсети, рассылает этот список Backup Browser’ам и клиентам своей IP-подсети, назначает Backup Browser’ы
• Backup Browser – рассылает список компьютеров в данной подсети клиентам своей подсети
• Domain Master Browser – принимает списки от Master Browser’ов всех подсетей домена, объединяет их и рассылает Master Browser’ам. Этой ролью всегда обладает PDC (В среде Windows 2000 – эмулятор PDC)

На роль можно влиять, изменяя ключ реестра MaintainServerList. Его возможные значения:

• No – компьютер никогда не станет браузером
• Yes – компьютер станет Backup Browser’ом или инициирует выборы
• Auto – компьютер может быть назначен Backup Browser’ом

В NT/2000 этот ключ находится в разделе HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters

Компьютеры принимают роль Master Browser в результате выборов (election). Процесс выборов инициирует любой компьютер, который не смог найти Master Browser. Также выборы начинаются, если загружается контроллер домена или предпочитаемый Master Browser. Предпочтиаемым Master Browser’ом является компьютер с Windows NT/2000/XP, с ключом IsDomainMaster, установленным в “yes”.
Ключ располагается здесь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters

Предпочитаемый Master Browser выигрывает выборы. В домене, им должен (желательно) являться PDC (или эмулятор PDC). Но, возможно решением проблемы с браузингом будет отнять эту роль у PDC и назначить BDC. В смешанных сетях (9x/NT или 2000) стоит сделать Master Browser’ом компьютер с NT или 2000. Естественно, желательно чтобы это компьютер был включён постоянно (к примеру, это может быть какой-нибудь сервер).

Нужно помнить, что выборы происходят при помощи широковещательных пакетов. Это значит, что для каждого домена коллизий будет выбран свой Master Browser и набор Backup Browser’ов. Кроме того, для нахождения Master Browser’а клиент использует широковещательный запрос. Поэтому, если компьютер со службой браузинга отделён он Master Browser’а маршрутизатором, который не пропускает широковещательные пакеты, – Master Browser будет не найден.

Также в процессе диагностики и наблюдения за работой браузинга нужно учитывать, что все изменения в списках происходят не мгновенно. Master Browser рассылает списки Backup Browser’ам каждые 12 минут. Это значит, что с момента включения компьютера до появления его в “Сетевом окружении” или с момента выключения до исчезновения из “Сетевого окружения” может пройти до 12 минут.

Утилиты для диагностики:

• net view
• nbtstat
• browstat из Support Tools
• browmon из Resource Kit

Синдром гамака является одним из ключевых моментов деградации сисадмина. Он начинается с того, что стабильность и неподвижность становятся синонимами. Когда-то, до того, как IPFilter включили в состав FreeBSD, единственным нормальным способом сделать NAT во FreeBSD был natd. Обязательным условием для полноценной работы natd является наличие dummynet(4). natd и до сих пор может быть в некоторых случаях актуален. Мы же рассмотрим использование ipnat из IPFilter в качестве средства для Network Address Translation (NAT).

Этот документ не является пошаговым howto для чайников — подразумевается, что не нужно объяснять, что например после изменения /etc/syslog.conf ему нужно послать сигнал HUP, а файлы, куда он будет писать, создавать нужно самостоятельно и как «применять» изменённые правила. Если Вы считаете, что ещё не совсем освоились с *nix и с FreeBSD в частности, то по этой теме можно почитать:
ipnat(1), ipnat(5), ipnat(8)
ipf(5), ipf(8), ipfstat(8), ipftest(1), ipmon(8)

Здесь и далее будет считаться, что IPFilter у нас как минимум версии 3.4.29. Если в Вашем случае это не так — то Вы ещё не совсем вылезли из гамака, хотя уже тот факт, что Вы читаете этот текст, является доказательством Вашего на то желания.

Итак, рассмотрим ситуацию: мы имеем 2 интерфейса — fxp0 (200.200.200.1), смотрящий в большой и злой интернет, и dc0 (192.168.0.1), смотрящий во внутреннюю сеть.

Задача: сделать возможность пользователям внутренней сети создавать соединения к внешним хостам без использования socks5/http proxy и т.п.

В ядре нам понадобятся всего 2 строчки:

После этого IPFilter доступен нам во всей своей красе.

Также в /etc/rc.conf нужно добавить строчку gateway_enable=”yes” или в /etc/sysctl.conf добавить строчку:

Теперь всё готово — пакеты перебрасываются между интерфейсами. Осталось контролировать их переброс и заменять в них IP адрес с внутреннего на внешний и наоборот.

Простенький stateful NAT

Начнём с простого stateful NAT т.е. IP пакеты с внешнего интерфейса для получателя во внутренней сети будут транслироваться только в том случае, если пользователь из внутренней сети сам установил это соединение. Все остальные пакеты, пришедшие на внешний интерфейс для получателя во внутренней сети бы будем блокировать (см. redirect далее, если какие-то пакеты извне нужно всегда пробрасывать внутрь).

Для соединений, установленных пользователем, мы будем создавать запись в state table с помощью простого правила IPFilter:
pass out quick on fxp0 proto tcp from 192.168.1.149 to any flags S/FSRA keep state (для TCP-соединений) и
pass out quick on fxp0 proto udp from 192.168.1.149 to any keep state (для UDP-соединений).
Можно вместо двух правил сделать одно общее как для TCP, так и для UDP:
pass out quick on fxp0 proto tcp/udp from 192.168.1.149 to any keep state
, однако в таком правиле мы не сможем отслеживать tcp-пакеты с флагом SYN с помощью flags, в результате чего любой пакет из внутренней сети будет создавать запись в state table (если её не было), а не те пакеты, которые являются первыми в установке TCP-соединения (с флагом SYN). Что удобнее/лучше/больше подходит — решайте сами.

Следом за этим правилом мы поместим правило, блокирующее все пакеты для внутренней сети:
block in quick on fxp0 from any to 192.168.0/16.
Под это правило будут попадать пакеты, не являющиеся частью соединений, запрошенных из внутренней сети либо пакеты из соединений, которых нет в state table

Теперь сама трансляция. Занесём в файл трансляций (по умолчанию это /etc/ipnat.rules) правило:
map fxp0 192.168.1.149/32 -> 200.200.200.1/32 portmap tcp/udp 20000:20099

В результате мы получаем следующую картину: при установке TCP-соединения самый первый пакет (с флагом SYN) из внутренней сети с хоста 192.168.1.149 при уходе в большой и злой интернет будет подвержен простому преобразованию — адрес хоста, запросившего установку соединения будет изменён с 192.168.1.149 на 200.200.200.1. Порт будет также изменён на первый доступный из диапазона от 20000 до 20099. Как можно заметить, в данном случае хост 192.168.1.149 может открыть наружу не более 100 соединений.

Всё что осталось — применить правила. ;-)

Для удобства отслеживания работы NAT можно добавить строчку в syslog.conf: local0.* /var/log/ipmon.log и запустить утилиту мониторинга работы IPFilter — ipmon с ключами -Dvas (стать демоном, показывать более детальную информацию, отслеживать все утройства IPFilter (NAT, state table и сам IPFilter) и работать через syslog). Если получаемый log-файл кажется сумбурным — не торопитесь включать log только NAT опцией -o N. Правила IPFilter попадающие в лог можно туда направлять с другой facility. Для этого достаточно в каждое правило с флагом log добавить facilty: block in log level local2.info quick on fxp0 from any to 192.168.0/16, а в syslog.conf добавить ещё одну строку: local2.* /var/log/ipfilter.block.log. В результате сего деяния в /var/log/ipmon.log будет попадать информация о NAT (созданные трансляции, закрытые трансляции) и state table (создание записи и её удаление), а в файл /var/log/ipfilter.block.log пакеты, которые были блокированы.

Если не желаете, чтобы в большом количестве правил была указана facility и правила были короче — можно отвергнуть возможность работы ipmon через syslog и заставить его писать прямо в файл; например так: ipmon -Dv -o NS /var/log/NAT.log (трансляции и state table протоколируем в файл /var/log/NAT.log) и ipmon -Dv -o I /var/log/ipfilter.log (работу самого фильтра протоколируем в файл /var/log/ipfilter.log).

Стоит заметить, что одним правилом можно транслировать несколько хостов. Например заменив в правилах ipnat и IPFilter 192.168.1.149/32 на 192.168.128/25 мы будем транслировать пакеты хостов из внутренней сети из диапазона от 192.168.1.128 до 192.168.1.254.

Перенаправление (редирект)

Если существует необходимость безусловно транслировать какие-то пакеты, пришедшие извне (например чтобы WWW/SMTP сервер из внутренней сети) был доступен снаружи – используется редирект (redirect).

Простой вариант: транслировать пакеты от любого хоста.

rdr fxp0 200.200.200.1/32 port 8080 -> 192.168.1.17 port 80 tcp

В данном случае любой пакет, пришедший на порт 8080 внешнего интерфейса 200.200.200.1 будет «проброшен» на 192.168.1.18 порт 80. Естественно, что хост 192.168.1.17 лучше поместить в таблицу трансляций как было описано в «Простеньком stateful NAT» и с учётом того, что инициироваться соединение будет снаружи — добавить правила IPFilter, которые бы разрешали их. В случае, если ipmon протоколирует работу IPFilter, допущенную ошибку можно будет легко увидеть.

Редирект можно делать не всех пакетов, а выборочно на основании их отправителя:

Этим правилом будут транслироваться пакеты, пришедшие на 200.200.200.1 порт 6000 только с хоста 212.118.165.100

Не стоит забывать создавать правила IPFilter, разрешающие прохождение таких пакетов. Хотя, если ipmon настроен и запущен, то он быстро об этом напомнит. ;-)

FTP proxy

Итак, всё работает замечательно, за исключением FTP из внутренней сети. Это обусловлено тем, что в ходе установки соединения, по которому будут передаваться данные, указывается IP-адрес клиента, который в нашем случае принадлежит частной сети.

ipnat способен в таких случаях быть «прокси-сервером» — то есть «ковыряться» в данных, передаваемых FTP-серверу и от него, и транслировать адреса из внутренних во внешние и наоборот. Для этого используется такое правило:

proxy-правило должно обязательно стоять перед другими правилами (за исключением redirect).

Использование отдельного IP-адреса для трансляций на внешнем интерфейсе

Если у Вас имеется в наличии не 1 IP-адрес, а сегмент сети, может быть удобным транслировать не с тех адресов, которые установлены на внешнем интерфейсе (fxp0), а с других. При этом важным является то, что на самом внешнем интерфейсе (fxp0) этот IP-адрес устанавливать нет никакой необходимости. ipnat делая трансляцию не открывает сокетов — об этом нужно помнить.

Допустим, что сеть 200.200.200.0/24 полностью принадлежит нам. В таком случае, во всех правилах трансляции мы можем ставить не реальный IP-адрес, установленный на внешнем интерфейсе (fxp0), а другой, например 200.200.200.200 (также можно по желанию сделать PTR запись для этого хоста в зоне 200.200.200.in-addr.arpa).

Безусловная полная трансляция

Если существует необходимость транслировать абсолютно все пакеты, пришедшие на какой-либо адрес (не забывайте, что этот IP-адрес необязательно должен быть установлен на внешнем интерфейсе fxp0) — используется правило bimap:

и/или

Контроль над трансляцией

Безусловно глупо настраивать NAT не глядя в протоколы, генерируемые ipmon’ом. Также возможно будет полезным ограничивать способность устанавливать соединения изнутри к привилегированным портам внешних хостов. Всё это можно и нужно настроить по желанию.

Хорошим помошником может быть старый добрый root-tail (/usr/ports/sysutils/roottail).

DNS — не роскошь, а необходимость

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

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

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

С ростом числа компьютеров в сети корректировать эти файлы вручную стало невозможно. Появилась необходимость в глобальной базе имен, позволяющей производить преобразование имен в IP-адреса без хранения списка соответствия на каждом компьютере. Такой базой стала DNS (Domain Name System) — система именования доменов, которая начала работу в 1987 году.

Структура DNS

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

Вторая особенность системы — это организация DNS-серверов в виде иерархической структуры. Например, запрос от клиента об имени ftp.microsoft.com может пройти через несколько DNS-серверов, от глобального, содержащего информацию о доменах верхнего уровня (.com, .org, .net и т. п.), до конкретного сервера компании Microsoft, в чьих списках перечислены поддомены вида *. miсrosoft.com, в числе которых мы и находим нужный нам ftp.microsoft.com. При этом множество DNS-серверов организуется в зоны, имеющие права и разрешения, делегированные вышестоящим сервером. Таким образом, при добавлении нового поддомена на местном сервере уведомления остальных серверов в Глобальной сети не производятся, но информация о новых серверах оказывается доступной по запросу.

Зоны, домены и поддомены

С ростом числа доменных имен работа между серверами была распределена по принципу единоначалия. Идея проста. Если организация владеет собственным доменным именем (например microsoft.com или white-house, gov), то именование внутри своего домена она производит самостоятельно. Единственная сложность при такой работе — предоставление вышестоящими серверами этих прав нижестоящим серверам.

Уточним термины. Домен — это некий контейнер, в котором могут содержаться хосты и другие домены. Имя домена может не совпадать с именем контроллера домена, то есть домен — это виртуальная структура, не привязанная к компьютеру. Хост же, напротив, соответствует физическому компьютеру, подключенному к сети. Имя хоста является именем конкретного компьютера. Имя хоста может совпадать с именем домена. Имя домена может совпадать с именем зоны, к которой он принадлежит, в этом случае домен является корневым в зоне. При этом зона не обязана содержать в себе одноименный (корневой) домен.

Зона — это контейнер, объединяющий несколько доменов в структуру с общими разрешениями на управление, то есть зоны являются контейнерами для доменов и хостов. Зоны могут быть вложены одна в другую. Разница между зонами и доменами в том, что домену может принадлежать несколько зон, содержащих различные его поддомены. Это дает возможность делегировать полномочия для поддоменов и управлять группами поддоменов.

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

Интеграция DNS в Active Directory

Компания Microsoft рекомендует использовать DNS-серверы в корпоративных сетях для организации работы компьютеров в составе домена. Дело в том, что технология DNS более универсальна и эффективна, чем использующиеся на старых системах WINS и NetBIOS. Клиенты только посылают запросы серверу и получают ответы без обращения к каким-либо иным узлам сети.

С точки зрения производительности лучше всего интегрировать DNS в Active Directory, что возможно на серверных ОС компании Microsoft начиная с Windows 2000 Server. Совмещение ролей DNS-сервера и контроллера домена упрощает администрирование сети, особенно если размеры ее достаточно велики.

Что нам стоит DNS построить

DNS реализуются в соответствии с единым стандартом, основы которого изложены в RFC 1011,1034 и 1035. В Windows Server 2003 процесс развертывания и управления DNS сделан проще, чем в предыдущих версиях операционных систем, благодаря мастерам настройки ролей сервера. В Windows Server 2003 добавлены и новые функции управления Active Directory, которая может быть интегрирована с DNS воедино,

При создании контроллера домена, то есть сервера, управляющего работой Active Directory, мастер предлагает создать и настроить DNS-сервер. Для этого достаточно в настройках отметить пункт «Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server». В этом случае запускается DNS-сервер и создается зона, одноименная с вашим доменом.

Для имени домена лучше использовать два слова, разделенных точкой (вида гпу-domen.ru). Технически возможно включить компьютеры вашей сети и в домен верхнего уровня, но Microsoft не рекомендует использовать для домена имя, состоящее из одного слова, так как в этом случае возникают сложности с организацией пересылки запросов (forwarding) и динамических обновлений.

Настройка DNS

После перезапуска системы в окне «Manage Your Server» (управление сервером) и на панели «Администрирование» появятся новые элементы — ссылки на консоли управления Active Directory (три иконки) и DNS (одна иконка). Остановимся подробнее на консоли управления DNS-сервером.

Дерево DNS содержит список ONS-серве-ров, в нашем случае список будет состоять из одного пункта — имени нашего сервера. Раскрыв его, мы увидим три папки — «Forward Lookup Zones» (зоны прямого просмотра), «Reverse Lookup Zones» (зоны обратного просмотра, пустая папка) и «Event Viewer» .

Папка зон прямого просмотра будет содержать две записи. Зона, чье имя начинается с _msdcs, относится к организации работы системы (DC расшифровывается как Domain Controller, контроллер домена), пока что нам ее трогать не нужно, так же как и папку _msdcs во второй зоне. Выбрав вторую зону, в списке справа мы увидим ее содержимое — собственно говоря, все компьютеры, чьи имена хранятся на нашем сервере, будут перечислены именно там.

Добавление новых хостов будет происходить автоматически. Все операционные системы Windows, начиная с Windows 2000 Professional, поддерживают корректное обновление базы DNS-сервера в своей локальной сети. Новые пункты в список имен хостов на DNS-сервере могут добавляться и при помощи службы «Computer Browser». Вручную же добавление новых доменов и хостов, равно как и удаление существующих, происходит из меню консоли «Action» или из контекстного меню правой клавиши мыши.

После запуска контроллера можно приступить к введению в домен клиентских машин. Повторим, что корректная работа в составе домена возможна только для систем ранга Professional, начиная с Windows 2000 Professional, то есть в домене откажутся работать компьютеры под управлением операционных систем Windows 98, Windows Me или Windows XP Home Edition.

Когда же вы добавляете в домен компьютер с установленной ОС Windows 2000 Professional или Windows XP Professional, система автоматически пошлет запрос DNS- серверу, а тот в свою очередь добавит новый IP-адрес в список.

В сети, состоящей из компьютеров с фиксированными IP-адресами, работа DNS предельно проста. Однако как быть, если в вашей сети IP-адреса должны раздаваться динамически? Тут мы сталкиваемся с определенными сложностями, поскольку в этом случае DNS-сервер должен обновлять свою базу постоянно, основываясь на данных, получаемых от DHCP-сервера.

Впрочем, чтобы настроить DNS и DHCP на совместную работу, не требуется особых усилий. Достаточно открыть «Scope Options» в консоли управления DHCP-сервером и указать имя вашего DNS-сервера в параметре «DNS Domain Name».

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

DNS-сервер может производить очистку списка, удаляя из него данные о тех хостах, которые удалены из сети. Чтобы настроить очистку списка хостов, нажмите кнопку «Aging» («Очистка») на вкладке «General» в свойствах зоны — по умолчанию удаление «просроченных» имен выключено (нужно поставить соответствующую галочку). Кроме того, там же указывается параметр автоматического обновления («Dynamic Updates») — по умолчанию он переключен в «Secure Only» и разрешает производить обновления базы на основе запросов только от безопасных источников.

Подключаемся к Интернету

У начинающих системных администраторов возникает немало проблем от некорректного обращения с настройками DMS, в том числе с соответствующими настройками на компьютерах пользователей. Во-первых, все зависит оттого, статические или динамические IP-адреса используются в вашей сети. В случае, если используются статические адреса, убедитесь, что на каждой машине корректно прописан ее IP-адрес, маска подсети и выбираемый по умолчанию DNS-сервер. Если же компьютеры получают свои IP-адреса динамически, посредством DHCP-сервера, то этот же сервер должен указывать и адрес DNS-сервера. Учтите, что для корректной работы клиентов DHCP-сервер в подсети должен быть единственным.

Другая задача, возникающая перед администраторами, — это настройка доступа в Интернет через локальную сеть. Доступ может быть организован по-разному, и, если все клиенты подключаются через прокси-сервер, настраивать DNS для работы в Интернете необходимости нет. Другое дело, если вы используете IР-маскарадинг при помощи NAT. В этом случае клиентские компьютеры в вашей сети должны будут иметь возможность получать ответы от DNS-серверов в Интернете, чтобы подключаться к веб-серверам по их IP-адресам.

Реализовать это просто. Вам нужно настроить пересылку запросов с вашего DNS-сервера на сервер интернет-провайдера {так называемый форвардинг). Лучше всего организовать это в два этапа. Сначала ваш DNS-сервер отправляет запрос на маршрутизатор, а тот уже пересылает его провайдеру.

Можно обойтись и одним шагом, ведь если маршрутизатор предоставляет сервис NAT для выхода в Интернет, то сам DNS-сервер может обращаться непосредственно к провайдеру. Однако такой метод менее грамотен. Например, если вы поменяете провайдера, вам придется править настройки уже на нескольких компьютерах. Кроме того, подключение к Интернету через NAT менее безопасно, чем перенаправление запросов посредством прокси-сервера. Также по соображениям безопасности не рекомендуется совмещать роль DNS-сервера и маршрутизатора на одном компьютере, особенно если он же является и контроллером домена в вашей сети.

Настройка форвардинга происходит в свойствах DNS-сервера из консоли управления. Нажимаем правой кнопкой на значке сервера, затем «Properties -> Forwarders», где и указываем имя вышестоящего домена или перечисляем DNS-серверы, к которым будет обращаться наш сервер. На вкладке «Root Hints» перечисляются адреса DNS-серверов сети (не обязательно вышестоящих). Список «Root Hints» может быть заполнен автоматически при помощи мастера Configure DNS Server из меню «Action».

Ошибкой является создание зоны с именем «.». В этом случае наш DNS-сервер начнет считать себя корневым, то есть верхним в глобальном дереве DNS. Разумеется, никакие пересылки вышестоящим серверам работать не будут. При создании зоны, чье имя совпадает с частью имени уже существующих зон после точки (например, у нас есть зона trading.office, а мы создаем зону office), все принадлежащие ей зоны и домены оказываются вложенными в нее.

Если у вашего сервера в свойствах подключения к локальной сети в качестве DNS-сервера указан сам контроллер домена, это тоже не очень хорошо. DNS-запрoсы никогда не должны приходить на сервер с его же адреса — любой подобный случай однозначно свидетельствует о неправильности настроек.

Разобраться в ситуации поможет «Event Viewer». В случае корректной работы DNS-сервера в журнале должна появиться запись о старте сервера. Также новые записи будут появляться по мере добавления новых имен хостов либо при ручном управлении зонами и доменами.

Для того чтобы детектировать неисправности со стороны клиента, проще всего воспользоваться консольной утилитой nsLookup, которая поставляется вместе с операционной системой. После ввода nsLookup в командной строке на экране должно появиться имя и IP-адрес вашего DNS-сервера, а после этого вам будет предоставлена возможность протестировать сервер путем отправления запросов на преобразование имени в IP-адрес. Чтобы увидеть справку по параметрам команды nslookup, введите в командной строке nslookup help.

Имею: 2 машины с Win2k Server SP4 на нём развёрнут домен /лес не организован/.
Задача: Перенести на другой сервер существующий контроллер домена, при этому сохранить базу Active Directory и прилагающие службы DNS, DHCP и WINS.
Цель: Чтобы все клиенты сети не потеряли свои десктопы. Чтобы сохранить учётные записи Active Directory и настройки DNS.
Действия: Я при помощи утилиты “Пуск->Выполнить…->” dcpromo произвёл с одного сервера на другой репликацию базы данных Active Directory. Всё прошло успешно.
Каким образом мне:
1. Понизить статус (роль) старого контроллера домена (хозяина операций).
2. Переименовать новый контроллер домена.
3. При успешной процедуре будут ли клиенты видеть новый сервер (контроллер домена)? /если “нет”, то опишите пожалуйста “почему?”/ 

решение 1:

1 :Я так понял, что ты хочешь все со старого сервера перекинуть на новый, новый обозвать также, как и старый и чтобы пользователи, придя утром на работу ничего не заметили ?
ИМХО, это невозможно.
2. Переименовать контроллер домена W2K невозможно. По крайней мере штатными средствами. Возможно программеры Билли выпустили какую-нибудь тулзу, но мне это неизвестно. А посему – невыполнение пункта 2 ведет к невыполнению всей поставленной задачи.

Если отступится от пункта 2 условия, то выглядит это так:
1. На втором сервере DC ты уже поднял
2. Проверь поднят ли на нем DNS (обычно при поднятии DC DNS ставится автоматом)
3. Рубишь на старом сервере DHCP и WINS и поднимаешь их на новом сервере.
4. Переносишь необходимые настройки на новый сервер.
5. Если старый сервер оставляешь контроллером домена, то на новый переносишь роль хозяина инфраструктуры или, наоборот, все роли, кроме инфраструктуры переносишь на новый сервер (включая GC, на старом GC рубишь). Если старый сервер опускаешь до рядового – просто запускаешь на нем dcpromo.

решение 2:

1) Включаешь на старом сервере СТАНДАРТНЫЙ IDE -контроллер дисков вместо “какой там у тебя IDE -контроллер дисков”.
2) Форматируешь диск НОВОГО сервера, активизируешь загрузочный раздел.
3) Копируешь ВСЕ с диска старого сервера на диск нового сервера. Для этого диск старого придется отвинтить и копировать на др. машине

Рекомендую пользовать:

4) Привинчиваешь диск нового сервера обратно, отключаешь сет провод, пробуешь загрузиться.
5) Если ОК, пробуешь войти в систему, если не ОК – читаешь как это поправить (можно найти на этом форуме).
6) Проверяешь все ресурсы нового сервера и поправляешь.
7) Если ОК, выдираешь провод из старого и втыкаешь провод в новый.
8) Проверяешь работоспособность клиентов.
9) Если ОК – убираешь старый сервер на неделю на склад.
10) Если через неделю ОК – форматируешь диск старого сервера и пользуешь его как хочешь.
———————-
Ps) Ежели отвинчивать диск нельзя:
1) NTBACKUP.exe диска старого сервера на любой носитель, доступный по сети. !!! На сервере лучше все что можно тормознуть на время работы NTBACKUP.
2) На новый сервер ставишь Win2K Pro в нестандартный каталог, например, WinNT.pro. Загружаешься.
3) Диск нового сервера привинчиваешь к третьей машине
4) Восстанавливаешь NTBACKUP диска старого сервера на диск нового.
5) !!!отключаешь сет провод

Задача: при наличии двух серверов перенести старый на новый с сохранением имени старого сервера.

Это сделать элементарно, но напоминает задачу про козла, капусту и волка. Вкратце выглядит все вот так:
1. Устанавливаем сервер SERVER2 и поднимаем его роль до BDC.
2. Понижаем роль старого сервера SERVER с контроллера домена до обычного.
3. Переименовываем старый сервер SERVER в SERVER_OLD.
4. Поднимаем его роль до BDC.
5. Понижаем роль сервера SERVER2 до обычного.
6. Переименовываем сервер SERVER2 в SERVER.
7. Поднимаем его роль до BDC.
8. Понижаем роль SERVER_OLD до обычного сервера.
9. Теперь у нас есть старый сервер с именем SERVER_OLD и новый с именем старого SERVER.

А зачем? Если можно пропустить стадии с 3 по 9 включительно и начать сразу с:

10. Поднимаем на SERVER службы DNS, DHCP, WINS.
11. Настраиваем DHCP.
12. Заводим вторичные зоны в DNS и получаем копии с SERVER_OLD.
13. Меняем типы зон с вторичных на главные и наоборот на обоих серверах.
14. Копируем профайлы, бла-бла-бла и прочую полезную и бесполезную дребедень.
15. Уносим SERVER_OLD на кремацию.

Перенос ролей осуществляется автоматически при повышении и понижении ролей с помощью dcpromo.

Для параноиков, то есть для таких как я, и нежелающих повторять шаги 3-9 есть консоль ntdsutil и графический интерфейс. Необходим только в случаях:
1. Балансировки нагрузки.
2. Когда старый сервер дохнет без перерыва и не успевает сам переносить роли. Или еще как. Короче бывает.

Перенос ролей:
1. Перенос роли «Schema master»
a. Открываем консоль «Active Directory Schema»
b. В дереве правой кнопкой щелкаем на «Active Directory Schema» и выбираем «Change Domain Controller».
c. Выбрать «Any DC» для выбора нового холдера или «Specify Name» для указания вручную.
d. Опять правой кнопкой на «Active Directory Schema» и выбираем «Operations Master».
e. Жмем «Change».
2. Перенос роли Domain naming master
a. Открываем консоль «Active Directory Domains and Trusts»
b. В дереве правой кнопкой на узле контроллера, на который переносим роль и выбираем «Connect to Domain».
c. Выбираем имя домена.
d. В дереве кликнем правой кнопкой мыши на «Active Directory Domains and Trusts» и выбираем «Operations Master»
e. Жмем Change.
3. Перенос роли Relative ID master и PDC emulator
a. Открываем консоль «Active Directory Users and Computers»
b. В дереве кликнем правой кнопкой на узле контроллера, на который переносим роль и выбираем «Connect to Domain».
c. Выбираем имя домена.
d. В дереве правой кнопкой мыши на «Active Directory Users and Computers» и выбираем «Operations Masters».
e. Выбираем закладку RID и жмем Change.
4. Перенос роли PDC emulator
a. Открываем Active Directory Users and Computers
b. В дереве кликнем правой кнопкой на узле контроллера, на который переносим роль и выбираем «Connect to Domain».
c. Выбираем имя домена.
d. В дереве правой кнопкой мыши на «Active Directory Users and Computers» и выбираем «Operations Masters».
e. Выбираем закладку PDC и жмем Change.
5. Переносим роль Infrastructure master
a. Открываем Active Directory Users and Computers
b. В дереве кликнем правой кнопкой на узле контроллера, на который переносим роль и выбираем «Connect to Domain».
c. Выбираем имя домена.
d. В дереве правой кнопкой мыши на «Active Directory Users and Computers» и выбираем «Operations Masters».
e. Выбираем закладку Infrastructure и жмем Change.

Ждем окончания репликации и переноса данных. Оно спокойней.

Проверяем, является ли новый главный контроллер домена сервером глобального каталога.
1. Открываем Active Directory Sites and Services
2. В дереве выбираем Sites и ищем свой или «Default-first-site-name».
3. Открываем «Servers» и ищем наш новый контроллер домена.
4. Правой кнопкой на «NTDS Settings».
5. На вкладке «Common» проверяем, установлен ли флаг «Global Catalog»

Служба Microsoft Computer Browser обеспечивает функционирование списков Windows-доменов, рабочих групп и компьютеров в масштабе всей сети, а также списков других сетевых аппаратных устройств, совместимых с протоколом NetBIOS (таких как сетевые накопители Network Attached Storage (NAS). В этих списках просмотра хранятся те самые данные, которые предъявляются пользователю после того, как он открывает Network Neighborhood в Windows Explorer. В сетях на базе ОС Windows 2000 служба Computer Browser применяется лишь из соображений совместимости с более ранними версиями Windows. Дело в том, что когда поддерживающие Active Directory – AD – клиенты взаимодействуют в сети Windows 2000, работающей в собственном режиме, служба Computer Browser замещается службой AD. Однако в сетях смешанного типа с контроллерами доменов под управлением более ранних по сравнению с Windows 2000 версий Windows, а также в сетях с клиентами, не оснащенными поддержкой AD, по-прежнему используется служба Computer Browser.

Если в сети имеется несколько доменов Windows 2000 и Windows NT, широковещательных доменов или протоколов, система просмотра (т.е. процесс обслуживания и распределения списков просмотра, а также вовлеченных в этот процесс компьютеров) будет достаточно сложной. Администратор должен следить за тем, чтобы в списки службы Computer Browser были включены все компьютеры, которые следует отобразить, и чтобы в них не было машин, которые лучше скрыть от рядовых пользователей. Эта работа требует навыков управления всеми аспектами работы сети. Прежде чем браться за нее, администратор должен получить четкое представление о том, как функционирует служба: какие роли могут играть те или иные системы, как определяются эти роли, как системы взаимодействуют в контексте службы и по каким причинам различные устройства могут оказаться вне списков просмотра.

Распределение ролей

Всякий компьютер, способный собирать, обслуживать и распределять списки просмотра, считается браузером и может брать на себя одну или несколько из пяти перечисленных ниже ролей: главный браузер (master browser), главный браузер домена (domain master browser), резервный браузер (backup browser), потенциальный браузер (potential browser) и не-браузер (nonbrowser). В качестве браузера могут выступать машины, работающие под управлением Windows for Workgroups (WFW) 3.11 или любой другой более поздней версии Windows (Windows XP, Windows 2000, NT, Windows Me или Windows 9.x).

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

Роль главного браузера домена всегда играет главный контроллер домена (в сети Windows 2000 – исполнитель роли главного контроллера домена). Главный браузер домена выступает в качестве центрального хранилища. Он компилирует списки просмотра, получаемые от главных браузеров сети и затем направляет полный список просмотра каждому главному браузеру. Кроме того, главный браузер домена играет роль главного браузера в своем сетевом сегменте. Роль главного браузера домена существует только в сетях на базе протоколов TCP/IP. (Вопрос о том, как служба Computer Browser взаимодействует с различными сетевыми протоколами, рассматривается во врезке “Домены широковещательных сообщений, сетевые протоколы и адаптеры”).

Врезка 1: Домены широковещательных сообщений, сетевые протоколы и адаптеры.

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

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

IPX/SPX NwLnkNb. NwLnkNb – NetBIOS протокол с поддержкой IPX/SPX. Маршрутизаторы IPX обычно разрешают передачу широковещательных пакетов, поэтому одного главного браузера достаточно для всех соединенных между собой сегментов IPX. Однако IPX/SPX может использовать только один из четырех типов фрейма, поэтому компьютеры могут взаимодействовать только с теми, кто использует тот же тип фрейма. Поэтому служба Computer Browser выбирает главного браузера для каждого типа фреймов, используемых в сети IPX/SPX.

NetBEUI. Это немаршрутизируемый протокол, и главный браузер и список просмотра необходимы для каждого сетевого сегмента, в который входят системы Windows NT и более старые.

Если компьютер-браузер содержит несколько сетевых адаптеров, то он собирает список компьютеров для каждого из них; список просмотра для каждого адаптера состоит только из компьютеров, которые объявляют о себе через этот адаптер. Следовательно, каждый главный браузер, в том числе главный браузер домена, управляет списком просмотра для каждой комбинации сетевой адаптер+протокол. Если главный браузер не поддерживает все протоколы, используемые в сегменте, потенциальный браузер, который поддерживает такой протокол, объявляет выборы для этого протокола. Таким образом, для каждого протокола в сети существует главный браузер. Многодомный компьютер, являющийся главным браузером, перенаправляет главному браузеру домена или резервному браузеру только те списки просмотра, которые соответствуют адаптеру или протоколу, через который эти браузеры послали запрос. Многодомный главный браузер домена, который получает объявления от хостов или удаленные списки просмотра через более чем один адаптер, не может управлять глобальным списком просмотра; удаленные главные браузеры и браузеры клиентов получают список, содержащий только те компьютеры, которые доступны через один из адаптеров главного браузера домена. Поэтому следует установить параметр MaintainServerList раздела HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters в No, чтобы отключить функцию браузера на многодомном комьютере.

Служба Computer Browser использует протокол NetBIOS over TCP/IP (NetBT), поэтому отключение протокола NetBIOS для сетевого адаптера приведет к игнорированию этого адаптера службой просмотра. Чтобы отключить NetBIOS в Windows 2000, откройте окно свойств для соответствующего сетевого соединения, укажите Internet Protocol (TCP/IP) в списке Components, нажмите Properties, а затем Advanced и откройте окно Advanced TCP/IP Settings. Перейдите на закладку WINS и укажите пункт Disable NetBIOS over TCP/IP. В NT 4.0 запустите модуль Network в Control Panel и перейдите на закладку Bindings. В списке Show Bindings for укажите all services. Раскройте пункты NetBIOS Interface, WINS Client (TCP/IP). Выберите нужный сетевой адаптер, щелкните Disable, потом OK. Когда в многодомном компьютере NetBIOS включен только для одного адаптера, только этот адаптер будет связан со службой Computer Browser, только через него будут поступать объявления от других компютеров и создаваться список просмотра. Но этот список может быть неполным, поскольку служба просмотра не видит объявлений других компьютеров, входящих в сегменты, подключенные к остальным сетевым адаптерам.

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

Потенциальный браузер может выполнять функции главного или резервного браузера, но не может выступать и в том, и в другом качестве одновременно. Не-браузер – это компьютер с отключенной администратором функцией обслуживания списков просмотра. При попытке запустить службу Computer Browser на таком компьютере служба не инициализируется, а система выдает код ошибки 2550 и регистрирует событие ID 7024. При этом клиенты, на которых не установлена служба Computer Browser, могут по-прежнему получать списки просмотра и отображать их в окне программы Windows Explorer.

Располагая полномочиями системного администратора Windows 2000 или NT, можно редактировать записи реестра и тем самым определять роль каждого компьютера в процессе просмотра ресурсов сети. Сводка соответствующих записей и их функций приводится в Таблице 1. Большинство связанных с просмотром ресурсов записей хранится в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\Browser\Parameters.

Таблица 1: Записи реестра, управляющие работой службы просмотра (Computer Browser).

Значение ключа в разделе HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services	Тип записи	Действие
\Browser\Parameters\IsDomainMaster=True	REG_SZ	Система определяется как предпочтительный главный браузер (значение по умолчанию False)
\Browser\Parameters\MaintainServerList=Yes	REG_SZ	Система определяется как браузер, который всегда используется в качестве главного или резервного (на серверах принимается по умолчанию)
\Browser\Parameters\MaintainServerList=Auto	REG_SZ	Система определяется как потенциальный браузер (принимается по умолчанию на клиентских системах)
\Browser\Parameters\MaintainServerList=No	REG_SZ	Система определяется как небраузер
\LanmanServer\Parameters\Hidden=1	DWORD	Система исключается из списка просмотра
\Browser\Parameters\UnboundBindings= NetBT_<network_adapter_driver>	REG_MULTI_SZ	Команда службе Computer Browser не обеспечивать список просмотра для указанного сетевого адаптера

Когда компьютеры сетевого сегмента принадлежат различным доменам или рабочим группам, по меньшей мере, один компьютер каждого из представленных доменов или рабочих групп обслуживает список просмотра для своего домена или группы. Главные браузеры каждого домена и рабочей группы данного сегмента “представляются” друг другу так, чтобы пользователи могли видеть ресурсы во всех доменах и рабочих группах – даже в тех, что расположены за пределами данного сегмента.

Какой системе поручается задача?

Допустим, что к сети подключен потенциальный браузер. Если эта машина является к тому же главным контроллером домена, если вы определили ее как предпочтительный главный браузер или если она не в состоянии обнаружить главный браузер для одного из своих сетевых протоколов, в момент начала работы в сети этот браузер инициирует среди потенциальных браузеров своего сетевого сегмента нечто вроде избирательного процесса. Процедура выбора построена таким образом, чтобы чаша весов склонилась в пользу сервера Windows 2000 или NT, содержащего последнюю версию правил выбора браузера (т.е. правил, в соответствии с которыми различные версии Windows определяют, какой машине быть главным браузером). Если одной и той же версией протокола оснащено несколько машин, серверным версиям Windows 2000 или NT всегда отдается предпочтение перед версиями XP, Windows 2000 Professional и NT Workstation. Последние, в свою очередь, неизменно получают преимущество перед версиями Windows 9.x. и WFW. А внутри каждого набора версий (т.е. сервер, рабочая станция Win32 или Windows 9.x и WFW) принимается следующий порядок предпочтения, от высшего к низшему: главный контроллер домена, сервер WINS, предпочтительный главный браузер, действующий главный браузер, система, сконфигурированная для выполнения роли главного браузера или резервного браузера и действующий резервный браузер. И последний критерий: (при прочих равных условиях) предпочтение отдается машине, имя которой в алфавитном порядке следует первым (регистр во внимание не принимается); таким образом, компьютер с именем ART получает преимущество перед машиной по имени BOB.

Инициализирующий процесс выбора компьютер передает в широковещательном режиме дейтаграмму выборов, содержащую поле Election Protocol Version размером в 1 байт и поле Election Criteria размером в 4 байта. Большее значение байта поля Election Criteria определяет приоритет операционной системы. Следующие 2 байта определяют уровень подверсии (внутри данной версии протокола выбора), а биты последнего байта определяют роль – или роли – данного компьютера при исполнении данной сетевой службы. Каждый потенциальный браузер производит оценку полей выбора и – если номер его версии протокола выбора (Election Protocol Version) или (когда номера версий идентичны) если значение поля «Критерии выбора» (Election Creteria) больше полученных значений – передает в широковещательном режиме свою дейтаграмму выбора. Система, выигравшая такое соревнование, становится главным браузером; если же главный браузер уже существует, ее статус понижается до статуса резервного браузера.

Служба Computer Browser предусматривает выделение резервного браузера для первых 31 компьютера в домене и дополнительного резервного браузера для каждой дополнительной группы из 32 компьютеров. Главный браузер следит за тем, чтобы достаточное число браузеров оставалось в активном состоянии. Все контроллеры доменов сетевого сегмента главного браузера, а также машины, в реестрах которых имеется запись MaintainServerList=Yes, становятся резервными браузерами, если не получают статуса главного браузера. Если же после этого сегмент все еще испытывает нехватку резервных браузеров, главный браузер осуществляет дополнительный отбор из пула потенциальных браузеров до тех пор, пока положение не меняется.

Разрешение имен NetBIOS

Но как же главный браузер отыскивает главный браузер домена? Как клиенты находят браузер, способный ответить на запрос о предоставлении списка просмотра? Чтобы ответить на эти вопросы, надо рассмотреть систему разрешения имен NetBIOS.

Система просмотра использует несколько определяемых ролями машин NetBIOS-имен, которые позволяют серверам службы просмотра и клиентским браузерам находить друг друга. Список этих имен приведен в Таблице 2, где также указано, какие системы их регистрируют и как они используются системами. Каждый раз, когда сервер просмотра или клиентский браузер не в состоянии разрешить одно из этих имен в IP-адрес выполняющего соответствующую роль компьютера, список просмотра оказывается неполным. Понимание принципов использования службой Computer Browser каждого из этих имен поможет производить диагностику подобных отказов.
Таблица 2: NetBIOS-имена, используемые службой Computer Browser.

NetBIOS-имя	Какая система регистрирует?	Какие системы используют?
domain_name<1Bh>	Главный контроллер домена в качестве главного браузера домена	Главные браузеры для поиска главного браузера домена.
domain_name<1Dh>	Главный браузер	Резервные браузеры для получения списка просмотра; клиенты для получения списка резервных браузеров у сервера, регистрирующего данное имя.
domain_name<1Eh>	Потенциальный браузер	Дейтаграммы выбора.
..__MSBROWSE__.<01H>	Главные браузеры	Объявления, предназначенные для нескольких доменов или нескольких рабочих групп.
computer_name<00h>	Обслуживание рабочих станций	Главные браузеры, клиенты.

Служба Computer Browser регистрирует три имени. Все потенциальные браузеры регистрируют имя_домена<1Eh> (domain_name<1Eh>). Это имя идентифицирует их в качестве компьютеров, которые будут принимать участие в выборе браузеров для именованного домена в их сетевом сегменте. Все главные браузеры регистрируют имя_домена<1Dh> (domain_name<1Dh>) и __MSBROWSE__.<01H> (трассировка с помощью сетевого монитора показывает, что фактическое имя – <01h><02h>__MSBROWSE__<02h><01h>). При поисках и взаимодействии с главным браузером в процессе извлечения списка просмотра резервные браузеры используют имя_домена<1Dh> (domain_name<1Dh>). При передаче и приеме предназначенных для нескольких доменов или рабочих групп объявлений в локальной подсети главные браузеры используют имя __MSBROWSE__.<01H>. Главные браузеры, подключенные к тем сетевым сегментам, где размещаются главные браузеры других доменов или рабочих групп, с помощью таких объявлений узнают о существовании друг друга, и в результате список просмотра может содержать информацию о каждом домене и рабочей группе. Наконец, главный контроллер домена регистрирует имя_домена<1Bh> (domain_name<1Bh>). Главные браузеры NT исходят из того, что компьютер с таким именем является главным браузером домена. Оснащенные поддержкой AD главные браузеры обращаются к службе AD с запросом об имени эмулятора главного контроллера домена, который и выполняет роль главного браузера домена.

Если резервный браузер (или главный браузер, выполняющий функции резервного) предоставляет клиентам неполный список просмотра, причина этого часто кроется в некорректной работе системы разрешения имен NetBIOS. Скажем, если список просмотра содержит только имена компьютеров локального сетевого сегмента, отсюда, возможно, следует, что главный браузер не в состоянии разрешить имя главного браузера домена – а это необходимо для того, чтобы получить полный глобальный список просмотра. Системы Windows Me, Windows 9.x или WFW 3.11b на базе TCP/IP могут выступать в качестве главного браузера лишь потому, что, во-первых, и данная Windows-система, и главный контроллер домена используют для разрешения имен систему WINS (так, чтобы эта Windows-система могла разрешать имя_домена<1Bh> (domain-name<1Bh>) в IP-адрес главного контроллера домена), и, во-вторых, поскольку имя рабочей группы компьютера совпадает с именем домена главного контроллера домена.

Формирование и обслуживание списка просмотра

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

Когда только что взявшая на себя роль главного браузера машина обнаруживает, что список просмотра пуст, она передает в широковещательном режиме дейтаграмму Announcement Request, которая направляется системе domain_name<00h> в локальном сегменте сети. Все компьютеры, получившие упомянутую дейтаграмму, заявляют о себе через произвольные интервалы в течение 30 секунд с момента получения первой дейтаграммы. Таким образом формируется первоначальный список просмотра.

Все компьютеры с включенной функцией File and Printer Sharing for Microsoft Networks заявляют о себе при инициализации системы, а также каждые 12 минут после этого, передавая соответствующим главным браузерам на имя domain_name <1Dh> дейтаграмму Host Announcement. Данные сведения сохраняются каждым главным браузером.

Все главные браузеры сети IP отыскивают главный браузер соответствующего домена и затем заявляют о себе главному браузеру домена при назначении последнего, а также после этого раз в 12 минут. Эти объявления создаются с помощью дейтаграммы Master Browser Announcement, которую соответствующий главный браузер направляет на имя domain_master_browser_name<00>.

Каждый главный браузер заявляет о себе потенциальным браузерам своего сетевого сегмента при получении статуса главного браузера и далее раз в 12 минут. Эти данные передаются с помощью дейтаграммы Local Master Announcement, направляемой на имя domain_name<1Eh>. В данном объявлении резервным браузерам сообщается имя главного браузера. Если этот пакет получает компьютер, полагающий, что именно он является главным браузером, получивший пакет компьютер инициирует новую процедуру выбора браузера, что и разрешает конфликтную ситуацию.

Раз в 12 минут главный браузер домена через интерфейс прикладного программирования NetServerEnum запрашивает список просмотра у каждого главного браузера. При этом вызов направляется главным браузером домена на IP-адрес каждого главного браузера (разрешенный из NetBIOS-имени master_browser_name<00h>).

Раз в 12 минут каждый главный браузер запрашивает у главного браузера домена глобальный список просмотра с помощью интерфейса NetServerEnum. Главный браузер направляет вызов на IP-адрес главного браузера домена (разрешенный из NetBIOS-имени domain_master_browser_name<00h>).

Раз в 12 минут каждый резервный браузер запрашивает глобальный список просмотра у своего главного браузера.

Главные браузеры сообщают о себе другим доменам или рабочим группам сетевого сегмента раз в 15 минут с помощью дейтаграммы Workgroup Announcement, которую главный браузер передает в широковещательном режиме на NetBIOS-имя ..__MSBROWSE_.<01H>, регистрируемое всеми главными браузерами.

Если в ходе трех следующих один за другим сеансов передачи объявлений браузер не получает от передающего компьютера каких-либо данных, он удаляет соответствующую запись из своего списка просмотра. Так, если главный браузер домена три раза подряд (т.е. в течение 36 минут) не получает данных от главного браузера, этот главный браузер домена удаляет из своего глобального списка просмотра все записи, сделанные ранее на основании полученной от умолкнувшего главного браузера информации. Подобным же образом, если главный браузер в течение трех сеансов связи подряд не получает от какого-либо компьютера дейтаграмму Host Announcement, данный главный браузер удаляет такой компьютер из своего списка просмотра.

При первом инициированном клиентским приложением запросе списка просмотра с помощью интерфейса NetServerEnum API клиент инициирует процесс, направляя на имя domain_name<1Dh> дейтаграмму Get Backup List Request. В ответ главный браузер направляет список резервных браузеров, который может включать в себя и направляющий сообщение главный браузер. Затем клиент направляет одному из этих браузеров NetServerEnum-запрос. Когда пользователь пытается получить информацию о другом домене или рабочей группе, клиентская машина запрашивает список браузеров для этого домена или рабочей группы, а затем запрашивает список просмотра у одного из этих браузеров.

По умолчанию обмен обновленными версиями списков просмотра между главным браузером домена и главными браузерами происходит раз в 12 минут. Между тем, в “Белой книге” Microsoft “MS Windows NT Browser” утверждается, что интервал обмена обновленными списками составляет 15 минут. Я провел мониторинг своей сети, в которую входит домен NT и домен Windows 2000 AD с пакетом Windows .NET Enterprise Server (Win.NET Enterprise Server – новое название Windows 2000 Advanced Server) третьей бета-версии, с системами Windows 2000 AS, NT Server, Windows 2000 Pro и с XP Professional Edition (все они выступают в качестве браузеров многосегментной сети). Трассировка пакетов показала, что интервал составляет именно 12 минут.

В IP-сетях служба Computer Browser использует как протокол TCP, так и протокол UDP. Главный браузер и главный браузер домена обмениваются списками просмотра по протоколу NetBIOS поверх TCP/IP (NetBT), что обеспечивает более надежную связь. Для передачи данных по всем другим каналам используется UDP, IP-протокол без установления соединения, не гарантирующий доставки пакетов. Точнее говоря, в этих каналах связи UDP используется реализация протокола Common Internet File System (CIFS), который, в свою очередь, представляет собой усовершенствованную версию протокола файловой системы, именуемого Server Message Block (SMB).

Поскольку успешная доставка браузерных дейтаграмм не гарантируется, целевая служба Computer Browser иногда не обеспечивает получение дейтаграмм в сети с интенсивным трафиком или на загруженном сервере. В результате бывает и так, что успешная передача обновленной информации осуществляется лишь по истечении нескольких интервалов между сеансами обмена обновленными списками. Иначе говоря, механизм доставки дейтаграмм далек от совершенства, и потому служба Computer Browser удаляет старую информацию из списка просмотра лишь после того, как данный браузер не получает данных от передающего компьютера на протяжении трех сеансов связи подряд. Надо сказать, что при выключении каждый компьютер четко извещает об этом главный браузер, однако система, которая отключается внезапно, остается в списке просмотра ее главного браузера в течение 36 минут. А поскольку до того момента, когда резервный браузер другого сетевого сегмента получит обновленный список просмотра, может пройти еще целых 36 минут, компьютер может оставаться в списке просмотра другого сетевого сегмента до 72 минут с момента завершения работы.

Понимание механизма работы службы Computer Browser поможет вам успешно решать проблемы диагностики. Более подробный анализ службы Computer Browser содержится в разделе “Appendix 1 – Windows 2000 Browser Server” материала Windows 2000 Server TCP/IP Core Networking Guide. В будущем я намерен посвятить одну из статей инструментальным средствам и процедурам, позволяющим решать проблемы, которые возникают при работе со службой Computer Browser.