В статье
"Служба Computer Browser" я рассказал о службе просмотра ресурсов
Microsoft Computer Browser, которая ведет списки доменов, рабочих групп и
компьютеров в сети Windows, а также сетевого оборудования, работающего на
основе протокола NetBIOS. Эти списки - источник информации, которую
пользователи могут увидеть, открыв раздел Network Neighborhood в Windows
Explorer. В сетях на базе Windows 2000 на смену Computer Browser пришла служба
Active Directory (AD). Однако Computer Browser по-прежнему используется в
смешанных сетях 2000/NT с контроллерами доменов (DC), унаследованными от
прежних версий Windows, и в сетях с несовместимыми с AD клиентами.
При
использовании службы Computer Browser главный компьютер, выполняющий роль
браузера (далее – просто браузер) домена IP-сети взаимодействует с главными
браузерами сегментов сети. Для подготовки списков компьютеров и другого
оборудования используется преобразование имен NetBIOS и несколько специальных
имен NetBIOS. Но что делать в случае отказа службы Computer Browser? Чтобы
исправить неполадки, необходимо владеть инструментами и процедурами диагностики
службы Computer Browser.
Ошибки в
преобразовании имен NetBIOS - главная причина незавершенности многих списков
ресурсов. Большинства этих проблем удается избежать, если в сети реализована
надежная подсистема преобразования имен. В Microsoft рекомендуют для
преобразования имен NetBIOS использовать службу WINS. В сети с несколькими
широковещательными доменами (то есть в сети, сегментированной маршрутизаторами
или виртуальными локальными сетями) гораздо проще обслуживать систему
WINS-серверов, чем вести клиентские файлы LMHOSTS.
Я думаю,
большинству администраторов WINS-серверов приходилось иметь дело с неполадками
в базе данных WINS, которые, по-видимому, возникают из-за ее территориальной
распределенности. Чтобы избежать типичных проблем с WINS и просмотром ресурсов,
следует сделать базу WINS как можно более компактной и удалить из нее
устаревшую информацию. Подробное описание WINS приведено по адресу http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/reskit/tcp/ip/
part2/tcpch07.asp.
Причиной
неполадок могут быть ошибки в преобразовании имен NetBIOS. Во врезке "Этапы
преобразования имен NetBIOS" приведена последовательность запросов,
направляемых Windows к различным источникам в процессе разрешения имен NetBIOS.
Эти сведения могут оказаться полезными при поиске точки отказа.
Browmon и Browstat
Microsoft
предлагает два инструмента специально для мониторинга и диагностики Browser
Service: Browser Monitor (Browmon - browmon.exe) и Browser Status (Browstat -
browstat.exe). Работая с любым из них, следует помнить, что возможности этих
средств ограничены компьютером, на котором они размещены. В многопротокольной
сети оба инструмента составляют списки ресурсов только для протоколов,
поддерживаемых локальным компьютером.
Browmon – графическая утилита из
комплектов ресурсов Microsoft Windows NT Server 4.0 Resource Kit и Microsoft
Windows 2000 Resource Kit. В каждом контролируемом домене утилита показывает
состояние подсистемы просмотра ресурсов для всех протоколов (Экран
1). Дважды щелкнув на названии протокола, можно получить подробную
информацию (Экран
2), в том числе имена основного и резервного браузеров, сведения о доменах
и серверах в списке ресурсов каждого браузера.
Browmon
сообщает данные о наличии изменений в домене, то есть утилите видны только
основной и резервный браузеры локального сегмента. С помощью Browmon можно
быстро выяснить, какие компьютеры используются в качестве основных и резервных
браузеров в доменах, и сравнить списки ресурсов этих браузеров. Browmon
автоматически обновляет окно через интервал времени, указанный пользователем.
Browstat - более мощный инструмент. Помимо
отображения списков ресурсов и имен компьютеров-браузеров, с помощью Browstat
можно принудительно инициировать процедуру выбора и перезапустить главный
браузер. Старая версия Browstat входит в состав комплекта ресурсов NT 4.0;
обновленная версия поставляется в наборе Windows 2000 Support Tools. Обе версии
наделены одинаковыми функциями диагностики, но пользоваться версией Windows
2000 проще. В прежней версии каждую команду нужно было дополнить именем
протокола, как видно на примере команды Net Config Rdr. Если ввести команду
net config rdr
на рабочей
станции Windows Professional, то имя протокола TCP/IP будет иметь вид
NetBT_Tcpip_{3F14F1D1-F77B-410E-8040-7582A8A889A2}. Таким образом, чтобы
увидеть список резервных браузеров, в прежней версии Browstat требовалось
ввести следующую команду:
browstat gb NetBT_Tcpip_{3F14F1D1-F77B-410E-8040-
7582A8A889A2}
Gb, или
Getblist - подкоманда Browstat, с помощью которой можно получить список
браузеров. Как мы видим, на некоторых машинах имена протоколов весьма длинные.
В версии
Browstat для Windows 2000 существует подкоманда Dumpnet, которая отображает
имена протоколов и назначает каждому из них односимвольный номер. Этот номер
можно использовать вместо имени протокола со всеми другими подкомандами. На
моей системе Windows 2000 команда
browstat dumpnet
ассоциирует
номер 2 с протоколом TCP/IP, связанным с сетевой платой (назначаемое число
зависит от порядка привязки, поэтому оно будет для разных систем различным).
Команда
browstat gb 2
отображает
список резервных браузеров.
Работая с
прежними версиями Browstat, я подготавливал двухстрочный командный файл с
жестко закодированным именем протокола. В Листинге
1 показан такой файл для IP-протокола с именем NetBT_DC21x41. Затем я могу
вызвать файл и без труда запустить любую команду Browstat, в которой
используется названный в файле протокол. Например, если назвать файл (см.
Листинга 1) browip.cmd и поместить его в путь поиска, то команда
browip view mydomain
представит
список ресурсов для протокола с данным именем в домене MYDOMAIN.
Следует
обратить внимание, что для использования этого командного файла необходимо
заменить NetBT_DC21x41 полным именем протокола, установленного на компьютере,
на котором выполняется Browstat. При запуске Net Config Rdr в разделе выходных
данных, следующем за словами "Workstation active on", указывается
полное имя протокола, MAC-адрес каждого сетевого адаптера и протокол, связанный
со службой Workstation. На моей системе Windows 2000 Pro команда Net Config Rdr
отобразила строку Tcpip_{3F14F1D1-F77B-410E-8040-7582A8A889A2} (0030843E6609)
для протокола TCP/IP. Требуется полное имя протокола - в данном случае, полная
строка символов, начинающаяся с NetBT вместе с закрывающей скобкой (}) - но не
MAC-адрес, указанный в скобках после имени протокола.
Практические приемы
Чтобы
избежать проблем при просмотре, я рекомендую использовать следующие приемы:
·
На
компьютере с несколькими сетевыми платами следует присвоить параметру реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Browser\Parameters\MaintainServerList
значение No, чтобы компьютер не мог играть роль активного браузера.
·
Определить,
какие компьютеры играют роль главного браузера в каждом сегменте. В каждом
сегменте следует присвоить параметру реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrebtControlSetServices
\Browser\Parameters\IsDomainMaster
значение True на одном или двух серверах. Если в сегменте лишь один сервер, то
следует выбрать одну или две рабочие станции для выполнения роли браузера в
случае отказа сервера. Процедура выборов организована так, что IsDomainMaster =
True принесет рабочей станции победу в голосовании лишь в том случае, если в
сетевом сегменте нет ни одного сервера.
·
Следует
убедиться, что каждый потенциальный главный браузер сегмента может найти
главный браузер домена, то есть может преобразовать NetBIOS-имя
domain_name<1Bh>. Если все главные браузеры настроены на использование
работающей подсистемы WINS, то они смогут обнаружить главный браузер домена.
AD-совместимые машины могут попросить AD найти главный браузер домена. В
отсутствие WINS и AD нужно настроить каждый потенциальный браузер в сетевых
сегментах, в которых нет главного контроллера домена (PDC), на использование
файла LMHOSTS.
Предположим,
что существует домен с именем NetBIOS – MYDOMAIN - и PDC с именем NetBIOS - DC1
по IP-адресу 192.168.0.1. Файл LMHOSTS должен содержать записи, показанные в Листинге
2. Первая запись явно задает преобразование имени для имени NetBIOS
domain_name<1Bh>. Имя домена, вместе с шестнадцатеричным символом в
позиции 16, следует заключить в двойные кавычки. Шестнадцатеричные числа
обозначаются в файле обратной наклонной чертой, цифрой 0 и буквой x (\0x), как
показано в Листинге 2. После имени домена и перед обратной косой чертой следует
добавить пробелы, чтобы обратная косая черта оказалась в позиции 16. Вторая
запись идентифицирует DC1 как контроллер домена MYDOMAIN и генерирует групповую
запись MYDOMAIN<1Ch> и записи для DC1, привязывающие его к службам
Workstation, Messenger и Server. Имена домена, компьютера, PRE и DOM следует
ввести заглавными буквами. Команда
nbstat -R
загружает
файл LMHOSTS (следует указать -R, а не -r; ключ -R перезагружает кэш, а ключ -r
выводит статистические данные). Проверить результаты можно с помощью команды
nbstat -c.
Процедура диагностики
Успешный
просмотр ресурсов - результат сложного взаимодействия между многими базовыми
подсистемами Windows, поэтому универсальной процедуры диагностики нет. Выбор
процедуры определяют внешние признаки неполадки. Успех часто зависит от того,
насколько полно и точно администратор представляет сетевую структуру.
Я не могу
рекомендовать универсальную процедуру, но могу описать, как действовать в одном
типичном сценарии: если в клиентском списке ресурсов отсутствует один или
несколько компьютеров (возможно, все компьютеры) из одного домена
широковещательной рассылки. В ходе диагностики всегда полезно представить себя
"на месте компьютера" - я прохожу по этапам известного мне процесса
до тех пор, пока не обнаруживаю неисправное звено. Таким образом, моя процедура
диагностики прослеживает список ресурсов, начиная с домена широковещательной
рассылки, в котором находится "потерянный" компьютер, до неполного
списка ресурсов широковещательного домена клиента.
Процедура
предполагает, что отсутствующий в списке просмотра компьютер проверен,
функционирует исправно и имеет надежную связь с сетью. В процессе работы будет
обнаружена неисправность в системе, и выяснятся конкретные элементы, которые
нужно проверить, чтобы отыскать слабое звено. Рассматривая проблему, следует
помнить, что она может возникнуть, если произошли ошибки в преобразовании имен;
если главный браузер подключен к нескольким сетям; если в одном или нескольких
компьютерах элементу реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\LanmanServer\Parameters\Hidden
присвоено значение 1; если главный браузер сегмента не получил объявление от
компьютера; если главный браузер и "потерянный" компьютер не имеют
общих активных транспортных протоколов для NetBIOS.
Работу
лучше начать с компьютера в том же широковещательном домене, в котором
находится сегмент проверяемого главного браузера, чтобы на тестовую процедуру
не повлияли потенциальные проблемы маршрутизации или WINS-сервера. При
выполнении следующих действий предполагается, что используется версия Browstat
для Windows 2000, протокол номер 2, домен с названием MYDOMAIN, PDC с именем
DC1, главный браузер сегмента с именем SERVER1 и резервный браузер с именем
BACKUP1.
1. Обнаружение главного браузера сегмента, к
которому принадлежит "пропавший" компьютер.
После
ввода команды
browstat status
утилита Browstat должна показать имена главного и резервного браузеров сегмента и текущий список ресурсов. Чтобы получить эту информацию, Browstat преобразует имя NetBIOS domain_name<1Dh> в адрес главного браузера сегмента. После того, как будет выбран главный браузер сегмента, его служба Computer Browser регистрирует имя domain_name<1Dh> в NetBIOS, но не WINS. В результате имя преобразуется в IP-адрес главного браузера локального сегмента в процессе преобразования широковещательных имен.
Если Browstat не обнаруживает главный браузер сегмента, то следует убедиться, что хотя бы один компьютер в сетевом сегменте может играть роль браузера. Затем нужно принудительно назначить браузер, для чего существует один или два способа. Во-первых, в сетевом сегменте "потерянного" компьютера следует остановить и перезапустить службу Computer Browser на DC или компьютере, параметру реестра которого HKEY_LOCAL_MACHINE\SYSTEM\CurrebtControlSetServices \Browser\Parameters\IsDomainMaster присвоено значение True. Иначе следует ввести команду
browstat elect 2 mydomain
2. Проверка полноты списка просмотра главного
браузера сегмента.
В
результате ввода команды
browstat view 2 \\server1
утилита
Browstat получит список ресурсов с сервера, указанного в командной строке. В
списке приведены коды служб, выполняемых на каждом компьютере. MBR - код
главного браузера, PBR указывает, что компьютер потенциально может быть
браузером, и BBR - код резервного браузера.
Если в
списке просмотра содержатся только компьютеры локального сетевого сегмента, то
велика вероятность, что главный браузер сегмента не сможет установить контакт с
главным браузером домена (то есть, PDC). Это может указывать на проблемы
маршрутизации или ошибку в преобразовании имен. Чтобы определить, может ли
главный браузер сегмента получить имя PDC, следует ввести команду
browstat getpdc 2 mydomain
на главном
браузере сегмента. В результате компьютер, выполнивший команду, посылает запрос
NetBIOS на преобразование имени domain_name<1Bh> в соответствии с
указанным транспортным протоколом. В случае успеха возвращается имя PDC.
Если
выполнить команду не удается, то имя PDC можно узнать другим способом. Утилита
Server Manager домена NT 4.0 сообщает, на какой компьютер возложена роль PDC. В
сети Windows 2000 AD роль PDC выполняет компьютер - мастер операций. Чтобы
определить владельца роли PDC FSMO, следует открыть оснастку Active Directory
Users and Computers консоли Microsoft Management Console (MMC) на DC или другой
машине, на которой установлены инструменты Windows 2000 Administration Tools.
Щелкнув на домене, следует выбрать пункт Operations Masters из меню Action.
Затем нужно щелкнуть на закладке PDC, чтобы увидеть текущего мастера роли PDC.
В домене AD с WINS, DC, выполняющий роль мастера PDC (также называемый
эмулятором PDC), регистрирует имя domain_name<1Bh> в WINS для
использования несовместимыми с AD компьютерами и приложениями.
Если имя
PDC нельзя получить с помощью команды Browstat Getpdc, то необходимо устранить
проблему с преобразованием имен.
Чтобы
получить друг от друга списки просмотра, главные браузеры домена и сегмента
должны иметь возможность взаимно преобразовывать имена
computer_name<00h>. Подключившись к диску главного браузера сегмента с главного
браузера домена, можно проверить способность двух машин к преобразованию имен
computer_name<00h> друг друга.
Если
компьютер в списке ресурсов главного браузера сегмента отсутствует, можно
воспользоваться подкомандой Browstat, чтобы все компьютеры объявили о себе:
browstat forceannounce 2 mydomain
После
принудительного объявления придется довольно долго ждать, когда будет готов
полный список ресурсов. Получив список, можно продолжить диагностику.
3. Проверка списка ресурсов главного браузера
домена.
Чтобы
отобразить список ресурсов главного браузера домена, следует ввести команду
browstat view 2 \\dc1
(DC1 - имя
главного браузера домена, или PDC). Если "потерянный" компьютер
содержится в списке главного браузера сегмента, но отсутствует в списке
главного браузера домена, то следует проверить правильность преобразования имен
на этапе 2.
4. Обнаружение главного браузера
сегмента клиентской сети и проверка его списка ресурсов.
Если в
списке ресурсов главного браузера домена нет пропусков, то источник проблемы -
клиент домена широковещательной рассылки или канал связи между клиентом и
главным браузером домена. Следует повторить действия, описанные на этапах 1 и
2, чтобы отыскать главный браузер сегмента клиентского компьютера и проверить
его список просмотра. Если этот список не полон, то нужно проверить
правильность преобразования имен, как описано на этапе 2. Если список ресурсов
полон, то причиной неполадки могут быть резервные браузеры сегмента.
5. Обнаружение резервных браузеров сегмента и
проверка их списков ресурсов.
Клиент
может получить список ресурсов с любого браузера в сетевом сегменте, поэтому
неполадки на резервном браузере могут привести к тому, что информация на
клиенте будет недостаточно полной. Передача изменений с главного браузера
сегмента на резервный браузер в том же сегменте может занять до 12 минут.
С помощью
утилит Browmon и Browstat можно определить, какие компьютеры используются в
качестве резервных браузеров в домене широковещательной рассылки клиентского
компьютера, и сравнить текущие списки резервных браузеров. В утилите Browmon на
пиктограммах резервных браузеров нет красной точки. Иначе можно ввести команду
browstat status
чтобы
получить имена резервных браузеров для каждого транспортного протокола в
локальном сетевом сегменте.
Для каждого
резервного браузера следует ввести команду
browstat view 2 \\backup1
Затем
необходимо проверить все списки ресурсов. Если обнаружен неполный список, то
следует проверить возможность преобразования имени
segment_master_browser<00h>, отобразив диск резервного браузера на
главный браузер сегмента.
Многодоменная диагностика
В списке
ресурсов могут содержаться имена других доменов. Главный браузер одного домена,
подключенный к сетевому сегменту, получает сообщения от главных браузеров
других доменов, существующих в том же сетевом сегменте. Главные браузеры
домена, настроенные на использование WINS, периодически запрашивают в базе
данных WINS записи domain_name<1Dh>. Затем браузеры включают обнаруженные
домены в свои списки ресурсов.
Чтобы
исследовать обнаруженный домен, клиент запрашивает список ресурсов для этого
домена в браузере домена, в главном браузере, сделавшем объявление, или в
реестре WINS. Если клиент может преобразовать имя браузера, то он сможет также
просмотреть ресурсы домена и даже увидеть компьютер в списке ресурсов, правда,
компьютер останется для него недоступным. Кроме того, клиент должен
преобразовать адрес компьютера, и поскольку браузеры могут удалить компьютер из
списка ресурсов с опозданием, машина может отсутствовать в сети в тот момент,
когда клиент пытается обратиться к нему.
Диагностика
системы Computer Browser может оказаться сложной задачей, требующей
исчерпывающих знаний о сетевых подсистемах Windows. Однако, проявив немного
терпения, разобравшись в работе Windows и имея необходимые инструменты, можно
успешно решить проблему.
Джон Грин - старший обозреватель программных продуктов в журналах SQL Server Magazine и Windows 2000 Magazine. С ним можно связаться по адресу: jgreen@win2000mag.com.