[UPDATE1]
Weitere, von dem Problem betroffene Applikationen:

• Microsoft SQL Server
• Symantec pcAnywhere
• Symantec Antivirus
• Adobe Acrobat Reader

Die msvcp71.dll ist auch auf der VMWare Tools CD (Windows.iso, wird gemountet wenn man die Tools installiert) unter folgendem Pfad zu finden:

<cdrom drive>\program files\VMware\VMware Tools\

[/UPDATE1]

[UPDATE2]

Laut http://communities.vmware.com/message/1363520#1363520 gibt es eine Möglichkeit dieses Problem zu umgehen. Ich muss gestehen, diese Möglichkeit ist nicht schön, aber vielleicht nützlich:

chjones behauptet u.a. die msvcp71.dll wurde nicht angefasst wenn man folgendes beachtet:

• die automatische Aktualisierung der Tools aktivieren
• VMs NICHT mit VMotion auf einen vSphere 4 Host migrieren
• VMs herunterfahren und auf einem vSphere 4 Host neu booten

BTW, VMWare hat diesen Bug erkannt. Er soll in vSphere 4 Update 1 behoben werden. U1 erscheint voraussichtlich erst im November 09. Anscheinend sollte man genau wie bei M$ bis zum ersten ServicePack warten

[/UPDATE2]

Das Problem kann behoben werden, indem man die zusätzlichen Festplatten im Diskmanager wieder ‘online’ schaltet und die VM neu startet. Der Bug wurde mir gerade von VMWare bestätigt – es wird an einer Lösung gearbeitet!

Die Ursache ist anscheinend der Austausch des virtuellen Festplattencontrollers. Windows sieht diese Festplatten als “neu” an und bindet sie nicht automatisch wieder ins System ein.

Der Hintergrund alle Systeme zuerst in virtuellen Maschinen abzubilden ist hauptsächlich die Möglichkeit, in wenigen Sekunden Snapshots anzufertigen und bei Bedarf wiederherzustellen. Man friert sozusagen das Komplettsystem – alte Server und neue Server – vor jeder Daten- und Programmmigration ein und kann, falls etwas schief geht, einen konsistenten Zustand wiederherstellen.

Ein Hot-Convert mit dem VMWare Converter eines Windows 2000 Domain Controllers birgt jedoch laut VMWare einige Risiken, wie zum Beispiel diese hier. Obwohl es in den meißten Fällen gut geht, haben wir uns für die Cold-Convert Boot CD entschieden. Diese Boot-CD ist Teil des VMware vCenter Converter Enterprise, der im vCenter Server integriert ist und leider nicht kostenlos zum Download verfügbar ist. Die Boot-CD startet eine Windows PE Umgebung in welcehr der normale P2V-Converter, alle im Rechner verfügbaren Festplatten konviertiert.

Die Migration selber dauerte ca. 80 Minuten für 90GB an Daten. Dank aller Vorsichtsmaßnahmen (Cold Convert usw.) startete der alte Server in der VM tadellos. Alle Programme und Datenbanken funktionierten… bis wir einen Client-PC eingeschaltet haben.

Sie konnten nicht angemeldet werden.
Überprüfen Sie Benutzernamen und Domain und geben Sie das Kennwort ein….

Kein einziger Client-PC konnte sich an der Domäne anmelden – das Eventlog am Server meldete das Computerkonto HOSTNAME$ versuche sich mit einem abgelaufenen Computerkennwort anzumelden. WTF?! Um mittlerweile 21Uhr haben wir den Entschluss gefasst, das trotz diverser Rettungsmaßnahmen die VM unbrauchbar war und wir die alte, physikalische Kiste wieder angeschmissen haben.

Es drängte sich die Frage auf, was schief gegangen ist. Nach näherer Analyse des Servers, musste ich feststellen, dass im Server zwei RAID1 – Laufwerke vorhanden waren. BEIDE Laufwerke hatten jeweils eine aktive Partition mit einem Windows Ordner… Warum?

Es stellte sich heraus, dass die Festplattenkapazität in dem Server vor einigen Jahren zur Neige ging und größere Platten eingebaut wurden. Alle Partitionen wurden dem alten, kleinen RAID1 auf ein neues, größeres RAID1 geklont und das neue RAID1 wurde im BIOS als erstes Boot-Device eingetragen. Das alte RAID wurde jedoch nie aufgelößt und dümpelte in dem Server vor sich hin. Und genau das wurde uns bei der P2V-Migration zum Verhängnis. Da keiner daran gedacht hatte, dass mehrere bootbare Partitionen vorliegen, habe ich bei der P2V-Migration den Punkt “Alle Festplatten konvertieren und Größen beibehalten” gewählt. Gesagt, getan. Der Converter fand zwei aktive Partitionen vor und stand wahrscheinlich vor der Entscheidung welche er als Systempartition bevorzugt. Er bediente sich der erst-besten: Das alte, kleine RAID hatte die LUN0:0 und das neue, Produktivsystem die LUN0:1. Fälschlicher Weise wurde nun ide LUN0:0 als Systempartition erkannt, für die VM mit Treibern vorbereitet und gestartet.

Plötzlich wurde uns klar, das wir nach der ersten Konvertierung mehrere Stunden an einem ca. 2 Jahre alten System herumgedoktort haben und uns wunderten warum die Clients sich nicht anmelden. Keinem war aufgefallen, dass es garnicht das aktuelle System war. *FAILED* Das Resultat waren über fünf Stunden verlorene Arbeit, eine steile Lernkurve und am nächsten Tag eine erneute Spätschicht

Also vorsicht bei der der P2V-Migration von Multi-Boot-Systemen, deren Boot-Reihenfolge im BIOS eingestellt wird. Die Cold-Convert CD bereitet lediglich die niedrigste LUN mit einem Systemverzeichnis für die virtuelle Maschine vor. Die Bootreihenfolge lässt sich, analog zum echten BIOS, auch im virtuellen BIOS einstellen, jedoch fehlen in den anderen Partitionen die notwendigen Treiber für die VM (zumindest bei Win2k).