Exchange 2013 Content Index Troubleshoot Script werkt niet

De Exchange Scripts directory (cd $exscripts) bevat een groot aantal script die je kunnen helpen om veelvoorkomende (complexe) taken uit te voeren of als hulpmiddel bij het verhelpen van issues. Een daarvan is de Content Index Troubleshooter (Troubleshoot-CI.ps1), dit script verscheen voor het eerst in Exchange 2010 RTM en kan problemen met Content Indexing niet alleen opsporen maar in veel gevallen ook verhelpen.

Op een Exchange 2013 server vind je dit script ook, maar als hem wilt uitvoeren krijg je een onduidelijke foutmelding:

Nou ja onduidelijk, het script meldt dat de volgende registry key niet gevonden kan worden:

SOFTWARE\Microsoft\ExchangeServer\v15\ContentIndex\CatalogHealth\{<Database GUID>}

Dit is logisch omdat de \ContentIndex hyve niet langer bestaat op een server met Exchange 2013:

Dit komt doordat zoeken en indexeren op Exchange 2007 en 2010 wordt uitgevoerd met Exchange Search. In Exchange 2010, en ook SharePoint en de andere "wave 15" producten, is dit vervangen door de FAST technologie ook wel Microsoft Search Foundation genoemd. Dit is bijvoorbeeld de reden dat we voor Exchange 2013 niet langer het Office Filter Pack hoeven te installeren omdat FAST deze types standaard als indexeren kan.

En hoewel de beheerinterface hetzelfde is gebleven, dat wil zeggen dat we dezelfde cmdlets gebruiken om search mee te managen, zijn de veranderingen onder de motorkap wel zichtbaar. En zo komen we weer bij Troubleshoot-CI.ps1 die zoekt naar een registry hive die niet langer bestaat...

Het mag geen geheim zijn dat ik, net als veel van mijn collega-specialisten, kritisch ben op het kwaliteitsniveau van Exchange en versie 2013 in het bijzonder. Het dat Microsoft gesierd als iemand even door de $exscripts directory was gewandeld om te controleren of alle aangeboden scripts in Exchange 2013 ook werken.

Een ander voorbeeld is het new-TestCasConnectivityUser.ps1 script die niet werkt als er meerdere OU's bestaan met de naam Users. Iets waar ik in 2010 al over schreef en verschillende keren bij Microsoft aangegeven heb. Boze tongen beweren dat dit is omdat Microsoft deze scripts niet belangrijk vind voor Office 365 en daarom geen prioritiet geeft. En misschien zit daar wel wat in...