Dysk sieciowy SharePoint rozłącza się lub prosi o hasło? Oto dlaczego

Mapowanie biblioteki SharePoint Online do litery dysku działa za pierwszym razem, a potem przestaje być zgodne z rzeczywistością: dysk znika w środku popołudnia, wraca pusty po ponownym uruchomieniu lub prosi o hasło, które jest już zapisane. Wszystkie trzy problemy mają to samo źródło. Mapowania WebDAV są wspierane przez sesję przeglądarki, a sesja to nie poświadczenie.

Cztery rzeczy decydują o tym, czy mapowanie będzie trwałe. Sprawdź je w tej kolejności.

[IMAGE: webdav-four-layers.png — alt: "Cztery warstwy, od których zależy zamapowany dysk SharePoint, oraz objawy awarii każdej z nich"]

1. Usługa WebClient — mapowanie nie może działać bez niej

WebDAV w systemie Windows jest dostarczany przez usługę WebClient, a w świeżej instalacji Windows Server podstawowa funkcja w ogóle nie jest obecna. W klienckich edycjach systemu Windows usługa istnieje, ale często jest ustawiona na tryb Ręczny, co oznacza, że uruchamia się na żądanie i zatrzymuje ponownie, gdy jest bezczynna. To jest dokładnie powód, dla którego dysk działa, a potem cicho znika.

Get-Service WebClient | Select-Object Status, StartType

Ustaw ją tak, aby uruchamiała się automatycznie, by nie znikała spod mapowania:

Set-Service WebClient -StartupType Automatic
Start-Service WebClient

W systemie Windows Server funkcja musi być najpierw zainstalowana:

Install-WindowsFeature WebDAV-Redirector -Restart

Ponowne uruchomienie w tym przypadku nie jest opcjonalne; przekierowanie nie zostanie załadowane, dopóki to nie nastąpi.

2. AuthForwardServerList — brakująca wartość rejestru

Domyślnie przekierowanie WebDAV odmawia przekazywania poświadczeń do serwera, którego nie uważa za lokalny. W przypadku SharePoint Online oznacza to, że nigdy nie wysyła tokenu, który już posiada, więc otrzymujesz monit o hasło przy mapowaniu, które technicznie jest poprawne.

Rozwiązaniem jest wartość MULTI_SZ zawierająca listę hostów, które mogą odbierać przekazywane poświadczenia:

$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

Użyj własnych nazw hostów dzierżawy. Uwzględnij również host -my, jeśli użytkownicy mapują swój OneDrive — to oddzielna nazwa hosta i to właśnie o niej ludzie zapominają.

Jest to ustawienie dla całej maszyny, co czyni je naturalnym elementem rejestru w Preferencjach zasad grupy, a nie czymś, co należy robić ręcznie czterdzieści razy.

3. Wygaśnięcie tokenu sesji — prawdziwa przyczyna "działało dziś rano"

[IMAGE: webdav-vs-onedrive-sync.png — alt: "Porównanie zamapowanego dysku WebDAV z klientem synchronizacji OneDrive pod kątem sześciu wymagań"]

To jest część, której nie naprawi żaden klucz rejestru. Mapowanie WebDAV do SharePoint Online opiera się na pliku cookie sesji, a ten plik cookie wygasa. Kiedy to nastąpi, dysk jest nadal zamapowany, a każdy dostęp kończy się niepowodzeniem lub ponownym monitem.

Dwie rzeczy wydłużają ten czas, i warto być szczerym, że żadna z nich nie czyni go trwałym:

• Użytkownik musi wybrać Pozostań zalogowany podczas uwierzytelniania w dzierżawie. Bez tego sesja jest z założenia krótka.
• Polityka częstotliwości logowania dzierżawy określa górny limit. Jeśli dostęp warunkowy wymusza ponowne uwierzytelnianie co kilka godzin, żadne ustawienie po stronie klienta tego nie przetrwa.

Jeśli Twoi użytkownicy potrzebują litery dysku, która przetrwa cały tydzień pracy, WebDAV jest niewłaściwym narzędziem i żadne strojenie tego nie zmieni. Klient synchronizacji OneDrive z funkcją Pliki na żądanie zapewnia rzeczywistą ścieżkę w Eksploratorze, przechowuje własny token odświeżania i nie zależy od sesji przeglądarki. Powiedz to głośno osobie zgłaszającej problem, zanim spędzisz tydzień na WebDAV.

4. Nieaktualne wpisy w Menedżerze poświadczeń

Gdy mapowanie kilkukrotnie zakończy się niepowodzeniem uwierzytelniania, system Windows buforuje błędną odpowiedź i ciągle ją odtwarza. Wyczyszczenie tego często sprawia, że poprawna konfiguracja zaczyna działać:

cmdkey /list | findstr /i sharepoint

Usuń każdy pasujący wpis:

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

Następnie zamapuj ponownie. Zrób to po pierwszych trzech poprawkach, a nie przed — w przeciwnym razie wyczyścisz pamięć podręczną, a ta sama uszkodzona konfiguracja ją ponownie wypełni.

Sprawienie, by samo mapowanie ponownie się łączyło

[IMAGE: net-use-command-anatomy.png — alt: "Polecenie net use dla biblioteki SharePoint, opisane krok po kroku"]

Dwa szczegóły dotyczące sposobu tworzenia dysku mają większe znaczenie, niż się wydaje:

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

Bez /persistent:yes mapowanie zniknie przy następnym logowaniu, niezależnie od innych poprawek. Ścieżka musi wskazywać katalog główny biblioteki dokumentów — wskazanie podfolderu powoduje mapowanie, które rozwiązuje się niespójnie.

Weryfikacja, czy przetrwa, a nie tylko, czy działa

Jedynym testem, któremu warto zaufać, jest ponowne uruchomienie:

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

Uruchom to po ponownym uruchomieniu i po przerwie na lunch. Mapowanie, które działa natychmiast po utworzeniu, nic Ci nie mówi — wszystko w tym artykule dotyczy drugiej godziny, a nie pierwszej minuty.

Jeśli wystąpi błąd z określonym kodem

Kod 0x80070043 to inny problem z inną przyczyną, a nie wariacja tego. Oznacza to, że nazwa nie może zostać rozpoznana, a nie że poświadczenie zostało odrzucone.