Ремонт папок Namespace на DFS
Добрый день! Уважаемые читатели и гости блога. В сегодняшней статье я хочу с вами разобрать траблшутинг DFS шар и адресных пространств в периметре Active Directory. Давно у меня руки не доходили для себя систематизировать свои накопленные знания в данном направлении. Суть проблемы, предположим, что есть сетевая файловая шара, которая в 2-3% случаев становится недоступна, через какое-то время при попытке в нее попасть все открывается успешно. В логах системы особенно ничего криминального нет. Вопрос как понять, почему, так и как это диагностировать.
Методы диагностики DFS NameSpace
На одном из серверов RDS фермы, сотрудник работает с файловой шарой, при попытке в нее попасть у него выскакивала ошибка:
Folder is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
Через некоторое время, ошибка исчезала и все открывалось. Первое, что вы должны сделать это открыть оснастку DFS Management и определить куда у вас ссылаются ваши namespace на DFS хостах. В моем примере есть NameSpace с именем 1cbase и его расположение ссылается на сетевую папку, расположенную на 4 контроллерах домена.
Путешествуя по всем 4 контроллерам домена, на которых располагается точка входа в это адресное пространство, я обнаружил что на одном из них папка была пуста, хотя линк до нее в DFS Management был активен.
В результате в 25% процентах случаев, это могло аффектить доступ до файловых ресурсов в данном NameSpace.
В нормальном состоянии данная папка должна выглядеть вот так и вмещать в себя список DFS папок опубликованных в
Ранее я вам показывал команды показывающие DFS кэш, что очень полезно при диагностике. Я на всех DFS нодах попытался открыть нужный сетевой путь, чтобы он попал в кэш. В итоге я подтвердил, что у одного пути есть ошибка:
AccessStatus: 0xc000003a (targetset)
Проверка наличия нужной записи в реестре
Когда вы используете DFS службы, они на серверах прописывают ваши Namespace в ветке реестра:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Domain и Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\domainV2
На сервере, где есть проблемы, как раз не хватает ключей реестра по-нужному Namespace.
В реестре не хватало вот такой записи:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Domain\1cbase]
"RootShare"="1cbase"
"LogicalShare"="1cbase"
Проверка атрибута DFS в AD
Еще перед работами советую проверить вот такую запись в вашем домене. Запустите AdsiEdit.msc и перейдите по пути в "Default naming contex':
CN=Dfs-Configurat,CN=System,DC=pyatilistnik,DC=org
Тут вам нужно найти нужный вам Namespace, открыть его свойства и найти атрибут RemoteServerName, открыв его удостоверьтесь, что у вас в списке серверов есть нужный. В моем случае его не хватало.
Как устранить проблему
Перовое, что вы должны сделать в такой ситуации, это зайти на сервер DFS, где есть папка с пустым Namespace. Убедитесь, что она у вас расшарена по сети и у всех есть возможность ее прочитать.
Далее в оснастке DFS Management вам необходимо отключить сбойный Namespace Server, переведя его в статус "Disable". Далее его нужно удалить из списка.
Подтвердите удаление данного сервера из списка.
Еще раз подтверждаем, что данный DFS сервер будет убран из списка "Namespace Servers"
После успешного удаления, добавляем его снова. Единственное, перед окончательным нажатием кнопки "Ok", обязательно допишите полное FQDN-имя сервера, чтобы в будущем не было проблем с короткими именами.
Как только сервер был добавлен, на нем сразу прописался нужный раздел в реестре, и обновился атрибут RemoteServerName
Дополнительный метод
Если вы по каким-то причинам не хотите производить удаление сервера из списка Namespace, то вы можете произвести экспорт нужных ключей реестра с работающего DFS сервера
В итоге у вас будет reg файл с приблизительно вот таким содержанием:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Domain\1cbase]
"RootShare"="1cbase"
"LogicalShare"="1cbase"
Дополнительный траблшутинг DFS
Еще в одном из сценариев на тестовом стенде я встретил ситуацию, что при проверке кэша DFS была ошибка:
AccessStatus: 0xc00000cc (TARGETSET)
тут причиной оказалось, что таких сетевых папок просто нет на DFS сервере, указанном в ошибке. Проверить это можно командой:
net share