cj_berlin

Moin, die Basis-Funktionalität geht sogar mit Exchange-Bordmitteln. Ansonsten sind die genannten Produkte gut, bewährt, es wäre noch Gangl zu nennen, aber dann hat sich die Créme de la créme auch schon versammelt. Was Du allerdings grundsätzlich abwägen müsst, ist dies: Der Disclaimer (und Signatur) kann entweder im Client oder im Transport (Exchange Transport-Agent oder Gateway hinter Exchange) angehängt werden. Beide Verfahren haben ihre Vor- und Nachteile: PRO Client: S/MIME funktioniert ohne irgendwelche Artefakte Preview durch den Absender möglich Funktioniert gleichermaßen on premises und in der Cloud CONTRA Client: Plug-In muss verteilt und verwaltet werden Funktioniert nicht mit mobilen Endgeräten oder Mails, die aus Systemen verschickt werden Gleiche Signatur für alle Empfänger (intern + extern) Absender kann Signatur beeinflussen Zugriff auf AD im Offline-Betrieb nicht ohne weiteres möglich (Mails im Flieger vorschreiben) PRO Agent: Funktioniert für alle Mails, egal auf welchem Wege sie reinkommen Unterschiedliche Signatur für intern/extern in der gleichen Mail möglich Verwaltungsaufwand in der Regel deutlich geringer als bei Client, der überall hin verteilt werden muss CONTRA Agent: Muss installiert und verwaltet werden S/MIME funktioniert nicht transparent (da der Body nach dem Signieren/Verschlüsseln verändert werden muss) Exchange Transport Agent kann nicht in die Cloud "mitgenommen" werden (eine Gateway-Lösung hingegen schon)

Das ist natürlich falsch. -ExecutionPolicy ist kein Parameter Deines Skripts, sondern ein Parameter von powershell.exe

Ich muss die Reise planen, und im September werden sich die Projekte eh überschlagen, und dann ist irgendwann womöglich noch der PSDAY.UK (wenn man dann denn dorthin reisen kann). Außerdem ist die Anmeldung, die ich im Sinn habe, bereits offen

Das ist richtig, aber die Webseite liest sich so, als ob es nur der Freitag wäre. Ich frag mal nach.

...aber diesmal irgendwie am Freitag?..

Nein Auch nicht auf den ersten. DHCP und Printserver packt man *nicht* auf einen DC.

Falls der Benutzer lokaler Administrator ist, kannst Du gar nichts für ihn unterbinden.

Ich würde sagen, die Umleitung beim Provider ist zu rigoros vorgenommen worden, denn hinter der Autodiscover-Adresse verbirgt sich gar kein Exchange (mehr)...

Moin, wie äußert sich "Empfangen nicht möglich" denn genau? Intern oder extern? Bei intern ist es evtl. die gecachte X.500-Adresse, die natürlich nicht mitgekommen ist.

Split Permissions prüfen: Container "Exchange Protected Groups" ist vorhanden und hat "Exchange Windows Permissions" drin Exchange Windows Permissions beinhaltet NICHT Exchange Trusted Subsystem Eventuell wurden Split Permissions ursprünglich eingerichtet und dann zurück gerollt. In diesem Fall muss noch New-ManagementRoleAssignment "Mail Recipient Creation_Organization Management" –Role "Mail Recipient Creation" –SecurityGroup "Organization Management" New-ManagementRoleAssignment "Security Group Creation and Membership_Organization Management" –Role "Security Group Creation and Membership" –SecurityGroup "Organization Management" New-ManagementRoleAssignment "Mail Recipient Creation_Recipient Management" –Role "Mail Recipient Creation" –SecurityGroup "Recipient Management" ausgeführt werden.

Diese Vorgehensweise hat auch den Charme, dass alle Systeme, bei denen Du sonst vergessen hättest, den DNS-Server umzutragen, weiterhin funktionieren.

Mich wundert es mittlerweile nicht mehr. Bin ich jetzt abgestumpft oder einfach nur Realist?

Das hat man ja auch zu Server 2019-RC-Zeiten vermutet, weil Microsoft die RDS-Rolle vergessen hat. Das wäre auf jeden Fall der richtige Weg (zumindest, wenn die Limits aufgehoben und nicht auf 10 oder 15 aufgeweicht werden). Und Server 2022 ist ja als TP schon da.

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.