Canni

Hallo zusammen, unser Windows Server 2003 R2, der als Terminalserver fungiert, sollte ersetzt werden. Ich dachte an Windows Server 2008, schon allein aufgrund der neuen Funktionen im Bereich Terminalserver. Domänencontroller ist ein Windows Server 2003 R2, im 2003-Funktionsmodus. Clients sind XP Prof. Dass der Lizenzserver auf dem TS laufen muss, weiß ich. Ist zwar nicht die feine Art, aber geht. Was ist noch zu beachten? Welche Funktionen stehen mir NICHT zur Verfügung, weil ich als DC keinen 2008er verwende? Kann ich alle Gruppenrichtlinien, die 2008 unterstützt, über den 2003er einstellen? Da hat sich ja auch was geändert. Funktioniert SingleSignOn auch bei XP mit dem entsprechenden TS-Client? Danke !

Wahrscheinlich zu schwache Hardware. Jedes Software-Update fordert bekanntlich mehr vom Server, da die Anwendungen nicht schlanker, sondern eher umfassender werden. Wir werden uns nach einem neuen TS umsehen müssen. Grundlegende Empfehlungen dazu?

Hallo, wenn Du mittels Suche meine Threads gefunden hättest, wüsstest Du, wie ich mit dieser Thematik bereits in der Vergangenheit die Foren-Gemeinde geplagt hatte ;-) Auch bei uns findet keine VPN-Verbindung VOR der Windows-Anmeldung statt. Lass` die User das Kennwort doch bei bestehender VPN-Verbindung ändern. Das Ablaufen des Passwortes regulierst Du mit Zusatz-Tools, die auf ein abgelaufenes Passwort hinweisen.

Stimmt. Vielen Dank.

Danke ! Memory leak war bezüglich der Festplatten gemeint? Könnte der Engpass auch dann auftreten, wenn viele User auf dem TS arbeiten (= Prozessorauslastung hoch)?

Vielleicht ist ja hier ein Zusammenhang bekannt, den ich nicht kenne, wer weiß? Ich jedenfalls weiß derzeit nicht, wie ich das Produkt weiterhin einsetzen soll. Der Hersteller meint, dass weder die Abtastrate zu hoch, noch die Anzahl der Sensoren (= abzufragende Datenquellen) zu hoch seien. Was mich eben stört ist, dass keinerlei Fehler im Ereignisprotokoll des Servers zu finden sind !

Hallo auch ;-) Nein, die 90 Sekunden benötige ich natürlich nicht rund um die Uhr, aber wenn ich einen Dienst auf Verfügbarkeit überwachen möchte, dann sollte man das, so finde ich, nicht nur alle 5 Minuten. Bis dahin haben die user schon angerufen ;-) Der Support prüft derzeit den Fall, weiß aber auch nicht weiter. Mir geht es ja eher um den Zusammenhang zwischen stockendem TS und den WMI-Abfragen. Weshalb löst sich das Problem erst nach einem Neustart und nicht bereits nach Deaktivieren der PRTG-Dienste?

Hi, vielen Dank für Deine Mühe! Einen "Agenten" (heißt "Probe) hatte ich anfangs auf dem Terminalserver eingesetzt, sodass nicht so viele Abfragen durch das Netzwerk gesendet werden, sondern nur ein Port mit der Probe kommuniziert. Leider führte dieser zu selbigem Phänomen, nämlich dass der TS nach einiger Zeit stockt - dieses Stocken war nur durch einen Neustart zu beheben. Danach deinstallierte ich den Agenten und führte die Abfrage klassich über das Netzwerk durch - selbes Phänomen. Wie geschrieben, das PRTG-Log verweist auf "WMI timeout" oder "Abtastrate WMI zu hoch" - jetzt weiß man natürlich nicht, ob der Server ein WMI-Problem hatte und danach keine Abfrage mehr duchgeführt werden konnte oder ob die vielen Abfragen des PRTG zu eben diesem Problem führten ;-) Was meinste, wie soll ich vorgehen? Bin kurz davor, das Tool rauszuschmeißen. Obwohl es toll is.

Hallo auch, vielen Dank für die schnelle Antwort und Deine Hilfe ! Das Problem ist ja gerade, dass zu den betreffenden Zeiten nicht besonders viele Benutzer auf dem System gearbeitet haben. Der PRTG Network Monitor (Monitoring-Tool) fragt ja auch bereits seit 3-4 Tagen alle 90 Sekunden recht viele Dinge per WMI ab - aber warum kommt es immer erst nach längerer Zeit zu Problemen? Und nur auf diesem Terminalserver ! Danke ;-)

Hallo, bisher hatten wir nie mit Leistungsproblemen auf unserem Terminalserver zu kämpfen. Klar hatten wir bei vielen Usern nicht das schnellste Gerät - aber keine Probleme. Seit kurzem setze ich den PRTG Network Monitor zum Monitoring unseres Systems ein. Prinzipiell ein tolles System, aber: ca. alle 4 Tage wird unser Terminalserver so enorm langsam, dass ein flüssiges Arbeiten immer nur für wenige Sekunden möglich ist. Die Prozessorauslastung ist dabei normal (z.B. bei 3 Benutzern minimal). Im Ereignisprotokoll sind keine Fehler für den entsprechenden Zeitraum zu verzeichnen. Einzig die Monitoring-Software verzeichnet bei sich die Fehler, dass der Zugriff per WMI nicht mehr möglich ist und man die Abtastrate höher stellen sollte. Ist das Problem jemanden von Euch bekannt? Könnt ihr Euch dies erklären? Vielen Dank für die Unterstützung ! Canni

Gerne HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Achtung bei Änderungen an der Registrierung... muss ich aber ja nicht sagen :-)

So, "ekrn.exe" wird nicht bei jedem User gestartet - sondern nur 1x im Systemkontext. "egui.exe" wird bei jedem User gestartet, was ich über die Registry verhindere. Damit ist jetzt alles perfekt. Vielleicht hilft das hier anderen.

Hallo zusammen, welchen Virenscanner verwendet ihr aktuell auf Eurem Terminalserver? Wir nehmen NOD32 - perfekte Erfahrungen. Aber: für jeden User startet er den Prozess "ekrn.exe" neu - ist das notwendig? Wie verhalten sich hier Eure Virenscanner? Danke !

Hallo zusammen, heute Früh hat unser Terminalserver ziemlich gestockt. Hatte dies bisher einmal. Die Warteschlange des Prozessors war recht hoch. Sehr ihr eine Ursache oder eine Möglichkeit, das Problem in Zukunft zu umgehen? Danke vielmals, Canni

Danke. Ich glaube, hier legen viele Unternehmen einen zu geringen Fokus drauf. Ich kenne einige - auch große und bekannte Unternehmen - die nicht einmal ein AD haben, bei denen das Administrator-Kennwort jedem bekannt ist, der im Support tätig ist - und das auch nach dessen Austritt. Eine ähnliche Unsitte ist es ja z.B. auch, dass man Diensten häufig den Domänen-Admin-Zugang gibt - bei mir ist jeder Dienst (Ausnahme ist ein einziger!) "Benutzer" und verfügt über ein eigenes Userkonto. Ist auch viel übersichtlicher so.

Richtig, ist nachvollziehbar. Du sprichst von "lokalen Admin-Rechten". Meinst Du damit einen Domänen-Account (also im Active Directory eingerichtet) oder einen lokalen Account (also in der Computerverwaltung eingerichtet)?

Ich weiß auch, dass das in der Praxis nicht realisiert werden kann. Aber nachdenklich machen sollte es einem schon, dass XP die Anmeldeinformationen nicht synchronisiert. Somit ist ein geändertes Passwort eben doch nicht geändert, wenn man sich an einem Notebook ohne Domänen-Verbindung neu anmeldet. Wie arbeitet ihr auf euren Servern, sprich mit welchen Rechten ?

Das werde ich hier nun auch so umstellen. Jedoch, wie gesagt, die lokale Administration ist ja nur sehr selten notwendig. Wie verfahrt ihr mit dem Problem des Passwortwechsels - ignoriert ihr die Problematik der "cached credentials"? Ihr meldet Euch mit "SupporterABC" am Notebook XY an. Euer Kennwort für SupporterABC habt ihr an einer anderen Workstation gewechselt - damit es aber auf XY aktualisiert wird, müsstet ihr Euch dort bei bestehender Domänen-Verbindung (oder über "Ausführen als") anmelden. Wie handhabt ihr dies?

Ok. Wie administriert ihr dann z.B. Eure(n) Server? Oder meldet ihr Euch dort auch als "normaler" User an? Aber nochmal zu den Clients: verwendet ihr dort wirklich LOKALE Konten oder Domänen-Konten mit wenigen Rechten?

Nun, damit meine ich den Domänen-Administator. Der Vorteil liegt eben darin, dass ich ausschließlich Domänen-Benutzer verwende und keine lokalen. Würdet ihr also in Zukunft keine Administration mehr mit dem Domänen-Administrator durchführen auf den Clients, sondern nur noch mit lokalen-Admin-Konten arbeiten? Dass es das Domänen-Admin-Konto weiterhin gibt, ist klar.

Hallo zusammen, danke für die Antworten. Es macht doch immer Spaß, sich gegenseitig auszutauschen. Ich hoffe, wir haben nicht etwas aneinander vorbeigesprochen. Ich nenne mal "die Fakten" :-) : 1. Alle Notebooks/Desktops befinden sich in der Domäne (Domänenfunktionsebene: Windows Server 2003); 2. wir setzen ausschließlich XP Prof. ein; 3. bei fast allen Geräten handelt es sich um Notebooks, die sich an entfernten Standorten oder unterwegs befinden; 4. ICH arbeite in meinem Büro immer mit einem normalen Benutzeraccunt. Benötige ich administrative Rechte, verbinde ich mich z.B. per RDP auf unseren DC. Dort arbeite ich als DOMÄNE\Administrator. 5. Alle User arbeiten als normale Benutzer. 6. Auf unseren Clients gibt es das Benutzerkonto DOMÄNE\Administrator. Dieses verwende ich nur, wenn ich auf den Rechnern administrative Arbeiten durchführen muss (was aber - wenn man sein Netzwerk eben entsprechend aufgebaut /gepflegt hat - nur sehr selten vorkommt). Ändere ich nun das Passwort für den Domänen-Admin im AD, so ist dies den Notebooks erstmal egal - sie cachen ja das neue Passwort erst wieder, wenn eine Anmeldung von einem Client aus erfolgt. Was meint ihr zur Konstellation? Würdet ihr auf den Clients die Profile des Domänen-Admins löschen und stattdessen mit lokalen Admin-Konten arbeiten? Bin auf Eure Meinung gespannt. Canni

Ok, sondern? Wie würdest Du Maschinen verwalten, die in der Domäne sind? Doch nicht mit einem lokalen Admin-Konto?

Hallo zusammen, wer meldet sich denn mit zu hohen Rechten an? :-) Die Nutzer sind "Domänen-Benutzer". Aber jeder hat doch einen Domänen-Administrator-Account auf der Maschine, nicht? Dessen Kennwort im Cache aktualisiert sich erst nach der nächsten erfolgreichen Anmeldung, bei der der DC verfügbar ist (oder "Anmelden als" bei aktiver VPN-Verbindung). Daher meine Frage.

Vielen Dank. Sobald man dieses Suchfeld oben rechts ausblenden möchte per GPO, erscheint nacher die Meldung wegen des beschädigten Standardsuchanbieters. Was meint ihr dazu?

Hallo, erstmal müssen wir Deine Themen etwas trennen: Bezüglich der Gültigkeit am Terminalserver solltest Du Dich mit dem "Loopbackverarbeitungsmodus" beschäftigen: Einsatz von Gruppenrichtlinien auf einem Terminal Server Wie funktioniert der Loopbackverarbeitungsmodus? Ist eine sehr spannende Geschichte, wenn man es einmal verstanden hat und weiß, wie man den LBVM anwendet. Am TS das Internet verbieten? Gebe doch mittels GPO einen Proxyserver vor, den es überhaupt nicht gibt - damit leitest Du jede Anfrage in´s Niemandsland. Noch eleganter geht es aber natürlich, wenn Du eine entsprechende Firewall hast, auf der Du Regelwerke definieren kannst. Hoffe, ich konnte etwas helfen.