NorbertFe

Da wo die WID (Windows Internal Database) immer liegt. ;) Such mal.

Microsoft hat heute die Januar 2023 Exchange Updates veröffentlicht. Wie immer gibts mehr Infos auf dem Exchange Team Blog: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-january-2023-exchange-server-security-updates/ba-p/3711808

Wär sehr merkwürdig, wenn man jedesmal den Schema Master verschieben müßte. Ich kenn das Problem, dass das Update fehlschlägt, wenn das beim ersten Mal/Exchange in einer "auswärtigen" Site durchgeführt wird. Aber das Schema ist ja global vorhanden, und sollte beim zweiten und allen weiteren Exchangeservern keine Probleme machen. Falls doch, kann er euch ja einen Screenshot schicken. Denn der Fehler kommt ja dann sichtbar auf denjenigen zu. ;) Also wenn das selbe CU wie beim ersten Exchange verwendet wird, sollte der Schema Master egal sein (sollte, weil es ja Pferde und Apotheken gibt).

Also nur Nachteile :)

Und warum braucht man sowas?

Was genau ist denn dein Ziel?

Vielleicht hilft das: https://www.frankysweb.de/exchange-2016-eac-nur-im-internen-netzwerk-freigeben/

Das weiß DO. ;)

Wie schon gesagt, das geht nicht, weil Name_Vorname nicht eindeutig in einer Domäne gewährleistet werden kann. Alternativ bau halt den %Username% um in Name_Vorname (dürfen halt maximal 16 Zeichen sein)

Da fehlt auf jeden fall ein Backslash hinter c:

Ja. Mit %username% ;)

Ja.

Irgendwie auch logisch, wenn man drüber nachdenkt, oder? ;) wie sollte etwas was nichts macht eine Änderung bewirken?

Bei mir musst du dich dafür nicht entschuldigen. War nur ein Hinweis, dass es da oben immer noch steht und es grundsätzlich eben Infos sind, die man nicht öffentlich bereitstellen sollte. Gründe dafür will ich nicht erläutern. :)

Und der kundenname wieder öffentlich im Forum. :/

Weiß nicht, was du genau damit meinst, aber üblicherweise kann man sich den Pfad sparen, vor allem weil in deinem Fall explizit ein DC angesprochen wird. Wenn der offline ist, geht das Login Script definitiv nicht mehr. Für alles andere hast du zwar ganz viel geschrieben, aber nix, was wirklich hilfreich ist. Was steht denn im Eventlog der Clients, bei denen es geht bzw. nicht geht? ggf. sogar mal das GP Logging hochdrehen. @daabm kann dir erklären wie das geht. ;)

Nee, weil die Adressliste eben bei Cloudpostfächern aus der Cloud kommt und nicht lokal. Insofern wars nicht mal den Versuch wert. ;)

dann sollte ein Update lokal aber keine Auswirkungen zeigen.

Pauschal: Ja, aber nicht unbedingt, weil der Virenschutz ausgelagert wird, sondern weil die Verbindung vom Internet aus nicht im internen Netz landet. ;)

Nein default ist nicht alles gewählt sondern mailbox User ist auch deaktiviert. https://learn.microsoft.com/en-us/exchange/mail-flow/connectors/receive-connectors?view=exchserver-2019#default-receive-connectors-created-during-setup Deswegen mein Hinweis, dass man sowas am besten mit einem eigenen connector regelt. Oder noch besser - relay in die dmz.

Das dürfte aber afaik nur mit 2019 funktionieren. 2016 geht nicht: https://learn.microsoft.com/en-us/exchange/clients/client-access-rules/client-access-rules?view=exchserver-2019

Ist jetzt auch nichts was ich unter Firewall oder waf abheften würde. ;) Ja leider verwenden viele den default connector und aktivieren auf ihm die Authentifizierung. Empfehlenswert, wenn man kein eigenes relay davor schalten kann oder will, ist ein eigener receive connector der aus dem Internet nur anonym zulässt und korrekten ehlo String und Zertifikat anbietet. persönlich bin ich ein Freund des exchange Edge, aber da steh ich vermutlich allein auf weiter Flur. ;)

Da tuts die oft vorhandene Sophos sg oder xgs ganz ok. Alternativ kann man auch kemp nehmen, die sind da ganz fit und bieten deutlich mehr Möglichkeiten als bspw. die Sophos. Je nachdem wieviel man selbst investieren will oder kann, geht natürlich auch https://www.frankysweb.de/apache-als-reverse-proxy-fuer-exchange-server-teil-1/amp/ aber da sollte man sich dann eben auch damit beschäftigen (gut, bei den anderen Dingen auch).

Je nach Version funktionieren dann diverse Funktionen in owa nicht mehr. Ich würd eher mal über mfa für owa und exp nachdenken. Keine Firewall zwischen dc und exchange mailboxservern erlaubt. Und dann kannst du dir die dmz auch sparen. ;) als Tipp, Port 25 auf keinen Fall von extern per Authentifizierung anbieten, und auch die anderen Protokolle, imap, Pop und smtp 587 am besten nicht verwenden.

Ja, das sah ich in der Antwort ganz oben ähnlich. ;) Es gibt aber von den 100 Clients abgesehen ja vielleicht auch noch Server ;) ich wiederhole mich bzw. Nils mal: ohne Anforderungen und komplette Infos sucht man sich keine Methode/Werkzeuge aus.