Terminalserver beendet sich immer wieder nach einiger Zeit

[Schaetzer 10]

Hallo Leute,

 

 

zu aller erst zu unserer Konfiguration des Netzwerkes:

 

Wir haben einen Windows 2003 Terminalserver und einen Windows 2003 SBS mit Exchange, DC, DNS. Dazu ca. 10 Clients (Windows XP und Vista). (alle auf aktuellem Stand)

 

Nun zu unserem Problem:

Wir haben ein mittelschweres Problem mit unserem Terminalserver.

Nach einiger Zeit und ohne ersichtlichen Grund können alle Terminalservernutzer nicht mehr in ihrem Terminal mehr arbeiten. So als ob ich den Terminalserver im laufenden Betrieb den Netzstecker ziehen würde.

 

Gleichzeitig funktioniert der Terminalserver erst dann wieder, wenn ich den Domänencontroller (ja den DC (!)) neu gestartet habe.

 

Danach können die User wieder neu arbeiten und alles geht wieder für einige Zeit (zwischen 1h - 8h).

 

Heute hats dann auch noch den Exchangeserver erwischt (liegt auch auf dem DC). Dort gingen keine Emails mehr raus und ca. 1h später verabschiedete sich wieder der Terminalserver. Erst der Neustart konnte das Problem "kurzfristig" wieder lösen.

 

Die Dienste sind zum Zeitpunkt des Ausfalles weder gestartet noch beendet worden (weder manuell noch automatisch).

 

Auch haben wir bisher nichts an den Servern geändert außer durch Neustarts das Problem umgangen. Des weiteren wurde an den Servern die letzten 2 Wochen keine Konfiguration geändert.

 

Auch das Ereignisprotokoll hat bisher wenig Ergebnisse gebracht.

 

Der DC zeigt keine Fehlermeldungen an. Der Terminalserver jedoch gibt folgenden Fehler aus:

 

Typ: Fehler

Quelle: Userenv

Ereigniskennung: 1058

Beschreibung:

Auf die Datei "gpt.ini" des Gruppenrichtlinienobjekts CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Richtlinien,CN=System,DC=<Domänenname>,DC=DC=<TopLevelDomain> kann nicht zugegriffen werden. Die Datei muss im Pfad <\\DomainName.com\sysvol\DomainName.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini> vorhanden sein. (Die Konfigurationsinformationen konnten vom Domänencontroller nicht gelesen werden. Der Computer ist entweder nicht verfügbar, oder der Zugriff wurde verweigert.) Die Verarbeitung der Gruppenrichtlinie wird abgebrochen.

 

 

Des weiteren ist mir aufgefallen (auch wenn ich nicht weiß, ob dies zum Problem gehört), wenn ich einen gpupdate /force auf dem DC ausführe, protokolliert er mir ca. 40 mal die gleiche folgende Fehlermeldung:

 

Ereignistyp: Fehler

Ereignisquelle: DCOM

Ereigniskategorie: Keine

Ereigniskennung: 10020

Datum: 23.05.2005

Zeit: 11:10:33

Benutzer: Nicht zutreffend

Computer: SERVER

Beschreibung:

Die computerweite Start und Aktivierung-Sicherheitsbeschreibung

(Standard) ist ungültig. Sie enthält Zugriffssteuerungseinträge mit

ungültigen Berechtigungen. Die angeforderte Aktion wurde daher nicht

ausgeführt. Diese Sicherheitsberechtigung kann mit dem

Verwaltungsprogramm für Komponentendienste korrigiert werden.

 

 

Nun habe ich folgende Lösungsmöglichkeit, nur wollte ich zuvor fragen, dass obwohl wir einen SBS 2003 mit SP2 haben und dies trotzdem des Pudels Kern sein könnte:

 

Ein Domänencontroller, auf dem Microsoft Windows Server 2003 ausgeführt wird, reagiert möglicherweise für einen Zeitraum von 2 bis 15 Minuten mehrmals am Tag nicht mehr

[simonak 10]

Ist der Terminalserver in der Domäne aufgenommen?

 

Interessant wäre ob der Terminalserver per Ping zu erreichen ist, wenn du dich nicht mehr darauf anmelden kannst. Einmal Ping auf DNS-Name und einmal Ping auf direkte IP-Adresse. Vielleicht spinnt der DNS Server auf eurem DC?

 

Wir hatten mal das Problem, dass sich automatisch immer die IP-Adresse eines Terminalservers auf DHCP umgestellt hat. Da sind wir dann natürlich auch nicht mehr drauf gekommen.

[Schaetzer 10]

Ist der Terminalserver in der Domäne aufgenommen?

 

Interessant wäre ob der Terminalserver per Ping zu erreichen ist, wenn du dich nicht mehr darauf anmelden kannst. Einmal Ping auf DNS-Name und einmal Ping auf direkte IP-Adresse. Vielleicht spinnt der DNS Server auf eurem DC?

 

Wir hatten mal das Problem, dass sich automatisch immer die IP-Adresse eines Terminalservers auf DHCP umgestellt hat. Da sind wir dann natürlich auch nicht mehr drauf gekommen.

 

Ein DNS Problem hatte ich auch schon gedacht, aber der Terminalserver und der DC erreichen sich gegenseitig nach dem Terminalserverausfall per ping (auch über die Namensauflösung). Wie gesagt ich gehe eher von einem DC Problem aus...

[Sunny61 772]

Das mit dem 1058er Fehler sieht für mich sehr nach SMB-Signing aus. Stell das doch gem. BestPraxis ein: SMB Signing - Einstellungen für: Kommunikation digital signieren

[Schaetzer 10]

Das mit dem 1058er Fehler sieht für mich sehr nach SMB-Signing aus. Stell das doch gem. BestPraxis ein: SMB Signing - Einstellungen für: Kommunikation digital signieren

 

Gesagt getahn, selbes Problem...

[Sunny61 772]

Gesagt getahn, selbes Problem...

 

Hast Du auch kontrolliert, ob das auf allen betroffenen Clients/Server ankommt? RSOP.MSC hilft dir dabei.

 

Sind die 1058er Fehler auf dem TS weg?

[Schaetzer 10]

Hast Du auch kontrolliert, ob das auf allen betroffenen Clients/Server ankommt? RSOP.MSC hilft dir dabei.

 

Sind die 1058er Fehler auf dem TS weg?

 

Das Problem ist sie treten sehr sporadisch auf. Mal ist einen halben Tag gar nichts, dann über Nacht mehrere male. Mithilfe von RSOP.MSC habe ich gesehen, dass die Gruppenrichtlinien auch gegriffen haben.

 

Des weiteren, was mir sehr komisch vorkommt ist, dass wenn ich ein gpupdate /force mache, jeder Client und der Terminalserver kein Problem hat die GPO's zu aktualisieren.

 

Wenn ich jedoch ein gpupdate /force auf dem DC mache, aktualisiert er mir zwar die Richtlinien, aber schmeißt mir zig mal den DCOM Fehler aus.

 

Ich weiß langsam echt nicht mehr weiter.

 

Jedoch was mir auch noch aufgefallen ist, dass seit drei Tagen auch die Datensicherung auf dem DC nicht mehr funktioniert. ArcSERVE sichert nicht mehr auf die Bandlaufwerke. Und wie es scheint, so bald er versucht zu sichern, beendet sich der Terminalserver (was er auch soll) kommt aber nicht mehr wieder hoch (nur über den Umweg net stop DFS ... net start DFS in der cmd des DC's)

[Sunny61 772]

Das Problem ist sie treten sehr sporadisch auf. Mal ist einen halben Tag gar nichts, dann über Nacht mehrere male. Mithilfe von RSOP.MSC habe ich gesehen, dass die Gruppenrichtlinien auch gegriffen haben.

 

Des weiteren, was mir sehr komisch vorkommt ist, dass wenn ich ein gpupdate /force mache, jeder Client und der Terminalserver kein Problem hat die GPO's zu aktualisieren.

 

OK.

 

Wenn ich jedoch ein gpupdate /force auf dem DC mache, aktualisiert er mir zwar die Richtlinien, aber schmeißt mir zig mal den DCOM Fehler aus.

 

Ich weiß langsam echt nicht mehr weiter.

 

Dann stell das auf dem DC mal in der Registry direkt ein, steht auch AFAIR so im Artikel drin. Dann kannst Du ja ein gpupdate /force laufen lassen. Der DC kann die GPO nicht übernehmen, wenn Du es in der Registry einträgst, hast Du 5 Minuten Zeit, dann kommt wieder die Einstellung aus den beiden GPOs.

 

Jedoch was mir auch noch aufgefallen ist, dass seit drei Tagen auch die Datensicherung auf dem DC nicht mehr funktioniert. ArcSERVE sichert nicht mehr auf die Bandlaufwerke. Und wie es scheint, so bald er versucht zu sichern, beendet sich der Terminalserver (was er auch soll) kommt aber nicht mehr wieder hoch (nur über den Umweg net stop DFS ... net start DFS in der cmd des DC's)

 

War das schon mal anders? Fehlermeldungen im Eventlog?

[Schaetzer 10]

Noch mal ein Nachtrag zum gpupdate /force auf dem DC. Der DCOM-Fehler mit ID 10020 scheint weg zu sein. Und die Clienten scheinen alle die GPOs gefressen zu haben.

 

Allerdings habe ich das Gefühl, dass alle Fehler irgendwie mit der Datensicherung zusammenhängen, die fehlschlägt. Sobald der Job gestartet wird, werden ja die meisten Dienste auf dem DC (wie z.B. auch Dienste die für den Terminalserver erforderlich sind) beendet (was nach Aussage einiger Kollegen in der Aussenstelle wohl schon immer so war). Allerdings startet ArcServe die Dienste wohl nicht wieder neu.

 

Der Fehler tritt fast immer dann auf, wenn die Datensicherung angestoßen wird und zieht sich über die Nacht hinweg.

 

Seit drei Tagen ist die Datensicherung nach dem Ereignisprotokoll von ArcServe ausgestiegen und hat folgenden Fehler protokolliert:

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

Fehler 6300

 

SCSI PORT-Fehler in Windows NT

 

Modul:

 

Bandprozess

 

Ursache:

 

Diese Fehlermeldung weist darauf hin, dass BrightStor ARCserve Backup ein Problem beim Senden eines SCSI-Befehls an das SCSI-Gerät erkannt hat.

 

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

 

Da dort bisher noch das SP§ und noch nicht das SP4 installiert ist werde ich das als nächstes machen.

[Sunny61 772]

Wow, ein W2K-Server in der heutigen Zeit ohne SP4 ist IMHO vorsätzlich. Und wie siehts mit den Updates im allgemeinen aus? Habt ihr keinen WSUS im Einsatz?

[Schaetzer 10]

Wow, ein W2K-Server in der heutigen Zeit ohne SP4 ist IMHO vorsätzlich. Und wie siehts mit den Updates im allgemeinen aus? Habt ihr keinen WSUS im Einsatz?

 

Ne ne der Server ist ein Windows 2003 SBS mit SP2 ;) ich sprach vom SP4 des ArcServe Backupprogrammes ;)

[Sunny61 772]

Ne ne der Server ist ein Windows 2003 SBS mit SP2 ;) ich sprach vom SP4 des ArcServe Backupprogrammes ;)

 

Glück gehabt. ;)

[Schaetzer 10]

Ich wollte nur noch kurz das HappyEnd angeben.

 

Es lag nicht an einer falschen Konfiguration von Windows 2003 SBS oder der Regisirierung.

 

Es lag tatsächlich an CA ArcServe Backup 11.5 SP3. Ein Tag zuvor ist diese auf dem DC ausgestiegen und hat alle paar Stunden unsere Domäne abgeschossen (incl. Terminalserver) warum das passiert ist ka. Das ganze lief ein Jahr mit der Software wunderbar.

 

Jedenfalls habe ich das CA ArcServe Backup 11.5 SP4 sowie die aktuellsten Sicherheitsupdates und Treiberupdates für das Bandlaufwerk (Tandberg TS400) installiert und nun sind die Fehler wieder weg und der Server sichert wieder.

 

Falls noch mal jemand das Problem haben sollte und nicht 2 Tage nach suchen muss ;)