doquentin

Es handelt sich um einen konkreten Benutzer. Mir ist bei uns kein Script bekannt, welches Computeraccounts ausmistet. Ich hatte heute schon wieder das gleiche Problem mit dem selben Computeraccount. Bevor der Support nun den PC neu in die Domäne gehoben hat bin ich nun hingegangen und habe den Computeraccount resettet. Leider ohne Erfolg, der benutzer bekommt weiterhin die Meldung, dass kein Domänencontroller zum anmelden zur Verfügung steht. Habe den Computeraccount nun komplett gelöscht, hoffe das es dann wieder langfristig funktioniert.. Das löst aber das Grundproblem auch nicht.

Hmm nein, der Benutzer hat gestern noch mit dem Computer ohne Probleme arbeiten können, den Freitag davor auch. Länger ausgeschaltet war der Computer also nicht. – Ich muss mich korrigieren. Der Computer wurde das letzte Mal am 01.09.2008 genutzt, da der Benutzer krank war. Evtl. doch ein Problem hier?!

Ich habe schonmal was davon gelesen, dass es zu Problemen kommen kann bzgl. des Kennwortes des Computer-Accounts. Könnte dies hier der Fall sein?! Es scheint mir, als sei das Benutzerkonto deaktiviert worden (evtl. durch ein Kennwort was abgelaufen ist) und mit ihm auch das Computerkonto. Kann das sein? Ich hoffe, dass jemanden das Problem etwas sagt. Viele Grüße, Doquentin

Hallo nochmal! Also ich hatte heute den nächsten Fall, wo ein Computer sich nicht mehr an der Domäne anmelden konnte. Der Support musste den PC aus der Domäne rausnehmen und neu reinheben, damit das anmelden wieder möglich war. Ich habe nun nach dem Erstellungsdatum des Computeraccounts geschaut und scheinbar wurde das Computerkonto nicht gelöscht sondern war noch vorhanden als das Problem auftrat. Aufgrund der eingeschalteten Kontoüberwachung habe ich nun mehr Informationen. Zu dem entsprechenden Hostnamen habe ich folgende Informationen gefunden (zeitlich nacheinander): ---------------------------------- Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 629 Deaktiviertes Benutzerkonto: Zielkontenname: Hostname$ Zieldomäne: DOM Zielkontokennung: DOM\HOSTNAME$ Benutzername des Aufrufers: UserName Domäne des Aufrufers: DOM Anmeldekennung des Aufrufers: (0x0,0x44387F83) Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 646 Geändertes Computerkonto: - Neuer Kontenname: HOSTNAME$ Neue Domäne: DOM Neue Kontokennung: DOM\HOSTNAME$ Benutzername des Aufrufers: UserName Domäne des Aufrufers: DOM Anmeldekennung des Aufrufers: (0x0,0x44387F83) Rechte: - Geänderte Attribute: SAM-Kontoname: - Anzeigename: - Benutzerprinzipalname: - Stammverzeichnis: - Stammlaufwerk: - Skriptpfad: - Profilpfad: - Benutzerworkstations: - Kennwort zuletzt gesetzt: - Konto läuft ab: - Primäre Gruppenkennung: - DelegierenAnZulässig: - Alter UAC Wert: 0x80 Neuer UAC Wert: 0x81 Benutzerkontensteuerung: Konto Deaktiviert Benutzerparameter: - Sid-Verlauf: - Anmeldestunden: - DNS-Hostname: - Dienstprinzipalnamen: - Daraufhin gab es scheinbar einen Neustart des Computers, da dann der andere DC mitgeloggt hat. (darum auch weiter in Englisch) Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 646 Computer Account Changed: Account Enabled. Target Account Name: HOSTNAME$ Target Domain: DOM Target Account ID: DOM\HOSTNAME$ Caller User Name: UserName Caller Domain: DOM Caller Logon ID: (0x0,0x13D64CE4) Privileges: - Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 646 Computer Account Changed: Account Disabled. Target Account Name: HOSTNAME$ Target Domain: DOM Target Account ID: DOM\HOSTNAME$ Caller User Name: UserName Caller Domain: DOM Caller Logon ID: (0x0,0x13D64CE4) Privileges: - Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 646 Computer Account Changed: Account Enabled. Target Account Name: HOSTNAME$ Target Domain: DOM Target Account ID: DOM\HOSTNAME$ Caller User Name: UserName Caller Domain: DOM Caller Logon ID: (0x0,0x13D64CE4) Privileges: - Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 646 Computer Account Changed: - Target Account Name: HOSTNAME$ Target Domain: DOM Target Account ID: DOM\HOSTNAME$ Caller User Name: UserName Caller Domain: DOM Caller Logon ID: (0x0,0x13D64CE4) Privileges: - Quelle: Security Kategorie: Kontenverwaltung Ereigniskennung: 628 User Account password set: Target Account Name: HOSTNAME$ Target Domain: DOM Target Account ID: DOM\HOSTNAME$ Caller User Name: Username Caller Domain: DOM Caller Logon ID: (0x0,0x13D64CE4) ------------------------------------- Diese Ereignisse sind innerhalb von ca. 1 Minute nacheinander aufgetreten.

Danke schonmal für die zahlreichen Tipps! Ich habe mal die Kontenüberwachung eingeschaltet und werde den Imageprozess anpassen lassen. Grüße, Doquentin

Bei der SID habe ich mal geschaut, dass sieht OK aus. Momentan läuft es so: Der Rechner, von dem ein Image gezogen wird ist Mitglied einer Domäne. Dann wird sysprep durchgeführt. Wenn ein neuer Rechner aufgesetzt wird, läuft ein Mini-Setup durch, wo man den PC in eine Domäne heben kann. Somit wird auch ein Computer-Account mit einer neuen SID erzeugt.

Haben Sie vielleicht eine Seite mit einer Beschreibung, wie ich dies für die Computers-OU einschalten kann? (Die Objektüberwachung) Dann würde ich dies mal einstellen und beobachten. Hinweis: Wir nutzen den Default Container für Computerkonten!

Also der Rechner war vorher definitiv in der Domäne und der Benutzer konnte wochenlang arbeiten. Wir müssen den Rechner dann neu in die Domäne heben, damit ein neues Computerkonto erstellt wird. Danach funktioniert alles wieder. Im Eventlog gibt es keine Fehler im Replizierungslog. Ich kriege lediglich die Fehlermeldungen im Systemlog. (die beiden beschriebenen Netlogon-Einträge) Wir haben ein Image erzeugt mit dem Sysprep-Tool. D.h. wenn wir einen Rechner aufsetzen mit dem Image wird ein Mini-Setup durchlaufen wo Sachen abgefragt werden und auch eine neue SID erzeugt wird. Dies war auch mal eine Vermutung von mir, habe dies aber geprüft. Sollte ich anders prüfen, ob es Replizierungsprobleme gibt oder sollte alles in Ordnung sein, wenn der Log keine Fehler anzeigt?

Hallo, ich wollte auf einen ähnlichen Beitrag antworten, leider hat dies nicht funktioniert, da der Beitrag sehr alt war und ich eine Antwort nicht bestätigen konnte. Daher ein neues Thema von mir. Es wird immer häufiger an mich heran getragen, dass sich Clients nicht mehr an der Domäne anmelden können. Wenn ich dann nachgucke, sehe ich, dass das entsprechende Computerkonto nicht mehr existiert. Angeblich hat aber niemand das Konto gelöscht. Im Eventlog erscheint folgende Netlogon-Meldung: " Quelle: Netlogon Ereigniskennung: 5723 Die Sitzung konnte vom Computer "Hostname" nicht eingerichtet werden, da die Sicherheitsdatenbank kein Vertrauenskonto "Hostname$" entsprechend dem angegebenen Computer enthält. BENUTZERAKTION Wenn dieses Ereignis das erste Mal für den angegebenen Computer vorkommt, ist das eventuell ein vorübergehendes Problem, auf das zur Zeit nicht geachtet werden muss. Andernfalls kann dieses Problem anhand der folgenden Schritte gelöst werden: Wenn "Hostname$" das legitime Computerkonto für den Computer "Hostname" ist, dann sollte "Hostname" dieser Domäne angeschlossen werden. Wenn "Hostname$" das legitime domänenübergreifende Vertrauenskonto ist, sollte die Vertrauensstellung neu erstellt werden. Im Falle das "Hostname$" kein legitimes Konto ist, sollte folgendes für "Hostname" veranlasst werden: ..." Und darauf folgend diese Meldung: " Quelle: Netlogon Ereigniskennung: 5805 Die Sitzungseinrichtung von Computer WIK39260 konnte nicht authentifiziert werden. Der folgende Fehler ist aufgetreten: Zugriff verweigert " Seit kurzem Klonen wir Rechner, könnte da ein Problem bestehen? Allerdings hatten wir das Problem sogar schon mit produktiven Serversystemen gehabt, welche logischerweise nicht geklont werden. ;-) Ich habe das Gefühl, dass es am DNS o.ä. liegt. Hier ist Scavenging aktiv. Aber dadurch dürften auch keine Computerkonten verloren gehen oder?! Wir nutzen eine Windows 2000 native AD-Umgebung. Auf den Domain Controllern läuft auch der DNS Dienst sowie DHCP. Ich hoffe, mir kann jemand einen Tipp geben. Viele Grüße, Doquentin

Hi, per WSUS lässt sich leider erst der Internet Explorer 7 verteilen. Grüße, Dominik Quentin

Ich hatte das gleiche Problem mal auf meiner Teststellung, wo ich eben mit der Migration und Neuinstallation von WSUS 3 herumprobiert habe. Da musste ich echt komplett das DB Verzeichnis und die Regeinträge killen, bevor ich wieder ein Installationsdurchlauf machen konnte. Nur ein Problem hast du jetzt evtl.. Hat er deine WSUS 2 Installation schon migriert auf das WSUS3 Format? (Also die Datenbank). Wenn er das schon gemacht hat und danach abgebrochen, kann es sein, dass es mit dem Upgrade dahin ist... Hoffe du hastein Backup.

Hi. Lief auf dem Server vorher schon ein Produkt, welches die Windows Internal Database mitinstalliert hat und nutzt? Das lässt das WSUS3 Setup tatsächlich nicht zu. Evtl. mal in der Registry nach Einträgen von der Windows SQL Server 2005 Express Edition suchen oder auch "Yukon". Vielleicht die Einträge mal säubern, da solltest du auch den Installationspfad für die SSEE Installation finden, den du dann löschen kannst. Evtl. erkennt er dann keine vorhandene Installation mehr und läuft weiter. Vorausgesetzt natürlich, da ist keine Internal Database installiert, die noch benötigt wird.

Richtig. Weil sonst will der Automatische Updates Dienst sich die Patches aus dem Internet holen. Du musst ihn zu deinem WSUS 3 Server leiten. Ich habe die Konfiguration damals per Regkey vorgenommen. In der WSUS Dokumentation findest du die genaue Bedeutung aller Konfigurationsmöglichkeiten (wie z.B. Installationszeitpunkt, darf der Benutzer eingreifen oder nicht, Neustart oder nicht etc.)

Schwierig schwierig... Habe die IDs mal nachgeschaut. (Guck mal hier: Troubleshooting Windows STOP Messages ) Es kann ein Hardwareproblem sein (ich würde auf Arbeitsspeicher tippen und den mal wechseln wenn noch nicht gemacht) aber auch eine Softwaregeschichte. Ansonsten recherchier doch mal alle Patch-IDs nach, was da alles geändert wird und ob es mit einem der Patches Probleme gab, kam ja auch schon vor.

Vielleicht war nur etwas mit dem lokalen Benutzerprofil nicht ok... In jedem Fall würde ich einen "Backup" DC aufsetzen, damit das AD synchronisiert wird. Falls also wirklich mal etwas mit deinem DC passieren sollte, kann der andere einspringen.

Da ist z.B. ein lokaler Drucker dabei (Free PDF Drucker), aber auch Netzwerkdrucker, die über Printserver verbunden werden oder 1 Drucker, der an einer Arbeitsstation hängt und freigegeben ist. Habe schon mehreres probiert, auch Drucker per Local Port zu verbinden.

Hallo, ich habe in meiner Firma einen Terminalserver unter Windows Server 2003 am laufen. Nun haben wir dort das kuriose Problem, dass man keinen Standarddrucker definieren kann!! Kein Drucker von z.B. 2-3 Druckern hat ein Häkchen wie gewohnt. Wenn man einen Drucker rechtsklickt, kann man zwar "Als Standard definieren" auswählen, aber es erscheint trotzdem kein Häkchen und der Drucker ist dann auch kein Standarddrucker. Das wird langsam zu einem ernsten Problem. Ich habe mal die Registrierung überprüft, wo die Drucker ja normalerweise aufgeführt sind. Was dort komisch ist: Unter HKEY_CURRENT_USER\Printers sind keinerlei Drucker eingetragen, was aber normalerweise der Fall sein sollte!! Ich habe das mal mit meinem ClientPC verglichen und da ist alles normal. Unter HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Devices , wo normalerweise ja die Standarddrucker definiert werden ist auch kein Schlüssel abgelegt. Hat jemand mal ein ähnliches Problem gehabt und kann mir da helfen oder hat einer ein Tipp für mich?! Mfg Doquentin

*gegen Kopf haut* Natürlich! Ich dachte der Haken muss drin sein, wenn alle Updates heruntergeladen werden sollen. Also braucht man die Option Expressinstallation gar nicht wenn ich das richtig verstehe. Ich dachte immer, man muss zwischen dieser Option wählen und der Option, dass nur Zugelassene Updates gezogen werden. :shock: Das erklärt natürlich, warum das immer so viel war. Danke sehr!

Hm, also normalerweise kann man sich nicht völlig ausschliessen. Der Besitzer des Ordners/Datei sollte in jedem Fall eigentlich noch zugreifen können. Und wenn es den Besitzer nicht gibt kann man auch den Besitz übernehmen. Schau da mal nach, evtl. geht das irgendwie.

Hallo liebe MCSE Gemeinde, mein erster Eintrag hier, ich hoffe ich beachte alle Regeln. :) Habe schon herumgesucht, doch nichts zu meiner Frage gefunden. Ich betreue in der Firma das SUS System. Dort werden Englische und Deutsche Patches gezogen für Win XP, 2000 und Server 2003. Der komplette SUS Ordner nimmt mittlerweise 3 GB Speicherplatz in Anspruch. Ich teste nun schon seit über einem Jahr das neue WUS System und habe nun auch ein Test WSUS System am laufen was ich demnächst auch produktiv einsetzen möchte. Eines stört mich bei WSUS noch, und zwar habe ich da auch die gleichen Einstellungen wie bei SUS: Englische und Deutsche Patches ziehen für Win XP, 2000, Server 2003, SQL Server und Exchange. Alle Patches werden lokal auf dem Server gespeichert und dann je nach Zulassung an die Clients verteilt. Auf dem SUS System funktioniert es genauso, dass wenn MS Patches veröffentlicht, diese bei der nächsten Synchronisation alle gezogen werden und auf dem Server lokal abgespeichert. Nun gibt es da aber einen imensen Unterschied bei dem Speicherplatzbedarf. SUS verbraucht 3,02 GB und WSUS nimmt ganze 13,9 GB samt Datenbank in Anspruch. Ich meine, klar, WSUS hat erweitete Möglichkeiten, was man ziehen kann wie z.B. SQL Updates oder Exchange Updates, Tools etc. Aber ein Unterschied von über 10 GB ?! Die Patches scheinen bei dem SUS Server kleiner zu sein, die gezogen werden. Bei WSUS sieht es immer so aus wie wenn neben der eigentlichen Update-Datei noch 2-3 andere gezogen werden. Was kann das sein? An den Einstellungen dürfte das nicht liegen. Man hat noch 2 andere Einstellmöglichkeiten, dass die Clients die Updates direkt von Microsoft per Internet beziehen oder das nur die Beschreibungen gezogen werden und wenn man Updates zulässt diese Updates gezogen werden. Allerdings favorisiere ich die Einstellungen, dass alles gezogen wird gleich. Also habt ihr eine Idee warum die Updates so ungewöhnlich größer sind als bei SUS? Als Anmerkung: SUS hat den gleichen aktuellen Stand wie der WSUS. Danke schonmal. Mfg, Doquentin