kostas
Goto Top

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

Content-Key: 466590

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

Printed on: February 6, 2023 at 17:02 o'clock

Member: Vision2015
Vision2015 Jun 27, 2019 at 13:58:47 (UTC)
Goto Top
moin...

du kannst doch die offline nehmen bis die apps aktuell sind... der reihe nach... wie bei den updates face-smile

Frank
Member: erikro
erikro Jun 27, 2019 updated at 14:04:13 (UTC)
Goto Top
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." face-wink

hth

Erik
Member: colinardo
colinardo Jun 27, 2019 updated at 14:22:41 (UTC)
Goto Top
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 face-wink.
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
Member: Kostas
Kostas Jun 27, 2019 at 15:06:11 (UTC)
Goto Top
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
Member: Kostas
Kostas Jun 27, 2019 at 15:18:58 (UTC)
Goto Top
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
Member: it-frosch
it-frosch Jun 28, 2019 at 09:19:25 (UTC)
Goto Top
Hallo Kostas,

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 Dateien
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
Member: Kostas
Kostas Jun 28, 2019 at 11:56:13 (UTC)
Goto Top
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
Member: GrueneSosseMitSpeck
GrueneSosseMitSpeck Jun 28, 2019 at 17:32:55 (UTC)
Goto Top
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.
Member: em-pie
em-pie Jun 28, 2019 at 21:47:59 (UTC)
Goto Top
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
Member: Kostas
Kostas Jun 29, 2019 at 12:17:08 (UTC)
Goto Top
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