Ich Blog Dich!

Seit einigen Wochen erhalten einige Outlook 365 Nutzer:innen beim Starten ihres Outlook 365 die Fehlermeldung „Der Kalender konnte nicht gelesen werden“.

Die Ursache tritt mit der Version 2103 (Build 13901.20336) auf.

Auf einen Microsoft Forumeintrag, in dem die Community recht schnell die Ursache in der aktuellen Outlook Version lokalisieren konnte, hat Microsoft nun offiziell Stellung zu dem Problem bezogen.

„The Outlook Team made a change from the service that should mitigate the issue. The change is not tied to an update. Outlook will automatically pick up the change on Outlook restart. It may take a couple days before the change is available to everyone.“

Für die Betroffenen heißt es nun, die Finger still zu halten, und nicht in der eigenen Konfiguration die Ursache zu suchen (und sich so unnötig Arbeit zu machen, oder evtl. größeren Schaden anzurichten).

Die klassischen 08/15 Ratschläge im Netz, die das Reparieren der PST Dateien mit Microsoft Tools empfehlen, schaffen bei diesem Fehler keine Abhilfe.

Im Januar 2020 lief Windows 2008 R2 aus dem Support. Um kleinere Server nun ohne großen Aufwand auf ein supportetes Betriebssystem zu bringen, bietet sich ein InPlace Upgrade an. Normalerweise macht man das ja eher ungern und migriert auf neuste OS-Versionen mittels Neuinstallationen. Aber um den Aufwand und die Lebensdauer bestehender Server noch etwas zu verlängern, kann man bei Windows 2008 R2 zumindest den Weg auf Windows 2012 R2 (EOL Oktober 2023) gehen um nochmal 3 Jahre Zeit zu gewinnen. Achtung, vorher am Besten beim Hwardware-Hersteller des Servers abchecken, ob Windows 2012 R2 für diese Hardware auch supported ist.

In meinem Fall war der Server ein DELL T110 II Server, der bis zu Windows 2012 R2 von DELL supported ist. Also ideale Voraussetzungen für ein günstiges Upgrade.

Hat man einen Server mit der 2008 R2 Foundation Version, funktioniert das Upgrade leider nicht sofort ohne weiteres. Um einen kleinen Server mit Windows 2008 R2 Foundation auf Windows 2012 R2 zu aktualisieren, habe ich foglenden Upgrade-Pfad verwendet:

1. Zuerst eine vollständige Datensicherung des Servers durchführen. Ich nutze dafür gerne den kostenlosen Veeam Windows Agent, der mir auch ein Bare Metal Restore ermöglicht, wenn alle Stricke reißen sollten.
2. Ein Update der Foundation auf eine höhere Version ist nicht direkt möglich. Man muss den Umweg über die Standard-Edition gehen. Dazu muss man die 2008 R2 Foundation zuerst auf eine 2008 R2 Standard Edition upgraden. Dazu führt man das Update über die Kommandozeile wie folgt aus:
   DISM /online /Set-Edition:ServerStandard /ProductKey: 4GGC4-9947F-FWFP3-78P6F-J9HDR
   (der ProductKey ist ein Evaluation Key, den ich hier gefunden habe)
   Das Upgrade der Edition dauert etwas und man benötigt dabei Internetzugriff. Nach dem Update startet der Server dann mehrfach neu bis die Edition auf Standard upgegraded ist.
3. Nun ist der Weg frei, mittels einer Windows 2012 R2 Standard ISO das Inplace Upgrade auf Windows 2012 R2 Standard durchzuführen. Dazu einfach das Setup auf der ISO starten und das Update anstossen.
   Das ISO für 2012 R2 bekomme ihr direkt bei Microsoft im Evaluation Center.
   

Abschließend benötigt man natürlich eine neue Lizenz für Windows 2012 R2 Standard, die man sich aber recht günstig bei div. Lizenzhändlern oder EBay besorgen kann. Auf jeden Fall kann man so das Upgrade zuerst einmal ausführliche testen bevor man Geld für eine Lizenz ausgibt.

Wer sich einen aktuellen VMware Workstation Player nach V12 auf seinem Rechner installiert und dieser noch mit einer älteren CPU läuft, bekommt bereits bei der Installation eine Meldung, dass die vorhandene CPU evtl. diverse CPU-Features nicht unterstützt.

Ignoriert man diese Meldung und installiert den Player dennoch in der aktuellen Version, bekommt man beim Start von VMs dann entsprechend die Quittung wie in meinem Fall mit folgender Meldung:

„This host does not support virtualizing real mode. The Intel „VMX Unrestricted Guest“ feature is necessery to run this virtual machine on an Intel Processor. Module ‚CPUIDEarly‘ power on failed. Failed to start the virtual mashine.“

Die Lösung für dieses Problem ist erst einmal ziemlich einfach, da die Recherche nach diesem CPU-Feature und der Unterstützung in der eigenen CPU nicht ganz einfach ist.

Man kann dem Player einfach sagen, dass er das ignorieren soll und auch Legacy-CPUs zulassen soll.

Dazu einfach in der CONFIG.INI des Players im Verzeichnis C:\ProgramData\VMware\VMware Workstation folgenden Eintrag hinzufügen und speichern:

monitor.allowLegacyCPU = „true“

Danach klappts auch wieder mit dem Player auf alten CPUs.

Gut nix alzu Neues, aber wer eben mit dem Updaten etwas hinterher ist, wird es auch erst jetzt merken. NVIDIA Geforce Experience hat die Accountbindung eingeführt.

Das sieht dann so aus:

Meine Reaktion sieht dann so aus:

Wenn sich doch nur alle Probleme so einfach lösen ließen.

Nach der Installation der aktuellen Windows Updates vom Mai 2016 auf einem WSUS-Server, bei denen auch der Patch KB3159706 enthalten ist, funktioniert der WSUS-Server nach dem Reboot erst mal nicht mehr.

Keine Panik, die Ursache dafür sind lediglich ein paar Steps die man NACH der Installation des KB3159706 unbedingt manuell noch durchführen muss. Danach geht wieder alles wie gewohnt.

https://support.microsoft.com/de-de/kb/3159706