VM plus zugehörige Dateien umbenennen

Eine VM läßt sich einfach mittels dem vSphere Client umbenennen.

Wenn man aber auch die zu Grunde liegenden Dateien mit umbennen möchte, wirds mit der GUI schwierig.
Der vSphere Client verweigert bspw das Umbenennen der vmdk Dateien.

Folgender Weg führt zur Lösung:

  • Im vSphere Client die VM aus der Bestandsliste entfernen (nicht von Festplatte löschen).
  • per putty eine SSH Verbindung zu einem VMware Host aufbauen.
  • in den Pfad /vmfs/volumes/’Volume-Name’/’VM-Name‘ wechseln
  • virtuelle Disk mittels vmkfstools umbenennen:
    vmkfstools –renamevirtualdisk AlterName.vmdk NeuerName.vmdkDabei wird die AlterName-flat.vmdk automatisch mit umbenannt.
  • Alle anderen Dateien mittels mv AlterName.xyz NeuerName.xyz umbenennen.
  • mittels vi die .vmx Datei öffnen und alle Stellen editieren, die auf den alten Namen verweisen und entsprechend den neuen Namen eintragen.
  • mit 😡 vi beenden und dabei die Datei speichern.
  • Im Datenspeicherbrowser die .vmx Datei auswählen und die VM registrieren. Fertig.

ODBC-Treiber unter Windows 7 64 Bit

Bei der Suche nach o.g. Problematik bin ich auf folgendes Blogposting gestoßen:Copy & Paste von http://www.hannes-bischof.de/?p=10

Gestern bin ich auf ein Problem mit ODBC-Treibern unter 64Bit Systemen wie z.B. Windows 2003 Server oder Windows Vista gestoßen. Dabei sollte eine .NET Anwendung die bisher auf allen 32Bit Systemen problemlos lief auf einem 64Bit Windows 2003 Server installiert und betrieben werden. Das Starten der Anwendung war auch problemlos möglich nur beim Verbinden mit der Datenbank konnte meine Anwendung den ODBC-Treiber bzw. den zugehörigen DSN nicht finden.
 
Nach aufwendiger Suche hat sich als erstes gezeigt das unter 64 Bit Systemen ODBC nicht gleich ODBC ist. Dies liegt daran das es zwei Arten von ODBC Treibern gibt, 32Bit und 64Bit ODBC Treiber. Viele Systeme liefern bisher aber noch ausschließlich die 32Bit Treiber aus und installieren diese auch. Wenn man nun unter dem Menüpunkt Systemsteuerung->Verwaltung->Datenquellen die Einträge für den System-DSN, User-DSN oder den zugehörigen ODBC Treiber sucht wird man nichts finden. Hier werden lediglich die DSN’s und Treiber angezeigt die 64Bit tauglich sind.
 
Um sich nun auch die 32Bit Treiber und DSN’s anzeigen zu lassen gibt es aber einen Trick. Mit dem Programm odbcad32.exe, das unter C:WindowsSysWOW64odbcad32.exe zu finden ist, wird vom Aussehen her genau die gleiche Datenquellenanzeige gestartet wie unter Systemsteuerung->Verwaltung->Datenquellen, jedoch dieses mal mit den 32Bit Treibern und DSN’s. Wie kann aber nun meine Anwendung festlegen das sie einen 32Bit oder 64Bit ODBC-Treiber verwenden will? Im Sourcecode ist das meines Wissens nach gar nicht möglich. Generell ist es so das 32Bit Anwendungen automatisch auf 32Bit ODBC-Treiber zugreifen und 64Bit Anwendungen auf die 64Bit ODBC-Treiber. 
 
Deshalb muss man seiner Anwendung sagen das Sie explizit als 32Bit Anwendung ausgeführt werden soll. Dazu muss man im VisualStudio in den Projekteinstellungen seiner Windows-Anwendung (.exe Datei) unter dem Reiter „Erstellen“ die Zielplattform von „Any CPU“ auf „x86“ umstellen. Dadurch wird die Anwendung explizit als 32Bit Anwendung gestartet und auch die zugehörigen ODBC-Treiber benutzt. Dies ist nur im Projekt der Startanwendung (.exe) nötig, nicht bei evt. eingebundenen DLLs. Die Angabe „x86“ ist hier gleichzusetzen mit 32Bit Anwendung und „x64“ mit 64Bit Systemen. Bei „Any CPU“ wird die Anwendung als 64Bit Anwendung gestartet falls es sich um ein 64Bit System handelt.

Sprache der Outlook Ordner zurücksetzen

Es gibt verschiedene Gründe, warum die Outlook Ordner beim ersten Aufruf eines Exchange Postfachs in einer falschen Sprache erscheinen (in meinem Fall englisch).

Mittels eines Parameters beim Outlookstart läßt sich das aber beheben.

…./Outlook.exe /resetfoldernames

Vollständige Liste für Outlook 2010 unter

http://office.microsoft.com/de-de/outlook-help/befehlszeilenoptionen-fur-microsoft-outlook-2010-HP010354956.aspx?CTT=1

Sysinternals ’newsid‘ für Windows 7 bzw. Windows Server 2008 R2 …

…wird es nicht geben. Und eigentlich hätte man es wohl auch nie gebraucht. Zu dem Schluss kommt zumindest der Author des Tools, Mark Russinovich bereits im November 2009. Jetzt ists auch bei mir angekommen.

http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

MAC Adresse unter Windows-NT als Gastsystem ändern

Da VMware die Änderung der MAC Adresse für eine VM nur für einen bestimmten Adressbereich zuläßt, kann es ggf. notwendig sein solche Änderungen innerhalb einer VM, direkt im Betriebssystem vorzunehmen.
Bei Windows Betriebssysteme ab Windows 2000 ist es möglich, die MAC direkt in den Eigenschaften der Netzwerkkarte zu ändern.
image
Für ein zu virtualisierendes Windows NT Workstation muss ich die MAC Adresse anpassen, da eine alte Applikation auf ein flexlm zugreift dessen Lizenz an die MAC Adresse gebunden ist.
Es hilft ein weiterer DWORD Eintrag in der Registry unter HKEY_LOCAL_MACHINESystemCurrentControlSetServicesvmxnetParameters mit dem Namen “NetworkAddress”. Als Wert trägt man die gewünschte MAC Adresse ein. Nach dem Neustart der VM ist der Wert aktiv.

Fehlende Stammzertifikate nach Update auf Windows 7

Um von meinem, mit unzähligen Applikationen bestückten, Windows XP Pro auf Windows 7 zu updaten, wählte ich den Weg, ein Update auf Win Vista zwischen zu schieben und anschließend direkt ein Update auf Windows 7 anzuschließen. Ein Datenträger von Vista hatte ich zur Hand, ein Lizenzschlüssel ist für die (ohnehin nur temporäre) Installation nicht notwendig. Bis auf vereinzelte Programme, welche jeweils im Vorfeld durch die Updateprüfung auffielen (und daraufhin deinstalliert wurden) verlief das Prozedere nun schon auf mehreren Rechnern weitgehend problemlos.
Ein gravierenderes Problem ist mir nun aber doch untergekommen. Direkt nach dem Update bekam ich immer beim Aufruf von Webseiten über https eine Zertifikatsfehlermeldung.
Ein Blick in den Zertifikatsspeicher für vertraute Stammzertifizierungsstellen offenbarte mir gähnende Leere. Testweise fügte ich einzelne Stammzertifikate von Hand in den Speicher ein, was dann tatsächlich auf den Internetseiten mit betreffend signierten Zertifikaten das Problem behob.
Ein Wenig Suche im Netz führte mich zu dem Microsoft Knowledgebase Artikel 931125. Hier wird ein Update für die Stammzertifikate als Komplettpaket angeboten. Dieses Paket, obwohl für Windows XP ausgewiesen, installierte ich unter Win 7 und siehe da, die Liste der vertrauten Stammzertifizierungsstellen ist wieder gewohnt gefüllt und die Zertifikatsfehler weitgehend verschwunden.

Kurze Ergänzung. Hier das Paket mit Stand April 2012