jan-markus

Okay. Eigentlich Schade, dass es da nichts gibt. Ich finde den Gedanken eigentlich ganz passabel auch die Clients virtualisiert zu haben. Hätte eben auch viele andere Vorteile. Ist ja ein Diskussionsforum hier: Mal interessehalber wie machen andere das? Oder ist Client-Virtualisierung überhaupt kein Thema, bzw. alles "nur" Terminal-Services versteckt hinter schicken neuen Namen und "Desktop Experiences"?

Na klar. Okay, die Variante mit Server behalt ich im Kopf. Danke Mit Windows 10 keine (sinnvolle) Chance?

Interessante Idee. Klingt zwar etwas verbogen, aber hey Ohne Remotedesktop-Dienste darf ich nicht nur administrativ auf die Kiste?

Hallo zusammen, ich habe eine Handvoll Windows 10 Pro Clients (eine spezielle kleine legacy-Nutzergruppe, innerhalb eines größeren Umfeldes), die theoretisch auf einem Hyper-V virtualisiert laufen sollten. Zugreifen soll immer nur ein Benutzer, und zwar von einem Linux-ThinClient, oder Tablet (per RDP), auf "seinen" virtualisierten PC (auf dem Hyper-V). Nach Board-Lektüre und Internet-Stöbereien manifestiert sich das Bild, das das nicht sinnvoll mit Microsoft geht...? Offensichtlich nehme ich wohl einen Windows-Terminalserver für die fünf Benutzer und die Leute kriegen dann "Desktop-Experience" (gibts das noch?) und arbeiten auf dem Server-Betriebsystem. Das ist dann wohl mit User-CAL und RDS-CAL sinnvoll lizenzierbar -wollte ich aber eigentlich vermeiden (eine Legacy App kann nicht (einfach) auf einem Terminal-Server laufen). Zurück zur Frage und zu Windows 10 Pro: Gibts da keine Möglichkeit (in der Größenordnung 5 User) das einfach virtualisiert zu betreiben und dann per RDP zuzugreifen? Ich lese, hier z.B. von der VDA-Lizenz. Und von Windows 10 Enterprise. Geht das auch in der Größenordnung für die paar User, oder macht das keinen Sinn? Also falls das Vorhaben mit VDA oder Windows 10 Enterprise geht, wie bezieht man das? (Hintergrund: Keine Windows-Firma) Danke für jede Hilfe! j

Es fehlten schlicht die Rechte für die lokale Administration. Wieder hinzugefügt. geht.

Alles klar. Danke für die Hilfe. Thema kann zu.

Das stimmt, da bin 100% bei Dir. Notwendige Horizont-Erweiterung für mich. Das werde ich also tun. Danke vielmals!

Wow, das war fix. Danke für die Hilfe! Aber klar, es wäre grundsätzlich besser wenn es so konfiguriert wäre, ist absolut nachvollziehbar. Bin in diesem Fall nur der "Bote", bzw. die Vertretung - werde dies aber mit dem Kollegen durchsprechen. Vielleicht sehe ich auch einfach nicht alles... Aber, warum nur auf diesem Server? Vermutlich eine Gruppenrichtlinie - da hatte ich nichts speziell auf diesen Server zutreffendes gefunden, werde aber nochmal genauer schauen. Kann ich zuverlässig testen, bzw. kann ich mittels z.B. der obigen Ausgaben von gpresult und z.B. klist davon ausgehen, dass die Verbindung zur Domäne soweit okay ist, und dass es sich tatsächlich um eine Einschränkung & Beschränkung der lokalen Rechte des Domänen-Admins (auf diesem Member-Server) handelt? Dies ist vermutlich wirklich eine seltsame Frage, aber ich hab da noch ein Verständnisproblem: Also auf diesem Server hat der Domänen-Admin keine lokalen Admin-Rechte (mehr), erklärt das auch den Zugriffsfehler auf die "admin$" Freigabe als Domänen-Admin von anderen Systemen? "Sticht" da nicht der Domänen-Admin? J.

Hallo Community, ich habe ein seltsames Problem mit einem (virtualisierten) Windows Server 2012 R2, der Mitglieds-Server einer Domäne ist (SQL-Server). Der Server ist auf aktuellem Patchstand (2019-03). Das Problem äußert sich wie folgt, und nur auf dem betreffenden Server: Ein externes Backup (Veeam) kann nicht mehr auf die administrative Freigabe (admin$) zugreifen, die es für die Ausführung seiner Backups benötigt. Dazu verwendet wird ein Domänen-Admin-Benutzerkonto. Das ging bisher. Auf andere SMB-Freigaben des Servers kann im Netzwerk zugegriffen werden. Sowohl als Benutzer, als auch mit dem obigen Domänen-Admin-Benutzerkonto. Eine entfernte Anmeldung per RDP mit diesem Domänen-Admin-Benutzerkonto an dem Server schlägt fehl mit "Die Verbindung wurde abgelehnt, da das Benutzerkonto nicht zur Remoteanmeldung autorisiert ist.". Das ging bisher. Eine Verbindung zu dem virtualisierten Server ist also nur noch über die lokale Hyper-V-Konsole möglich. Dort wird das fragliche Domänen-Admin-Benutzerkonto auch akzeptiert, aber: In der Ereignisanzeige wird dem Benutzerkonto mit "Zugriff verweigert(5)" die Ansicht des Security Eventlogs verweigert Das Neustarten von Diensten wird ebenfalls wegen fehlender Rechte verweigert Der Neustart des Servers (z.B. shutdown /r in administrativer Eingabeaufforderung) scheitert ebenfalls mangels Berechtigung des Benutzers Das besagte Domänen-Admin-Benutzerkonto kann sich weiterhin administrativ an alle anderen Server der Domäne anmelden und dort eben diese administrativen Tätigkeiten ausführen. Auf dem besagten Server "ging" das ebenfalls immer. Ich bin nur vertretungsweise für den abwesenden Windows-Kollegen am Start. Weiß nicht so recht, wo ich starten soll. Was ich gemacht/probiert habe: Neustart (über Hyper-V). Problem besteht weiterhin. Updatestand aktuell. Keine ausstehenden Updates Namensauflösung geprüft. DCs alle erreichbar Uhrzeit stimmt "klist": Interpretiere ich wie folgt: Ich bin erfolgreich als Benutzer administrator@DOMÄNE legitimiert, oder? Ist die Inegration des Systems in der Domäne also okay? "gpresult /r": Fehlen hier nicht Sicherheitsgruppen? Ein Abgleich mit einem anderen Server auf dem alles okay ist, deutet z.B. auf: "Administratoren", "Remotedesktopbenutzer", "Interaktive Remoteanmeldung"? Fehlen dem Benutzer lokale Admin-Rechte? klist gpresult /r Warum wird das Passwort, also der Login, lokal an der Hyper-V Konsole akzeptiert, hat dann aber offensichtlich keine "administrativen" Rechte? (Warum) hat der Benutzer keine lokalen Admin-Rechte? Warum darf nicht (mehr) per RDP zugegriffen werden? Warum darf mit dem Domänen-Admin-Benutzerkonto nicht mehr auf die "admin$" Freigabe zugegriffen werden? Danke für jede Hilfe. J.