Gestern hatte ich eine doch etwas merkwürdige Fehlermeldung in meiner Testumgebung mit der ich nicht viel anzufangen wusste.

Event ID: 21502
Event Description: “Virtual Machine TPC-1.neumanndaniel.de: Die Livemigration war am Ziel nicht erfolgreich. Fehler beim Schreiben der Migrationsanforderung in die Warteschlange durch den Verwaltungsdienst für virtuelle Computer.”

Nach einiger Zeit, in der ich die kompletten Einstellungen inklusive Internetrecherche auf Bing und Google durchgegangen war, kam ich auf die Idee mir die Failover Clustering Einstellungen der VM näher anzuschauen. Da meine Testumgebung aus einem Server sowie einem Notebook besteht, hat der Failover Cluster zwei Netzwerke konfiguriert. Davon wird das WLAN Netzwerk auf dem Notebook jedoch nicht benutzt und ist für das Clustering deaktiviert. Leider war das WLAN Netzwerk in der VM als Live Migration Netzwerk noch definiert, so dass die Live Migration vom Notebook zum Server funktionierte, aber nicht anders herum und zu der oben genannten Fehlermeldung führte. Kurz den Haken bei dem Netzwerk entfernt und schon funktionierte die Live Migration auch in die andere Richtung ohne Probleme. Zu aller Freude am Ende muss ich doch sagen, dass die Fehlermeldung nicht sehr aussagekräftig ist und man erst mal für eine gewisse Zeit im Dunkeln herumtappen muss, um die Lösung zu finden.

Vor einigen Wochen ist mir ein sehr merkwürdiges Phänomen unter die Augen gekommen. Da ich schon seit längerer Zeit Offline Dateien nutze und diese entsprechend der angebotenen Option verschlüsselt habe, ergab sich daraus folgendes Problem. Nachdem ich mich wieder entschlossen hatte BitLocker für das komplette Systemlaufwerk zu aktivieren, meldete das Synchronisierungscenter bei mehreren Dateien “Zugriff verweigert”. Nach langem hin und her stellte sich heraus, dass nur die Option der Verschlüsselung bei den Offline Dateien deaktiviert werden musste. Was im Endeffekt auch logisch erscheint.

Vor kurzem hatte ich auf meinem Netbook einem Samsung NC10 folgenden Bluescreen:

Hardware Malfunction
Call your hardware vendor for support
NMI: Parity Check / Memory Parity Error

Nach einigen Recherchen hat sich heraus gestellt, dass dafür der  neue Atheros Treiber verantwortlich ist, der über Windows Update verteilt wird. Dieser trägt die Versionsnummer .366 am Ende. Die Treiberversion .351 von der Samsung Homepage funktioniert dagegen einwandfrei.
Solltet ihr also ein NC10 besitzen und den Bluescreen erhalten, müsst ihr nur den Treiber von der Samsung Homepage herunterladen sowie installieren.

Heute wollte ich das BIOS meines Servers aktualisieren. Dafür sollte das One Boot Flash Update Tool von Intel verwendet werden. Nach der Installation und dem dazugehörigen Neustart musste ich leider feststellen, dass meine VMs nicht mehr starteten. Als ich versuchte die VMs manuell zu starten, erschien folgende Fehlermeldung:

‘computername’ Microsoft Emulated IDE Controller (Instance ID {83F8638B-8DCA-4152-9EDA-2CA8B33039B4}): Failed to restore with error ‘General access denied error’ (0×80070005). (Virtual machine D6355DA9-5D3D-4E0A-82E7-7751F8A9BA46)…

Da mein Server-Mainboard von Intel ist, bin ich dann auf den folgenden Artikel in der Microsoft Knowledge Base gestolpert. Wodurch der Fehler auf den Intel IPMI Treiber zurückzuführen ist, der durch das One Boot Flash Update Tool installiert wird.
-> http://support.microsoft.com/kb/969556

Das in dem Artikel beschriebene ResetAccess Tool von Intel, welches nur unter Windows Server 2008 läuft, also unter Windows Server 2008 R2 den Kompatibilitätsmodus verwenden, funktionierte auf meinem Hyper-V (Windows Server 2008 R2) nicht. Vermutlich liegt es an der Konstellation der VMs auf dem Testserver, denn meine beiden DCs laufen als VM und der Testserver ist Mitglied in der Domäne. Daher musste ein anderer Weg her, um die Berechtigungen auf die VHD-Dateien wiederherstellen zu können. Im Endeffekt ist es sehr einfach, man benutzt einfach icacls dafür. Dazu braucht man nur den Pfad des Verzeichnisses der VM und deren GUID. Die GUID ist einfach die Zahlen- und Buchstabenfolge der XML-Datei der VM. Als nächstes muss in der CMD folgende Befehlszeile pro VM ausgeführt werden.

icacls "Pfad des Verzeichnisses der VM" /grant "NT Virtueller Computer\GUID":F /T

Danach hat die VM wieder Zugriff auf alle von ihr benötigten Dateien und lässt sich ohne Probleme starten.
Die Aktualisierung des BIOS habe ich dann auf die altbewährte Methode mittels DOS durchgeführt.

Es war zwar schon länger geplant sich mit dem Windows XP Mode zu beschäftigen, aber heute wurde ich gewisser Maßen durch unser Programm zum designen unserer Etiketten und zum ansteuern des Etikettendruckers dazu gezwungen. Was war genau passiert und warum lief das Programm nicht unter Windows 7 wie es sollte?
Von der Installationsseite aus gesehen musste ich nur den Kompatibilitätsmodus des Installers auf Windows Vista SP2 setzen. Allerdings hatte ich vergessen vor dem Setup den USB-Hardlock an zu stecken, so dass während der Installation nicht die richtigen Treiber installiert werden konnten. Die Erkenntnis erreichte mich leider auch erst, als ich schon kurz davor war das Notebook komplett für den restlichen Tag auszuschalten und ausgeschaltet zu lassen.
Nun zum eigentlichen Problem: Windows 7 installierte nach dem Setup von der Seite des Hardwareherstellers aus gesehen die richtigen Treiber, allerdings fand die Software nicht den USB-Hardlock und verweigerte somit ihren Dienst, da sie einen speziellen von der Softwarefirma angebotenen Treiber für den USB-Hardlock benötigt. Die Lösung des Problems schien mir der Windows XP Mode zu sein. Also Software deinstalliert und  im Windows XP Mode wieder installiert. Tada und es wurde alles richtig installiert und erkannt. Die Ernüchterung folgte darauf im nächsten Schritt, dass ich sämtliche Datenbanken, die ich per ODBC unter Windows 7 schon angegeben hatte, nun auch in den XP Mode übertragen musste, so dass die Software darauf zugreifen konnte. Die angegebenen Verzeichnisse für die Grafiken, konnte die Software dann bei der Druckausgabe auch nicht finden, obwohl diese korrekt angegeben waren. Das Einzige was ich im Endeffekt machen konnte war:

• neue Etiketten erstellen und designen
• vorhandene Etiketten ändern
• die Datenbanken ansteuern für dynamische Inhalte

Damit war leider mittels XP Mode nur ein kleiner Teil der sonst umfangreichen Programmfunktionen abgedeckt. Naja und plötzlich kehrte die Erinnerung wieder, was ich bei der Installation unter Windows 7 falsch gemacht hatte –> USB-Hardlock vor der Installation anstecken! Gesagt getan und die Software unter Windows 7 neu installiert, gestartet und sie lief.

Fazit zum Windows XP Mode:
Solange man nicht mit der installierten Software auf Datenbanken und Netzwerkdateien zugreifen muss, die einen erheblichen Konfigurationsaufwand mit sich bringen im XP Mode, damit sie auch vernünftig funktionieren oder im meinem Falle auch nicht, ist der XP Mode eine gute Idee seitens Microsoft. Ich denke bei dem ein oder anderen Programm wird mir der XP Mode in Zukunft nochmal tatkräftig zur Seite stehen.

Vor ein paar Tagen hatte ich zusätzlich zu den bestehenden DNS-Servern (2 DC’s)  in meinem Testlab einen zusätzlichen sekundären DNS-Server aufgesetzt. Naja als dann gewisse Abfragen über diesen Server nicht funktionierten, schaute ich ins Ereignisprotokoll und stellte dort die Fehlermeldung:
Quelle: DNS
Ereignis-ID: 6527
fest, dass die Zonendatei nicht übertragen werden konnte und tatsächlich die Inhalte der Zone kamen nie vollständig auf dem sekundären DNS-Server an.

Heute wurde ich dank des MCSEboard.de dann doch fündig! MS stellt für dieses Problem einen Hotfix bereit.
Mehr Details gibt es unter:
->http://blogs.technet.com/askds/archive/2009/02/12/headache-prevention-install-hotfix-953317-to-prevent-dns-records-from-disappearing.aspx

Vor gut 2 Wochen ist für mein Serverboard ein neues BIOS-Update mit einigen Neuerungen herausgebracht worden, so dass ich mich heute dazu entschlossen habe dieses Update auf dem Server zu installieren. Die Konsequenzen die daraus entstanden sind, konnte ich leider nicht erahnen. Nach dem das Update ordnungsgemäß durchgeführt worden war und ich den Neustart durchführte, wollte danach der Windows Server 2008 Hyper-V nicht mehr starten, sondern stürzte immer wieder mit einem BSOD ab.

Na gut dachte ich mir, wird es wohl mit dem Treiber des Flashtools zusammenhängen. Naja der Abgesicherte Modus funktionierte auch nicht, so dass ich mich kurzer Hand entschloss das System neuaufzusetzen, da die VM’s auf einer anderen HDD untergebracht waren, kein großer Aufwand. Nur leider stürzte die Setup-DVD auch ständig mit einem BSOD ab, was sehr merkwürdig war. Im Endeffekt habe ich die alte BIOS-Version wieder eingespielt, das System neuaufgesetzt und nun läuft alles wieder so wie es soll.

So schnell werde ich ein BIOS-Update erstmal nicht mehr machen, der ganze Ärger hat mich insgesamt 5 Stunden gekostet. BIOS-Update? Never again!

Nebenbei habe ich heute auf dem Windows Server Blog folgende Nachricht entdeckt:

->http://blogs.technet.com/windowsserver/archive/2008/10/24/windows-server-2008-service-pack-2-beta.aspx