Решение проблем службы обозревателя компьютеров (Microsoft Computer Browser)
HashFlare
 
Главная HI-TECH Форум Поиск Книги Авторам Новости партнёров Реклама
Новостей на сайте: 10263
Программы  
  Система
  Безопасность
  Интернет и сети
  Текст
  Графика и дизайн
  Мультимедиа
  Программирование
  Бизнес
  Образование
  Дом, семья, хобби
  Игры и развлечения
 
Рассылка
 
HashFlare
 
Рейтинг программ...    
    Ф2Мастер Банк (138115)
    Коллекция руссификаторов O-S (34177)
    Товар версия 1.10 (25111)
    Коллекция софта № 13 (24431)
    New_Profile v3.4 (400) (23769)
    NetGraf 1.0 (23074)
    Revolter Commander 3.9 beta 8 (16211)
    Коллекция софта № 14 (15349)
    Net Transport 2.22 (15208)
    Intel Sound MAX 4.0 Ac' 97 5.12.01 (15072)
 

[!] Знаете ли Вы, что каждый может добавить программу в наш каталог абсолютно бесплатно?


Windows NT/2000 Статьи
Решение проблем службы обозревателя компьютеров (Microsoft Computer Browser)

Хотя нет никакого централизованного метода определить, получен ли список обзора через 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 view devicenetbt_ieepro1 pdcname | findstr /i mbr

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

Если главный браузер не может быть найден, Вы можете перезапускать службу браузера на контроллере домена, который находится в сегменте сервера. А затем, через несколько минут, выполните этот тест снова. Либо, в консоли сервера, Вы можете выполнить следующую команду:

browstat elect devicenetbt__ieepro1 domainname

Определите, имеет ли главный браузер имя сервера в своем списке. Главный браузер - первый сервер в цепочке связи, которая должна содержать имя отсутствующего сервера. Этот тест определяет, получил ли главный браузер фрейм Host Announcement. Обратите внимание что строка "device... " получена из результатов команды выполненной выше. Выполните следующую команду:

browstat view devicenetbt_ieepro1 masterbrowser | findstr/i missingserver

Если главный браузер имеет сервер в своем списке, команда возвратит подобный ответ:

Missingserver NT 04.00 (W, S, NT, PBR, DFS) "Описание сервера"

Missingserver

Если локальный главный браузер не имеет имени сервера, Вы можете выполнить следующую команду с любого компьютера в сегменте отсутствующего сервера:

browstat forceannounce devicenetbt_el59x1 domainname

Или, Вы можете выполнить следующую команду с консоли отсутствующего сервера:

browstat announce devicenetbt_el59x1 domainname

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

Также, Вы можете перезагрузить сервер, чтобы вынудить послать фрейм Host Announcement.

Определяем, получил ли PDC имя сервера от главного браузера. Выполните следующую команду:
browstat view devicenetbt_ieepro1 pdc | findstr/i missingserver

Вы должны увидеть подобный ответ:

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, но в сегменте клиента.
Определите, имеет ли главный браузер имя отсутствующего сервера в сегменте клиента.
browstat view devicenetbt_ieepro1 mbclientseg | findstr/i missingserver

Если сервер есть, вывод должен быть подобен следующему:

Missingserver NT 04.00 (W, S, NT, PBR, DFS) "Описание сервера"

Missingserver

Если главный браузер не имеет имени отсутствующего сервера, это - вероятно из-за проблемы разрешения имени. Проверьте, что главный браузер в сегменте клиента разрешает имя DomainName<1b>, выполняя следующую команду:

browstat getpdc devicenetbt_el59x1 domainname

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

Если любой из этих тестов не работает, решите проблемы разрешения имен.

Определите резервные браузеры в сегменте клиента. Для уменьшения запросов в сегменте главного браузера, когда клиент запрашивает список обзора, этим занимаются резервные браузеры, если они доступны. Поэтому, наиболее вероятно, что все клиенты будут использовать резервные браузеры. Есть два способа определить локальные резервные браузеры для этого сегмента.
С консоли главного браузера, выполните следующую команду:

browstat locallist devicenetbt_ieepro1 | findstr/i bbr

Она возвратит подобный список:

BackupBrowser NT 04.00 (W, S, BDC, NT, bbr, DFS) "Описание сервера"

BackupBrowser

При удаленном обращении к главному браузеру, выполните следующую команду:

browstat view devicenetbt_ieepro1 masterbrowser 0x40000000 | findstr/i bbr

ОБРАТИТЕ ВНИМАНИЕ: Эти флаги определены в следующем документе CIFS Browsing Protocol:
ftp://ftp.microsoft.com/developr/drg/cifs/cif%20sbrow.doc

Определите, имеют ли резервные браузеры имя отсутствующего сервера. Для всех клиентов в сегменте, чтобы отыскать надежный список обзора, Вы должны проверить каждый резервный браузер для имени отсутствующего сервера. Для каждого резервного браузера, выполните следующую команду:
browstat view devicenetbt_ieepro1 backupbrowser | findstr/i missingserver

Если резервный браузер не содержит имя отсутствующего сервера, проверьте, может ли резервный браузер подключить сетевой диск к главному браузеру. Резервный браузер - более динамичен. Главные браузеры инструктируют потенциальные браузеры стать резервными в зависимости от загрузки браузера. Ждите 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":

    http://www.microsoft.com/ntserver/commserv/techdetails/prodarch/ntbrowser.asp

    Источник: http://www.networkdoc.ru


  • Ссылки по теме:
    Память в Windows NT
    Службы Windows 2000 Server
    Доступ к журналу событий из командной строки
    Повышение надежности Windows 2000. Часть 1
    Решение проблем службы обозревателя компьютеров (Microsoft Computer Browser)



     
    Статьи    
      Windows 10
      Windows 8
      Windows 7
      Windows Vista
      Windows XP/2003
      Windows NT/2000
      Безопасность
      Windows 9x/ME
      Hardware
      Software
      Интернет
      BIOS
      Сеть
      Разное
     
    Рекомендуем
     
    http://cialis-24.com/ru/product/fliban-100 какие бывают женские возбудители.
     
    Рейтинг статей...    
        Предел входящих подключений в Windows (128320)
        Как установить Windows XP на ноутбук или как добавить SATA-драйвер в дистрибутив Windows XP (67906)
        Из дома в офис - быстро, надежно и безопасно (55197)
        Всё, что надо начинающему хакеру (48783)
        Восстановление реестра Windows XP (22990)
        Второй сервис-пак для Windows XP: личный опыт (22989)
        Вызываем синий экран смерти Windows (18222)
        Информация о proxy серверах (17032)
        Как устроена защита Windows Vista (16945)
        Настройка удаленного подключения между Windows 7 и Linux с помощью TightVNC (16810)
     
     
    Programmed by Ventura
     

     

    Яндекс цитирования