Длинная пауза при доступе к пространству имен DFS
У меня когда-то была проблема со слушанием Skype порта 80, если это было запущено, в то время как IIS не был. Если Skype занимает порт 80, можно решить эту проблему, изменяющую настройки Skype:
File > Options > Connection
Снимите флажок "С Портом использования 80 и 443 как альтернативы для входящих соединений". Необходимо смочь перезапустить веб-сайт по умолчанию теперь.
Ну, мы наконец, кажется, решили этот вопрос в нашей среде. Для преимуществ других вот то, что мы обнаружили и как мы решили проблему:
Попытаться получить дальнейшее понимание, что происходило прежде чем/во время/после того, как задержек, мы использовали Wireshark на клиентской машине для получения/анализирования сетевого трафика, пока тот клиент попытался получить доступ к доле DFS.
Эти получения показали что-то странное: каждый раз, когда задержка произошла, промежуточная запрос DFS, отправляемый от клиента к DC и направления к корневому серверу DFS, возвращающемуся от DC до клиента, DC отсылал несколько широковещательных поисков имени в сеть.
Во-первых, DC широковещательно передал бы поиск NetBIOS для ДОМЕНА (где ДОМЕН является нашим доменным именем Active Directory перед Windows 2000). Несколько секунд спустя это широковещательно передало бы поиск LLMNR для ДОМЕНА. Это сопровождалось бы еще одной широковещательной передачей поиск NetBios для ДОМЕНА. После того, как эти три поиска были широковещательно переданы (и я принимаю приведенный к таймауту), DC наконец ответил бы клиенту с (корректным) направлением к корневому серверу DFS.
Эти широковещательные поиски имени для ДОМЕНА только отправлялись, когда длительная задержка, открытие долю DFS, произошла, и мы могли ясно видеть от получения Wireshark, что DC не возвращал направление корневому серверу DFS до всех трех поисков, отправленный (и ~7 секунд передали). Так, эти широковещательные поиски имени были, довольно очевидно, причиной наших задержек.
Теперь, когда мы знали, какова проблема была, мы начали пытаться выяснить, почему эти широковещательные поиски имени происходили. После немного большего количества поиска с помощью Google и некоторых эмпирических, мы нашли наш ответ: мы не установили ключ реестра DfsDnsConfig на наших контроллерах домена к 1, как требуется при использовании DFS в среде только для DNS.
Когда мы первоначально устанавливаем DFS в нашей среде, мы действительно читали различные статьи о том, как настроить DFS для среды только для DNS (например, Microsoft KB244380 и другие) и знали об этом ключе реестра, но имели misintepreted инструкции относительно того, когда/как использовать его.
KB244380 говорит:
Ключ реестра DFSDnsConfig должен быть добавлен к каждому серверу, который будет участвовать в пространстве имен DFS для всех компьютеров для понимания полностью определенных имен.
Мы думали, что это означало, что ключ реестра должен быть установлен на серверах пространства имен DFS только, не поняв, что он также требовался на контроллерах домена. После того, как мы устанавливаем DfsDnsConfig на 1 на наших контроллерах домена (и перезапустил "сервис" Пространства имен DFS), проблема исчезла.
Очевидно, мы довольны этим результатом, но я добавил бы, что я все еще не 100%, убежденных, что это - наша единственная проблема - интересно при добавлении, что DfsDnsConfig=1 к нашему DCS только работал вокруг проблемы, вместо того, чтобы решить его. Я не могу выяснить, почему DCS попробовал бы к ДОМЕНУ поиска (само доменное имя, а не сервер в домене) во время ссылаемого процесса DFS, даже в среде non-DNS-only, и я также знаю, что не установил DfsDnsConfig=1 на контроллерах домена в другом (по общему признанию намного меньший / более простой) среды только для DNS и не имел той же проблемы. Однако, мы решили нашу проблему, таким образом, мы счастливы.
Я надеюсь, что это полезно другим, кто испытывает подобную проблему - и еще раз спасибо тем, которые предложили предложения по пути.
Клиент кэширует направление DFS, т.е. когда Вы введете \domain.name\namespace, он будет кэшироваться, к которому относится фактический сервер domain.name. После того как направление истекает от кэша, клиент в основном должен "обнаружить" Вашу топологию DFS снова и снова, следовательно задержка.
Взгляните здесь: http://technet.microsoft.com/en-us/library/cc758234 (WS.10) .aspx и здесь http://blogs.technet.com/filecab/archive/2006/01/20/417832.aspx для дальнейшей информации о том, как это работает.
Возможные решения? hacky способ идти об этом мог бы состоять в том, чтобы записать небольшую программу, которая делает "поддержание" каждых нескольких минут; например, программа C, которую fopen's первый файл это находит и сразу fclose's это. Я не попробовал или протестировал это, и необходимо было бы определенно уделить некоторое внимательное внимание, если бы Вы собирались сделать это.
-
1Нормальное направление DFS shouldn' t берут, как секунды, тем не менее, как плакат указывают. – Evan Anderson 6 August 2009 в 15:11
-
2Спасибо, будет иметь чтение спасибо завтра к наименее лучшему, понимают ссылаемый процесс. Don' t как " solution" хотя :-S Если бы я просто хотел работать вокруг этого, то я мог бы сделать продолжительность Кэша огромным значением, но я хочу найти " proper" решение проблемы. – Matt 6 August 2009 в 16:10
Это могло быть вызвано упорядочиванием сетевой маски сервера DNS. Мы недавно столкнулись с этим в Сервере 2003. Это зависит от Вашего текущего разделения на подсети.
Пример.
Сайт 1: подсеть IP 10.0.0.0/24 Сайт 2: подсеть IP 10.0.1.0/24
Клиент в сайте 2 делает запрос DNS для Вашего основанного на домене пространства имен и будет дан сервер DFS в сайте 1 по умолчанию, поскольку сервер DNS не знает о границах IP сайта. Необходимо сказать серверы DNS что маску подсети использовать для идентификации который IP-адреса ответить.
-
1Спасибо, но we' ре, только имеющее дело с одним сайтом здесь - все рабочие станции и серверы, находится даже на той же подсети. – Matt 3 February 2010 в 10:17
У нас была подобно звучащая проблема, где пользователи испытали бы задержки (до минуты) между нажатием на диск, подключенный к доле DFS и способностью видеть и просмотреть к папкам в доле.
Пользователи также имели домашние диски, подключенные к другой доле DFS на том же объеме, и не имели никакой задержки при доступе к папкам там.
Различием между этими двумя является Основанное на доступе перечисление (ABE) - проблемная доля имеет, это включило (это - обычный диск для пользователей с тысячами папок - ABE означает, что пользователи только видят те папки, к которым у них есть полномочия).
Отключение ABE удалило проблему полностью. Очевидно, это не решение, поскольку пользователи затем видят все папки, путая их. Я копировал долю DFS в сервер с некоторым резервным диском как временная мера, и даже с ABE, включенным на этой новой цели, задержка пошла.
Проблемный сервер 2k3R2 и имеет время работы более чем 150 дней (!), таким образом, он собирается быть перезагруженным и иметь CHKDSK, работает на основе незаконного объема. Я отправлю назад здесь, если это будет иметь какое-либо значение к проблеме. Новая цель идет 2k8 сервер.
-
1Спасибо, но мы - not' t использующий ABE (все же), таким образом, этот isn' t проблема. – Matt 3 February 2010 в 10:18
dfsutil/spcflush и dfsutil/pktflush могут быть решением также во много сети сайта, удостоверяются, что ссылка DFS домашнего сайта появляется, формируют локальный сервер а не от кэша.
Вы упоминаете, что у Вас есть 20 серверов DFS, все же не удаются упомянуть, находятся ли все серверы в том же средстве.
Если эти серверы не находятся в том же средстве и друг друге, сайт имеет свой собственный домен, можно хотеть удостовериться, что клиентский возврат к состоянию до сбоя включен.
-
1У нас есть 20 DFS / пространства имен/, не 20 DFS/servers/. Только 2 сервера DFS, и в том же сайте (и в подсети). – Matt 3 February 2010 в 10:18
Запахи как проблема DNS, но что-либо идет. Я очень предпочел старый FRS, потому что инструменты диагностики как Ультразвук были настолько полезными:7
Вы получаете что-нибудь в журнале событий Репликации DFS на целях? (медицинский отчет DFS привлечет свои предупреждения из журнала событий),
Выполнение без WINS является хорошей целью и замечательный, хотя я в значительной степени против этого, если существует кто-либо pre-Vista/2008 системы Windows вокруг, поскольку вещи не всегда работают как ожидалось или как быстро без WINS, по моему опыту - хотя это действительно не должно иметь значения.
-
1We' ре, не используя Репликацию DFS, просто DFS для абстракции долей файла. Ваше ре комментариев среды только для DNS интересны, однако - много наших серверов, является Windows 2008, но всеми рабочими станциями является XP, и у нас также есть справедливое небольшое количество Windows 2003 серверы. Когда у меня есть шанс преследовать это далее, я думаю, что могу попытаться установить WINS и видеть, помогает ли это. – Matt 3 February 2010 в 10:22
Блог Команды Active Directory имеет Три статьи части ВСЕ о Задержках DFS.
http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx
Это покрывает основы на Ссылаемом процессе и затем показывает, как использовать различные инструменты включая dfsUtil и dfsDiag для обнаружения фактической причины задержек.
Это помогло мне найти свою проблему. Который не оказался никакими полномочиями Read на каталог доли для Пользователей домена.
HTH, Daniel
Я знаю, что в исходном плакате не использовался WINS, но я публикую его для других, так как мы использовали этот пост для решения очень похожей проблемы. Для нас это закончилось тем, что кто-то решил назвать свою рабочую станцию тем же именем, что и домен. Таким образом, каждый раз, когда контроллер домена выполнял поиск по доменному имени для ссылки DFS, он хотел разрешить эту рабочую станцию и вызывал значительную задержку в несколько десятков секунд. В WINS была помещена статическая запись 20, указывающая на DC, и это решило проблему. Если бы у вас не было WINS, вы могли бы поэкспериментировать с размещением доменного имени в качестве имени машины в файле LMHOSTS, указывающем на контроллер домена, чтобы получить поиск 20, и установить приоритет, чтобы LMHOSTS был первым местом, где нужно искать для разрешения имен netbios.
http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx This page actually mentions both Domain Controllers and DFSN, if that helps.
DFS Domain Controller and Root Server Registry Entries
The following registry entries are located under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs
on root servers and domain controllers. All entries are REG_DWORD.
Для тех, кто попадает сюда через поиск в Google и у кого такая же проблема ...
Сначала проверьте что все ссылки в вашем пространстве имен доступны и исправны. Вот что произошло в моем случае, в пространстве имен все еще была ссылка на неработающий сервер, поэтому долгая пауза при открытии DNS была вызвана тем, что поиск этого сервера завершился неудачей. Как только я отключил эту ссылку в DFS, длинная пауза исчезла.
Убедитесь, что группа Authenticated Users имеет доступ к списку содержимого корневой директории, к которой вы привязаны. Например, если диск x: отображен на \domain.local\departents\Marketing, то пользователю понадобится разрешение на список для \domain.local\departments. В 2008/2012 вы можете указать в разделе расширенных разрешений, что он применяется только к "Только для этой папки", чтобы им не разрешалось перечислять содержимое любых подпапок, которые могут наследовать разрешения.
.Итак, я использовал эту статью в своем поиске. Я все настроил, но проблемы остались. Потратив несколько дней на изучение проблемы и исключение всего «Microsoft», я решил, что это связано с сетью. Оказывается, проблема была в нашем WAN Accelerator . Я попросил наших сетевых специалистов отключить ускорение для наших контроллеров домена, и все стало лучше.
Было много контроллеров, как и сценарий ( dnsdfs.cmd servername ):
dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs