Gulp

Ob einem etwas unplausibel vorkommt oder stimmen dürfte ist zunächst irrelevant. Wenn Microsoft in seinen Lizenzbestimmungen festlegt, dann ist dies solange gültig, wie es nicht höchstrichterlich festgestellt wird. Da kann auch ThinStuff nichts daran rütteln. Microsoft setzt voraus, dass wenn Terminaldienste auch von 3rd Party Tools wie Citrix oder sonstwem verwendet werden, in jedem Fall passende RDS CAL's vorliegen müssen. Natürlich kann Microsoft auch gegen den Einsatz von StarOffice auf seinen Betriebssystemen klagen, wenn diese gegen die Lizenzbestimmungen verstossen, wer dann am Schluss recht bekommt bleibt dann den Gerichten überlassen. Solange kann dir aber Microsoft ganz legal zB jeglichen Support verweigern oder zB generell in Rechung stellen, wenn StarOffice oder ein ThinStuff Produkt installiert ist, wenn gegen die aktuell gültigen Lizenzbestimmungen verstossen wurde. Das muss man sicherlich nicht uneingeschränkt gut finden, ist aber nunmal auch in anderen Bereichen des Lebens so. Grüsse Gulp

Ist es nicht doch eher ein Satellite L350D-11S? Also eines mit AMD CPU, Grafik und Chipsatz? Schon mal falls möglich ein BIOS Update gemacht? Welcher S-ATA Modus ist aktiviert? Grüsse Gulp

Jeder direkt oder indirekte Zugriff auf einen Windows Server bedingt eine CAL, auch wenn der Dienst oder die Funktion an sich keine seperate CAL benötigt, so auch in Deinem Fall. Es spielt hierbei keine Rolle welcher einzelne Port verwendet wird oder ob ein AD verwendet wird oder nicht, nur der Zugriff entscheidet (auch zB die Vergabe einer DHCP Adresse bedingt einen Zugriff auf den Server), deswegen heissen die Dinger ja auch Client Access License (CAL). siehe auch Microsoft Volume Licensing - Client Access License (CAL) Guide Grüsse Gulp

Auch da können Dateien kompromittiert werden, also Malware im Spiel sein. Auch werden in Windows Treiber mitgeliefert, die im Zusammenspiel mit der Notebook Hardware eventuell nicht ganz passen könnten. Grüsse Gulp

Diese Nachricht tritt auf, wenn Windows in den Kernelmodus wechselt und dadurch ein Subsystem gefährdet ist und die Sicherheit nicht mehr garantiert werden kann. Weitere Ursache könnten fehlerhafter Grafikkartentreiber und/oder Systemdienst eines Drittanbieters sein. Siehe auch Bug Check 0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED (Windows Debuggers) Könnte auch eine durch Malware kompromitierte CSRSS.EXE sein. Grüsse Gulp

Das passiert dann, wenn der Hersteller im BIOS einen entsprechenden Eintrag konfiguriert und ein passendes Installationsmedium mit entsprechendem vorgegebenen Key verwendet wird. Das machen quasi alle OEM Hersteller so, ist aber, wenn keine Lizenz für den Rechner vorliegt, illegal, wenn Du es so weiterverwendest. Du kannst den vorinstallierten Produkt Key aber auch entfernen und so die erneute Eingabe eines Produkt Keys von einer gekauften Lizenz ermöglichen: CMD mit Adminrechten öffnen und folgendes eingeben: slmgr -upk Allerdings kann es passieren, dass die Eingabe eines gekauften Lizenzschlüssels nun nicht mehr zu der installierten Windows Version passt, sei es, weil sich die entsprechende Edition unterscheidet oder aber weil ein Retail Produkt Key nicht von der installierten OEM Version angenommen wird. Ausserdem kann der entfernte Hersteller Key jederzeit wieder installiert werden und so die Lizenz illegalerweise wieder über das BIOS aktiviert werden. Von daher ist es eigentlich empfehlenswert den Rechner platt zu machen und dann mit der neu gekauften Lizenz neu zu installieren. Grüsse 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