Редактировать: Я не был полностью осведомлен о том, что происходит с моей проблемой, но с тех пор она исправлена. Смотрите мой ответ ниже.
Задний план
У нас возникли некоторые проблемы с пространствами имен DFS в нашей среде после изменения того, как мы настроили нашу среду, и я искал некоторое представление о том, как устранять неполадки, прежде чем мы потратим деньги на звонок в службу поддержки Microsoft.
Мы используем пространства имен DFS для чистых путей, но не используем репликацию DFS. До изменения у нас было одно пространство имен, которое мы назовем \\my.domain.com\main. Этот домен работал отлично, но мы поддерживаем 5 подразделений, поэтому мы решили создать пространства имен для каждого подразделения. \\my.domain.com\Div1, \\my.domain.com\Div2, и т.д.
До изменения все отображали диск как Q: \\my.domain.com\main\Div1Dept и после изменения они отображают диск, например Q: \\my.domain.com\Div1\Folders. \\my.domain.com\main\Div1Dept будет в том же месте, что и \\my.domain.com\Div1\Folders. Единственная разница будет в пространстве имен.
Проблема
Пользовательский элемент предпочтения Q: в Standard_DriveMaps_Divisional {5559ca2b-79af-4a37-82d8-451d2fb71543}
Объект групповой политики не был применен из-за сбоя с кодом ошибки «0x80070035 Сетевой путь не найден». Эта ошибка была подавлена.
У нас бывают различные случаи (мы поддерживаем 2000 пользователей и получаем несколько звонков в неделю с этой проблемой), когда, когда пользователь входит в систему, местоположение недоступно и диск не может быть сопоставлен. Мы можем подтвердить, что у вас качественное соединение с сетью и мы можем связаться с контроллерами домена и серверами пространства имен.
Эта проблема никогда бы не возникла, если бы мы использовали main пространство имен. Когда пользователь переходит к пути вручную, он становится доступным. Обходной путь - запустить gpupdate для повторного сопоставления дисков, но мы не можем просить пользователя делать это каждый раз, когда это происходит.
У нас есть один диск, отличный от DFS, который успешно отображается каждый раз, когда эти связанные карты DFS выходят из строя. Это заставляет меня думать, что это не только подключение к сети.
Устранение неисправностей выполнено
Я далек от профессионала в DFS, но я достаточно знаю, как создавать целевые папки и тому подобное.
Используя DFS Management, я проверил продолжительность кэша и другие настройки между пространствами имен, и все они совпадают. Они также используют те же серверы пространства имен.
Используя DFSDiag command у нас есть положительные результаты тестирования для всех пространств имен.
Вопрос
Учитывая предоставленную информацию, может ли кто-нибудь подумать о некоторых конкретных вещах, которые я мог бы упустить? Существуют ли какие-либо настройки за пределами графического интерфейса управления DFS, которые могут повлиять на доступность не-main пространства имен, потому что main вроде всегда доступен.
Возможно, GPO применяется без доступа к сети, и поэтому они не могут получить изменения (отображение Networkdrive)
Произошло ли это с одним и тем же человеком?
Существует политика GPO для ожидания сети, но убедитесь, что она активна только на клиентах внутреннего домена, а не на мобильных / портативных компьютерах.
Проверь это https://technet.microsoft.com/en-us/library/gg486839.aspx
Без этих настроек клиенты могут пройти аутентификацию с помощью локального хранилища учетных данных, но сетевой стек не завершил загрузку.
У нас есть эта проблема на нашем сайте, но это проблема с компьютером / сетевым драйвером, из-за которой инициализация / загрузка сетевых драйверов / стека занимает так много времени.
Если честно, я забыл, что разместил эту проблему. Однако, поскольку этот вопрос был просмотрен 1000 раз, я решил, что должен дать этим 1000 людям ответ.
Эта проблема была решена ссылкой на эту статью под названием Медленное связывание с Windows 7 и пространствами имен DFS написано одним из моих любимых людей в Твиттере Нед Пайл. У меня не было полного понимания моей проблемы, поэтому вот что вам нужно знать:
Когда мы подключили сетевые диски для наших пользователей, они получили бы пару дисков:
H: \\my.domain.com\div1\Users\Username
Q: \\my.domain.com\div1\Folders
Проблема
Диск H: на самом деле был перенаправленной папкой, которая была кэширована на компьютере. Если задержка соединения для достижения пути \\my.domain.com\div1\Users\Username был слишком высок, компьютер передал бы долю \\my.domain.com\div1 в автономном режиме и вместо этого используйте кеш. Диск H: (перенаправленная папка) появится, потому что он кэширован, но любой другой диск, использующий общий ресурс / пространство имен DFS \\my.domain.com\div1 будет казаться отключенным. Это произошло потому, что другие каталоги не были в кэше, используемом компьютером.
Решение
Пример:
UNC Path Latency
-------- -------
\\my.domain.com\div1\* 32000
\\my.domain.com\div2\* 32000
\\my.domain.com\div1\Users\* 60
\\my.domain.com\div2\Users\* 60
Это должно предотвратить отключение корней DFS при перенаправлении папок.