AFM_Adm

Wie ich herausgefunden habe wurde dies zum 01.10.2022 für alle Tenannten aktiviert: Azure Security Defaults (msxfaq.de)

Aus verschiedenen Gründen sollen nur die DC's am eigenen Standort verwendet werden. Danke für den Tipp. Aber geht es bei dem "Scalability Mode" nich darum, dass die DFS-Stammserver den DC am gleichen Standort nutzen oder was hat dies mit den Clients zu tun?

Moin zusammen, wir bekommen seit ein paar Tagen die Aufforderung wenn man sich an Microsoft365 anmeldet, MFA einzurichten und das man hierzu 14 Tage Zeit hat. Bewusst aktiviert haben wir dies nicht, wird anscheinend durch MS erzwungen. An Sich ist MFA ja auch eine tolle Sache, nur haben leider nicht alle User ein Smartphone. Welche Möglichkeiten habe ich, wie löst ihr das? Durch Whitelisting, etc.? Bekommt ihr auch seit ein paar Tagen die Aufforderung zur Einrichtung? Leider finde ich keine Ankündigungen dazu.

Moin, Domain Based DFS - Ja. Beide DC's als Namespace-Server - Ja. Target-Shares - jeweils nur die Shares am eigenen Standort verfügbar.

Ja, es gibt zwei Standorte mit den entsprechenden Subnets.

Wie meinst du das? Es geht um Zugriff auf ein Filesystem per DFS und muss daher die Domäne auflösen können.

Dies würde doch nur Sinn machen, wenn die DC's sind nicht direkt erreichen könnten bezgl. Replikation?

Moin zusammen, folgende Problemstellung habe ich (vereinfacht dargestellt): 2 Server-Netze (Standort A und B mit jeweils 1 x DC), 2 Client-Netze (Standort A und B). Die Server-Netze können untereinander kommunizieren, die Client-Netze nur mit dem Server-Netz am gleichen Standort. Bei der Namens-Auflösung der Domäne beispiel.local im Client-Netz B, gibt der DC im Server-Netz B, beide DC's wieder (den von Standort A und von Standort B), kann den DC an Standort A aber nicht erreichen. AD Sites und Services ist konfiguriert und den entsprechenden Subnetzen der richtige Standort zugewiesen. Mit "nltest /dsgetsite" getestet wird auch der korrekte Standort angezeigt auf dem Client. Die Clients am Standort B versuchen aber immer den DC am Standort A zu erreichen. Was für Lösungsmöglichkeiten gibt es hier?

Was machst du mit dem Desktop, etc.? Was machen die Notebook-User, wenn diese Offline arbeiten wollen? Und für Desktop, etc.? Klappt nicht offline oder? Wie sind deine Erfahrungen hinsichtlich Offline Dateien, klappt das zuverlässig?

Was nutzt ihr statt Folder Redirection denn?

Clients sind aktuelle Windows 10 Systeme mit Patches. Serverseitig Windows Server 2016 mit aktuellen Patches.

Hallo zusammen, wir nutzen zur Zeit servergespeicherte Profile, da die User öfters die Arbeitsplätze bzw. Rechner wechseln und damit die Notebook-User ihr Profil Offline dabei haben. Leider sind bei Nutzung der servergespeicherten Profile die Anmeldezeiten durch den Sync sehr lang und gibt es hin und wieder auch mal Probleme damit. Die Alternative von MS sind ja Ordnerumleitungen. Hierbei hätten wir aber zwei Herausforderungen: 1. Nutzung offline bei den Notebooks bzw. im Homeoffice bevor die VPN-Verbindung steht. 2. Haben wir mehrere Standorte und mit standortbezogenen Fileservern, auf die dann die Ordnerumleitungen zeigen müssten. Wenn die User dann an den verschiedenen Standorten sind, hätten sie verschiedene Profile. Wir löst ihr diese Herausforderungen oder gibt es für das Szenario ein Best-Practice Ansatz?

Im SMTP Log vom Exchange steht nur folgendes: 250... Recipient ok, DATA, "354 Enter mail, end with '.' on a line by itself", *,,"HandleError has encountered a suspicious connection reset from a remote, non-mailbox transport server." -,,Remote

Doch genau, der lokale Exchange nimmt die Mail vom Postfix an und wird sie dann beim Smarthost nicht los und hängt in der Queue vom lokalen Exchange. Im Log vom Exchange finde ich auch nur den Fehlercode den ich im ersten Post geschrieben habe. Auf dem Exchange sind nur die MS-Boardmittel, keine 3rd-Party Tools oder Scanner installiert. Firewall prüft zwar den Verkehr, aber habe in den Logs nichts gefunden und testweise die Security-Features deaktiviert gehabt ohne Erfolg.

Die externen E-Mails werden in der DMZ vom einem Postfix angenommen und anschließend an den internen Exchange 2016 weitergeleitet. Für einen bestimmten Adressraum (Subdomain) werden E-Mails per Smarthost an ein anderes internes System (TK-Anlage) weitergeleitet. Dies funktioniert auch wie im Eingangspost beschrieben seit Jahren ohne Probleme, nur bei externen E-Mails die ihren Ursprung von Office365 (Exchange Online) haben, gibt es diese Probleme.