11
Windows Client aus Domäne entfernen und wieder anmelden - lokales Konto gelöscht?
Hallo zusammen,
ich habe in einem Windows Netzwerk mit einem DC Windows Server 2012 R2 das Problem an nur einem Windows 10 - Client, dass dieser sich nicht mehr mit seinem Domänenbenutzer anmelden kann.
Fehlermeldung:
"Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Laut Suchmaschine passiert der Fehler, wenn ein Rechner doppelt in eine Domäne gebracht wird oder wenn Datum/Uhrzeit am Client erheblich verstellt sind.
Dies ist in diesem Fall aber nicht so.
Der User berichtet, dass gestern Windows-Updates installiert wurden...
Wie auch immer:
Als Lösung behaupten die Suchmaschinenergebnisse, dass man sich mit einem lokalen Konto einloggen soll und dann den Rechner aus der Domäne entfernen soll, um danach wieder der Domäne neu beizutreten.
Frage:
Wird dadurch das aktuelle, lokale Domänenbenutzerkonto gelöscht und "leer" neu erstellt, oder ist das aktuell vorhandene, lokale Domänenkonto dann wieder weiter verwendbar?
Mir geht es um Dateien innerhalb des lokalen Benutzerkontos sowie die ganzen Einstellungen - gehen die dadurch verloren?
Gruß,
Colt
ich habe in einem Windows Netzwerk mit einem DC Windows Server 2012 R2 das Problem an nur einem Windows 10 - Client, dass dieser sich nicht mehr mit seinem Domänenbenutzer anmelden kann.
Fehlermeldung:
"Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Laut Suchmaschine passiert der Fehler, wenn ein Rechner doppelt in eine Domäne gebracht wird oder wenn Datum/Uhrzeit am Client erheblich verstellt sind.
Dies ist in diesem Fall aber nicht so.
Der User berichtet, dass gestern Windows-Updates installiert wurden...
Wie auch immer:
Als Lösung behaupten die Suchmaschinenergebnisse, dass man sich mit einem lokalen Konto einloggen soll und dann den Rechner aus der Domäne entfernen soll, um danach wieder der Domäne neu beizutreten.
Frage:
Wird dadurch das aktuelle, lokale Domänenbenutzerkonto gelöscht und "leer" neu erstellt, oder ist das aktuell vorhandene, lokale Domänenkonto dann wieder weiter verwendbar?
Mir geht es um Dateien innerhalb des lokalen Benutzerkontos sowie die ganzen Einstellungen - gehen die dadurch verloren?
Gruß,
Colt
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: 621154
Url: https://administrator.de/forum/windows-client-aus-domaene-entfernen-und-wieder-anmelden-lokales-konto-geloescht-621154.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
11 Kommentare
Neuester Kommentar
Als Lösung behaupten die Suchmaschinenergebnisse, dass man sich mit einem lokalen Konto einloggen soll und dann den Rechner aus der Domäne entfernen soll, um danach wieder der Domäne neu beizutreten.
Überflüssig, ein Reset-ComputerMachinePassword reicht in den meisten Fällen bei dieser Meldung ...Mir geht es um Dateien innerhalb des lokalen Benutzerkontos sowie die ganzen Einstellungen - gehen die dadurch verloren?
Nein.Frage:
Wird dadurch das aktuelle, lokale Domänenbenutzerkonto gelöscht und "leer" neu erstellt, oder ist das aktuell vorhandene, lokale Domänenkonto dann wieder weiter verwendbar?
Kein Problem das Profil lässt sich natürlich weiterverwenden:Wird dadurch das aktuelle, lokale Domänenbenutzerkonto gelöscht und "leer" neu erstellt, oder ist das aktuell vorhandene, lokale Domänenkonto dann wieder weiter verwendbar?
https://serverfault.com/questions/75154/how-to-join-domain-and-still-mai ...
https://www.forensit.com/domain-migration.html
Ein Rejoin ist aber wie oben gesagt mit dem o.g. Befehl in den wenigsten Fällen bei dieser Meldung nötig.
2
Moin,
dir fehlt's glaub ich ein bischen an Grundwissen...
1. Ein DomänenKONTO ist NIE lokal, sondern in der Domäne
2. Du schreibst ...konto, meinst aber Profil! Und das bleibt verwendbar, solange siche die SID des Users nicht ändert.
3. Evtl. solletst ihr mal über Roamingprofile und/oder Folder-Redirection nachdenken
lg,
Slainte
/EDIT: Typos...
dir fehlt's glaub ich ein bischen an Grundwissen...
lokale Domänenbenutzerkonto
1. Ein DomänenKONTO ist NIE lokal, sondern in der Domäne
2. Du schreibst ...konto, meinst aber Profil! Und das bleibt verwendbar, solange siche die SID des Users nicht ändert.
3. Evtl. solletst ihr mal über Roamingprofile und/oder Folder-Redirection nachdenken
Der User berichtet, dass gestern Windows-Updates installiert wurden
Keine Stuerung per GPO? Kein WSUS?? ufflg,
Slainte
/EDIT: Typos...
Hi,
E.
Zitat von @coltseavers:
Laut Suchmaschine passiert der Fehler, wenn ein Rechner doppelt in eine Domäne gebracht wird oder wenn Datum/Uhrzeit am Client erheblich verstellt sind.
Dies ist in diesem Fall aber nicht so.
Nicht selten ist es "bloß" eine zu große Differenz zwischen den Uhrzeiten von Client und Domaincontroller.Laut Suchmaschine passiert der Fehler, wenn ein Rechner doppelt in eine Domäne gebracht wird oder wenn Datum/Uhrzeit am Client erheblich verstellt sind.
Dies ist in diesem Fall aber nicht so.
E.
Zitat von @146189:
Moin window - vielen Dank für das Posten der Lösung!
Für Mitleser:
mit "TestComputerSecureChannel" kommt man wohl ebenfalls zum Ziel:
www.powershell.no/activedirectory/2017/02/08/ad-computer-repair-secure-channel.html
Inzwischen ist ein zweiter Rechner im gleichen Netzwerk betroffen, während alle anderen Rechner einwandfrei funktionieren.
Ursache war vermutlich, dass an beiden Rechnern das Update auf Version 2004 installiert wurde.
Beim nächsten Hochfahren dann traute der Server dem Client nicht mehr über den Weg.
Hat jemand einen Ratschlag, wie ich das Update installieren kann, ohne dass danach die Domänenanbindung repariert werden muss?
Gruß,
Colt
Hier hat weder 2004 noch 20H2 sowas gemacht bei 15 upgegradeten Rechnern, insofern halte ich das Update für unschuldig. Aber wer weiß, welche Wechselwirkungen es in einer anderen Softwareumgebung haben kann.
1
Hallo,
also das Update halte ich auch für nicht schuldig.
Eher wenn 2 Rechner den gleichen Namen haben.
also das Update halte ich auch für nicht schuldig.
Eher wenn 2 Rechner den gleichen Namen haben.
Hallo
Redest Du von dem Konto oder dem lokalen Profil?
Das Domänenkonto (im ActiveDirectory) wird natürlich niemals angefasst, wenn Du einen Rechner aus der Domäne nimmst. Das wäre ja noch schöner...
Das Profil liegt im Übrigen auf der Festplatte und eventuell - bei serverseitigen Profilen - auch auf dem Server.
Was sollte deiner Meinung nach denn sonst im Profil gespeichert werden, wenn nicht eben genau diese Informationen?!?
Gruß,
Jörg
Zitat von @coltseavers:
Wird dadurch das aktuelle, lokale Domänenbenutzerkonto gelöscht und "leer" neu erstellt, oder ist das aktuell vorhandene, lokale Domänenkonto dann wieder weiter verwendbar?
Wird dadurch das aktuelle, lokale Domänenbenutzerkonto gelöscht und "leer" neu erstellt, oder ist das aktuell vorhandene, lokale Domänenkonto dann wieder weiter verwendbar?
Redest Du von dem Konto oder dem lokalen Profil?
Das Domänenkonto (im ActiveDirectory) wird natürlich niemals angefasst, wenn Du einen Rechner aus der Domäne nimmst. Das wäre ja noch schöner...
Das Profil liegt im Übrigen auf der Festplatte und eventuell - bei serverseitigen Profilen - auch auf dem Server.
Mir geht es um Dateien innerhalb des lokalen Benutzerkontos sowie die ganzen Einstellungen - gehen die dadurch verloren?
Was sollte deiner Meinung nach denn sonst im Profil gespeichert werden, wenn nicht eben genau diese Informationen?!?
Gruß,
Jörg
Es ist so, dass beide betroffenen Rechner gestern beim Herunterfahren von 1909 auf 2004 upgedatet haben.
Beim heutigen Hochfahren kam dann die Fehlermeldung.
Nach dem offline Login (ohne Netzwerkverbindung) wurde dann die 2004er Installation abgeschlossen (Bitte warten, wir bereiten einige Dinge vor) [wer auch immer "wir" ist - lol Microsoft].
Es wurden in den letzten Wochen keine Rechner getauscht, dupliziert, umbenannt oder sonstwas.
Es gibt jedoch auch PCs im gleichen Netzwerk, die problemlos auf 2004 upgedatet worden sind.
Dennoch ist das Update der einzige Verdacht, zumal es die einzige Gemeinsamkeit der beiden betroffenen Rechner ist, die sich von gestern auf heute geändert hat.
Meine Vermutung ist aktuell die, dass sich durch das Update in manchen(!) Fällen die Computer SID ändert, warum auch immer.
In diesem Artikel wird als mögliche Ursache angegeben: "...if OS was reinstalled". Naja - ein Funktionsupgrade macht ja sowas ähnliches.
mikerodionov.com/2017/01/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed-proper-fix/
Weiterhin vermute ich, dass dieses Problem in dem Netzwerk erneut auftreten wird.
In dem Fall werde ich die computer SID aus dem Active Directory mit der computer SID auf dem Client abgleichen und dann dürfte Klarheit herrschen, ob der Verdacht korrekt war und die IDs nicht mehr identisch sind.
Für ebenfalls betroffene:
Offenbar kann man über dieses Powershell-Skript die Computer SID herausfinden, wenn man die Bezeichnung des Clients an die Stelle von "Administrator" setzt.
stackoverrun.com/de/q/695881
Ich werde berichten, sobald sich der Vorfall wiederholt.
Gruß,
Colt
Beim heutigen Hochfahren kam dann die Fehlermeldung.
Nach dem offline Login (ohne Netzwerkverbindung) wurde dann die 2004er Installation abgeschlossen (Bitte warten, wir bereiten einige Dinge vor) [wer auch immer "wir" ist - lol Microsoft].
Es wurden in den letzten Wochen keine Rechner getauscht, dupliziert, umbenannt oder sonstwas.
Es gibt jedoch auch PCs im gleichen Netzwerk, die problemlos auf 2004 upgedatet worden sind.
Dennoch ist das Update der einzige Verdacht, zumal es die einzige Gemeinsamkeit der beiden betroffenen Rechner ist, die sich von gestern auf heute geändert hat.
Meine Vermutung ist aktuell die, dass sich durch das Update in manchen(!) Fällen die Computer SID ändert, warum auch immer.
In diesem Artikel wird als mögliche Ursache angegeben: "...if OS was reinstalled". Naja - ein Funktionsupgrade macht ja sowas ähnliches.
mikerodionov.com/2017/01/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed-proper-fix/
Weiterhin vermute ich, dass dieses Problem in dem Netzwerk erneut auftreten wird.
In dem Fall werde ich die computer SID aus dem Active Directory mit der computer SID auf dem Client abgleichen und dann dürfte Klarheit herrschen, ob der Verdacht korrekt war und die IDs nicht mehr identisch sind.
Für ebenfalls betroffene:
Offenbar kann man über dieses Powershell-Skript die Computer SID herausfinden, wenn man die Bezeichnung des Clients an die Stelle von "Administrator" setzt.
stackoverrun.com/de/q/695881
Ich werde berichten, sobald sich der Vorfall wiederholt.
Gruß,
Colt
H,
wäre interessant. Ich habe ein ähnliches Problem mit einem Client gehabt. Dieser hat aber lediglich Windows Updates gemacht, kein Funktionsupgrade. Da es nur der eine war, habe ich die Sache nicht weiter analysiert.
Gruß
wäre interessant. Ich habe ein ähnliches Problem mit einem Client gehabt. Dieser hat aber lediglich Windows Updates gemacht, kein Funktionsupgrade. Da es nur der eine war, habe ich die Sache nicht weiter analysiert.
Gruß
Mahlzeit!
Das Problem ist nun erneut aufgetreten - und wieder nach dem Update Version 2004.
Tatsächlich sind die Computer SIDs vom PC und im AD (nur bei einigen PCs!) nach dem Update nicht mehr identisch, was Ursache des Problems sein dürfte.
Diesmal funktioniert die Repairfunktion jedoch nicht.
Fehlermeldung:
Jemand eine Idee?
Gruß,
Colt
Das Problem ist nun erneut aufgetreten - und wieder nach dem Update Version 2004.
Tatsächlich sind die Computer SIDs vom PC und im AD (nur bei einigen PCs!) nach dem Update nicht mehr identisch, was Ursache des Problems sein dürfte.
Diesmal funktioniert die Repairfunktion jedoch nicht.
Fehlermeldung:
Test-ComputerSecureChannel : Die Domäneninformationen zum lokalen Computer können wegen folgender Ausnahme nicht
abgerufen werden: Nicht gefunden .
In Zeile:1 Zeichen:1
+ Test-ComputerSecureChannel -Repair -Server dc1 -Credential domain ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (PC-blablubb:String) [Test-ComputerSecureChannel], InvalidOperati
onException
+ FullyQualifiedErrorId : FailToGetDomainInformation,Microsoft.PowerShell.Commands.TestComputerSecureChannelComman
dJemand eine Idee?
Gruß,
Colt
Hello again,
wollte nur kurz nachschieben, wie ich das Problem vom 9.12.2020 gelöst habe:
Habe mich mit einem lokalen Benutzerkonto angemeldet (lokaler Admin), habe den Rechner aus der Domäne entfernt, den PC neu gestartet und den PC wieder in die Domäne gebracht.
Das lokale Nutzerprofil der Domänenbenutzer ist dann übrigens weiter nutzbar gewesen, was meine Hauptsorge war.
Warum das Update nun einige PCs aus der Domäne befördert und andere nicht (und wie sich das verhindern lässt), bleibt aber weiter unklar.
An geclonten Rechnern in der Domäne lags jedenfalls nicht (weil Rechner nie geclont wurden) und auch Zeitdifferenzen zwischen Client und Server konnten als Ursache ausgeschlossen werden.
Gruß,
Colt
wollte nur kurz nachschieben, wie ich das Problem vom 9.12.2020 gelöst habe:
Habe mich mit einem lokalen Benutzerkonto angemeldet (lokaler Admin), habe den Rechner aus der Domäne entfernt, den PC neu gestartet und den PC wieder in die Domäne gebracht.
Das lokale Nutzerprofil der Domänenbenutzer ist dann übrigens weiter nutzbar gewesen, was meine Hauptsorge war.
Warum das Update nun einige PCs aus der Domäne befördert und andere nicht (und wie sich das verhindern lässt), bleibt aber weiter unklar.
An geclonten Rechnern in der Domäne lags jedenfalls nicht (weil Rechner nie geclont wurden) und auch Zeitdifferenzen zwischen Client und Server konnten als Ursache ausgeschlossen werden.
Gruß,
Colt
