cj_berlin

Moin, nach allem, was ich weiß, liest ESE die Daten nicht auf Verdacht hin in den Cache ein, sondern erst, wenn sie angefordert werden. Daher: 1. Ist sichergestellt, dass da wirklich 85 GB Daten drin sind? Vielleicht ist da ganz viel Whitespace? 2. ist es vorstellbar, dass nicht alle Datensätze über den fraglichen Zeitraum abgerufen wurden?

Klar gibt's Intune. Und ja, MECM ist SCCM, aber Intune als Einzelprodukt gibt's weiterhin.

So etwas in der Art. Muss aber nicht 8531 sein, kann auch 7411 sein

Genau, das muss so im Subject:-Feld stehen. Jemand hat es weggefiltert, oder es stand nie drin...

Auch ohne VPN kannst Du das, aber dennoch musst Du den Maschinen einmal mitteilen, wo sie sich melden sollen. Wenn Du die Möglichkeit hast, Code auf den Maschinen auszuführen, und sei es nur einmal, machst Du einen geplanten Task, welcher jeden Tag um 12 ein Skript ausführt, und das Skript sucht nach Updates bei Microsoft Update und installiert sie. Das ist natürlich absolut krude und ein fehlerhaftes Update würde Deine ganze Notebook-Flotte wegreißen. Aber ohne Gerätemanagement ist halt nicht viel möglich. Vielleicht wäre bei 30 Geräten Intune eine Möglichkeit?

Dann braucht euer Geschäft ein Patch-Management-Werkzeug. WSUS ist nur ein Patch-Auslieferungs-Werkzeug.

Moin, ich würde sagen, der Betreff müsste explizit kodiert sein, wenn da Umlaute vorkommen. Vielleicht kann die Web-Oberfläche der ProofPoint damit besser umgehen als Outlook/OWA. Hier ist ein Beispiel aus Outlook/Exchange, was korrekt angezeigt wird: ?iso-8859-1?Q?Zeiterfassung_bei_T&M_Projekten_au=DFerhalb_der_Regelarbeitszeit?= Das ist für ISO-8859-1, für UTF-8 müsste da entsprechend ?utf-8? stehen.

Microsoft nennt das "Cloud Storage", setzt dafür aber eine Exchange Online-Lizenz voraus: https://docs.microsoft.com/de-de/microsoft-365/compliance/search-cloud-based-mailboxes-for-on-premises-users?view=o365-worldwide

Moin, da musst Du wohl die Subject-Zeile im Quelltext der Mail auf der Proofpoint und in Exchange vergleichen.

Moin, wohin verbinden sich die Clients denn? Wenn sie sich zu Exchange 2007 verbinden, wird es schwer mit dem Proxy zu 2013. In aller Regel muss der Einfallspunkt für die Clients zuerst geändert werden, evtl. brauchst Du noch eine LegacyURL, da ja 2007 als Quellversion am Start ist. EDIT: Ich habe nachgeschaut, Dein Szenario ist Step-by-Step im Exchange Deployment Assistant abgebildet.

Auch von mir nachträglich @Nobbyaushb: Alles alles Gute zum Geburtstag!

Moin, ich find's bezeichnend, aber auch erschreckend, dass selbst dieser Thread genau die Entwicklung genommen hat, die auch die meisten Security-Beratungen im ersten Versuch durchlaufen. Die Hausaufgaben sind vorwiegend im LAN zu machen, man unterhält sich stattdessen aber gerne über den Perimeter. Just sayin'

Doch, ganz bestimmt im AD... Aber in de Configuration Partition, Unter CN=<OrgName>,CN=Microsoft Exchange,CN=Services

...und warum ist es so, technisch gesehen? Ich fand das bisher bei zentralen SQL-Clustern, auf die mehrere Fachbereiche mit unterschiedlichen DBA-Truppen und unterschiedlichen Ressourcen-Anforderungen zugreifen, eigentlich recht charmant. Und das Argument, dass sich mehrere Instanzen einen Kampf um Hardware-Ressourcen liefern würden, gilt ja nur dann, wenn man die Ressourcen nicht korrekt segmentiert. Tut man dies jedoch, so könnte man argumentieren, dass man durch mehrere Instanzen gerade die Möglichkeit hat, jedem Subset von Datenbanken eine bestimmte Menge an Ressourcen zu garantieren...

...und die sind definitiv und erwiesenermaßen unhackbar und frei von Fehlern, die eine Sicherheitslücke offen lassen

Exchange speichert nahezu seine gesamte Konfiguration im AD, inklusive Zeitstempel und Watermarks. Das ist einer der Gründe, warum das Anfertigen von Snapshots einer Exchange-VM unsupported ist und ein Backup vollständiger Exchange-Server so orchestriert werden muss, dass zum gleichen Zeitpunkt auch ein AD-Backup erzeugt wird.

Moin, ich empfehle - meist vergebens - meinen Kunden den Split Permissions Mode fast so lange wie es das gibt. Ich empfehle - mit noch geringeren Erfolgsraten - Exchange grundsätzlich in einem separaten Resource Forest zu betreiben. Und dort wieder mit Split Permissions. Und den Trust des Ressource Forest gegenüber dem User Forest zu filtern. Ich empfehle, Active Directory weder als Identity Management noch als Configuration Management zu missverstehen und folglich zu missbrauchen. Ich empfehle, Admins in die Protected User oder, besser, in ein Authentication Silo. Und das kombiniert mit Tiering. Die ersten zwei hätten die Übernahme des User Forests im vorliegenden Fall verhindert. Der dritte Punkt hätte, wenn man ihn konsequent umsetzt, den Wiederaufbau nach einer möglichen Übernahme des User Forests zu einer planbaren Übung statt zu einem Disaster gemacht. In der Realität? Die Admins wollen doch nur Bequemlichkeit. Lieber alle paar Jahre einen Breach und Stress und Nachtschichten, als irgendwas in den eigenen Abläufen zu ändern.

Anderen Port für die anderen Webdienste wie Dein NAS. Oder mehrere FQDNs für die gleiche IP und einen Reverse Proxy, der anhand des aufgerufenen FQDN weiterleitet statt anhand vom Unterverzeichnis.

Wenn Du /RDWeb weiterleitest, bekommst Du eben nur RDWeb und alles darunter. RD Gateway sitzt nicht in einem Unterverzeichnis, sondern direkt am Anfang.

Moin, für RDG kannst Du keinen Context-Switch verwenden, das braucht die Weiterleitung von /

In einem freien offenen Forum kann keine verbindliche Rechts- oder Lizenzberatung erteilt werden. Aber nach diesem Hinweis: Ich würde jetzt vorsichtig sagen, dass Du keine CALs brauchst, sofern der AADConnect-Server die Kommunikation stets selbst initiiert. Das dürfte bei Dir aber der Fall sein.

Bei Server 2019 scheinen sich diese Eval-Umwandlungsprobleme wirklich zu häufen. Ich würde daher keine Zeit verschwenden, den Server "einfach" neu installieren und das ganze als teures Lehrgeld im Hinterkopf speichern. Eine nicht aktivierte Vollversion läuft ja eine ganze Weile. Wenn man sich theoretisch vorstellen kann, den jeweiligen Server später produktiv einzusetzen, sollte man keine Eval, sondern von vorn herein eine Vollversion dafür nehmen. Wenn ich mich recht erinnere, darf eine Eval sowieso keine produktiven Workloads ausführen...

...und ein Loadbalancer macht das automatisch sicherer? Von den 50% der Unix-Linux-Webserver weltweit, die von HeartBleed betroffen waren, werden die meisten hinter Loadbalancern gestanden haben...

https://freeloadbalancer.com/

Die Quotas noch einmal drüberbügeln?