Flam3h3ad 10 Geschrieben 18. September 2007 Melden Teilen Geschrieben 18. September 2007 Hallo zusammen Letzte Woche hatten wir in unserem Unternehmen vermehrt Anmeldeprobleme (das Anmelden an der Domäne dauerte Zeitweise bis zu 5 Minuten). Ich habe dann letzte Woche auf diversen Geräten gpupdate /force /wait:-1 ausgeführt. Dies dauerte zwischen 10 bis 20 Minuten. Nach dieser zeit war das gpupdate jedoch erfolgreich. Gestern dauerte das gpupdate dann auf einem Gerät 1,5 Stunden bevor wir es abgebrochen haben. Habe bereits einigen Orten zu diesem Thema was von DNS Problem und so gelesen. Deshalb erwähne ich hier mal noch, dass wir nicht Windows DNS einsetzen, sondern QIP. Serverbetriebsystem ist 2k3. Hat irgendjemand einen Lösungsansatz oder eine Idee was ich noch überprüfen könnte ? Vielen Dank bereits im voraus Freundliche Grüsse Flamehead Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 18. September 2007 Melden Teilen Geschrieben 18. September 2007 Naja, sind sämtliche SRV-Ressource Records der DCs und alle anderen relevanten Einträge in den Zonen vorhanden ? Registrieren sich die DCs und die Clients dynamisch oder sind die Einträge statisch vorgenommen worden. Wenn dynamisch, registrieren sie sich auch wirklich ? Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 18. September 2007 Autor Melden Teilen Geschrieben 18. September 2007 Danke für die rasche Antwort :) Das mit den SRV Resourcen Einträge bin ich gerade am checken... Habe in unserem DNS bisher folgende beide Einträge noch net gefunden: _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSTreeName> _ldap._tcp. ._sites.gc._msdcs.<DNSTreeName> Ansonsten habe ich sämtliche Einträge gefunden.... ich bin mir aber noch nicht ganz sicher, ob diese Einträge nicht vorhanden sind, oder ob ich einfach noch nicht genügend gut gesucht hab. Die Einträge der DCs sind statisch, die Clients registrieren sich dynamisch. Sämtliche dynamischen, sowie statische Einträge sind vorhanden. Sind die beiden SRV Resourcen Einträge, wo ich bisher noch nicht gefunden hab überhaupt relevant ? resp. hat mein Problem eventuell gar nichts mit dem fehlen dieser beiden Einträge zu tun ? GreeZ Flamy Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 18. September 2007 Melden Teilen Geschrieben 18. September 2007 Prüfe doch mal mit NETDIAG, ob alles da ist ... Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 18. September 2007 Autor Melden Teilen Geschrieben 18. September 2007 NETDIAG hab ich durchgeführt... Folgende Warnings resp. Errors: DNS test . . . . . . . . . . . . . : Passed 2 Verschiedene DNS Server überprüft und bei beiden war der Check erfolgreich und beim dritten folgendes: [WARNING] The DNS entries for this DC cannot be verified right now on DNS server IP-ADRESSE, ERROR_TIMEOUT. Die angegebenen IP-Adresse ist jene, welche bei der Backup-NIC als DNS Server eingetragen ist. Ausserdem folgendes Problem: NetBT name test. . . . . . : Passed [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenge r Service', <20> 'WINS' names is missing. No remote names have been found. 00, 03 und 20 sind ja WINS Codes.... Kann leider mit den Fehlermeldungen nichts anfangen.... hast du 'ne Idee ? Vielen Dank nochmals Flame Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 18. September 2007 Autor Melden Teilen Geschrieben 18. September 2007 Also habe die SRV Resources Einträge jetzt komplett überprüft und es sind sämtliche vorhanden. Das Problem war, dass natürlich der GC sowie der Domains eintrag natürlich in der Root oben zu finden war. Wie schauts aus mit den Warnings aus NETDIAG ? Gruss Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 18. September 2007 Melden Teilen Geschrieben 18. September 2007 Die Warnungen von NETDIAG haben nichts mit Deinem Problem zu tun ... Backup-NIC des Servers ? Poste bitte mal IPCONFIG /ALL des Servers ... Zitieren Link zu diesem Kommentar
carlito 10 Geschrieben 18. September 2007 Melden Teilen Geschrieben 18. September 2007 Also habe die SRV Resources Einträge jetzt komplett überprüft und es sind sämtliche vorhanden. Das Problem war, dass natürlich der GC sowie der Domains eintrag natürlich in der Root oben zu finden war. Wie schauts aus mit den Warnings aus NETDIAG ? Ich verstehe dein Posting so, dass die erste Warnung bzgl. DNS erledigt ist. Die zweite Warnung bzgl. NetBIOS kannst du ignorieren. PS: aus welchem Grund setzt du einen nicht-Microsoft DHCP Server ein? Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 18. September 2007 Melden Teilen Geschrieben 18. September 2007 Funktioniert denn sonst alles wie gewohnt und gibt es nur Verzögerungen beim Ausführen von GPUDATE ? Was steht in den Ereignisanzeigen der Clients und des Servers ? Das funktionierte doch schon oder ? Die Clients haben auch den richtigen DNS-Server eingetragen ? Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 21. September 2007 Autor Melden Teilen Geschrieben 21. September 2007 Backup-NIC des Servers ? Poste bitte mal IPCONFIG /ALL des Servers ... Windows IP Configuration Host Name . . . . . . . . . . . . : Servername des PDC Primary Dns Suffix . . . . . . . : xxx.yyyyy.ch Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : xxx.yyyyy.ch yyyyy.ch Ethernet adapter Backup NIC: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : HP NC7781 Gigabit Server Adapter Physical Address. . . . . . . . . : --------------- DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : No IP Address. . . . . . . . . . . . : --------------- Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCP Class ID . . . . . . . . . . : prod DHCP Server . . . . . . . . . . . : 10.xx.xxx.2 DNS Servers . . . . . . . . . . . : 10.0.0.1 Lease Obtained. . . . . . . . . . : Freitag, 21. September 2007 03:07:27 Lease Expires . . . . . . . . . . : Samstag, 22. September 2007 03:07:27 Ethernet adapter Teaming NIC: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : HP Network Team #1 Physical Address. . . . . . . . . : ----------------- DHCP Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 10.xx.xx.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.xxx.xx.10 DNS Servers . . . . . . . . . . . : 10.x.xx9.1 10.xxx.xx0.1 Primary WINS Server . . . . . . . : 10.xx.xxx.43 Secondary WINS Server . . . . . . : 10.xxx.xx.3 Hoffe, dass dir die Angaben langen, sonst sag bitte bescheid :) Den DNS Server der die Backup-NIC eingetragen hat, gibt es nicht. PS: aus welchem Grund setzt du einen nicht-Microsoft DHCP Server ein? DAS wüsste ich auch gerne, dass war nicht meine Entscheidung und unser Team wollte das auch nicht. Das wurde vom Management so entschieden und BASTA :mad: Jetzt haben wir ein alternativ Produkt eingesetzt (QIP) und müssen damit leben. Funktioniert denn sonst alles wie gewohnt und gibt es nur Verzögerungen beim Ausführen von GPUDATE ? Eigentlich nicht, gpresult dauert jedoch auch entsprechend ewig. Was steht in den Ereignisanzeigen der Clients und des Servers ? Unter System findet man pro Tag etwa 14 Netlogon Errors. Jeweils immer mit der Event ID 5719. Microsoft Support sagt, dass folgendes ein möglicher Grund für diesen Error sein könnte: One possible cause of this error is that you have run out of buffer space in the NetBT datagram buffer. Der letzte Error in Directory Service war am 09.08.2007 also schon fast 1,5 Monate her. Unter Application haben wir nach jedem Neustart des DC's zwei Errors von Userenv mit der Event ID 1030 und 1097. Jedoch ist dies "normal" bei einem Neustart des DC's laut Microsoft Support Die Clients haben auch den richtigen DNS-Server eingetragen ? Client und Server haben beide die gleichen Einträge und diese sind korrekt. Unsere Domäne steht schon einige Jahre und das ganze hat immer ordentlich funktioniert. Hoffe, dass euch meine Angaben weiterhelfen um mir zu helfen :D Gruss Flamy Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 21. September 2007 Autor Melden Teilen Geschrieben 21. September 2007 Habe jetzt noch in den anderen vier Domänen getestet und das Problem besteht dort nur teilweise. In der zweiten Domäne der Produktion besteht das Problem. In der Testumgebung, besteht das Problem nicht. Lokal auf den PDCs funktioniert gpupdate in sämtlichen Domänen einwandfrei. Wenn ich in einer der beiden produktiven Domäne gpupdate /force ausführe ohne Zeitangabe, so bekomme ich folgende Meldung nach 10 Minuten: User Policy Refresh has completed. Computer Policy has not completed in the expected time. Exiting... Computer Policy Refresh has completed Na wie jetzt ? Computer Policy has not completed in the expected time. Exiting.... und dann trotzdem gleich anschliessend Computer Policy Refresh has completed ? :suspect: Wie schon gesagt, wenn ich noch /wait:-1 mitgebe, funktionierts eigentlich. Natürlich dauerts eben wie schon gesagt manchmal bis zu 1,5 h... Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 24. September 2007 Autor Melden Teilen Geschrieben 24. September 2007 Wir benötigen immer noch Hilfe.... haben noch etwas anderes bemerkt: gpresult funktioniert nur sehr sporadisch. Manchmal funktionierts 2-3 Mal ohne Probleme und dann wenn gpresult bei folgendem Part ist: Creating the RSOP session for MOBI\u110533... bekommen wir nach etwa 1 Minute die Meldung: ERROR: Access Denied. Wie gesagt, sehr sporadisch funktioniert es. Wir haben uns weder neu angemeldet an der Domäne noch sonstwas verändert. Der Logonserver war immer der gleiche und wir haben das ganze mit unterschiedlichen Logonserver getestet. Überall ists das gleiche. Freundliche Grüsse Flamehead Zitieren Link zu diesem Kommentar
Flam3h3ad 10 Geschrieben 4. Februar 2008 Autor Melden Teilen Geschrieben 4. Februar 2008 fyi: Konnten das Problem lösen. Die Virenscanner Engine war nicht auf dem neusten Stand. Unser Virenscanner hat jede Datei, auf welche wir per Default Domain Policy ACL's gesetzt haben gescannt. Da dies C:\Windows und auch C:\Program Files u.v.m. beinhaltet, dauerte gpupdate enorm lange. Ausserdem haben wir das setzen von ACL aus der Default Domain Policy genommen. Wir steuern dies nun per Script. Vielleicht hilft der Hinweis ja noch jemandem :) Freundliche Grüsse Flam3h3ad Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.