Bei diesem Artikel handelt es sich um einen Bericht über einen kürzlich zugetragenen realen Fall.
Im Rahmen eines Kundenprojekts wurden unter anderem neue PCs von einem namhaften Hersteller angeschafft. Der Name wird bewusst nicht genannt, um niemanden unnötig in Misskredit zu bringen, zumal der Autor bislang keine Probleme mit dem Hersteller hatte. Salopp könnte man ausdrücken das irgendwann immer das erste Mal ist.
Ein wenig Hintergrund
Pro Windows-Netzwerk darf jede SID nur einmal vorkommen. Die SID dient dazu, einen Computer, Benutzer oder eine Gruppe eindeutig zu identifizieren. In diesem Fall ging es um die Computer-SID.
Das eigentliche Problem
Hat man nun mehrere Computer mit der gleichen SID im Netzwerk, so kann das Active Directory nicht eindeutig feststellen, ob der Computer oder der dort angemeldete Benutzer nun zugriffsberechtigt ist oder nicht.
Nahezu ein Klassiker, wie man indirekt feststellen kann, ob man mehrere gleiche Computer-SIDs im Netzwerk hat besteht in einem Blick in den WSUS, sofern man Diesen einsetzt.
Dort zeigt sich dann ein wechselndes Bild. Man sieht niemals alle vorhandenen Computer gleichzeitig und kann beobachten, wie z.B. PC01 nach einer Aktualisierung der Ansicht zu PC02 wird.
SIDs auslesen
Im Paket der PsTools gibt es ein kleines Programm namens PsGetSid, mit dessen Hilfe man die Computer- oder auch Benutzer-SID auslesen kann. Startet man das Tool ohne weitere Parameter wird immer die lokale Computer-SID ausgegeben.
Wie kam es (vermutlich) dazu
Da dem Autor die genauen Abläufe beim Hersteller nicht bekannt sind, kann an dieser Stelle nur gemutmaßt werden.
Vermutlich wurde bei der Erstellung des Master-Abbilds mittels Sysprep schlicht vergessen, den Haken bei “Verallgemeinern” zu setzen.
Folglich hat das Master-Abbild, nach wie vor eine eindeutige SID die dann z.B. auf eine komplette Serie oder Charge von Computern übertragen wird. Auf diese Weise kann man ganz schnell 100 oder mehr Computer mit der gleichen SID erhalten. Fügt man dann mehrere dieser Maschinen dem gleichen Netzwerk hinzu kommt es zu Problemen.
Mögliche Lösungswege
Die sauberste Lösung besteht darin, die betroffenen Systeme sofort Offline zu nehmen, vollständig neu von einem reinen, nicht gebrandeten OEM-Medium zu installieren, da in einem solchen Fall mitunter die Abbilder auf Recovery-Medien (CD, DVD, Partition) ebenfalls die “falsche” SID enthalten könnten.
Alternativ kann man versuchen, nachträglich Sysprep auszuführen und eine Verallgemeinerung bzw. neue, eindeutige SID generieren zu lassen. Dieser Weg ist allerdings in Abhängigkeit der möglicherweise bereits installierten Software nicht möglich. Windows und Office haben damit erfahrungsgemäß kein Problem. Ob man das allerdings auf jede andere Anwendung umsetzen kann, muss von Fall zu Fall geklärt werden.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
bei geklonte pcs die nicht alle im wsus auftauchen hilft dieser script.
wsus clients haben ein eigener id der auch eindeutig sein soll.
@echo off
REM Script to generate a new SusClientID. Use it if you have problems
REM with machines not appearing on the WSUS server. Mostly the problem
REM is based on duplicate SusClientIDs and can be resolved creating a new one.
echo.
echo WSUS – Generate new SusClientID
echo ===============================
echo.
echo Stop services…
net stop wuauserv >NUl 2>&1
net stop bits >NUl 2>&1
echo.
echo Delete registry keys…
reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v PingID /f >NUl 2>&1
reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v AccountDomainSid /f >NUl 2>&1
reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate” /v SusClientId /f >NUl 2>&1
echo.
echo Start services…
net start wuauserv >NUl 2>&1
echo.
echo Report to WSUS server…
wuauclt.exe /resetauthorization /detectnow >NUl 2>&1
echo.
echo Finished!
So kann man es auch machen.
In meinem Fall hat auch geholfen, die betroffenen Computer aus dem WSUS zu löschen.
Nachdem entweder sysprep noch mal mit Verallgemeinern durch ist oder man die Systeme neu installiert hat, wieder in die Domäne und damit auch wieder im WSUS.
Hallo,
mich würden die konkreten Probleme interessieren die du beobachtet hast. Ich untersuche derzeit Fehler in dieser Richtung und stelle fest, dass keine Probleme mit An/Abmelden, Rechten etc. gibt wenn ich z.B. dieses Szenarion habe:
W2008R2 Domäne
2xW7 mit selber SID in der Domäne
Anmeldung nur über Domänen-Benutzerkonten
Danke
Bob
Das ist teilweise schon unter “Das eigentliche Problem” angedeutet.
Mir sind solche Szenarien leider schon ein paar Mal begegnet, die Probleme gingen von “Banalitäten” wie kein Erscheinen der Computer mit doppelter SID im WSUS bis hin zu “Anmeldung geht nicht”.
Achtung bei der Verwendung von PsSid!
Das Tool zeigt nicht die ganze Computer SID an.
Besser per Powershell die SID auslesen.
Die User SID’s sind jedoch OK.
Für Domänen-Computer lautet der entsprechende Powershell-Befehl:
Get-ADComputer -Filter "name -eq '%computername%'" -Properties sid | select name, sidQuelle:
TechNet: Weekend Scripter: Use PowerShell to Find Computers SIDs in AD DS
Hallo,
habe genau das gleiche Problem…. 1x Server 2008 R2 installiert, Vorlage aus VMware exportiert und 3x neu importiert. Jetzt der Mist mit dem WSUS, daher hab ich das hier gefunden.
Frage. Von den insg. vier Win2008R2 sind 2 DC.
Kann ich sysprep “direkt” darauf laufen lassen oder muss ich erst
– 2. DC downgraden
– Aus Domain entfernen
– sysprep mit “Verallgemeinern”
– wieder in Domain aufnehmen
– wieder zum DC upgraden
und das dann ebenso mit dem 1. DC..? (nach Umstellen aller Master-Geschichten auf den dann schon geänderten, klar)
Ebenso auf dem Fileserver, keine weitere Software drauf.
Den 4. Server, den Terminalserver, würde ich dann so lassen, da darauf als einziger weitere Software installiert ist, die da vermutlich allergisch drauf reagiert.
Hab ich was vergessen..?
Danke erstmal für den Post hier!
Hallo Michael,
könnte so gehen, hab’ ich allerdings mit Servern geschweigendenn DCs noch nie versucht.
Evtl. das Ganze erstmal in einer abgeschotteten Testumgebung durchspielen.
Im Grunde müssen alle betroffenen System einmal aus der Domäne raus, eine neue SID erhalten und wieder in die Domäne rein.
Kurze Rückantwort, hat geklappt.
Ich habe 2 DC Server 2008 R2 in meiner Domain, beide gleiche SID, nennen wir sie DC1 und DC2.
Aufgefallen ist mir die Problematik mit den selben SIDs durch das “Wechselspielchen” im WSUS, daher hab ich auch die Seite hier gefunden.
Ich Depp hab einfach nach dem “bequemen” Rückspielen meiner OVA-Vorlage in VMware das sysprep nie gemacht. Das wird mir nicht mehr passieren. Versprochen. ;D
Folgendes nach Anleitungen MS Technet und Abgleich mit weiteren Informationen (google) im laufenden Betrieb (10:00 Uhr) gemacht.
DC1 ist überall Primary DNS,
DC2 ist überall Secondary DNS.
Vorgehen:
– mit
Dsquery server –hasfsmo schema
Dsquery server –hasfsmo name
Dsquery server –hasfsmo rid
Dsquery server –hasfsmo pdc
Dsquery server –hasfsmo infr
geprüft, dass alle Schemata und Rollen auf dem DC1 liegen, der DC2 im klassischen Sinne also wirklich “nur” BDC ist und der DC1 PDC.
– DC2 mit dcpromo zum Member-Server degradiert, neues lokals Admin-Passwort angegeben (Frage kommt im Rahmen von dcpromo automatisch), Reboot
– Prüfung auf DC1 mit o.g. dsquery, dass der DC2 nirgends mehr auftaucht.
– DC2 aus der Domain genommen in eine Workgroup, Reboot
– mit einem Tool wie ProduKey den Windows-Key auslesen und dokumentieren, wenn man ihn nicht sauber dokumentiert hat ;D
– sysprep gestartet auf DC2, OOBE und Haken bei “Verallgemeinern” reingesetzt (allein das sollte automagisch schon den Server aus der Domain nehmen, sicherheitshalber aber zuvor manuell gemacht), dann SHUTDOWN (NICHT reboot, überall gelesen), dann wieder angestellt
– Windows-Key neu eingegeben und aktiviert
– Feste IP wie vorher (wichtig, steht ja noch in diversen Rechnern damit als DNS drin!) vergeben, durch das OOBE wird das wieder auf DHCP gesetzt
– PC-Namen wieder auf DC2 gesetzt (steht durchs Verallgemeinern der übliche post-install-Mist drin), Reboot
– DC2 wieder zum Member-Server gemacht, Reboot
– DC2 via dcpromo wieder zum DC in einer vorhandenen Domain gemacht
– automagischer Abgleich aller Daten; AD- und DNS-Rollen waren ja noch installiert, ebenso wie VMware Tools. Sonst da nix drauf, da DC.
– Reboot, fertig. Kontrollieren in den Windows-Logs, ob alles sauber synchronisiert wurde.
–> wenn mans “sauber” macht und prüft, dass alle entsprechenden Einträge nach dem Entfernen vom DC2 aus der Domain gelöscht werden gibts auch keine Probleme beim Wiedereinbinden. Zumindest bei mir nicht.
Um das gleiche mit dem DC1 zu machen müssen also jetzt erst Schemata etc. (dsquery s.o., da muss dann alles auf DC2 stehen) umstellen und dann das gleiche Spielchen.
Wichtig: Der DC2 sollte dann zumindest als Secondary, besser wohl Primary DNS-Server in allen Member-Servern angegeben sein. Ansonsten einfach ein Zeitfenster wählen, wo der “nicht unbedingt benötigt” wird… sollte aber auch so gehen.
Wenn fertig Schemata etc. je nach Geschmack wieder rübertransferieren oder auf dem DC2 lassen.
Vielleicht hilfts ja wem… alles ohne Gewähr. ;D
Hallo Michael,
danke für das Feedback. Klingt gut soweit.
interessant wäre doch das komplette ps – script zu sehen und nicht nur einen teil.