Gulp

Zwischen schon installiert und tatsächlich vom jeweiligen Hersteller für Terminalserver freigegeben kann durchaus schonmal ein Unterschied bestehen. Die Warenwirtschaftssysteme, die ich noch kenne, sind entweder normale Server/Client Systeme, bieten keine Terminalserverunterstützung oder bieten nur TS Unterstützung mit Hersteller eigener (eigen-vorbereitet) Hardware. Bankprogramme laufen unter Umständen zwar auf Terminalservern, sind aber meist weder dafür freigegeben, noch vorgesehen. Beim Rechnungswesen sprich Buchhaltung sehe ich noch am meisten Chancen, dass diese auf Terminalservern unterstützt wird. Wobei ich auch zugeben muss, dass ich da jetzt nicht mehr so dicht am Thema bin, es kann durchaus sein, dass es derzeit deutlich mehr Warenwirtschafts- und Banksoftware gibt die tatsächlich für TS freigegeben ist. Da sollte aber der jeweilige Hersteller sicherlich mehr dazu sagen können, ebenfalls wie das auf einer TS Farm aussieht, vor allem sei da auf die Lizenzierung der Software hingewiesen, das kann dann schon mal sein, dass man bei insgesamt 3 Terminalservern auch 3 Serverlizenzen der Software benötigt. Grüsse Gulp

Und die sind auch alle zugelassen und lauffähig auf einem Terminalserver? Grüsse Gulp

Es kann zumindest wenig Schaden anrichten den DC der Domäne B mal zu demoten, schlimmstenfalls meckert da ja nur SharePoint rum, zum anderen wird man ihn ja ohnehin neu machen müssen, wenn kein Backup da sein sollte. Ausgehend von den geposteten Logs würde ich mich zunächst auch erst auf den DC von Domäne B konzentrieren und danach schauen was noch an Fehlern aufkommt. Was die Dienstleistung angeht, ich bin kein freier Dienstleister und vermutlich auch ein bisschen zu weit weg von Euch, um mir ein Bild vor Ort machen zu können oder mal schnell "Vorbeizuschauen". Ob man das dann trotz der Fehler solange weiterlaufen lassen kann, kann ich so nicht sagen, das macht sonst keiner. Es dürfte mit jedem Tag Laufzeit mehr jedenfalls nicht einfacher werden, einfach aus dem Schlamassel herauszukommen, das dürfte eher immer mehr in Richtung "alles neu machen" gehen, je länger das so betrieben wird. Grüsse Gulp

Ob Hardware oder virtueller DC ist im Prinzip eigentlich nicht von Belang, beides hat Vor- und Nachteile, auch lassen sich mit beiden Varianten ganz schnell USN Rollbacks erzeugen. Ich würde Dir empfehlen jemanden mit Sachkenntnis hinzuzuziehen, der die Situation vor Ort nochmals beurteilt und bewertet. Es kann hier zB bereits reichen den DC der Domäne B zu entfernen und das AD sauber aus einem Backup am Besten nur des SystemState zu restoren. Allerdings sollte erwähnt werden, dass ein SystemState Backup auch Treiber enthält von daher muss man vermutlich abwägen, ob man den Restore überhaupt auf den SystemState begrenzen kann. Grüsse Gulp

Und wo läuft der Exchange? [EDIT]ah ... das ist ja schonmal ganz gut. Und wurde ausser der anderen Domänenstruktur noch etwas gross geändert im AD? Will heissen im Backup gibt es nur die alte erste Domäne? Dann würde ich nämlich empfehlen die andere Domänenstruktur zu entfernen und einen SystemState aus dem alten Backup wieder einzuspielen, das dürfte am wenigsten Arbeit machen. Grüsse Gulp

Verloren gehen alle Dinge, die im AD gespeichert werden, die Domäne muss ja quasi komplett neu eingerichtet werden, sprich alle User, Gruppen, GPO's, usw. Auch die Freigabeberechtigungen sind anschliessend zu kontrollieren, man sollte hierbei nicht vergessen, dass ein Exchange Server, der auch DC ist kein Demote und Promote durchführen darf, ansonsten ist der Exchange futsch. Auch hier muss man seperat nochmals planen, wie man vorgeht. Tut mir ja leid, das sagen zu müssen, aber meistens kostet eine gute Vorbereitung zwar einiges an Zeit, dafür spart man hinterher an Ärger. Auch sind solche Aktionen an einer noch so kleinen Produktivumgebung ohne vorheriges Backup recht "mutig". Ist zwar jetzt zu spät dafür, soll auch nicht gehässig sein, man muss aber dennoch mal erwähnt haben, finde ich. Auch wenn das Backup vielleicht recht alt ist, so würde ich es nicht ganz vergessen wollen, wie alt ist es eigentlich? Grüsse Gulp

Da Du ja vermutlich quasi alle DC's so behandelt hast, sind auch alle von der USN Rollback Problematik betroffen. Hier hilft ausschliesslich, wie bereits mehrfach erwähnt, entweder ein sauberes Backup des gesamten AD's und das VOR dem USN Rollback oder aber die DC's müssen demoted und dann neu promoted werden und somit in dem Fall das AD neu angelegt werden. Da muss man hier gleich noch darauf achten, dass es ja auch einen aktiven Exchange gibt. Oder sind da noch mehr DC's im Spiel? Grüsse Gulp

Jo, aufgrund des USN Rollbacks können sich die DC's nicht mehr replizieren (werden es ohne weiteres auch nicht mehr können). Wie bereits erwähnt, wenn es ein Backup der Domänen in ihrem fehlerfreien Zustand VOR dem Umzug gibt, solltest Du dieses wiederherstellen und dann eine geeignete Methode für den Umzug verwenden. Seitens Microsoft gibt es, wie dem Artikel nachzulesen, den ich in meinem vorigen Post bereits erwähnt hatte, ganze 2 Möglichkeiten der Reparatur: 1: Ein sauberes Backup des Active Directory auf alle betroffenen DC's zurücksichern. 2: Alle betroffenen DC's aus der Domäne entfernen und das AD neu aufsetzen. Grüsse Gulp

Was meinst Du denn was gleich die erste Meldung einem so sagen möchte? Warum versucht man immer wieder solche unsupporteten Dinge ohne a: das in einer Testumgebung ausgiebig zu testen und b: sich vorher umfassend zu informieren, ob das gewünschte Verfahren überhaupt unterstützt wird und nicht zu Problemen führt. Den Meldungen nach hast Du höchstwahrscheinlich nun einen USN Rollback. How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 Eine saubere Wiederherstellung ohne Neuinstallation der DC's (und meist auch gleich von Exchange) und ohne ein aktuelles Backup der Ausgangssituation (noch ohne USN Rollback) ist nicht so einfach möglich. Grüsse Gulp

Tja, dann hast Du mit Deinen vorhandenen ThinClients Pech würde ich sagen .... Wenn Du jetzt zusammenrechnest was Du an Aufwand für diese (aus meiner Sicht hier nicht zufriedenstellend lösbare) Aufgabe insgesamt alleine bisher gesehen reingesteckt hast, könntest Du als Gegenwert sicherlich ein paar der IGEL für diese Aufgabenstellung bekommen (wobei ich da jetzt nicht gehässig oder ketzerisch klingen will, auch wenn es sich vermutlich so anhört). Grüsse Gulp

Es geht durchaus mit ThinClients, nicht mit allen das ist wohl wahr, die ThinClients müssen RDP 6.0 oder RDP 6.1 unterstützen oder aber Seamless Window. siehe zB IGEL: Mit Microsoft RemoteApp® und Linux-Thin Clients Kosten senken « Pressemitteilungen « Presse & Medien « Unternehmen « IGEL Technology Ob das Eure ThinClients unterstützen kann ich ja nicht wissen, wenn die aber mit rdesktop arbeiten sollten, dann könnte folgendes für Euch interessant sein: Cendio AB - SeamlessRDP Ausgeführt wird die App aber defintiv nicht lokal, sondern auf dem Terminalserver, das ist ja der Clou. Citrix kann das ja schon länger auch zB mit Java Clients ..... Grüsse Gulp

Das reicht doch auch für Remote App, les mal den Link dazu den ich oben gepostet habe. Grüsse Gulp

Wenn man damit eine RDP Verknüpfung oder eine HTTP Seite erreichen kann reichen ThinClients, egal mit welchem OS, auch für Remote App dicke aus. Grüsse Gulp

Ein frei zugänglicher Internetraum, gerade da kann man doch mit Remote App nur den IE freigeben, da muss der Student nur auf eine Verknüpfung klicken oder einen Link auf einer Webseite anklicken, das bekommt selbst der Nichttechniker ganz gut hin und das rund um die Uhr ohne Button verstecken und sonstwohin klicken zu können. Er sieht nichts ausser dem IE (oder anderen für seinen User freigegebenen Apps) ..... das ist ja gerade der Sinn von Remote App. Schrittweise Anleitung zu RemoteApp für Terminaldienste Das von Dir geschilderte Szenario ist ja eigentlich auch ein einfaches Standardszenario, das hat man schon unter Windows NT Zeiten vorgefunden, da aber nicht so elegant lösen können, da war dann eher das Verstecken von Funktionen angesagt und modern. Off-Topic:Ich hatte mir da mal das Vergnügen gemacht und dem örtlichen Sysadmin, der in einem nicht kleinen Warenhaus 10 NT Surfstationen (damals gabs fast keine bessere Internetanbindung als dort) "überwachte" zum fast permanenten Haareraufen gebracht, indem ich an allen Stationen den Startbutton (der Windows 95 und NT 4.0 bis ich meine zum SP4 quasi ein einfaches Fenster mit seperatem Kontextmenü war - also verschieben etc) einfach geschlossen habe. Der Arme stand völlig konsterniert vor den Kisten und wusste im ersten Moment gar nicht wie er nun die Dinger neu starten sollte, so ganz ohne Start Button. Wen's interessiert wie das mit dem Button ging: http://www.geek.com/articles/geek-cetera/windows-95-let-you-close-the-start-button-but-why-20120215/ Heute ist das mit aktuellen Betriebssystemen natürlich nicht mehr möglich. :D Grüsse Gulp

Können kann man bekanntlich viel .... ob's dann wirklich Sinn macht ist immer eine andere Frage. Wenn ein User sich nicht abmelden können soll, würde ich eher Remote App benutzen anstatt ihn in eine RDP Session zu zwingen, alle anderen "Nicht-Abmeldeszenarien" würde ich eher einem Dienst zuordnen, anstatt einem User. Wenn ein User sich mit einer RDP Session auf einen TS verbinden soll, dann sollte ihm aus meiner Sicht auch die Möglichkeit gegeben werden, die Session ordentlich zu beenden. Kommt mir anderfalls so vor, wie wenn man ein Auto anmachen darf, es dann aber nicht ausmachen dürfte und dann einfach aussteigt und wartet bis der Sprit alle ist. Grüsse Gulp

Wie gesagt Du könntest einen Bug dazu bei Microsoft aufmachen, ich befürchte aber, dass es so kommt wie im Link beschrieben und nur die Dokumentation angepasst wird. Ich glaube kaum, dass Microsoft einen Grund dazu sieht das einzubauen, allein um bei nicht automatischer Abmeldung der User bei einem Terminalserver die Supportanfragen zu minimieren warum der TS so viele Benutzersessions vorhält und sich keiner abmeldet. Schliesslich ist das Abmelden der User Session der eigentlich ideale Weg, um einen TS sauber zu verlassen. Eine solche Funktion wird man daher auch kaum entfernen wollen. Grüsse Gulp

Nur am Rande, dass die GPO nicht greift ist "well-known" ....... Disable logoff button in Windows2008 R2 RDS (Terminal Services) Wer den Bug aufmachen will, nur zu ..... Grüsse Gulp

Off-Topic:Nicht dass ich genau diese Reaktion nicht schon geahnt hätte ...... Grüsse Gulp

Ich bin hier keinem aggressiv oder unfreundlich gesinnt, ganz im Gegenteil, an Deiner Stelle würde ich aber mal in mich gehen und Deine Antworten von Beginn an mal ganz langsam laut vorlesen, wenn gerade keiner in der Nähe ist. Dann bewerte Deine Wortwahl nochmal und frage Dich dann wer aggressiv rüberkommt. Nur weil einem eine Antwort nicht gefällt, gleich alles damit Zusammenhängende ausblenden zu wollen ist in einem, wie Du ja selber sagst Diskussionsforum (vor allem in einem öffentlichem Forum und damit jedem zugänglichen Forum) aber fehl am Platze, denn dann gibt es schlicht keine Diskussion. Gerade die Erwähnung alternativer Lösungsansätze sorgt doch eigentlich erst für eine Diskussion, die Du dann gleich brachial abwürgst mit "so will ich das aber nicht". Ohne weitere Details, die das "will ich nicht" und Deinen Standpunkt vielleicht erklären hätten können, die Du ebenfalls abwürgst, weil Du Dich nicht rechtfertigen willst (das erwartet keiner, die eingangs genannten Details aber eher schon). Das ist für mich auch nicht gerade ein repräsentatives Zeichen von Diskussion. Es geht hier nicht darum zu sagen Du wärst zu dumm oder Du hast Dir keine Gedanken gemacht, es geht darum Dich auf eventuelle Problem und/oder durch Deine Idee auftretende Probleme aufmerksam zu machen und im Idealfall Dir und auch anderen, die ähnliche Probleme haben einen Lösungsansatz zu geben (oder nur eine neue Idee). Das kann aber nicht funktionieren, wenn von vornherein mögliche Ansätze und Ideen im Keim erstickt werden. Das gilt natürlich auch für Deinen Ansatz, wenn man den denn vielleicht im Detail verstehen könnte. Grüsse Gulp

Ach, wenn Du Besuch hast, dann darf der Dir auch vorschreiben, was er am liebsten in Häusern so alles macht oder wie? Na danke lieber Besucher dieses Forums, zeigt aber wessen Geistes Kind Du bist ...... Dann weiterhin viel Erfolg mit Deiner Einstellung. Grüsse Gulp

Jetzt denke doch mal ein wenig über Deinen eigenen Telelrrand hinaus und bedenke das dies hier zum einen ein öffentliches Forum ist, zum anderen wir weder wissen, ob Du das bei einem Kunden machst, zuhause, in einem Testlabor oder sogar unberechtigt als User und nicht als Admin. Es geht Nils nicht darum Dir irgendetwas vorzuschreiben oder Dir sein Sicherheitsverständnis aufzudrücken, um Leute von seiner Meinung zu überzeugen kann er weiterhin Artikel in der c't oder bei iX oder wo auch immer veröffentlichen oder seine (sehr guten, wie ich finde) faq-o-matic Seiten verwenden. In diesem Forum sind ein Haufen MVP's unterwegs die nicht wenig Ahnung von der Materie haben, ebenso sind hier nicht wenige sehr kompetente Consultants, Adminsitratoren und sonstige IT'ler unterwegs, die auch zum Teil in recht engem Kontakt zu Microsoft selbst stehen. Allein deswegen ist ein Anspruch dieses Forums eben keine sicherkritischen "Hacks" und Basteleien zu propagieren, da diese dann quasi als "Empfehlung dieses Forums" öffentlich im Netz stünden. Ich sehe auch keinen Sinn nur eine Ansicht oder ein UI (wie einen Button) einfach nur abzuändern oder auszublenden, damit ist die Funktion an sich ja nicht weg. Wenn ich aber die Funktion an sich sperre, dann ist es auch wurscht, ob da ein Button, Link oder was auch immer ist. Und wenn Du schon festgestellt hast, dass der genannte Registry Zweig bei 2008R2 wenig bringt, dann sollte Dir klar sein, dass es sich mit sehr hoher Wahrscheinlichkeit auch nicht abändern lässt. Was dann wieder den Lösungsansatz mit den Leserechten in der Vordergrund bringt. Grüsse Gulp

Mir ist das schon klar, sie können zB schon mal das AD durchsuchen, was sie eben nicht können, wenn sie dafür keine Leserechte haben. Und das wäre auch eine Antwort auf Deine Frage wenn Du Nils Antwort gelesen und den Sinn dahinter verstanden hättest. Das reine Abschalten der Ansicht in der Netzwerkumgebung ist ja nur das Abschalten einer einzigen Ansichtsmöglichkeit, es gibt dann immer noch genügend Ansätze das AD zu erreichen. Wenn jemand dort also was wissen will, findet er es auch ohne die Ansicht in der Netzwerkumgebung heraus. Den enstprechenden Registry Zweig findest Du als ersten Treffer in Google mit den Stichworten: "registry active directory ausblenden netzwerkumgebung" Sinn macht das auch aus meiner Sicht allerdings nicht wirklich. Grüsse Gulp

Zum einen: Wie sollen wir entscheiden, was Deinen Usern erlaubt werden soll und was nicht? Zum anderen: Was ist an der Aussage von Nils so schwer zu begreifen? Nimm dem Kiosk User alle oder von gewünschten Objekten im AD die Leseberechtigungen und fertig. Grüsse Gulp

Wenn es konform zu dem Passus aus den PUR, den ich in #24 bereits gepostet hatte passt und Du den dortigen Abschnitt unter "Tragbares Gerät" mit Zweitnutzungsrecht meinst, dann sollte das schon greifen. Deswegen hatte ich den ja überhaupt erst erwähnt. Grüsse Gulp

Die Office Lizenzen sind immer Device Lizenzen, egal ob Du die Windows CAL per User oder Device lizenzierst. Können 5 Geräte an den Terminalserver rankommen, musst Du 5 Office Lizenzen haben. Es ist laut den PUR allerdings erlaubt eine Kopie der Office Lizenz des einzigen Hauptbenutzers eines PC auf ein tragbares Gerät (zB Notebook) zu installieren, das könnte in Deinem Fall ja eventuell anwendbar sein. Aus den aktuellen PUR: Rechte zur Installation und Nutzung ZUWEISEN DER LIZENZ ZU EINEM GERÄT Bevor Sie die Software unter einer Lizenz verwenden, müssen Sie diese Lizenz einem Gerät zuweisen. Dieses Gerät ist das „lizenzierte Gerät“ (siehe Universelle Lizenzbestimmungen, Definitionen). LIZENZIERTES GERÄT Sie sind berechtigt, eine beliebige Anzahl von Kopien der Software und früherer Versionen der Software auf dem lizenzierten Gerät zu installieren und zu verwenden Außer wie im Abschnitt „Remotezugriff“ weiter unten beschrieben, darf nur jeweils ein Nutzer die Kopien auf dem lizenzierten Gerät verwenden. TRAGBARES GERÄT Sie sind berechtigt, eine Kopie auf einem tragbaren Gerät zur Verwendung durch die einzige Hauptnutzerin oder den einzigen Hauptnutzer des lizenzierten Geräts zu installieren. NETZWERKGERÄT Sie sind außerdem berechtigt, zusätzliche Kopien auf einem Netzwerkgerät zu installieren. Sie dürfen diese Kopien nur wie im Abschnitt „Remotezugriff“ weiter unten beschrieben verwenden. Grüsse Gulp