SharePoint-Links brechen über VPN an veröffentlichten URLs

Eine SharePoint-Seite öffnet sich über das VPN, und der erste Dokumentlink schlägt mit einem Namen fehl, der nie in der Adressleiste stand. Diese Lücke ist das ganze Problem: Die Seite kam von einer URL, und der Dienst formatierte die nächste Anfrage aus einer anderen. Die veröffentlichte URL ist eine serverseitige Entscheidung, daher ist die Korrektur am Client das falsche Ende. Prüfen Sie, welchen Namen der Dienst zurückgibt, bevor Sie DNS oder Routen anfassen.

Die erste Seite und die nächste Anfrage verwenden verschiedene Namen

Ein Benutzer, der den Server über die Adresse erreicht, sieht eine funktionierende Startseite. Die Dokumentlinks auf dieser Seite werden aus der URL erzeugt, die der Dienst zu veröffentlichen glaubt, nicht aus dem, was der Browser eingegeben hat. Wenn diese abweichen, führt der nächste Klick zu einem Namen, den der Client nie aufgelöst hat.

Die Adresse einmal einzugeben repariert nicht jeden erzeugten Link, und ein Lesezeichen auf die Adresse verbirgt das Problem, bis ein Dokument geöffnet wird.

Der Fehler wird leicht als VPN-Problem missverstanden, weil er erst nach der Nutzung des Tunnels auftritt. Tatsächlich tut der Tunnel seine Arbeit: Er trägt die Anfrage zu einem Namen, für den es keinen funktionierenden Pfad oder kein passendes Zertifikat gibt. Trennen Sie die beiden Fragen, bevor Sie eine davon ändern. Die eine ist, wohin das Paket geht, die andere, welchen Namen der Dienst zu veröffentlichen gewählt hat.

Vier Kontrollen, ein Name

Jeder veröffentlichte Name muss vier unabhängige Kontrollen bestehen. DNS muss ihn für den tatsächlichen Client auflösen, Routing und Zugriffsrichtlinie müssen den Pfad erlauben, TLS muss für diesen Namen validieren, und der Dienst muss so konfiguriert sein, dass er ihn veröffentlicht.

Eine Änderung an einer Kontrolle erfüllt nicht die anderen. Das Akzeptieren einer Zertifikatswarnung ist keine Reparatur der Namensauflösung.

Die folgende Tabelle ist die Reihenfolge der Checkliste. Halten Sie bei der ersten Zeile an, die fehlschlägt, denn eine spätere Korrektur kann eine frühere Lücke nicht ausgleichen.

Lesen Sie das Veröffentlichungsmodell, bevor Sie es ändern

SharePoint Server-Bereitstellungen unterscheiden sich. Klassische Webanwendungen können alternative Zugriffszuordnungen verwenden, bei denen eine interne URL das ist, was der Server empfängt, und eine öffentliche URL das, was er zur Formatierung von Links verwendet. Hostbenannte Websitesammlungen folgen einem anderen Ansatz und können laut Microsofts Anleitung kein AAM verwenden.

Microsofts Planungsanleitung kennzeichnet AAM-Funktionen zudem als veraltet und empfiehlt hostbenannte Websitesammlungen für neue Planungen. Das macht das Bereitstellungsmodell zu einer Frage für seinen Eigentümer, nicht zu einem Standard, den Sie flicken.

Stellen Sie fest, welches Modell verwendet wird, bevor Sie eine Zuordnungsänderung vorschlagen. Ein AAM-Eintrag in einer hostbenannten Bereitstellung bewirkt nichts, und einer in einer klassischen Bereitstellung ändert jeden zurückgegebenen Link auf einmal. Beides sind Konfigurationsänderungen mit großer Reichweite, bereiten Sie sie daher in Stufen vor und halten Sie einen Rückweg bereit. Dies ist keine Empfehlung, alte Zuordnungen in eine moderne Umgebung einzuführen.

Folgen Sie dem fehlgeschlagenen Vorgang, nicht der Startseite

Notieren Sie das Ziel, das die fehlgeschlagene Anfrage tatsächlich verwendet hat, die Clientanwendung, den Zeitpunkt und den Fehler. Ein Browser und eine Desktopanwendung können unterschiedliche Proxy-, VPN- oder Authentifizierungswege zum selben Dokument nehmen.

Der Browser kann erfolgreich sein, während der Office-Client scheitert, und dieser Unterschied ist ein Hinweis darauf, welcher Kontext den Namen auflöst.

Wenn die URL und die Netzwerkübergabe beide funktionieren und der Dienst den Vorgang weiterhin ablehnt, liegt das verbleibende Problem auf Anwendungsebene. Dokumentberechtigungen und Auscheckstatus gehören dem Diensteigentümer, und eine VPN-Route liefert Konnektivität statt Berechtigung.

Prüfen Sie die Übergabe von Anfang bis Ende

Führen Sie die Prüfungen der Reihe nach auf dem fehlschlagenden Client aus: Auflösen des veröffentlichten Namens, Anfordern der Seite unter diesem Namen, dann Anfordern der Dokument-URL aus dem Seitenquelltext. Jeder Schritt isoliert eine Kontrolle.

Drei Befehle decken Auflösung, TLS und den Dokumentpfad ab:

nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx

Wenn die Auflösung nur durch den Tunnel fehlschlägt, ist die Split-DNS-Richtlinie der Verdächtige. Wenn TLS fehlschlägt, vergleichen Sie den Zertifikatnamen mit dem veröffentlichten Namen, statt durchzuklicken. Wenn beide erfolgreich sind und das Dokument weiterhin fehlschlägt, geht es beim Fehler nicht mehr um die URL.