cj_berlin

Ja. Ich schrieb: Das ist was völlig anderes als euer Connector, der Mails von Druckern akzeptiert.

Klar. GPRESULT, Logs, Debug Logs usw. usw.

Huch? Accepted Domains haben mit dem Senden wenig zu tun.

Moin, Du kannst auch in O365 eine Accepted Domain vom Typ "internal Relay" anlegen. Partner-Connector anlegen und fertig. MX muss auf O365 zeigen.

Beim RecipientContainer muss die OU stehen, wo die Mitglieder drunter sind.

Das steht aber nirgends Hier nicht: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-client-access-license Und wenn man in den Product Terms nach VDA sucht, kommen ausschließlich Dokumente für Desktop-OS raus:

Nicht falsch. In einem Netzwerk, das ausschließlich aus zwei Windows 10-Maschinen besteht, benötigt man für den Zugriff von Maschine A auf Maschine B keine CALs. Es gibt auch gar keine "Windows Client CALs". Das CAL-Erfordernis kommt beim Zugriff auf ein Client-OS nicht aus diesem Zugriff, sondern aus der vorhandenen Infrastruktur, und hätte vermutlich bereits in dem Moment bestanden, wo der Thin Client bootet und von einem Windows-DHCP seine IP-Konfiguration erhält.

Moin, VDA ist doch nur der Tatsache geschuldet, dass es keine valide Lizenzierung für virtualisierte Desktop-OS "per se" gibt. Das Server-OS hingegen musst Du zwingend via Blech lizenzieren, und dann ist es lizenziert, braucht also nichts zusätzlich. Zugriff auf den Server --> CAL, Zugriff auf den Server per Remoting (RDP, ICA, Blast, you name it) --> RDSCAL. Und das ist völlig unabhängig davon, ob der Server virtuell, physisch, imaginär ist oder sonst wie ist. Und auch unabhängig davon, was auf dem Client läuft. Beim Zugriff auf ein Client-OS brauchst Du schon mal keine CALs, denn CALs sind ein Server-"Feature". RDSCALs brauchst Du nur, wenn Du irgendeine RDS-Serverrolle für den Zugriff verwendest - Connection Broker, RD Gateway, RDWeb oder was weiß ich. Und wenn der zugreifende Client ein nicht qualifiziertes OS fährt, brauchst Du noch die VDA, um das angesprochene OS zu lizenzieren. Das ist auch von der Art des Zugriffs unabhängig - selbst wenn Du die VMRC dafür nutzt, brauchst Du die VDA. Bei Microsoft waren die Antworten schon immer davon abhängig, mit wem Du sprichst, vielleicht hast Du "früher" einfach mehr Glück gehabt.

Moin, Server-OS braucht kein VDA, nur RDS-CAL.

Dafür, wie ich bereits schrub, brauchst Du die Data Definitions.

Moin, stimmt denn der Recipient Container? Filter ist ja nur die halbe Miete

Moin, Desk Sharing in O365 --> Workspaces: https://learn.microsoft.com/en-us/exchange/troubleshoot/outlook-issues/create-book-workspace-outlook Ansonsten hilft nur Demos anfordern und testen - für Hunderttausende Organisationen ist Outlook für diese Aufgaben übersichtlich genug, daher ist es in einem Forum schwer zu beurteilen, was denn bei euch in dieser Hinsicht besonders ist.

...oder so (innerhalb der Schleife): if($l -imatch '^\s*\<cfg:node.*mNumber=\"(?<mNumber>\d+)\".*\>\s*$'){ $mNumber = $Matches['mNumber'] break } break hilft mit der Ausführungszeit, wenn es wirklich gesichert ist, dass der Pattern nur einmal vorkommt bzw. dass das erste Vorkommen ausreicht. Jede präzise Verarbeitung dieser XML erfordert die Data Definitions, die Du nicht mitgeliefert hast.

Du hast Deine Frage bereits selbst beantwortet. Kopiere den Kram, den Du in der Vorlage brauchst, in den .DEFAULT auf jeder Workstation (kannst per GPO tun, wenn es dann wieder geht, oder per Software-Verteilung), und fertig ist.

Das kommt darauf, an, was Du unter "auf die Adresse zugreifen" verstehst.

OK, es sind ZWEI Vulnerabilities in einem Blog-Beitrag Die zweite könnte tatsächlich den normalen PowerShell-Endpoint nutzen - hier liegen im Moment noch keine Details vor. Andererseits sollte das WinRM-basierte Remoting ja erst recht nur für andere Exchange-Server oder Management-Workstations erreichbar sein, hier ist der Angriffsvektor in wohlgemanagten Systemen tatsächlich eher beschränkt.

Das ist ein Trugschluss. Remote PowerShell zu *Exchange* geht über einen Web-Endpoint, somit 443 oder sogar 80.

...und das Konto danach möglichst nicht mehr zu benutzen, außer im Notfall. ...und genau deswegen sollte man es auch lassen. Im Troubleshooting-Fall behindert es den dazugerufenen Externen mehr als im Angriffsfall den Angreifer.

Das aber mit Support von MS, weil es ja das neue RecipientManagement Snap-In verwendet.

Du würdest Dich wundern, wie viele "Verzeichnisdienst-Architekten" und Admins sich in den Design-Workshops den Sachverhalt noch erklären lassen... Das gleiche bei der Platzierung von FSMO-Rollen

Moin, das kannst Du alles machen, nur gehört der Lizenzserver ja nicht inhaltlich zu einer bestimmten Bereitstellung, sondern kann mehrere Bereitstellungen, einzelne Server usw. bedienen.

Moin, auf den DC kommt gar nichts drauf außer DC + DNS, also auch kein Broker. Gründe sind vielfältig und liegen tatsächlich nicht nur im Bereich Security. Aber auch dort. Von allen RDS-Rollen ist der Lizenzserver die einzige, die ich mich unter Umständen noch zwingen lassen würde, auf einem DC unterzubringen. RDWeb + RDG zusammen kommt darauf an, ob man RDWeb auch extern veröffentlichen möchte. Falls nicht, wäre Broker + RDWeb eine mögliche Alternative, dann kommt man für beide mit einem Zertifikat aus. Wieviele Sessions auf einen RDSH kommen, kommt auf die Ausstattung des RDSH an. Ich habe durchaus Session Hosts mit dreistelligen Userzahlen betrieben, aber die waren dann meistens Physik.

Warum müsstest Du dafür irgendwas neu machen? Und warum gibt es dafür bereits zwei Postfächer?

Na aus Gründen natürlich!

Moin, wenn der Zeitstempel korrekt gesetzt wird, scheint alles zu funktionieren. In einer DAG werden ja mehr Logs vorgehalten, wenn mehrere Kopien vorhanden sind, daher würde ich etwas mehr Zeit zwischen den Backups verstreichen lassen, so dass vielleicht ein paar Tausend Logs auflaufen, und dann schauen, wieviele davon verschwinden.