NorbertFe

Dass du keinen Stromausfall hast. SCNR. Bye Norbert

Der neue Server hat eine neue IP und vergibt keine Adressen aus dem anderen Bereich? Dann wirst du vermutlich den IP Helper auf dem Gateway umkonfigurieren müssen. Das is kein Clou, das ist normal.

Also so wie ich oben sagte. Mal mit einem funktionierenden System vergleichen. ;) Aber gut, wenn es jetzt läuft. Bye Norbert

Hmm den Nachsatz zum Thema Security hast du jetzt lieber nicht bewusst wahrgenommen, oder? ;)

Du kannst exchangeserver nicht offline patchen afair.

Stimmt, dann ignoriert man sie am besten. :/ schau doch einfach mal in den Screenshot den ich oben gemacht hab. Dann fällt die bestimmt auf, dass es weitere Attribute gibt, die mit msexchmailboxmanager beginnen.

Ich tippe weiterhin drauf, dass irgendwo noch mailboxmanager Settings vorhanden sind. Du antwortest ja nicht auf die Frage. ;) Ansonsten bleibt nur der Vergleich mit einem funktionierenden System. Das ist nur im Forum echt schwierig, wenn man nur die paar Infos hat.

Nö, denn eine CA ist eine CA genauso wie ein DC ein DC und ein Hyper-V Host ein Hyper-V Host ist. Ob das für die jeweilige Umgebung paßt, sei mal dahingestellt, aber da wird man dann eben anhand der Umgebung entscheiden müssen. Die vorherigen Aussagen sind ganz klar als best practice zu verstehen. Wenn man die nicht einhalten kann oder will, dann kann man das tun, aber das ist dann eben nicht mehr best practice. ;)

Sehr merkwürdig. Und was steht da sonst noch so drin? Laß dir doch nicht alles aus der Nase ziehen. Get-EmailAddressPolicy "default policy" | fl https://learn.microsoft.com/en-us/exchange/email-addresses-and-address-books/email-address-policies/email-address-policies?view=exchserver-2019

Set-EmailAddressPolicy "Default Policy" –IncludedRecipients AllRecipients -ForceUpgrade das setzt normalerweise die Policy korrekt. Deswegen meine Frage, welchen Befehl du denn jetzt eigentlich ausgeführt hast.

Nochmal anders: Ich käme nicht auf die Idee unfreiwillig einen Snapshot eines Exchangeservers zu nutzen. Zieh dir ein vernünftiges Backup vorab und nutze das.

Einen Snapshot eines Datenbanksystems zu erstellen ist in der Form gute Idee. Ich käme freiwillig nie auf die Idee einen Exchange aus einem Snapshot zurückzuholen.

Und was gibt dir jetzt ein get-emailaddresspolicy aus?

Weil ein DC der NUR ein DC ist mal eben ersetzt werden kann. Sobald weitere Dienste drauf laufen ist das meist nicht mehr der Fall. Zusätzlich kommt immer auch das Thema Security eines DCs dazu.

Ich meine den hier: Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients

Welchen Befehl genau hast du denn jetzt ausgeführt? Offenbar fehlen ja die Empfänger der Empfängerrichtlinie. ;)

Ja schon klar, Sicherheit ist ja insgesamt nur bescheuert. Hab ich wenig Verständnis. bye norbert

Wie sieht’s denn bei den anderen mailboxmanager Attributen aus? schau mal hier: https://blog.expta.com/2011/06/fix-for-default-policy-with-mailbox.html?m=1

Der "Mailanteil" ist eigentlich weniger kritisch, denn dazu gibts ja genug tools und sogar inzwischen MS eigene Möglichkeiten. Interessanter sind Teams und Sharepoint, denn für die wirst du fast immer entsprechende 3rd Party Tools brauchen, wenn du die Daten mitnehmen willst/musst. Ich würde mal davon ausgehen, dass man da locker von 12 Monaten mit Vorbereitung usw. ausgehen kann. Wir haben das neulich mit einem Tochterunternehmen (nur ca. 30 Personen) gemacht und da durften bestimmte Daten vernachlässigt werden bzw. wurde Teams und Sharepoint von denen kaum oder gar nicht genutzt. Da hat dann die Vorbereitung und Testphase entsprechend auch mehrere Monate gedauert (auch weil die Kollegen nicht nur dieses Projekt auf dem Tisch hatten). Die eigentliche Umstellung war dann aufgrund der Größe entsprechend schnell. Was Zeit frist sind eher die klassischen lokalen Themen wie Domain Join ins neue AD (wenn man es will und braucht) und die damit zusammenhängenden Datenmigrationen (Userprofile usw.) Bye Norbert

Haha das is ja wirklich uralt. Hab grad die Fehlermeldung nochmal genauer gelesen. ;) Du hattest in Exchange 2003 dort Postfachmanagerrichtlinien reingeschraubt. Die gibts aber schon ewig nicht mehr, und die einzige GUI, die das damals konnte war der Exchange System Manager. Da wirst du jetzt mit adsiedit ranmüssen: Geh mal in adsiedit in den Configuration Container und dann unter CN=Recipient Policies,CN=DEIN-ORGNAME,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=deinad,DC=tld dort dann die Eigenscahften der Default Policy aufrufen und zu msExchMailboxManagerFolderSettings gehen und alles rauslöschen was dort drin steht.

Wie gesagt, im Zweifel schauen, ob man was im Logfile von Exchange Online finden kann. Da muss ja der Anmeldeversuch zu sehen sein. Alternativ einfach mal einen eigenen kleinen SMTP Service hinstellen, damit man einfach an die Logfiles kommt. Ich kann mir zwar nicht vorstellen, dass so ein Drucker keine Logs erzeugt, aber ob und wie wird man wohl nur über den Herstellersupport rausfinden. Bye Norbert

Probier mal: Set-EmailAddressPolicy "Default Policy" –IncludedRecipients AllRecipients -ForceUpgrade Nach ca. 15 Jahren fällt das auch mal jemandem auf? ;)

Hallo, Microsoft hat die PreRequisites geändert. Neuerdings wird der Message Queuing (MSMQ) nicht mehr benötigt und kann deinstalliert werden. Da der Dienst gerade erst im April 2023 mit seinem eigenen Security Bulletin bekannt wurde: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21554 kann man natürlich durch die Deinstallation jetzt diese potentielle Schwachstelle grundsätzlich entfernen. Dazu einfach auf dem Exchange per Powershell: Remove-WindowsFeature NET-WCF-MSMQ-Activation45 https://learn.microsoft.com/en-us/exchange/plan-and-deploy/prerequisites?view=exchserver-2019 Bye Norbert PS: Ich seh grad, dass damit ja nur die .net MSMQ Activation entfernt wird. Den Dienst wird man mit Remove-WindowsFeature MSMQ los. Nur lustigerweise steht das nirgends bei MS im Artikel. :/

Natürlich, das war einfach ohne Wertung meinerseits sondern allein als Bestätigung, dass system engineer nicht zwingend mit einem Hochschulabschluss gekoppelt ist.

Vor allem hätte das den Vorteil, dass Gruppen die man im AD aus dem Sync fallen läßt bzw. löscht im Azure dann nicht einfach ersatzlos weg sind, sondern man braucht dann bloß wieder die Gruppen schachteln. Denn Gruppen landen leider nicht im Azure AD Papierkorb. ;) Wie mein Sharepoint Kollege schon feststellen durfte.