Jump to content

W2K3 DC AD Fehlfunktion


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Wir haben vier W2K3 Server im AD. Alle sind DC, replizieren untereinander. Ein Server spielt nicht mehr mit, ich habe mal die gängingsten Protokolleinträge angehangen. Die Ursache ist uns nicht bekannt, wir vermuten, dass es nach einer Rücksicherung durch Acronis passiert ist, wobei wir nicht sofort etwas bemerkt haben. Der Server funktioniert weiterhin als Printserver, allerdings verweigert er dann und wann mal den Zugriff, was aber nicht weiter schlimm ist. Man kann auch kein Laufwerk mappen, es sei denn, man gibt die IP an (Namensauflösung scheinbar vollkommen defekt). Der Zugriff auf Freigaben von einem anderen Rechner/Server auf diesen funktioniert tadellos, nur umgekehrt wie gesagt nicht. Hat da jemand einen Tip?

----------------------------------------------------------------------------------------------------

Ereignistyp: Fehler

Ereignisquelle: Userenv

Ereigniskategorie: Keine

Ereigniskennung: 1053

Datum: 16.03.2006

Zeit: 09:55:44

Benutzer: NT-AUTORITT\SYSTEM

Computer: XXX

Beschreibung:

Der Benutzer oder der Computername kann nicht ermittelt werden. (Der Zielprinzipalname ist falsch. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.

 

Weitere Informationen ber die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.'>http://go.microsoft.com/fwlink/events.asp.

 

-----------------------------------------------------------------------------------------------------

Ereignistyp: Fehler

Ereignisquelle: Kerberos

Ereigniskategorie: Keine

Ereigniskennung: 4

Datum: 16.03.2006

Zeit: 09:55:59

Benutzer: Nicht zutreffend

Computer: XXX

Beschreibung:

Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "host/XXX.XXX.local" empfangen. Der verwendete Zielname war cifs/XXX.XXX.LOCAL. Dies deutet darauf hin, dass das Kennwort, das zum Verschlsseln des Kerberos-Diensttickets verwendet wurde, anders als das Kennwort auf dem Zielserver ist. Hufige Ursache hierfr sind identische Computerkontonamen im Zielbereich (XXX.LOCAL) und dem Clientbereich. Wenden Sie sich an den Systemadministrator.

 

Weitere Informationen ber die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Link zu diesem Kommentar

Erst einmal vielen Dank für Deine Mühe.

 

 

Ich habe zwar mit den Uhrzeiten nichts gemacht, aber einen Versuch ist es sicher wert. Könntest du mir krz auflisten, welchen Dienst ich auf welchem Server beenden muss und wo bzw. auf wlechem Server der Befehl für die Ticketleerung abgesetzt werden soll?

 

Dabei kann doch den anderen drei, noch funktionierenden Servern nichts passieren? :confused:

Link zu diesem Kommentar

Hallo!

Ob dabei mit den anderen nichts passieren kann, kann ich leider nicht versichern. Von unserem Systemhaus habe ich erfahren, dass der Befehl "klist purge" mit Vorsicht eingesetzt werden sollte. Warum weiß ich aber nicht...

Wenn du also keine Probleme bei der Replikation zwischen den DCs oder ähnliches feststellst, kannst du ja auch noch nach einer anderen Lösung suchen.

 

Meine Schritte:

 

Auf dem Server mit den Problemen

1. Kerberos Schlüsselverteilungscenter deaktivieren

2. Server neu starten

3. netdom /resetpwd /s:"PDC-EMULATOR" /ud: DOMÄNE\DOMÄNENADMIN /pd:*

(groß geschriebenes ist entsprechend zu ersetzen)

4. Neu starten

5. Kerberos Schlüsselverteilungscenter

 

Ob die Schritte 1 - 5 wirklich nötig sind weiß ich nicht. Das habe ich vorher im Rahmen eines anderen Lösungsversuchs probiert. Anschließend konnten sich die User aber wieder über die "normalen" Freigaben und nicht über die IP mit den Netz-Laufwerken verbinden.

 

Hier die Schritte die nachher die Replikation wieder in Gang gebracht haben und alle Fehler in dcdiag beseitigt haben.

 

Auf dem DC mit den Problemen...

6. Kerberos Schlüsselverteilungscenter beenden

7. In der Kommandozeile

klist purge

--> für jedes angegebene Ticket das Löschen bestätigen

8. Kerberos Schlüsselverteilungscenter

9. Server neu starten

 

Nach kurzer Zeit sollte im Dateireplikations-Log folgender Eintrag erscheinen:

 

Ereignistyp: Warnung

Ereignisquelle: NtFrs

Ereigniskategorie: Keine

Ereigniskennung: 13509

Datum: 10.03.2006

Zeit: 15:43:38

Benutzer: Nicht zutreffend

Computer: DC2

Beschreibung:

Der Dateireplikationsdienst hat die Replikation von DC1 nach DC2 für

c:\windows\sysvol\domain nach wiederholten Versuchen aktiviert.

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

 

 

Ich hoffe ich konnte dir damit helfen. Eine Garantie kann ich dir leider nicht geben, da ich mir selber nicht 100%ig über die Auswirkungen von klist purge im klaren bin.

Link zu diesem Kommentar

Hat leider nicht geklappt, scheint wohl doch eine andere Ursache zu haben. Ich hatte schon mal angedacht, den Server umzubenennen, was ja seit W2K3 möglich ist. danach aus dem AD rauswerfen, und wieder neu einbinden. Meiner Meinung nach ist das schlimsste was passieren kann ein neuer Servername. Die Drucker binden wir per skript ein, wäre also von der Benamsung her nicht das Problem. Wäre das wohl praktikabel?

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...