![[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
07-'20 Word : "Contact opnemen met..."
Reacties
Door
edeboeck,
woensdag 15 april 2020 18:10
Wat me opviel aan de foutcode is dat die als negatief getal getoond wordt... dat gebeurt weleens meer als een unsigned waarde (in dit geval uint) als signed (in dit geval int) getoond wordt. Stel dat je dit in de toekomst nog eens hebt, loont het de moeite die waarde naar binair om te zetten, de laatste 32 bits te nemen en die om te zetten naar hexadecimaal.
In dit geval wordt dat: -2147221231 -> 1000 0000 0000 0100 0000 0001 0001 0001 -> 8004011
Als je dan gaat zoeken op exchange error 0x8004 0111 ("0x" voor de code omdat het een hex waarde is), dan krijg je al wat meer hits.
Just my 2 cents, wie weet komt dat ooit eens van pas.
Bedankt om jouw ervaringen te delen!
edeboeck
In dit geval wordt dat: -2147221231 -> 1000 0000 0000 0100 0000 0001 0001 0001 -> 8004011
Als je dan gaat zoeken op exchange error 0x8004 0111 ("0x" voor de code omdat het een hex waarde is), dan krijg je al wat meer hits.
Just my 2 cents, wie weet komt dat ooit eens van pas.
Bedankt om jouw ervaringen te delen!
edeboeck
Door
DaLass,
woensdag 15 april 2020 18:41
Goeie tip, die kende ik nog niet. Zo leren we weer van elkaar.edeboeck schreef op woensdag 15 april 2020 @ 18:10:
Wat me opviel aan de foutcode is dat die als negatief getal getoond wordt... dat gebeurt weleens meer als een unsigned waarde (in dit geval uint) als signed (in dit geval int) getoond wordt. Stel dat je dit in de toekomst nog eens hebt, loont het de moeite die waarde naar binair om te zetten, de laatste 32 bits te nemen en die om te zetten naar hexadecimaal.
In dit geval wordt dat: -2147221231 -> 1000 0000 0000 0100 0000 0001 0001 0001 -> 8004011
Als je dan gaat zoeken op exchange error 0x8004 0111 ("0x" voor de code omdat het een hex waarde is), dan krijg je al wat meer hits.
Just my 2 cents, wie weet komt dat ooit eens van pas.
Bedankt om jouw ervaringen te delen!
edeboeck
Door
Shinoki,
maandag 20 april 2020 23:37
De grootste vraag is natuurlijk wat is er met de publicfolder db gebeurt. Lijkt erop dat men die niet mee heeft gemigreerd. (Kan een bewuste keuze zijn maar dan is de cleanup niet goed uitgevoerd)
Door
DaLass,
dinsdag 21 april 2020 19:42
Er is in beide cases sprake geweest van een oude public folder database die al eerder verwijderd was. Deze heeft toch sporen achtergelaten, wat de problemen van deze blog veroorzaakt heeft.Shinoki schreef op maandag 20 april 2020 @ 23:37:
De grootste vraag is natuurlijk wat is er met de publicfolder db gebeurt. Lijkt erop dat men die niet mee heeft gemigreerd. (Kan een bewuste keuze zijn maar dan is de cleanup niet goed uitgevoerd)
Is het dan een slecht uitgevoerde cleanup? Ja, wellicht. Die is destijds vast uitgevoerd met alle kennis die er op dat moment beschikbaar was. Achteraf blijkt dat er dus nog meer is om op te schonen.
Om te kunnen reageren moet je ingelogd zijn. Via deze link kun je inloggen als je al geregistreerd bent. Indien je nog geen account hebt kun je er hier één aanmaken.