BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
PRODID:- PBCS IT-News //NONSGML Events //EN
CALSCALE:GREGORIAN
X-WR-CALNAME:ICAL-BLOG
BEGIN:VEVENT
UID:0ae379c2-bff2-43d0-b74d-e2744c0f766d
DTSTAMP:20260415T135009Z
CREATED:20260415T135009Z
SUMMARY:Sysprep erzeugt keine eindeutigen vm IDs
DESCRIPTION:https://wp.pbcs.de/sysprep-erzeugt-keine-eindeutigen-vm-ids/ - Artikel vom: Di.\, 29. Juli 2025\, 20:50:07 - Wenn man Sysprep beim Klonen von Windows-VMs verwendet\, kann es passieren\, dass alle geklonten Systeme die gleiche IdentifyingNumber aus Win32_ComputerSystemProduct erhalten – insbesondere bei virtuellen Maschinen (VMs).\n \n🧩 Warum ist das so?\n \nIdentifyingNumber stammt aus SMBIOS\n \n\nDie Eigenschaft Win32_ComputerSystemProduct.IdentifyingNumber wird vom SMBIOS geliefert.\n \nBei physischen PCs enthält sie z. B. die Seriennummer des Mainboards.\n \nBei VMs (z. B. Hyper-V\, VMware\, VirtualBox) wird dieser Wert vom Hypervisor simuliert oder fix vorgegeben.\n\n \nSysprep verändert SMBIOS-Werte nicht\n \n\nSysprep entfernt Benutzerinformationen\, SIDs\, Netzwerkkonfigurationen etc.\n \nAber es verändert keine Hardwareinformationen wie:\n\nIdentifyingNumber\n \nUUID (aus Win32_ComputerSystemProduct.UUID)\n \nSerialNumber (aus Win32_BIOS)\n\n\n \nDiese Werte bleiben nach dem Sysprep-Klonen identisch\, wenn der Hypervisor sie nicht automatisch generiert oder du sie manuell ersetzt.\n\n \n⚠️ Warum ist das ein Problem?\n \nAsset-Management\n \nTools wie SCCM\, GLPI\, OCS Inventory oder Lizenzsysteme nutzen IdentifyingNumber zur Erkennung von Geräten.➡️ Wenn alle VMs die gleiche ID haben → Geräteüberschreibung.\n \nLizenzierung\n \nSoftware\, die per Hardware-ID lizenziert wird (z. B. manche PHP-Verschlüsselungen\, SQL-Server-Bindungen)\, wird beim Klonen ungültig oder doppelt registriert.\n \n🛠 Lösung: Eindeutige SMBIOS-IDs zuweisen\n \nFür Hyper-V:\n \npowershellKopierenBearbeitenSet-VMFirmware -VMName "VM-Name" -SystemSerialNumber "DEINE-EINDEUTIGE-ID"\n\n \nFür VMware Workstation/ESXi:\n \n\nIn .vmx-Datei: iniKopierenBearbeitenuuid.bios = "56 4d 12 34 56 78 90 ab-cd ef 12 34 56 78 90 ab" serialNumber = "VM-1234567890"\n\n \nFür VirtualBox:\n \ncmdKopierenBearbeitenVBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/SerialNumber" "UNIQUE-ID"\n\n \n\n⚠️ Diese Werte müssen vor dem ersten Boot nach dem Klonen gesetzt werden.\n\n \n✅ Empfohlener Klon-Prozess für VMs mit Sysprep\n \n\nSysprep ausführen (generalize + shutdown)\n \nVM nicht sofort starten\, sondern:\n\neine neue UUID\, Seriennummer\, MAC-Adresse etc. konfigurieren\n\n\n \nErst danach VM starten und initialisieren lassen\n\n \n🔒 Alternative: Bessere Hardware-IDs nutzen\n \nWenn du eine eindeutige Systemkennung brauchst\, verwende eine dieser Optionen:\n \nWMI PropertyVorteilWin32_ComputerSystemProduct.UUIDEtwas robuster\, aber oft auch identischWin32_BIOS.SerialNumberManchmal vom Host überschrieben (z. B. "VMware-56...")Get-CimInstance Win32_BaseBoard + SerialNumberBIOS-Board-spezifisch\, aber bei VMs oft leerMAC-Adresse der NICUnterscheidbar\, falls per DHCP/Hypervisor generiert\n \nOder:Erzeuge bei Erststart eine eindeutige Kennung (z. B. GUID in Datei/Registry) → das ist verlässlich\, selbst bei gleichen Hardware-IDs.\n \n🧾 Fazit\n \nPunktAussageIdentifyingNumber wird nicht von Sysprep zurückgesetzt✅ korrektKlone ohne Anpassung erzeugen Duplikate⚠️ problematisch für Inventar\, Lizenzierung\, MonitoringLösungSeriennummer/UUID per Hypervisor setzen vor dem Start der geklonten VMAlternativEigene GUID beim First Boot generieren und persistieren
LOCATION:https://wp.pbcs.de
CATEGORIES:Gelbe Kategorie
TRANSP:TRANSPARENT
X-MICROSOFT-CDO-BUSYSTATUS:FREE
SEQUENCE:0
CLASS:PUBLIC
PRIORITY:1
DTSTART:20260309T080000Z
DTEND:20260309T090000Z
BEGIN:VALARM
TRIGGER:-PT30M
ACTION:DISPLAY
DESCRIPTION:Reminder for Sysprep erzeugt keine eindeutigen vm IDs
END:VALARM
END:VEVENT
END:VCALENDAR