cj_berlin

Sobald in der Remote-Sitzung irgendwas passiert, was über die Verwaltung dieser Maschine hinausgeht, brauchst Du eine RDS-CAL (Server-OS) oder eine VDA / SA (Client-OS).

Moin, eine mögliche Lösung wurde Dir bereits von @testperson präsentiert. Für das Client-Management gibt es aus Security-Sicht nur zwei valide Ansätze: Classic Management: Der Client ist drin. Er ist Mitglied im AD und hat direkten Netzwerkzugriff auf Anwendungen und Ressourcen. Anwendungen sind lokal installiert. Zugriff auf externe Ressourcen ist geregelt durch Firewall, Webfilter, Proxy etc. Wenn der Client sich außerhalb des Netzes befindet, regelt die lokale Firewall auf dem Client den Zugriff so, dass die einzige Adresse, die direkt erreicht werden kann, die des VPN-Konzentrators ist. Der gesamte Traffic geht durch den VPN-Tunnel. Der Client ist draußen. Er ist nicht Mitglied im AD und ist mit Modern Management gemanaged (WorkspaceONE, Intune, whatever). Die Arbeit wird auf Terminalservern / VDI verrichtet, der Zugriff auf diese mit einem Reverse Proxy (UAG, Netscaler, RDG, ...) abgesichert. Auch das Client-Netz im Firmengebäude ist als "untrusted" eingestuft. Keine Anwendungen auf dem Client, zumindest keine, die Daten verarbeiten. Alle Mischformen zwischen diesen beiden Extremen sind Augenwischerei und Selbstbetrug. Und wenn man sich für das Szenario 2 entscheidet, kann man den Internetzugriff des Clients in einem vernünftigen Maße durchaus zulassen.

Das ist beides optional. Nur kannst Du VDI nur mit KMS (technisch) sinnvoll betreiben, und KMS Keys gibt nur mit VL.

Lizenzierung und Aktivierung haben nichts miteinander zu tun. Du bekommst ja z.B. mit jeder Server-Lizenz das Downgrade-Recht, aber das bedeutet nicht, dass Dir neben der gekauften Server 2019-Lizenz die Datenträger und Lizenzkeys für 2012, 2012R2 und 2016 mitgeliefert werden. Andererseits ist es vollkommen legal, für eine solche Aktivierung einen Schlüssel zu nutzen, der mit einer anderen Lizenz geliefert wurde. Mit der VDA-Lizenz bekommst Du das Recht, ein Jahr lang auf bis zu vier Windows-VMs von einem beliebigen Client remote zuzugreifen. Da VDA nur im VL existiert, bekommst Du den Lizenzschlüssel und den ISO-Download dort.

Wieso? Genau so eine Mietlizenz wie jede andere Mietlizenz. Und wenn Du M365-Lizenzierung abschließt, nur um Windows für VDI zu lizenzieren (sprich: Deine Clients fahren *nicht* Windows Enterprise, sondern Linux, ChromeOS, MacOS oder Retail-Windows), ist eine VDA billiger als die Differenz zwischen O365 und M365. Just sayin'...

Für Office-Apps nicht.

x365-Lizenzierung ist zwar per User, aber es sind per User eben nur 5 PCs, 5 Tablets und 5 Smartphones abgedeckt.

Moin, wenn der Domain Controller nicht erreichbar ist, wird auch kein neuer RSoP gebildet (wie auch?) und somit auch keine WMI-Filter angewandt. Du musst Dir vielleicht mit einem Scheduled Task behelfen, der prüft, ob der DC erreichbar ist oder nicht und, falls nicht, die gewünschten Anpassungen selbst vornimmt.

Das stimmt, auch praktisch Nichtsdestotrotz müssen die User darauf hingewiesen werden, dass das Szenario "ich mache eine Weltreise und arbeite jeden Tag von einem anderen Internet-Café aus" damit nicht abgedeckt ist.

Wenn Du keinen Broker hast, kannst Du dem Hyper-V-Host auch keine RDVH-Rolle geben Dann ist es einfach nur ein Hyper-V-Host, auf dem Windows-VMs virtualisiert sind. Und ja, das ist so bekloppt, wie es sich anhört: VDI mit Citrix oder VMware >> keine RDS-Lizenz nötig, VDI mit Microsoft >> RDS-Lizenz nötig.

Es geht nicht um den Zugriff von inner- oder außerhalb, sondern darum, ob es technisch möglich ist, dass ein User beliebige Geräte für den Zugriff auf einen virtuellen Desktop mit installiertem Office verwendet. Wenn es bei euch im LAN ohne weiteres möglich ist, habt ihr dasselbe Problem (und viele weitere, die aber hier nicht zum Thema gehören).

Sieht nach Split Permissions aus, da ist es nur mit PowerShell möglich.

Moin, Windows: Wenn die zugreifenden Endgeräte alle der Firma gehören und mit SA lizenziert sind, brauchst Du keine VDA. Andernfalls ja, VDA für jede VDI-VM. Wenn Du kein Connection Brokering benötigst (jeder User kriegt eine vollständige VM, auf die er per FQDN oder IP zugreift) und keinen RDS Gateway davor (weil alle über LAN oder VPN kommen), werden RDS CALs nicht benötigt. Viel eleganter ist aber die von Dir und @NorbertFe bereits zitierte Lösung mit Einzel-VMs, die jedoch auf Server-OS basieren. Dafür brauchst Du zwar Datacenter-Lizenzierung und RDS-CALs, aber das sind alles einmalige Anschaffungen und keine Abo-Modelle. Und dann virtualisierst Du innerhalb einer Session Collection ganz viele kleine Terminalserver und setzt die maximale Session-Anzahl für sie auf 1, schon hast Du quasi eine VDI gebaut. Office. Hier muss der Blick wieder auf die zugreifenden Endgeräte gerichtet werden. Wenn Du die Endgeräte unter Kontrolle hast (z.B. dadurch, dass der Zugriff nur aus dem Firmen-LAN möglich ist und dort eine Netzzugangskontrolle implementiert ist) kannst Du für jedes Endgerät eine Lizenz aus VL widmen und bist in Bezug auf RDSH oder VDI sauber. Retail-Lizenzen sind dafür nach dem, was ich weiß, ungeeignet, aber da kann es sein, dass ich da etwas missverstanden habe. Sind die Endgeräte hingegen nicht unter Deiner Kontrolle, musst Du Office per User lizenzieren, und das ist nur mit x365 möglich. Nebenthema "Terminalserver vs. VDI". Wenn Du keine konkreten Anhaltspunkte für Applikationen hast, die auf einem Terminalserver nicht gut spielen, wirst Du mit Terminalservern immer eine deutlich höhere Packungsdichte erreichen als mit VDI. Und wenn sich für Dich die Frage "Citrix, Microsoft oder VMware" stellt, sondern Du im Microsoft-Universum verankert bist, würde ich immer versuchen, das Gewünschte mit Terminalservern zu realisieren.

Moin, ein DC konnte bis inkl. 2016 nicht von einer Eval auf eine Vollversion konvertiert werden. Laut Microsoft ist es in 2019 immer noch nicht supported, ich habe aber bereits mehrere Stimmen gehört, die behaupten, dass es zumindest technisch funktioniert. Eine Lizenzierung ist aber etwas völlig anderes - Du Lizenzierst einen Windows Server, indem Du dem physischen eine ausreichende Lizenz zuweist. Es ist ein rein dokumentarischer, kein technischer Vorgang, der mit der Aktivierung, d.h. mit dem Eintippen eines Lizenzkeys in eine Windows-Instanz, nichts zu tun hat. Ein gleicher Patchstand ist dafür, einen zweiten DC in eine bestehende Domäne einzubinden und zum DC zu machen, nicht erforderlich - die Version des Servers muss >= dem eingestellten Funktionslevel der Domäne sein. Und mach das nicht mit ner Eval, nimm den richtigen Datenträger.

2016 kann kein RPC/TCP mehr. D.h. wenn Dein Outlook nicht konfiguriert ist, RPC/HTTPS zu nutzen, wird er zum 2010 verbinden.

DNS=firma.de + NetBIOS=FIRMA ist ohne weiteres möglich.

Nur der Webseite "firma.de". Diese muss immer auf Domain Controller zeigen. Alles andere kann über Split-DNS abgewickelt werden.

Moin, oder ein Third Party-Tool. Damit kannst Du ohne Trust und ohne Downtime alles, was Exchange ist, migrieren. Kostet aber Geld.

Moin, ich hoffe, es ist eine Labor-Übung und keine produktive Umgebung. Aber solange der ursprüngliche Exchange noch in seinem ursprünglichen AD wohnt, ist ja alles in Ordnung Hilfreiche Fragen, die man sich stellen könnte sind: wo ist die Konfiguration eines Exchange-Servers gespeichert? welche AD-Attrribute migriert ADMT für Computer? wo ist die Konfiguration einer Exchange-Mailbox gespeichert? welche Attribute migriert ADMT für Benutzer? anhand welches Attributs identifiziert Exchange Objekte im AD? Das sollte bereits genügen.

Moin, welche Anmeldeverfahren sind denn für IMAP zugelassen? Plain Text muss man ja extra erlauben.

05.2023 https://docs.microsoft.com/de-de/lifecycle/products/windows-10-enterprise-and-education Aber hier steht's nochmal: https://docs.microsoft.com/de-de/lifecycle/faq/windows#wie-sieht-die-servicezeitachse-f-r-eine-version--featureupdate--von-windows-10-aus-

Moin, je nachdem, wie euer Client Management organisiert ist, kann es von Bedeutung sein, dass die H2-Versionen eine deutlich längere Supportdauer (30 Monate) haben als H1 (18 Monate). Ansonsten bei den wenigen Deployments, die ich gesehen habe, keine signifikanten Probleme.

Hätte der Kunde zu Not getan, aber ich habe tatsächlich eins da. Du auch, bist einfach schon länger nicht mehr bis an die Rückwand des Kellers vorgedrungen

Ich bin in der Regel einer dieser Dienstleister. Folgende Varianten habe ich jetzt oder hatte in den letzten 5 Jahren: VDI über Citrix mit Token, von dort auf Server / Jumphosts / PAWs / Web-Oberflächen VDI über VMware mit Token, von dort auf Server / Jumphosts / PAWs / Web-Oberflächen RDSH über RD Gateway mit Token, von dort auf Server / Jumphosts / PAWs / Web-Oberflächen VPN mit Token, von dort RDP auf Jumphost und/oder Zugriff auf Web-Oberflächen TeamViewer unbeaufsichtigt auf eine dedizierte statische VM TeamViewer interaktiv mit dem MA des Kunden FastViewer interaktiv mit dem MA des Kunden Teams Desktop Sharing interaktiv mit dem MA des Kunden Modem-Einwahl in ein dediziertes System

Moin, in einem größeren RZ, das unter KVM läuft, war ich noch nie - was nicht bedeuten soll, dass es die nicht gibt, nur dass ich noch nie in einem war. Unter Hyper-V oder ESXi würde man nie auf die Idee kommen, alle Kerne eines Hosts einer einzigen VM zuzuweisen (während andere VMs dort laufen), denn da funktioniert das Scheduling offenbar anders als bei KVM. Aber es gibt Quellen, die behaupten, ein CPU Overcommitment von 5:1 wäre noch OK. Meine Erfahrung sagt hier etwas anderes. Woher Du die Erkenntnis nimmst, dass Windows ein Dingle-User-System ist, während Du einen Terminalserver betreibst, ist mir allerdings schleierhaft.