17
Geklonte Windows Systeme in MDM aufnehmen
Hallo,
ich hab' in der Vergangenheit diverse Windows-Systeme durch einfaches Klonen eines "Master-Systems" erzeugt und dann nur noch ein paar User-Spezifische Anpassungen gemacht. Die Systeme laufen problemlos in unserer Umgebung (kein AD, kein Entra, etc.)
Jetzt möchte ich diese Systeme in ein MDM-System aufnehmen, um die Verwaltung un das Management zu vereinfachen.
Dabei hab' ich folgendes Problem:
Alle geklonten Systeme melden sich anscheinend mit der selben System-Id bei meinem MDM
(ich vermute das ist der Registry Eintrag Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\MDMDeviceID\DeviceClientId)
und können deshalb von der MDM-Verwaltung nicht unterschieden werden.
Frage:
Gibt es einen Weg, diese Produktiv-Systeme zu individualisieren (neue DeviceClientId) ohne ansonsten an den Systemen irgend etwas zu ändern ?
Danke für hilfreiche Hinweise.
Grüße, Karl
ich hab' in der Vergangenheit diverse Windows-Systeme durch einfaches Klonen eines "Master-Systems" erzeugt und dann nur noch ein paar User-Spezifische Anpassungen gemacht. Die Systeme laufen problemlos in unserer Umgebung (kein AD, kein Entra, etc.)
Jetzt möchte ich diese Systeme in ein MDM-System aufnehmen, um die Verwaltung un das Management zu vereinfachen.
Dabei hab' ich folgendes Problem:
Alle geklonten Systeme melden sich anscheinend mit der selben System-Id bei meinem MDM
(ich vermute das ist der Registry Eintrag Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\OMADM\MDMDeviceID\DeviceClientId)
und können deshalb von der MDM-Verwaltung nicht unterschieden werden.
Frage:
Gibt es einen Weg, diese Produktiv-Systeme zu individualisieren (neue DeviceClientId) ohne ansonsten an den Systemen irgend etwas zu ändern ?
Danke für hilfreiche Hinweise.
Grüße, Karl
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669384
Url: https://administrator.de/contentid/669384
Ausgedruckt am: 12.11.2024 um 22:11 Uhr
17 Kommentare
Neuester Kommentar
Vor dem Klonen von non AD joined clients generell
Generalisieren einer Windows-Installation (Systemvorbereitung)
Gruß catrell
%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdownGeneralisieren einer Windows-Installation (Systemvorbereitung)
Gruß catrell
2
Nein, ohne Änderungen hast du keine Chance. Deswegen eskalieren diese Fragen immer.
Wer sowas ohne Sysprep macht steht hier leider auf verlorenem Posten.
Wer sowas ohne Sysprep macht steht hier leider auf verlorenem Posten.
Hallo Catrell und Kollegen,
Danke für den Hinweis auf Sysprep.
Da die Systeme aber bereits ohne Sysprep ausgeliefert wurden, suche ich nach einer Alternativlösung.
Grüße,
Karl
Danke für den Hinweis auf Sysprep.
Da die Systeme aber bereits ohne Sysprep ausgeliefert wurden, suche ich nach einer Alternativlösung.
Grüße,
Karl
Zitat von @KarlHo:
Hallo Catrell und Kollegen,
Danke für den Hinweis auf Sysprep.
Da die Systeme aber bereits ohne Sysprep ausgeliefert wurden, suche ich nach einer Alternativlösung.
Grüße,
Karl
Hallo Catrell und Kollegen,
Danke für den Hinweis auf Sysprep.
Da die Systeme aber bereits ohne Sysprep ausgeliefert wurden, suche ich nach einer Alternativlösung.
Grüße,
Karl
Die Alternative ist sauber neuinstallieren.
suche ich nach einer Alternativlösung.
Die gibt es nicht, das Kind liegt im Brunnen wenn du das System so behalten willst.
Seltsam nur, daß ich mit dem SID Changer schon zig laufende Systeme aus dem Brunnen wieder rausgefischt habe. Laufen bis heute in unserem Desktop Central und auch am jeweiligen Wsus.
Hallo MacLeod,
Danke für Deinen Hinweis auf den SIDCHG.
Hast du Erfahrung, welche (der vielen) Parameter man wie setzen muss, um die Systeme MDM-fähig /-unterscheidbar zu machen ?
Grüße, Karl
Danke für Deinen Hinweis auf den SIDCHG.
Hast du Erfahrung, welche (der vielen) Parameter man wie setzen muss, um die Systeme MDM-fähig /-unterscheidbar zu machen ?
Grüße, Karl
Hallo,
prinzipiell keinen. Steht alles in den 8 Zeilen des Overview. Wenn Du deinen Rechnernamen behalten willst setzt Du diesen eben manuell auf den bisherigen. Sonst wird alles durch Random Namen ersetzt. Einfacher geht es kaum.
BSP: SIDCHG64-3.0h.exe /COMPNAME:HOLLDRIO /F /R /WS:20
MfG,
Macleod
prinzipiell keinen. Steht alles in den 8 Zeilen des Overview. Wenn Du deinen Rechnernamen behalten willst setzt Du diesen eben manuell auf den bisherigen. Sonst wird alles durch Random Namen ersetzt. Einfacher geht es kaum.
BSP: SIDCHG64-3.0h.exe /COMPNAME:HOLLDRIO /F /R /WS:20
MfG,
Macleod
Hallo MacLeod,
Nochmal vielen Dank.
Ich werde das in den nächsten Tagen testen.
Grüße, Karl
Nochmal vielen Dank.
Ich werde das in den nächsten Tagen testen.
Grüße, Karl
Zitat von @MacLeod:
Hallo,
prinzipiell keinen. Steht alles in den 8 Zeilen des Overview. Wenn Du deinen Rechnernamen behalten willst setzt Du diesen eben manuell auf den bisherigen. Sonst wird alles durch Random Namen ersetzt. Einfacher geht es kaum.
BSP: SIDCHG64-3.0h.exe /COMPNAME:HOLLDRIO /F /R /WS:20
MfG,
Macleod
Hallo,
prinzipiell keinen. Steht alles in den 8 Zeilen des Overview. Wenn Du deinen Rechnernamen behalten willst setzt Du diesen eben manuell auf den bisherigen. Sonst wird alles durch Random Namen ersetzt. Einfacher geht es kaum.
BSP: SIDCHG64-3.0h.exe /COMPNAME:HOLLDRIO /F /R /WS:20
MfG,
Macleod
Und dann lassen die Geräte sich sauber in eine Domain aufnehmen?
Bei einer Aufnahme des Clients in eine Domain ist es egal welche lokale SID der Rechner hat, beim Domain Join bekommt der Rechner sowieso eine neue eindeutige Computer-SID in der Domain zugewiesen.
Gruß catrell
Gruß catrell
Zitat von @catrell:
Bei einer Aufnahme des Clients in eine Domain ist es egal welche lokale SID der Rechner hat, beim Domain Join bekommt der Rechner sowieso eine neue eindeutige Computer-SID in der Domain zugewiesen.
Gruß catrell
Bei einer Aufnahme des Clients in eine Domain ist es egal welche lokale SID der Rechner hat, beim Domain Join bekommt der Rechner sowieso eine neue eindeutige Computer-SID in der Domain zugewiesen.
Gruß catrell
Diese Aussage würde Sysprep ja ad absurdum führen.
Ich kann mir nicht vorstellen das dies stimmt!
Nein, bei Umgebungen ohne Domain und beim Klonen von DCs/WSUS macht Sysprep natürlich absolut Sinn und sollte mandatory sein.
Hier darfst du dazu auch gerne lesen
The Machine SID Duplication Myth (and Why Sysprep Matters) / MarkRussinovich
Ich kann mir nicht vorstellen das dies stimmt!
Dann vergleiche mal die SID des Computers auf dem DC im AD, und des Clients vor und nach dem Join 😉, dann hast du es schwarz auf weiß wenn du es mir nicht glaubst.Hier darfst du dazu auch gerne lesen
The Machine SID Duplication Myth (and Why Sysprep Matters) / MarkRussinovich
Zitat von @catrell:
Hier darfst du dazu auch gerne lesen
The Machine SID Duplication Myth (and Why Sysprep Matters)
Hier darfst du dazu auch gerne lesen
The Machine SID Duplication Myth (and Why Sysprep Matters)
Was soll ich hier lesen? Das ist ne Frage ohne Antwort.
Mich würden mehr Antworten von anderen Forenteilnehmern zu dem Thema interessieren.
Der eigentliche Beitrag ist nur "eingeklappt", hier der ganze:
https://techcommunity.microsoft.com/blog/Windows-Blog-Archive/the-machin ...
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/u ...
https://techcommunity.microsoft.com/blog/Windows-Blog-Archive/the-machin ...
...
So is having multiple computers with the same machine SID a problem? The only way it would be is if Windows ever references the machine SIDs of other computers. For example, if when you connected to a remote system, the local machine SID was transmitted to the remote one and used in permissions checks, duplicate SIDs would pose a security problem because the remote system wouldn’t be able to distinguish the SID of the inbound remote account from a local account with the same SID (where the SIDs of both accounts have the same machine SID as their base and the same RID). However as we reviewed, Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.
...
So is having multiple computers with the same machine SID a problem? The only way it would be is if Windows ever references the machine SIDs of other computers. For example, if when you connected to a remote system, the local machine SID was transmitted to the remote one and used in permissions checks, duplicate SIDs would pose a security problem because the remote system wouldn’t be able to distinguish the SID of the inbound remote account from a local account with the same SID (where the SIDs of both accounts have the same machine SID as their base and the same RID). However as we reviewed, Windows doesn’t allow you to authenticate to another computer using an account known only to the local computer. Instead, you have to specify credentials for either an account local to the remote system or to a Domain account for a Domain the remote computer trusts. The remote computer retrieves the SIDs for a local account from its own Security Accounts Database (SAM) and for a Domain account from the Active Directory database on a Domain Controller (DC). The remote computer never references the machine SID of the connecting computer.
...
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/u ...
The system generates the SID that identifies a particular account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can never be used again to identify another user or group.
Und Lizenzierung ist dann egal oder wie?
Das Problem fällt dem anderen Kollegen mit seinen geclonten VMs ja jetzt schon auf die Füße.
Das Problem fällt dem anderen Kollegen mit seinen geclonten VMs ja jetzt schon auf die Füße.
