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

5Feb/170

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…

9Aug/160

Office 365 und Exchange Server – nützliche PowerShell-Schnipsel

Im folgenden möchte ich euch einige Code-Schnipsel für die PowerShell zur Verfügung stellen, die das Arbeiten mit Office 365 bzw. einem Exchange Server mittels PowerShell erleichtern sollen. Dabei ist immer kurz angegeben, was der Code macht.

Der Artikel wird regelmäßig ergänzt und erweitert.

Allgemein

Verbinden der PowerShell mit Office 365:

1
2
3
4
Import-Module "PFAD-ZUR-EXCHANGE-PSM-DATEI.psm1" 
$credential = Get-Credential -UserName "USER@DOMÄNE.DE" -Message "Bitte das Passwort für O365 eingeben!" 
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $credential -Authentication Basic -AllowRedirection 
Import-PSSession $ExchangeSession -AllowClobber >> $null

Verteiler / Distribution Groups

Auflisten aller Verteiler:

1
Get-DistributionGroup

Mitglieder (Postfächer) eines bestimmten oder mehrerer Verteiler(s) auflisten:

1
2
3
4
$Mailbox = Get-Mailbox "Haiko Hertes" 
$DN=$Mailbox.DistinguishedName 
$Filter = "Members -like ""$DN&""" 
Get-DistributionGroup -ResultSize Unlimited -Filter $Filter

Mitglieder (Kontakte) eines bestimmten oder mehrerer Verteiler(s) auflisten:

1
2
3
4
$Mailbox = Get-MailContact "*KONTAKTNAME*" 
$DN=$Mailbox.DistinguishedName 
$Filter = "Members -like ""$DN""" 
Get-DistributionGroup -ResultSize Unlimited -Filter $Filter
30Jun/160

Exchange 2010: Viele merkwürdige Fehler und eine fast noch merkwürdigere Lösung

Auf einem produktiven Exchange 2010 SP3 mit aktuellem Patchstand begegnete mir heute folgendes Problem: Der Mailserver war weder über Outlook noch über OWA erreichbar und wenn man sich per RDP angemeldet hat, dann war nahezu nichts möglich, jede Aktion führte zu einem sich ewig drehenden Sanduhr-Symbol. Keines der Systemsteuerungswerkzeuge oder auch nur die Netzwerkwerk-Adapter-Verwaltung ließen sich öffnen.

Um zunächst erst mal mit dem Server arbeiten zu können, hatte ich ihn im abgesicherten Modus gestartet. Da hier aber auch sehr viele Werkzeuge nicht funktionieren, habe ich alle Exchange-Dienste deaktiviert und die Maschine neugestartet. Jetzt konnte man erst mal wieder arbeiten und mit der Fehlersuche beginnen.

Zunächst hatte ich mit ESEUTIL die Datenbank-Files geprüft, hier war aber alles in Ordnung. Netzwerk, DNS und co. sowieso, DC war auch erreichbar, auch Kerberos-Auflösungen waren kein Problem. Da ich am Vorabend das aktuellste Update Rollup 14 eingespielt hatte, hatte ich dieses im Verdacht und hab es wieder deinstalliert – ohne Erfolg. Der Server reagierte wieder so wie vorher.

Im Eventlog war mir vor allem dieser Fehler aufgefallen:

Exch2010_1

(Quelle: MSExchange ADAccess | Ereignis-ID: 2114 | Aufgabenkategorie Topologie)

Außerdem noch dieser Fehler:

Exch2010_2n

(Quelle: MSExchange ADAccess | Ereignis-ID: 2102 | Aufgabenkategorie Topologie)

Dort heisst es: “Keine Antwort von allen verwendeten Domänencontrollerservern”. Dies war merkwürdig, weil sämtliche Arten der von mir getesteten Kommunikation mit dem DC funktionierten tadellos, zur Sicherheit hatte ich noch ein dcdiag gegen den DC laufen lassen – ohne Auffälligkeiten. Zur Sicherheit hatte ich noch das Computerkonto sowie den Secure Channel zurückgesetzt die Mitgliedschaft des Computerkontos in den notwendigen Exchange-Gruppen im AD geprüft.

Symptomatisch war, dass sich der Dienst “Microsoft Exchange Active Directory-Topologie” und auch “Microsoft Exchange-Diensthost” relativ problemlos (wenn auch nur mit längerer Wartezeit) starten ließen, aber die “Microsoft Exchange-Systemaufsicht” ließ sich nicht starten!

Nach etwas Suche im Internet fand ich diverse Hinweise. Der erwarte war das Thema IPv6 – tatsächlich hatte mein Vorgänger dies am Exchange Server abgeschaltet. Also das Häckchen wieder rein:

Exch2010_3

Leider brachte dies – auch nach einem Neustart nichts.

Ein weiterer Hinweis der sich fand, schien mir etwas abwegig, aber da ich kurz vor dem Restore des gesamten Servers stand, habe ich es drauf ankommen lassen und das Computerkonto des Exchange-Servers in die Gruppe der Domänen-Admins aufgenommen. Und tatsächlich, nach einem Neustart des Servers kamen alle Dienste hoch. Damit war mein Kernproblem zwar gelöst, aber ich war mir sicher, die eigentliche Ursache nicht gefunden zu haben, denn es ist IMHO keine Bedingung für Exchange, dass der Server DomAdmin ist. Nach längeren Recherchen fand ich dann den “Übeltäter”:

Eine GPO hatte die Berechtigung für “Manage auditing and security log” (“Verwalten von Überwachungs- und Sicherheitsprotokollen”) auf einen zu kleinen Benutzerkreis festgelegt.

Exch2010_4

Laut diesem Artikel muss hier auch die Gruppe der Exchange-Server mit eingetragen werden – und zwar für die GPO die auf die DCs zielt!

Das war also das recht kleine Problem mit riesiger Auswirkung!

Jeden Tag fiebere ich nun der endgültigen Umstellung auf Office 365 entgegen – dann gehören derartige Probleme wohl der Vergangenheit an.

11Jun/150

SCDPM meldet “Replikat inkonsistent” wenn man einen Exchange 2013 Server sichert

Beim Versuch die Mailbox-Datenbank(en) eines Exchange 2013 Server zu sichern, kann es vorkommen, dass der System Center Data Protection Manager 2012 R2 meldet:

“Replikat inkonsistent” bzw. “Replica is inconsistent”

Das schaut dann in etwa so aus:

exch_dpm_1

Was kann man nun also dagegen tun?

Zunächst einmal muss sichergestellt sein, dass die Dateien “ese.dll” und “eseutil.exe” vom Exchange Server auf den DPM Server kopiert wurden – und zwar immer in der auf dem Exchange aktuell verwendeten Version – also nach größeren Updates neu kopieren!

Die Dateien befinden sich im Exchange-Verzeichnis unter “Bin”, also z.B. unter “D:\Program files\Microsoft\Exchange Server\V15\Bin” und müssen in den Bin-Pfad vom DPM, also z.B. nach “D:\Program files\Microsoft System Center 2012 R2\DPM\DPM\bin” kopiert werden.

Nach Updates sollte unbedingt die Version bzw. das Dateidatum kontrolliert werden!

exch_dpm_0

Weiterhin muss eine aktuelle Version des “Visual C++ Redistributable for 2012” auf dem Exchange Server installiert sein! Dieses lässt sich z.B. hier herunterladen: https://www.microsoft.com/de-de/download/details.aspx?id=30679 

Zur Sicherheit lässt sich auch eine Reparatur-Installation ausführen. Anschließend ist ein Reboot nötig.

exch_dpm_3 exch_dpm_4

Wenn diese Voraussetzungen geschaffen worden, dann kann entweder nur eine Konsistenzprüfung durchgeführt oder direkt die Sicherung fortgesetzt werden (was dann auch zunächst zu einer Konsistenzprüfung führt).

exch_dpm_5

exch_dpm_6

Wenn diese Abgeschlossen ist (was eine Weile dauern kann), sollte die Schutzgruppe wieder den Zustand “OK” (grün) annehmen.

18Mrz/140

Exchange 2007 lässt sich nicht via Windows Server Sicherung sichern

Hinweis: Bei meinen Recherchen zu dem Thema habe ich festgestellt, dass dieses Problem scheinbar auch bei Exchange 2010 auftritt!

Bei einem Exchange Server 2007 mit LCR trat seit längerem das Problem auf, dass sich dieser nicht sauber (auf Anwendungsebene) sichern ließ. Die Windows Server Sicherung meldete immer

“Abgeschlossen mit Warnungen – Die Anwendung kann aus dieser Sicherung nicht wiederhergestellt werden […]”

exchbkp0

Kurz nach Start der Sicherung findet sich im Ereignisprotokoll folgender Eintrag:

exchbkp2

Anwendungsprotokoll / Ereignis 565 / Quelle Backup / “Fehler bei der Konsistenzprüfung für die Komponente […]”

Eine Überprüfung der Postfachdatenbank sowie der Datenbank für die öffentlichen Ordner und aller Logs mit Hilfe von ESEUtil brachte keinerlei Fehler oder sonstige Probleme.

Als Lösung des Problemes habe ich den Exchange VSS-Writer per Registry deaktiviert.

Dazu ist unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters ein neuer DWORD-Schlüssel anzulegen, der den Namen “EnableVSSWriter” und den Wert 0 bekommt.

exchbkp3

Danach funktioniert das nächtliche Backup wieder ohne Probleme:

exchbkp4

21Nov/119

Exchange Server aus Domäne entfernen – auf die harte Tour

Offiziell wird von MS das Entfernen eines Exchange-Servers nur durch dessen Deinstallation unterstützt.

Ein mögliches Szenario, in dem die händische Entfernung dennoch notwendig sein kann, ist aber recht schnell umschrieben: Beim Update bzw. einer Versions-Migration ist etwas schief gegangen und die Exchange-Installation eines Exchange-Servers ist defekt. In der Exchange-Verwaltungskonsole der anderen Server taucht er aber weiterhin auf und ist Bestandteil des ActiveDirectoy - das kann zu Problemen führen. Hier hilft es auch nichts, den Server aus der Domäne zu entfernen oder gar sein Computerkonto zu löschen.

Eine weitere Möglichkeit wäre, dass einer der Mailserver (z.B. physikalisch) defekt ist, und smit nicht mehr sauber deinstalliert werden kann.

Also muss eine Lösung her. Die (in meinen Augen) einfachste ist die Verwendung des ADSI-Editors. Dazu startet man eine mmc (Start -> Ausführen -> mmc) und fügt das Snap-In für den ADSI-Editor hinzu (Datei -> Snap-In hinzufügen / entfernen).  Dort muss man mit einem Rechtsklick auf "ADSI-Editor" eine Verbindung zu dem entsprechenden Domänencontroller herstellen und als Namenskontext "Konfiguration" auswählen.

Hier muss man nur zu folgendem Zweig navigieren:

  • CN=Configuration,DC=DOMAIN,DC=NAME
    • CN=Services
      • CN=Microsoft Exchange
        • CN=NAME
          • CN=Exchange Administrative  Group
            • CN=Servers

Dort sind nun alle Exchange-Server, die im AD bekannt sind, aufgelistet. Derjenige, der entfernt werden soll, kann hier einfach entfernt werden und taucht dann z.B. in der Exchange Verwaltungskonsole nicht mehr auf.