colinardo
Goto Top

Arbeitsordner (Workfolders) unter Windows Server 2012 R2 auf einem anderen SSL Port als 443 benutzen

article-picture

back-to-topVorwort

Diese Anleitung zeigt wie man die Arbeitsordner-Rolle auf einem Windows Server 2012 R2 auf einen anderen SSL-Port verschiebt, so dass z.B. weiterhin Dienste im IIS die den Port 443 und 80 benötigen, parallel weiterlaufen können. Standardmäßig ist es nämlich so, dass bei installierter Arbeitsordner-Rolle, welche im Hintergrund auf Port 443 und 80 lauscht, die IIS-Website nicht mehr gestartet werden kann wenn sie Bindungen auf Port 443 oder 80 hat.

In dieser Anleitung ändern wir den Port als Beispiel von 443 auf 9443 ab.

Ich gehe in dieser Anleitung davon aus, dass die Arbeitsordner-Rolle bereits installiert, grundlegend eingerichtet, und soweit funktionsfähig ist.

back-to-top1. Ändern des SSL-Ports in der SyncShareSvc-Config

Damit der Dienst der Arbeitsordner-Rolle (SyncShareSvc) weiß auf welchem Port er von nun an lauschen soll, müssen wir die Web-Config des Dienstes anpassen. Diese findet sich an folgendem Ort
C:\Windows\System32\SyncShareSvc.config
WICHTIG: Damit wir die Datei bearbeiten können, muss man diese zu erst in Besitz nehmen und sich Schreibrechte in den ACLs verpassen, da sie dem TrustedInstaller gehört und selbst Administratoren keine Schreibrechte darauf haben.

Ist das erledigt ändert man folgenden Abschnitt in der Datei:
...
<bindings>
     <binding protocol="http" bindingInformation="*:80:" />
     <binding protocol="https" bindingInformation="*:443:" sslFlags="0" />
</bindings>
...
so ab: (In diesem Beispiel ändern wir den SSL-Port auf Port 9443, passt hier also euren gewünschten Port an)
<bindings>
     <!-- <binding protocol="http" bindingInformation="*:80:" /> -->
     <binding protocol="https" bindingInformation="*:9443:" sslFlags="0" />
</bindings>
den HTTP-Port habe ich hier auskommentiert da man seine Arbeitsordner sowieso besser nur SSL verschlüsselt anbieten sollte. Alles andere wäre grob fahrlässig, außer man nutzt ein VPN, aber dann bräuchte man ja keine Arbeitsordner face-wink.

Nun speichert Ihr die Datei.

back-to-top2. Dem Service-Account "NT-AUTORITÄT\Lokaler Dienst" das Recht erteilen den neuen Port zu verwenden

Da der SyncShareSvc-Dienst unter dem Account "Local Service" läuft hat dieser Standardmäßig kein Recht auf dem neuen Port zu lauschen. Deswegen müssen wir dem Account den neuen Port explizit per netsh erlauben.

Dazu führen wir folgende Zeile in einer CMD aus:
netsh http add urlacl url=https://*:9443/ user="NT-AUTORITÄT\Lokaler Dienst"
ACHTUNG: Sollte das System auf Englisch eingestellt sein verwendet man hier stattdessen die Account-Bezeichnung "NT AUTHORITY\LOCAL SERVICE"

back-to-top3. Binden des SSL-Zertifikats an den neuen Port

Als nächstes müssen wir ein SSL-Zertifikat das die zu verwendende Workfolder-Domain als CommonName oder SAN enthält an diesen neuen Port binden. Dazu führen wir ebenfalls per netsh folgenden Befehl aus (Den Hash des Zertifikates an euer verwendetes Zertfikat anpassen):
netsh http add sslcert ipport=0.0.0.0:9443 certhash=XXXXXXXXXXXXXXXXXXXXXXXXXX appid={4dc3e181-e14b-4a21-b022-59fc669b0914}
Den Hash eures Zertifikats könnt Ihr mit einem einfachen Powershell-Befehl ermitteln:
gci Cert:\LocalMachine\My
Das listet euch die Zertifikate und die Hashes (Thumprint) auf, die im Machine-Store liegen.

Wichtig ist das ihr das Binden des Zertifikats per netsh vor nehmt und nicht in der IIS-Konsole, da sich ansonsten später beim Starten der Website der IIS beschweren würde das der neue Port schon belegt ist.

back-to-top4. In der Firewall den neuen Port öffnen

Nicht zu vergessen, den Port in der Firewall zu öffnen (TCP 9443).
Per GUI
screenshot
Per Powershell
New-NetFirewallRule -DisplayName "Arbeitsordner Port 9443" -Profile Domain -Direction Inbound -Action Allow -Protocol TCP -LocalPort 9443

back-to-top5. Den "SyncShareSvc" Dienst neu starten

Damit die Änderungen übernommen werden muss der Dienst SyncShareSvc neu gestartet werden
Als Beispiel per Powershell:
Restart-Service SyncShareSvc

back-to-top6. Optional: Via GPO die neue URL mit Portangabe den Clients bekannt machen

Da wir ja jetzt den SSL-Port vom Standard-Port 443 auf einen abweichenden Port abgeändert haben müssen wir das den Domain gejointen PCs mitteilen. Das machen wir in folgender Richtlinie:
Benutzerkonfiguration > Windows Komponenten > Arbeitsordner > "Festlegen der Arbeitsordnereinstellungen"
Dort hinterlegen wir die neue URL mit der neuen Portangabe: https://workfolders.domain.de:9443

back-to-top7. Hinweise zur Clienteinrichtung

Da die Arbeitsordner nun nicht mehr auf dem Standard-SSL-Port laufen, ist es auf NON-DOMAIN PCs nicht mehr möglich die Einrichtung über die E-Mail-Adresse und die Autoermittlung zu benutzen. Wir müssen bei der Einrichtung im Dialog stattdessen die neue Arbeitsordner-URL mit Portangabe angeben:

screenshot

screenshot


Wurde die Anleitung wie oben befolgt sollte es jetzt wieder möglich sein, die Standard-Website zu starten da die Ports 443/80 nun nicht mehr belegt sind.

Hoffe die Anleitung nutzt dem ein oder anderen bei der Konsolidierung der Arbeitsordner-Rolle auf einen bereits vorhandenen Server der weiterhin seine IIS-Site auf den Standard-Ports bereit stellen soll.

Ich freue mich über jegliches Feedback face-smile

Gruß @colinardo

Falls der Beitrag gefällt, seid so nett und unterstützt mich durch eine kleine Spende / If you like my contribution please support me and donate

Content-Key: 317279

Url: https://administrator.de/contentid/317279

Ausgedruckt am: 19.03.2024 um 09:03 Uhr

Mitglied: DerWoWusste
DerWoWusste 09.10.2016 um 13:54:51 Uhr
Goto Top
Moin.

Ich nutze Workfolders zwar noch nicht, aber danke für die gründliche Arbeit.
Hätte noch eine Verbesserung vorzuschlagen für Punkt 4, und zwar, die Regel nur für das Profil Domain zu erstellen, denn in anderen Profilen sollte man alles dicht lassen.

Grüße
DWW
Mitglied: colinardo
colinardo 09.10.2016 um 14:00:54 Uhr
Goto Top
Hi DWW,
Zitat von @DerWoWusste:
Hätte noch eine Verbesserung vorzuschlagen für Punkt 4, und zwar, die Regel nur für das Profil Domain zu erstellen, denn in anderen Profilen sollte man alles dicht lassen.
Jupp, Korrektur oben übernommen.

Merci.
Grüße Uwe
Mitglied: Dani
Dani 10.10.2016 um 15:44:02 Uhr
Goto Top
Moin Uwe,
was veranlasst einen Admin zur solche einer Krücke? Abgesehen davon, dass eine Lizenz eingespart wird.
Weißt du zufällig ob diese Anpassung seitens Microsoft auch supportet wird?


Gruß,
Dani
Mitglied: colinardo
colinardo 10.10.2016 aktualisiert um 16:02:15 Uhr
Goto Top
Hallo Dani.
Zitat von @Dani:
Moin Uwe,
was veranlasst einen Admin zur solche einer Krücke?
Fremde Chefs die sich nicht belehren lassen face-wink und Software die alles andere als Benutzerfreundlich anpassbar angelegt wurde.
Weißt du zufällig ob diese Anpassung seitens Microsoft auch supportet wird?
Die Grundidee stammt von Microsoft selber (Technet, Konflikt mit Essentials Server Rolle), leider war die Ausführung im Web unvollständig ausgeführt, weswegen ich sie um die weiter nötigen Schritte ergänzt habe.

Ob es nun sinnvoll ist muss jeder selber entscheiden, jeder hat seine Vorgaben... und wenn man sich z.B. in einer Testumgebung nur eine VM einspart kann das unter Umständen schon nützlich sein.

Grüße Uwe
Mitglied: PKlemm
PKlemm 05.09.2019 aktualisiert um 21:59:26 Uhr
Goto Top
Vielen Dank für die super Beschreibung!
Kleine Korrektur: Die appid muss in einfache Anführungszeichen, also appid='{4dc3e181-e14b-4a21-b022-59fc669b0914}'
ansonsten gibt netsh eine Fehlermeldung aus: Falscher Parameter.
Zumindest war das bei mir so.