Good bye Windows XP!

Am 25. Oktober 2001 begann eine lange Ära. An dem Tag wurde Windows XP offiziell released. Damals dominierten noch Windows 2000 und Windows 9x (95/98/ME) den heimischen PC-Markt. Natürlich wurde das neue Betriebssystem aus Redmond von vielen noch kritisch beäugt. Viel zu bunt. Und es wurde auch geunkt, dass die Treiberunterstützung nicht umfangreich genug sei, obwohl es im Vergleich zu Windows 2000 eine deutliche Verbesserung gab und die meisten Hersteller zumindest für die Topseller ihrer Hardware Treiber für Windows XP im Vorfeld entwickelt haben.

Natürlich gab es zu Anfang noch Kinderkrankheiten bei XP, die größtenteils mit dem ServicePack 1, ungefähr ein dreiviertel Jahr später am 30. August 2002, behoben wurden. Im Februar 2003 folgte dann die Neuauflage des SP1 als ServicePack 1a, welches im Großen und Ganzen jedoch nur Sicherheitspatches und Hotfixes beinhaltete. Richtig gut und für die breite Masse sinnvoller wurde XP mit dem ServicePack 2, welches am 9. August 2004 veröffentlicht wurde und die in Windows integrierte Firewall standardmäßig aktivierte. Das war auch bitte nötig, da es zu der Zeit ausreichte, ein Windows XP nur für wenige Sekunden an das Internet anzuschließen, um es mit Viren zu infizieren. Die Firewall trug dazu bei, dass Windows erstmals einen für Ottonormalbenutzer brauchbaren hauseigenen Schutz mitbrachte und das System relativ sicher machte. Neben der Firewall wurden noch weitere Sicherheitsmerkmale zu XP hinzugefügt, wie die DEP (Data Execution Prevention = Datenausführungsverhinderung), die verhindern sollte, dass schadhafter Code sich im System einnisten kann. Mit der Zeit war aber klar, dass auch solche Mechanismen nur eine grundlegende Sicherheit bieten und man dennoch auf die Verwendung von Anti-Virus-Software angewiesen war, zumal natürlich auch die Entwickler von Schadsoftware mit der Zeit gingen und die neuen Sicherheitsmerkmale von XP relativ schnell umgangen werden konnten. Es war trotzdem ein richtiger Schritt. Am 21. April 2008 wurde das 3. und letzte ServicePack für Windows XP veröffentlicht. Über Windows Update stand es aufgrund einiger Probleme jedoch erst am 6. Mai zur Verfügung.

Bis heute war XP das erfolgreichste Windows aller Zeiten. Der Nachfolger Windows Vista war aus guten Gründen ein Flop. Ich habe es selbst kurze Zeit ausprobiert und hatte insbesondere mit der Performance Probleme. Wie gut, dass Windows 7 alles besser machte und die Vorteile aus Vista und XP in sich vereinbarte. Es war deutlich schneller und besser zu bedienen als Vista, so dass es sich beim Heimanwender und im Unternehmensbereich gut durchsetzen konnte. Auch der Nachfolger Windows 8/8.1 hat gute Aussichten, selbst wenn viele aufgrund der Metro-Oberfläche (Modern UI) und dem fehlenden Startmenü bedenken haben. Ich nutze es seit Erscheinen von Windows 8 jedoch begeistert, auch wenn ich selbst anfangs skeptisch war und gesagt habe: ich glaube nicht, dass es gut ist, aber ich gebe ihm ne Chance. Die Chance war auf jeden Fall verdient und inzwischen ist Windows 8.1 ganz gut bedienbar. Das Startmenü brauche ich eigentlich gar nicht mehr. Trotzdem finde ich es gut, dass Microsoft es noch dieses Jahr wieder zurück bringen will.

Gestern, am 08. April 2014 wurde nun auch der von Microsoft schon verlängerte Langzeitsupport für Windows XP beendet. Gestern gab es die letzten Sicherheitpatches. Diese halten noch ein paar Tage oder Wochen durch, doch kann es jederzeit sein, dass eine Sicherheitslücke gefunden wird, die aus Windows XP eine Gefahr für den Benutzer und seine Umwelt machen (bspw. Botnetze). Denn die organisierten Verbrecherbanden wissen auch, dass es für XP keine Sicherheitspatches mehr geben wird und sie wissen auch, dass XP immer noch weit verbreitet ist. Also werden sie auch weiterhin Schadsoftware entwickeln. Deshalb ist Windows XP ab sofort nicht mehr dazu geeignet, bspw. Online-Banking zu nutzen, da Banken im Falle eines Falles darauf verweisen können, dass der verwendete PC nicht mehr sicher genug war und der Nutzer somit auf allen entstandenen Kosten sitzen bleibt. Versicherungen und Gerichte könnten die weitere Nutzung von XP als grob fahrlässig oder sogar als vorsätzlich werten. Wer jetzt noch XP nutzt, handelt auf eigene Gefahr und muss mit allen Konsequenzen, die daraus entstehen, leben.

So long and thanks for all the fish! Good bye Windows XP!

XPGOODBYE

[Tech-Tipp] Hyper-V VMs schalten NumLock aus

Sehr nervig, aber relativ einfach zu beheben, ist das Problem, dass virtuelle Maschinen (VMs), die unter Microsoft Hyper-V (Server 2012 und Windows 8) laufen, bei einer Konsolenverbindung (also nicht per RDP) den NumLock ausschalten. So muss man nach der Benutzung der direkten Verbindung immer überprüfen, ob NumLock wieder angeschaltet ist, bevor man was auf dem Nummernblock eintippt.

Mit dem Windows PowerShell Befehl (als Admin ausführen)

Set-VMBios [VM-Name] -EnableNumLock

wird NumLock für die konkrete VM aktiviert. Die VM muss dabei ausgeschaltet sein.

Hat man mehrere VMs, kann man auch mehrere gleichzeitig ändern. Auch hier müssen die VMs selbstverständlich ausgeschaltet sein, was der erste Teil des PowerShell-Scripts überprüft:

$NumLockVMs = Get-VM  | Where-Object -Property State -EQ "Off"
$NumLockVMs | Set-VMBios -EnableNumLock

[Tech-Tipp] Windows Server 2012 Firewall und Linux Server LDAP-Abfrage

Ausgangssituation: In unserer Serverumgebung haben wir als Domain-Controller Windows Server 2012 im Einsatz. Einige Dienste (bspw. Confluence, Jira, Fisheye) laufen auf Linux-Servern und rufen die User-Credentials per LDAP-Anbindung von den Domain-Controllern ab. In den Log-Dateien der Linux-basierten Dienste haben wir regelmäßig Timeouts bzw. fehlgeschlagene LDAP-Verbindungen gefunden. Außerdem war es häufiger nötig, die Linux-Dienste neu zu starten, damit eine Benutzeranmeldung (wieder) möglich war.

Lösung: nach einiger Recherche bin ich darauf gestoßen, dass die Firewall der Windows Server seit Windows Server 2008 einen so genannten Stealth-Mode besitzt. Soweit ich das verstanden habe, werden dadurch Verbindungen von Clients zum Server kurz verzögert oder bei zu vielen Anfragen (automatisierte Anfragen) abgelehnt. Dieser Stealth-Mode kann nur über eine Änderung an der Registry ausgeschaltet werden. Weitere Infos: http://technet.microsoft.com/en-us/library/dd448557%28WS.10%29)

HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile

Hier einen neuen DWORD-Eintrag mit dem Namen “DisableStealthMode” (Groß- und Kleinschreibung beachten) und dem Wert “1″ anlegen. Nach einem Neustart des Servers ist der Stealth-Mode für das Domänen-Profil der Firewall deaktiviert. Unter Umständen kann es notwendig sein, dass auch in den anderen Firewall-Profilen (falls angelegt und in Benutzung) dieser Eintrag gemacht werden muss.

Fazit: Seit der beschriebenen Änderung an den Domain-Controllern kommt es zu keinen Fehlermeldungen mehr und keiner der Linux-Server bzw. Linux-Dienste musste seitdem neugestartet werden.

[Tech-Tipp] Operationen beim Shutdown unter Windows 8.1

Bei Windows hat man ja die Möglichkeit, irgendwelche Operationen beim Herunterfahren des Systems durchführen zu lassen. Bei mir zu Hause ist es zum Beispiel das Backup mit Acronis True Image (Amazon Link). Bei mir in der Firma ist es die Installation von Software- und Windows-Updates mit baramundi. Seit dem Patchday im Februar habe ich bemerkt, dass dies nicht mehr funktioniert, sondern der PC augenscheinlich direkt ausgeht. Zunächst habe ich es zu Hause an meinem Privat-PC bemerkt, dass irgendwas nicht stimmt, da das Backup nicht mehr lief (beim Herunterfahren fehlte mir das “Operations are in progress” und natürlich gab es auf der externen Festplatte keine neuen Backup-Dateien). Auch hatte ich, um eine andere Sache zu testen, mal den Virenscanner bis zum nächsten Neustart deaktiviert, der diesen Status allerdings auch nach dem Neustart beibehielt. Nach einiger Recherche bin ich darauf gestoßen, dass wohl beim letzten Update-Rollup was an der Mechanik des Herunterfahrens “ausgebessert” wurde:
http://support.microsoft.com/kb/2919394/en-us
bzw.
http://support.microsoft.com/kb/2922812/en-us

Ich konnte das Problem gestern Abend an meinem Privat-PC beheben, indem ich den Schnellstart deaktivierte: http://www.askvg.com/fix-windows-8-r…tdown-feature/

Rechtsklick auf den Startbutton und dann Energieoptionen wählen:

Win8.1_Energieoptionen

Dort links auf “Auswählen, was beim Drücken des Netzschalters passieren soll”:

Win8.1_Energieoptionen2

Hier muss ggf. noch auf “Einige Einstellungen sind momentan nicht verfügbar” geklickt werden, um die benötigten Optionen freizuschalten:

Win8.1_Energieoptionen3

Dann kann das Häkchen hinter “Schnellstart aktivieren (empfohlen)” entfernt werden:

Win8.1_Energieoptionen4
Heute habe ich es auch schon erfolgreich an einem Windows 8.1 Client in der Firma ausprobiert. Die Installation der Updates läuft wieder. Ob Windows 8 auch betroffen ist, kann ich nicht sagen (ich schätze aber schon). Ältere Windowsversionen (also Windows 7 und älter) haben das Schnellstartfeature nicht und sind somit nicht betroffen.

Leider lässt sich der Schnellstart über die Gruppenrichtlinien nicht sehr komfortabel deaktivieren. Stattdessen muss man entweder manuell alle Clients entsprechend einstellen oder eine Registry-Änderung über die GPO verteilen. Der entsprechende Schlüssel ist:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled = 0

(siehe auch die letzten beiden Beiträge hier: http://social.technet.microsoft.com/…&prof=required)

Nachtrag am 07.03.2014: Ich habe gerade festgestellt, dass in Domain-Umgebungen bei aktiviertem Schnellstart auch keine servergespeicherten Profile (Roaming Profiles) mehr synchronisiert werden. In Firmen, bei denen die Benutzerprofile also auf einem Server liegen und die Benutzer (wenigstens hin und wieder mal) ihren Arbeitsplatz wechseln (müssen), sollte der Schnellstart also unbedingt deaktiviert werden.

[Tech-Tipp] Windows 8.1 Ruhezustand Monitor-Bug

In den letzten Tagen beschäftigte mich ein merkwürdiges Problem bei einem DELL Inspiron 15 mit Windows 8.1. Ging der Laptop nach 15 Minuten in den Ruhemodus, konnte das Display nicht reaktiviert werden. Eine Verbindung per RDP konnte nicht wirklich hergestellt werden (das Bild blieb schwarz), aber bspw. mit mmc, psexec oder über die administrativen Freigaben konnte ich auf den Laptop zugreifen. Um wieder richtig mit dem Gerät arbeiten zu können, war ein Hard-Reset nötig.

Nachdem ein Update aller Grafikkartentreiber nichts brachte, musste ich die Lösung an anderer Stelle suchen. Da ich die Original-Festplatte gegen eine (auch von DELL bezogene) SSD getauscht hatte, wollte ich nun ein eventuelles Kompatibilitätsproblem ausschließen und baute die ursprüngliche Platte wieder ein. Dort war noch der Werkszustand vorhanden, also Windows 8 ohne weitere Updates. In diesem Zustand funktionierte der Ruhemodus tadellos. Auch nach der Installation sämtlicher verfügbarer Windows-Updates inklusive der von Windows Update bereitgestellten Treiberupdates funktionierte der Ruhemodus so, wie er sollte.

Nach dem Upgrade auf Windows 8.1 war das Problem plötzlich da. Die meisten in Internetforen erwähnten Tipps (Treiber aktualisieren, Kennwortabfrage bei Reaktivierung deaktivieren usw.) haben nicht geholfen. Da sich das Problem doch relativ gut auf die Grafikkarte und somit genauer auf die verbaute ATI-Grafikkarte eingrenzen ließ (das Catalyst Control Center konnte nicht gestartet werden), habe ich es sogar mit den aktuellen Beta-Treibern von ATI ausprobiert, doch auch hier gab es keine Änderung am Verhalten. Ebenso half auch kein Update der Intel Chipsatz-Treiber und der Treiber für die integrierte Intel-Grafikkarte.

Der letzte Schritt, nämlich die Deaktivierung des Ruhemodus durch “powercfg -h off” (hierzu muss die Kommandozeile mit Admin-Rechten gestartet werden; danach ein Neustart), konnte das Problem mehr oder weniger beseitigen. Es ist zwar nur ein Workaround, weil der Ruhemodus anschließend ja ausgeschaltet ist, wichtiger ist aber, dass man den Laptop wieder reaktivieren kann, wenn die Energiespar-Optionen greifen. Vermutlich hilft es auch, den Energie-Plan auf “Höchstleistung” zu setzen und den Bildschirm nie ausschalten zu lassen.

Offenbar betrifft dieses Problem hauptsächlich Laptops, die neben der integrierten Intel-Grafik noch eine zusätzliche ATI-Grafikkarte verbaut haben. Jedenfalls konnte ich das soweit durch Internetrecherche eingrenzen. Sehr wahrscheinlich ist der ATI-Treiber an diesem Problem schuld. Auf allen anderen Laptops (ohne ATI-Grafik), die ich hier getestet habe, tritt das Problem nicht auf. Andererseits kann es auch sein, dass Windows 8.1 Probleme damit hat, wenn zwei Grafikkarten unterschiedlicher Hersteller verbaut sind. Letztendlich kann man nur abwarten, ob es dafür irgendwann einen Windows-Patch oder einen passenden ATI-Treiber gibt.