Jump to content

AFM_Adm

Members
  • Gesamte Inhalte

    277
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von AFM_Adm

  1. AFM_Adm

    Microsoft365 und MFA

    Wie ich herausgefunden habe wurde dies zum 01.10.2022 für alle Tenannten aktiviert: Azure Security Defaults (msxfaq.de)
  2. 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?
  3. AFM_Adm

    Microsoft365 und MFA

    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.
  4. Moin, Domain Based DFS - Ja. Beide DC's als Namespace-Server - Ja. Target-Shares - jeweils nur die Shares am eigenen Standort verfügbar.
  5. Ja, es gibt zwei Standorte mit den entsprechenden Subnets.
  6. Wie meinst du das? Es geht um Zugriff auf ein Filesystem per DFS und muss daher die Domäne auflösen können.
  7. Dies würde doch nur Sinn machen, wenn die DC's sind nicht direkt erreichen könnten bezgl. Replikation?
  8. 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?
  9. 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?
  10. Was nutzt ihr statt Folder Redirection denn?
  11. Clients sind aktuelle Windows 10 Systeme mit Patches. Serverseitig Windows Server 2016 mit aktuellen Patches.
  12. 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?
  13. 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
  14. 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.
  15. 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.
  16. Moin zusammen, ich habe ein Problem das E-Mails die von externen Absendern von Exchange Online (Office 365) rein kommen und per Smarthost an ein anderes internes System weitergeleitet werden mit folgenden Fehler in der Queue auf unserem lokalen Exchange 2016 (aktuelle Patches) liegen bleiben: 3;2;[{LED=450 4.4.318 Connection was closed abruptly (SuspiciousRemoteServerError)};{MSG=};{FQDN=};{IP=};{LRT=}];0 Dies passiert nur von externen Absendern die Exchange Online nutzen, ich habe dies selbst nachgestellt mit einem Office 365 Testaccount und konnte das Problem nachvollziehen. Von anderen externen Absendern, z.B. Freemailer, etc. tritt das Problem nicht auf. Hatte jemand von euch schonmal das Problem in Verbindung mit Exchange Online Absendern bzw. hat eine Idee oder einen Tipp?
  17. Werden bei dir die Räume als verfügbar gekennzeichnet? Siehe rechter Teil von meinem Screenshot.
  18. Ist wohl ein bekanntes Problem laut MS. Es wundert mich aber, wieso ihr keine Probleme damit habt!? https://docs.microsoft.com/de-DE/outlook/troubleshoot/calendaring/no-available-rooms-for-meeting-outside-working-hours
  19. Ich habe mal noch ein bisschen getestet, leider ohne Erfolg. Das einzige was wirklich hilft ist die Arbeitszeit im persönlichen Kalender zu ändern. Anbei mal ein Screenshot, der Raum ist in diesem Beispiel nur bis 13.00 Uhr reservierbar, er wird in der Kalenderansicht auch ab diesem Zeitpunkt ausgegraut dargestellt, ist laut der Raumliste aber verfügbar. Und ab 17.00 Uhr taucht er nicht mehr auf als verfügbarer Raum in der Raumliste auf, außer ich ändere meinem persönlichen Kalender die Arbeitszeit z.B. auf 18.00 Uhr, dann kann ich diesen Raum bis 18.00 Uhr buchen. Das Verhalten in OWA ist identisch, daher schließe ich Outlook als Problem jetzt auch mal aus.
  20. Ja, ok für so Displays sollte man das aufjedenfall machen :) Danke schonmal für die Hilfe! Wie gesagt, ich kann das Verhalten ändern, wenn ich die Arbeitszeit in den Kalenderoptionen meines persönlichen Kalenders ändere. Dafür müsste ich jetzt aber die Arbeitszeit von allen Usern per Powershell ändern. Ich kann mir vorstellen das es "leichte" Irritationen auslöst, wenn ich jetzt die Arbeitszeit der User im Kalender ändere.
  21. Das Verhalten hat sich mit AutoAccept nicht geändert. Was meinst du mit DeleteSubject? Das sollte doch mit diesem Problem nicht zu tun haben, da es dabei ja um die Anzeige des Betreffs im Kalender geht.
  22. Der Schalter für "Terminplanung nur während der Arbeitszeit zulassen" ist nicht gesetzt. Buchungsanfragen stehen nicht auf AutoAccept, sondern müssen genehmigt werden.
  23. Ja, habe ich gemacht: Identity WorkDays WorkingHoursStartTime WorkingHoursEndTime WorkingHoursTimeZone -------- -------- --------------------- ------------------- -------------------- Weekdays 01:00:00 23:00:00 W. Europe Standard Time Ja, IIS Reset habe ich auch getestet. Ich habe jetzt rausgefunden, dass die Anzeige der freien Räume in der Raumliste nicht vom Raumpostfach selber, sondern vom persönlichen Kalender abhängig ist. Mir erschließt sich der Sinn auch noch nicht richtig, aber wenn ich in Outlook in der Kalenderoptionen mit Arbeitszeit z.B. bis 23.00 Uhr ändere, wird mir das Raumpostfach als freier Raum angezeigt,
×
×
  • Neu erstellen...