cj_berlin

Aber im Enterprise-Umfeld braucht das, was da vorgestellt wurde, definitiv kein Mensch. Was mich ein bißchen bekümmert, ist die nun sehr hohe Divergenz in der GUI zwischen Server und Client. Aber bevor sie die neue GUI als Default auf jeden Infrastruktur-Server klatschen, sollen lieber die Terminalserver "altbacken" aussehen

Moin, da die Anwendung ja im Benutzer-Kontext startet, kann sie nicht vor der Anmeldung gestartet werden Ansonsten schau Dir die Kosk Modes von Windows an: https://docs.microsoft.com/de-de/windows/configuration/kiosk-methods , vielleicht ist für Dich das Passende dabei...

Vermutlich sind für die Remote Domain die automatischen Weiterleitungen gesperrt (Get-RemoteDomain ist Dein Freund hier). Ansonsten würde ich das eher mit Set-Mailbox -ForwardingAddress <...> -DeliverToMailboxAndForward $true (oder $false, wenn Du eh alle Mails nochmal migrieren willst) lösen.

Moin, das kann an vier Stellen geregelt sein: Richtlinie am Host (GPO, LocalGPO, RDS-Bereitstellung) Einstellungen am Remote Desktop Gateway, falls dieser verwendet wird Einstellungen im AD-Objekt des Benutzers (Reiter "Environment") Einstellungen im Client bei Verbindungserstellung

Ja, das ist korrekt. Gern wird aber vergessen, dass der RDG ebenfalls zu den RDS-CAL-pflichtigen Funktionen gehört.

Das ist nur richtig, falls die VDI mit VMware, Citrix oder einer anderen Third Party betrieben wird. Kommt Microsoft-VDI zum Einsatz, und sei es nur der Remote Desktop-Gateway, ist tatsächlich eine RDS-CAL notwendig.

nslookup im debug mode. Da siehst Du, wer was gefragt wird und was er antwortet.

Schon, aber das Clerainghouse hat ja keine Informationen darüber, was für Lizenzen Du irgendwo herum liegen hast

Was meinst Du mit automatisch erkennen? Bei welchem Vorgang? Wenn Du 2019er CALs im VL hast, spiel sie in den 2019er Server ein, dann sind sie aktiv.

Moin, Du kannst ein Lizenzpaket einfach mit dem Wizard im RDS-Lizenzmanager auf einen Server der gleichen oder einer neueren Version umziehen, sofern beide Server gleichzeitig am Laufen und erreichbar sind. Das macht aber aus 2012er RDC-CALs keine 2019er RDS-CALs. Letztere musst Du, wie von @Nobbyaushb angeregt, aus dem VL neu beziehen, und dann gelten sie auch für ältere Versionen.

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.