cj_berlin

Der Administrator hätte dann keinen Zugriff mehr auf die Inhalte in diesen Datenbanken Hätte er bei einem frisch installierten System auch nicht.

Moin, wenn Postfachinhalte mit 3rd-Party-Tools migriert wurden, könnte das ein Überbleibsel davon sein. Definitiv so nicht vorgesehen. Ganz zu schweigen davon, dass man mit dem RID500-Administrator grundsätzlich nicht arbeiten sollte.

Moin, AutoVervollständigung muss jeder User selbst löschen. Du kannst sie administrativ nur komplett ausleeren, aber da wären die User vermutlich traurig. Wenn wirklich gelöschte User in der GAL (also im OWA oder Outlook im Online-Modus) auftauchen, musst Du klären und die GAL evtl. updaten. Was Du aber vermutlich siehst, ist das Offline-Adressbuch. Dieses kann der User jederzeit forcieren, ansonsten schaut Outlook alle 24h nach, ob sich das OAB auf dem Server geändert hat. Auch die OAB-Generierung kannst Du serverseitig explizit anstoßen.

Moin, meinst Du wirklich das Adressbuch (GAL), die AutoVervollständigung oder die persönlichen kontakte?

Moin, da die gängigen Produkte nicht "Laufwerke", sondern Dateien verschlüsseln, wird es wohl darauf ankommen, wieviele Versionen in SharePoint für diese konkrete Website eingestellt sind, und ob die Ransomware für diesen Fall vorgesehen hat, die Dateien so oft zu verändern, dass alle verfügbaren Revisionen durch verschlüsselte Kopien "aufgefressen" werden. Insofern kann SharePoint Online durchaus einen gewissen Schutz gegen etwas dümmere Ransomware bieten. Besser ist es jedoch, die Synchronisierung nicht zu verwenden und sich auf die Programme zu beschränken, die den "SharePoint-mäßigen" Zugriff über HTTP verwenden.

Moin, wenn ich das noch richtig im Kopf habe, ist GroupID nur für eine Custom Group relevant, und da wird eine GUID erwartet. Source muss dann auf 0 stehen. Bei Source=2 ist die Domain praktisch die Gruppe. Wenn die Filialen als AD Sites abgebildet sind, könntest Du mit Source=1 arbeiten, das wäre wohl am einfachsten und würde auch funktionieren, wenn ein Rechner die Filiale wechselt.

Eigentlich nicht, sonst würde O365 ja nicht funktionieren - oder? Das ist der Unterschied zwischen CNAME und A auf die IP des Exchange... Ich meine so etwas:

Moin, wenn nur AD-Member und darauf nur Outlook-Clients zu versorgen sind, kannst Du den Autodiscover-SCP in den zweiten Forest schreiben lassen (Export-AutodiscoverConfig). Wenn Du DNS zwingend brauchst --> siehe Norberts Vorschlag oder alternativ einen Alias (CNAME-Record). Den Alias könntest Du theoretisch sogar in der öffentlichen Zone von BBB setzen und bräuchtest zumindest dafür kein Split-DNS.

Moin, ist der Remote Registry Service aktiviert und wird er tatsächlich ausgeführt? Ich habe in letzter Zeit Situationen gesehen, wo er zwar per GPP auf Automatic gestellt wurde, aber nach einem Reboot tatsächlich nicht lief. Per GPO hat es besser funktioniert, aber auch nicht 100%... Die zweite Ursache wäre die Firewall auf der Zielmaschine (und vielleicht auch auf der Quellmaschine, obwohl das Blocken ausgehender Verbindungen leider seltener ist).

Ganz sicher? Ich meine, seit es nicht mehr Backup ist, sondern Backup & Replication, geht das... Aber in so kleinen Umgebungen, wo die Free Edition ausreicht, sieht man so selten LTO-Laufwerke...

Moin, das Bandsubsystem (Verwaltung für Wechseldatenträger) gibt es seit 2012 nicht mehr, somit kann WSB auch kein Backup mehr auf Band. Hol Dir Veeam, die Community Edition ist kostenlos.

Die Agenda mit Zeitfenstern ist übrigens seit Sonntag online

Moin, das sollte funktionieren. Die Frage ist nur, was Du damit erreichen möchtest. Beider Mechanismen arbeiten mit VSS, d.h. solange die Integration Components auf den VMs intakt sind, ist das Hyper-V-Backup genau so "application aware" oder nicht wie ein Backup aus dem Inneren einer VM. Ein Wort der Warnung: Wenn eine der VMs ein Domain Controller ist, musst Du den Zugriff auf dessen Backup so stark einschränken wie irgend möglich.

Kannst mich ja bei den Mods anzeigen.

Moin, ohne das hier bis in alle Tiefe durchgelesen zu haben: Der ganze Sinn von UDP ist ja, dass Pakete nicht bestätigt werden müssen. Insofern kriegt bei UDP der sendende gar nicht mit, ob sein Paket angekommen ist...

Hmmm... Teams? Geht im Browser. Edit: Auch WebEx geht im Browser, ist aber grottig.

https://james-rankin.com/articles/per-user-ftas-file-type-associations-in-windows-10-server-2012-r2-and-server-2016-the-final-word/

Das Problem war, dass EOP deren Mail als Spam geflaggt hat, und man hat gesagt "dann senden wir halt gar nicht erst an die" Zum Glück war es nicht mit den vorhandenen Mitteln möglich, das technisch umzusetzen.

Hier zum Einstieg: https://www.infoblox.com/wp-content/uploads/infoblox-white-paper-ad-dns-facts-and-fiction-1.pdf

Moin, in keiner besonderen Reihenfolge: Du hast offenbar kein Problem mit Exchange, sondern nur ein Problem mit RCA. Es kann sein, dass dort auch wirklich ein Problem besteht Mach eine QUALYS-Test (https://www.ssllabs.com/ssltest/ ), er wird schon zeigen, ob Du auf Deiner Seite irgendwas ausrichten kannst. Exchange per NAT zu veröffentlichen ist keine gute Idee. Der Router scheint keine Reverse Proxy-Funktion zu haben, Du solltest Dir also etwas suchen, was Du dazwischen schalten kannst.

Du musst unterscheiden zwischen "DNS läuft nicht auf DC" und "DNS, was auf DC läuft, wird nicht von Hinz und Kunz zur Namensauflösung angesprochen". Und ja, DCs ohne DNS und DNS auf anderen Servern ist eine unterstützte Konfiguration und von Microsoft dokumentiert. "Dokumentiert" und "unterstützt" ist aber etwas anderes als "empfohlen" und stammt aus einer Zeit, wo Du auf einem Uni-Campus 5000 Knoten im UNIX-DNS hattest, und daneben war noch ein Windows-Bereich mit AD und 50 Rechnern. Mit einer Konfigurationsverwaltung und Software-Verteilung. Die meisten Produkte, die nicht von Microsoft sind, benötigen dafür kein AD. Steht alles in den Event Logs. Attribute am AD-Objekt des Clients können auch bei der Diagnose helfen.

Moin, alles hier beschrieben: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536 TLDR; Auditing einschalten (hast Du ja schon gemacht) Event 2889 im Directory Service Log: Verbindungen ohne Signierung ODER ohne TLS Event 3039 im Directory Service Log: Verbindungen mit TLS, aber ohne Channel Binding Wenn keines dieser Events kommt, wird TLS ausgehandelt und offenbar auch CB verwendet. Wenn Du es ganz genau wissen willst, kannst Du den Diagnostic Level höher drehen und Dich auf einen Haufen Events vorbereiten NB: Die Einstellung "Require Signing" erzwingt die Signierung nur dann, wenn TLS nicht verwendet wird! @NorbertFe Warum sollte ich keinen Simple Bind auf 389 hinbekommen? Wenn die Signierung klappt, muss es doch gehen, und dafür braucht es keine Domänen-Mitgliedschaft... oder übersehe ich ob der frühen Stunde etwas?

Moin, wenn Du keine AD-Standorte hast, geht jeder Client davon aus, dass beide Exchange Server gleichermaßen gut erreichbar sind.

Ich wage mir nicht auszumalen, was Du mit "After-Rollout" meinst Aber Deine Organisation wäre nicht die erste, die ihre IT grundsätzlich durch diese Öffnung betreibt...

Doch, weil man es jedes mal wiederholen muss, wenn sich Berechtigungen ändern Und die "Lösung" sollte ja durch die Fachabteilungen verwaltbar sein, so wie früher in Notes