"Netzweite Aktualisierung" : ... noch auf dem Weg der Besserung oder "am Ende der Fahnenstange" angekommen ?

[#1]

Hallo Community,

im Unterschied zu Einigen hier in der Community, nutze ich gerne die "Netzweite Aktualisierung" aus dem "Installationsmanager" heraus

Bei den letzten paar netzweiten Aktualisierungen glaubte ich, ein paar Detail-Verbesserungen im Installationsablauf zu 'spüren'.

Allerdings bleibt immer noch ein Rest an Effekten übrig, der mich und vermutlich auch andere Installateure noch 'ausbremst'.

Bei den letzten paar netzweiten Hotfix-Aktualisierungen gab es z.B. immer wieder ein paar bzw. immer die selben Kandidaten (Clients), die sich trotz vorherigem Neustart nicht automatisch als Administrator  automatisch einloggen konnten. Das führte dann zu einem fehlerhaften Abschluss der Aktualisierung auf diesen PCs.

Eigentlich hätte ich erwartet, dass die "Netzweite Aktualisierung" mit dem Beginn der Aktualisierung wartet, bis die jeweiligen PCs entweder automatisch oder manuell eingeloggt sind.

Aber nein, die Aktualisierung wartet nicht auf diejenigen, die entweder zu spät oder gar nicht zur Sache kommen und bricht dort die Aktualisierung mit einer Fehlermeldung ab.

Lässt sich dieses 'unhöfliche' Verhalten des "Installationsmanagers" irgendwie abstellen oder anders einstellen ?

Bei den betroffenen Clients musste ich nämlich immer im Nachhinein eine "Arbeitsplatz-Aktualisierung" anstoßen, was natürlich die abendliche TV-Planung oder gar die Familienplanung des Installateurs durcheinanderbringen kann 😉

Vielleicht kann ja Frau @Katrin_Zahlten etwas dazu sagen (wie schon einmal zu einem ähnlichen Thema)

[#2]

kann an vielem liegen..

ist denn bei funktionierenden und nicht funktionierenden PCs die Netzwerkconfig identisch (bis auf IP)?

Schon versucht die "defekten" Maschinen neu in die Domäne zu holen und das Verhalten zu prüfen?

Ich hab die Probleme nicht.. sollte eine Maschine mal nicht sofort an gang kommen, stoße ich die Installation manuell per RDP an. Das ist dann meist der KommSRV.. ist das gewollt? 

Keine Ahnung.. aber dauert ja nur wenige Sekunden.

Die letzte Installation ging ziemlich schnell.. mit 4 Maschinen in der Datenanpassung usw.

[#3]

---

@boomboom schrieb:
[...] sollte eine Maschine mal nicht sofort an gang kommen, stoße ich die Installation manuell per RDP an [...]

---

Was heißt "anstoßen" ?  ... womit ?  

Manuelles Login und "Warten auf Godot" reicht bei mir bei mehreren PCs nicht aus.

Ich muss mich also auf mehreren PCs manuell einloggen, eine "Arbeitsplatz-Aktualisierung" anstoßen und auf das Ende der "Arbeitsplatz-Aktualisierung" warten.

Das dauert länger als einem lieb ist und sollte eigentlich nicht erforderlich sein.

Normalerweise sollte das gesamte Client-Netzwerk ja parallel und automatisch aktualisiert werden

... wüsste auch nicht, was an der Netzwerkkonfiguration falsch sein sollte, da die betreffenden PCs ansonsten völlig normal im Datev-Client-Server-Netzwerk arbeiten.

Das Stochern im Nebel wäre zwar immer möglich, frisst aber enorm Zeit

[#4]

in die domäne neureinholen dauert nicht lange.

mit manuell anstossen klicke ich unten rechts, in der infoleiste, auf so einen updateknopf (den auftrag hat die maschine erhalten.. aber wartet..?) oder nehme die verknüpfung auf desktop.

da öffnet sich dann so ein fenster mit sofort starten, 10 minuten warten usw.

Mit der Verknüpfung geht es auch sofort:

DATEV\PROGRAMM\Install\DvInesASD.exe" -run

[#5]

danke @boomboom ,

Das Update-Tool hatte ich auch schon gesucht, aber auf den betreffenden PCs nach dem manuellen Einloggen nicht gesehen. 
Insofern weiß ich nicht, ob der Auftrag jeweils 'bis zum Desktop des Administrators' vorgedrungen ist.

Wenn der Direktaufruf des Update-Tools funktioniert, ist es schon mal eine Verbesserung.

Nochmals danke, @boomboom 

[#6]

Hier möchte ich auch gerne, als "Betroffener" nachtragen, dass mich das Verhalten ebenso ärgert.

Es ist noch nicht viel Installationen her, da hatten wir im P2P-Netz dreimal in der Folge das Glück, dass die netzweite Aktualisierung, die ich absolut bevorzuge, durchlief und sauber abschloss.

Nur aber deshalb, weil ich irgendwann drauf kam, dass zunächst alle PCs inklusive Quasi-Server neu zu starten sind und zunächst der Quasi-Server als Arbeitsplatzinstallation bearbeitet werden muss, bis diese vollständig abgeschlossen ist.

Anschließend dann die netzweite Installation für die Klienten, welche, wie erwähnt vor geraumer Zeit noch durchlief.

Bereits vor und richtig nach Installation von 15.0 tauchten wieder massive Probleme auf, die eine Installation verhinderten.

Im Prinzip muss man dann mit allen Tricks arbeiten: Update im Monitor manuell anstoßen geht hier zumeist in den wenigsten Fällen.

Die Geräte bekommt man oftmals nur noch durch die Säuberung via "dvinesmasterinfo" aus der Installationsschleife, muss dann die netzweite Aktualisierung abschließen, um anschließend Arbeitsplatzinstallationen anzustoßen.

Ich muss dem Beitragsersteller hier beipflichten, denn ein charmanter Installationsablauf sieht anders aus und wenn dann der gesamte Freitag Mittag (arbeitet bei uns niemand) für eine Update verbraten wird, weil man ja aktiv teilnehmen muss, ist das alles andere als hilfreich.

Ach ja, die DATEV hat sich das bereits via FB angeschaut, die Einstellungen als richtig bewertet und auch auf o.g. "workarounds" verwiesen.

edit: Den "Update-Manager" öffnet man relativ einfach über "win" und Eingabe "Update-" und er erscheint bei den Apps; ebenso die "dvinesmasterinfo" zur Löschung bestehender Aufträge, die eine neue Installation blockieren.

Fazit: Das lief schon mal deutlich besser.

[#7]

... wenn die 'arbeitsunwilligen' PCs wenigstens auf Godot warten würden ...

... aber nachdem auf dem "Admin-PC" im Status der 'faulen' Arbeitsplätze eine fehlerhafte Aktualisierung gemeldet ist, tut sich dort nichts mehr, jedenfalls nicht freiwillig.

Dann musste ich immer von Hand (per virtueller Turnschuh-Installation) die "Arbeitsplatz-Aktualisierung" starten.

...das nervt !

[#8]

---

---

---

@vogtsburger  schrieb:

Bei den letzten paar netzweiten Hotfix-Aktualisierungen gab es z.B. immer wieder ein paar bzw. immer die selben Kandidaten (Clients), die sich trotz vorherigem Neustart nicht automatisch als Administrator  automatisch einloggen konnten. Das führte dann zu einem fehlerhaften Abschluss der Aktualisierung auf diesen PCs.

---

Bereits "schlechte" Netzwerkkabel reichen dafür aus, so ein Verhalten zu erzeugen. Das können minderwertige Kabel sein oder die haben einen kleinen Defekt (leichter aber blöder Knick reicht aus). Manchmal kann man sowas auch wie folgt erkennen: Einfach mal in die Netzwerkeinstellungen in Windows reinschauen und die Eigenschaften der Ethernet-Verbindung aufrufen. Seit längerer Zeit haben alle PC's und Router mit einigermaßen guten Kabeln 1Gbit/1000 Mbps bei Kabelverbindung. Stehen da nur 100Mbit/Mbps an, ist irgendwas nicht ok. Da sollte man nach Möglichkeit als erstes auf das Kabel (von der Wand zum PC) schauen und hoffen dass es nicht die Leitung in der Wand ist ...

Ich habe hier auch einen Platz mit dem Phänomen, bei dem ich sowohl beim aktuellen PC als auch bei den Vorgängergeräten die Aktualisierung immer manuell anstoßen muss. Dann läuft es aber auch durch. Und da läuft auch die Kopiererei von Dateien etwas langsamer als bei den anderen. Da habe ich den konkreten Verdacht dass das Kabel nicht mehr in Ordnung ist. Problem ist ich müsste drei Tische und zwei Regale, also sozusagen die halbe Bude ausräumen um da ran zu kommen, bin da nie dazu gekommen. Es läuft ja, nur nicht optimal, und es gab nie Probleme bei SQL.

[#9]

sowas kann es auch sein.. wenn alle stricke reißen einen kleinen switch an ein funktionierendes kabel hängen. besser zwei maschinen mit je 500mbit als eine maschine mit 100mbit.. vereinfacht gesprochen.

[#10]

Das Problem kann man nicht nur der DATEV in die Schuhe schieben.

Wenn Sie viele "PCs" haben, dann bekommen Sie ein "Schneeflockenproblem":

Die sehen eigentlich alle ganz gleich aus, aber wenn Sie sie mit einer starken Lupe betrachten, dann wird sofort offenbar, daß sie sich alle unterscheiden.  Nichtmal Microsoft hat seine automatisierten Betriebssystemupdates im Griff.

Vielleicht ändern Sie Ihr Betriebskonzept ?   Das Problem ist mit zwei Buchstaben erklärt:  "PC", "personal computer".  HP entblödete sich vor 15 Jahren nicht, zu werben mit dem Slogan "The PC is personal again".

Unternehmen, also auch Steuerkanzleien, brauchen absolut keinen "PC", sondern ein Werkzeug für den Firmengebrauch.   Man kann sehr einfach aus einem "PC" einen "Thin Client" machen.  Besser noch:  Preiswerte Mini-Geräte besorgen, z.B. INTEL NUC.

Die booten dann aus dem Netz und verbinden sich gegen einen fälschlicherweise so bezeichneten "Terminalserver".  Da haben Sie dann Ihre DATEV drauf, und zwar KOMPLETT mit Fileserver, Lizenzmanager und Anwendungen.  Spaßigerweise läuft das fluffiger, als wenn Sie einen separaten Fileserver betreiben.  Abgesehen davon ist der "Fileserver" eigentlich ein "Datenbankserver", aber wer weiß heute noch den Unterschied ?

Wie auch immer:   Sie haben EINMAL ein bißchen Arbeit, aber dann sind die Updates völlig problemlos.   Das muß man wirklich sagen:  Gute Arbeit, DATEV.   Ich wähle "Arbeitsplatzaktualisierung" und nach 30 Minuten ist das durch, und zwar ohne Fehler.

Schon die Anbindung des "Fileservers" hat DATEV ja eigentlich nie richtig hinbekommem, die "Platte L" und der SMB-Schmutz sind ja immer noch in vielen Installationen zu finden.  Gru-se-lig.   Kann man sich wirklich guten Gewissens sparen, in einer Kanzlei mit etwa 30 Nutzern haben wir so etwas seit 20 Jahren im Einsatz, seinerzeit mit "Windows 2003 Server".   Der zuständige DATEV-Berater meinte, "so schnell habe ich unsere Programme noch nie laufen sehen".

Mit der "all-in-one" - Lösung sparen Sie sich auch die fehleranfällige, alberne und vor allen Dingen teuere "Wirrtualisierung".   Und für die Datensicherung bringen die Windows-"Server" geeignete Werkzeuge mit.

Wenn man ein Problem, hier:   "Automatisierte Rechneraktualisierung" nicht in den Griff bekommt, dann eliminiert man einfach die Ursachen.

Als Kür stellen Sie eine kleine Linux-Büchse davor, über die Sie den Fernzugriff regeln.

Denn so ein "Windows NT", egal jetzt in welchem Metastasierungsstadium, möchte man eigentlich nicht ins Internet hängen.

[#11]

@Koppelfeld 

https://sharepoint360.de/aus-fuer-office-via-terminal-server-microsoft-forciert-cloud-modell-anwender-koennen-noch-ausweichen/

Jetzt noch auf Terminalserver umstellen.. naja.

TS hat auch viele Nachteile:

- defekt, ganz Kanzlei steht erstmal.. außer man hat mehrere WTS mit Brokern usw.

- komplexer

- schlechtere Skalierbarkeit

- die für DATEV wichtige Singlethreadperformance ist beschränkt

usw.

Hat alles so seine Vor- und Nachteile..

Mir war immer sehr wichtig, dass immer alles läuft.. und wenn ich die Clientfunktion auf 25 Geräte verteile, halte ich das Risiko doch relativ gering. Verbleibt hauptsächlich nur noch der FS als Störquelle.

[#12]

Oh ja, da bringen sie mich tatsächlich auf einen Idee, denn diesen "Flaschenhals" habe ich auch schon mal irgendwie "gespürt" und ja, bei mir am Quasi-Server stehen da tatsächlich nur 100 im Ethernet und wenn mehr da gleichzeitig die Updates saugen wollen, wird es knapp.

Super Tipp. Danke.

Mal schauen, was es bringt, das "Rohr frei zu machen".

[#13]

Bei uns war mal ein komplettes Geschoss 'lahm'

(Achtung: ich spreche nicht von Munition, sondern von einem Gebäude-'Stockwerk') 

Ich teste seither immer wieder mal konkret die Übertragungsgeschwindigkeit aller Clients im LAN und werde das jetzt auch nochmal tun, aber ich rechne eigentlich mit anderen Ursachen.

... vielleicht 'beißen' sich irgendwelche Prozesse im Autostart der Clients oder der Prozessaufruf ist in der falschen Reihenfolge, oder vielleicht huschen die PCs zu schnell über einzelne Schritte hinweg.

... klingt abenteuerlich, aber ich habe schon erlebt, dass es Fehlermeldungen gab, weil ein PC zu schnell war. Nach dem künstlichen Einfügen von Wartezeiten, z.B. mit dem PING-Befehl im Login-Script, lief die Anmeldung dann korrekt

... aber es wird sich (hoffentlich) noch eine plausible Erklärung für die o.g. Effekte finden lassen

[#14]

Ihre Einwände sind nachvollziebar, aber die Erfahrungen im unmittelbaren Vergleich mit "Streichelzoo" - PC-Landschaft zeigen:

- Die Gesamt-Zuverlässigkeit ist DEUTLICH höher.

- Die Performance ist wesentlich besser.

Auch bei einem "klassischen" Modell haben Sie mehrere kritische Punkte, den "Fileserver" haben Sie ja schon genannt.   Wenn ein (ggfs. der einzige) Switch ausfällt, dann war's das.

Sie eliminieren allerdings mit einem zentralen Anwendungsserver die schlimmste anzunehmende Unfallquelle, nämlich den verspielten Benutzer.  Der kann nämlich in einem "flachen" Netz die gesamte Umgebung NACHHALTIG lahmlegen, wie schon häufig passiert.

"Single Thread Performance":   Viele "DATEV-Systempartner" empfehlen ZWEI Anwendungsserver ("Terminalserver" ist Laiensprech -- das ist nämlich ein Gerät, mit dem man ein serielles ASCII-Terminal bspw. mit TELNET über Netzwerk betreibt - ich versuche immer, zu verhindern, daß Microsoft eine klare Fachterminologie kompromittiert).   Dazu braucht es dann aber einen gemeinasmen "Fileserver".   Und weil man keine drei Server betreiben möchte, kommt noch eine Virtualisierungsinstanz drunter.

Und schon ist der Performancekiller geboren.

Die DATEV-Software ist nicht für Systeme geeignet, die auf Multithreading setzen.

"Small is manageable".

Wenn Sie dann auch noch ein bißchen Geld in die Hand nehmen und einen vernünftigen Server kaufen, also nix DELL o.ä., sondern bspw. einen HP DL360 mit SAS-SSDs, ordentlichen Controllern, viel Hauptspeicher, starke CPUs und sauber LACP-aggregierten Netzwerkkarten (sind ja schon 2x10GB/s an Bord), dann haben Sie Ihre Ruhe PLUS Performance satt - da kommt ein Einzel-PC nicht dran.

Das Problem sind eher die Mtarbeiter, die plötzlich nicht mehr spielen und basteln können.

Und wenn Microsoft "Exchange und Outlook" abkündigt:  Aber gerne doch, berufsrechtlich sowieso nicht verwendbar.  Nimmt man halt die 2019er Versionen.

[#15]

Office 2019 läuft auch bald aus..

Das sind persönliche Erfahrungswerte die man nicht teilen muss...

bis auf 5-6 defekte Netzteile, ein defektes Mainboard und nun mal ein defektes Userprofil hatten wir die letzten 10 Jahre nichts.

Und die Sachen lassen sich in 10-15 Minuten reparieren.. mal ausgenommen die Updatezeiten also sehr nahe an 100% Verfügbarkeit.

Auch haben wir nicht die angesprochenen Performanceprobleme im Dokumentenkorb, DMS usw. usw.

Natürlich kommen einzelne PC's dadran...

Das sieht nicht nur schnell aus, sondern fühlt sich auch so an... und wenn der Fileserver nicht schon 5 Jahre alt wäre, sähe es evtl. noch etwas besser aus.. dabei ist es auch noch vollkommen egal, ob 5 oder 25 Mitarbeiter am gange sind oder die 2 oder 20 Programme offen haben.

Und we keinen Ersatzswitch im Schrank hat.. naja!

[#16]

Hallo @vogtsburger ,

gerne versuche ich zu Ihrer Schilderung etwas beizutragen. Nur bin ich angesichts der Beschreibung etwas ratlos. Die Netzweite Aktualisierung (NWA) muss und soll nicht warten, bis alle Clients angemeldet sind (automatisch oder manuell). Der Auftrag zur NWA liegt zentral im Netz und jeder Client, der sich (automatisch) anmeldet, oder manuell angemeldet wird, arbeitet den Auftrag für sich selbst ab. Zwischen Erstellung/Freigabe des Auftrags und Abarbeitung durch alle Clients können durchaus auch mal Tage liegen (weil ein Notebook gerade im Außendienst ist). Auf derlei 'Nachzügler' zu warten wäre im Sinne des Durchsatzes kontraproduktiv.

Nur: ein Client, der (gerade) nicht angemeldet ist, darf deswegen noch lange nicht abbrechen! 

Meine Annahme ist, dass der Abbruch-Grund nicht verursacht wird durch ein verspätetes Anmelden, sondern durch System-Implikationen (Vertrauensstellung oder dergl.). Gerne können wir hier mit Analyse unterstützen. Voraussetzung ist allerdings, dass Sie uns vom 'Problem-Zeitpunkt' die Logbücher zukommen lassen.

Wenden Sie sich dazu gerne unter Bezugnahme dieses Community-Beitrags an die Mailadresse it-infrastruktur@datev.de 

Der Tipp von @boomboom den Auftrag am Client, der sich vermeintlich zu spät anmeldet, manuell an zu stoßen funktioniert durch Aufruf des Update-Managers im Startmenü.

mit freundlichen Grüßen,

Katrin Zahlten

[#17]

Danke für das Feedback, Frau @Katrin_Zahlten 

vermutlich habe ich den Effekt nicht präzise genug geschildert.

Bei der 'normalen' "Netzweiten Aktualisierung" starten die Clients mit der Aktualisierung, sobald sie automatisch oder manuell eingeloggt sind, ggfs. auch Stunden später. Falls sich ein Client nicht automatisch einloggt, klappt es dann in der Regel automatisch nach einem manuellen Neustarten.

Bei dieser normalen "Netzweiten Aktualisierung" habe ich also (fast) nichts zu meckern. Das hat sich in den letzten paar Monaten mMn verbessert.

Bei der "netzweiten Hotfix-Aktualisierung" starten aber mehrere Clients gar nicht mit der Aktualisierung, auch nicht nach dem manuellen Neustart oder dem manuellen Login. Der automatische Login funktioniert bei diesen Clients sowieso nicht.

'Dummerweise' erscheint aber im Statusfenster am "Admin-PC" schon nach rel. kurzer Zeit die Meldung "Aktualisierung nicht erfolgreich" (oder so ähnlich)

Der Auftrag zur Hotfix-Aktualisierung ist dann anscheinend gecancelt.

Wenn ich die Hotfix-Aktualisierung bei diesen Clients durch Aufruf des "Update-Managers" nachträglich doch noch anstoßen kann, soll es mir für den Moment Recht sein, ansonsten muss ich die Arbeitsplatz-Aktualisierung anstoßen.

Haben Sie vielleicht einen 'heißen' Tipp, in welchem der vielen Logbücher die Ursache des Abbruchs zu finden sein könnte ? Ich will möglichst auch verstehen, was und warum etwas nicht so läuft, wie es sollte.

Ich vermute mal, dass die normale "Netzweite Aktualisierung" auch nicht korrekt laufen würde, wenn es noch Fehler in der Netzwerkkonfiguration gäbe. Gibt es denn grundsätzliche Unterschiede zu der "Hotfix-Aktualisierung" ?

[#18]

Sehr geehrter Herr Vogtsburger

Diese Frage wurde bereits im Jahr 2012 gestellt.

Mit freundlichen Grüßen

Diplodocus

[#19]

@diplodocus schrieb: [...] Diese Frage wurde bereits im Jahr 2012 gestellt [...]

.. dann haben Sie sicher auch den Link zur Lösung 'im Ärmel' .... falls es damals eine Lösung gab 😉

Übrigens, damals wusste ich noch nicht, dass es eine Datev-Community gibt 

[#20]

Die Lösung war mit der DVD jeden client manuell zu installieren.

[#21]

Hallo @vogtsburger ,

vielleicht habe ich auch nicht sorgfältig genug gelesen.

Für die netzweite Hotfixinstallation ist ein unwesentlich anderer Prozess zuständig, als bei der Netzweiten Aktualisierung. Eine spezifische Problem-Situation, in der ein relevanter Prozess auf den Clients bei Änderung des Benutzer/-kennworts nicht startet, wurde identifiziert, wird aller Voraussicht nach aber erst zu den DATEV-Programmen 16.0 flächendeckend ausgeliefert. 

Um Ihre Situation beurteilen zu können, würden wir uns freuen, wenn Sie uns die Logbücher zukommen lassen würden. Die Logbücher sammeln Sie wie im Dokument Installations-Logbücher zur Analyse an DATEV übermitteln - DATEV Hilfe-Center beschrieben vom relevanten Zeitraum ein.

Mit freundlichen Grüßen,

Katrin Zahlten

[#22]

Hallo @diplodocus ,

hier handelt es sich vermutlich um ein Missverständnis. Hotfixes, die @vogtsburger gerne installieren möchte, sind nicht auf der DATEV Programm-DVD enthalten. 

mit freundlichen Grüßen,

Katrin Zahlten

[#23]

Moin Moin

Also bei der netzweiten Aktualisierung des Lodas-Hotfixes kam es bei uns dazu, dass danach der Arbeitsplatz nicht mehr starten konnte. Notwendig war, sich auf den Terminalservern als Admin einzuloggen und die Admin-Abmeldung vornehmen zu lassen.

Übrigens, wozu ist die denn gut? Ich meine nach dem Server-Neustart sollte doch alles erledigt sein. Die Antwort interessiert mich brennend und meine Geschäftsführung war auch nicht begeistert und hätte auch gerne eine Antwort.

Ich habe diese Abmeldung des Admin am Ende schon einige Zeit beobachtet - aber bislang schien es so, es reicht, wenn dies am TS geschieht, auf dem der Installationsmanager läuft. Seltsame Entwicklung!

Dass man hin und wieder einem TS (oder Rechner) anstupsen muss, ist so, hat sich aber gegenüber der Zeit vor 5 Jahren gut reduziert. War allerdings vor 2 Jahren auch schon besser. - Natürlich meine Erfahrung, das muss nicht allgemeingültig sein.

Was ich seit einigen Monaten allerdings beobachte, ist, dass das Fenster für den Fortschritt der netzweite Aktualisierung gerne mal nicht den Stand der Aktualisierung anzeigt. Die beiden letzten Male war es praktisch kompletter Unsinn: Die TS waren durch, aber die Anzeige war der Meinung das läuft nicht richtig. Hätte ich vielleicht Screenshots machen sollen ... aber zugegeben, ich war froh, durch zu sein und auch müde.

Will sagen: Rund läuft die Netzweite Aktualisierung zumindest in den Fortschrittanzeigen nicht. Das lief schon viel besser - auch schon perfekt! Wer aber ein paar Jahre Datev-Update-Erfahrung mitbringt, der kann damit schon leben - auch wenn es hin und wieder unerwartete Ausfälle, wie den erwähnten Fehlerabbruch beim Start des Arbeitsplatzes gibt (zugegeben, es war der weitaus schlimmste Konsequenz nach einem Update in den letzten Jahren). Hoffen wir, dass Neueinsteiger in die Datev-Welt sich keinen Herz-Kasper holen. 😉

QJ

[#24]

Ich habe mal 'spaßeshalber' die Logbücher des relevanten Zeitraums eingesammelt, also von dieser einen, 'kleinen', netzweiten Hotfix-Installation (LODAS) ...

... und war wieder schwer beeindruckt, wie viel die Datev-Mitarbeiter in diesem kurzen Installations-Zeitraum 'von Hand' mitprotokollieren 😅

538 Dateien in 67 Ordnern
95,2 MB (99.882.028 Bytes)

Jedes dieser ca 100 Millionen Bytes entspricht ja einem (1) ASCII-Zeichen,

Also werden quasi für diese kurze Aktion rund 100 Millionen Tasten gedrückt 

Das ganze Konvolut als Bettlektüre wäre verdammt viel Lesestoff.

Die Familienplanung müsste dann endgültig und komplett gecancelt werden.

Ich hatte Sie in meinem jugendlichen Leichtsinn um einen 'heißen' Tipp gebeten, wo ich in den Logs die Ursache des o.g. Effekts erkennen könnte.

Diese Bitte ziehe ich jetzt sicherheitshalber wieder zurück, um die Datev nicht komplett zu blockieren 😋  Es warten ja viel wichtigere Aufgaben, z.B. der Buchungsautomat mit seiner KI.

Außerdem bin ich ja sicher der Einzige unter den Zigtausenden von Datev-Installateuren, der diese Effekte hat. Und solche Privilegien würden ja auch eine große Verantwortung mit sich bringen 😎

Ich werde daher versuchen, den betreffenden PCs bei der nächsten Hotfix-Installation 'die Steigbügel zu halten', z.B. indem ich mich schon vorauseilend als Administrator einlogge und bei Bedarf schon mal manuell den Update-Manager starte oder mit anderen 'Klimmzügen' unter die Arme greife, in der Hoffnung, dass die Zickereien demnächst von alleine verschwinden

Ich beneide Sie nicht, Frau @Katrin_Zahlten, dass Sie es mit solchen Prozessen und 'Workarounds' zu tun haben.

Ich frage mich bloß:

Guckt jemals eine natürliche Person in solche Logs oder werden sie nur 'auf Halde' produziert und dann bei Bedarf nach bestimmten Suchbegriffen gescannt oder gar von relativ intelligenten, künstlichen Algorithmen ausgewertet ?

[#25]

---

@vogtsburger  schrieb:

Ich habe mal 'spaßeshalber' die Logbücher des relevanten Zeitraums eingesammelt, also von dieser einen, 'kleinen', netzweiten Hotfix-Installation (LODAS) ...

... und war wieder schwer beeindruckt, wie viel die Datev-Mitarbeiter in diesem kurzen Installations-Zeitraum 'von Hand' mitprotokollieren 😅

538 Dateien in 67 Ordnern
95,2 MB (99.882.028 Bytes)

...

Ich frage mich bloß:

Guckt jemals eine natürliche Person in solche Logs oder werden sie nur 'auf Halde' produziert und dann bei Bedarf nach bestimmten Suchbegriffen gescannt oder gar von relativ intelligenten, künstlichen Algorithmen ausgewertet ?

---

Der Umfang an Logs ist in der Tat beeindruckend. Natürlich erlauben diese automatisiert und auch manuell eine qualifizierte Fehlersuche. Man muss halt wissen wonach man suchen muss, durchlesen kann man die praktisch nicht mehr. Sicher sind die auch so aufgebaut, um einen gewissen Zwang zum "Herstellerservice" zu erreichen.

Wenn man das letztlich bezahlen müsste (z.B. nach Aufwand), dann wird man wohl schnell feststellen, dass ein Neuaufsetzen eines Systems im Grunde günstiger ist (dies ist die klare Aussage, die ich von eine Datev-Systempartner mal bekam, wobei er sich primär auf Microsofts Logs bezog).

Den bei Ihnen relevanten Fehler müsste die netzweite Installationsroutine m.E. eigentlich von selbst aufführen und bestenfalls auf die relevante Log verweisen.

Viele Grüße

[#26]

@Nutzer_8888 schrieb: [...] Den bei Ihnen relevanten Fehler müsste die netzweite Installationsroutine m.E. eigentlich von selbst aufführen und bestenfalls auf die relevante Log verweisen [...]

... das bringt mich auf neue Ideen:

Beim Auftreten solcher Fehler reagiere ich leider nicht so kühl und ruhig, wie es eigentlich gut wäre, sondern ich versuche, den Fehler schnellstmöglich zu beheben oder zu umgehen.

Wie bei echten Kriminalfällen sollte man aber erst die 'forensischen Spuren' sichen und nicht durch Hyperaktivität vernichten, also Datum, Uhrzeit, Computername, Status, Blutdruck, Puls, Raumtemperatur etc. festhalten, um anschließend exakt nach solchen Merkmalen suchen zu können 😉 

Eigentlich sollte ja auch das ServiceTool detailliertere Informationen zu den Fehlern und ggfs. zu deren Behebung geben können. Da aber wohl niemand von den Datev-Mitarbeitern diese Effekte jemals gesehen oder damit gerechnet hat, wurde dieser Check sicher nicht implementiert.

Da diese Effekte aber (erst) in letzter Zeit regelmäßig auftreten, muss es ja konkrete Ursachen dafür geben ... sollte man meinen. 

(vielleicht gibt es ja sogar im TV eine Sendung oder im Internet einen Blog "Technical Detectives" oder so ähnlich und ich weiß bloß nichts davon)

[#27]

Die genaue Analyse bestenfalls mit konkretem Log-Eintrag wäre schon toll.

In meine Augen ist dieses "Fremdanmelden" aber immer auch sensibel abhängig von den nicht gerade wenigen und obendrein auch nicht gerade einfach verständlichen Einstellungen des Windows OS (AD, GPO ....) sowie der enthaltenen nicht seltenen Fehlerchen. Somit könnte auch die Ereignisanzeige vom Windows wertvolle Hinweise liefern.

Datev könnte ja mal präziser beschreiben, wie die Fremdanmeldung konkret abläuft .

Die genaue Zeit, wann etwas passiert ist beim Durchstöbern der diversen Diagnostik-Logs und Meldungen absolut essenziell!

Ich hatte früher (aber halt vor 15.0) auch mal eine Phase, wo ich mich an einigen Rechner manuell als Install-Admin anmelden musste (dann lief aber alles automatisch durch - ggf. konnte man beim Start halt gleich die Prozedur ohne Wartezeit anstoßen). Dies wurde dann in der Tat besser und glaube Version 13.1 und evtl. noch 14.0 lieferten einige netzweite Installationen, wo alles ohne manuelle Eingriffe durchlief.

Bei uns gab es seinerzeit keine erkennbare Systematik bei den betroffenen Rechnern und die Anmeldung konnte initial oder auch nach einem Neustart im Laufe der Installation hängen bleiben.

Die Rechner wurden auch bei uns vor Installationen neu gestartet um das Risiko mit den Anmeldungen zu minimieren.

Die 14.1 brachte dann ständig Probleme wegen beendeter Dienste am Fileserver (Stichpunkt: Plattforminstallation), aber die Anmeldung der Client klappte sehr gut im Gegensatz zur Abmeldung, die nun manuell erfolgen musste.

Bei Ihnen scheint das Thema jedoch anders gelagert zu sein, aber ggf. decken sich die Erfahrungen mit der früheren Zeit.

Nach Installation wird Datev normalerweise auch über den Ablauf informiert (falls man dies nicht deaktiviert hat), so dass die Abbrüche zumindest registriert sein sollten.

PS: Wenn ich mir das ständige Gefrikel an allen Remote-Funktionalitäten im Zusammenhang mit Windows Updates so anschaue, kann hier auch einiges schlummern. Hier könnten sfc.exe mal hilfreich sein, falls irgendwas am System beschädigt ist.

Solange es notfalls manuell läuft und der physikalische Zugriff möglich ist, dann wäre ein Würgaround ggf. die betroffenen Rechner aus der netzweiten Installation zu nehmen und gleich manuell zu installieren.

Im Übrigen hatte unser Datev-Systempartner immer - auch bei kleinsten Fehlern - sofort die Installation manuell angestoßen.

Vielleicht wird auch bald wieder was geändert und alles ist anders ...

[#28]

Nachtrag:

... habe noch ein wenig Detektiv 'gespielt' und muss jetzt doch eine meiner früheren Aussagen etwas korrigieren

@vogtsburger schrieb:

'Dummerweise' erscheint aber im Statusfenster am "Admin-PC" schon nach rel. kurzer Zeit die Meldung "Aktualisierung nicht erfolgreich" (oder so ähnlich)

Der Auftrag zur Hotfix-Aktualisierung ist dann anscheinend gecancelt.

... das lief laut den Screenshots, die ich während der Installation gemacht hatte, doch ein wenig anders:

Die betreffenden PCs reagierten nämlich gar nicht auf den 'Befehl' zur netzweiten Hotfix-Installation und es gab bei diesen Arbeitsplätzen auch keine neuen Status- oder Fehlermeldungen. Alle anderen Arbeitsplätze lieferten nach recht kurzer Zeit jeweils eine Erfolgsmeldung.

Erst nach dem manuellen  Einloggen und nach dem manuellen Start der Hotfix-Arbeitsplatz-Installation wurde jeweils der Auftrag ausgeführt und im Statusfenster des Admin-PCs erschien dann für den jeweiligen PC die Meldung: "Ausführung erfolgreich abgeschlossen"

Neue Erkenntnis:

Da die Aufträge zur Installation gar nicht erst starteten, konnten sie auch nicht abgebrochen werden 😋

Nach wie vor stellt sich die Frage:

warum 'hören' und 'befolgen' mehrere Arbeitsplätze den 'Befehl' zur Hotfix-Installation nicht ?

[#29]

Nachtrag:

vielleicht gibt es ja eine Prüfmöglichkeit mit Datev-Bordmitteln vor der nächsten "Netzweiten Aktualisierung" oder der nächsten netzweiten Hotfix-Installation, z.B. mit dem ServiceTool, mit DSTest oder mit anderen Tools, um mir die 'zickenden' Kandidaten anzuzeigen.

Dann könnte ich gezielt die Voraussetzungen schaffen, bei Bedarf auch durch manuelle 'Handgriffe', damit die nachfolgende, netzweite Installation unterbrechungsfrei und automatisch durchlaufen kann.

So jedenfalls die Theorie 😉

... und falls es diese Prüfmöglichkeit mit Datev-Bordmitteln und vor der netzweiten Installation nicht gibt, wäre es doch eine gute Gelegenheit, eine solche Möglichkeit zu schaffen, oder, Frau @Katrin_Zahlten & Datev-Kollegen ?

[#30]

Ein paar posts weiter funktioniert die update Installation nicht, weil ein win11 Client nicht startet. Bei mir vor 10 Jahren lag es am automatischen Herunterfahren des Fileserver.s. Der war herunter und dann gab es einen GAU. Bei den hotfixes kann man nur die Logs ansehen. Wie die Kollegen sagen Kabel, schlechte Programmierung, PCs überholen ,unterschiedl.pcs etc

Genaues nicht bekannt da nicht alle updatefehler haben.