NorbertFe

Genau so, und nicht anders funktioniert das. Diese ganzen "Geburtstagskalender", "Urlaubskalender" und sonstige Gruppierungen sind im Allgemeinen für den A...h. Das funktioniert nur, wenn man sich dran hält und das ist meist genau 1x danach nie wieder, weil man vergessen hat, oder am Handy war usw. Bye Norbert

Functional level wird als Suchbegriff besser passen. ;) bye norbert ps: ich hab (leider) auch Kunden, da ist das Gateway die .12 oder .126 usw. ;)

Was auch kein Wunder ist, weil auf iOS alle die selbe Engine verwenden. ;) verwendest du das gleiche oder dasselbe Zertifikat?

Also unabhängig davon, wenn du den MX umschaltest, kommt bei IONOS sowieso nix mehr an. Dann kannst du evtl. noch in O365 noch IMAP Migration der bestehenden IONOS Postfächer durchführe, wenn da welche sind, oder zur Not eben von Hand und lokalen PST Files den Kram in O365 schieben. Dann arbeiten die Leute vorübergehend halt mal mit einem leerem Postfach und warten darauf, dass du ihnen die Mails ins neue Postfach schiebst. :)

WElchen Grund sollte es denn für den Co-exist geben? Man definiert am alten, dass er keine neuen Mails mehr bekommt und stellt alles auf O365 um. Ansonsten kann das natürlich nur schiefgehen.

Ex-online kann die Daten bei ionos auch abrufen. Dann muss man sich nur um historische Daten kümmern. Ich würde so schnell wie möglich den mx zu ex-o legen und alle Nutzer dort arbeiten lassen. Kein koexistenzbetrieb. Das ist vermutlich nur mehr Aufwand und bei Leuten die jetzt noch xp im Einsatz haben (als „Server“) vermutlich auch gar nicht notwendig.

Das ist tatsächlich vom Cluster. Das aktualisiert sich alleine. Zumindest hab ich das noch nie manuell irgendwo aktualisiert. bye norbert Ps: bitte zukünftig auf crosspostings hinweisen: https://www.frankysweb.de/community/exchangezertifikate/frage-bezueglich-cliusr-zertifikat-ex2019/#post-6060

Ja, den wollt ich mir ersparen. Hab grad genug anderen "Kram" an der Backe. ;) Naja vielleicht fällt ja noch jemandem was ein. Ansonsten berichte ich, sobald ich mehr weiß.

Intern siehts korrekt aus. Sonst wär das vermutlich schon früher aufgefallen.

wie geschrieben, sowohl ein get-remotemailbox (onprem) als auch ein get-mailbox (ExO) geben mir jedesmal meine korrekte Adresse als primary als auch unter ProxyAddresses die mit SMTP (also Großschreibung) zurück. Ich "vermute", da wird irgendwas generiert und da OOF ja mit empty sender geschickt werden, fällt irgendein Prozess auf die Nase, und zwar schon in der cloud, denn ich sehe im Hybrid Edge schon den OOF mit der falschen Author Address durchrauschen. Also wird der OOF mit der falschen Adresse generiert.

Hi, ich hätte da auch mal eine Frage, die evtl. schon jemand beantworten kann, der das Problem gelöst hat. Wir verwenden Exchange Hybrid und alle Postfächer sind cloud-basiert. Wir nutzen centralized mailflow. Cloud <----smtp---->Exchange Edge2<--smtp-->Exchange Mailbox<------smtp----->Exchange Edge1<-----smtp---->Internet Sieht mehr oder weniger aus, wie oben. Wenn ich jetzt den Abwesenheits-Assi aktiviere, dann erhält der externe Empfänger eine Abwesenheitsnachricht, die in etwa folgenden Absender hat: NorbertFE@tenantname.mail.onmicrosoft.com Das ist natürlich falsch und sollte mit unserer Domain rausgehen. Jemand eine Idee, welche Option ich irgendwo übersehen haben könnte? Im AD und AzureAD ist natürlich meine korrekte Mailadresse als SMTP:NorbertFE@Firma.tld drin. Danke Norbert PS: Den Thread gibts auch hier: https://www.frankysweb.de/community/exchangehybrid/out-of-office-reply-mit-falscher-adresse/

Sehe ich ähnlich. Welche Bauchgefühle gibts denn da so?

hattest du etwa Zweifel? ;)

Na der beste Weg dem Kunden zu erklären, wer einmal pfuscht zahlt halt drauf. Wäre ja jetzt für alle eine gute Gelegenheit, es in jeglicher Hinsicht besser zu machen. ;)

Ja mit gebastel und vorprogrammierten Problemen, sobald der zweite $Jens Müller eingestellt wird. ;)

Hast du doch schon. ;) sonst könntest du das ja wohl kaum einbinden so wie du es jetzt hast. also einfach neues Konto hinzufügen, Mailadresse des zusätzlichen Kontos und bei Notwendigkeit mit deinen Anmeldedaten authentifizieren. Achso und send-as rechte nicht vergessen. ;)

Nein, das kannst du nicht per Default belegen bei der Variante. Besser ist es sowieso (imho), wenn du zwei Exchangekonten im Outlook einbindest.

Das hängt davon ab, wo du den mx haben willst. Du kannst den MX lokal zeigen haben, dann läuft er wie bisher und die Mails für Cloudpostfächer werden über den entsprechenden Connector zur Cloud geschickt, oder man hat ihn in ExO, dann geht alles zu MS und von dort per Connector zu deinem lokalen Exchange der die lokalen Postfächer hat. Zusätzlich gibts noch den centralized mailflow, dann geht alles immer durch lokal. ;)

Kann ich wie gesagt nur allgemein beantworten was zum Thema ExO oder Onprem betrifft. Wer bisher OnPrem war, sollte sich die Lizenzen natürlich mal anschauen. Spätestens wenn irgendwelche O365 Lizenzen benötigt werden (meist ja Teams oder Sharepoint Online), kann man natürlich die onprem CALs meist durch entsprechende Pläne ersetzen. NAtürlich gibts die nicht geschenkt, und meist stellt sich dann recht schnell raus, dass die OnPrem Kosten gar nicht so hoch sind, wie man immer vorgerechnet bekommt (auch mit admin, Strom und Klima nicht). ;) Aber das ist halt ne Diskussion, die man bis aufs Messer führen kann, wenn man will. Alternativen gibts natürlich schon, aber da laß ich lieber andere zu Wort kommen. Bye Norbert

Je nach O365 Plan sind die aber dort bereits mit enthalten, so dass sich das ggf. als "Scheinargument" rausstellt. Ob das bei euch zutrifft, müßte man prüfen. Wenn ihr überlegt, auf O365/ExO zu wechseln, warum fragst du dann nach Alternativen vom Exchange? Wär denn das wirklich das Ziel, wieder Onprem eine neue Lösung hinzustellen? Bye Norbert

Wenn du die Rechte hast, führt das Exchange Update vom CU23 dich durch alles durch. Man kann es natürlich manuell am cmd prompt auch tun. Ein Schemaupdate kann natürlich auch tagsüber durchgeführt werden. Was soll denn da Probleme machen (in normalen Umgebungen, von der ich bei dir erstmal ausgehen würde).

WIeviele andere gibts denn? https://setup.microsoft.com/exchange/exchange-update da steht eigentlich alles. Grundsätzlich scheint deine Liste zu passen, aber ich habs jetzt nicht ausprobiert. Und ja du hast vergessen ganz am Ende noch das aktuellste SU (das von gestern) zu installieren. ;)

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).