gerber
Goto Top

Exchange Online mit lokalem Exchange nach Migration verwalten

Hi Community,

ich habe nun schon einige Migrationen von lokalen Exchange Servern nach M365 durchgeführt, bei denen ich teilweise gegen die Aussage von MS den letzten Exchange Server entfernt habe, aber auch Migrationen bei denen ich den letzten Exchange zur Verwaltung der Postfächer in M365 weiterhin nutze.

Ich habe die meisten Migrationen per Hybrid (MS empfohlen) durchgezogen. Aber auch mit Drittanbieter Tools.


Nun habe ich eine Anforderung, bei der ich gerade etwas auf dem Schlauch stehe.


Kurzer Aufbau:

-> Komplett neue Umgebung mit zwei Standorten (AD, DC, Exch -> alles Neu)
-> Alle Postfächer sollen in Exchange Online genutzt werden (120 Postfächer)
-> Azure AD Sync soll trotzdem für die Kennwortsynchronisation konfiguriert werden


Migration von:

Es wird von einem Exchange Server migriert:

-> Migration über Hybrid Wizzard ist nicht möglich, das die Firma aus einer bestehenden Firma ausgegliedert werden muss
-> Zugriff wird per EWS gewährt um die Migration über ein Tool nach M365 durchführen zu können


Problem oder Unklarheiten:

- Es soll in Zukunft für die Verwaltung der 120 Postfächer ein lokaler Exchange Server 2016 (Hybrid Lizenz) zum Einsatz kommen, welcher Hybrid die lokale Umgebung mit M365 verbindet

Nun stehe ich entweder gerade auf dem Schlauch oder habe ein Denkfehler wie genau ich am besten die Reihenfolge wählen soll um diese Migration durchzuführen.


Version 1:

- Exchange Server wird im lokalen AD (komplett neu angelegt) installiert.
- Azure AD Sync + Hybridkonfiguration wird durchgeführt
- Alle 120 Postfächer werden als New-RemoteMailbox über den lokalen Exchange in M365 angelegt, damit die lokalen AD Attribute korrekt befüllt werden
- Danach werden die Konten über das Tool vom Drittanbieter gematched und befüllt

Nachteil:

Hier kommt ein erheblicher Aufwand für das erstellen der Remote-Mailboxen über den lokalen Exchange zusammen.

Gibt es hier ein Script um für alle AD Benutzer ein Remotemailbox Postfach anzulegen ohne für jeden Benutzer einzeln ein Befehl auszuführen?


Version2:

- Azure AD Sync konfigurieren
- KEIN lokalen Exchange installieren (somit keine Exchange Attribute im lokalen AD vorhanden)
- Über die Software alle Konten migrieren (Postfächer werden automatisch von der Software angelegt in dem die Lizenz in Exchange Online zugewiesen wird)
- Exchange im lokalen AD installieren
- Hybrid Konstellation einrichten

Müssen dann die MailboxGuid Einträge von der Cloud über Powershell den lokalen AD Konten zugeordnet werden?


Version3:

- Mailboxen über Tool nach M365 migrieren (Konten werden komplett von dem Tool angelegt und lizenziert)
- Azure AD Sync Matching mit dem Tenant durchführen
- Hybridverwaltung konfigurieren



Version 4 ähnelt Version 2:

- Lokalen Exchange installieren
- Azure AD Sync konfigurieren (MailboxGUID Attribut entfernen) somit kann das Tool Online ein Postfach anlegen
- Hybrid Konfiguration
- Migration durch das Tool (Postfächer werden erstellt)
- Attribut wieder in den Sync mit aufnehmen
- Alle weiteren Postfächer werden über den lokalen Exchange über "new-remotemailbox angelegt"




Frage:

1.) Was passiert, wenn ich nachträglich den ADSync so anpasse, dass das MailboxGuid Attribut wieder synchronisiert wird?

Ändert es hier was an den bereits synchronisierten Konten oder nur bei den neuen?

2.) Um über den lokalen Exchange die bestehenden Cloud Postfächer zu managen, muss ich dem lokalen Exchange Server auf irgendeinen Weg sagen, dass es sich um ein Cloud Postfach handelt und dieser AD Benutzer ein Postfach in der Cloud besitzt.

Bedeutet, auch wenn ich das Attribut für die Migration deaktiviere, weiß der lokale Exchange nicht, dass es ein Postfach für die Benutzer in der Cloud gibt und somit kann ich diese nicht verwalten, richtig?

Somit muss ich also auch hier im Nachgang dem lokalen AD Konto per "Enable-RemoteMailbox" die Cloud Mailbox bekannt machen, damit diese verwaltet werden kann, richtig=?



Eventuell ist ja bereits jemand über eine ähnliche Anforderung gestolpert und konnte Erfahrungen sammeln face-smile .


Danke euch im Voraus.

Grüße
Phil

Content-Key: 605038

Url: https://administrator.de/contentid/605038

Printed on: April 26, 2024 at 04:04 o'clock

Member: 7Gizmo7
7Gizmo7 Sep 16, 2020 at 17:16:13 (UTC)
Goto Top
Hi,

ich versuche es mal auseinander zu Klammüsern


Zitat von @Gerber:
Version 1:

- Exchange Server wird im lokalen AD (komplett neu angelegt) installiert.
- Azure AD Sync + Hybridkonfiguration wird durchgeführt
- Alle 120 Postfächer werden als New-RemoteMailbox über den lokalen Exchange in M365 angelegt, damit die lokalen AD Attribute korrekt befüllt werden
- Danach werden die Konten über das Tool vom Drittanbieter gematched und befüllt

Nachteil:

Hier kommt ein erheblicher Aufwand für das erstellen der Remote-Mailboxen über den lokalen Exchange zusammen.

Gibt es hier ein Script um für alle AD Benutzer ein Remotemailbox Postfach anzulegen ohne für jeden Benutzer einzeln ein Befehl auszuführen?


New-Remotemailbox mit einer CSV ?



Version2:

- Azure AD Sync konfigurieren
- KEIN lokalen Exchange installieren (somit keine Exchange Attribute im lokalen AD vorhanden)
- Über die Software alle Konten migrieren (Postfächer werden automatisch von der Software angelegt in dem die Lizenz in Exchange Online zugewiesen wird)
- Exchange im lokalen AD installieren
- Hybrid Konstellation einrichten

Müssen dann die MailboxGuid Einträge von der Cloud über Powershell den lokalen AD Konten zugeordnet werden?

Das wäre das klassische Offboarding, du musst nur Exchange Zurückschreiben in AADConnect konfigurieren,



Version3:

- Mailboxen über Tool nach M365 migrieren (Konten werden komplett von dem Tool angelegt und lizenziert)
- Azure AD Sync Matching mit dem Tenant durchführen
- Hybridverwaltung konfigurieren



Version 4 ähnelt Version 2:

- Lokalen Exchange installieren
- Azure AD Sync konfigurieren (MailboxGUID Attribut entfernen) somit kann das Tool Online ein Postfach anlegen
- Hybrid Konfiguration
- Migration durch das Tool (Postfächer werden erstellt)
- Attribut wieder in den Sync mit aufnehmen
- Alle weiteren Postfächer werden über den lokalen Exchange über "new-remotemailbox angelegt"




Frage:

1.) Was passiert, wenn ich nachträglich den ADSync so anpasse, dass das MailboxGuid Attribut wieder synchronisiert wird?

Ändert es hier was an den bereits synchronisierten Konten oder nur bei den neuen?

2.) Um über den lokalen Exchange die bestehenden Cloud Postfächer zu managen, muss ich dem lokalen Exchange Server auf irgendeinen Weg sagen, dass es sich um ein Cloud Postfach handelt und dieser AD Benutzer ein Postfach in der Cloud besitzt.

Über den Sync von AADConnect


Bedeutet, auch wenn ich das Attribut für die Migration deaktiviere, weiß der lokale Exchange nicht, dass es ein Postfach für die Benutzer in der Cloud gibt und somit kann ich diese nicht verwalten, richtig?

Somit muss ich also auch hier im Nachgang dem lokalen AD Konto per "Enable-RemoteMailbox" die Cloud Mailbox bekannt machen, damit diese verwaltet werden kann, richtig=?



Eventuell ist ja bereits jemand über eine ähnliche Anforderung gestolpert und konnte Erfahrungen sammeln face-smile .


Danke euch im Voraus.

Grüße
Phil

Wenn Version 1 geht, würde ich das machen ...
Member: Gerber
Gerber Sep 17, 2020 updated at 06:45:50 (UTC)
Goto Top
@7Gizmo7 :

Danke dir für deine Antworten.

New-Remotemailbox mit einer CSV ?

Wenn das funktioniert, werde ich mir den Weg auf alle Fälle mal genauer anschauen.

Das wäre das klassische Offboarding, du musst nur Exchange Zurückschreiben in AADConnect konfigurieren

Naja in diesem Fall wird aber die ExchangeGUID von Exchange Online nicht ins lokale AD geschrieben.

Hier die Werte, welche zurückgeschrieben werden:

https://docs.microsoft.com/de-de/azure/active-directory/hybrid/reference ...


Über den Sync von AADConnect

Dies ist mir bewusst, dass der AADConnect dies steuert.
Angenommen ich habe nun aber über den AADSync Benutzer aus dem lokalen AD in Azure AD gesynct. Danach weiße ich diesen Usern eine Lizenz zu und somit wird ein Postfach in EO erstellt.

Eigentlich müsste ich doch noch zusätzlich ein "Enable-RemoteMailbox" auf den lokalen AD Benutzer durchführen, damit der lokale Exchange mitbekommt, dass ein EO Postfach für diesen Benutzer existiert und ich dieses dann verwalten kann?


Weitere Fragen:

1. Kann ich auch ein Enable Remote Mailbox über eine CSV steuern?

2. kann Enable-Remotemailbox ausgeführt werden, wenn der Benutzer bereits ein lokales Exchange Postfach besitzt oder muss dies zunächst entfernt werden?

Danke im Voraus.

Grüße
Phil
Member: 7Gizmo7
7Gizmo7 Sep 18, 2020 at 07:39:08 (UTC)
Goto Top
Zitat von @Gerber:


Naja in diesem Fall wird aber die ExchangeGUID von Exchange Online nicht ins lokale AD geschrieben.

dann kannst du Enable- Remotemailbox machen


Über den Sync von AADConnect

Dies ist mir bewusst, dass der AADConnect dies steuert.
Angenommen ich habe nun aber über den AADSync Benutzer aus dem lokalen AD in Azure AD gesynct. Danach weiße ich diesen Usern eine Lizenz zu und somit wird ein Postfach in EO erstellt.

Eigentlich müsste ich doch noch zusätzlich ein "Enable-RemoteMailbox" auf den lokalen AD Benutzer durchführen, damit der lokale Exchange mitbekommt, dass ein EO Postfach für diesen Benutzer existiert und ich dieses dann verwalten kann?
JA


Weitere Fragen:

1. Kann ich auch ein Enable Remote Mailbox über eine CSV steuern?

2. kann Enable-Remotemailbox ausgeführt werden, wenn der Benutzer bereits ein lokales Exchange Postfach besitzt oder muss dies zunächst entfernt werden?

Zunächst entfernt werden

https://www.msxfaq.de/cloud/exchangeonline/exo_und_mailboxguid.htm
https://www.msxfaq.de/cloud/identity/doppelpostfach_mit_exo.htm
Member: Gerber
Gerber Oct 05, 2020 at 08:59:07 (UTC)
Goto Top
Danke dir für die Antwort und die verspätete Antwort.

dann kannst du Enable- Remotemailbox machen

Durch diesen Befehl wird allerdings der lokale AD Benutzer nur Mail enabled gemacht und nicht die Mailbox Guid von EXO in das lokale AD geschrieben.

Dies wird auch nicht durch den Hybrid Wizzard zurückgeschrieben. Es muss händisch erledigt werden.


Zunächst entfernt werden

Alles klar.

Ich muss mir nochmals genau Gedanken machen mit welchem Weg ich nun tatsächlich am wenigsten Aufwand habe.

Grüße
Phil