Kraftzwerg

Morgen, ich denke das Öffnen der Konsole wird am Terminalserver auf ähnliche Weise eingeschränkt. Dazu musst du halt den Schlüssel rausfinden, der für die Lizensierung zuständig ist. Denke aber in diesem Fall ist das nur die halbe Miete. In meinem Fall war es so, dass die MSC am Ende ja auf eine Anwendung am Terminalserver selbst zugreift. Dort hat der Benutzer die nötigen Rechte. In deinem Fall ist es aber so, dass der User nicht nur die MSC starten, sondern über sie auch auf einen anderen Server zugreifen können muss. Da musst du also am DC Rechte drehen, wenn es möglich ist. Genauso ist es im Prinzip, wenn man im TSadmin die Liste der Server vom Sessionbroker importieren will. Braucht man auch Adminrechte am SB und die Möglichkeit tsadmin am Terminalserver auszuführen. GL

Seid ihr sicher, dass es ein bug ist? Wir setzen auch eine Serverfarm auf 2008-Basis ein und der Fehler tritt nur bei XP Clients auf. Wichtig ist, dass man unter XP die aktuellste RDP Version (mit RDP 7 Unterstützung)und Netframework 3.5 einsetzt und CredSsp aktiviert hat. Danach hatten wir damit keine Probleme mehr. Hoffe wir haben nun nicht aneinander vorbei geredet;)

Hallo, die Option gibt es auch bei R1. Hatte das schonmal versucht. Leider braucht es dazu Adminrechte auf dem Sessionbroker. Im konkreten Fall ist es so, dass die Benutzer der Terminalserververwaltung keine Administatoren auf den Terminalservern bzw. dem Sessionbroker sind. Sie haben lediglich die Möglichkeit die Terminalserververwaltung auszuführen und die Benutzer zu betreuen. Muss in unserer Struktur so sein. Kenn jemand eine Möglichkeit das auch ohne Adminrechte zu lösen?

Hallo zusammen, ich habe eine Frage zum Tsadmin des 2008R1. Wir betreiben eine Serverfarm mit wachsender Anzahl an Terminalservern. Unter Server 2003 gab es in der Terminalserververwaltung einen Punkt "Alle aufgelisteten Server". Darunter wurden alle verfügbaren Domänen und die darin befindlichen TS aufgelistet. Durch Doppelklick kam man zur Übersicht der eingeloggten User etc. Dieser Punkt fehlt mir unter 2008R1. Wenn ich tsadmin öffne sehe ich nur den Server, auf dem ich selbst eingeloggt bin. Ich habe zwei Wege gefunden mich mit den anderen Servern zu verbinden: 1. Manuell connecten. Dann verliere ich aber die Verbindung zum ursprünglichen Server, sehe also immer nur einen zur selben Zeit und muss umständlich neu zu einem anderen connecten. 2. Ein Gruppe erstellen und dort alle Server reinpacken. So kann ich einfach zwischen den Servern hin und her schalten. Schon wesentlich besser, aber bedarf immer noch manueller Pflege, da neue Server (unsere Farm wächst die nächste Zeit immer weiter an) nachgepflegt werden müssen. Kennt jemand eine Möglichkeit das so dynamisch zu gestalten wie unter 2003? Gruß

Morgen, bin jetzt ein Stück weitergekommen. Das Problem scheint unter Vista, Win7 und 2008 Server bekannt zu sein. Dort gibt es auch einen Hotfix. Siehe hier Leider scheinbar nicht für XP. Muss da mal weiterforschen.

Hallo zusammen, ich habe wieder einmal eine Frage zu unserer Terminalserverumgebung. Es handelt sich um 2x2008R1 TS in einer gemeinsamen Farm mit NLB und Sessionbroker. Funktioniert alles wunderbar. Bislang auch das SSO von XP Clients mit SP3 und RDP 7.0. Seit kurzem haben wir ein SSL-Zertifikat auf den Namen der Farm bezogen und an den TS eingebunden, so dass es beim Anmelden zum Sichern der Verbindung verwendet wird. Wenn man sich von einem Win7 Client aus anmeldet, dann läuft alles super. Eine Anmeldung, alles prima. Wenn man sich nun von einem XP Client mit SP3 und RDP 7.0 verbindet, läuft die Anmeldung auf den Fehler "Die Verbindung wurde beendet, da ein unerwartetes Serverzertifikat vom Remotecomputer empfangen wurde..." Irgendwie muss das ja mit dem Zertifikat zusammenhängen. Vorher lief es ja. Bekam man eben die Zertifikatswarnung. Verwundert mich eben, dass es vom Win7 Client aus klappt. Bin für jeden Ansatz dankbar.

Tatsache, auf den Zielrechnern stehen wirklich deren lokale Gruppen drin. Hab das ganze gestern schonmal getestet. Könnt schwören da war es eben nicht so, sondern wie ich beschrieben habe... Nun gut. Danke dir jedenfalls für deine Hilfe!!! ;)

Hm, leider ist das nicht das was ich suche. Oder ich sehe es nicht richtig. Kann ja durchaus sein. In den Preferences kann ich ja Registryeinträge Zielorientiert vornehmen. Allerdings sollen ja alle den gleichen key nutzen. Geht glaube ich auch nicht anders, da es einer aus dem Class-Root-Bereich ist. Mir geht es ja darum die Berechtigungen auf den Key anzupassen, nicht den Key selbst. Leider ist es so, dass ich beim Modifizieren der GPO immer die lokalen Gruppen des Rechners, der die GPO modifiziert, eingetragen bekommen. Nicht die des Rechners auf die sie wirkt. Sprich: Ich modifiziere die ACL auf meinem Rechner. Dazu navigiere ich im GPO-Editor auf den entsprechenden Key unter Class root und bekomme die ACL angezeigt. Also wird dort "meinClient\administrators" und "meinClient\users" als Gruppen angezeigt. Wenn ich diese Settings für die GPO speichere, dann wird auch auf den Zielcomputern "meinClient\administrators" und "meinClient\users" stehen. Eigentlich sollte dort aber "Zeilcomputer\administrators" und "Zielcomputer\users" stehen. Natürlich könnte ich die Users durch eine Domänengruppe ersetzen, aber das bringt mir nachher wieder Probleme. Suche also eigentlich nach einer Variable, die ich für den Hostnamen eintragen kann, so dass immer administrators und users des jeweilgen Zielcomputers in die ACL eingetragen werden.

Hallo zusammen, habe gerade versucht die Berechtigungen eines Registry-Schlüssels via GPO zu ändern. Das System ist mir klar. Leider habe ich bislang keine Möglichkeit gefunden genau meine Anforderungen umzusetzen. Situation ist folgende: Key-XY hat folgende Berechtigungen: System:VZ Owner:VZ ComputerXX\Administrators:VZ ComputerXX\Users:Read ComputerXX steht dabei für den Namen des lokalen Rechners. Nun soll lediglich den Usern das Lesen verweigert werden. Also entweder ich lösche die Gruppe ganz oder ich verweigere ihnen das Recht. Soweit ok. Die GPO soll jedoch auf eine OU mit mehreren Rechnern wirken. Nun wird beim Einstellen der GPO ja die Berechtigung des Schlüssels für den Rechner ausgelesen, auf dem ich die Einstellungen vornehme. Also quasi mein Win7Client. Alle Rechner auf die die GPO wirkt bekommen dann für KeyXY die Berechtigungen: System:VZ Owner:VZ MeinWin7Client\Administrators:VZ MeinWin7Client\Users:Read Das bringts natürlich nicht. Kennt jemand ne Lösung, wie ich den Rechner "variabel" angeben kann. So dass am Computer "Hans1" auch Hans1\users steht etc.? Sowas wie "%computername%" oder "localhost"? Die tuns nämlich irgendwie nicht:( Thx

So, habe die Fehlermeldung nun wegbekommen. Bislang läuft es nur per Registry-Key, der via GPO an die User verteilt wird. Werde jetzt versuchen das noch in eine admx Datei einzubauen. Um die TSAdmin.msc zu den Ausnahmen der .msc hinzufügen zu können, müssen folgende Keys zu HKCU hinzugefügt werden: -Für das Snap-in "Terminalservermanager": Software\Policies\Microsoft\MMC\FX:{3FCE72B6-A31B-43ac-ADDA-120E1E56EB0F} -Für das Snap-in "Folders": Software\Policies\Microsoft\MMC\{C96401CC-0E17-11D3-885B-00C04F72C717} In beiden Keys ein Dword mit dem Namen "Restrict_Run" erstellen und den Wert "0" für zulassen bzw. "1" für nicht zulassen eintragen. Danach lässt sich tsadmin.msc als Benutzer starten. Welche Benutzer das dürfen kann man dann ja über Berechtigung steuern.

Hallo zusammen, würde auch gerne einigen Usern unserer Terminalserver das Ausführen der Tsadmin.msc erlauben und stehe vor dem gleichen Problem wir Christoph. Habe mir das GPO-Template mit den "freischaltbaren" Snap-ins mal mit dem ADMX-Editor angesehen. Dort wird bei Freischaltung im Reg-Key: Software\Policies\Microsoft\MMC\XXX der Wert "Restrict_Run" auf 0 gesetzt. XXX steht dabei für das jeweilige Snap-in. Hab diesen Schlüssel für TSAdmin.msc einmal per GPO erzeugt. (User-Config\Einstellungen\Windows-Einstellungen\Registrierung). Nun kommt zunächst die Meldung "The snap-in below, referenced in this document, has been restricted by policy..." Bestätigt man diese mit ok, dann lässt sich die TSAdmin.msc normal starten und nutzen. Die Meldung kommt nicht, wenn man eine der voreingestellten .msc in den GPO "freischaltet". Kennt das jemand und hat nen Lösungsansatz?

Servus zusammen, hat jemand mittlerweile ne Lösung für dieses Problem? Haben unsere TS über GPO soweit dicht gemacht. Nun hängt es eigentlich nur noch an der Adressleiste. Über den Registry Eintrag "NoNavBar" kann man diese für den IE ganz toll ausblenden. Nur für den Windows Explorer bin ich noch nicht fündig geworden. Wäre klasse wenn da jemand nen Tipp hätte.

Servus zurück, habe mir jetzt selbst helfen können. Falls es noch wer braucht, so haben wirs jetzt gelöst: In den GPOs des 2008R2-Servers gibt es ja unter Benutzer- und Computereinstellungen jeweils den Bereich "Einstellungen". Dort kann man unter "Windows-Settings" - "Ordner" auswählen und einen neuen Pfad angeben. Nun einfach den Ordner angeben, den man ausblenden möchte und in den Eigenschaften "Versteckt" aktivieren. Hat bei uns wunderbar funktioniert. Allerdings kann man den Ordner "Programs" im Startmenü nicht direkt ausblenden. Man muss alle Unterordner einzeln verstecken. Der Programsordner ist dann leer.

So, haben die Sache jetzt gelöst. Zumindest den ordnungsgemäßen Import. Unser Fehler war, dass wir den offenen Request am Exchange-Server (dort haben wir ihn ja über Powershell erstellt) gelöscht hatten. Dachten, dass er am Exchange ja nicht mehr benötigt würde und nur stört. Da aber dieser offene Request den pirvaten Schlüssel enthält konnte ohne ihn der Import nicht abgeschlossen werden. Haben den gleichen Request erneut ausgeführt, beim Zertifikatsaussteller ein Re-Key durchgführt und den Request ordnungsgemäß beendet. Anschließend das Zertifikat inkl. Key am Exchange exportiert und an den TS in den lokalen Speicher importiert. Nun kann man es in den RDP-Settings anwählen. Aktuell besteht leider noch folgender Fehler: Bei der Anmeldung an der TS-Farm über RDP kommt die Meldung "Es konnte keine Sperrpüfung für das Zertifikat durchgeführt werden" Ist das schon mal wem untergekommen? Bei uns kennt sich keiner so recht mit dem Zertifikatsthema aus, daher läuft es etwas holprig. Bitte um Entschuldigung, wenn das hier Zertifikats-Grundwissen ist;) Gruß

Hallo zusammen, ich würde gerne den Ordner "Programme" aus dem Startmenü via GPO ausblenden. Es handelt sich um einen 2008R1 64 bit Terminalserver. In den Gruppenrichtlinien habe ich einen Eintrag für das Ausblenden gefunden (Benutzerkonfiguration-Administrative Vorlagen-Startmenü und Taskleiste), allerdings scheint der aber nur für das 2008-Standardmenü zu greifen. Wir haben aber das "klassische Startmenü" aktiviert. Dort greift der Eintrag wohl nicht. Setzt man den Eintrag "Benutzerordner aus dem Menü Start entfernen", dann ist der Programmordern zwar leer, aber noch da. Wäre ok. Leider wird mit dem Benutzerordner auch der "obere Teil des Startmenüs ausgeblendet und diesen widerum brauchen wir zu andern Zwecken. Hat jemand eine Möglichkeit den Programmordner direkt auszublenden? Hier hatte jemand das gleiche Problem, aber keine Lösung: http://www.mcseboard.de/windows-forum-allgemein-83/ordner-programme-startmenue-verschwinden-lassen-108382.html Thx

Guten Morgen, uns wurde es als SAN-Zertifikat "verkauft". Ist ein SSL Zertifikat. Es enthält neben dem Commonname noch die Namen aller TS und des NLB-Clusters. Das mit dem ausstellenden Server ist ein guter Hinweis. Wir haben den Zertifikatsrequest nämlich am Exchange erstellt. Aber auch dort hat der Import nicht das gewünschte Ergebnis gebracht. Ich habe nun beim Anbieter nachgefragt und mir wurde nahegelegt den Schlüssel neu zu erstellen. Sobald ich Zeit dazu habe, werde ich es versuchen. Melde mich mit dem Ergebnis. Wenn jemand einen anderen Ansatz hat, bin ich sehr interessiert;)

Moin, also der Gruppenrichtlinienergebnissatz ist definitiv wichtig für den Lösungsansatz. Wenn du weisst welche Richtlinie die Einstellungen beinhaltet, dann schau dir mal die Berechtigung an dieser GPO an. Kann sein, dass du "normalen Benutzer" keine Rechte haben die GPO zu lesen bzw. zu übernehmen. Gruß

Kann es sein, dass die GPO für die Admins nicht greift und die Suche für die "normalen Benutzer" via GPO deaktiviert ist?

Hallo zusammen, ich habe bereits die SuFu benutzt, aber meine Frage konnte nicht beantwortet werden. Vll liegt das aber auch an mir. Folgende Situation: mehrere Terminalserver mit Win2008R1 x64. Zusammengefasst zu einer TS-Farm inkl. NLB-Cluster. Nun das bekannte Problem. Wenn man sich am Cluster anmeldet, bekommt man einen Zertifikatfehler, da das ausgestellte Zertifikat nicht mit dem Namen des Clusters übereinstimmt. Aus diesem Grund haben wir über eine Zertifizierungsstelle (soll auch von außen, pber die Domänengrenze hinaus erreichbar sein) ein SAN-Zertifikat beantragt. Nun haben wir ein .crt-file erhalten, welches ich testweise am ersten TS manuell in den lokalen Zertifikatsspeicher importiert habe. Leider kann ich das Zertifikat in den Eigenschaften des RDP in der Terminalservices-configuration nicht auswählen. Feld ist weiterhin leer. Bei unseren Tests hatten wir bislang auch .pfx-files (also mit Key) in den lokalen Zertifikatsspeicher importiert. Diese Zertifikate waren dann auswählbar. Hat jemand einen Hinweis für mich?

OK, habe den schuldigen Server in unserem Netz gefunden. Aber mehr zufällig. Wäre also gut, wenn jemand ne Möglichkeit wüsste, wie man ermittelt bei der Anmeldung an welchem TS die CAL angefragt wurde.

Hallo, habe neulich auch so einen "Fehler" gemacht. Umstellen kannst du m.E. problemlos. Habe ich auch gemacht. Nun bestehen eben zunächst mal die temp-Lizenzen weiter bis zum Ablaufen. dürfte auch ein event Eintrag mit der ID 1009 im Systembereich auftauchen, oder!? Um ganz sicher zu gehen, dass keine neuen "pro Gerät Lizenz" ausgestellt wird kannst du folgendes machen: Von einem Client, der noch nie mit irgend einem TS verbunden war, an den besagten TS anmelden. Wenn nun keine Lizenz ausgestellt wird, ist alles richtig. Da habe ich aber nochmal eine Frage in eigener Sache, geht aber auch um dieses Thema: Kann mir jemand sagen, ob man irgendwie ermitteln kann, woher die "per Device" CALs kommen? Also ob es eine Kennzeichnung gibt, bei der Anmeldung an welchem TS sie beim Lizenzserver beantragt wurden? Ich habe nämlich trotz eingestelltem "pro user" Lizenzmodus weiterhin einige wenige frisch ausgestellte temporäre "per device" Lizenzen am Lizenzserver herumgeistern. Allerdings müssten es sehr viel mehr sein, wenn es von "meinen" TS kommt. Dort melden sich ca. 50-80 User an. Lizenzen sind aber nur 2-3 ausgestellt. Vermute also, dass irgendwo im Netz noch ein TS auf "per device" steht. Daher die Hoffnung, dass die Lizenzen irgendwo ein Merkmal haben von wem sie beantragt wurden.

Hallo, das klingt doch schonmal beruhigend. Werden freilich noch einige Tests machen bevor das System in der Form produktiv wird. Aber an alles kann man halt nicht denken. Wenn jemand jetzt schon direkt etwas gewusst hätte, dass ein K.O.-Kriterium gewesen wäre, wärs eben gleich rum gewesen. Das "Mehr" an Ressourcen stelle ich mir jetzt einmal vor wie damals von Vista zu Win7. Werden wir natürlich noch kritisch beleuchten müssen, damit die physikalischen Maschinen richtig dimensioniert sind. Danke für die Antworten! Sollte noch wem was einfallen, dann immer raus damit ;)

Hey, dass ging fix;) Hast schon recht, die Antwort ist mehr als umfangreich, wenn man alle Details berücksichtigt. Hab daher versucht unsere Absicht zu beschreiben, damit man sieht welche Funktionen im Wesentlichen benötigt werden. Mir geht es ja eher darum, ob jemand weiss, wie sich R1 in einer Terminalserverfarm mit Sessionbroker verhält. Sind das nicht eigentlich Mechanismen die erst mit R2 wirklich angepriesen wurden? Mich hat eben diese IP-Stickiness-Meldung aufmerksam gemacht. Beim betroffenen Teil des ERP handelt es sich um ein Konfigurator-Modul der Firma IFS. Denke diese Software ist nicht so sehr verbreitet wie z.B. SAP. Das ist wohl das Problem. Wäre dem so, würde sicher an der Umsetzung für 2008R2 gearbeitet.

Servus, wir haben vor zukünftig folgendes Szenario auf die Beine zu stellen: Zwei oder mehr physikalische Server Server werden mit 2008R2 Enterprise eingerichtet und zu einem Failovercluster zusammengefasst. Zusätzlich führen Sie Hyper-V aus. Darauf soll eine Terminalserverfarm (mit Loadbalancing und Sessionbroker) aus virtuellen Servern laufen. OS soll ebenfalls 2008R2 Enterprise sein. Haben das in einem Testsystem aufgebaut. Funktioniert soweit gut. Jedenfalls in dem Rahmen, in dem wir es testen können. Nun dienen die TS in erster Linie als Plattform für unser ERP-System. Dieses hat aber keine Freigabe für 2008R2, sondern lediglich für 2008R1 64bit. Lässt sich auch auf 2008R2 erst garnicht installieren. Denke es ist sicher mit etwas genauerem Betrachten der Registryberechtigungen (wurden m.W. bei R2 verschärft) zum Laufen bringen würde. Support gibt es aber keinen vom Hersteller. Ohne den wollen/können wir es aber nicht betreiben. Nun stellt sich die Frage, ob wir wesentliche Einschränkungen haben, wenn wir die Terminalserver mit 2008R1 64bit statt 2008R2 installieren. Weiss da jemand was konkretes dazu? Habe mich schon zu den Neuerungen eingelesen. Aber nicht wirklich erkennen können, ob es für uns Nachteile hätte. Soweit ich weiss, nutzt R1 den Vista und R2 den Win7-Kernel und bei R2 wurden einige Neuerungen implementiert. Zudem würde es uns mehr Lizenzen kosten, weil die 1+4-Regel (1 physikalische, 4 virtuelle Installationen) mit einer R2-Enterprise-Lizenz nicht möglich ist. Ich habe testweise einen TS mit 2008R1 64bit installiert und in das bestehende 2008R2 System (TS-Farm etc) integriert. Es gab lediglich beim NLB-Cluster die Meldung, dass IP-Stickiness nicht unterstützt wird. Kann jemand in kurzen Worten zusammenfassen, was IP-Stickiness ist? Wird im Netz gerne mit statischen IPs vermischt, was für mich in unserem Zusammenhang nicht passt. Könnte mir nur vorstellen, dass es mit dem erneuten Verbinden bzw. Senden von Anfragen an den gleichen TS innerhalb einer Farm zu tun hat. Loadbalancing und Wiederverbindung via Session-Broker funktioniert aber augenscheinlich. Mir ist aber unwohl das System ohne fundiertes Wissen über die Unterschiede/Nachteile einzusetzen. Wäre super, wenn jemand mir was dazu sagen könnte. Gruß

Morgen, erstmal Frohes Neues! Unser Problem ist bislang noch nicht gelöst, ist aber genauso begründet wie in den anderen Fällen. Es gibt Betreuer für die Anwendungen auf dem TS, die alle damit in Verbindung stehenden Prozesse verwalten können sollen. Eine mögliche Alternative für uns wäre schon, dass diese Betreuer die Prozesse aller Benutzer einsehen können, ohne diese zu verwalten. Wenn dadurch ersichtlich ist, welcher Prozess u.U. hängt oder eine hohe Hardwareauslastung verursacht, könnte der entsprechende Benutzer informiert werden. Dieser könnte ja dann den Prozess selbst beenden. Nicht ganz so schön, aber im Rahmen finde ich. Fragt sich nur, ob es eine Software gibt, die einem normalen Benutzer die Einsicht in die Prozesse aller Benutzer gibt. Wird ja sicher durch die Rechte verhindert.