mcdaniels 29 Geschrieben 17. April 2009 Melden Teilen Geschrieben 17. April 2009 Hallo Leute! Obwohl bei meiner heutigen Serverumstellung eigentlich alles wie geplant gelaufen ist. (Ich habe einen DC ohne Rollen und mit globalem Katalog mittels DCPROMO aus der Domäne entfernt, das Computerkonto danach gelöscht und auch überbleibsel in den NTDS Settings entfernt). Danach kam der neue DC (ebenfalls ohne Rollen und als GC in die Domäne - mittels dcpromo - was keine Probleme machte). Natürlich gibt es hier auch einen DC der alle Rollen hat und in der Domäne läuft. (zu diesem kommt der neue als weiterer DC dazu) Nachdem DCPROMO ordnungsgemäß gelaufen ist und die erste Replikation in Ordnung schien (replmon) habe ich als DNS1 beim neuen DC die IP des neuen DC eingetragen und als DNS 2 die IP des zusätzlichen bestehenden DC mit allen Rollen. - soweit so gut. Auch ein DCDIAG meldet keine Probleme... nur folgendes steht ca. alle 5 Minuten im Anwendungseventlog: Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1054 Datum: 17.04.2009 Zeit: 20:42:58 Benutzer: NT-AUTORITÄT\SYSTEM Computer: TIMESERVER Beschreibung: Eventid 1054Quelle: Userenv Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Unerwarteter Netzwerkfehler. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen. Was mir noch auffiel ist, dass der neue Server in REPLMON bei den Properties / Serverflags folgendes stehen hat: Server is the Primary Domain Controller for the Domain: X (also nein) Müsste das nicht auch ein PDC sein - nur ohne Rollen? Bin ein wenig gefrustet und weiß ehrlich gesagt im Moment nicht mehr weiter? Hoffe auf eure Hilfe LG Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 17. April 2009 Melden Teilen Geschrieben 17. April 2009 Hi, der PDCe einer Domäne ist eine sogenannte FSMO Rolle. Es gibt keine PDCs im Sinne von Windows NT mehr. Ein "netdom query fsmo" etwa zeigt Dir, wo die PDCe Rolle derzeit in der jeweiligen Domäne liegt. In Bezug auf den Fehler kann es sehr, sehr viele Fehlerursachen geben. Der Fehler 1054 ist schon fast ein "Sammelbecken" für ganz verschiedene Probleme. Einen ersten Ansatz findest Du vielleicht hier: Cannot connect to domain controller and cannot apply Group Policy with Gigabit Ethernet devices Ansonsten kannst Du auch einmal einen Blick auf die Scalable Network Pack Features werfen und ggf. Deinen Netzwerkkarten Treiber aktualisieren: A Scalable Networking Pack (SNP) hotfix rollup package is available for Windows Server 2003 bzw. ggf. An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers . Viele Grüße olc Zitieren Link zu diesem Kommentar
mcdaniels 29 Geschrieben 17. April 2009 Autor Melden Teilen Geschrieben 17. April 2009 Hallo olc! Danke dir für deine schnelle Reaktion. War mir klar, dass es keine PDC im Sinne v. NT mehr gibt ;) Welche Auswirkungen hat dieser Fehler. Augenscheinlich läuft doch etwas nicht rund und unerwarteter Netzwerkfehler klingt mir gar nicht gut... Hat dieser Fehler also keine Auswirkungen oder doch? LG Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 17. April 2009 Melden Teilen Geschrieben 17. April 2009 Hi, Du kannst schlichtweg keine Gruppenrichtlinien abrufen, was gemeinhin ein großes Problem ist (insbesondere auf DCs). ;) Schau einmal in die oben genannten Links, vielleicht löst das schon Deine Probleme. Viele Grüße olc Zitieren Link zu diesem Kommentar
mcdaniels 29 Geschrieben 17. April 2009 Autor Melden Teilen Geschrieben 17. April 2009 Hi! Ja steht ja auch in der Meldung :o - man sollte lesen können ;) bin schon etwas konfus heute... sorry Naja ich versuch mal Mediasense zu deaktivieren bzw. arbeite deine Links mal ab. Meld mich dann wieder. LG und Danke einstweilen Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 17. April 2009 Melden Teilen Geschrieben 17. April 2009 Hi, ok, mach das einmal. Wenn MediaSense nicht hilft, dann prüfe die oben genannten SNP Features. Hilft auch das nicht, könnte man noch einmal in Richtung SMB Signing schauen. Du schreibst oben, daß Du "überbleibsel" der NTDS Settings entfernt hast. Was genau meinst Du damit? Wenn der DC korrekt entfernt wurde, dann gibt es kein NTDS Objekt mehr. Falls doch, wäre das DCPROMO nicht korrekt gelaufen. In diesem Fall könnte das auch Probleme bereiten bzw. den Fehler verursachen, Du solltest dann ggf. noch einmal mittels Metadata Cleanup die Reste des alten DCs entfernen, siehe How to remove data in Active Directory after an unsuccessful domain controller demotion . Viele Grüße olc Zitieren Link zu diesem Kommentar
capsuel 10 Geschrieben 17. April 2009 Melden Teilen Geschrieben 17. April 2009 hallo dnaiel, hatte das problem auch und folgendes hat geholfen: Event-Log Meldung: “USERENV 1054″ | Server Talk nach einem reboot war dann im log alles clean. gruss capsuel Zitieren Link zu diesem Kommentar
mcdaniels 29 Geschrieben 18. April 2009 Autor Melden Teilen Geschrieben 18. April 2009 Hallo zusammen! Habe nun (bzw. hatte um 00:54) alles durch. Angefangen von den Hotfixes über den Eintrag in die Registry der übrigens schon so eingestellt war. (lt. Link von casuel und auch olc). Abgesehen davon habe ich lt. Gruppenrichtlinien - Übersicht, FAQ und Tutorials das Bestpractise Beispiel betreffend SMB Signing umgesetzt. Ebenso hat mich XP-Fan gestern noch unterstützt (DANKE NOCHMALS!) und ist mit mir etliche Details durchgegangen u.a. DNS Auflösung (ok), DCdiag (ok), Replmon (ok), Umsetzen von Gruppenrichtlinien, Kontrolle des Eventlog. Um 00:54 heute Früh hab ich es sein lassen und hänge grade wieder per VPN auf dem betroffenen Server, der Event 1054 meldet. Momentan sollte ich eher sagen meldete, denn seit 00:54 kein solcher Eintrag mehr in der Anwendungseventlog. Die Frage ist nun natürlich, was hat den Ausschlag gegeben, denn es sah ja gestern bzw heut in aller Frühe nicht so aus, als ob das Problem behoben wäre... LG Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 18. April 2009 Melden Teilen Geschrieben 18. April 2009 Hi, neben dem MediaSense habe ich oben doch auch vom SMB Signing und SNP gesprochen :suspect: ...? In jedem Fall macht es sich natürlich immer gut, Schritt für Schritt die Änderungen einzeln durchzugehen, um nicht genau in die Situation zu laufen, die Du jetzt hast: Nicht zu wissen, welche Einstellung das Verhalten geändert hat. Aber gut, im Moment scheint das Problem gelöst zu sein, also gibt es schlimmeres als nicht genau zu wissen, woran es lag. ;) Viele Grüße olc Zitieren Link zu diesem Kommentar
mcdaniels 29 Geschrieben 18. April 2009 Autor Melden Teilen Geschrieben 18. April 2009 Hallo olc! Sorry falls das jetz so rübergekommen ist , als hättest du das SMB Signing etc. nicht erwähnt. Natürlich hast du das gemacht. Danke dafür! Nunja, ich habe schon nach jeder Änderung gewartet, gpupdate / force angestartet und mir dann gpresult angeschaut bzw. bin dann -nach jeder Änderung am System- sämtliche Schritte durchgegangen, die dann wieder die Fehlermeldung provoziert hatten. Eben bis 00:54, dann hab ich das alles sein lassen. (War schon ziemlich ko ;) ) Einzig und allein eine Konstellation kommt mir komisch vor. Auf dem bestehenden 2K PDC wird bei jedem dcdiag angemeckert, dass der Dienst RPCLocator nicht läuft. Deshalb läuft auch der Test der Services in ein Failed, solange ich diesen Dienst nicht starte. Der Dienst steht standardmäßig auf manuell und ist nicht gestartet gewesen. Ich habe gestern vorm schlafen gehen noch versucht, den Dienst auf automatisch zu stellen und hab ihn gestartet. Könnte es auch damit zusammenhängen? Wie gesagt normal sollte dieser Dienst auf manuell stehen. Update: Grade eben in nem Newsbeitrag gelesen: If these are Windows 2000 DCs, make sure the Remote Procedure Call (RPC) Locator services is Started and Automatic. If these are Windows Server 2003 DCs make sure this service is not started and set to Manual. Also ist das auf 2K Servern auf automatic zu stellen und auf 2k3 auf manuell. LG Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 18. April 2009 Melden Teilen Geschrieben 18. April 2009 Hi Daniel, mach Dir keine Gedanken, ich wollte mit meinem Kommentar nicht drauf bestehen, daß es genannt wurde. ;) Ich habe nur manchmal Sorge, daß es "übersehen" wird und man dann länger an einem Problem herum fummelt, welches schon behoben sein könnte. Aber das ist ja in diesem Fall nicht so. Beim DCPROMO wird der RPCLocator von "deaktiviert" auf "automatisch" gestellt, von daher sollte er eigentlich auch gestartet sein. Siehe dazu: Directory Service Configuration . Neben dem SMB Signing könnte also auch das ausschlaggebend gewesen sein. Viele Grüße olc Zitieren Link zu diesem Kommentar
mcdaniels 29 Geschrieben 18. April 2009 Autor Melden Teilen Geschrieben 18. April 2009 Hi nochmals! Man sieht, dass es gestern nicht mein Tag war, denn ich habe vor dem zu Bette gehen noch etwas gemacht, das ich euch nicht vorenthalten will. Dieser "Server" ist ein AMD Athlon 64 X2 4450e. Nachdem ich auf EVENT ID Net gelesen hatte, dass dieses Verhalten auch mit dem Prozessortreiber zutun haben kann. Also habe ich mir von AMD Support Search den letzten aktuellen Athlon 64 Prozessortreiber heruntergeladen und installiert. Nun muss ich dir, olc, insofern Recht geben, da ich sowohl den Prozessortreiber installiert, als auch den RPC Locator gestartet habe und nun nicht weiß, welche der beiden Aktionen nun der momentan richtige Weg war. LG und besten Dank an alle Helfer! Ich hoffe, ich seh diesen Eintrag nicht mehr in meimem Eventlog ;) Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 18. April 2009 Melden Teilen Geschrieben 18. April 2009 Hi, Du kannst ja einfach das SMB Signing wieder umstellen und den RPCLocator Dienst noch einmal beenden. Tritt der Fehler dann wieder auf, dann weißt Du, daß es daran lag. :D Scherz beiseite, Hauptsache es läuft wieder. :) Viele Grüße olc 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.