departure

Sicher, daß die Profile beim Abmelden auch wirklich vollständig zurückgeschrieben und vom nächsten TS auch wieder vollständig gezogen werden? Das läßt sich ja wohl austesten. Nur 1 Byte mehr oder weniger wäre da ja schon verdächtig. Denn wenn das nach einiger Zeit dann doch klappt, ist es doch sehr wahrscheinlich, daß jeder TS erstmal profilmäßig abgeklappert wird. Ich weiß nicht, wie Du das Load Balancing eingerichtet hast, aber gerade beim Einsatz von Load Balancing kann es schon ordentlich lange dauern, bis jeder mal auf jedem TS drauf war. Außerdem würde ich die liegengebliebenen, lokalen Profilkopien jede Nacht oder frühmorgens entladen und löschen, sonst können sich ungute Mix-Effekte ergeben. Außerdem sollte ein Windows-Terminalserver täglich neu gestartet werden. Grüße

Hmm, ich verstehe das nicht. Ich bin hundertprozentig sicher, daß mir schon der W2K3-Terminalserver vor Jahren den Installationsmodus selbsttätig vorgeschlagen (und auswählbar gemacht) hat, wenn ich leichtfertig einfach eine "setup.exe" oder "install.exe" doppelgeklickt hatte. Das wird also durchaus irgendwie abgefangen. Ich weiß bloß nicht, ob das auch bei einem Deployment von selbst geht. Grüße

Hallo, ich bräuchte Eure Hilfe. Ich möchte den gelb markierten Radio-Button für alle User in unserem Netzwerk ändern, ohne das ich jeden Client aufsuchen und an jeden Client Hand anlegen muß. Ich habe mich schon durch unsere GPO's gewälzt, sowohl durch die Allgemeinen von Windows als auch durch die office-2003-spezifischen und leider nichts gefunden. Weiß jemand, ob und wie ich das für alle ohne Riesenaufwand zentral umstellen kann? Per GPO wäre mir am liebsten, finde aber den richtigen Punkt für die Einstellung nicht (wenn es ihn überhaupt gibt). Wäre klasse, wenn jemand etwas dazu wüßte. Vielen Dank erstmal. Grüße

Danke Euch. Ich werde wohl die 32-Bit Treiber neben den 64ern zusätzlich hinterlegen (hoffentlich ziehen die Clients dann die richtigen Treiber!). Grüße von departure

Hallo, wir haben mehrere HYPER-V-Server im Einsatz. Dicke Maschinen, Dual-Sockel Quad-Core-Xeons mit HT (also 16 logische Rechenkerne), 72 Gigabyte RAM, schnellen, Fibre-Channel angebundenen Storage dahinter undsoweiter. Es geht aktuell um den Einsatz zweier virtueller W2K8R2-Server als Druckserver auf einem der Hypervisor-Hosts. Die Hosts waren so konzipiert und eingerichtet/eingekauft worden, daß sie im Schnitt ungefähr 10 virtuelle Server beherbergen können. Die beiden virtuellen Server, die jetzt neu hinzukommen sollen, sollen nun auf einen der Hypervisor-Hosts. Dort läuft momentan nicht allzuviel, 2 bis 3 VDI-Rechner (XP und 7) 2 W2K3-Server und1 W2K8R2-Filserver. Meines Erachtens verkraftet die Maschine die beiden Server, die nun noch hinzukommen sollen, locker. Nun habe ich aber Ärger mit meinem Chef, der mir vorwirft, daß ich mich nicht nur auf meine Erfahrungen verlassen soll, sondern ein fundiertes Leistungsmonitoring über einen angemessenene Zeitraum betreiben soll, um beurteilen zu können, ob der angedachte Hypervisor w i r k l i c h noch die Leistung aufbringen kann, die beiden neuen virtuellen Server aufzunehmen. Der Vorwurf ist unberechtigt, da ein anderer, bau- und leistungsgleicher Hypervisor deutlich mehr und größere virtuelle Maschinen zu stemmen hat und dies leicht verkraftet, jedenfalls wurden noch keine Engpässe bemerkt. Doch nun muß ich wohl in den sauren Apfel beißen und auf dem angedachten Hypervisor die Leistung und die noch vorhandenen Reserven verläßlich und aussagekräftig messen. Was könnt ihr mir empfehlen? Nur als Hinweis: Zu einem Power-Shell-Studium fehlt mir momentan die Zeit, dennoch muß ich Meßergebnisse liefern. Wie geht Ihr da vor? Grüße von departure

Hallo, wir kriegen momentan immer mehr Windows 7 Professional Clients (32Bit) in unserem Betrieb. Bisher haben wir die Drucker (allessamt Netzwerkdrucker) immer lokal auf den Clients installiert, doch das wird uns jetzt zu aufwendig. Wir möchten stattdessen einen zentralen Druckserver stellen, der die Druckaufträge für die Clients spoolt. Nun haben wir damit aber, so befürchten wir, ein Plattformproblem. Die Clientplattform ist Windows 7 32-Bit (ein Wechsel auf 64-Bit bei den Clients ist nicht vorgesehen, viele Fachsoftwarehersteller geben uns darauf keinen Support). Ein zum Clientbetriebssystem passender Server wäre ja ein Windows 2008R2. Doch den gibt es nur in 64-Bit. Nun meine Frage: Kann ich die 32-Bit-Druckertreiber für Windows 7 überhaupt auf einem W2K8R2-Druckserver installieren? Falls nein, was wäre denn die geeignete Serverplattform für diesen Fall? Vielen Dank und Grüße von departure

O.K., dann nochmals vielen Dank an alle.

Danke, das hilft auf jeden Fall. Doch was ist mit der Plattform? Sind denn diese RSAT (von 2008) überhaupt geeignet, eine 2008R2-Domäne zu administrieren? Danke nochmal.

Hallo, ich hätt' gern mal ein Problem: Ich möchte von einem Windows 2008 (ohne R2) SP2 Standard Terminalserver aus eine Windows 2008R2 AD-Domäne verwalten. Was muß ich dazu installieren? Wenn ich die Beschreibung in diesem Link: Detail Seite Microsoft Remoteserver-Verwaltungstools für Windows Vista richtig deute, dann dienen die RSAT in diesem Download dazu, eine Windows 2008 (ohne R2)-AD-Domäne von einem Vista-SP1-System aus zu administrieren. Es existiert leider kein Download der RSAT für W2K8 (ohne R2), um von so einem Terminalserver aus W2K8R2" (also mit R2) zu administrieren. Es soll in erster Linie über MMC das Snap-In "Active Directory Benutzer und Computer", aber auch noch ein paar andere, z.B. die HYPERV-Konsole, aufgerufen werden können. Weiß da jemand was? Was muß ich installieren? Und brauche ich dazu auch noch zusätzlich die Side-by-Side-Extensions für Vista/2008? Danke Euch erstmal. Grüße von departure

Die per ICA-Protokoll auf den Terminalserver zugreifenden Clients sind was? Windows FAT-Clients? Windows ThinClients (XP Embedded usw.)? Linux ThinClients? Falls letzteres: Der ICA-Client für Linux ist demjenigen für Windows leider unterlegen, ein ziemliches Stiefkind bei Citrix, sieht man auch an der Versionsnummer, der ICA-Client für Windows ist längst bei Version 12.X, der für Linux seit mehreren Jahren fast unverändert bei 11.X. Wir mußten unsere Linux-basierenden ThinClients gegen solche mit Windows XP Embedded austauschen, um über Citrix am USB-Port des ThinClients scannen zu können. Grund: Der ICA-Client für Linux beherrscht keine TWAIN-Redirection über USB! Ich weiß nicht, was das für Kartenlesegeräte sind, doch leider ist es allgemein aktuell immer noch so, daß sich nicht jede Peripherie per ICA-Client mit dem TS verbinden läßt. Häufig auch deswegen, weil sich immer noch eine Unmenge an Hard- und Softwareherstellern noch gar nie mit dem Thema "Terminalserver" beschäftigt hat. Wir waren schon des öfteren gezwungen, Software lokal auf FAT-Clients zu installieren, weil die benötigte Peripherie nicht mit dem TS zusammenarbeiten konnte. Grüße von departure

Du meinst also den Fall, daß eine getrennte Sitzung von einem anderen Client an anderem Ort wiederverbunden wird und dort dann andere Drucker stehen, die nicht in die Sitzung verbunden sind? Bei uns ist in Citrix MetaFrame auch konfiguriert, daß getrennte Sitzungen von beliebigen Clients wiederverbunden werden können. Aber eigentlioch nur, weil's Nice To have ist, im Normalfall hockt der betroffene (getrennte) Anwender bei der Wiederverbindung an seinem angestammten Platz, wo die Drucker immer noch zu der Sitzung passen, von der er vorher getrennt wurde, weil er eben beim Wiederverbinden den Platz nicht gewechselt hat. Ich weiß deshalb leider auch keine technische Lösung. Ich würde das organisatorisch regeln und den Usern mitteilen und beibringen, daß sie sich in diesen Fällen (also Sitzung getrennt, Arbeitsplatz=Client gewechselt und wiederverbunden und dann falsche Drucker) einfach einmal ab- und dann gleich wieder anmelden sollen. Kommt denn dieser Fall überhaupt so oft vor und warum? Häufig getrennte Sitzungen lassen auf Netzwerkprobleme schließen, oder, daß der Terminalserver rumzickt. Und aktive Verbindungen an anderem Ort zu übernehmen muß doch wirklich nicht sein. Wenn die User wissen, daß sie den Platz wechseln, ist doch zuzumuten, offene Arbeit zu speichern und sich abzumelden und dann am anderen Platz wieder anzumelden. Geht unter Terminalserver normalerweise doch sehr flott. Grüße von departure

Yep, sind dann halbe/halbe verteilt. Dir nochmals Danke. Grüße von departure

Ja, aber die Printserver werden als virtuelle Maschinen in den Hypervisoren laufen.

Nö, unsere HYPER-V-Server sind alle Einzelkämpfer. Die LUN's, in denen die VHD's liegen, sind zwar per FC-Multipath verbunden und liegen in einem halbredundanten Storage, doch ein automatisches Failover gibt es nicht. Bisher auch nicht nötig gewesen, wenn wirklich mal ein Hypervisor ausfällt, wird der Inhalt der entspr. LUN manuell in eine andere LUN übertragen, die an einem funktionierenden Hypervisor hängt. Handarbeit also. Die Downtime vertragen unsere User aber ganz gut , das sind max. 15 Minuten bei dieser Vorgehensweise.

"TCPView" von Sysinternals zeigt Dir alle aktiven TCP/IP-Verbindungen an. Die User, die derzeit aktiv sind (also nicht im Urlaub, nicht krank usw. usf.) haben eine bestehende Verbindung (auch dann, wenn sie gerade nicht aktiv genutzt wird, also gerade kein Druckjob passiert). TCPView zeigt Dir die Client-Zugriffe entweder als IP-Adresse, oder, bei funktionierender Namensauflösung, mit Hostnamen an. Dann weiß Du schon mal, welche Clients auf den Druckserver zugreifen. Und dann hast Du hoffentlich irgendwo noch eine Liste, in der steht, welchem Client welcher Drucker (grundsätzlich) zugeordnet ist (ich weiß nicht, wie das steuerst, pflegst und organisierst). Aus diesen beiden Informationsquellen müßtest Du eigentlich herauskriegen, welche Drucker momentan verbunden sind. Die gerade nicht verwendeten kannst Du dann erstmal in Ruhe umziehen. Grüße von departure

O.K., Dankeschön, zugunsten einer sauberen Trennung kriegen unsere Windows-7-Fatclients zwei eigene W2K8R2-Druckserver (virtuelle). Ich war eigentlich auch schon soweit, wollte aber nochmal eine andere Meinung hören. Danke, daß Du mich da bestätigt hast. Grüße von departure

Sehr guter Vorschlag. Der gute Ruf von Thinprint hatte uns im letzten Jahr auch schon erreicht. Wir waren auch wild entschlossen, uns Thinprint zuzulegen, allerdings haben uns die Lizenzkosten für Citrix einen Strich durch die Rechnung gemacht, die uns teurer kamen, als zunächst angenommen. Thinprint wurde uns deshalb gestrichen, woran sich bis heute leider nichts geändert hat. Wie gesagt, guter Vorschlag, doch aus Kostengründen derzeit nicht machbar. Du scheinst Dich aber mit der Materie dennoch gut auszukennen, vielleicht kannst Du meine Frage in den letzten beiden Absätzen meines Eingangspostings trotzdem beantworten: Eigener W2K8R2-Druckserver für die Windows-7-Fat-Clients oder die beiden 2008-Druckserver mitnutzen und die Windows7/Windows2008R2-Druckertreiber zusätzlich hinterlegen? Grüße von departure

Hab' mal so ganz auf die Schnelle dies hier gefunden: Kontrollieren des sicheren Internetzugriffs mit ISA Server 2004 Beim groben Überflug meinte ich, daß mit dem Regelwerk des ISA sehr vieles sehr granular möglich ist. Vielleicht führst Du Dir diesen Artikel mal zu Gemüte, evtl. ist Deine Frage dann schon beantwortet. Grüße von departure

In welcher Funktion nutzt Du den ISA 2004? Als Proxy, als Firewall oder als beides?

Hallo, ich hätt' gern mal ein Problem: Wir nutzten bisher fast ausschließlich Terminalserver als generelle Plattform für unsere ca. 500 User (Windows 2008 [ohne R2] mit Xenapp 5.0). Wir haben den Desktop veröffentlicht und die User verwenden ThinClients (Linux oder XP Embedded). Die meisten kapieren da auch gar nicht, daß sie mehr oder weniger fernsehschauen, die ThinClients werden immer kleiner und dann kommen Kommentare wie "Wahnsinn, was in dem kleinen Ding alles drin ist" ;). Dieses Szenario betreiben wir seit Jahren mehr oder weniger problemlos. Doch jetzt tauchen Probleme auf, zu denen Ihr vielleicht einen Rat wißt: Leider, leider, leider müssen wir die User aus verschiedenen Gründen immer häufiger mit FAT-Client PC's ausrüsten (also vollwertige Kisten mit vollwertigem, lokalen Betriebssystem, stationäre PC's oder Notebooks). Hinsichtlich des Druckens verwenden wir ausschließlich Netzwerkdrucker. Für die Terminalservernutzer haben wir zum Drucken 2 Druckserver, die plattformgleich mit den Terminalservern auf Windows 2008 (ohne R2) laufen und den Terminalserverusern die Druckaufträge spoolen. Bei den nun leider immer mehr hinzukommenden FAT-Clients nutzen wir auch die Netzwerkdrucker, spoolen aber lokal, die Netzwerkdrucker werden also in den FAT-Clients lokal installiert. Nachdem die FAT-Client-Kisten immer mehr werden, kommen wir langsam in Bedrängnis, wenn es um die Pflege der Drucker auf diesen FAT-Clients geht. Es ändert sich ständig was, neue Druckermodelle kommen hinzu, Drucker fallen weg, es wird Druckerspeicher nachgerüstet, die Anzahl der Papierschächte ändert sich undsoweiter undsofort. Auf den beiden Druckservern, die von den Terminalservern aus genutzt werden, ist das alles kein Problem, die Änderungen werden zentral an den beiden Druckservern vollzogen. Doch auf den FAT-Clients ist das alles Handarbeit. Auch fehlt uns der Überblick, was an Druckern wo und wie lokal installiert ist. Ich habe nun die Möglichkeit, den Windows-7-FAT-Clients einen eigenen Windows 2008 R2 (also hinsichtlich der Treiber plattformgleich mit den Windows 7-FAT-Clients) Druckserver zu spendieren und die Drucker nicht mehr lokal zu installieren. Doch das will ich nicht, kostet uns eine weitere Serverlizenz (gut, virtuell im 2008 R2-Datacenter-HYPER-V kostet es keine Lizenz, aber es wäre trotzdem ein Server mehr, der ja nicht unbedingt sein muss). Nun (endlich) meine Frage: Ist es möglich, den Druckern in den bereits vorhandenen Windows 2008 Druckservern (die bisher nur für Druckaufträge vom Terminalserver gedacht waren) die Treiber für Windows 2008 R2 (= Windows 7) zusätzlich zu hinterlegen? Das heißt, fragt ein Windows-7-FAT-Client bei dem Druckserver Druckdienste an, zieht er den 2008 R2-Treiber, und nicht den 2008 (ohne R2). Außerdem muß gewährleistet sein, daß die Terminalserver weiterhin nur den 2008-Treiber (ohne R2) ziehen, denn Treiber für 2 verschiedene Windowsplattformen für einen Drucker auf Terminalserver sind tödlich, Bluescreens sind damit garantiert. Was meint Ihr? Vorhandene Druckserver mit zusätzlichen Treibern für die Windows-7-FAT-Clients ausrüsten, oder für die Windows-7-FAT-Clients einen eigenen Druckserver hinstellen (ggf. auch virtuell)? Danke. Grüße von departure

Nun ja, die Performancerisiken sind nun wirklich eigene Risiken. Auf das Drahtseil, einen DC nach der Inst. von EXCH2010 nicht mehr demoten/promoten zu können, würde ich aber auf keinen Fall aufspringen. Die Domäne ist wichtiger als Exchange, weil sie für die User und den Exchange überhaupt erst Voraussetzung ist.

Take That! Windows 7: Bibliotheken entfernen In der zip-Datei ist vermutl. eine Reg-Datei drin. Und das ist schon die halbe Miete. Denn mit einer Reg.-Datei kannst Du Dir eine Adm basteln (dafür gibt's Tools). Sind die Tools zu alt und bauen Dir nur nur eine adm, Du brauchts für Windows 7 aber eine admx, dann hilft Dir das Tool "ADMXMigrator.msi" (googlen hilft). Hast Du die admx (und die Sprachdatei) fertig, ab damit ins Sysvol, GPO in der richtigen OU erstellen bzw. verknüpfen, admx hinzufügen und schon kannst Du Deine Bibliotheken ausblenden (tut mir leid, daß ich so ironisch klinge, das kann schon so funktionieren, ist aber ein Mordsarbeit). Ist dann zwar alles Eigenbau, wenn Du's aber richtig machst, könnte das funktionieren. Grüße von departure

Das mit dem Richtlinienergebnissatz ist grundsätzlich schon richtig, wenn aber die Ausgabe von gpresult da nichts brauchbares anzeigt, führe doch stattdessen mal "rsop.msc" aus! Vielleicht gibt's da mehr zu sehen (da kommen die Ergebnisse grafisch). Grüße von departure

Es geht nicht darum, IP-Adressen mit der Gewalt aktiv auswendig zu lernen, sondern darum, daß man sie binnen relativ kurzer Zeit einfach auswendig weiß, wenn man sie öfter liest/öfter mit ihnen zu tun hat. Und das geht bei IPv4-Adressen so einfach, weil sie so kurz und überschaubar sind. Ich weiß jetzt auf Anhieb ohne langes Nachdenken die Adressen unserer beider DC's, des Exchange, des Proxy und der Terminalservermasterbrowser, ohne daß ich diese jemals aktiv und bewußt "gelernt" hätte. Wenn ich jetzt was an der Firewall konfigurieren muß, was diese Maschinen tangiert, weiß ich die Adressen einfach, ohne irgendwo nachsehen zu müssen und kann sie hinschreiben. Mit IPv6 wird das schlichtweg nicht mehr gehen, die Adressen sind einfach zu lang. Auch das zeigt, daß funktionierende Namensauflösung immer wichtiger wird. Wobei ich angesichts dessen nicht kapiere, warum unsere Firewall nach innen nach wie vor ausschließlich mit IP-Adressen hantiert anstatt mit Namen (Microsoft Forefront Threat Management Gateway Server). Grüße von departure

@NilsK: Es kann in diesem Fall allerdings sein, daß Fa. Sybase die Virtualisierung ihrer Datenbank nicht supportet. In dem Fall muß dann aber einfach weitere Hardware beschafft werden (und keineswegs eine Datenbankumgebung physisch einfach auf einen Hypervisor geknallt werden). Grüße von departure