Microsoft Windows NT Server, Enterprise Edition version 4.0
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server
РЕЗЮМЕ
Хотя нет никакого централизованного метода определить, получен ли список обзора через WAN, есть методы, определяющие, представлены ли серверы в частном сегменте в списке обзора в удаленном сегменте. Эти же самые методы могут применяться на все сегменты всей WAN. Однако, результаты этих испытаний могут изменяться, если изменяются роли серверов, когда происходят выборы браузера. Только, если все серверы в домене всей WAN полностью статичны, и ни один из серверов не подключаются и не отключаются, результаты этих тестов будут реальными.
Тесты, которые описаны ниже, полагаются на утилиту Browstat.exe из Microsoft Windows NT Resource Kit. Пример вывода будет только для TCP/IP протокола. Также, как с диагностикой большинства сетевых проблем, чтобы решить проблемы службы браузера, администратор должен иметь полное знание сетевых границ сегмента и конфигураций маршрутизатора сети. Как пример, предположите, что клиент на удаленном сегменте не имеет сервера в своем списке обзора, который расположен в другом сегменте.
Поскольку служба обозревателя чувствительна ко времени, Вы не должны исполнять эти шаги, пока не пройдет 48-минутный цикл (полный цикл распространения в мульти-сегментном домене).
ИНФОРМАЦИЯ
Найдите главный браузер в сегменте, в котором расположен сервер. Выполните эту команду в сегменте, в котором постоянно теряется сервер:
browstat status
Вы должны получить подобный ответ:
Status for domain DomainName on transport DeviceNetBT_IEEPRO1
Browsing is active on domain.
Master browser name is: MasterBrowser
Master browser is running build 1381
1 backup servers retrieved from master BackupBrowser
SmallerServer
There are 100 servers in domain DomainName on transport
DeviceNetBT_IEEPRO1
There are 1500 domains in domain DomainName on transport
DeviceNetBT_IEEPRO1
Состояние для домена DomainName на транспорте DeviceNetBT_IEEPRO1
Просмотр в домене активен.
Имя главного браузера: MasterBrowser
Главный браузер выполняется, сборка 1381
1 резервный сервер, найден из главного BackupBrowser
SmallerServer
Есть 100 серверов в домене DomainName на транспорте
DeviceNetBT_IEEPRO1
Есть 1500 доменов в домене DomainName на транспорте
DeviceNetBT_IEEPRO1
Эта информация должна показать, какой сервер действует как главный браузер в сегменте. Однако, если локальный главный браузер не спешил отвечать, эта информация, возможно, была получена от другого главного браузера.
Результаты этой команды дают Вам строку "DeviceProtocol_NIC", которую Вы можете использовать с другими browstat командами.
Чтобы найти локальный главный браузер в сегменте клиента, выполните следующую команду:
browstat getmaster devicenetbt_el59x1 domainname
Использовании ключей status или getmaster посылает DomainName<1d> запрос и возвращает текущий главный браузер для этого сегмента. Служба обозревателя не используется, чтобы найти компьютер, который действует как главный браузер. Вы можете выполнять этот шаг дистанционно, если служба самого браузера используется для указания, какие компьютеры действуют как главный браузер в сегменте, но для этого необходимо, чтобы администратор знал имена всех серверов в каждом из сегментов. Также, это - плохая методика решения проблемы, потому что служба браузера используется, чтобы решить проблемы самого браузера. И даже если эта часть браузера не имеет проблемы, список, который возвращается, может быть устаревшим вплоть до 36 минут. Чтобы дистанционно определять список главных браузеров в домене, выполните следующую команду:
Затем, администратор должен определить, какой главный браузер в сегменте содержит имена отсутствующих серверов.
Если главный браузер не может быть найден, Вы можете перезапускать службу браузера на контроллере домена, который находится в сегменте сервера. А затем, через несколько минут, выполните этот тест снова. Либо, в консоли сервера, Вы можете выполнить следующую команду:
browstat elect devicenetbt__ieepro1 domainname
Определите, имеет ли главный браузер имя сервера в своем списке. Главный браузер - первый сервер в цепочке связи, которая должна содержать имя отсутствующего сервера. Этот тест определяет, получил ли главный браузер фрейм Host Announcement. Обратите внимание что строка "device... " получена из результатов команды выполненной выше. Выполните следующую команду:
Missingserver NT 04.00 (W, S, NT, PBR, DFS) "Описание сервера"
Missingserver
Если имя сервера отсутствует, это - вероятно из-за проблем разрешения имени. Чтобы PDC (Главный контроллер домена) получил список серверов от главного браузера, главный браузер сервера должен разрешать имя DomainName<1b>, чтобы можно было послать направленный фрейм Master Announcement, используя 138 UDP порт. PDC, чтобы ответить на это объявление, и получить имя сервера, должен разрешать компьютерное имя главного браузера. (Главный браузер сервера, чтобы получить список домена с PDC, также, должен разрешать компьютерное имя PDC.)
Разрешение имени в обоих направлениях является критически важным. Чтобы проверить, что главный браузер сервера разрешает вход DomainName<1b>, выполните следующую команду:
browstat getpdc devicenetbt_el59x1 domainname
Чтобы проверить, что PDC и главный браузер понимают, компьютерные имена, друг друга, подключите сетевой диск от главного браузера к PDC и с PDC к главному браузеру. Если любой из этих вариантов не работает, решите проблему разрешения имени.
Определите главный браузер в сегменте клиента. Делайте это, используя те же самые шаги как в шаге 1, но в сегменте клиента.
Определите, имеет ли главный браузер имя отсутствующего сервера в сегменте клиента.
Если сервер есть, вывод должен быть подобен следующему:
Missingserver NT 04.00 (W, S, NT, PBR, DFS) "Описание сервера"
Missingserver
Если главный браузер не имеет имени отсутствующего сервера, это - вероятно из-за проблемы разрешения имени. Проверьте, что главный браузер в сегменте клиента разрешает имя DomainName<1b>, выполняя следующую команду:
browstat getpdc devicenetbt_el59x1 domainname
Также, главный браузер должен разрешать компьютерное имя PDC. Чтобы проверить это, подключите сетевой диск к PDC.
Если любой из этих тестов не работает, решите проблемы разрешения имен.
Определите резервные браузеры в сегменте клиента. Для уменьшения запросов в сегменте главного браузера, когда клиент запрашивает список обзора, этим занимаются резервные браузеры, если они доступны. Поэтому, наиболее вероятно, что все клиенты будут использовать резервные браузеры. Есть два способа определить локальные резервные браузеры для этого сегмента.
С консоли главного браузера, выполните следующую команду:
Определите, имеют ли резервные браузеры имя отсутствующего сервера. Для всех клиентов в сегменте, чтобы отыскать надежный список обзора, Вы должны проверить каждый резервный браузер для имени отсутствующего сервера. Для каждого резервного браузера, выполните следующую команду:
Если резервный браузер не содержит имя отсутствующего сервера, проверьте, может ли резервный браузер подключить сетевой диск к главному браузеру. Резервный браузер - более динамичен. Главные браузеры инструктируют потенциальные браузеры стать резервными в зависимости от загрузки браузера. Ждите 12 минут, а затем повторите шаги 6 и 7.
Многодомные проблемы
Примечание:Многодомный (Multihomed) компьютер - компьютер входящий в несколько сетевых групп, т.о. компьютер имеющий две сетевые карты можно считать многодомным.
Чтобы PDC создавал единственный доменый список, он не может являться многодомным сервером. Каждый главный браузер в удаленных сегментах будет устанавливать подключение с PDC. Поскольку нет никакой гарантии, что каждый главный браузер выберет тот же самый интерфейс к PDC, PDC должен быть однодомным, чтобы мог быть построен единственный доменный список. Также, все главные браузеры должны быть однодомными. Каждые 12 минут, главный браузер соединяется с PDC и запрашивает список домена. Однако, так как PDC не поддерживает отдельные IP адреса для каждого интерфейса на главном браузере, когда PDC соединяется с главным браузером, он только получает список компьютеров и серверов, который собран на этом частном интерфейсе.
Другие соображения
Чтобы избегать неустойчивые функциональные возможности браузера и не исполнять эти тесты, Вы можете выделить компьютеры в каждом сегменте для обслуживания непротиворечивого доменого списка. Если серверы часто перезагружают, подумайте о размещении BDC (Резервного контроллера домена), если число сегментов - не велико, или сократите до минимума количество серверов на Windows NT в каждом сегменте с ключом системного реестра IsDomainMaster, установленным в True. Это даст серверу преимущество во время выборов главного браузера в сегменте.
Ошибку "конфликт имени" Вы можете проверить, выполнив следующую команду:
nbtstat -n
Вы можете использовать эту команду дистанционно, используя ключ -a или-A.
Браузер очень чувствителен к конфигурации маршрутизаторов WAN.
Другой вариант, который Вы можете попробовать, чтобы решить проблемы, это сбор данных сетевого трафика анализатором протокола, типа Microsoft Network Monitor. Чтобы непосредственно рассмотреть изменения браузера, Вы можете перезапускать службу обозревателя. К сожалению, нет никакой гарантии, что браузер примет ту же самую роль, после того, как Вы перезапустите службу обозревателя. Однако, этот метод может быть особенно полезен, чтобы проверить связь, когда главный браузер запрашивает список домена от PDC, и немедленно следующие затем PDC запросы локального списка от главного браузера. После того, как служба обозревателя запустилась на главном браузере, в пределах одной или двух минут, должен пройти полный обмен. Сконфигурируйте буфер анализатора протокола и размер фрейма, чтобы учесть это количество трафика.
Список серверов, возвращенных службой обзора предшествующей Windows NT 4.0 был ограничен 64 КB. Когда этот размер превышен, Вы увидете усеченный алфавитный список серверов. Чтобы избегать этого, все браузеры должны быть Windows NT версии 4.0 или выше.
ССЫЛКИ
Для получения дополнительной информации, прочтите "Microsoft Windows NT Browser":
