Sysprep erzeugt keine eindeutigen vm IDs

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).

🧩 Warum ist das so?

IdentifyingNumber stammt aus SMBIOS

  • Die Eigenschaft Win32_ComputerSystemProduct.IdentifyingNumber wird vom SMBIOS geliefert.
  • Bei physischen PCs enthält sie z. B. die Seriennummer des Mainboards.
  • Bei VMs (z. B. Hyper-V, VMware, VirtualBox) wird dieser Wert vom Hypervisor simuliert oder fix vorgegeben.

Sysprep verändert SMBIOS-Werte nicht

  • Sysprep entfernt Benutzerinformationen, SIDs, Netzwerkkonfigurationen etc.
  • Aber es verändert keine Hardwareinformationen wie:
    • IdentifyingNumber
    • UUID (aus Win32_ComputerSystemProduct.UUID)
    • SerialNumber (aus Win32_BIOS)
  • Diese Werte bleiben nach dem Sysprep-Klonen identisch, wenn der Hypervisor sie nicht automatisch generiert oder du sie manuell ersetzt.

⚠️ Warum ist das ein Problem?

Asset-Management

Tools wie SCCM, GLPI, OCS Inventory oder Lizenzsysteme nutzen IdentifyingNumber zur Erkennung von Geräten.
➡️ Wenn alle VMs die gleiche ID haben → Geräteüberschreibung.

Lizenzierung

Software, die per Hardware-ID lizenziert wird (z. B. manche PHP-Verschlüsselungen, SQL-Server-Bindungen), wird beim Klonen ungültig oder doppelt registriert.

🛠 Lösung: Eindeutige SMBIOS-IDs zuweisen

Für Hyper-V:

powershellKopierenBearbeitenSet-VMFirmware -VMName "VM-Name" -SystemSerialNumber "DEINE-EINDEUTIGE-ID"

Für VMware Workstation/ESXi:

  • In .vmx-Datei: iniKopierenBearbeitenuuid.bios = "56 4d 12 34 56 78 90 ab-cd ef 12 34 56 78 90 ab" serialNumber = "VM-1234567890"

Für VirtualBox:

cmdKopierenBearbeitenVBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/SerialNumber" "UNIQUE-ID"

⚠️ Diese Werte müssen vor dem ersten Boot nach dem Klonen gesetzt werden.

✅ Empfohlener Klon-Prozess für VMs mit Sysprep

  1. Sysprep ausführen (generalize + shutdown)
  2. VM nicht sofort starten, sondern:
    • eine neue UUID, Seriennummer, MAC-Adresse etc. konfigurieren
  3. Erst danach VM starten und initialisieren lassen

🔒 Alternative: Bessere Hardware-IDs nutzen

Wenn du eine eindeutige Systemkennung brauchst, verwende eine dieser Optionen:

WMI Property Vorteil
Win32_ComputerSystemProduct.UUID Etwas robuster, aber oft auch identisch
Win32_BIOS.SerialNumber Manchmal vom Host überschrieben (z. B. „VMware-56…“)
Get-CimInstance Win32_BaseBoard + SerialNumber BIOS-Board-spezifisch, aber bei VMs oft leer
MAC-Adresse der NIC Unterscheidbar, falls per DHCP/Hypervisor generiert

Oder:
Erzeuge bei Erststart eine eindeutige Kennung (z. B. GUID in Datei/Registry) → das ist verlässlich, selbst bei gleichen Hardware-IDs.

🧾 Fazit

Punkt Aussage
IdentifyingNumber wird nicht von Sysprep zurückgesetzt ✅ korrekt
Klone ohne Anpassung erzeugen Duplikate ⚠️ problematisch für Inventar, Lizenzierung, Monitoring
Lösung Seriennummer/UUID per Hypervisor setzen vor dem Start der geklonten VM
Alternativ Eigene GUID beim First Boot generieren und persistieren
Zusammenfassung
  1. Aber es verändert keine Hardwareinformationen wie: (aus ) (aus ) Diese Werte bleiben nach dem Sysprep-Klonen identisch, wenn der Hypervisor sie nicht automatisch generiert oder du sie manuell ersetzt.
  2. Wenn man Sysprep beim Klonen von Windows-VMs verwendet, kann es passieren, dass alle geklonten Systeme die gleiche aus erhalten – insbesondere bei virtuellen Maschinen (VMs).
  3. ") + BIOS-Board-spezifisch, aber bei VMs oft leerMAC-Adresse der NICUnterscheidbar, falls per DHCP/Hypervisor generiert Oder:Erzeuge bei Erststart eine eindeutige Kennung (z.
Verwandte Beiträge
Software Bild

TreeSizeFree vs. WindirstatTreeSizeFree ist (bis Version 4.7.2) ein geschäftlich und privat nutzbares, portables Werkzeug, um sich in Ordnerstrukturen die größten Platz-Verbraucher anzeigen

Software Bild

Notepad PlusPlusn rnden beliebten Text-Editor gibt es nun ab Version 7.0 auch in 64-Bit. Damit fällt die Größenbeschränkung im RAM

Häufige Fragen
Worum geht es?

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).

Was ist dabei besonders wichtig?

Die Eigenschaft Win32_ComputerSystemProduct.IdentifyingNumber wird vom SMBIOS geliefert. Bei physischen PCs enthält sie z. B. …

Welche zentralen Punkte sollte man beachten?

PunktAussageIdentifyingNumber 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

Was sollte man dazu wissen?

cmdKopierenBearbeitenVBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/SerialNumber" "UNIQUE-ID" ⚠️ Diese Werte müssen vor dem ersten Boot nach dem Klonen gesetzt werden.

Fakten zu 🔒 Alternative: Bessere Hardware-IDs nutzen

GUID in Datei/Registry) → das ist verlässlich, selbst bei gleichen Hardware-IDs. B. B. …

Fakten zu Sysprep verändert SMBIOS-Werte nicht

Sysprep entfernt Benutzerinformationen, SIDs, Netzwerkkonfigurationen etc. …

Fakten zu IdentifyingNumber stammt aus SMBIOS

Die Eigenschaft Win32_ComputerSystemProduct.IdentifyingNumber wird vom SMBIOS geliefert. Hyper-V, VMware, VirtualBox) wird dieser Wert vom Hypervisor simuliert oder fix vorgegeben. …

Fakten zu Asset-Management

Tools wie SCCM, GLPI, OCS Inventory oder Lizenzsysteme nutzen IdentifyingNumber zur Erkennung von Geräten.➡️ Wenn alle VMs die gleiche ID haben → Geräteüberschreibung.

Über den Autor: Patrick Bärenfänger ist Ihr Experte für IT-Sicherheit und IT-Systeme mit TÜV-Zertifizierungen als IT-Security Manager und -Auditor mit mehr als 35 Jahren IT-Erfahrung. Er bietet Ihnen professionelle Dienstleistungen in den Bereichen: Ausbildung und Zertifizierung von Systemkoordinierenden, Infrastruktur-Analyse und -Optimierung zur Azure-Cloud-Migration, IT-Systemprüfungen und Notfallplan/Risiko-Analyse nach anerkannten Standards BSI-Grundschutz und IDW PS330 und Anwendung der künstlichen Intelligenz in der Praxis.
Di. 29. Juli 2025 20:50:10 | 1 J01:29 | 361 W 402 | 379 | 1 74 | 18% 21 h
Software

Kommentare

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert