testperson

Dann teste es mal andersrum und verwende "Lokal anmelden zulassen" mit Usern in berechtigten Gruppen (und lasse "Administratoren, Sicherungs-Operatoren" drin bzw. füge diese auch hinzu). Evtl. noch ein bisschen was zum _vorher_ lesen: https://support.microsoft.com/en-us/help/823659/client-service-and-program-issues-can-occur-if-you-change-security-set ;)

Hi, hier wird das Problem AFAIK sein, dass Windows Server 2019 DCs keine Sysvol Replikation per FRS supporten und dein SBS noch per FRS replizieren möchte: https://social.technet.microsoft.com/wiki/contents/articles/51435.what-s-new-to-promote-a-additional-domain-controller-on-windows-server-2019.aspx?Sort=MostRecent&PageIndex=1 Migration FRS -> DFSR: https://blogs.technet.microsoft.com/filecab/2014/06/25/streamlined-migration-of-frs-to-dfsr-sysvol/ Gruß Jan

Ja, so ist es.

Dann erstelle eine Gruppe "Mitglied_darf_sich_nicht_am_PC_anmelden" und pack dort alles rein, was sich nicht anmelden darf.

Ich hatte es so verstanden, dass die Einstellungen dieses GPO eben nur auf den RDSHs gelten bzw. auf den (allen) Clients nicht gelten soll. Wobei ich dann halt auch schon wieder beim Loopbackverarbeitungsmodus wäre.

Du könntest noch überlegen, es andersrum zu machen. Authentifizierte Benutzer -> Entfernen Domänen Benutzer -> Hinzufügen; Lesen + Übernehmen Gruppe mit den Computerkonten der RDS-Hosts -> Hinzufügen; Lesen In der Regel wechselt man den Client häufiger wie die Session Hosts. Dann hättest du weniger Aufwand / Verwaltung. ;)

Dann filterst du eben per WMI aufs Betriebssystem. ;) Oder steckst die Computerkonten in Gruppen, wie NorbertFe schreibt. Bei so einem Szenario könnte man auch über den Loopbackverarbeitungsmodus nachdenken.

Hi, warum nicht per GPO (Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Zuweisen von Benutzerrechten -> Lokal anmelden verweigern)? Gruß Jan

Hi, es wäre vermutlich einfacher die GPO mit der FolderRedirection zu filtern und dort den RDP Clients das Lesen / Übernehmen zu verweigern. Gruß Jan

Hi, evtl. wurde durch die neue MAC-Adresse vom Gateway ein neues Netzwerk "identifiziert". Solange du das nicht bestätigst, ist das AFAIK mit dem Firewall-Profil "Öffentlich" ausgestattet. Sofern es nur einen DC gibt, kann das so schonmal passieren. Oder eben doch IPv6. ;) Gruß Jan

Da wäre doch mal die Frage, welches OS eure Terminalserver denn derzeit haben? Seit 2008 R2 ist so ein Terminalserver mit passendem Client eigentlich multimonitorfähig. UPDs können immer nur einmal exklusiv von einem RDS / User im Zugriff sein. An welcher Stelle habt ihr denn durch zwei getrennte Sitzungen welche Lizenzvorteile?

Hi, warum die Terminalserver nicht auch aus der Cloud z.B. aus dem gleichen RZ wie Exchange? Es gibt sicherlich Provider die gegen Einwurf von mehr (oder weniger) Geld die geforderte Bandbreite liefern. Ansonsten UPDs für das komplette Profil oder eben nur \AppData\Local\Micorosoft\Outlook in die Disk legen. Des Weiteren sollte ein möglichst aktuelles Outlook genutzt werden und der Cache-Modus so kurz wie möglich gehalten werden. Ebenfalls könnte eine E-Mail-Archivierungslösung inkl. Retention Policy am Exchange auch noch helfen die Postfächer klein zu halten, damit nicht so viel gecached werden kann. Gruß Jan

Hi, vielleicht ist ja der bald erscheinende Windows Virtual Desktop in Azure was für dich / deine Kunden: https://azure.microsoft.com/en-us/services/virtual-desktop/ bzw. https://azure.microsoft.com/en-us/blog/microsoft-365-adds-modern-desktop-on-azure/ Gruß Jan

Hi, die knapp 17K Mails dürften nicht problematisch sein. Falls möglich, verzichte auf den Cache Modus. Was ist für ein Virenschutz auf dem Client und hat der eine Port Überwachung, HTTPS Scan und / oder Outlook Add In? Das wichtigste für "Cheffchen" dürfte wohl so langsam mal ein Update auf einen Exchange der noch Support hat sein. ;) Gruß Jan

Mea culpa: Get-ClientAccessServer | fl AutoDiscoverServiceInternalUri

Get-ClientAccessServer -AutodiscoverServiceInternalUri Gibt es im öffentlichen DNS ein SRV Eintrag für Autodiscover? Wenn möglich, tausch das Zertifikat um und nimm ein Multidomain mit "mail.<deineDomain>.de" und "autodiscover.<deineDomain>.de".

Hi, dann schalte das SMTP Logging an. Steht noch was vor dem Exchange, wo die Gruppe / Mail-Adresse noch nicht bekannt ist? Gruß Jan

Hi, Set-DistributionGroup <Deine Gruppe> -RequireSenderAuthenticationEnabled:$false Oder eben im EAC -> Empfänger > Gruppen -> Verteilergruppe bearbeiten -> Zustellungsverwaltung -> "Absender innerhalb und außerhalb meiner Organisation" Gruß Jan

Welcher Name steht denn jetzt im Zertifikat? Bzw. wie sind die URLs der vDirs und die AutodiscoverServiceInternalUri konfiguriert?

Warum denn jetzt kein Multidomain Zertifikat für horrende 39€ im Jahr und es dadurch direkt "komplett" richtig gemacht?!

Andere Alternative: Schmeiß die Win7 raus und geh komplett auf Win10. ;)

Hi, in dem Fall musst du vermutlich nur auf dem LTE Router eine Route ins 10.10.0.0/16 anlegen. Dann solltest du ohne NAT bis zum Webinterface kommen. Gruß Jan

Hi, kann man sicherlich. Aber https://www.watchguard.com/de/wgrd-support/support-by-phone/2136 https://www.hornetsecurity.com/de/kontakt wären wohl meine ersten Anlaufstellen. Gruß Jan

Hi, du müsstest auch mit "Get-ADUser -Filter {Name -like "*.ext"} | where { $_.DistinguishedName -like "*OU=Deine;OU=OrgaUnit1;DC=domain;DC=tld" -or $_.DistinguishedName -like "*OU=DeineAndere;OU=OrgaUnit2;DC=domain;DC=tld" }" zurecht kommen. Gruß Jan

Das hat auch schon geholfen wenn der RepairRequest nix gebracht hat. ;)