Mehrere Fehler mit merkwürdigem Ausgang

[aeigb 11]

Hallo Boardianer,

 

ich habe heute morgen ein kurioses Problem, aber zuerst die Ausgangslage:

ein SBS2003-Server, voll gepatcht, läuft in einer VMware-Umgebung. Er hat 3GB RAM zugewiesen sowie zwei virtuelle Festplatten, auf der ersten ist das System und Exchange, auf der zweiten die Dateifreigaben. In der Nacht um 00:00 Uhr wird die Maschine zwecks Datensicherung heruntergefahren und danach, ca. 01:30 Uhr wieder gestartet.

 

Und nun zu meinem Problem:

es begann um 08:38 Uhr mit einem Eintrag in der Ereignisanzeige/Anwendungen: Userenv mit EventID 1058 und 1030. Diese Meldung wurde bis 09:19 Uhr sieben mal wiederholt und während dessen war kein Client in der Lage auf den Server zuzugreifen. Im Systemprotokoll kann ich keinen Eintrag bezüglich Fehler oder ähnliches finden.

 

Im Verzeichnis der Policies, die in der Fehlermeldung angegeben wurde, habe ich mir die Datei gpt.ini angesehen: dort steht als Name "Neue Gruppenrichtlinie" drin, eine mit einem solchen Namen habe ich aber nicht (mehr), die werden von mir entsprechend umbenannt, wobei ich seit einem Monat keine Gruppenrichtlinie mehr erstellt oder geändert habe.

 

Nachdem ich um 09:20 die Maschine neu starten lies kam die Meldung Systemprotokoll/Anwendungen/dsrestor mit EventID 1005 (DSRestore-Filter konnte keine Verbindung zum lokalen SAM-Server herstellen). Dazu habe ich per NTDSUTIL das Passwort neu gesetzt -> weiß aber nicht, ob es mit dem Hauptproblem zusammenhängt. Diese Meldung kommt nach bisher jedem Neustart, habe es jetzt aber nicht mit dem neu gesetzten Passwort probiert.

 

Hat irgendjemand den entscheidenden Tipp, was bei mir genau schief läuft bzw. warum der Server seinen Dienst komplett verweigert?

 

NACHTRAG: Laut Aussage des Kunden tritt dieser Fehler bereits länger in sehr sporadischen Abständen auf.

 

Gruß

 

aeigb

[Stephan Betken 43]

Du weißt aber schon, dass es nicht supportet ist, den SBS2003 zu virtualisieren?

[aeigb 11]

Hallo Stephan,

 

der Kunde kam erst letzte Woche auf uns zu, der Server wurde von jemand anderem installiert. Nichtsdestotrotz ist der Fehler meiner Meinung nach nicht auf die Virtualisierung zurück zuführen.

 

Der Fehler mit dem DSRestore ist nach der Behebung (wie beschrieben) nicht mehr nach dem Neustart aufgetreten.

 

Für einen kleinen Hinweis wäre ich dankbar.

 

Gruß

 

aeigb