1
Exchange (2016): Suche in Outlook + OWA liefert kein Ergebnis
Quelle des Titelbildes: https://i.wfcdn.de/teaser/1920/39662.jpg
Hallo zusammen,
weil ich vorhin selbst darüber gestolpert bin.
Ausgangslage
Am WE habe ich aufgrund des Exchange-2022-Bugs die AntiMalwareEngine via "Disable-AntiMalwareScanning.ps1 deaktiviert und gestern unseren Exchange 2016 CU21 auf CU21 SU Nov. 21 aktualisiert. Anschließend noch die Thematik mit dem 2022er-Bug gefixt (
Kollegen meldeten heute dann, dass die Suche in Outlook nicht funktioniert.
Erste Recherche: https://community.spiceworks.com/topic/2177995-exchange-2016-outlook-and ...
Status ermitteln
Status der beiden relevanten Dienste ermitteln
Pfad der Exchange-Datenbank ermitteln (wird später benötigt):
Dienste stoppen
Parallel zur Exchange-DB existiert ein Ordner
Ist der Ordner "weg", dann können die Dienste gestartet werden:
Hinweis
In unserem Fall lies sich der Dienst
Anschließend die Status' prüfen:
Hinweis: Sind die Dienste gestartet, baut der Exchange die Suchindizes neu auf. Das sorgt dann für eine - je nach Größe der DB - länger andauernde Anzahl an I/Os auf dem Drive, auf dem die DB liegt.
Ob obiges Vorgehen auch für den Exchange 2013 und 2019 funktioniert weiß ich nicht. im 2019er habe ich gerade flüchtig irgendwo gelesen, dass die dortigen Suchindizes direkt in der DB abgelegt werden...
Hallo zusammen,
weil ich vorhin selbst darüber gestolpert bin.
Ausgangslage
Am WE habe ich aufgrund des Exchange-2022-Bugs die AntiMalwareEngine via "Disable-AntiMalwareScanning.ps1 deaktiviert und gestern unseren Exchange 2016 CU21 auf CU21 SU Nov. 21 aktualisiert. Anschließend noch die Thematik mit dem 2022er-Bug gefixt (
Reset-ScanEngineVersion.ps1 -Force). Mails konnten intern und extern versendet werden (Betroffen waren wir bisweilen nicht von dem Bug).Kollegen meldeten heute dann, dass die Suche in Outlook nicht funktioniert.
Erste Recherche: https://community.spiceworks.com/topic/2177995-exchange-2016-outlook-and ...
Status ermitteln
Get-MailboxDatabaseCopyStatusName Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndexState
Length Length
----------------------------- ------ --------- ----------- -------------------- ------------
EXDatabase\SRV-Exchange Mounted 0 0 FailedStatus der beiden relevanten Dienste ermitteln
get-service | Select-Object Name, DislayName, Status | Where-Object {($_.Name -eq "MSExchangeFastSearch") -or ($_.Name -eq "HostControllerService")} Name DisplayName Status
---- ----------- ------
HostControllerService Microsoft Exchange Search Host Controller Stopped
MSExchangeFastSearch Microsoft Exchange-Suche RunningPfad der Exchange-Datenbank ermitteln (wird später benötigt):
Get-MailboxDatabase -Status | select edbfilepathEdbFilePath
-----------
Z:\Exchange Server\V15\Mailbox\EXDatabase\EXDatabase.edbDienste stoppen
get-service | Select-Object Name, DislayName, Status | Where-Object {($_.Name -eq "MSExchangeFastSearch") -or ($_.Name -eq "HostControllerService")} | Stop-Service -Name $_.Name Parallel zur Exchange-DB existiert ein Ordner
<GUID>.Single. Dieser muss gelöscht oder verschoben werden. Ein Umbenennen in <GUID>.Single.old reicht nicht, da der Exchange-Server/ Suchdienst den umbenannten auch wieder finden wird.Ist der Ordner "weg", dann können die Dienste gestartet werden:
get-service | Select-Object Name, DislayName, Status | Where-Object {($_.Name -eq "MSExchangeFastSearch") -or ($_.Name -eq "HostControllerService")} | Start-Service -Name $_.Name In unserem Fall lies sich der Dienst
HostControllerService nicht starten. Ein Blick unter Services.msc zeigte, dass er deaktiviert gewesen ist. Hier habe ich ihn dann wieder aktiviert/ auf automatisch gesetzt.Anschließend die Status' prüfen:
get-service | Select-Object Name, DislayName, Status | Where-Object {($_.Name -eq "MSExchangeFastSearch") -or ($_.Name -eq "HostControllerService")} Name DisplayName Status
---- ----------- ------
HostControllerService Microsoft Exchange Search Host Controller Running
MSExchangeFastSearch Microsoft Exchange-Suche RunningGet-MailboxDatabaseCopyStatusName Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndexState
Length Length
----------------------------- ------ --------- ----------- -------------------- ------------
EXDatabase\SRV-Exchange Mounted 0 0 CrawlingHinweis: Sind die Dienste gestartet, baut der Exchange die Suchindizes neu auf. Das sorgt dann für eine - je nach Größe der DB - länger andauernde Anzahl an I/Os auf dem Drive, auf dem die DB liegt.
Ob obiges Vorgehen auch für den Exchange 2013 und 2019 funktioniert weiß ich nicht. im 2019er habe ich gerade flüchtig irgendwo gelesen, dass die dortigen Suchindizes direkt in der DB abgelegt werden...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1691614850
Url: https://administrator.de/contentid/1691614850
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
1 Kommentar
Hallo,
zur Info - ab Exchange 2019 geht das definitiv NICHT.
Hier bekommt man die Meldung "NotApplicable" bei der ContentIndexState
Der Grund: Die SuchEngine "BigFunnel", wie sie auch bei ExchangeOnline ist, wurde hier implementiert. Und ja, das ist dann direkt pro Postfach
https://www.alitajran.com/exchange-server-content-index-state-notapplica ...
Probleme mit der Suche gibt es aber weiterhin.
Das wurde ja auch hier schon öfter diskutiert, dass das einfach suboptimal ist:
Outlook Suche in freigegebenen Postfächern
zur Info - ab Exchange 2019 geht das definitiv NICHT.
Hier bekommt man die Meldung "NotApplicable" bei der ContentIndexState
Der Grund: Die SuchEngine "BigFunnel", wie sie auch bei ExchangeOnline ist, wurde hier implementiert. Und ja, das ist dann direkt pro Postfach
https://www.alitajran.com/exchange-server-content-index-state-notapplica ...
Probleme mit der Suche gibt es aber weiterhin.
Das wurde ja auch hier schon öfter diskutiert, dass das einfach suboptimal ist:
Outlook Suche in freigegebenen Postfächern
