Workfolders auf anderen Port legen

« | 15 May 2021 | »

Da habe ich vor kurzem das Windows Server Update Service installiert und dabei gar nicht gemerkt, dass meine Server Work Folders seither nicht mehr funktionieren.

Der Grund war einfach: Ein Port Konflikt.
Aber dann kam noch ein dummes Anmeldeproblem hinzu und schon ward ein Drama geboren …

---

Die Windows Server Workfolders (zu deutsch Arbeitsordner) arbeiten mit dem IIS und belegen die üblichen HTTP und HTTPS Ports. Tatsächlich läuft der Dienst nicht direkt innerhalb eines IIS, sondern nutzt nur dessen Kern.

Wenn man nun parallel andere HTTP Dienste installiert (oder wie ich einfach die IIS Konfiguration ändert), schafft man schnell eine Situation, in der die konfigurierten HTTP Ports von anderen Seiten benutzt werden und die Workfolders fallen aus.

Nun stellt sich für mich die Frage, wie ich die Workfolders auf einen anderen Port legen kann. Denn mit “Nicht-Standard-Ports” geht man künftigen Konflikten aus dem Weg.

Wären Workfolders direkt im IIS zu Hause, könnte man den Port leicht in dessen UI abändern, doch leider liegt die Konfiguration nicht dort.
Was nun?

Workfolders mit neuem Port einrichten

Zum Glück hilft uns das Internet schnell weiter: blog.cloud-client.info Ein meinem Beispiel möchte ich den alten konfigurierten HTTPS Port 443 durch 3443 ersetzen.

• Unter c:\windows\system32\SyncShareSvc.config liegen die benötigten Einstellungen und nachdem man den Besitz der Datei übernommen hat, kann man sie auch bearbeiten.
• Der enthaltene Eintrag :443: ist durch den neuen Port :3443: zu ersetzen. Die Doppelpunkte sind beide notwendig.
• Dann führt man auf der Konsole
  netsh http add urlacl url=https://*:3443/ user=”NT Authority\LOCAL SERVICE” aus.

Tatsächlich reichte diese Einstellung bei mir schon aus und nach dem Neustart der Sync-Dienste (SyncShareSvc und SyncShareTTSvc) konnte ich meine Arbeits-PCs mit der angepassten neuen URL mit dem neuen Port auch gleich wieder verbinden.

Fazit

Tja … Ports.
Seit 20 Jahren immer wieder das gleiche: Zwei Dienste bilden sich ein, sie müssten ihre Inhalte über die HTTP-Ports (80 und 443) bereitstellen und wehe man will zwei dieser Dienste auf einer Maschine laufen lassen.

Das üble dabei: Gerade der IIS sollte als “Host” all diese Verbindungsdetails übernehmen und Anfragen an seine Plug-Ins weiterverteilen. Denn da würde genau ein Prozess die Ports belegen und es könnten mehrere Dienste parallel betrieben werden, so lange sie in unterschiedlichen virtuellen Unterverzeichnissen liegen.

Doch Fehlanzeige! Jedes Feature will seinen Port nur für sich alleine.

Und so werde ich wohl auch noch in 20 Jahren immer noch damit beschäftigt sein, Dienste auf unterschiedliche Ports zu verteilen.
… eigentlich ist so etwas eine furchtbare Zeitverschwendung!