In diesem Beitrag möchte ich euch heute kurz zeigen, wie man das IIS Modul URL Rewrite für SharePoint Short URLs (Kurz-URLs) nutzen kann. Mit URL Rewrite kann ein Regelwerk konfiguriert werden, dass eine URL umgeschrieben oder auch umgeleitet wird. In diesem Artikel geht es primär um die Weiterleitung eines URL-Aufrufs.
Bei URL Rewrite handelt es sich um eine Erweiterung für den IIS. URL Rewrite in der Version 2.0 kann hier heruntergeladen werden.
Und noch eine kleine Anmerkung vorweg, dass in diesem Artikel die web.config
direkt bearbeitet wird. Das sollte man bei SharePoint natürlich nicht unbedingt tun und dazu lieber die Änderung per SPWebConfigModifications
durchführen. Dies sollte der bevorzugte Weg sein, würde die Funktionsweise von IIS URL Rewrite aber für den Anfang unnötig verkomplizieren.
Damit man SharePoint Short URLs anlegen kann, muss zuerst die Erweiterung im IIS installiert sein. Sobald das Modul erfolgreich installiert wurde, erscheint der entsprechende Punkt auch im IIS Manager.
Ein ganz konkreter Anwendungsfall ist z.B. bei der Nutzung von SharePoint Variations. Hier möchte man einzelne Sprachen unter möglichst einprägsamen SharePoint Short URLs verfügbar machen. Wurde dies bei der initialen Einrichtung nicht beachtet, ist eine nachträgliche Änderung nicht mehr möglich. Gehen wir also von folgendem Szenario aus:
- Die eigentliche SharePoint URL der Seite lautet: http://sharepointrocks.local/eng-gb
- Die kurze und einprägsame URL der Seite soll aber lauten: http://sharepointrocks.local/en
Um diese Weiterleitung technisch zu realisieren, legen wir eine neue Regel im URL Rewrite Modul an. Dazu erstellen wir eine neue eingehende Regel in der URL Rewrite Oberfläche.
Nun beginnt der komplexere Teil bei URL Rewrite, wir müssen eine entsprechende Regel erstellen. Der einfachste Teil ist die Vergabe eines Namen für die Regel. 🙂 In unserem Beispiel ist es eigentlich nur wichtig zu erkennen, ob der Pfad genau mit en
übereinstimmt. Die komplette Regel ist im nachfolgenden Bild abgebildet, die Erklärung im Detail erfolgt danach.
Zuerst definieren wir, wann eine Weiterleitung erfolgen soll. Das Muster dafür ist ^/en$
. Die Sonderzeichen sind notwendig, damit wir ausschließen können einen falschen Pfad umzuleiten, der zufällig auch die Zeichenkette en
enthält. Das Zeichen ^
legt fest, dass das Muster direkt am Anfang stehen muss. Das $
-Zeichen ist dafür zuständig, dass nach der Zeichenkette en
kein weiteres Zeichen mehr folgt.
Weitere Bedingungen müssen nicht eingetragen werden. Ein klassisches Beispiel für das Nutzen von Bedingungen ist die Weiterleitung von HTTP zu HTTPS. Dort kann man prüfen, ob der Aufruf per HTTP erfolgt und ggf. auf HTTPS umleiten. Das ist ziemlich praktisch, wenn eine IIS Site nur HTTPS unterstützt und Benutzer automatisch umgeleitet werden, wenn sie per HTTP zugreifen.
Zuletzt muss noch die Aktion definiert werden, die bei Übereinstimmung der Regel durchgeführt werden soll. In unserem Fall wäre es eine Weiterleitung auf die eigentliche SharePoint URL. Die Variable {HTTP_HOST} enthält immer den Host des Aufrufs. Ist dieser nicht identisch mit der Weiterleitung, kann dieser natürlich auch explizit angegeben werden.
Somit können wir nun beliebige SharePoint Short URLs anlegen und nutzen. Ein kleiner Hinweis an dieser Stelle noch, dass beim Testen so mancher Cache Probleme machen kann und das Ergebnis verfälschen kann. Also am Besten immer den Browser-Cache beim Testen löschen und auch ein IISRESET
kann manchmal helfen, wenn es zu seltsamen Verhaltensweisen kommt.
In diesem Sinne,
Happy SharePointing…
Gibt es eine Möglichkeit, die definierten Rules für einzelne User oder Usergruppen, zu deaktivieren?
Hallo Anja,
eine Unterscheidung auf Basis des Benutzernamens ist leider nicht möglich.
Das Problem ist, das der Mechanismus vor der Authentifizierung des Benutzers ausgeführt wird. Man kann also nicht herausfinden, wer gerade darauf zugreift.
Viele Grüße
Frank
Hallo!
Funktioniert die Lösung auch für Sharepoint 2019?
Hallo, die Lösung funktioniert auch für SharePoint 2019.