Der April 2016-Patchday (siehe Patchday: Microsoft Updates vom 12. April 2016) scheint für einige Windows-Nutzer mal wieder arge Nachwirkungen oder argen Ärger zu bereiten. Das reicht von arg zäher Update-Suche über Boot-Fehler ist. Hier ein kleiner Abriss ….
Anzeige
Update-Suche ist extrem zäh …
Auf meinem System wurden die Updates für Windows 7 SP1 recht zügig gefunden und auch installiert (wie immer man auch zügig definieren mag). Auffällig ist in den Kommentaren zum Artikel Patchday: Microsoft Updates vom 12. April 2016, dass Nutzer sich über eine elendig lange Update-Suche beschweren.
Zitat eines Blog-Lesers per E-Mail: In meiner W7-VM in der ich viel arbeite, läuft es auch wieder Amok. Das Ganze ist mittlerweile ein Drama bei W7, sicher nicht ganz zum Unwillen von MS, so wechseln die Leute dann doch schneller zu W10.
Und nein, das ist keine Quelle, die nicht weiß, wie man mit Updates umgeht, sondern eher Tippgeber, wenn es um Inside-Infos geht. Ich hatte das Thema ja grundsätzlich im Blog-Beitrag Windows 7: Update findet nichts oder dauert ewig angesprochen. Fehlende Updates zur Aktualisierung des Windows Update-Clients können keine Ursache sein – behaupten die Kommentatoren doch, dass an den vorherigen Patchdays die Update-Suche zügig ablief. Irgend etwas scheint sich also geändert zu haben.
"Secure Boot Violation" bei ASUS Mainboards für Skylake
Auf die zweite Unbill wurde ich von Blog-Leser Mathias L. per E-Mail aufmerksam gemacht.
Heute erreichten mich unabhängig bereits zwei Kunden die beim Starten ihres PCs eine "Secure Boot Violation" Meldung bekamen (roter Kasten mit englischem Text nach dem Bios). Diese Meldung kam noch nie von sich aus… Die Kunden haben gemeinsam das sie beide Asus Mainboards besitzen und das sie beide Windows 7 mit dem gestrigen Patch installiert haben…
Kurz sortiert: Es geht wohl um UEFI-Systeme mit ASUS Mainboards, die nach dem Patchday unter Windows 7 mit der Fehlermeldung "Secure Boot Violation" den Start des Systems abbrechen. Bei Computerbase gibt es diesen Thread zum Thema und dort ist die Meldung auch dokumentiert.
Anzeige
(Quelle: Computerbase)
Dort ist ein Mainboard ASRock Q1900M in Verwendung. Scheint also nicht auf ASUS Mainboards beschränkt zu sein. Recherchiert man weiter, findet man ältere Artikel (hier, hier oder hier), wo das Problem in anderem Kontext auftritt.
Update: Es kristallisiert sich heraus, dass sich das Problem auf Boards für Skylake-Prozessoren begrenzt.
Erklärung: Offenbar hat Microsoft am Patchday irgend etwas an den Boot-Dateien von Windows 7 geändert, so dass ein Secure UEFI-Boot wegen Signaturfehler nicht mehr möglich ist. So viel zum Thema: "Wir von Microsoft wissen, was für unsere Kunden gut ist" und der obligatorische Verweis auf Rüdiger Weiss, der über Secure Boot und TPM wettert, weil Microsoft es nicht im Griff hat (siehe Blog-Beitrag Warnung vor "Botnetz" Windows 10 …). Für alle Betroffenen, hat mir Blog-Leser Mathias L. folgendes mitgeteilt.
Mein Workaround ist das deaktivieren von secure boot und löschen dieser Keys im Bios… (siehe hierzu heise.de Hotline Secure Boot-FAQ, letzter Eintrag von "teneick vom 23.09.2015").
Der Nutzer teneick beschreibt, unter Asus H97M-Plus Board: Kein ausschalten von Secure Boot möglich wie man den Secure Boot durch Löschen der Secure Boot Keys den Secure Boot abschalten kann (siehe auch meinen Nachtrag unten). Vielleicht hilft es dem einen oder anderen Betroffenen aus der Patsche.
Danke an Mathias für den Hinweis. Da kommt doch richtig Freude auf und wir warten mit Aufregung auf den nächsten Patchday.
PS: Das Ganze ist etwas mysteriös – aber mit UEFI und Secure Boot-Updates gab es bereits im Sommer 2014 Ärger (siehe diesen heise.de-Beitrag). Ein etwas ähnliches Problem trat im März 2015 bei BIOS-Systemen auf, wo ein Patch für eine Boot-Schleife unter Windows 7 sorgte (siehe heise.de-Artikel) – wobei UEFI-Systeme nicht betroffen waren.
Update: So geht es bei ASUS-Boards
Ein kleines Problem ist wohl der Umstand, dass die UEFI-Einstellungen bei ASUS-Boards ausgegraut sind, man als Secure Boot nicht einfach deaktivieren kann. Gemäß diversen Kommentaren hier und bei computerbase.de gibt es zwei Workarounds:
- Man stellt im BIOS die Option "Windows UEFI Boot" auf "Other OS" um, so dass der Secure Boot deaktiviert hat.
- Oder man entfernt die betreffenden Secure Boot Keys aus dem BIOS (wie oben vorgeschlagen).
Um die Umstellung vorzunehmen, muss man in die Einstellseiten des ASUS BIOS gelangen. Hierzu drückt man direkt beim Starten des Systems die Funktionstaste F2 (ggf. mehrfach drücken). In der ersten BIOS-Einstellseite mit der Uhrzeit gibt es eine Option, um die Sprache von Englisch auf Deutsch umzustellen.
Dann ist unten rechts die Option "Advanced Mode" anzuwählen, so dass man die Seite mit den Auswahloptionen für die jeweiligen Funktionskategorien wie "Hauptmenü" oder "Boot" angezeigt bekommt.
- Wird die Kategorie "Boot" ausgewählt, lässt sich im nächsten Schritt zur Option "Secure-Boot" gehen.
- Anschließend ist in der Seite die "Schlüsselverwaltung" auszuwählen. In der Folgeseite wählt man "Schlüssel löschen" und betätigt dies.
Die Änderungen im BIOS lassen sich durch Drücken der Funktionstaste F10 speichern und die Einstellseite des BIOS wird wieder verlassen. Das System bootet nun.
Nachtrag: Bitlocker Update KB3133977 als Übeltäter?
In diesem Technet-Thread wird der im März 2016 ausgegebene Patch KB3133977 für Bitlocker als Ursache für Boot-Probleme genannt. Beim April-Patchday wurden aber nur die Meta-Informationen aktualisiert (siehe Patchday: Microsoft Updates vom 12. April 2016).
In diesem Forenthread aus 2007 wird der Fehler auch diskutiert. Dort gibt es neuere Einträge von März 2016 mit einer Erklärung, was das Update KB3133977 macht. Das Bitlocker-Update, welches einen Bug fixen soll, modifiziert die beiden Dateien:
Bootmgfw.efi
Bootmgr.efi
Die Dateien enthalten den UEFI Boot-Lader für Windows 7. Da sich diese beiden Dateien geändert haben, blockiert das ASUS UEFI den Windows 7-Start. Ein Nutzer berichtet, dass er das Problem durch ein BIOS-Update und abschalten des Secure Boot gelöst habe.
Ähnliche Artikel
Patchday: Microsoft Updates vom 12. April 2016'
Warnung vor "Botnetz" Windows 10 …
UEFI-BIOS-Bug verhindert Booten bei USB-Geräten
BIOS-Update für Intel Skylake-Bug von Asrock
Windows PE im UEFI- oder BIOS-Mode booten
Medion Akoya P6640 Notebook: BIOS/UEFI-Tipps
Windows 8: Aktivierungsfalle bei BIOS/UEFI-Updates
Anzeige
Windows 7 kennt doch grundsätzlich kein Secure Boot. Secure Boot muss für die Nutzung von Windows 7 grundsätzlich im UEFI Setup deaktiviert sein.
Wenn es vorher aus war (muss es ja), gibt es m.W. für ein Windows Update auch keine Möglichkeit, dieses zu aktivieren. Sehr seltsam…
Das ist höchst seltsam, da mindestens Windows 8 oder Linux mit signiertem Bootloader für Secure Boot vorausgesetzt wird.
Ja,
hier bei mir auf bisher 3 Win 7 Maschinen ca. 2-3 Stunden bis Windows Update die Updates "gefunden" und installiert hat. Der Updatedienst hatte aber die ganze Zeit über "Last" gemacht…
Vorher hatte ich diesbezüglich noch keine Probleme. Mal schauen wie es zukünftig weitergeht.
Bei 2 PCs (Win7) lief alles ordnungsgemäß und habe die Updates auch alle installiert. Fazit keine Probleme bisher und in Benutzung.
Bei einem dritten PC (Win7) Notebook Toshiba hatte ich am Dienstag Abend keine Lust mehr, weil ich am Nachmittag alles Vorangegangene erst einmal aktualisieren wollte. Die Updatesuche am Mittwoch dauerte dann mächtig lange, ca. 1,5 h. Nach Installation keine Probleme.
Hinsichtlich der langen Updatesuche vermute ich nach wie vor, dass es ab 18 Uhr MEZ bzw. jetzt 19 Uhr MESZ weltweit bzw. regional dann etwas dauert und bis alle dann aufwachen, dauert es schon mal bis zu einem Tag danach. Aber 1,5 h hatte ich auch noch nicht.
Habe gestern nach 22.00 Uhr versucht Updates (Win7) zu suchen. Dauerte ca. 60 Min. bis die Anzahl der Files angezeigt wurden.
Am heutigen Tage vergingen 30 Min. für die Downloads.
Nach der Installation war meine Bluetooth-Mouse am Ende. Konnte die Bluetooth-Funktion aber wieder neu einrichten.
Fazit: Die Microsoft-Server sind derzeit stark überlastet!
Achtung: nicht gleich eine fehlerhafte Update-Funktion vermuten!
Abschließend meinen herzlichen Dank an Herrn Born, denn seine Tipps sind absolut TOP.
Dem kann ich mich nur anschließen. Ihr Blog, lieber Herr Born, ist einfach toll und Ihre damit verbundene Mühe und investierte Zeit einfach immer wieder lobenswert.
@RV:
Ich hoffe, Du hast Recht mit Deiner Aussage in Bezug auf die überlasteten Server, und die Suche nach den Updates dauert künftig nicht immer so lange. Ich hatte die Suche am Mittwochnachmittag gestartet, und erst nach über einer Stunde wurden Updates gefunden.
Es kann aber doch auch nicht richtig sein, dass MS seine Kunden nach meiner Vermutung auf diese Weise schikaniert, damit sie letztlich doch auf Windows 10 umsteigen. Ist ja schon schlimm genug, dass die einem ständig irgendwelche Updates aufdrängen wollen, die sich auf Windows 10 beziehen. So langsam reicht es…
Allgemeine Frage:
Bezieht sich das mit der Secure Boot Violation bzw. das damit verbundene Problem ausschließlich auf ASUS-Geräte, oder muss man als Windows-Nutzer jetzt tatsächlich bei jedem Gerät mit dieser schlimmen Meldung rechnen? Finde es mehr als traurig, dass MS neuerdings immer häufiger fehlerhafte Patches heraus gibt – ohne auch nur ansatzweise darüber nachzudenken, was das für den einzelnen Nutzer bedeutet. Nicht Jeder hat das Geld, jeden Monat einen Fachmann kommen zu lassen oder das nötige Know-How, um die Probleme selbst zu lösen. Es nervt einfach nur noch…
Allgemeine Antwort: Ich vermute, wenn PC startet dann kein Problem also kein Problem. Ich weiß nicht warum man immer nach dem sog. Dienstag im Monat einen Fachmann kommen lassen muss. Ich bin selbstständig und habe HP-PCs. Jedenfalls bei Win-7-Geräten alles o.k.
Naja, das mit dem Fachmann war auch eher ironisch gemeint. Fakt ist aber, dass MS seit einiger Zeit immer und immer wieder (anscheinend auch auf Windows 10) fehlerhafte Patches heraus gibt. Und in der Tat musste ich in der Vergangenheit wegen zwei durch solche Patches verursachte Probleme (Bluescreen etc.) einen Fachmann kommen lassen.
Früher kam das mit den fehlerhaften Patches meines Wissens nach so gut wie nie vor. Inzwischen muss man ja schon regelrecht zittern, wenn etwas Neues heraus kommt, weil MS die Patches scheinbar nicht gründlich genug testet, und das finde ich einfach ärgerlich und zugleich enttäuschend.
Stand im Text – es sind ASUS und MSI-Boards aufgefallen
Eigentlich steht im Text bisher nur was von ASUS. ;-)
Ich nehme nicht an, dass es ein fehlerhafter Patch war. Ich könnte mir eher vorstellen, dass das UEFI von ASUS einen Fehler hat. Schließlich aktiviert es von selber Funktionen, die vorher deaktiviert waren.
Dann habe ich Tomaten oder ähnliche auf den Hühneraugen oder so.
Ich z.B. habe Null Ahnung, was ich mit dieser Fehlermeldung anfange und kann leider kein Englisch. Bin mit dem Tablett auf Suche nach Hilfe, weil mein Computerverkäufer heute nicht zu erreichen ist, ich aber dringend Aufträge erledigen sollte. Oh , menno alles böhmische Dörfer für mich *verzeifelt* Gruß Claudia
Da werden wir dir eher nicht helfen können, da man am Tablet eher keine Tastatur hat (oder ist es ein Convertible mit anclippbarer Tastatur?).
Zudem signalisiert mir "Tablet", dass da weniger Windows 7 sondern eher Windows 8, Windows 8.1 oder Windows 10 installiert ist – oder irre ich mich?
Zur Vorgehensweise: Man muss ins BIOS/UEFI und versuchen, die hier im Blog-Beitrag sowie in den Kommentaren skizzierten Einstellungen abzuschalten. Da das aber von Maschine zu Maschine unterschiedlich ist, wird ein Fachmann ran müssen.
Es sei denn, Du lieferst hier ein paar Details zum Gerät (Typ, Windows-Version etc.) und ein Blog-Leser kennt zufällig die Schritte zum Deaktivieren des Secure Boot.
Sie sucht mit dem Tablet nur nach einer Lösung, hat das Problem aber auf ihrem Windows 7 Desktop oder Laptop. Jetzt verstanden?!?
Ok, aber die obigen Hinweise sind das Beste, was ich liefern kann – und der Nachtrag zur Vorgehensweise ist mittlerweile in deutsch. Vielleicht hilft es.
Vielen lieben Dank! :-)
Aufgrund regelmäßigen Ärgers mit den Updates in letzter Zeit ("Black Wednesday Morning") habe ich nicht alle, sondern "erstmal" nur das MRT und die zwei Framework Updates runtergeladen.
Das ging noch ohne Probleme und Fehlermeldung.
Aber danach geht updatemäßig nichts mehr.
Beim Versuch ein weiteres Update aus der Liste zu laden passiert nichts (0%…).
Dafür rattert svchost.exe mit 25-100% Auslastung, bis die Kiste heißläuft.
Das gleiche, wenn ich die Updatesuche neu anstosse.
In beiden Fällen wird im Taskmanager nicht der Hauch einer Netzwerkaktivität angezeigt! Internetzugriff ansich ist aber vorhanden.
Vielleicht liegt's ja wirklich an der Gegenseite (Updateserver)…
Werde es noch ein paar Tage abwarten…
Das ist ein bekanntes Ereignis, welches immer dann auftritt, wenn am .netFramework Veränderungen stattfanden. Kurz gesagt: ein Compiler läuft im Hintergrund und anschließend ein Optimierungsdienst.
Quelle: https://blogs.msdn.microsoft.com/davidnotario/2005/04/27/what-is-mscorsvw-exe-and-why-is-it-eating-up-my-cpu-what-is-this-new-clr-optimization-service/
Hatte das selbe Problem und habe Windows 7.. Bei mir wurde im Bios Menü Secure Boot angezeigt, konnte es aber nicht deaktiviern musste den Schlüssel löschen und jetzt geht es wieder..
Zum Glück hab ich den Blog hier gefunden, vielen Dank :)
Danke für die Rückmeldung
also ich hab die Updates am 12. April unter Windows 7 64bit Ultimate auf einem ASUS A88XM-E Socket FM2+ Mainboard mit UEFI/BIOS, Secure Boot ist natürlich deaktiviert Installiert, ging ohne Probleme!
Ich würde Theoretisch auch auf Windows 10 Upgraden, ich hab mit Windows 10 kein Problem, aber erstens habe ich momentan keine Zeit mich darum zu kümmern und zweitens steckt in dem PC eine Terratec S2 TV Karte für die es glaube ich keine Treiber für Win10 gibt und dann fängt die ganze Scheiße wieder an was vernünftiges dafür zu finden.
Ich habe ein ASUS H97 plus-Mainboard. Im UEFI war "Secure boot" aktiviert und ausgegraut, so dass ich es nicht deaktivieren konnte. Als Betriebssystem war "Windows-UEFI" eingestellt. Das habe ich auf "Other OS" geändert. Jetzt geht's wieder. Warum das so ist, finde ich vielleicht auch noch raus…
Hallo Webun!! Du hast meinen Computer gerettet! Danke!!! Ich war am Verzweifeln… Wie jeder von uns glaub ich… Aber bei mir hat das funktioniert und ich bin sowas von happy!!!
An dieser Stelle möchte ich auch mal mein Anwendererlebnis mit diesem Patchday schildern (Win 7 prof – 64 bit).
Die Suche nach Updates dauerte etwa 45 min. bei 25 % CPU-load und einem guten GB zusätzlichem RAM-Verbrauch.
Download und Installation liefen sauber durch (etwa 10 min.).
Dann Neustart eingeleitet und bis zum Bildschirm 'Konfigurieren von Windows wird vorbereitet – Schalten Sie den Computer nicht aus' gekommen.
Diesen Bildschirm sehe ich für gewöhnlich nur wenige Sekunden. Diesmal nicht.
Nach einer guten Stunde hab' ich den Rechner dann abgeschossen und zurückgesetzt.
Also auf ein Neues.
Diesmal hab' ich vorher KB3102810 installiert. Ergebnis: Keine Veränderung bei der Suche (wieder ~45 min.).
Nachdem der Download nach etwa einer Stunde immer noch bei 0 % stand, hab ich erstmal abgebrochen.
Etwas später lief dann alles sauber durch und ich bemerke bis jetzt keine Nachwehen.
Halber Tag vorbei – Rechner gepatcht – Yes.
Dazu kommt noch, daß man jedes Update nach 'Win 10-Spuren' durchsuchen muß, wenn man sein Win 7 ohne Nerverei benutzen möchte – Ein Ärgernis.
Diesen "UEFI-Kram" kann man bereits beim Booten der Installations-DVD ausgewählt haben. Die Auswahl "UEFI" erscheint, wenn ein Datenträger (DVD oder USB-Stick) UEFI-fähig ist. Ich habe das bei meinem Asus Board aus 2011 (1. EFI-Generation ohne Secure Boot) und Asrock von 2014 (mit Secure Boot) beobachtet. Wenn man eine UEFI-Installation vorliegen hat, ist der Windows Bootmanager im UEFI aufgeführt.
Bei mir hat es gestern knapp 4 Stunden gedauert bis mein Win7 die ganzen Updates gefunden hatte. Das Herunterladen und Installieren ging dann aber schnell und war innerhalb von knapp 10 Minuten erledigt.
P.S. Danke für diese wirklich informative Seite hier! Ich bin jeden Tag mindestens einmal hier um die neuesten Infos zu erfahren.
Diese Sache mit Secure Boot Violation hat mich schon ziemlich erschreckt, ließ sich aber (und darüber bin ich heilfroh!!) Einfach lösen, indem ich im BIOS die secure-boot Keys gelöscht habe… Danke für die Hilfe! !
Seit dem Microsoft-Patchday (2016-04-12/12.04.2016) und dem Ausrollen bei mir am 2016-04-13 und 2016-04-14 habe ich das Problem auf zwei baugleichen PCs:
Mainboard: Asus H87-Pro (neueste Firmware 2104)
CPU: i5-4670 (Haswell)
Betriebssystem: Windows 7 pro 64 sp1 (alle Patches automatisiert eingespielt)
Windows startet nur noch, wenn im UEFI/BIOS Secure Boot abgeschaltet wird. Im UEFI/BIOS ist statt "Windows UEFI Mode" nun "Other OS" auszuwählen.
Ich war bislang der Meinung, dass Windows 7 pro 64 mit den entsprechenden Updates UEFI/Secure Boot beherrscht. Wenn man den Foreneinträgen Glauben schenkt, ist das aber wohl auch witerhin nicht der Fall.
Die Mainboard-Hersteller wie Asus liefern aber wohl alle Boards zwischenzeitlich mit der Grundeinstellung UEFI/Secure Boot AKTIV aus, und da in den letzten drei Jahren mit dieser Einstellung alles funktioniert hat, habe ich die Einstellung halt belassen.
Es wäre schon interessant zu erfahren, was Microsoft jetzt am 2016-04-12 genau geändert hat. Die Windows-7-Systemwiederherstellung auf einen Zeitpunkt vor den 2016-04-12 zu stellen, hat bei mir nichts geändert, nur die geänderte UEFI/BIOS-Einstellung hilft.
An den (Asus) UEFI-Secure-Boot-Schlüsseln/PK/KEK werde ich ohne nähere Auseinandersetzung (Rücksprache mit dem Hersteller Asus) mit dem Thema erst einmal nichts ändern.
Vielleicht kann hier jemand die Aussage: "Unter Windows 7 64 generell kein UEFI/Secure Boot möglich" bestätigen oder entkräften?
Schönen guten Abend,
ich benutze W7 auf Asus H87-Pro. Seit dem Patchday startet Windows nicht mehr,
es wird jedes Mal auf die Bios-Pflege-Anzeige verzweigt. Eine Boot-Secure-Violation wird nicht angezeigt, aber beim ersten Mal kam die Meldung: "No Operating System Found" – aber nur ein Mal.
Spiele ich von einem Notfall-Stick eine älter Windows-Version vom Januar ein,
läuft alles prima. Spiele ich das Patch wieder auf geht wieder nichts mehr.
Macht es Sinn, den hier vorgeschlagenen Workaround zu versuchen oder geht dann evtl. nichts mehr ? (Jetzt läuft wenigstens der Rechner auf dem alten Stand – Updates habe ich erstmal komplett abgeschaltet).
P.S.: Manuelle Downloads haben bei mir mit langem Warten geklappt – den April-Patch habe ich zwar komplett abgewählt aber MS hat mir den "Stinkefinger" gezeigt und wieder alles installiert – wieder ging nichts mehr
beste Grüsse
H.-J.
Wenn ich die Forenkommentare bei heise.de so richtig interpretiere, sollte das Löschen der Secure Boot-Keys helfen und ließe sich rückgängig machen. Aber ich habe kein solches Board und für nichts garantieren. Ich würde "Other OS" als Option versuchen.
Hallo Günter o Martha,
die oben vorgeschlagene Änderung funktioniert (statt „Windows UEFI Mode" nun „Other OS"), auch wenn es bei mir keine Secure Boot Violation -Meldung gab.
Wichtig war aber dann die Boot-Reihenfolge richtig zu wählen.
Bei mir kam erst wieder mal die Meldung "No Operating System". Meine SSD mit dem OS wird von ASUS bei der Auswahl 2x unter verschiedenen Bezeichnungen angezeigt….(warum auch immer)
Besten Dank
H.-J.
Zur möglichen Ursache: Beachtet meinen Nachtrag im obigen Text.
Ich hatte ein ähnliches Phänomen, nachdem Windows 7 Updates installiert hatte:
Windows bootete nicht mehr, Bluescreen (eher wenig aussagekräftig).
Kein UEFI BIOS, betraf in mehreren Fällen Gigabyte-Boards mit Skylake Prozessoren.
Lösung: TPM-Support im BIOS deaktivieren, danach bootet Windows wieder problemlos.
Hi,
nur zur Info: es ist defintiv nicht nur auf Intel Skylake Systeme beschränkt. Siehe
http://www.planet3dnow.de/cms/23097-uefi-boot-probleme-nach-windows-7-update-auch-bei-amd-systemen/
Manchmal frage ich mich, wie viel Geld die Patch-QA von MS so von der Konkurrenz bekommt, um all die User zum Wechsel zu bewegen… (8->)…
Steht ja schon in der c't –> Weg von WIN10… (;->)…
Ich bin mit WIN ab 1.0 groß geworden und habe die leidvolle Umstellung von 80% produktiv arbeiten zu 80++% Scheiße schippen mit gemacht.
Das es sich nun aber so langsam Richtung 100% bewegt, ist bald nicht mehr erträglich!
…weder für meine Kunden, die das alles nicht mehr bezahlen wollen und können und auch für mich, der von den ganzen Problemen beim Kunden kaum noch zum richtigen Arbeiten und weiter entwickeln der Netzwerke kommt.
Schreibt man MS oder deren intimste Jünger mal auf QA-Enhancements an, kommt nur die dröge Antwort, man muss halt alle Patches testen, bevor man sie auf die Produktiv-Systeme los lässt.
DAS machen die Kunden aber nicht mehr mit!
Ich müsste glatt einen neuem MA einstellen für diese Patch-Test und dann finaly-patch-it Orgie!
NUR wer bezahlt's?!
MS –> Wenn ihr keine QA mehr könnt, nachdem ihr zu viele hochpreisige, also wohl GUTE Techniker raus geschmissen habt, solltet ihr vielleicht mal ein paar kompetente Herrschaften dafür einstellen, oder die geschassten MA nun eben als sehr viel teurere externe beschäftigen, bevor man euch GERNE und zügig den Rücken zu wendet!
…wer das bezahlen soll –> Der Spitzen-MA, der sich gerne mal über die Frauen und deren leistungsgerechte Bezahlung aus lässt und das dann nur noch mit GUTEN Zahlen durch massive Einsparungen kompensieren kann, um nicht selber geschasst zu werden –> Kann da mal einer HALT rufen und für kompetente Geschäftsführung sorgen, bevor der Kollateralschaden zu groß wird?!?!?!