AFM_Adm
-
Gesamte Inhalte
277 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von AFM_Adm
-
-
Am 21.10.2022 um 12:57 schrieb Squire:
Was spricht dagegen eine Policy auf Deinen Firewalls zu setzen, dass die Clients mit den DCs an Standort A und B wechselseitig reden dürfen?
Hätte doch auch den Vorteil, dass die Clients bei Ausfall des DCs am Standort immer noch mitspielen dürfen. Nebenbei (1 DC pro Standort finde ich etwas dünn - abhängig von der Anzahl der User ...)
Was mir noch einfällt ... ich denk mal Dein DC an Standort A hält die PDC Rolle ... manche Vorgänge am Client erfordern eine Verbindung zum PDC. Deshalb .. lass die Clients mit dem DC am Standort A reden
Aus verschiedenen Gründen sollen nur die DC's am eigenen Standort verwendet werden.
Am 21.10.2022 um 18:35 schrieb cj_berlin:Welche? Ich habe Umgebungen, wo Clients noch nie einen schreibbaren DC gesehen haben, vom PDCe ganz zu schweigen.
Was bei DFS-N sein kann, ist, dass es im "Consistency Mode" konfiguriert ist (Default-Einstellung). Du brauchst den "Scalability Mode".
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.
-
vor 17 Stunden schrieb daabm:
Ich versuch's noch mal: Was _genau_ versuchen sie zu erreichen?
Domain based DFS? Beide DCs als Namespace-Server? Target-Shares in beiden Standorten vorhanden und verfügbar? Fragen über Fragen
Du hast Fragen, Du suchst Lösungen. Dann mußt Du auch Input liefern.
Moin, Domain Based DFS - Ja. Beide DC's als Namespace-Server - Ja. Target-Shares - jeweils nur die Shares am eigenen Standort verfügbar.
-
vor 32 Minuten schrieb teletubbieland:
Naja, unter Active Directory Standorte und Dienste. Ob Du die IP Bereiche getrennt hast.
Ja, es gibt zwei Standorte mit den entsprechenden Subnets.
-
vor 21 Stunden schrieb teletubbieland:
Hast Du denn die Standorte im AD auch getrennt ?
Wie meinst du das?
vor 19 Stunden schrieb daabm:Was _genau_ versuchen sie zu erreichen? Also welcher Prozess auf dem Client versucht welchen Dienst auf dem DC zu erreichen?
Und wIe gesagt, AD ist nicht DNS. AD ist site aware, aber DNS nicht.
Zum DC Locator: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689
Da steht zwar auch noch "across forest trust", aber die Grundlagen sind auch dabei.
Es geht um Zugriff auf ein Filesystem per DFS und muss daher die Domäne auflösen können.
-
vor 9 Minuten schrieb NilsK:
Moin,
ich habe das Problem jetzt nur halb durchdrungen, vermute aber, dass du das Automatic Site Link Bridging abschalten musst.
Gruß, Nils
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?
-
Am 20.5.2022 um 15:12 schrieb teletubbieland:
Bevor hier Niemand antwortet...
Ich habe das Problem umschifft, indem ich bei Notebooks keine Ordnerumleutung mache und den Usern klar mache, dass Sie Daten, die sie überall haben wollen, eben auf dem Netzwerk ablegen sollen (User Home).Was machst du mit dem Desktop, etc.? Was machen die Notebook-User, wenn diese Offline arbeiten wollen?
Am 20.5.2022 um 15:51 schrieb testperson:Hi,
wäre evtl. OneDrive eine Option für euch? Alternativ hol die User zu den Daten und nicht die Daten zu den Usern -> Remote Desktop Bereitstellung.
Gruß
Jan
Und für Desktop, etc.? Klappt nicht offline oder?
vor 23 Stunden schrieb Sunny61:Auch wenn es schon länger her ist, wir arbeiten mit Ordnerumleitungen und Offline Dateien. Für verschiedene Fileserver bietet sich DFS an.
Wie sind deine Erfahrungen hinsichtlich Offline Dateien, klappt das zuverlässig?
-
vor 21 Stunden schrieb daabm:
Wieso netlogon.log? Zitat: "Note The log file can be found at: %windir%\debug\usermode\fdeploy.log" - ob das noch stimmt, weiß ich nicht mal
Wir nutzen FR schon lange nicht mehr.
Und ja, geht auch ohne die FR-GPO-Einstellungen zu verwenden. Steht sinngemäß in meiner Blog-Serie von oben, mußt nur die Reg-Werte passend setzen.
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?
-
vor 15 Minuten schrieb testperson:
Und die SMTP Logs vom Exchange und Smarthost schweigen?
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 -
vor 30 Minuten schrieb testperson:
Hi,
nimmt der lokale Exchange die Mail nicht von eurem vorgeschalteten Postfix an oder wird er die Mail nicht beim Smarthost los? Ich würde dann zusätzlich im SMTP Log vom Postfix oder eben Smarthost nach weiteren Infos suchen.
Spontan:
- Ist auf dem Exchange ein AV installiert, der im SMTP Traffic rumpfuscht?
- Ist eine Firewall dazwischen, die im SMTP Traffic rumpfuscht?
Gruß
Jan
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.
-
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?
-
vor 13 Stunden schrieb NorbertFe:
Vielleicht, weils bei mir eben nicht nachvollziehbar ist ;) Wie du siehst, ist da nix grau. Außer ich hab jetzt das Problem komplett falsch verstanden.
Und alle diese Räume hab ich erst am Freitag bei uns angelegt. Da ist also "keine" Sonderbehandlung über die Jahre passiert.
Werden bei dir die Räume als verfügbar gekennzeichnet? Siehe rechter Teil von meinem Screenshot.
-
Ist wohl ein bekanntes Problem laut MS. Es wundert mich aber, wieso ihr keine Probleme damit habt!?
-
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.
-
vor 2 Minuten schrieb Nobbyaushb:
Wenn sich das Verhalten nicht geändert hat müsste man jetzt in die Tiefe gehen - ich bin mir nicht sicher, ob das über das Forum klappen kann
Und ja, das DeleteSubject hat nichts mit dem Verhalten zu tun, wir haben aber Displays von TouchOne draussen vor den Türen und da muss man das setzten
(empfehle ich sonst immer....)
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.
-
vor 49 Minuten schrieb tesso:
Hast du händisch mal eine längere Zeit eingegeben?
Wo meinst du?
-
vor 1 Stunde schrieb Nobbyaushb:
Baue mal Testweise einen Raum/Ressource mit Autoaccept - würde mich jetzt direkt interessieren, ob der Fehler weg ist.
Per Default ist ja DeleteSubject auf True, das braucht man aber z.B.
Ich hänge mal den Output von unserem Konf-1 anonymisiert an (ich hoffe, nix vergessen...)
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.
-
vor einer Stunde schrieb Nobbyaushb:
Das ist bei uns definitv anders - auch ich habe Arbeitszeit bis 17:00h in meinem Profil, trotzdem kann ich den Raum um 22:00h buchen.
Der Schalter Ignore Working Hours im ECP bzw. per Shell ist auch wirklich gesetzt?
Ist der Raum auf AutoAccept oder gibt es einen Delegate?
Der Schalter für "Terminplanung nur während der Arbeitszeit zulassen" ist nicht gesetzt.
Buchungsanfragen stehen nicht auf AutoAccept, sondern müssen genehmigt werden.
-
vor 17 Stunden schrieb tesso:
Du hast die XXXX und die Zeiten entsprechend angepasst?
Und in der Exchange Powershell ausgeführt?
Nach deinem Output musst du wahrscheinlich die Timezone auch noch anpassen. Ich gehe davon aus der Server braucht eine deutsche Timezone, jetzt steht die Resource auf PST.
Ja, habe ich gemacht:
Identity WorkDays WorkingHoursStartTime WorkingHoursEndTime WorkingHoursTimeZone
-------- -------- --------------------- ------------------- --------------------
Weekdays 01:00:00 23:00:00 W. Europe Standard Timevor 16 Stunden schrieb Nobbyaushb:Alle unsere Räume und auch die anderen Ressourcen haben PST als Timezone.
Hast du nach Änderungen mal den IIS resettet?
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,
-
vor 2 Minuten schrieb Gerber:
Na dann stelle doch die WorkingHours mal wie @tesso geschrieben hat um...
Hat leider keine Auswirkungen.
Microsoft365 und MFA
in MS Azure Forum
Geschrieben
Wie ich herausgefunden habe wurde dies zum 01.10.2022 für alle Tenannten aktiviert: Azure Security Defaults (msxfaq.de)