Perfekt!

Irgendwie ist dieser Thread hier zu einem "Schice IT-Thread" vergammelt.

Diese Tradition möchte ich heute mit einem kleinen Beitrag weiterführen.

Was mir in letzter Zeit häufiger unterkommt, ist die Installation von Windows 11 auf älteren Geräten, die teilweise so alt sind, dass sie ganze 2 (zwei!) Jahre unter Windows 10 überstanden haben.

Der Support für Windows 10 läuft aber jetzt im Oktober 2025 aus - und so ist zu überlegen, wie man auf Windows 11 umsteigt: Neuinstallation oder Neuanschaffung.

Ich bin ein Freund davon, brauchbare Hardware solange zu brauchen, bis man sie trotz kleinerer Aufrüstung wirklich nicht mehr brauchen kann.

So etwa die HP-Minidinger hier mit einem 12 Jahre alten i3-Prozessor. Kostet 60 Euro in der Anschaffung. Wer WILL, kann ein vorhandenes Gerät für gut 30 Euro von 4 auf 8 GB RAM aufrüsten, die Wärmeleitpaste neu machen und das Ding unter Windows 11 als Terminalserver-Client laufen lassen.

Geht super!

Und kommt auch unserer Umwelt zugute. Wenn man nur will. Und sich traut. Und die Arbeit an so einer alten Kiste bezahlen will. Ein defekter Lüfter wird wirtschaftlicher Totalschaden.

Ich weiß, dass hier auch Admins unterwegs sind, die sich mit Uhren von der IT ablenken wollen. Vielleicht hilft das Folgende ja hier und dort.

Bei einigen Geräten kommt es vor, dass im Setup-Vorgang keine Datenträger ermittelt werden können. Üblicherweise passiert das nur, wenn das Gerät wesentlich neuer ist, als das Setup-Image.

Das ist bekannt.

Mittlerweile hat man aber offenbar gerne eine Technik verbaut, die Xeon-Prozessore nutzen können, also Prozessore, die in Servern genutzt werden, weniger in Desktop-Rechnern oder Notebooks.

Wenn also im Setup keine Laufwerke gefunden werden, ist der erste Weg, im BIOS nach "VMD" zu suchen und diese Option zu deaktivieren. Dann werden auch wieder Laufwerke angezeigt. Sonst ist der übliche Weg die fehlenden Treiber zu suchen, die dann halt noch fehlen.

Ein weiteres Schmankerl boten mir Lenovo Notebooks, hier der Typ T470S - ein wirklich schnuckeliges Ding! Echt jetzt!

Mit der Installation von Windows 11 war es allerdings über seine Tastatur/Touchpad-Kombi nicht mehr bedienbar...

... aber auch nicht immer (nicht). Per USB angeschlossene Geräte funktionierten jedenfalls immer.

"Herunterfahren" und "Neu starten" verhalten sich unterschiedlich. Nach einem "neuen Start" ("Herunterfahren" und neu Einschalten) war keine Tastatureingabe möglich, nach einem "Neustart" hingegen schon!

Alleine DAS herauszufinden...

Wenn ich Euch jetzt erzähle, dass ich Windows 11 zur Fehlerbehebung als Upgrade aus Windows 10 installieren wollte... und dazu einen Widerherstellungs-Datenträger von Lenovo downloaden wollte... um halt alle Treiber schon mal beisammen zu haben... wozu ein Lenovo-Kundenkonto errichtet werden muss... wozu ich mein Kleinschmiede-Google-Konto verwendete... ohne aber den Download zu erhalten, weil das Notebook bei Lenovo aus der Pflege geflogen ist... aber wichtig ist: Erst das Konto erstellen, dann Daten sammeln und DANN dem Kunden sagen, dass er auf dem falschen Weg ist...

Jetzt schaut Lenovo halt Kleinschmiede-Videos...

OK...

Die Lösung des Tastatur-Problems am T470S (und sicher auch bei weiteren Modellen) war:

- in Windows 11
- CMD als Admin öffnen
- eintippen und mit [Enter] bestätigen:

powercfg /h off

Warum auch immer.

Jedenfalls deaktiviert dieser Befehl den Ruhezustand. /h steht hier für "Hibernation", "Tief-" oder "Winterschlaf". Gleichzeitig wird Plattenplatz in RAM-Höhe freigegeben, der vorher für den Ruhezustand reserviert wurde (eine Datei, in die der Inhalt des Arbeitsspeichers geschrieben wurde, wenn die Kiste in den Ruhezustand gehen sollte). Was auch nett sein kann.

Bestimmt 20 Starts (auf welche Weise auch immer) weiter kann ich tatsächlich recht sicher sein:

Das war die Lösung für das Tastaturproblem am Lenovo! Sogar die Funktionstasten funktionieren. Ist das nicht schön? Ist das nicht wunderwunderschön? Lauter, leiser, heller, dunkler... alles per Tastendruck - und sogar nach einem Neustart! Oder nachdem das Ding neu gestartet wurde!

Wie auch immer.

Locker über acht Stunden Sucherei, damit eine Tastatur funktioniert? Oder damit ein Betriebssystem installiert werden kann? Weil Ihr Blödstudierten Technik eingeschaltet habt, die gar nicht eingebaut ist?

Wer bezahlt dafür? Wer gibt mir für diesen Blödsinn meine Lebenszeit zurück?

Und wenn hier jetzt einer aus der Linux-Fraktion aufmuckt... dass das alles ja so einfach und sooo sicher ist...

... NUR EINER!

Noch ein Schmankerl gefällig? Echt jetzt?

OK.

Stellt Euch einen Kunden vor, der eine Telefonzentrale für seine Kunden und seine Fahrer draußen betreibt. 30 Fahrzeuge im 24-Stunden-Betrieb macht 90 Mitarbeiter, die in drei Schichten benötigt werden. Nebenjobber, Urlauber, Krankheits-Ausfälle... gut 300 Kollegen stehen auf der Payroll mit den Jungs und Mädels aus der Werkstatt, der Verwaltung, der Telefonzentrale... und so...

Dieser Kunde wollte eine neue Telefonanlage, die dann auch mit einer neu anzuschaffenden Software zusammenarbeiten soll, sodass ein Mitarbeiter aus dieser Software heraus Anrufe einleiten kann und andererseits in dieser Software auch sieht, wer gerade anruft. Vielleicht sogar Zugriff auf Verläufe bekommt. Und dass eventuell gleich erkennbar wird, ob die Rechnungen gerne bezahlt werden. Oder so. Kann ja mal ganz interessant sein, wenn Transport das Hautpgeschäft ist.

Das Ganze gespickt mit einer Warteschleife, mit Gruppen und mit Teilnehmern, die sich lustig in die Gruppe integrieren können oder auch nicht. Etc.

Und wenn eben jenes "etc." die Chefin persönlich beschreibt, die sich gerne mal... hin und wieder... wie es ihr Tag so zulässt... selbst in die Gruppe einschalten möchte... um die Zentrale zu entlasten... aus ihrem Büro selbstverständlich... weil es ihr in der Zentrale zu wuselig ist...

Die Wahl fiel auf eine Lösung, die auf einem Server virtualisiert werden sollte. "Schwuppdiwupp" war alles installiert und eingerichtet, die Anlage lief, die Nutzer waren begeistert von den Möglichkeiten und der Geschwindigkeit, wie so alles funktioniert und ineinander greift.

Gleichzeitig haben wir sie verwöhnt: Jeder Mitarbeiter hat sein eigenes Headset und braucht seinen Ohrenschmalz nicht mehr mit dem Kollegen teilen! Und das macht mal möglich, wenn sich gut 20 Mitarbeiter in wechselnden Schichten fünf Telefone teilen... eine spannende Aufgabe: Bindet doch mal 20 Headsets an fünf Telefone an, wenn die Mitarbeiter mal hier und mal dort arbeiten wollen!

Na? Problem erkannt, oder?

Chefin nicht vergessen!

Und die Jungs und Mädels aus der Werkstatt und von der Tankstelle nicht vergessen, die mit ihren mobilen Endgeräten auf dem ganzen Campus telefonieren wollen...

Aber hin und wieder... ja: Hin und wieder schmierte diese Anlage einfach ab. Kein Anruf rein, kein Anruf raus, laufende Gespräche wurden unterbrochen.

Nicht immer! Aber hin und wieder mal. So zwei Mal pro Woche. Gefühlt. Manchmal aber auch nicht.

Nach fünf Minuten war der ganze Spuk wieder vorbei und alles lief, wie gewollt.

Wir haben alles geprüft! ALLES! Jedes einzelne Kabel, jeden Switch, jeden Unterverteiler, jeden Medienkonverter zwischen den Gebäuden (LWL auf Kupfer und umgekehrt), jeden WLAN-AccessPoint, jede Video-Kamera, jeden Rechner, sogar die Heizung, den Bremsenprüfstand und die Tankstelle, ob irgendwer Blödsinn im Netzwerk macht... wir haben mit den Providern gesprochen... haben auf die Logfiles geschaut... haben an dem Standort auch zwei Provider, falls mal einer ausfallen sollte... und ein Backup über 3G... oder ist's 4G? Haben die Firewalls geprüft... und neu eingerichtet... und so...

Was man halt so macht, als gestandener Admin, oder? OSI von unten nach oben halt: Von Layer 0 bis Layer 8, vom Medium bis zum... naja... wer ihn kennt, der kennt ihn halt, den DAU.

Und wir haben auch so einiges gefunden! So ist es ja nicht!

Wenn kein User in der Gruppe angemeldet ist, klingelt's auch nirgendwo. Nur so als Beispiel. 50km Landstraße brauchen aber auch eine Stunde.

Und wenn der Kollege in der Nachtschicht hingeht, und alle Telefone auf lautlos stellt, klingelt es am Morgen auch nicht. Da muss man schon mal auf den Bildschirm schauen, ob wer angerufen hat.

Randerscheinungen halt. Aber: erhellende! Unglaublich, worauf User von alleine kommen... und was die von alleine können... und machen...

Aber das Problem blieb: Hin und wieder flog die Anlage weg: nicht immer! Aber hin und wieder mal. So zwei Mal pro Woche. Gefühlt. Manchmal aber auch nicht.

Wir hatten mal wieder Fernwartung. Und innerhalb dieser Fernwartung eine irrsinnige Sitzung: Mitten in der Nacht, Kollege und ich gleichzeitig von verschiedenen Standorten aus per VPN auf dem Netzwerk des Kunden, Festnetz-Telefone am Ohr, mit unseren Handys leiteten wir Rufe ein, nutzten noch unsere Softphones am Rechner für Parallelrufe gleichzeitig dazu, schauten dabei beide in die Ereignisprotokolle... was Netzwerktechnik so alles verkraftet...

Unglaublich.

Dann... irgendwann mitten in unserer Fernwartung... da flog die Anlage weg!

Was war passiert?

Der Kollege hat ein recht günstiges Handy. Und hat mit diesem Handy beim Kunden angerufen. Und: Zack! War die Anlage weg!

Der Witz:

Da mein Kollege (in der Fernwartung per VPN, mit Headset auf dem Kopf zum Gespräch mit mir, während die Softphones auf den Rechnern liefen...) das Handy vor sich liegen hatte... und das Ding auf Außenlautsprecher stand... damit wir beide über unsere Festnetz-Verbindungen mithören konnten... ob denn nun eine Verbindung... und wie viele gleichzeitig... ob nun rein oder raus... oder so...

... gab sein Handy MTF-Wähltöne von sich... die durch unsere Headsets und über die Festnetz-Verbindung in die Anlage kamen... wahlweise über die Softphones... keinesfalls jedoch über das VPN... und zum Absturz führten!

Das konnten wir mehrfach hintereinander darstellen!

Und damit auch den Fehler:

Jedes Mal...

... wenn ein Mitarbeiter in der Zentrale gerade im Gespräch war...

... und das Faxgerät dort ein Fax zu einem Kunden schicken sollte...

... und eben dieses Faxgerät dazu die MTF-Wähltöne von sich gab (allerdings ziemlich leise...)

... schmierte die Anlage ab!

... weil ja jetzt diese MTF-Töne aus dem Fax über die Headsets der Mitarbeiter in die Anlage gelangten!

Hihi.

Mit diesem Ergebnis betrafen wir den Hersteller.

Nach einigem Hin und Her gab es den Tipp: "Nehmt mal 'Secure Boot' aus der VM-Konfig raus und startet die Anlage neu!"

Und das war's dann auch wirklich.

Wie viele Zufälle waren nötig, um diesem Fehler auf die Spur zu kommen?

Wenn dieses billige Handy jetzt nicht diese Asbach-Uralten MTF-Töne von sich gegeben hätte... im Freisprech-Modus... aus lauter Frust von zwei Admins... mitten in der Nacht... in einer völlig verkappten Netzwerk-Situation...

... dann wäre die komplette Anlage vielleicht durch eine Freeware eines anderen Herstellers ersetzt worden...

... wo die Oberfläche nicht so hübsch ist...

... aber wo die Anlage funktioniert. Einfach so.

Noch mal der Hinweis an die Linuxer: Die Anlage basiert auf Linux, wie andere auch. Asterisk ist hier das Suchwort der Wahl. Aber das klappt ja alles immer so einfach und so sicher...

Wer von Euch Admins da draußen eines dieser Problemchen hat... ich hoffe, vielleicht eine Lösung angeboten zu haben.

Von der gesparten Zeit könnt Ihr Kleinschmiede-Videos gucken gehen... viel Spaß dabei!

Ah: Der BOFH!

Ein Klassiker!

Meine letzte Nacht und mal wieder so ein Ding aus der Gruselecke:

Die Remotedesktop-Verbindung fliegt nach 10...15 Sekunden weg. Jedes Mal.

Ganz kurz zur Remotedesktop- ("früher": Terminalserver-) Geschichte: Ein leistungsstarker Server wird irgendwo hingestellt. Auf ihm werden alle nötigen Büro-Anwendungen eines Unternehmens installiert (CAD, Video- und Bildbearbeitung etc. sind hier nur bedingt geeignet - es geht aber mit etwas Aufwand!).

Die Benutzer melden sich auf diesem Server an und bekommen von ihm einen Bildschirm angezeigt, als säßen sie selbst davor. Nun können sie ihre Anwendungen starten: Word, Excel, Outlook... Unternehmenssoftware wie Buchhaltung und Lohnbuchführung, Lagerverwaltung, Transportmanagement etc. Was man halt so braucht.

Der Witz ist, dass dieses ganze Geraffel nur auf dem Server installiert werden muss, nicht auf allen einzelnen Rechnern. So ist eine Installation gleich für alle nutzbar, ein installiertes Update ebenfalls. Alles muss nur ein Mal gemacht werden. Je nach Software können 20...40 Nutzer gleichzeitig auf so einem Server arbeiten, der Server kümmert sich darum, dass jede Anwendung für jeden Benutzer getrennt ausgeführt wird. Wenn's dann doch zu wild wird, stellt man weitere Server in einen "Forest", sodass aufkommende Last automatisch verteilt wird und auch ein Ausfall eines Servers keinen großen Einfluss hat.

Abgesehen von der verschlankten Administration gibt es weitere Vorteile: RDP-Server werden gerne genutzt, um Home-Offices einzurichten oder um über ganze Standorte hinweg eine einheitliche Umgebung für alle Mitarbeiter zu stellen. Auch darf dann mal ein Notebook gestohlen werden, ohne gleich einen Daten-Diebstahl zu befürchten, wenn dieser Dienst konsequent genutzt wird. Auf denn Endgeräten ist halt nichts drauf, außer der Verbindung ins Unternehmen und das Progrämmchen, um sich das Bild vom Server anzeigen zu lassen. Somit dürfen die Arbeitsplatzrechner auch gerne urmelalt sein, da sie keine schweren Programme ausführen müssen.

Ein kleines Progrämmchen wird vom Arbeitsplatz aus dazu genutzt: MSTSC. Ist quasi auf jedem Windows-Rechner vorinstalliert. Namen bzw. IP-Adresse des Servers eingeben, Benutzernamen und Passwort hinterher... und auf geht die wilde Fahrt.

Jetzt gab es das Phänomen, dass die RDP-Sitzung an einem Rechner nach 10...15 Sekunden abbrach. Immer wieder.

Und die Fehlersuche begann. In den Ereignisprotokollen gab es Hinweise auf einen Absturz von MSTSC in Verbindung mit NTDLL.DLL, einer üblen Systemdatei.

Die üblichen Reparaturversuche in Verbindung mit der ntdll.dll folgten ohne Besserung.

Komischerweise lief die Verbindung unter einem anderen Nutzer auf dem gleichen Rechner störungsfrei, was auf ein Problem mit dem Nutzerprofil, nicht jedoch auf einen Systemfehler an sich hinwies. Auf die Idee muss man auch erst mal kommen... also... es auf dem gleichen Rechner unter einem anderen Nutzer zu probieren... weil: MSTSC kann quasi nichts! Das ist keine komplexe, schwierig zu installierende Anwendung! Vom IQ her irgendwo bei MS-Paint anzusiedeln... und vom Alter her ebenso... gab's schon unter NT4... da gab's sogar einen eigenen Server für... das war 1998...

Internet-Recherche folgte. Mit Hinweisen in sämtliche Richtungen.

Acht Stunden später dann: Es war der Druckertreiber! Ich bin halt nicht so schnell.

Der am Arbeitsplatz installierte Drucker wird in der RDP-Sitzung genutzt, damit Dokumente auch in Nähe des Nutzers ausgedruckt werden können - was Sinn macht!

Was aus meiner Sicht aber keinen Sinn macht: Der Druckertreiber wird im System installiert, nicht gesondert für den Nutzer. Warum nun der eine Nutzer fuktionierte und der andere nicht... keine Ahnung!

Mal wieder nicht. Irgendwas wird sich da zerschossen haben. Aber nur für diesen Nutzer. Heißt ja nicht umsonst "Personal-Computer", oder?

Und da wundern sich die Leute, warum mich morgens um acht niemand anrufen braucht...