![[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.
Word : "Contact opnemen met..."
Recent werd ik door een collega gevraagd om eens mee te denken met een geval van traagheid bij het starten van Word. In de betreffende case was er sprake van een vertraging van +/- 1 minuut bij het openen van een ouder Word document welke al meer dan een half jaar geleden is aangemaakt. Bij het openen van het bestand was het mooie blauwe start-scherm van Word te zien, met onderin de volgende tekst:
Contact opnemen met \\SERVER01\Share$\Bedrijf\Templates
Dit scherm bleef ongeveer een minuut staan, waarna het document geopend werd. Wat opviel in het start-scherm was dat er verwezen werd naar SERVER01, welke al een half jaar niet meer bestaat en is gemigreerd naar SERVER02. Alle bestanden die op SERVER02 zijn aangemaakt, hebben ook geen problemen en worden gewoon snel geopend in Word. Tijd om even verder te kijken.
De documenten in kwestie zijn .DOCX bestanden, wat eigenlijk gewoon archieven zijn. Bij een voorbeeld document hebben we de extensie dan ook hernoemd naar .ZIP en zijn we gaan spitten in het archief om de verwijzing naar de betreffende template locatie te kunnen vinden. De verwijzing was terug te vinden in het bestand settings.xml.rels, te vinden in de map word\_rels van het archief. Hierin was het volgende te vinden:
De documenten in kwestie zijn .DOCX bestanden, wat eigenlijk gewoon archieven zijn. Bij een voorbeeld document hebben we de extensie dan ook hernoemd naar .ZIP en zijn we gaan spitten in het archief om de verwijzing naar de betreffende template locatie te kunnen vinden. De verwijzing was terug te vinden in het bestand settings.xml.rels, te vinden in de map word\_rels van het archief. Hierin was het volgende te vinden:
code:
1
2
3
4
| <?xml version="1.0" encoding="UTF-8" standalone="true"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship TargetMode="External" Target="file:///\\SERVER01\Share$\Bedrijf\Templates\Template.dotx" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate" Id="rId1"/>
</Relationships> |
Na het handmatig aanpassen van de template verwijzing naar de nieuwe locatie (\\SERVER02.domein.nl\Share\Bedrijf\Templates\Template.dotx) hebben we het archief weer terug hernoemd naar .DOCX om te kijken of de wijziging effect zou hebben, en met succes: Het bestand kon weer snel geopend worden en werd met de juiste template geladen.
Maar nu... De map in kwestie is een datamap van een applicatie die word documenten opslaat en bevat (inclusief submappen) enkele duizenden word documenten. Niet echt een klus om met de hand aan te gaan passen. Gelukkig waren wij niet de enige die tegen dit probleem zijn aangelopen en is er iemand geweest die daar een tooltje voor geschreven heeft, genaamd Word Template Corrector:
Maar nu... De map in kwestie is een datamap van een applicatie die word documenten opslaat en bevat (inclusief submappen) enkele duizenden word documenten. Niet echt een klus om met de hand aan te gaan passen. Gelukkig waren wij niet de enige die tegen dit probleem zijn aangelopen en is er iemand geweest die daar een tooltje voor geschreven heeft, genaamd Word Template Corrector:
De tool moet je zelf even compilen (je kunt ook de binary aanschaffen en de ontwikkelaar supporten) met de instructies op bovenstaande website, en dan heb je een mooie executable genaamd wtc.exe die je kan helpen met het aanpassen van de template locatie in de .DOCX bestanden.
Het runnen van wtc.exe zonder verder input toont de info hoe je de applicatie kunt gebruiken:
Het runnen van wtc.exe zonder verder input toont de info hoe je de applicatie kunt gebruiken:
code:
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
| C:\Temp>wtc.exe
Word Template Corrector
Correcting wrong paths to templates in MS Office Word documents.
USE AT YOUR OWN RISK.
WTC 1.0.0.3
Don't panic!
ERROR(S):
-d/--directory required option is missing.
-o/--old required option is missing.
-n/--new required option is missing.
-d, --directory Required. working directory.
-o, --old Required. The old part of the templates path to be
replaced.
-n, --new Required. The new (replacement) part of the templates
path.
-r, --recursive Recurse through subdirectories.
-b, --nobackup (Default: False) Do NOT create a backup (.bak) of each
changed document.
-t, --dry-run (Default: False) Do not change any files (for testing).
-v, --verbose (Default: False) Activates verbose error messages.
-p, --preserve (Default: False) Preserve permissions & dates
--help Display this help screen.
Example: wtc -d \\server\share\documents -o \\oldserver\share\templates\ -n \\server\share\templates\ -r
C:\Temp> |
Goed, laten we eens een dry run doen op een originele versie van het document:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| C:\Temp>wtc.exe -d "C:\Temp\Docs" -o \\SERVER01\Share$\Bedrijf\Templates\Template.dotx -n \\SERVER02.domein.nl\Share\Bedrijf\Templates\Template.dotx -t -p Directory : C:\Temp\Docs Search for : \\SERVER01\Share$\Bedrijf\Templates\Template.dotx Replace with: \\SERVER02.domein.nl\Share\Bedrijf\Templates\Template.dotx no Backups : False Recursive : False Preserve : True Dry run : True AFFECTED C:\Temp\Docs\Testdocument.docx 1 file(s) scanned 1 file(s) affected and need correction 0 error(s) occured Runtime 00:00:00.04 C:\Temp> |
De dry-run is goed gegaan, maar de locatie van de template is te specifiek, want op de share is er sprake van meerdere templates. Het liefst vervangen we dus alleen het begin van de share, aangezien alleen de servernaam en de sharenaam zijn gewijzigd en de rest van de template locatie(s) gelijk gebleven zijn.
Nogmaals een dry-run, alleen wat algemener:
Nogmaals een dry-run, alleen wat algemener:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| C:\Temp>wtc.exe -d "C:\Temp\Docs" -o \\SERVER01\Share$\ -n \\SERVER02.domein.nl\Share\ -t -p Directory : C:\Temp\Docs Search for : \\SERVER01\Share$\ Replace with: \\SERVER02.domein.nl\Share\ no Backups : False Recursive : False Preserve : True Dry run : True AFFECTED C:\Temp\Docs\Testdocument.docx 1 file(s) scanned 1 file(s) affected and need correction 0 error(s) occured Runtime 00:00:00.04 C:\Temp> |
Nice, dat werkt ook. Ok, dan eens geen dry-run, maar een daadwerkelijke aanpassing:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| C:\Temp>wtc.exe -d "C:\Temp\Docs" -o \\SERVER01\Share$\ -n \\SERVER02.domein.nl\Share\ -p Directory : C:\Temp\Docs Search for : \\SERVER01\Share$\ Replace with: \\SERVER02.domein.nl\Share\ no Backups : False Recursive : False Preserve : True Dry run : False CHANGED C:\Temp\Docs\Testdocument.docx 1 file(s) scanned 1 file(s) corrected 0 error(s) occured Runtime 00:00:00.06 C:\Temp> |
Een controle in de .DOCX laat zien dat het bestand settings.xml.rels netjes is aangepast naar de nieuwe locatie en het word document kan ook zonder problemen en snel geopend worden. Voor de uiteindelijke uitvoer op de locatie van de bestanden passen we nog de volgende wijzigingen toe:
- Voor de dry-run:
wtc.exe -d "<ROOT_DOCX_BESTANDEN>" -o \\SERVER01\Share$\ -n \\SERVER02.domein.nl\Share\ -t -r -p
(-r toegevoegd, zodat ook de submappen meegepakt worden). - Extra backup draaien van de locatie van de DOCX bestanden, alvorens we daadwerkelijke aanpassing uitvoeren.
- Voor de aanpassing:
wtc.exe -d "<ROOT_DOCX_BESTANDEN>" -o \\SERVER01\Share$\ -n \\SERVER02.domein.nl\Share\ -r -b -p
(-t verwijderd, het is geen dry-run meer. -b toegevoegd, het proces hoeft geen .bak te maken van elk aangepast document, daar hebben we al een backup voor).
Met minimale inspanning alle documenten van de klant aangepast, zodat deze weer snel en met de juiste template verwijzing(en) geopend kunnen worden.
Voor het oplossen zijn de volgende bronnen gebruikt:
- Google Search
Mijn grote zoekvriend - How to fix slow opening Microsoft Word documents because of invalid network paths
Het blog van Schakko, die de problemen hierboven in het engels beschrijft en de Word Template Changer tool heeft geschreven - Word Template Corrector @ Github
De Github locatie van Word Template Corrector
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