10
Updates Terminal-Server Farm
Hallo Zusammen,
wir bekommen auf unserer neuen HCI-Umgebung nun eine neue TS-Farm auf Basis WS2019DC (1xBroker+Lizenzmgr, 3xSessionHost) mit Roaming Profilen. Im Schnitt sind hier ca. 20-30 User unterwegs.
Auf den TS laufen dann neben Standard-Apps wie Office, PDF-Tools, Browser etc. eben auch unsere Wawi- und Lagerverwaltungssoftware sowie Versandsoftware von Paketdiensten und Speditionen als Clientversion. Darin steckt auch das eigentliche Problem. Wenn Updates an der (im speziellen LV-) Software vorgenommen werden, müssen auch die installierten Clients nachgezogen werden bzw. müssen Entwickler und Dienstleister hier Codeschnipsel und Units tauschen. Kompliziert, ist aber leider so, denn einen Autoupdater o. ä. gibt es leider nicht.
Aktuell ist das kein Problem, weil es nur an max. 2 Stellen nachgezogen werden muss (Datenbankserver und aktuell einziger TS-SessionHost), in Zukunft kommen aber mit den zwei zusätzlichen Session Hosts, auch zwei weitere Stellen hinzu, die beim Update angefasst werden müssen. Ein vierter SH ist dann auch für nächstes Jahr schon geplant. Es gibt natürlich noch weitere Gründe, aber damit will ich jetzt nicht langweilen.
Als Hypervisor nutzen wir (acropolis) AHV, durch den ein simples clonen von VM´s möglich ist und auch die Pflege eines Templates (Golden-Image) kein Problem wäre. So würden wir dann nur dieses TS-Template pflegen und davon wiederum geklonte ("gesysprepte") VM´s ziehen und im Broker dann ersetzen. Soweit die Theorie. Was ich bisher gelesen habe, sollte das so auch funktionieren und der manuelle Aufwand würde sich auch via PS-Script auf ein Minimum reduzieren lassen. Vielleicht hat da jemand schon Erfahrung, die er mit mir teilen kann.
Ich habe die Suchfunktion genutzt aber zu dem Thema nur ältere Einträge gefunden und frage mich aktuell, was der beste Weg ist um Updates bei den Terminalservern durchzuführen. In Lösungen wie Citrix provisioning o. ä. wollten wir aktuell noch nicht investieren ist aber nicht gänzlich ausgeschlossen. Vielleicht hat hier jemand eine gute Lösung parat, die für kleinere Umgebungen durchaus praktikabel ist und sich bei dem ein oder anderen hier durch wenig Aufwand mit größtmöglicher (Ausfall-) Sicherheit bewährt hat.
Sollte es doch schon einen Eintrag zu diesem Thema geben, haut bitte nicht so dolle drauf
Ich habe ihn nicht gefunden.
Wäre super, wenn sich hier Vorschläge ergeben.
Vielen Dank vorab.
Gruß
wir bekommen auf unserer neuen HCI-Umgebung nun eine neue TS-Farm auf Basis WS2019DC (1xBroker+Lizenzmgr, 3xSessionHost) mit Roaming Profilen. Im Schnitt sind hier ca. 20-30 User unterwegs.
Auf den TS laufen dann neben Standard-Apps wie Office, PDF-Tools, Browser etc. eben auch unsere Wawi- und Lagerverwaltungssoftware sowie Versandsoftware von Paketdiensten und Speditionen als Clientversion. Darin steckt auch das eigentliche Problem. Wenn Updates an der (im speziellen LV-) Software vorgenommen werden, müssen auch die installierten Clients nachgezogen werden bzw. müssen Entwickler und Dienstleister hier Codeschnipsel und Units tauschen. Kompliziert, ist aber leider so, denn einen Autoupdater o. ä. gibt es leider nicht.
Aktuell ist das kein Problem, weil es nur an max. 2 Stellen nachgezogen werden muss (Datenbankserver und aktuell einziger TS-SessionHost), in Zukunft kommen aber mit den zwei zusätzlichen Session Hosts, auch zwei weitere Stellen hinzu, die beim Update angefasst werden müssen. Ein vierter SH ist dann auch für nächstes Jahr schon geplant. Es gibt natürlich noch weitere Gründe, aber damit will ich jetzt nicht langweilen.
Als Hypervisor nutzen wir (acropolis) AHV, durch den ein simples clonen von VM´s möglich ist und auch die Pflege eines Templates (Golden-Image) kein Problem wäre. So würden wir dann nur dieses TS-Template pflegen und davon wiederum geklonte ("gesysprepte") VM´s ziehen und im Broker dann ersetzen. Soweit die Theorie. Was ich bisher gelesen habe, sollte das so auch funktionieren und der manuelle Aufwand würde sich auch via PS-Script auf ein Minimum reduzieren lassen. Vielleicht hat da jemand schon Erfahrung, die er mit mir teilen kann.
Ich habe die Suchfunktion genutzt aber zu dem Thema nur ältere Einträge gefunden und frage mich aktuell, was der beste Weg ist um Updates bei den Terminalservern durchzuführen. In Lösungen wie Citrix provisioning o. ä. wollten wir aktuell noch nicht investieren ist aber nicht gänzlich ausgeschlossen. Vielleicht hat hier jemand eine gute Lösung parat, die für kleinere Umgebungen durchaus praktikabel ist und sich bei dem ein oder anderen hier durch wenig Aufwand mit größtmöglicher (Ausfall-) Sicherheit bewährt hat.
Sollte es doch schon einen Eintrag zu diesem Thema geben, haut bitte nicht so dolle drauf
Ich habe ihn nicht gefunden.
Wäre super, wenn sich hier Vorschläge ergeben.
Vielen Dank vorab.
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1122609676
Url: https://administrator.de/contentid/1122609676
Ausgedruckt am: 25.11.2024 um 04:11 Uhr
10 Kommentare
Neuester Kommentar
Mahlzeit!
Sieht doch nach einem Plan aus, den Du da hast.
Die Vorzüge von AHV kenne ich nicht. Ich arbeite auf einer Hyper-V-Umgebung mit 3 TS-SH-VMs und einem Broker.
Wenn Updates (egal welche für die SHs) anstehen, habe ich ein definiertes Wartungsfenster.
Auf jedem SH startet mit Anmeldung eines Nutzers ein automatisches Abmeldescript, dass die Nutzer vor diesem Wartungsfenster innerhalb eines definierten Zeitrahmens abmeldet.
Auf dem Broker liegen drei PS-Scripts, die über geplante Tasks gefeuert werden und dann folgendes passiert:
Gruß
bdmvg
Sieht doch nach einem Plan aus, den Du da hast.
Die Vorzüge von AHV kenne ich nicht. Ich arbeite auf einer Hyper-V-Umgebung mit 3 TS-SH-VMs und einem Broker.
Wenn Updates (egal welche für die SHs) anstehen, habe ich ein definiertes Wartungsfenster.
Auf jedem SH startet mit Anmeldung eines Nutzers ein automatisches Abmeldescript, dass die Nutzer vor diesem Wartungsfenster innerhalb eines definierten Zeitrahmens abmeldet.
Auf dem Broker liegen drei PS-Scripts, die über geplante Tasks gefeuert werden und dann folgendes passiert:
- Jeden Sonntag um 0 Uhr:
- Auf dem CB startet ein PS-Script und setzt alle SHs auf "Neue Verbindungen zulassen = falsch"
- Jeden Sonntag zwischen 2 und 4 Uhr:
- Auf den SHs wurden bei Anmeldung eines jeden Nutzers ein Abmeldescript gestartet, dass dynamisch die Zeit bis zu besagtem Zeitfenster berechnet und innerhalb dieses Zeitfensters den jeweiligen Nutzer abmeldet. Dadurch melden sich nicht alle Nutzer zur gleichen Zeit ab, sondern verteilen sich. Das ist gut, wenn man langsamen Speicher hat.
- Jeden Sonntag um 5 Uhr:
- Auf dem CB startet ein PS-Script das die SHs der Reihe nach durchbootet. Das geht nämlich nur, wenn keiner mehr angemeldet ist.
- Ab jetzt hab ich ein Wartungsfenster bis 12 Uhr, denn:
- Dann startet auf dem CB ein PS-Script, dass alle SHs auf "Neue Verbindungen zulassen = wahr" setzt.
Gruß
bdmvg
Also mein Bauchgefühl sagt mir das das (teilautomatisierte) Klonen eines TS um ein WaWi Update einzuspielen mehr Arbeit und Probleme mit sich bringt als das WaWi Update auf 3 Hosts durchzuführen. Das ist jetzt erstmal ein (starkes) Bauchgefühl aber du kannst das ja testen.
Wie groß sind die Roaming Profile? Wenn die auf den RD-SH verbleiben und bei Anmeldung nur aktualisiert werden sind die nach einem Klonen natürlich weg.
Wie groß sind die Roaming Profile? Wenn die auf den RD-SH verbleiben und bei Anmeldung nur aktualisiert werden sind die nach einem Klonen natürlich weg.
Hi,
das Clonen ist in der HCI-Umgebung eine feine Sache und funktioniert nahezu mit einem "Fingerschnippen". Also vom Zeitaufwand her steht das in keinem Verhältnis zu der manuellen Installation. Ich habe auch größere Bauchschmerzen damit, dass die Entwickler und Dienstleister nicht bei einem Host mal was unbemerkt vergessen und wir dann ungleiche Systeme pflegen. Sind leider nicht die Zuverlässigsten die Kollegen.
Aber ja, das ist sicher erst einmal zu testen, für eine valide Aussage...
Die Profile werden auf einer separaten Backup-VM im gleichen Datastore-Cluster gespeichert. Ich denke die Performance wird eher kein Problem.
das Clonen ist in der HCI-Umgebung eine feine Sache und funktioniert nahezu mit einem "Fingerschnippen". Also vom Zeitaufwand her steht das in keinem Verhältnis zu der manuellen Installation. Ich habe auch größere Bauchschmerzen damit, dass die Entwickler und Dienstleister nicht bei einem Host mal was unbemerkt vergessen und wir dann ungleiche Systeme pflegen. Sind leider nicht die Zuverlässigsten die Kollegen.
Aber ja, das ist sicher erst einmal zu testen, für eine valide Aussage...
Die Profile werden auf einer separaten Backup-VM im gleichen Datastore-Cluster gespeichert. Ich denke die Performance wird eher kein Problem.
Zitat von @Dirty2186:
Hi,
das Clonen ist in der HCI-Umgebung eine feine Sache und funktioniert nahezu mit einem "Fingerschnippen". Also vom Zeitaufwand her steht das in keinem Verhältnis zu der manuellen Installation. Ich habe auch größere Bauchschmerzen damit, dass die Entwickler und Dienstleister nicht bei einem Host mal was unbemerkt vergessen und wir dann ungleiche Systeme pflegen. Sind leider nicht die Zuverlässigsten die Kollegen.
Aber ja, das ist sicher erst einmal zu testen, für eine valide Aussage...
Die Profile werden auf einer separaten Backup-VM im gleichen Datastore-Cluster gespeichert. Ich denke die Performance wird eher kein Problem.
Hi,
das Clonen ist in der HCI-Umgebung eine feine Sache und funktioniert nahezu mit einem "Fingerschnippen". Also vom Zeitaufwand her steht das in keinem Verhältnis zu der manuellen Installation. Ich habe auch größere Bauchschmerzen damit, dass die Entwickler und Dienstleister nicht bei einem Host mal was unbemerkt vergessen und wir dann ungleiche Systeme pflegen. Sind leider nicht die Zuverlässigsten die Kollegen.
Aber ja, das ist sicher erst einmal zu testen, für eine valide Aussage...
Die Profile werden auf einer separaten Backup-VM im gleichen Datastore-Cluster gespeichert. Ich denke die Performance wird eher kein Problem.
Moin,
Denken, bedeutet nicht automatisch Wissen.
Es gibt Unternehmen, in denen wird kein Handschlag gemacht, der nicht Detailliert in einem Change-Request niedergeschrieben ist. Und jeder Schritt wird bei der Abarbeitung dokumentiert.
Freestyle-Administration ist ein absolutes Tabu.
Also Roaming Profile werden bei Anmeldung am Terminal Server aus dem Profilspeicher lokal auf den Terminal Server geladen. Bei Abmeldung werden die dann entweder gelöscht oder verbleiben dort (ist glaube ich der Standard). Meldet sich der User erneut an werden die Profile aktualisiert.
Da das i.d.R. sehr viele kleine Dateien sind ist die Performance immer ###e, richtig ###e. Ich wüsste nicht mal, ob komplett neu laden oder aktualisieren schneller (bzw. weniger langsam) geht. Wenn die Anmeldezeit über 2 Minuten liegt würde ich allgemein Mittel empfehlen um dem entgegen zu wirken, sprich Redirected Folders und / oder Profile Disks. Beim Klonen eines RD-SH ist die einzige Besonderheit halt das der dann keine Profile mehr lokal liegen hat oder womöglich sehr alte Stände, falls ein Produktiv System geklont wird.
Da das i.d.R. sehr viele kleine Dateien sind ist die Performance immer ###e, richtig ###e. Ich wüsste nicht mal, ob komplett neu laden oder aktualisieren schneller (bzw. weniger langsam) geht. Wenn die Anmeldezeit über 2 Minuten liegt würde ich allgemein Mittel empfehlen um dem entgegen zu wirken, sprich Redirected Folders und / oder Profile Disks. Beim Klonen eines RD-SH ist die einzige Besonderheit halt das der dann keine Profile mehr lokal liegen hat oder womöglich sehr alte Stände, falls ein Produktiv System geklont wird.
Zitat von @148656:
Moin,
Denken, bedeutet nicht automatisch Wissen.
Es gibt Unternehmen, in denen wird kein Handschlag gemacht, der nicht Detailliert in einem Change-Request niedergeschrieben ist. Und jeder Schritt wird bei der Abarbeitung dokumentiert.
Freestyle-Administration ist ein absolutes Tabu.
Zitat von @Dirty2186:
Hi,
das Clonen ist in der HCI-Umgebung eine feine Sache und funktioniert nahezu mit einem "Fingerschnippen". Also vom Zeitaufwand her steht das in keinem Verhältnis zu der manuellen Installation. Ich habe auch größere Bauchschmerzen damit, dass die Entwickler und Dienstleister nicht bei einem Host mal was unbemerkt vergessen und wir dann ungleiche Systeme pflegen. Sind leider nicht die Zuverlässigsten die Kollegen.
Aber ja, das ist sicher erst einmal zu testen, für eine valide Aussage...
Die Profile werden auf einer separaten Backup-VM im gleichen Datastore-Cluster gespeichert. Ich denke die Performance wird eher kein Problem.
Hi,
das Clonen ist in der HCI-Umgebung eine feine Sache und funktioniert nahezu mit einem "Fingerschnippen". Also vom Zeitaufwand her steht das in keinem Verhältnis zu der manuellen Installation. Ich habe auch größere Bauchschmerzen damit, dass die Entwickler und Dienstleister nicht bei einem Host mal was unbemerkt vergessen und wir dann ungleiche Systeme pflegen. Sind leider nicht die Zuverlässigsten die Kollegen.
Aber ja, das ist sicher erst einmal zu testen, für eine valide Aussage...
Die Profile werden auf einer separaten Backup-VM im gleichen Datastore-Cluster gespeichert. Ich denke die Performance wird eher kein Problem.
Moin,
Denken, bedeutet nicht automatisch Wissen.
Es gibt Unternehmen, in denen wird kein Handschlag gemacht, der nicht Detailliert in einem Change-Request niedergeschrieben ist. Und jeder Schritt wird bei der Abarbeitung dokumentiert.
Freestyle-Administration ist ein absolutes Tabu.
Da hat jetzt aber jemand auf ein (aus seiner Sicht) falsches Wort gewartet...
Wie geschrieben, wird es getestet, aber danke für den nutzlosen Kommentar. Wenn Du keine Lösung präsentieren willst, dann schreib lass es doch einfach. Oberlehrer braucht keiner...
Zitat von @ukulele-7:
Also Roaming Profile werden bei Anmeldung am Terminal Server aus dem Profilspeicher lokal auf den Terminal Server geladen. Bei Abmeldung werden die dann entweder gelöscht oder verbleiben dort (ist glaube ich der Standard). Meldet sich der User erneut an werden die Profile aktualisiert.
Da das i.d.R. sehr viele kleine Dateien sind ist die Performance immer ###e, richtig ###e. Ich wüsste nicht mal, ob komplett neu laden oder aktualisieren schneller (bzw. weniger langsam) geht. Wenn die Anmeldezeit über 2 Minuten liegt würde ich allgemein Mittel empfehlen um dem entgegen zu wirken, sprich Redirected Folders und / oder Profile Disks. Beim Klonen eines RD-SH ist die einzige Besonderheit halt das der dann keine Profile mehr lokal liegen hat oder womöglich sehr alte Stände, falls ein Produktiv System geklont wird.
Also Roaming Profile werden bei Anmeldung am Terminal Server aus dem Profilspeicher lokal auf den Terminal Server geladen. Bei Abmeldung werden die dann entweder gelöscht oder verbleiben dort (ist glaube ich der Standard). Meldet sich der User erneut an werden die Profile aktualisiert.
Da das i.d.R. sehr viele kleine Dateien sind ist die Performance immer ###e, richtig ###e. Ich wüsste nicht mal, ob komplett neu laden oder aktualisieren schneller (bzw. weniger langsam) geht. Wenn die Anmeldezeit über 2 Minuten liegt würde ich allgemein Mittel empfehlen um dem entgegen zu wirken, sprich Redirected Folders und / oder Profile Disks. Beim Klonen eines RD-SH ist die einzige Besonderheit halt das der dann keine Profile mehr lokal liegen hat oder womöglich sehr alte Stände, falls ein Produktiv System geklont wird.
Wir haben die Konstellation ja jetzt schon mit dem einen SH (2012R2) und da ist das Laden der Profile aus dem Backup kein Problem. Funktioniert einwandfrei und auch für das zurückschreiben bei Abmeldung gibt es keine große Wartezeit. So denke ich wird es mit den 3 SHosts ähnlich sein. Oder ist ws2019 das Problem?
Vermutlich kein Problem wenn die Ladezeiten jetzt gut sind. Ich denke auch nicht das das bei Windows 2019 anders läuft...
Hallo,
wenn es hier nur um die Update eines Versandsystems geht, würde ich den Aufwand TSse zu klonen und im Endeffekt die ganzen Maschinen neu zu machen nicht sehen.
Sind die Updates rein auf Dateiebene? Auf einem machen, muss nicht mal der TS sein, und dann per Skript zu einem Wartungsfenster (ggf. nachts) synchron halten. Ja nach Software funktioniert sogar eine Installation in einem Netzwerkpfad.
Gruß
Marco
wenn es hier nur um die Update eines Versandsystems geht, würde ich den Aufwand TSse zu klonen und im Endeffekt die ganzen Maschinen neu zu machen nicht sehen.
Sind die Updates rein auf Dateiebene? Auf einem machen, muss nicht mal der TS sein, und dann per Skript zu einem Wartungsfenster (ggf. nachts) synchron halten. Ja nach Software funktioniert sogar eine Installation in einem Netzwerkpfad.
Gruß
Marco
Moin,
Gruß,
Dani
Als Hypervisor nutzen wir (acropolis) AHV, durch den ein simples clonen von VM´s möglich ist und auch die Pflege eines Templates (Golden-Image) kein Problem wäre. So würden wir dann nur dieses TS-Template pflegen und davon wiederum geklonte ("gesysprepte") VM´s ziehen und im Broker dann ersetzen. Soweit die Theorie. Was ich bisher gelesen habe, sollte das so auch funktionieren und der manuelle Aufwand würde sich auch via PS-Script auf ein Minimum reduzieren lassen. Vielleicht hat da jemand schon Erfahrung, die er mit mir teilen kann.
Wir haben ähnliche Baustellen. Wir haben uns inzwischen von Klonen von RDS Hosts verabschiedet. Inzwischen werden über Unified Entpoint Management (UEM), sprich Softwareverteilung, entsprechende Pakete gebaut, getestet und ausgerollt. Hintergrund ist bzw. war, dass jedes Mal verschiedene Teams (Infrastruktur, Server, Backup und Applikation) zusammenarbeiten mussten. Zwar wurde mit PowerShell auch der Aufwand minimiert, aber nichts desto trotz waren Abhängigkeiten nicht zu lösen. Was immer wieder zu Mehraufwand geführt hat, wenn was schief lief.Gruß,
Dani
