NorbertFe

Ich glaub die arbeiten im selben Büro, oder direkt in der Nachbars***aft. Ansonsten kämen nicht unterschiedliche Entwickler auf die selben doofen Ideen. ;) PS: Lustig, dass die deutsche Neighborhood zensiert wird. ;)

Alternativ einfach Windows Server 2022 nehmen, da geht das wieder ;)

Ist es beruhigend, wenn Webex identische Gedanken hervorruft?

Is gar nicht mal so cool, die neue Technik. ;)

Du musst halt verstehen, dass das eine userinstallation/-Programm ist, welches x-mal pro pc (je nach Anzahl der Benutzer) installiert und aktualisiert wird (am Ende liegt es zig mal in den verschiedenen User Profilen). Das macht man „heutzutage“ so. ;)

Keine Ahnung, aber ich kenne diesen Bildschirm: https://jasonhowe.net/2019/05/03/migrate-from-frs-to-dfs-to-promote-windows-server-2019/

Glaub mir doch auch mal :p

Nicht als DC. da weigert sich Windows 2019 soweit ich mich erinnere.

OK, aber so oder so, ohne DFRS SYSVOL wär der 2019er gar nicht erst in die Domäne gekommen. ;)

Da ist aber noch einiges Rot in deinem Report und aktuell ist der vielleicht, aber nicht mit dem aktuellsten Skript. ;)

Oder Januar.

Ja aber 2019 geht afaik noch mit ntfrs rein. Erst ab 2022 geht das nicht mehr.

Wieviele Interfaces hat denn dein Exchangeserver?

Du hast doch zwei alte dcs? Was sind da für Meldungen?

Dann solltest du da erstmal ansetzen und diese Fehler zu beheben. Die Event id kommt jetzt aus dem neuen oder aus dem alten dc? Klingt jedenfalls sehr schräg, was da vor sich geht. Im Zweifel jemanden holen der sich auskennt.

Wozu? wenn er den deinstalliert passiert das automatisch, und da er ja nur 2 hat, wo sollten die denn landen? ;)

Steht auch was in den eventlogs? bye norbert ps: also entweder Domain oder Domäne. ;)

Ja, das stimmt (leider). ;)

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.