10
Wie eigene Anwendung auf dem AppServer mit TS im laufenden Betrieb aktualisieren
Hallo Zusammen,
sorry für den unpräzisen Betreff.
System Windows 2016 DataCenter, alles Virtualisiert mit HyperV
Wir haben überwiegend eigene Windows-Anwendungen die auf dem AppServer installiert sind.
Es gibt mehrere TerminalServer. Der User meldet sich auf der TS Farm und bekommt irgend einen TS zugewiesen.
Auf dem TS sind lediglich Verknüpfungen der Anwendungen auf dem AppServer. Die .Exe ist also nur auf dem AppServer.
Die Anwendungen werden im eigenen Haus weiterentwickelt. Wenn es ein Update gibt, gibt es ein Rundmail: Bitte AppXY beenden.
Es ist sehr schwer alle User dazu zu bewegen die App zu beenden und zu warten bis Sie wieder dürfen. Der eine geht raus der andere hupft wieder rein.
Je nachdem was es für ein Update ist, benennen wir die laufen .exe um und kopieren die neue .exe auf dem AppServer. Alle User die die .exe starten bekommen die neue Version.
Leider funktioniert das nicht zuverlässig. Manchmal bekommen die doch die alte .exe weil irgend ein TS die .exe vermutlich chasht.
Es muss doch einen zuverlässigen Weg geben. Wir sind ca. 100 User. Das würde bei 24/7 Unternehmen mit mehreren Niederlassungen und mehreren hundert Usern nicht funktionieren.
Wie geht Ihr vor?
Gruß Kostas
sorry für den unpräzisen Betreff.
System Windows 2016 DataCenter, alles Virtualisiert mit HyperV
Wir haben überwiegend eigene Windows-Anwendungen die auf dem AppServer installiert sind.
Es gibt mehrere TerminalServer. Der User meldet sich auf der TS Farm und bekommt irgend einen TS zugewiesen.
Auf dem TS sind lediglich Verknüpfungen der Anwendungen auf dem AppServer. Die .Exe ist also nur auf dem AppServer.
Die Anwendungen werden im eigenen Haus weiterentwickelt. Wenn es ein Update gibt, gibt es ein Rundmail: Bitte AppXY beenden.
Es ist sehr schwer alle User dazu zu bewegen die App zu beenden und zu warten bis Sie wieder dürfen. Der eine geht raus der andere hupft wieder rein.
Je nachdem was es für ein Update ist, benennen wir die laufen .exe um und kopieren die neue .exe auf dem AppServer. Alle User die die .exe starten bekommen die neue Version.
Leider funktioniert das nicht zuverlässig. Manchmal bekommen die doch die alte .exe weil irgend ein TS die .exe vermutlich chasht.
Es muss doch einen zuverlässigen Weg geben. Wir sind ca. 100 User. Das würde bei 24/7 Unternehmen mit mehreren Niederlassungen und mehreren hundert Usern nicht funktionieren.
Wie geht Ihr vor?
Gruß Kostas
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-Key: 466590
Url: https://administrator.de/contentid/466590
Ausgedruckt am: 25.04.2024 um 05:04 Uhr
10 Kommentare
Neuester Kommentar
moin...
du kannst doch die offline nehmen bis die apps aktuell sind... der reihe nach... wie bei den updates
Frank
du kannst doch die offline nehmen bis die apps aktuell sind... der reihe nach... wie bei den updates
Frank
Moin,
1. Aufforderung, dass man sich abmelden soll mit
Damit fange ich so eine halbe Stunde vor dem geplanten Herunterfahren an und wiederhole das alle 5 Minuten.
2. Im der Bereitstellung das Anmelden abschalten.
Im Servermanager mit der rechten Maustaste auf die Hostserver klicken. Achtung: Es kann sich niemand mehr per RDP anmelden. Auch kein Admin.
3. Renitente User zwangstrennen
Wer sich bis 15.31 Uhr immer noch nicht abgemeldet hat, wird rausgeschmissen.
4. Update durchführen und danach nicht vergessen, das Anmelden wieder zu erlauben.
So mache ich das mit meinen TS. Das funktioniert. Und wenn sich ein User beschwert, dass Daten verloren gegangen sind bei der Zwangsabmeldung, kriegt er als Antwort: "Selber schuld. Lesen Sie die Meldungen, die ich schicke, bevor sie Sie wegklicken."
hth
Erik
1. Aufforderung, dass man sich abmelden soll mit
msg * "Es wird ein Update durchgeführt. Bitte melden Sie sich bis 15.30 Uhr ab. Der Server steht voraussichtlich um 16.00 Uhr wieder zur Verfügung." 2. Im der Bereitstellung das Anmelden abschalten.
Im Servermanager mit der rechten Maustaste auf die Hostserver klicken. Achtung: Es kann sich niemand mehr per RDP anmelden. Auch kein Admin.
3. Renitente User zwangstrennen
Wer sich bis 15.31 Uhr immer noch nicht abgemeldet hat, wird rausgeschmissen.
4. Update durchführen und danach nicht vergessen, das Anmelden wieder zu erlauben.
So mache ich das mit meinen TS. Das funktioniert. Und wenn sich ein User beschwert, dass Daten verloren gegangen sind bei der Zwangsabmeldung, kriegt er als Antwort: "Selber schuld. Lesen Sie die Meldungen, die ich schicke, bevor sie Sie wegklicken."
hth
Erik
Also wenn du mit "AppServer" App-V oder VMWare ThinApp meinst die bieten das Updaten im Live-Betrieb von Haus aus ohne irgendwelches Abmelden oder Trennen an, so wie das sein soll, alles was den User fordert vermeiden, gibt sowieso nur Höddel .
https://docs.microsoft.com/de-de/sccm/apps/get-started/deploying-app-v-v ...
https://pubs.vmware.com/horizon-workspace-18/index.jsp?topic=%2Fcom.vmwa ...
Grüße Uwe
.https://docs.microsoft.com/de-de/sccm/apps/get-started/deploying-app-v-v ...
https://pubs.vmware.com/horizon-workspace-18/index.jsp?topic=%2Fcom.vmwa ...
Grüße Uwe
Moin,
wir haben mehrere Anwendungen. Ich möchte ungern den User aus der TS-Session kicken sondern NUR aus der App die gerade aktualisiert werden soll. Da die Entwickler nicht in der Gruppe der Admins sind, können die die Prozesse nicht beenden. Somit wird der Admin kontaktiert der alle TC und den APP-Server besucht und die Anwendung telefonisch zum beenden kontaktiert. Einfach die Anwendung Remote beenden haben wir uns nicht getraut. Da kann alles passieren. Das ist auch der Grund warum wir das terminieren der App nicht in der App eingebaut haben.
Möglicherweise ist App-V ais dem nächsten Beitrag eine Lösung. Die kannte ich nicht.
Gruß Kostas
wir haben mehrere Anwendungen. Ich möchte ungern den User aus der TS-Session kicken sondern NUR aus der App die gerade aktualisiert werden soll. Da die Entwickler nicht in der Gruppe der Admins sind, können die die Prozesse nicht beenden. Somit wird der Admin kontaktiert der alle TC und den APP-Server besucht und die Anwendung telefonisch zum beenden kontaktiert. Einfach die Anwendung Remote beenden haben wir uns nicht getraut. Da kann alles passieren. Das ist auch der Grund warum wir das terminieren der App nicht in der App eingebaut haben.
Möglicherweise ist App-V ais dem nächsten Beitrag eine Lösung. Die kannte ich nicht.
Gruß Kostas
Mit AppServer meinte ich einen klassischen FileServer. App-V kenne ich noch nicht.
Ist dir bekannt welche Art von Anwendungen virtualisiert werden können? Sind das möglicherweise NUR Dot-Net Anwendungen?
Unsere größte Sorge ist, wir können (wollen) die Anwendung nicht Remote abschießen weil wir nicht wissen können was der Anwender gerade macht. Es könnte ja ein Prozess sein der länger dauert und der Anwender in der Zwischenzeit Mittag macht. Ist dieses Problem bei App-V berücksichtigt? Wenn ja, ist dir bekannt wie tief das berücksichtigt wurde? Es gibt Updates da wird ein Labe von links nach rechts verschoben. Das sit nicht kritisch. Es gibt Updates mit Datenbankstrukturänderungen. Da muss zwangsläufig ausnahmslos jeder die App beenden und darf ab den Update nur noch mit der neuen App arbeiten.
Aktuell haben wir den Zustand, der Admin schaut ob alle User aus allen TS die App beendet haben und die App auf dem FileServer niemand offen hat. Dann dir die App gelöscht. Normalerweise ist es so, wenn ich die .exe löschen kann, kat sie niemand offen. Das ist leider nicht zuverlässig. Wir erleben immer wieder dass irgend ein TS die .exe im cashe hat. Wenn der User die .exe startet, bekommt er dann die alte .exe ohne der aktuellen DB-Struktur. In der Regen passiert nicht da es sofort knallt.
Gruß Kostas
Ist dir bekannt welche Art von Anwendungen virtualisiert werden können? Sind das möglicherweise NUR Dot-Net Anwendungen?
Unsere größte Sorge ist, wir können (wollen) die Anwendung nicht Remote abschießen weil wir nicht wissen können was der Anwender gerade macht. Es könnte ja ein Prozess sein der länger dauert und der Anwender in der Zwischenzeit Mittag macht. Ist dieses Problem bei App-V berücksichtigt? Wenn ja, ist dir bekannt wie tief das berücksichtigt wurde? Es gibt Updates da wird ein Labe von links nach rechts verschoben. Das sit nicht kritisch. Es gibt Updates mit Datenbankstrukturänderungen. Da muss zwangsläufig ausnahmslos jeder die App beenden und darf ab den Update nur noch mit der neuen App arbeiten.
Aktuell haben wir den Zustand, der Admin schaut ob alle User aus allen TS die App beendet haben und die App auf dem FileServer niemand offen hat. Dann dir die App gelöscht. Normalerweise ist es so, wenn ich die .exe löschen kann, kat sie niemand offen. Das ist leider nicht zuverlässig. Wir erleben immer wieder dass irgend ein TS die .exe im cashe hat. Wenn der User die .exe startet, bekommt er dann die alte .exe ohne der aktuellen DB-Struktur. In der Regen passiert nicht da es sofort knallt.
Gruß Kostas
Hallo Kostas,
nicht eine Möglichkeit für euch?
Da könnt ihr sortieren und seht genau, wer welche EXE in Benutzung hat und könnt genau diese trennen.
Ich mache einen solchen Austausch außerhalb der Bürozeiten meist zw. 22 und 0 Uhr.
Die paar Leute, die dann gerade arbeiten, kann man problemlos handeln.
grüsse vom it-frosch
Ich möchte ungern den User aus der TS-Session kicken sondern NUR aus der App die gerade aktualisiert werden soll.
Wäre die Computerverwaltung auf dem Application Server - System - geöffnete Dateiennicht eine Möglichkeit für euch?
Da könnt ihr sortieren und seht genau, wer welche EXE in Benutzung hat und könnt genau diese trennen.
Ich mache einen solchen Austausch außerhalb der Bürozeiten meist zw. 22 und 0 Uhr.
Die paar Leute, die dann gerade arbeiten, kann man problemlos handeln.
grüsse vom it-frosch
Hi it-frosch,
doch eigentlich schon. Vor Windows 2016 hat das auch einwandfrei und zuverlässig funktioniert. Seit Windows 2016 zumindest bei unserer Installation funktioniert das nicht mehr zuverlässig. Die TS und der App-Server zeigen mir an, kein User hat das Programm offen. Ich kann auch die .Exe löschen die ich normalerweise nicht löschen kann wenn sie noch in Benutzung ist. Ich überschreibe die .exe und die Anwender starten sie. Von derzeit 107 User bekommen 105 die neue .exe geladen und zwei oder drei sind ab und zu dabei die die alte .exe geladen bekommen. Wenn ich jedoch alle Server neu starte, funktioniert das Update immer zu 100%. Bei unkritischen Updates (z.B.: Feld von links nach rechts verschoben) funktioniert das Update nach dem Vorgehen: .exe umbenennen, neue .exe rein kopieren, Info an die Anwender: "Bitte App XY neu starten" auch mit der gleichen Fehlertoleranz. Die meisten bekommen die aktuelle .exe aber eben nicht zuverlässig jeder.
Gruß Kostas
doch eigentlich schon. Vor Windows 2016 hat das auch einwandfrei und zuverlässig funktioniert. Seit Windows 2016 zumindest bei unserer Installation funktioniert das nicht mehr zuverlässig. Die TS und der App-Server zeigen mir an, kein User hat das Programm offen. Ich kann auch die .Exe löschen die ich normalerweise nicht löschen kann wenn sie noch in Benutzung ist. Ich überschreibe die .exe und die Anwender starten sie. Von derzeit 107 User bekommen 105 die neue .exe geladen und zwei oder drei sind ab und zu dabei die die alte .exe geladen bekommen. Wenn ich jedoch alle Server neu starte, funktioniert das Update immer zu 100%. Bei unkritischen Updates (z.B.: Feld von links nach rechts verschoben) funktioniert das Update nach dem Vorgehen: .exe umbenennen, neue .exe rein kopieren, Info an die Anwender: "Bitte App XY neu starten" auch mit der gleichen Fehlertoleranz. Die meisten bekommen die aktuelle .exe aber eben nicht zuverlässig jeder.
Gruß Kostas
klassisches Cache-Problem... es ist außerdem komplett vorsintflutlich, eine .exe auf einem Fileshare zur Verfügung zu stellen. Ihr aktualisiert also die .exe auf dem Fileshare, überseht aber daß die eine oder andere Usersession noch offen ist und der LOKALE Cache im Arbeitsspeicher jener User-Session hat noch die alte Version.... die Filecache Funktion von Windows kann man aber für Shares abstellen, denn die macht gerne mal Streß, auch mit Tools, die dateibasiert Informationen austauschen.
Die Entwickler sollten mal ein setup bauen, mit dem kann man dann sehr schön auf einer Terminalserverfarm die Anwendung aktualisieren... jeweils einen Server außer Betrieb nehmen, deinstallieren, neu installieren, Server wieder zur Verfügung stellen, fertig. Dann wär auch das Problem mit "der User hat die .exe kopiert" erledigt, denn man kann sogar das komplette c: Laufwerk im Explorer ausblenden.
Alternative:
Sich mal in AppV einlesen, sich eine Maschine zum Erstellen der AppV Container bauen, und die exe in den AppV Container zur Verfügung stellen. Man braucht für ein volles AppV Rollout natürlich ein paar Serverchen extra, aber AppV Container kann man auch so starten solange das AppV Feature aktiv ist bzw bei älteren Versionen die Ausführungsumgebung installiert ist.
Die Entwickler sollten mal ein setup bauen, mit dem kann man dann sehr schön auf einer Terminalserverfarm die Anwendung aktualisieren... jeweils einen Server außer Betrieb nehmen, deinstallieren, neu installieren, Server wieder zur Verfügung stellen, fertig. Dann wär auch das Problem mit "der User hat die .exe kopiert" erledigt, denn man kann sogar das komplette c: Laufwerk im Explorer ausblenden.
Alternative:
Sich mal in AppV einlesen, sich eine Maschine zum Erstellen der AppV Container bauen, und die exe in den AppV Container zur Verfügung stellen. Man braucht für ein volles AppV Rollout natürlich ein paar Serverchen extra, aber AppV Container kann man auch so starten solange das AppV Feature aktiv ist bzw bei älteren Versionen die Ausführungsumgebung installiert ist.
Moin,
Warum nicht wie folgt vorgehen:
Die Entwickler stellen die App auf dem Filer bereit. In einem zwoten Verzeichnis liegt immer eine Kopie des Hauptverzeichnisses. Der erste, der die Exe des Kopieverzeichnisses startet schaut, ob es noch geöffnete Sessions gibt. Wenn nein, wird alles in das Kopie Verzeichnis kopiert/ aktualisiert und erst dann die eigentliche App gestartet.
Ließe sich auch entzerren:
Das Hauptverzeichnis liegt auf dem File und die Kopien auf den TS. Der erste, der am jeweiligen TS die Applikation startet, startet dann den „Updater“, der wiederum die eigentliche App/ dlls startet. Somit wäre spätestens am nächsten Tag jeder TS mit der neuesten Version unterwegs...
Gruß
em-pie
Warum nicht wie folgt vorgehen:
Die Entwickler stellen die App auf dem Filer bereit. In einem zwoten Verzeichnis liegt immer eine Kopie des Hauptverzeichnisses. Der erste, der die Exe des Kopieverzeichnisses startet schaut, ob es noch geöffnete Sessions gibt. Wenn nein, wird alles in das Kopie Verzeichnis kopiert/ aktualisiert und erst dann die eigentliche App gestartet.
Ließe sich auch entzerren:
Das Hauptverzeichnis liegt auf dem File und die Kopien auf den TS. Der erste, der am jeweiligen TS die Applikation startet, startet dann den „Updater“, der wiederum die eigentliche App/ dlls startet. Somit wäre spätestens am nächsten Tag jeder TS mit der neuesten Version unterwegs...
Gruß
em-pie
Hallo em-pie,
du schreibst: "Somit wäre spätestens am nächsten Tag jeder TS mit der neuesten Version unterwegs" das ist leider zu gefährlich. Es kommt darauf an, um was für ein Update es sich handelt. Wenn DB Strukturänderungen sind muss zwangsläufig die passende Version gestartet werden. Wie schon oben beschrieben ist das Caching der Server das Problem. Selbst wenn alle TS zeigen niemand hat die App offen, ist es nicht sichergestellt dass der nächste der die App startet auch die aktuelle Version bekommt. Nur wenn alle TS und der Fileserver heruntergefahren werden hat es zumindest dann zuverlässig funktioniert. Doch genau das ist das Problem. Dann müssen alle User alle Programme beenden und nicht nur das eine welches aktualisiert wurde.
Das Ziel meiner Anfrage war zu erfahren wie große Firmen damit umgehen die mehrere Niederlassungen mit Hunderten von Usern mit dem Problem umgehen. Vorgeschlagen wurde AppV. Kannte ich bis jetzt nicht. Möglicherweise ist das die Lösung. Es kommt darauf an, wie viel Aufwand das bedeuten würde bei jedem Update so einen AppV Container zu erstellen. Schließlich geht es "nur" um eine .exe die zuverlässig ersetzt werden soll. Ich bin generell ein Gegner von Setup-Routinen da sie immer etwas im System hinterlassen. Alle unsere Anwendungen kommen komplett ohne aus. Alles ist in einer Verzeichnisstruktur. Keine Nutzung der Registry, keine DLL oder sonstige Files außerhalb des AppVerzeichnisses. Deshalb funktioniert auch ein Umzug von A nach B mit einem einfachen Verschieben des AppVerzeichnisses.
Gruß Kostas
du schreibst: "Somit wäre spätestens am nächsten Tag jeder TS mit der neuesten Version unterwegs" das ist leider zu gefährlich. Es kommt darauf an, um was für ein Update es sich handelt. Wenn DB Strukturänderungen sind muss zwangsläufig die passende Version gestartet werden. Wie schon oben beschrieben ist das Caching der Server das Problem. Selbst wenn alle TS zeigen niemand hat die App offen, ist es nicht sichergestellt dass der nächste der die App startet auch die aktuelle Version bekommt. Nur wenn alle TS und der Fileserver heruntergefahren werden hat es zumindest dann zuverlässig funktioniert. Doch genau das ist das Problem. Dann müssen alle User alle Programme beenden und nicht nur das eine welches aktualisiert wurde.
Das Ziel meiner Anfrage war zu erfahren wie große Firmen damit umgehen die mehrere Niederlassungen mit Hunderten von Usern mit dem Problem umgehen. Vorgeschlagen wurde AppV. Kannte ich bis jetzt nicht. Möglicherweise ist das die Lösung. Es kommt darauf an, wie viel Aufwand das bedeuten würde bei jedem Update so einen AppV Container zu erstellen. Schließlich geht es "nur" um eine .exe die zuverlässig ersetzt werden soll. Ich bin generell ein Gegner von Setup-Routinen da sie immer etwas im System hinterlassen. Alle unsere Anwendungen kommen komplett ohne aus. Alles ist in einer Verzeichnisstruktur. Keine Nutzung der Registry, keine DLL oder sonstige Files außerhalb des AppVerzeichnisses. Deshalb funktioniert auch ein Umzug von A nach B mit einem einfachen Verschieben des AppVerzeichnisses.
Gruß Kostas
