XPhile

ich könnt heulen, es ist schon wieder passiert. AD iss wech, DNS-Fehler noch und nöcher. Was zum Zeitpunkt des Fehler im Ereignislog stand anbei: Der Rest ist wie oben beschrieben. Problem ist, dass ich den Server jetzt nicht neu starten kann, weil sonst den Usern Ihre Daten flöten gehen. Die Last ist auch nicht höher als heute morgen, als noch alles funktionierte... Hat jemand noch ne Idee? Gruß Sascha

Iss i.O. kann ich aber nicht gebrauchen, da die Anmeldeinformationen Passwörter nur bis 15 Zeichen zulässt, unsere sind aber länger :-( Gruß

werde das mit der Chefetage besprechen und berücksichtigen. Gibt es noch weitere Ansätze, die zu dem Fehler führen können? Das System läuft schon in dieser Form über 1 Jahr. Was mich wundert ist halt, dass es so plötzlich auftritt. Gruß Sascha

Hi danke für die Antwort. Habe die Aufgabe geerbt und hab noch nicht so viel Erfahrung damit. Kann dir nicht sagen, warum die TerminalServer zu DCs gemacht wurden. Was bedeuted die DCs konsolidieren? Danke und Gruß

Hi Dirk, Ein Standort Genaue Userzahl kann ich dir nicht nennen, dürften um die 250 sein. Wir haben 6 DCs weil wir eine Branchensoftware über Terminaldienste anbieten. 4DCs teilen sich die Terminalsessions über NLB. Jeder unserer Kunden hat seine eigene Freigabe, welche sich auf dem Betriebsmaster befindet. Falls es nützlich ist: Tasmanager sagt aus: Handles: 25000 Threads: 600 Prozesse: 60 Betriebsmaster hat 2GB RAM und 500MB in Benutzung Gruß

Hi zusammen, System: W2K3-Domäne 6 DCs aktueller Patchstand Fehler tritt nur auf dem Betriebsmaster auf. Google und eventid.net helfen da leider nicht. netdiag läuft ohne Fehler durch, dcdiag ebenfalls. Folgende Einträge im Ereignislog, fallen mir auf, der Rest ist sauber Der Eintrag "best match of:" ändert sich jedes mal. U.a. sind auch folgende Einträge zu finden: 'CN=Dfs-Configuration,CN=System,DC=meinedomain,DC=local' 'CN=rechnername,OU=Domain Controllers,DC=meinedomain,DC=local Weitere Einträge, direkt nach dem Start des Servers sind folgende: Zwischendurch kommt noch folgende: Ich glaube, dass ist das Problem, welches dazu führt, dass der Server (vermutlich) unter Last sein AD verliert. Äußerst sich so, als das ich bei der Benutzerverwaltung und ähnlichem die Fehlermeldung bekomme: "Der Server ist nicht funktionsfähig". Dann bringen dcdiag/netdiag auch Fehlermeldungen, von wegen Domäne nicht gefunden. Nach einem Neustart klappt wieder alles, bis auf obige Ereignislogs. Fehler tritt nun schon das 2. Mal in 2 Tagen auf. Immer zur Hauptbelastungszeit (nach der Mittagspause) Server arbeitet auch brav weiter. Zugriff auf die Freigaben sind weiterhin möglich, Anmeldung am Server selber auch (nur Admins melden sich an),AD ist halt nicht verfügbar. Ist der Fehler da, dann hagelt es auch massig DNS-Fehler (4007, 4007,4013). Der DNS hat auch alle AD-integrierten Domänen verloren, bis zum nächsten Neustart. Sorry, dass es so ne Masse an Text ist. Danke und Gruß

Hi, ist das eine Andere als "UPHClean-Setup.msi"? Das Ding läuft schon als Dienst, kommt aber immer noch vor, dass manche Drucker nicht gelöscht werden. Tritt häufiger bei Epson-Tintenstrahlern auf, weil die den StatusMonitor nutzen, der Monitor knallt mal ganz gerne weg.

Es gibt neues von der Front. Habe einen Hinweis von den MS-Newsgroups bekommen: Das habe ich schon gemacht, Timeout läuft auf 30 Minuten Leerlaufzeit, dann wird getrennt. Getrennte Sessions werden nach 1 Minute zurückgesetzt. Was mir noch aufgefallen ist, ich habe abends, wenn alle raus sind, noch ein paar Heimatlose Drucker rumfliegen, die in mehreren Sessions gebunden sind. Die kann man auch nicht löschen, da hilft nur Serverneustart. Hat dafür jemand eine Lösungsvorschlag? Danke und Gruß

Hi und danke für die Antwort, das der eine User den Drucker des anderen Users sehen kann ist ausgeschlossen, da die Sicherheitseinstellungen der Drucker immer nur die Ersteller, das betroffene Userkonto und die Adminstratoren aufweisen. Ferner werden nur die Drucker der eigenen SitzungsID angezeigt. Das ist ja grad das seltsame, dass der Druckjob auf einem Drucker eines anderen Users einer anderen Sitzung rauskommt. Gruß

Hallo Board, ich habe hier ein störendes Problem mit verbundenen Druckern am Terminalserver. Vorabinfos: 5 W2k3-Server die sich die Terminalsession über NLB teilen. Clients sind über ganz Deutschland verteilt und nicht im gleichen lokalen Netzwerk. Die Clients verbinden sich über RDP und übergeben die lokalen Drucker. Drucker werden auch alle schön verbunden, jeder User hat auch nur seine(n) eigene(n) Drucker zur Verfügung. Ab und zu kommt es aber vor, dass der Druckauftrag eines Users(z.B. in München) auf dem Drucker eines anderen Users(z.B. in Berlin) rauskommt. Inwiefern das jetzt Serverübergreifend stattfindet kann ich nicht sagen, da die User natürlich erst anrufen, wenn das Ei schon lange ausgebrütet ist. Im konkreten Fall ist es gestern passiert und der Kunde ruft heute an :-( Ich weiss da nicht mehr weiter, da es auch unterschiedliche Drucker sind. Die User bekommen verschiedene Sitzungs-IDs und die Drucker werden ja an verschiedenen TS00x-Anschlüssen verbunden. Hat jemand ne Idee, wie sich ein Druckjob derart verirren kann? Danke und Gruß

hi, vielleicht ist deine tcpip.sys in mitleidenschaft gezogen worden. Hatte ähnliche Phänomene, konnte mir aber mit der Systemwiederherstellung behelfen.

Das mit der Timeoutzeit ist von Hersteller zu Hersteller verschieden. Musst mal im Manual nachschauen. Bei meinem (Firma SMC) nennt sich der Punkt "Disconnect Timeout". Ist unter den WAN-Einstellungen.

da kann man so pauschal nicht viel sagen. Wie ist denn die Signalstärke? Hast du schon mal probiert verschiedene Kanäle des Routers zu testen? Was sagt der Timeout? Liegt der vielleicht noch bei 5 Minuten oder ähnlichem?

lass doch mal den filemon oder den regmon mitlaufen, die sind immer aufschlussreich, wenn es um solche probleme geht. http://www.sysinternals.com

Hi kwakS, um welches Gerät geht es denn? Komponente auf dem Mainboard? Welcher Hersteller? schon mal auf der Herstellerseite oder bei http://www.treiber.de geschaut? Gruß Sascha

hi, wir hatten das Problem ebenfalls. Spielt sich alles am Client ab: Aktiviere den Druckerpool und weise dem Drucker einen 2. Anschluss auf LPTx zu. Ferner empfehle ich dir das RDP auf Version 3790 zu uppen, die Version 2600 war da etwas bockig, was die Drucker anging. Das hat alle Verbindungsprobleme mit Druckern bei uns behoben, insofern, als dass die identischen Treiber auf den TS verfügbar waren. Gruß

Würd ich ja gerne, aber aus dem Rheinland nach München fahren?? :suspect: Bin lieber hier ein gern gesehener Gast. :p und nerv euch mit Fragen... Gruß Sascha

habs auch mal gemacht, auch wenn es nicht mehr zählen sollte. skloeppel [at] googlemail.com Gruß Sascha