Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

5Feb/173

Office 365: Letzten Exchange-Server entfernen

Nach einer Migration zu Office 365 kann es sinnvoll bzw. gewünscht sein, alle on-premise Exchange-Server zu deinstallieren. Microsoft selbst beschreibt dies z.B. in der Schritt-für-Schritt-Anleitung für eine Cutover-Migration (Übernahmemigration):

Außerbetriebnahme der lokalen Exchange Server.    Nachdem Sie sich vergewissert haben, dass alle E-Mails direkt an die Office 365-Postfächer weitergeleitet werden, und wenn Sie Ihre lokale E-Mail-Organisation nicht mehr benötigen oder nicht planen, eine Lösung für einmaliges Anmelden zu implementieren, können Sie Exchange auf Ihren Servern deinstallieren und Ihre lokale Exchange-Organisation entfernen.

(https://support.office.com/de-de/article/Durchf%C3%BChren-einer-%C3%9Cbernahmemigration-von-E-Mails-zu-Office-365-9496e93c-1e59-41a8-9bb3-6e8df0cd81b4?ui=de-DE&rs=de-DE&ad=DE#postmigration)

Im Nachsatz dazu heisst es dann interessanterweise:

HINWEIS : Eine Außerbetriebnahme von Exchange kann unerwartete Folgen haben. Vor der Außerbetriebnahme Ihrer lokalen Exchange-Organisation sollten Sie Kontakt mit dem Microsoft-Support aufnehmen.

Ich für meinen Teil wollte in erster Linie den Alten Exchange 2010 loswerden. Vermutlich werde ich später einen neuen Exchange 2016 installieren…

ACHTUNG: Wenn DirSync bzw. Azure AD verwendet werden, dann können AD-Attribute nur on-premise und nicht in Azure geändert werden. Wenn Exchange entfernt wird, können einige Mail-relevante Attribute nicht mehr geändert werden. Einige Attribute könnten zwar über ADSIEdit geändert werden, das wird aber offiziell nicht unterstützt!

Aber reden wir weniger über das WARUM als viel mehr über das WIE…

Wenn man sich nun also entschieden hat, den (letzten) Exchange-Server los zu werden und die Deinstallation gestartet hat, wird man relativ schnell feststellen, dass es nicht ganz so einfach ist! Die Deinstallation stört sich nämlich daran, dass es noch Postfächer gibt:

Exch1

Nun könnte man natürlich einfach alle Mailboxen löschen (bzw. deaktivieren – löscht man eine Mailbox, löscht man den dahinterstehenden AD Benutzer, also keine gute Idee), aber: Nach dem Deaktivieren der Mailbox hat der entsprechende AD-Benutzer keine E-Mail-Adresse mehr (und er verliert auch auf anderen Attributen die Werte), was durchaus ein Problem für DirSync bzw. eine Synchronisation zu Azure AD sein kann. Was ist nun also der richtige Weg?

Im wesentlichen sind zwei Schritte notwendig:

  1. Mailbox deaktivieren
  2. Benutzer in einen so genannten “Mail-Enabled-User” umwandeln

Die Schwierigkeit dabei besteht darin, dass die E-Mailadresse “zwischengespeichert” werden muss, damit diese dem Mail-Enabled-User zugewiesen werden kann (oder man hat eine Syntax, nach der sich ALLE E-Mail-Adressen bilden lassen, da könnte man das weglassen)

Das Ganze habe ich natürlich mit PowerShell gelöst. Das folgende Skript soll ein Anhalt sein, passt es bitte an eure Gegebenheiten an!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
Import-Module ActiveDirectory
 
$mbxs = Get-Mailbox # This will disable ALL mailboxes! Pay attention...
 
foreach ($mbx in $mbxs) 
{
    $adusr = Get-ADUser $mbx.SamAccountName -Properties mail,mailNickname,msExchShadowProxyAddresses,proxyAddresses,UserPrincipalName
 
    # Getting Mailboxes mail adress befor disabling it
    If($adusr.Mail -eq "")
    {
        [string]$MailAdress = $mbx.UserPrincipalName
    }
    else
    {
        [string]$MailAdress = $adusr.Mail
    }
 
    Disable-Mailbox -Id $mbx.Identity -Confirm:$False
    Enable-MailUser -Id $mbx.Identity -ExternalEmailAddress $MailAdress
    Set-MailUser -Id $mbx.Identity -EmailAddresses $MailAdress
}
 
# Make users MailEnabled users that never had a mailbox
 
$newUsersWithoutMailbox = Get-ADUser -Filter * -SearchBase "OU=TempOuForNewEmps,OU=internal_users,OU=users,OU=API-Leipzig,DC=API-Leipzig,DC=local" -Properties Mail,UserPrincipalName
foreach($user in $newUsersWithoutMailbox)
{
    $FullDistinguishName = “LDAP://+ $user.distinguishedName
    $AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName
    $AccountEntry.PutEx(1, “msExchHomeServerName”, $null)
    $AccountEntry.SetInfo()
 
    If($user.Mail -ne "")
    {
        [string]$MailAdress = $user.Mail
    }
    else
    {
        [string]$MailAdress = $user.UserPrincipalName
    }
    # Enable-MailUser 
 
    If((Get-MailUser $user.SamAccountName -ErrorAction SilentlyContinue).RecipientType -ne "MailUser")
    {
        Enable-MailUser -Id $user.SamAccountName -ExternalEmailAddress $MailAdress
    }
 
    Set-MailUser -Id $user.SamAccountName -EmailAddresses $MailAdress
}

 

Nach dem nun keine Mailboxen mehr vorhanden sind, wäre es möglich, dass der Deinstallationsassistent weitere Probleme meldet, u.a. könnten:

  • noch Public Folder Databases mit Replikaten,
  • Arbitration-Mailboxes oder
  • weitere Inhalte in der Mailbox Database

vorhanden sein.

Für die Replicas in der Public Folder Database bzw. die Database selbst könnten folgende PowerShell-Aufrufe nützlich sein:

1
2
3
4
5
Get-PublicFolder -Identity \ -GetChildren | Remove-PublicFolder -Recurse 
 
Remove-PublicFolderDatabase -Identity "My Public Folder Database" 
 
Get-PublicFolderDatabase | Remove-PublicFolderDatabase –RemoveLastAllowed

 

Für das Entfernen der (ggf. letzten) Arbitration Mailbox hilft

1
Get-Mailbox –Arbitration | Disable-Mailbox –Arbitration –DisableLastArbitrationMailboxAllowed

Danach sollte es möglich sein, Exchange “normal” zu entfernen:

Exch4

13Okt/160

Hürden bei der Office 365 Migration in Bezug auf AD Connect

Vor zwei Wochen habe ich nun endlich die E-Mail-Kommunikation meiner Firma auf Office 365 umstellen können. Diese eigentlich gar nicht so aufwändige Projekt war leider durch zu viele kleine Dinge im Alltag zeitlich in die Länge gezogen worden.

Aus den Erfahrungen bei der Migration möchte ich hier ein paar Hürden und Stolpersteine, die mir im Zusammenhang mit Azure AD Connect begegnet sind, erläutern, in der Hoffnung, dass andere diese so umgehen können.

Azure AD Connect zu früh benutzt I

Ich hatte Azure AD Connect bereits aktiviert, bevor ich den Migrationsendpunkt (Migration Endpoint) für die Cutover-Migration angelegt hatte. Danach ließ sich die Option “Übernahmemigration” (Das ist die Cutover-Migration) nicht mehr auswählen, diese war ausgegraut (siehe mein Blogpost vom 12.09.2016)

Erkenntnis: Azure AD Connect erst benutzen, wenn der Migrationsendpunkt angelegt ist. (siehe auch nächster Punkt!) Alternativ kann AD Connect auch wieder abgeschaltet werden: (kann ggf. einige Stunden dauern)

image

Azure AD Connect zu früh benutzt II

Ich hatte, bevor alle Postfächer durch Cutover-Migration umgezogen waren, schon Azure AD Connect (früher DirSync) auf unseren Systemen installiert und einige Benutzer aus unserem Active Directory zu Azure bzw. Office 365 synchronisiert. Für diese Benutzer konnte ich dann keine Postfächer mehr per CutOver-Migration migrieren, weil dann bemängelt wird, dass es bereits Objekte mit der selben Mailadresse gibt.

Erkenntnis: Azure AD Connect erst benutzen, wenn alle Postfächer migriert sind.

Azure AD Connect kommt mit multiplen Mail-Adressen im AD nicht so gut klar

Neben der finalen Mailadresse unserer Public Domain hatten die Exchange-Postfächer (und damit auch die AD Objekte der Benutzer) mehrere Mailadresse, u.a. die der lokalen internen AD Domäne. Diese sind u.a. im Attribut “ProxyAddresses” gespeichert. Die primäre Mailadresse hat dabei ein großgeschriebenes “SMTP:” vorangestellt, alle anderen ein kleingeschriebenes:

image

Daran aber stört sich anscheinend Azure AD Connect. Darauf deutet auch ein älterer Blog-Artikel bei Microsoft hin. Dort heisst es:

  • “SMTP:username@contoso.com” is an acceptable value.
  • username@contoso.com” and “smtp:username@contoso.com” are not acceptable values.

Als Fehler kommt “Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet sind” – und zwar für jeden User der Domäne.

Also habe ich vorübergehend alle kleingeschriebenen “smtp” durch großgeschriebene ersetzt (ACHTUNG: Das ist nur temporär, in der Zwischenzeit solltet ihr keine Exchange-Konsolen benutzen, da diese damit ein Problem haben, dass es mehrere primäre Adressen gibt! Alternativ könnte man auch alle sekundären Adressen entfernen – das kam für mich aber nicht in Betracht). Dies habe ich natürlich mit PowerShell erledigt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Get-ADUser -SearchBase "OU=SOMEOU,DC=MYDOMAIN,DC=local" -Filter * | 
    Get-ADObject -Properties proxyAddresses | 
        ForEach-Object 
        {
 
            $ProxyA = $_.proxyAddresses.Replace("smtp","SMTP") 
            ForEach($Adress in $_.proxyAddresses) 
            { 
                if($Adress -like "*@THEDOMAIN.COM") 
                { 
                   $ProxyA = $Adress 
                } 
            } 
            $_.ProxyAddresses = $ProxyA 
            Set-ADObject -Instance $_ 
        }

Selbst nach dem ich dies bei allen Benutzer gemacht hatte kam ausgerechnet für mein eigenes Konto noch immer der selbe Fehler:

image

Dabei hatte ich meinen Account ebenso behandelt wie alle anderen. Dieses Mal war die Ursache aber eine andere: Es gab noch einen gelöschten O365-Benutzer mit dieser Adresse! Also musst auch noch der gelöschte Benutzer endgültig gelöscht werden. Dies habe ich ebenfalls per PowerShell gelöst:

1
Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force

(Achtung: Das löscht ALLE gelöschten Benutzer endgültig! Will man nur einen einzelnen Benuter löschen geht dies mittels:

1
Remove-MsolUser -UserPrincipalName Lynn@office365bootcamp.com –RemoveFromRecycleBin


Danach klappte auch die Synchronisierung des letzten Kontos problemlos…

12Sep/160

Office 365–Einige Hinweise zur Cut-Over Migration

Die “Übernahmemigration” (Englisch: Cutover-Migration) ist eine nette Option, um alle Postfächer eines Exchange-Servers in einem Rutsch nach Office 365 zu migrieren. Allerdings gibt es ein paar Dinge zu beachten. Und manches erfährt man nur durch Ausprobieren, auch das möchte ich euch hier nicht vorenthalten…

o365_1

Zu beachten:

  • Die Option “Übernahmemigration” bzw. “Cutover Migration” ist ausgegraut, wenn “Azure DirSync” bzw. “Azure AD Connect” aktiv sind. Am einfachsten ist es, dies im Azure-Portal abzuschalten. Erst danach steht die Option zur Verfügung.
  • Konten, die bereits per Azure AD Connect oder Vorgänger-Techniken nach Azure bzw. Office 365 synchronisiert wurden, können nicht durch die Übernahmemigration “befüllt” werden. Diese Konten müssen gelöscht und neu angelegt werden.

Allgemein hin liest man immer wieder, das man mit der Cutover-Migration nur ALLE Postfächer auf einmal (bzw. nacheinander, aber in einem Rutsch) migrieren kann. Das ist so nicht ganz richtig… Insbesondere für Tests vor der eigenen Migration ist es sinnvoll, nur ein paar wenige (Test)Postfächer zu migrieren. Jedoch hat man bei dem Assistenten keine Möglichkeit zur Auswahl. Der Trick ist, die Postfächer vor Office 365 zu “verstecken”. Office 365 liest nämlich einfach nur die Global Address List (GAL, Globales Adressbuch) aus. Wenn dort nun nur die Postfächer drin stehen, die migriert werden sollen, dann wird der Rest einfach ignoriert.

Um jetzt ein Postfach aus der GAL zu entfernen, gibt es zwei Wege:

    1. Das Postfach öffnen und den entsprechenden Haken setzen:o365_2
    2. Die Änderungen (vor allem bei vielen Postfächern) durch PowerShell erledigen lassen:
1
2
Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $true 
Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $true

Mit der PowerShell-Variante werden ALLE Postfächer und Verteiler aus dem Adressbuch entfernt. Danach können die gewünschten Postfächer wieder händisch hinzugefügt werden. Nach der (Test)Migration sollte man dann nicht vergessen, die Postfächer wieder im Adressbuch sichtbar zu machen:

 

1
2
Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $false 
Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $false

 

o365_3

Auf dem Bild ist zu sehen, dass nur 2 (von insgesamt deutlich mehr) Postfächern synchronisiert wurden!

 

Wichtig ist noch, dass Benutzer, die bereits in Office 365 von Hand angelegt wurden (! – wichtig, das geht nicht bei synchronisierten Benutzern – !), nicht gelöscht werden müssen! Die Cutover-Migration kann diese einfach mit dem passenden Postfach vom Exchange-Server verbinden und auffüllen. Wichtig ist dazu nur, dass der O365-Account als primäre Mailadresse die selber hat wie auf dem Exchange-Server und eben noch keine AD-Attribute synchronisiert wurden.