Was ist denn ein Anwendungsfall für einen Browser auf einem Server?

[the_second]

Betrifft das auch Terminalserver? Sonst würd ich doch sagen - in was für einem workflow benötigt man denn einen Browser auf einem Server?

[MarcusK]

the_second schrieb:
--------------------------------------------------------------------------------
> Betrifft das auch Terminalserver? Sonst würd ich doch sagen - in was für
> einem workflow benötigt man denn einen Browser auf einem Server?

naja, und wenn es nur für den Admin eine Software runterladen und installieren muss.

[JouMxyzptlk]

Schon mal Exchange ab Version 2013 administriert? Vor allem wenn er korrekt abgesichert ist dass die ECP für Admins absichtlich nur noch lokal geht. Und das ist nur das bekannteste Beispiel lokaler Serversoftware welche dann über einen Browser auf https://127.0.0.1:xxx gesteuert wird.

[the_second]

>Schon mal Exchange ab Version 2013 administriert?

Nee, wegen so was frag ich. Ich komm aus der anderen Ecke, ich kenn das halt so, dass möglichst die gesamte Konfiguration in die Automatisierung und in eine Versionsverwaltung kommt und die konkreten Instanzen der verwalteten Software gar nicht mehr angefasst werden. Aber da ist Konfiguration auch Text in irgendeiner Form, oder API, aber halt nicht GUI.

Aber ja, klingt ja nach einem validen Anwendungsfall für kleine Unternehmen, verstehe. Trotzdem, würde man sich zur Verwaltung die Ports der verwalteten Anwendungen nicht irgendwie über einen reverse-proxy entsprechend gehärtet für sein Arbeitsgerät zur Verfügung stellen oder so?



1 mal bearbeitet, zuletzt am 17.01.24 16:01 durch the_second.

[countzero]

Es wird zwar nicht im Artikel erwähnt, aber ich wüsste nicht, warum sich ein Terminalserver hier anders verhalten sollte wie ein "normaler" Server.

Beispiel, warum ich auf einem Server einen Browser installiert habe:

Updates werden über eine Weboberfläche eingespielt. Die könnte ich natürlich auch auf einem anderen PC aufrufen, aber so kann ich gefahrlos die RDP-Sitzubg unterbrechen oder meinen PC neu starten und muss mir auch keine Sorgen machen, dass während der Installation die Netzwerkverbindung abbricht.

[the_second]

I see. Ja, okay, sowas hatte ich wirklich nicht auf dem Schirm, danke.

[JouMxyzptlk]

Bei Exchange ist die Konfiguration in der Active Directory. Zumindest das meiste davon, der Webserver, der ja nicht nur Adminkonsole sondern auch normalen Web Access, Active Sync für die Mobilclients und so weiter bereitstellt hat Teile in seiner Webserverkonfiguration in Registry und .config Dateien. Eine komplette Vorkonfiguration ist theoretisch möglich, so dass mal nach der Basisinstallation einfach nur ein Powershell-Script ablaufen lässt, in der Realität aber unrealistisch da die Umgebungen so vielfältig sein können.
Die Variante die du erwähnt zielt auf Software, welche von vornherein dafür ausgelegt, oder zumindest einfacher in der Konfiguration ist. Ggf. auch gleich in containern. Gibt es da etwas, was mit Exchange mithalten kann? Auch bis hin zu Hochverfügbarkeit mit mehreren Nodes? Microsoft hat dem Ding bis 2013 extrem viel reingepflanzt. Seit 2013 kommt weniger neues hinzu. Das was ich so bisher gesehen habe ist anders, nicht unbedingt besser, und nicht mal billiger wenn es was gutes sein soll...

[uschatko]

the_second schrieb:
--------------------------------------------------------------------------------
> Sonst würd ich doch sagen - in was für
> einem workflow benötigt man denn einen Browser auf einem Server?

Gerade bei Microsoft wird viel unter der Haube über den Webbrowser erledigt. Selbst auf Servern ohne GUI werden die entsprechenden Bibliotheken genutzt.

[ovbspawn]

Terminalserver, ansonsten Exchange mit Web-GUI oder andere Adminverwaltungsoberflächen.