Подключенный диск SharePoint постоянно отключается или запрашивает пароль? Вот почему

Подключение библиотеки SharePoint Online к букве диска работает с первой попытки, а затем перестает выдерживать контакт с реальностью: диск отключается в середине дня, или возвращается пустым после перезагрузки, или запрашивает уже сохраненный пароль. Все три проблемы имеют одну и ту же причину. Сопоставления WebDAV поддерживаются сеансом браузера, а сеанс — это не учетные данные.

Четыре вещи определяют, будет ли подключение стабильным. Проверьте их в следующем порядке.

[IMAGE: webdav-four-layers.png — alt: "Четыре уровня, от которых зависит подключенный диск SharePoint, и симптом при сбое каждого из них"]

1. Служба WebClient — без нее подключение работать не будет

WebDAV в Windows предоставляется службой WebClient, и при чистой установке Windows Server соответствующая функция может отсутствовать вовсе. В клиентских версиях Windows служба существует, но часто настроена на «Вручную», что означает, что она запускается по требованию и снова останавливается при простое. Именно поэтому диск работает, а затем незаметно исчезает.

Get-Service WebClient | Select-Object Status, StartType

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

Set-Service WebClient -StartupType Automatic
Start-Service WebClient

На Windows Server эту функцию необходимо сначала установить:

Install-WindowsFeature WebDAV-Redirector -Restart

Перезагрузка в этом случае обязательна; перенаправитель не загрузится, пока она не произойдет.

2. AuthForwardServerList — отсутствующее значение реестра

По умолчанию перенаправитель WebDAV отказывается пересылать учетные данные на сервер, который он не считает локальным. В случае с SharePoint Online это означает, что он никогда не отправляет уже имеющийся токен, поэтому вы получаете запрос пароля для подключения, которое технически в порядке.

Решение — это значение MULTI_SZ, содержащее список хостов, которым разрешено получать пересылаемые учетные данные:

$key = 'HKLM:\SYSTEM\CurrentControlSet\Services\WebClient\Parameters'
New-ItemProperty -Path $key -Name AuthForwardServerList -PropertyType MultiString `
    -Value @('https://contoso.sharepoint.com', 'https://contoso-my.sharepoint.com') -Force
Restart-Service WebClient

Используйте свои собственные имена хостов клиента. Включите хост с -my, если пользователи подключают свой OneDrive — это отдельное имя хоста, и именно его часто забывают.

Это настройка для каждого компьютера, что делает ее естественным элементом реестра в групповых политиках (Group Policy Preferences), а не тем, что нужно делать вручную сорок раз.

3. Истечение срока действия токена сеанса — истинная причина фразы "утром все работало"

[IMAGE: webdav-vs-onedrive-sync.png — alt: "Сравнение подключенного диска WebDAV с клиентом синхронизации OneDrive по шести требованиям"]

Эту часть нельзя исправить ключом реестра. Подключение WebDAV к SharePoint Online зависит от сеансового файла cookie, и срок действия этого файла cookie истекает. Когда это происходит, диск остается подключенным, но каждый доступ к нему завершается ошибкой или повторным запросом.

Две вещи продлевают его действие, и стоит быть честным: ни одна из них не делает его постоянным:

• Пользователь должен был выбрать Оставаться в системе при аутентификации в клиенте. Без этого сеанс по умолчанию будет коротким.
• Политика частоты входа в систему клиента определяет максимальный срок. Если условный доступ (Conditional Access) требует повторной аутентификации каждые несколько часов, никакая клиентская настройка не сможет это обойти.

Если вашим пользователям нужна буква диска, которая сохраняется в течение всей рабочей недели, WebDAV — это неправильный инструмент, и никакие настройки этого не изменят. Клиент синхронизации OneDrive с функцией «Файлы по запросу» (Files On-Demand) предоставляет реальный путь в Проводнике, сохраняет свой собственный токен обновления и не зависит от сеанса браузера. Скажите это вслух запрашивающему, прежде чем тратить неделю на WebDAV.

4. Устаревшие записи в диспетчере учетных данных

Как только подключение несколько раз не прошло аутентификацию, Windows кэширует неверный ответ и продолжает его воспроизводить. Очистка этого кэша часто позволяет запустить правильно настроенную конфигурацию:

cmdkey /list | findstr /i sharepoint

Удалите каждую соответствующую запись:

cmdkey /delete:<target-name-from-the-list>

Затем переподключите диск. Делайте это после первых трех исправлений, а не до — иначе вы очистите кэш, и та же самая неисправная конфигурация снова его заполнит.

Как обеспечить автоматическое переподключение диска

[IMAGE: net-use-command-anatomy.png — alt: "Команда net use для библиотеки SharePoint, аннотированная по частям"]

Две детали в том, как создается подключение диска, имеют большее значение, чем кажется:

net use Z: "https://contoso.sharepoint.com/sites/finance/Shared Documents" /persistent:yes

Без /persistent:yes подключение исчезнет при следующем входе в систему, независимо от других исправлений. И путь должен быть корнем библиотеки документов — указание на подпапку приводит к подключению, которое разрешается непоследовательно.

Проверка на сохранение подключения, а не только на его работоспособность

Единственная проверка, которой стоит доверять, — это перезагрузка:

Get-PSDrive -PSProvider FileSystem | Where-Object { $_.DisplayRoot -like 'http*' }
Test-Path 'Z:\'

Запустите это после перезагрузки и после обеденного перерыва. Подключение, которое работает сразу после создания, ничего вам не сказало — все в этой статье касается второго часа, а не первой минуты.

Если возникает ошибка с определенным кодом

0x80070043 — это другая проблема с другой причиной, а не вариация этой. Она означает, что имя не может быть разрешено, а не то, что учетные данные отклонены.