12
Loop: Sicherheitsdatenbank auf Server enthält kein Computerkonto für diese Arbeitsvertrauensstellung
Moin,
ich habe einen Client der in unserer Windows-Domäne der mir ein wenig Kopfschmerzen bereitet.
Der Client wurde von einem Image erstellt welches bereits in der Domäne ist, also wird nur noch Domäne raus, Host umbenennen, Client wieder rein. Funktioniert i.d.R. super, neues PC-Konto wird erstellt, alles gut.
Bei diesem Client hats irgendwie nicht geklappt. Der Client war in der Domäne und ein User hat damit auch gearbeitet.
Nun war der Client einige Zeit aus und wurde nun wieder in Betrieb genommen.
Siehe da Fehlermeldung aus dem Titel taucht auf.
In der Domäne nachgeschaut, kein Konto vorhanden.
Nun habe ich den Client mehrmals aus der Domäne raus und wieder in die Domäne gehoben, was jedes mal problemlos funktioniert, es wird jedoch kein Computerkonto erstellt.
Wenn ich manuell eines erstelle, also RK-> Neu mit dem jeweiligen Hostnamen, wird dieser sogar deaktiviert sobald ich den PC aus der Domäne nehme, jedoch nicht reaktiviert wenn ich Ihn wieder rein hebe.
So langsam bin ich mit meinem Latein am Ende. Der Client hat Netzwerk und meldet sich sauber am DNS an. Der DC hat auch kein Problem da er einen frischen Client vorhin sauber aufgenommen hat.
Zwischendurch war die Anmeldung am Client mit dem Domain-Admin möglich, nach Bentzerwechsel und dem Anmeldeversuch eines neuen Users (kein lokales Profil), erscheint die Meldung erneut und das Spiel geht von vorne los.
Kann mir jemand sagen ob es einen weg gibt den Client manuell "richtig" am Server anzumelden?
Danke im Voraus
ich habe einen Client der in unserer Windows-Domäne der mir ein wenig Kopfschmerzen bereitet.
Der Client wurde von einem Image erstellt welches bereits in der Domäne ist, also wird nur noch Domäne raus, Host umbenennen, Client wieder rein. Funktioniert i.d.R. super, neues PC-Konto wird erstellt, alles gut.
Bei diesem Client hats irgendwie nicht geklappt. Der Client war in der Domäne und ein User hat damit auch gearbeitet.
Nun war der Client einige Zeit aus und wurde nun wieder in Betrieb genommen.
Siehe da Fehlermeldung aus dem Titel taucht auf.
In der Domäne nachgeschaut, kein Konto vorhanden.
Nun habe ich den Client mehrmals aus der Domäne raus und wieder in die Domäne gehoben, was jedes mal problemlos funktioniert, es wird jedoch kein Computerkonto erstellt.
Wenn ich manuell eines erstelle, also RK-> Neu mit dem jeweiligen Hostnamen, wird dieser sogar deaktiviert sobald ich den PC aus der Domäne nehme, jedoch nicht reaktiviert wenn ich Ihn wieder rein hebe.
So langsam bin ich mit meinem Latein am Ende. Der Client hat Netzwerk und meldet sich sauber am DNS an. Der DC hat auch kein Problem da er einen frischen Client vorhin sauber aufgenommen hat.
Zwischendurch war die Anmeldung am Client mit dem Domain-Admin möglich, nach Bentzerwechsel und dem Anmeldeversuch eines neuen Users (kein lokales Profil), erscheint die Meldung erneut und das Spiel geht von vorne los.
Kann mir jemand sagen ob es einen weg gibt den Client manuell "richtig" am Server anzumelden?
Danke im Voraus
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: 4159471083
Url: https://administrator.de/contentid/4159471083
Ausgedruckt am: 08.11.2024 um 11:11 Uhr
12 Kommentare
Neuester Kommentar
Moin. Du wiedersprichst dir selbst:
Wenn es problemlos funktioniert, dann hast du auch ein Computerkonto. Kann es sein, dass du das Konto einfach nicht siehst, da du in der falschen OU nachschaust bzw. die OU nicht händisch aktualisierst? Die AD Ansicht aktualisiert sich nicht automatisch.
Gruß
Doskias
Zitat von @flotaut:
Nun habe ich den Client mehrmals aus der Domäne raus und wieder in die Domäne gehoben, was jedes mal problemlos funktioniert, es wird jedoch kein Computerkonto erstellt.
Nun habe ich den Client mehrmals aus der Domäne raus und wieder in die Domäne gehoben, was jedes mal problemlos funktioniert, es wird jedoch kein Computerkonto erstellt.
Wenn es problemlos funktioniert, dann hast du auch ein Computerkonto. Kann es sein, dass du das Konto einfach nicht siehst, da du in der falschen OU nachschaust bzw. die OU nicht händisch aktualisierst? Die AD Ansicht aktualisiert sich nicht automatisch.
Nun war der Client einige Zeit aus und wurde nun wieder in Betrieb genommen.
Klingt für mich fast so, als gäbe es ein Skript, welches alte Geräte, die lange nicht angemeldet waren aus dem AD löscht. Kann das sein?Kann mir jemand sagen ob es einen weg gibt den Client manuell "richtig" am Server anzumelden?
Wenn du ihn der Domäne hinzufügst und eine Erfolgsmeldung hat, dann hat alles funktioniert. Irgendwo muss dein Client dann sein. Das ist der richtige Weg.Gruß
Doskias
Wenn du mehrere Domänencontroller hast, musst du auch erst replizieren, um das Konto auf allen DCs zu sehen. Das passiert in der Regel ohne Zusatzkonfiguration erst nach 30 Minuten, ausser du verkürzt über Sites and Services das Intervall, oder startest die Replikation manuell.
Und wie der Kollege bereits geschrieben hat, sobald du "Willkommen in der Domäne xy" liest, ist das der richtige Weg.
Lösche erstmal alle Konten, die du eventuell versehentlich angelegt hast, aus der Domäne.
Dann repliziere manuell die Einstellungen auf alle DCs die du so im Einsatz hast.
Dann führst du einmalig die Anmeldung an der Domäne aus.
Dann replizierst du nochmal.
Und wie der Kollege bereits geschrieben hat, sobald du "Willkommen in der Domäne xy" liest, ist das der richtige Weg.
Lösche erstmal alle Konten, die du eventuell versehentlich angelegt hast, aus der Domäne.
Dann repliziere manuell die Einstellungen auf alle DCs die du so im Einsatz hast.
Dann führst du einmalig die Anmeldung an der Domäne aus.
Dann replizierst du nochmal.
Moin,
Wer hat das nicht.
Seltsames Vorgehen aber wenn es den funktioniert ...
Also hat es geklappt.
Dann war er >30 Tage aus. Das Verhalten ist normal. Das Computer-Passwort ist abgelaufen.
Wie hast Du nachgeschaut? In der OU, in der Du ihn vermutest? Oder hast Du die Suche bemüht?
Wenn es geklappt hat, dann wurde auch ein Computerkonto erstellt oder es wurde ein schon vorhandenes benutzt. Sonst gäbe es beim Join eine Fehlermeldung.
Was machst Du genau? RK?
Mein Tipp für das nächste Mal: Nutze den Powershell-Befehl
In dem vorliegenden Fall: Lösche den Computer aus dem AD (Computerkonto suchen). Entferne den Computer aus der Domain offline. Erstelle ein neues Computerkonto in der gewünschten OU in Active Directory - Benutzer und Computer. Dann den Computer wieder in die Domain heben.
hth
Erik
P.S.: Von dem "Tipp" die Replikation händisch anzustoßen, rate ich ausdrücklich ab. Das kann bei größeren Domains schon recht lange dauern, da immer der gesamte Inhalt des AD repliziert wird und nicht wie bei einer regelmäßigen Replikation nur die Differenz.
Zitat von @flotaut:
ich habe einen Client der in unserer Windows-Domäne der mir ein wenig Kopfschmerzen bereitet.
ich habe einen Client der in unserer Windows-Domäne der mir ein wenig Kopfschmerzen bereitet.
Wer hat das nicht.
Der Client wurde von einem Image erstellt welches bereits in der Domäne ist, also wird nur noch Domäne raus, Host umbenennen, Client wieder rein. Funktioniert i.d.R. super, neues PC-Konto wird erstellt, alles gut.
Seltsames Vorgehen aber wenn es den funktioniert ...
Bei diesem Client hats irgendwie nicht geklappt. Der Client war in der Domäne und ein User hat damit auch gearbeitet.
Also hat es geklappt.
Nun war der Client einige Zeit aus und wurde nun wieder in Betrieb genommen.
Siehe da Fehlermeldung aus dem Titel taucht auf.
Siehe da Fehlermeldung aus dem Titel taucht auf.
Dann war er >30 Tage aus. Das Verhalten ist normal. Das Computer-Passwort ist abgelaufen.
In der Domäne nachgeschaut, kein Konto vorhanden.
Wie hast Du nachgeschaut? In der OU, in der Du ihn vermutest? Oder hast Du die Suche bemüht?
Nun habe ich den Client mehrmals aus der Domäne raus und wieder in die Domäne gehoben, was jedes mal problemlos funktioniert, es wird jedoch kein Computerkonto erstellt.
Wenn es geklappt hat, dann wurde auch ein Computerkonto erstellt oder es wurde ein schon vorhandenes benutzt. Sonst gäbe es beim Join eine Fehlermeldung.
Wenn ich manuell eines erstelle, also RK-> Neu mit dem jeweiligen Hostnamen, wird dieser sogar deaktiviert sobald ich den PC aus der Domäne nehme, jedoch nicht reaktiviert wenn ich Ihn wieder rein hebe.
Was machst Du genau? RK?
Mein Tipp für das nächste Mal: Nutze den Powershell-Befehl
Reset-ComputerMachinePasswordIn dem vorliegenden Fall: Lösche den Computer aus dem AD (Computerkonto suchen). Entferne den Computer aus der Domain offline. Erstelle ein neues Computerkonto in der gewünschten OU in Active Directory - Benutzer und Computer. Dann den Computer wieder in die Domain heben.
hth
Erik
P.S.: Von dem "Tipp" die Replikation händisch anzustoßen, rate ich ausdrücklich ab. Das kann bei größeren Domains schon recht lange dauern, da immer der gesamte Inhalt des AD repliziert wird und nicht wie bei einer regelmäßigen Replikation nur die Differenz.
Hallo
Der Computer wurde gecloned so wie ich das sehe. Und das image wurde zuvor nicht mit sysprep vorbereitet. Also existieren 2 Computer mit der gleichen SID, wenn auch unterschiedlichem Namen in der Domäne.
Computer aus der Domäne nehmen, mit SIDchange (https://www.stratesave.com/html/sidchg.html) dem Computer eine neue SID und anderen Namen verpassen, und wieder rein in die Domäne.
Hatten vor 4 Wochen auch so einen Fall mit einem Reservecomputer bei einer Firma der gecloned und umbenannt war. Der eine hat immer den anderen Computer weggeschossen, je nachdem an welchem man das Reset-ComputerMachinePassword zuletzt ausgeführt hat.
MfG,
MacLeod
Der Computer wurde gecloned so wie ich das sehe. Und das image wurde zuvor nicht mit sysprep vorbereitet. Also existieren 2 Computer mit der gleichen SID, wenn auch unterschiedlichem Namen in der Domäne.
Computer aus der Domäne nehmen, mit SIDchange (https://www.stratesave.com/html/sidchg.html) dem Computer eine neue SID und anderen Namen verpassen, und wieder rein in die Domäne.
Hatten vor 4 Wochen auch so einen Fall mit einem Reservecomputer bei einer Firma der gecloned und umbenannt war. Der eine hat immer den anderen Computer weggeschossen, je nachdem an welchem man das Reset-ComputerMachinePassword zuletzt ausgeführt hat.
MfG,
MacLeod
Kann es eventuell sein das wenn du deinen PC in die Domäne aufnimmst
irgendwo anders ein PC aus der Domäne rausfliegt?
Ich mein damit das du, ggf unterbewust, versuchst den selben Hostnamen
2 mal zu vergeben ? Denn das geht ebenfalls nicht. Es dürfen keine 2 Systeme
mit dem selben Hostnamen exsistieren. Wenn du jetzt versuchst einen zweiten PC
mit dem selben/gleichen Hostnamen in die Domain aufnimmst so bekommst du wenn alles
OK was die Meldung "Wilkommen in der Domäne BLA.BLUBB" und dann kannst du arbeiten
bzw. den PC verwenden. Wenn jetzt jemand den anderen PC verwenden will der vorher ebenfalls
den selben Hostnamen hatte dann bekommt dieser die Meldung mit der Sicherheitsdatenbank
und Computerkonto ebenfalls da der neue PC ( der wo später hinzugefügt wird ) sozusagen die
Einstellungen "überschreibt".
Wenn man jetzt einen Kollegen hat der hier nicht nachschaut bei so einer Meldung bzw. die Kollegen fragt
und die Kiste dann einfach wieder in die Domäne aufnimmt dann ist so ein Fehler vorprogrammiert.
Ist schon öfters vorgekommen, ich spreche da aus Erfahrung gerade wenn die Hostnamen etwas komplizierter
sind als PC-01 / 02 / 03 etc.
Ein Tipp von mir:
Wenn du ein System suchst und es nicht findest dann bemühe am besten die Suche des AD´s oder die Suche
des ActiveDirectrory Admin Center und zwar am besten so weit oben wie geht. Je nach dem wie schnell das
Repliziert wird kann es da u.U. mal Probleme geben und die Suche ist das m.M.n. der schnellste und beste weg.
Und was der Kollege MacLeod sagt stimmt natürlich auch. Wenn zwei Systeme die gleiche SID haben, welche bei der Installation erstellt wird, dann gibt das hier auch nur Probleme. Windows arbeitet INTERN mit der SID. Der AD versucht im Hintergrund dafür zu sorgen das es keine gleichen SID´s und Hostnamen ( Computerkontennamen ) gibt denn wenn das so wäre würde dies ein Sicherheitsproblem erzeugen. Deswegen immer ein Sysprep am Ende der Imageerstellung machen und das ganze mit generalize speichern bzw. beenden.
irgendwo anders ein PC aus der Domäne rausfliegt?
Ich mein damit das du, ggf unterbewust, versuchst den selben Hostnamen
2 mal zu vergeben ? Denn das geht ebenfalls nicht. Es dürfen keine 2 Systeme
mit dem selben Hostnamen exsistieren. Wenn du jetzt versuchst einen zweiten PC
mit dem selben/gleichen Hostnamen in die Domain aufnimmst so bekommst du wenn alles
OK was die Meldung "Wilkommen in der Domäne BLA.BLUBB" und dann kannst du arbeiten
bzw. den PC verwenden. Wenn jetzt jemand den anderen PC verwenden will der vorher ebenfalls
den selben Hostnamen hatte dann bekommt dieser die Meldung mit der Sicherheitsdatenbank
und Computerkonto ebenfalls da der neue PC ( der wo später hinzugefügt wird ) sozusagen die
Einstellungen "überschreibt".
Wenn man jetzt einen Kollegen hat der hier nicht nachschaut bei so einer Meldung bzw. die Kollegen fragt
und die Kiste dann einfach wieder in die Domäne aufnimmt dann ist so ein Fehler vorprogrammiert.
Ist schon öfters vorgekommen, ich spreche da aus Erfahrung gerade wenn die Hostnamen etwas komplizierter
sind als PC-01 / 02 / 03 etc.
Ein Tipp von mir:
Wenn du ein System suchst und es nicht findest dann bemühe am besten die Suche des AD´s oder die Suche
des ActiveDirectrory Admin Center und zwar am besten so weit oben wie geht. Je nach dem wie schnell das
Repliziert wird kann es da u.U. mal Probleme geben und die Suche ist das m.M.n. der schnellste und beste weg.
Und was der Kollege MacLeod sagt stimmt natürlich auch. Wenn zwei Systeme die gleiche SID haben, welche bei der Installation erstellt wird, dann gibt das hier auch nur Probleme. Windows arbeitet INTERN mit der SID. Der AD versucht im Hintergrund dafür zu sorgen das es keine gleichen SID´s und Hostnamen ( Computerkontennamen ) gibt denn wenn das so wäre würde dies ein Sicherheitsproblem erzeugen. Deswegen immer ein Sysprep am Ende der Imageerstellung machen und das ganze mit generalize speichern bzw. beenden.
Moin,
Nein, das stimmt nicht. Es ist und bleibt ein Mythos. Die lokale SID der Maschine spielt keine Rolle in der Domain. Wäre ja auch schlimm, wenn sich die Domain auf eine Information, die vom lokalen Gerät gesendet wird, verlassen würde. Dann hätten wir einen nicht beherrschbaren Angriffsvektor. Dass das so ist, hat Mark Russinowich in seinem Artikel The Machine SID Duplication Myth (and Why Sysprep Matters) schon 2009 beschrieben. Lesen und verstehen.
Liebe Grüße
Erik
Zitat von @Mr-Gustav:
Und was der Kollege MacLeod sagt stimmt natürlich auch. Wenn zwei Systeme die gleiche SID haben, welche bei der Installation erstellt wird, dann gibt das hier auch nur Probleme. Windows arbeitet INTERN mit der SID. Der AD versucht im Hintergrund dafür zu sorgen das es keine gleichen SID´s und Hostnamen ( Computerkontennamen ) gibt denn wenn das so wäre würde dies ein Sicherheitsproblem erzeugen. Deswegen immer ein Sysprep am Ende der Imageerstellung machen und das ganze mit generalize speichern bzw. beenden.
Und was der Kollege MacLeod sagt stimmt natürlich auch. Wenn zwei Systeme die gleiche SID haben, welche bei der Installation erstellt wird, dann gibt das hier auch nur Probleme. Windows arbeitet INTERN mit der SID. Der AD versucht im Hintergrund dafür zu sorgen das es keine gleichen SID´s und Hostnamen ( Computerkontennamen ) gibt denn wenn das so wäre würde dies ein Sicherheitsproblem erzeugen. Deswegen immer ein Sysprep am Ende der Imageerstellung machen und das ganze mit generalize speichern bzw. beenden.
Nein, das stimmt nicht. Es ist und bleibt ein Mythos. Die lokale SID der Maschine spielt keine Rolle in der Domain. Wäre ja auch schlimm, wenn sich die Domain auf eine Information, die vom lokalen Gerät gesendet wird, verlassen würde. Dann hätten wir einen nicht beherrschbaren Angriffsvektor. Dass das so ist, hat Mark Russinowich in seinem Artikel The Machine SID Duplication Myth (and Why Sysprep Matters) schon 2009 beschrieben. Lesen und verstehen.
Liebe Grüße
Erik
Seltsam nur, daß dieses Problem schon seit W2K existiert und schon immer so behoben wurde. Ebenfalls seltsam, daß sich das Problem mit 2 geclonten PCs sofort replizieren lässt. Und noch gruseliger ist es, daß Firmen wie stratesave nach der Abkündigung von NewSID ihre eigene Software geschrieben haben und damit vermutlich schon zigtausend Admins geholfen haben solche Probleme zu lösen. Einzig durch das konsequente Ändern der SID 
"...will still require cloned systems to be made unique with Sysprep"
ist das Schlusswort von Mark im Jahr 2009 (!) Darauf läuft der ganze Artikel hinaus.
Und hat man das vergessen hilft einem eben SIDchange zum reparieren.
MfG,
MacLeod
"...will still require cloned systems to be made unique with Sysprep"
ist das Schlusswort von Mark im Jahr 2009 (!) Darauf läuft der ganze Artikel hinaus.
Und hat man das vergessen hilft einem eben SIDchange zum reparieren.
MfG,
MacLeod
Moin,
Nein. Genau das beschreibt der Artikel. Es ist nicht die SID das Problem.
Man muss schon alles lesen: "Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep" (zitiert nach https://techcommunity.microsoft.com/t5/windows-blog-archive/the-machine- ..., Hervorhebung von mir).
Was sysprep nicht immer tut, wie man auch in dem von mir zitierten Artikel auch beschreibt: "I wrote NewSID in 1997 (its original name was NTSID) because the only tool available at the time for changing machine SIDs was the Microsoft Sysprep tool, and Sysprep doesn’t support changing the SIDs of computers that have applications installed." (a.a.O., Hervorhebung von mir) Genau deshalb hat der Autor mal ein Tool geschrieben, das das tut. Und weil er eben festgestellt hat, dass sein Tool überflüssig ist, hat er den Artikel geschrieben, in dem er das Tool sysprep empfiehlt, das eben nicht immer die SID ändert.
BTW: Die Informationen stammen von Microsoft selbst und wurden an der hier angegebenen Stelle noch einmal 2019 publiziert. Mark Russinovich ist langjähriger Mitarbeiter (zur Zeit Technischer Direktor von MS Azure) und trägt den Titel Microsoft MVP, die höchste Auszeichnung, die Microsoft vergibt. Daher halte ich die in seinem Artikel vorhandene Information für zuverlässig.
Liebe Grüße
Erik
Zitat von @MacLeod:
Seltsam nur, daß dieses Problem schon seit W2K existiert und schon immer so behoben wurde. Ebenfalls seltsam, daß sich das Problem mit 2 geclonten PCs sofort replizieren lässt. Und noch gruseliger ist es, daß Firmen wie stratesave nach der Abkündigung von NewSID ihre eigene Software geschrieben haben und damit vermutlich schon zigtausend Admins geholfen haben solche Probleme zu lösen. Einzig durch das konsequente Ändern der SID
Seltsam nur, daß dieses Problem schon seit W2K existiert und schon immer so behoben wurde. Ebenfalls seltsam, daß sich das Problem mit 2 geclonten PCs sofort replizieren lässt. Und noch gruseliger ist es, daß Firmen wie stratesave nach der Abkündigung von NewSID ihre eigene Software geschrieben haben und damit vermutlich schon zigtausend Admins geholfen haben solche Probleme zu lösen. Einzig durch das konsequente Ändern der SID
Nein. Genau das beschreibt der Artikel. Es ist nicht die SID das Problem.
"...will still require cloned systems to be made unique with Sysprep"
ist das Schlusswort von Mark im Jahr 2009 (!) Darauf läuft der ganze Artikel hinaus.
ist das Schlusswort von Mark im Jahr 2009 (!) Darauf läuft der ganze Artikel hinaus.
Man muss schon alles lesen: "Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep" (zitiert nach https://techcommunity.microsoft.com/t5/windows-blog-archive/the-machine- ..., Hervorhebung von mir).
Und hat man das vergessen hilft einem eben SIDchange zum reparieren.
Was sysprep nicht immer tut, wie man auch in dem von mir zitierten Artikel auch beschreibt: "I wrote NewSID in 1997 (its original name was NTSID) because the only tool available at the time for changing machine SIDs was the Microsoft Sysprep tool, and Sysprep doesn’t support changing the SIDs of computers that have applications installed." (a.a.O., Hervorhebung von mir) Genau deshalb hat der Autor mal ein Tool geschrieben, das das tut. Und weil er eben festgestellt hat, dass sein Tool überflüssig ist, hat er den Artikel geschrieben, in dem er das Tool sysprep empfiehlt, das eben nicht immer die SID ändert.
BTW: Die Informationen stammen von Microsoft selbst und wurden an der hier angegebenen Stelle noch einmal 2019 publiziert. Mark Russinovich ist langjähriger Mitarbeiter (zur Zeit Technischer Direktor von MS Azure) und trägt den Titel Microsoft MVP, die höchste Auszeichnung, die Microsoft vergibt. Daher halte ich die in seinem Artikel vorhandene Information für zuverlässig.
Liebe Grüße
Erik
OK
So sei es. Und um der Diskussion wieder einen Sinn zu geben @enriko und nicht nur zu erklären, wo wir alle falsch liegen:
Wie sollte der TO sein Problem lösen? Ohne eine oder beide Maschinen zu plätten und mit sysprep bei Null anzufangen?
MfG,
MacLeod
So sei es. Und um der Diskussion wieder einen Sinn zu geben @enriko und nicht nur zu erklären, wo wir alle falsch liegen:
Wie sollte der TO sein Problem lösen? Ohne eine oder beide Maschinen zu plätten und mit sysprep bei Null anzufangen?
MfG,
MacLeod
Zitat von @MacLeod:
OK
So sei es. Und um der Diskussion wieder einen Sinn zu geben @enriko und nicht nur zu erklären, wo wir alle falsch liegen:
Wie sollte der TO sein Problem lösen? Ohne eine oder beide Maschinen zu plätten und mit sysprep bei Null anzufangen?
MfG,
MacLeod
OK
So sei es. Und um der Diskussion wieder einen Sinn zu geben @enriko und nicht nur zu erklären, wo wir alle falsch liegen:
Wie sollte der TO sein Problem lösen? Ohne eine oder beide Maschinen zu plätten und mit sysprep bei Null anzufangen?
MfG,
MacLeod
So, wie ich es beschrieben habe. Das funktioniert, wenn man es genau so macht:
Konto im AD suchen, löschen und neu machen.
Moin
Ich musste neulich auch mal lernen, dass dem nicht mehr so ist. Aus: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/m ...
Gruß
Doskias
Zitat von @erikro:
Dann war er >30 Tage aus. Das Verhalten ist normal. Das Computer-Passwort ist abgelaufen.
Dann war er >30 Tage aus. Das Verhalten ist normal. Das Computer-Passwort ist abgelaufen.
Ich musste neulich auch mal lernen, dass dem nicht mehr so ist. Aus: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/m ...
Question: If a workstation does not change its password, will it not be allowed to log onto the network?
Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.
So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.
Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.
So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.
Gruß
Doskias
Moin,
OK, das ist neu. Nur hatte ich das Phänomen gerade vor ein paar Tagen bei einem Reservenotebook aus dem Lager. Genau die Fehlermeldung (fehlende Vertrauensstellung), die nach dem Absetzen des o. g. Befehls weg war. DCs sind 2019. Hmmmmm.
Liebe Grüße
Erik
Zitat von @Doskias:
Moin
Ich musste neulich auch mal lernen, dass dem nicht mehr so ist. Aus: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/m ...
Moin
Zitat von @erikro:
Dann war er >30 Tage aus. Das Verhalten ist normal. Das Computer-Passwort ist abgelaufen.
Dann war er >30 Tage aus. Das Verhalten ist normal. Das Computer-Passwort ist abgelaufen.
Ich musste neulich auch mal lernen, dass dem nicht mehr so ist. Aus: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/m ...
OK, das ist neu. Nur hatte ich das Phänomen gerade vor ein paar Tagen bei einem Reservenotebook aus dem Lager. Genau die Fehlermeldung (fehlende Vertrauensstellung), die nach dem Absetzen des o. g. Befehls weg war. DCs sind 2019. Hmmmmm.
Liebe Grüße
Erik
