Dukel

Wieso installiert man bei einem Cluster zwei unterschiedliche Versionen? Oder wurde der eine Node aktualisiert und der zweite Node kam später hinzu?

Hier wäre immer noch die Frage offen, wieso die selbe Software mit unterschiedlichen Namen installieren wird. Was ist das für ein Monitoring? Bei einem klassischen Failovercluster mit einem Shared Namen / IP würde man diesen (und ggf. beide Nodes unabhängig (mit eigenem Namen) monitoren.

Dann behaupte ich das Gegenteil :)

Nachdem es unterschiedliche Dot.Net Requirements gibt sollte man das nicht direkt machen: https://www.alitajran.com/which-net-framework-for-exchange-server/

Was hattest du denn für Ideen? Evtl. kannst du Teile daraus als Projekt umsetzen.

Nochmal nachgeprüft. Das ist bei dem Connector :587 der Fall. :25 und :465 haben diese Einschränkung nicht.

Theoretisch kann auch HW befallen werden. Es gab wohl schon Maleware, welche sich im Bios eingenistet hat. Außerdem kann ja eine bestimmte Hardware, die man dann austauschen sollte bzw. sauber konfiguriert werden sollte, das Einfallstor gewesen sein.

Vielleicht hilft dir folgender Link: https://www.codetwo.com/admins-blog/how-to-prevent-internal-email-spoofing-in-exchange/

Diverse Recovery Tools, Externer Datenrettungs DL. Letzteres ist empfehlenswert, da man sonst mehr kaputt machen kann.

Wieso installierst du den Lic. Server auf dem DC und nicht auf dem Terminalserver? Hier wäre dann alles 2019 (Broker, RDS Host & Lic. Server)!

Ist das entsprechende Audit Log aktiviert?

Ich meine, per Default, ist das nicht erlaubt, wenn es den Account administrator@deinedomain.de gibt, dass jeder mit dieser Adresse schicken darf. Hier greifen die Exchange Berechtigungen.

Kurzes Googlen: https://www.security-insider.de/azure-ad-anwendungsproxy-fuer-die-sichere-bereitstellung-von-webapps-a-1116308/ Hilft das?

Hast du pro Tier eigene Adminrechner / Sprungserver? oder einer für alle Tiers? Sind die Adminrechner besonders abgesichert? 2FA? Credential Guard? Bitlocker? ...

Für mich klingt das so, dass (Automatisches HA) möglich ist innerhalb des selben Clusters, aber nicht zu anderen Clustern (hier gilt dann die 90 Tage Regelung).

Wichtig ist, dass es eine Zeitquelle gibt. Wieso sollten die Clients (und andere) nur von einem DC die Zeit erhalten? Wieso nicht von allen? Wieso die Firewall von extern und nicht von intern?

Wie sieht es generell mit SQL Verbindungen vom Client aus? Merkt man z.B. vom SSMS einen unterschied ob dieser auf dem Client oder Server gestartet wird?

Tipp dafür: Set-MailboxDatabase -IsExcludedFromProvisioning:$true

So ein minimales Script braucht man nicht suchen, das geht aus dem Handgelenk: $user = Get-ADUser username -Properties mail # Wenn es genauer sein soll, sollte man proxyAddresses nutzen, muss dies aber extra parsen! if($user.mail -eq $user.UserPrincipalName){"ok"}else{"bad"} # Geht auch in einer Schleife für alle Nutzer foreach($user in Get-ADUser -Properties mail -Filter '*'){ if($user.mail -eq $user.UserPrincipalName){ "ok: $($user.SamAccountName)" }else{ "bad: $($user.SamAccountName)" } }

Veeam arbeitet hier anders. Hier wird der komplette Server (incl. der DB) gesichert und bei einem Single Item Restore wird das Backup gemountet (bei Exchange wird die DB gemountet) und man greift darauf zu und kann Postfächer oder einzelne Elemente restoren oder exportieren. Dafür ist kein Bricklevel Backup notwendig. @Scorp1337 Man könnte das entsprechende Postfach in eine eigene DB auslagern (nicht vergessen, diese DB dann nicht für andere Postfächer nutzbar machen). Diese kann man dann im Backup ausnehmen. Entweder diese DB in ein eigenes Laufwerk (und dieses ausnehmen) oder wie folgt: https://helpcenter.veeam.com/docs/backup/vsphere/backup_job_vss_exclude.html?ver=120

Testen kannst du es schon mit einzelnen Cloud Usern. Aber ob das so sinnvoll ist kann ich dir nicht sagen. Im Betrieb möchte man auf jeden Fall einen Sync und keine zwei unterschiedliche (AD und Cloud) Accounts. Es kommt auch auf das Ziel an. Möchte man langfristig komplett Cloud Only? Möchte man Hybrid bleiben? Um die Verwirrung aufzulösen hilft dir ein DL.

Ich würde auch empfehlen einen DL dazuzuholen. Auf jeden Fall möchtest du die Benutzer nicht manuell anlegen sondern synchronisieren!

Das ist bei Veeam Dokumentiert: https://helpcenter.veeam.com/docs/backup/vsphere/replica_resume_disconnect.html?ver=120

Wenn man an den Voraussetzungen nichts machen kann muss man initial halt Geduld haben. Einfach den Copy Job laufen lassen und nach zwei Wochen ist es inital übertragen und es werden nur noch die Änderungen übertragen. Evtl. gibt es bei AWS auch eine Send-In Möglichkeit. Man schickt einen Datenträger mit dem Backup und diese spielen die Daten in Ihrem RZ ein. https://aws.amazon.com/blogs/aws/send-us-that-data/

Daher sollte man sich angewöhnen von Core-Lizenzen und nicht von Server-Lizenzen zu sprechen. Dann sollten solche Nachfragen obsolete sein.