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

28Jun/170

Office 365 – E-Mail-Adresse enthält einen Unterstrich (“_”)

Heute bin ich über folgendes Problem gestolpert: Bei einem neuen Mitarbeiter enthielt die E-Mail-Adresse im Office 365 einen Unterstrich (“Underscore”) an erster Stelle:

underscore1

(Zusätzlich wurde nicht die reguläre Domäne sondern eine “@*.onmicrosoft.com” verwendet…)

Die Benutzer werden mittels “Azure AD Connect” vom lokalen Active Directory nach Azure AD synchronisiert und bilden dort die Grundlage für die Office 365 Benutzer. Daher kann man die E-Mail-Adressen auch nicht online ändern, sondern nur on-premise. Im lokalen AD war aber auf den ersten Blick alles in Ordnung:

underscore2

Nach kurzer Recherche fand ich einen Microsoft KB Artikel, der mich auf die Lösung brachte:

In this scenario, after directory synchronization is run, the special character is replaced by an underscore character. Therefore, the user’s Office 365 email address contains an underscore character instead of the special character.

Dabei wird eine Liste mit “verbotenen” Zeichen aufgeführt (die merkwürdigerweise auch das @-Zeichen enthält…), zu denen auch das Leerzeichen gehört. Bezogen ist das ganze auf die AD-Attribute “mail” und “proxyAddresses”. “Mail” war in Ordnung, aber “proxyAddresses”…

underscore3

…nicht! Hier war ein Leerzeichen zwischen “SMTP:” und der eigentlichen E-Mailadresse. Nach dem ich dieses entfernt hatte und schnell noch den DirSync mit

Start-ADSyncSyncCycle -PolicyType Delta

angestoßen hatte, war der Benutzer mit seiner korrekten E-Mail-Adresse in Office 365 vorhanden!

26Apr/172

Office 365 – E-Mail-Adressen von neuen Benutzern aus on-premise AD falsch

Wenn man mit Azure AD Sync arbeitet und einen neuen Mitarbeiter im lokalen on-premise Active Directory anlegt, dann kann es einem passieren, dass dieser im Office 365 Portal eine *.onmicrosoft.com E-Mail-Adresse als primäre Mailadresse bekommt, selbst wenn man im AD-Konto die richtige Adresse eingetragen hat:

o365_1

Das lässt sich über das Office 365 Admin-Portal auch nicht ändern, da der Benutzer eben aus dem lokalen AD synchronisiert wird:

o365_2

Der Trick besteht darin, im lokalen AD das Attribute “proxyAddresses” zu erweitern (entweder ist es leer oder es enthält bereits einen Eintrag “x500:/o=…”).

Der neue Eintrag muss mit “SMTP:” (Großbuchstaben und den Doppelpunkt nicht vergessen) gefolgt von der gewünschten E-Mail-Adresse (ohne Leerzeichen) bestehen:

o365_4

Nach der nächsten Synchronisierung sollte es dann auch in Office 365 passen! Viel Spaß damit…

 

Nachtrag: In meinem Fall existiert kein on-premise Exchange Server! Wenn ihr einen solchen doch habt, dann verändert ihr mit der Änderung des AD-Attributes natürlich auch dort die Mailadresse...

13Mrz/170

Windows Server Usergroup Leipzig–Übersicht über die bisherigen Treffen und Recordings

Auf den bisher drei Treffen der in 2016 neu gegründeten Windows Server Usergroup Leipzig (WSUG L.E. – organisiert über Meetup unter meetup.com/de-DE/wsugle/) haben bereits diverse Leute Vorträge gehalten, darunter auch einige MVPs.

Hier möchte ich eine kurze Übersicht der Video geben, die ihr dann ganz bequem von zuhause anschauen könnt. Die Qualität der Videos variiert leider recht stark – seid also bitte nicht gleich abgeschreckt, wenn das erste Video das ihr euch zum Anschauen ausgewählt habt nicht so toll ist. Danke!

11.08.2016 – 1. Treffen – Begrüßung & Einleitung (Haiko Hertes) Link
11.08.2016 – 1. Treffen – Windows Server 2016 (Eric Berg) Link
11.08.2016 – 1. Treffen – Storage Spaces Direct S2D (Florian Klaffenbach) Link
03.11.2016 – 2. Treffen – Begrüßung & Einleitung (Haiko Hertes) Link
03.11.2016 – 2. Treffen – Windows PowerShell DSC (Haiko Hertes) Link
02.03.2017 – 3. Treffen – Begrüßung & Einleitung (Haiko Hertes) Link
02.03.2017 – 3. Treffen – Active Directory Security (Jan-Henrik Damaschke) Link
02.03.2017 – 3. Treffen – Übersicht System Center (Haiko Hertes) Link
02.03.2017 – 3. Treffen – Übersicht Altaro Hyper-V Backup (Haiko Hertes) Link

 

Diese und auch alle folgenden Videos werdet ihr auch über diese YouTube-Playlist finden:

https://www.youtube.com/playlist?list=PLPK8RW8p4Ok8-2qVVi0AHdoKuC448OEcM

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

12Jan/170

Passwort Self-Service für Office 365 und Azure AD – nur mit Premium-Lizenz

Nur als kurze “Randnotiz”: Wenn man eine Office 365 Subscription hat und seine Benutzerkonten aus einem On-Premise Active Directory nach Azure AD synchronisiert, dann kann man zwar an verschiedenen Stellen Dinge wie Passwort-Reset und andere Self-Service-Angebote aktivieren, diese aber nicht (so ohne Weiteres) benutzen. Der Benutzer bekommt beim Versuch, das Kennwort zu ändern eine Fehlermeldung, in etwa so:

kennwort1

oder so:

kennwort2

Im Wortlaut für die Suche:

“Ihr Konto ist für ein Zurücksetzen des Kennworts nicht aktiviert. Leider hat der Administrator Ihr Konto nicht zum Verwenden dieses Dienstes eingerichtet.”

bzw.

“Sie können Ihr Kennwort hier nicht ändern. Eine Kennwortänderung auf dieser Website wird von Ihrer Organisation nicht gestattet.”

Das Problem dabei ist: Mit dem in Office 365 enthaltenen Azure AD Lizenzen (Entspricht der Lizenzstufe Azure AD Basic) ist das nicht möglich – man bräuchte dazu Azure AD Premium! Und das wiederum wäre nur für dieses eine Feature (wenn man den Rest nicht braucht) in meinen Augen zu teuer…

Zitat aus der Microsoft Doku (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords):

Pricing and availability

Azure AD Password Reset is available in 3 tiers, depending on which subscription you have:

  • Azure AD Free - cloud-only administrators can reset their own passwords
  • Azure AD Basic or any Paid O365 Subscription - cloud-only users and cloud-only administrators can reset their own passwords
  • Azure AD Premium - any user or administrator, including cloud-only, federated, or password synced users, can reset their own passwords (requires password writeback to be enabled)

Heisst also, man kann nur die nicht-synchronisierten Accounts in der kostenlosen Stufe ändern bzw. zurücksetzen lassen.

10Jan/170

Active Directory: Benutzer GPOs mit Sicherheitsfilterung funktionieren nicht

Ja, ich weiß, ich erzähle jetzt hier nichts brandneues mehr. Aber vielleicht geht es anderen so wie mir diese Woche, daher also dieser Artikel. Aber erst mal von Anfang an:

Ich habe diese Woche in unserer ActiveDirectory Umgebung eine neue GPO angelegt. Mein Ziel war, damit eine neue Mailsignatur an alle Benutzer auszurollen. Die nötigen Einstellungen befinden sich im Benutzer-Zweig der GPOs, daher spreche ich gerne von einer “Benutzer-GPO”, was man bei mir auch immer im Namen sieht. Um das Ganze erstmal sinnvoll testen zu können, habe ich auf die Sicherheitsfilterung zurückgegriffen. Ihr wisst schon, damit kann man die GPO statt auf die gesamte verknüpfte OU auf einzelne Benutzer oder Gruppen anwenden. Also habe ich die “Authentifizierten Benutzer” entfernt, und stattdessen mich und einen weiteren Kollegen dort eingetragen:

gpo1

Das Problem

Leider wirkte sich die GPO dann nicht wie gewünscht aus. Auffällig war aber, dass ich plötzlich auch das Verzeichnis, in dem sich die GPO-Daten und damit auch das Skript, dass die GPO ausführen sollte, befanden, nicht mehr lesen konnte. Selbst mit einem Domänen-Admin-Konto nicht! Sobald ich die “Authentifizierten Benutzer” bzw. in meinem Fall “Authenticated Users” wieder hinzugefügt hatte, konnte ich die Dateien wieder lesen. Natürlich hätte ich damit aber auch die GPO für die gesamte GPO ausgerollt.

Die Ursache

Ein bisschen Recherche im Internet brachte mich dann auf die Ursache des Problems und damit auch auf dessen Lösung:

Microsoft hatte durch ein Update, dass bereits im Juni 2016 erschienen war, eine wesentliche Arbeitsweise von GPOs geändert:

Bisher war es so, dass für das Wirksamwerden von Computer-GPOs das Computerkonto für die GPO das Lesen-Recht haben musste und bei Benutzer-GPOs das Benutzerkonto. Das Ganze passte auch zur Logik, dass Computer-Richtlinien nur auf Computerkonten wirken und Benutzer-Richtlinien nur auf Benutzerkonten (Ausnahme: Loopback-Verarbeitung). Das hat man auch nicht geändert. Was allerdings geändert wurde ist, dass auch bei Benutzer-Richtlinien das Computerkonto die Leserechte auf die GPO braucht.

Wenn man entweder keine Benutzer-GPOs benutzt oder bei diesen immer die “Authenticated Users” in der “Security Filtering” drin lässt (womit dann faktisch nur noch eine Steuerung über die verknüpfte OU oder über WMI-Filter möglich wird, wenn man nicht vom “verweigern” der Berechtigungen Gebrauch machen will) ändert sich für einen selbst nichts.

Wenn man aber so wie ich gerne mal auch bei Benutzer-GPOs auf die Gruppen- oder Benutzerkonten-bezogene Filterung zurückgreift, dann muss man diese Änderung unbedingt kennen!

Die Lösung

Die Lösung des Problem ist eigentlich recht einfach – wenn man die Ursache kennt. Das Computerkonto des Computers, an dem der jeweilige Benutzer arbeitet muss also in die Lage versetzt werden, die GPO zu lesen. Da man nicht immer weiß, wer gerade wo arbeitet und sich das ja auch täglich ändern könnte, bleibt fast nur, den “Domänen-Computern” das Leserecht zu geben. Und das funktioniert über den Reiter “Delegation” bzw. “Delegierung”:

gpo2

Hier findet ihr noch den Blog-Artikel bei Microsoft, der mich zum Problem und dessen Lösung brachte:

https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/

14Dez/161

Hyper-V auf Windows Server 2012 R2 / 2016: VMs mittels Kerberos verschieben

Im Windows Server 2012 R2 und 2016 steckt ja nun schon seit einer Weile die so genannte “Shared Nothing Live Migration”, die es möglich macht, VMs zwischen Hyper-V-Hosts zu verschieben (auch im laufenden Betrieb), ohne, dass die VM auf einem Hyper-V-Cluster laufen muss, entsprechend ist hier auch kein Storage nötig.

Für die Shared Nothing Migration gibt es zwei Protokolle zur Authentifizierung: CredSSP und Kerberos.

CredSSP ist an sich sehr einfach in der Benutzung, bedarf es doch keiner echten Einrichtung. Lediglich den richtigen Radio-Button auswählen, einmal ab- und wieder anmelden und das war’s. Aber die Sache hat einen Haken: Bei CredSSP kann man nur dann eine VM verschieben, wenn man (lokal oder z.B. per RDP) an dem Hyper-V-Host angemeldet ist, von dem man die VM weg-verschieben will. MMC-Remoting mit dem Hyper-V-Manager geht hier nicht! Versucht man es doch, bekommt man folgende Fehlermeldung:

kerberos00

Im Wortlaut: “Failed to establish a connection with host HOSTNAME. The credentials supplied to the package were not recognized (0x8009030D).”

Insbesondere bei Core-Servern, auf denen es keinen Hyper-V-Manager gibt, wird das Verschieben also einigen Administratoren schwer fallen (wenngleich PowerShell eine nutzbare Lösung wäre).

Auch wenn man jetzt einfach im Hyper-V-Manager auf Kerberos umstellt:

kerberos7

..kommt es immer noch zu einem Fehler:

kerberos0

Im Wortlaut: “The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: The specified target is unknown or unreachable (0x80090303).”

Was hier fehlt ist die sogenannte “Constrained Delegation”. Diese einzurichten ist an sich nicht kompliziert, bei steigender Host-Anzahl aber etwas aufwändiger (eine einfachere PowerShell-Lösung versuche ich zeitnah nachzuliefern).

Zur Einrichtung benötigt man Schreibrechte auf den Computer-Objekten der Hyper-V-Hosts im Active Directory oder einfacher gleich einen Domain-Admin-Account.

Über die “Active Directory Users and Computers” öffnet man sich nun der Reihe nach die Computerkonten aller Hyper-V-Hosts und führt dort folgende Einstellung durch:

kerberos1kerberos2kerberos3

kerberos4kerberos5

Im Ergebnis muss es auf jedem Host so aussehen:

kerberos6

Jeder Host muss jedem anderen bei den Diensten “cifs” und “Microsoft Virtual System Migration Service” vertrauen. Kerberos alleine genügt.

Danach muss man natürlich die Hyper-V-Hosts auf Kerberos-Migration umstellen (oder dies zumindest noch einmal überprüfen!)

kerberos7

Das war’s dann schon! Jetzt kann man von jedem Client oder Server aus mittels Hyper-V-Manager auf die Hosts zugreifen und eine Verschiebung initiieren. Viel Spaß dabei!

14Nov/160

Office 365 / Azure AD: Kennwort eines Benutzers soll nicht ablaufen

Wenn man Office 365 Konten hat, die keinem Benutzer fest zugeordnet sind (in meinem Fall für Konferenz-Telefone), dann ist es eher ungünstig, wenn das Kennwort abläuft. Auch bei regulären Benutzern kann es gewünscht sein, dass das Kennwort nicht abläuft.

Wenn der Benutzer aus dem lokalen Active Directory synchronisiert wird, dann kann man diese Option einfach im lokalen AD einstellen. Aber bei einem Benutzer, der nur online existiert geht das nicht. Wie also dort das Ablaufen eines Kennwortes deaktivieren? Natürlich per PowerShell!

Dazu muss erst mit

Connect-MsolService

eine Verbindung mit Azure AD aufgebaut werden. Danach kann dann mit

Set-MsolUser -UserPrincipalName USER@MAIL.DE -PasswordNeverExpires $True

die entsprechende Einstellung vorgenommen werden.

O365_User_Password_Expire

Viel Spaß damit!

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…