![[RSS]](https://tweakers.net/g/if/v2/icons/rss_small.png){kind=icon}
Let op: Tweakers stopt per 2023 met Tweakblogs. In
dit artikel
leggen we uit waarom we hiervoor hebben gekozen.
Exchange 2016 : Mailbox logon returned EcLoginFailure -2147221231
Afgelopen week ben ik door 2 collega's benaderd om eens mee te denken bij 2 verschillende cases waarbij Outlook clients die niet meer konden verbinden naar de mailbox van de gebruiker. Gek genoeg was het wel mogelijk om verbinding te maken via OWA, dus er was geen sprake van een verlopen wachtwoord of een geblokkeerd account.
In beide gevallen was er sprake van een recente & bijgewerkte versie van Outlook in combinatie met een on-premises Exchange 2016 server.
Tijd om te wat testen uit te voeren. Hiervoor heb ik gebruik gemaakt van de tools die Microsoft online heeft staan, de Microsoft Remote Connectivity Analyzer:
In de analyzer is een optie om de Outlook Connectivity te testen, waarmee je middels een testaccount kunt controleren of de connectiviteit naar Outlook goed gaat. In beide cases kwam dezelfde fout naar boven:
1 van de hits beschrijft een situatie die vergelijkbaar is met de 2 cases waar ik mee te maken heb, namelijk een Exchange 2016 server die is ontstaan na een migratie uit Exchange 2010:
De symptonen komen overeen en de foutcode komt overeen, dus we zitten op de goede weg. Na het lezen van de blogpost blijkt dat er niet echt een goede oplossing is, de schrijver biedt als "oplossing" om de mailbox(en) te verplaatsen naar een nieuwe mailbox database, waarmee het probleem verholpen is.
Ok, het is dan niet echt een oplossing, maar wel het testen waard of dat inderdaad ook bij mijn cases zo is. We verplaatsen het testaccount naar een nieuwe database en draaien nogmaals de Outlook Connectivity test.
Resultaat : Succes! Het werkt.
Maargoed, zoals al geschreven, dit is niet echt een oplossing, want even nieuwe databases aanmaken en alle mailboxen verplaatsen is een behoorlijke klus en vergt ook (tijdelijk) extra storage om deze databases kwijt te kunnen.
We testen ook de weg terug: Wat gebeurd er als we het testaccount terugzetten in een bestaande database? Na het terugzetten wederom weer de Outlook Connectivity test.
Resultaat: Error! Dezelfde foutmelding als voorheen.
Conclusie: Er zit "iets" in de bestaande databases, wat niet in een nieuwe database zit. Tijd om deze te vergelijken.
Middels de Exchange Management Shell op de mailserver geven we het volgende commando:
We krijgen de bestaande databases en de nieuw aangemaakte databases terug.
Per database halen we alle info naar boven en zetten deze in een Excel sheet naast elkaar om snel de waarden te vergelijken.
Per database:
Afgezien van de standaard dingen (naam van de database, pad naar de bestanden, etc), valt het attribuut "PublicFolderDatabase" op, om 2 redenen:
Dit geeft weer nieuwe mogelijkheden om verder te zoeken, want het hebben van een waarde die naar een verwijderd object verwijst, is opmerkelijk en lijkt niet te kloppen. De volgende stop is het de blog van SomoIT :
De blogpost van SomoIT spreekt hier niet over Exchange 2016, maar over Exchange 2013, maar de rest komt overeen: De Exchange 2013 server is ontstaan na een migratie vanaf Exchange 2010 en het attribuut PublicFolderDatabase van de mailbox database verwijst naar een deleted object. De reden dat deze blogpost niet naar voren kwam in de eerste zoekopdracht is omdat er geen verwijzing is naar de foutcode die we krijgen in de Remote Connectivity Analyzer.
De oplossing volgens SomoIT is om, middels ADSI EDIT, de inhoud van het attribuut msExchHomePublicMDB op elke mailbox database te verwijderen.
Na het veilig stellen van de huidige waarde hebben we bij de mailboxdatabase met onze testgebruiker de waarde verwijderd, waarna we opnieuw een test gedaan hebben met de Outlook Connectivity test.
Resultaat : Succes! Het werkt.
In beide cases zijn de waarden van de mailbox databases opgeschoond, waarna alles weer als een zonnetje werkt.
Voor het oplossen zijn de volgende bronnen gebruikt:
In beide gevallen was er sprake van een recente & bijgewerkte versie van Outlook in combinatie met een on-premises Exchange 2016 server.
Tijd om te wat testen uit te voeren. Hiervoor heb ik gebruik gemaakt van de tools die Microsoft online heeft staan, de Microsoft Remote Connectivity Analyzer:
In de analyzer is een optie om de Outlook Connectivity te testen, waarmee je middels een testaccount kunt controleren of de connectiviteit naar Outlook goed gaat. In beide cases kwam dezelfde fout naar boven:
Vooral de statuscode is interessant, want je verwacht dat je daarmee wel iets moet kunnen vinden om bij de oplossing te kunnen komen. Helaas zijn het aantal potentieel bruikbare hits te tellen op 1 hand.Testing the MAPI Mail Store endpoint on the Exchange server.
An error occurred while testing the Mail Store.
Attempting to log on to the Mailbox.
An error occurred while logging on to the Mailbox.
Additional Details
Mailbox logon returned EcLoginFailure -2147221231. Possible causes are:
1. The user doesn't have any access to a private mailbox or public folder messaging data.
2. There are no private mailboxes or public folders on the server.
3. The server is exiting or is about to exit.
Status Code: -2147221231
1 van de hits beschrijft een situatie die vergelijkbaar is met de 2 cases waar ik mee te maken heb, namelijk een Exchange 2016 server die is ontstaan na een migratie uit Exchange 2010:
De symptonen komen overeen en de foutcode komt overeen, dus we zitten op de goede weg. Na het lezen van de blogpost blijkt dat er niet echt een goede oplossing is, de schrijver biedt als "oplossing" om de mailbox(en) te verplaatsen naar een nieuwe mailbox database, waarmee het probleem verholpen is.
Ok, het is dan niet echt een oplossing, maar wel het testen waard of dat inderdaad ook bij mijn cases zo is. We verplaatsen het testaccount naar een nieuwe database en draaien nogmaals de Outlook Connectivity test.
Resultaat : Succes! Het werkt.
Maargoed, zoals al geschreven, dit is niet echt een oplossing, want even nieuwe databases aanmaken en alle mailboxen verplaatsen is een behoorlijke klus en vergt ook (tijdelijk) extra storage om deze databases kwijt te kunnen.
We testen ook de weg terug: Wat gebeurd er als we het testaccount terugzetten in een bestaande database? Na het terugzetten wederom weer de Outlook Connectivity test.
Resultaat: Error! Dezelfde foutmelding als voorheen.
Conclusie: Er zit "iets" in de bestaande databases, wat niet in een nieuwe database zit. Tijd om deze te vergelijken.
Middels de Exchange Management Shell op de mailserver geven we het volgende commando:
code:
1
| Get-MailboxDatabase |
We krijgen de bestaande databases en de nieuw aangemaakte databases terug.
Per database halen we alle info naar boven en zetten deze in een Excel sheet naast elkaar om snel de waarden te vergelijken.
Per database:
code:
1
| Get-MailboxDatabase -Identity Databasenaam | Format-List |
Afgezien van de standaard dingen (naam van de database, pad naar de bestanden, etc), valt het attribuut "PublicFolderDatabase" op, om 2 redenen:
- 1. Het attribuut is bij de bestaande databases gevuld en bij de nieuwe database niet.
- 2. Nog opmerkelijker is dat er verwezen wordt naar een niet-bestaand object, zie hieronder:
code:
1
2
3
4
5
6
7
8
| Get-MailboxDatabase | Format-List Name,PublicFolderDatabase
Name : EXISTING-DB
PublicFolderDatabase : contoso.local/Configuration/Deleted Objects/Public Folder Database CONTOSO
DEL:f5k3d44e-b1c5-9674-2648-15e29b1ghd91
Name : NEW-DB
PublicFolderDatabase : |
Dit geeft weer nieuwe mogelijkheden om verder te zoeken, want het hebben van een waarde die naar een verwijderd object verwijst, is opmerkelijk en lijkt niet te kloppen. De volgende stop is het de blog van SomoIT :
De blogpost van SomoIT spreekt hier niet over Exchange 2016, maar over Exchange 2013, maar de rest komt overeen: De Exchange 2013 server is ontstaan na een migratie vanaf Exchange 2010 en het attribuut PublicFolderDatabase van de mailbox database verwijst naar een deleted object. De reden dat deze blogpost niet naar voren kwam in de eerste zoekopdracht is omdat er geen verwijzing is naar de foutcode die we krijgen in de Remote Connectivity Analyzer.
De oplossing volgens SomoIT is om, middels ADSI EDIT, de inhoud van het attribuut msExchHomePublicMDB op elke mailbox database te verwijderen.
Na het veilig stellen van de huidige waarde hebben we bij de mailboxdatabase met onze testgebruiker de waarde verwijderd, waarna we opnieuw een test gedaan hebben met de Outlook Connectivity test.
Resultaat : Succes! Het werkt.
In beide cases zijn de waarden van de mailbox databases opgeschoond, waarna alles weer als een zonnetje werkt.
Voor het oplossen zijn de volgende bronnen gebruikt:
- Microsoft Remote Connectivity Analyzer
Test tools voor o.a. Office365 en Exchange - Google Search
Mijn grote zoekvriend - SuperTekBoy
Een van de weinige blogs die iets schreef over de foutcode - SomoIT
Het blog met de oplossing voor de PublicFolderDatabase waarde