XPhile
-
Gesamte Inhalte
54 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von XPhile
-
-
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
Quelle: NTDS LDAP
Fehler: 1535
Internes Ereignis: Der LDAP-Server hat einen Fehler zurückgegeben:
Zusätzliche Daten
Fehlerwert:
0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of:
'CN=File Replication Service,CN=System,DC=meinedomain,DC=local'
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:
Quelle: NTDS
Fehler: 1535
Internes Ereignis: Der LDAP-Server hat einen Fehler zurückgegeben:
Zusätzliche Daten
Fehlerwert:
00002071: UpdErr: DSID-030502F7, problem 6005 (ENTRY_EXISTS), data 0
Zwischendurch kommt noch folgende:
Quelle: NTDS
Fehler: 1317
Internes Ereignis: Der lokale Domänencontroller hat die LDAP-Verbindung von der folgenden Netzwerkadresse aufgrund einer Zeitüberschreitung getrennt.
Netzwerkadresse:
127.0.0.1
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:
Idee - naja, Vermutung trifft es besser.
Ich hatte ein ähnliches Phänomen und habe mehr oder weniger durch Zufall
herausgefunden, das ein- und derselbe User mehrere Session-IDs auf dem
Terminalserver hatte, herbeigeführt dadurch, das sich der User nicht
abmeldet, sondern einfach die Verbindung trennt und somit die Session
weitergeführt wird, teilweise über mehrere Tage hinweg.
Ein anderer User meldet sich an und bekommt die eigentlich schon vergebene
Session-ID (keine Ahnung, wie das passiert, war aber so) und somit auch die
dieser Session-ID zugeordnete Drucker-Warteschlange zugewiesen. Und schon
verirren sich die Druckjobs....
Gelöst habe ich das einfach durch striktere Richtlinien, was die Sessions
betrifft, Stichwort Zwangstrennung etc.
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.
-
die signalstärke bleibt auf hervorragend bis sehr gut ! hab das mit dem router schon getestet ! wie bekomm ich die timeout zeit raus ?
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.
-
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ß
-
Aber bei der Party bist du dann dabei. ;)
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
Betriebsmaster verliert AD?
in Windows Server Forum
Geschrieben
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