The Hidden Cost of Restoring a DAG Node
This case began with a simple symptom:
Search didn’t work for any database mounted on one DAG node — even though everything looked healthy.
- ContentIndexState = Healthy
- MSExchangeFastSearch and HostControllerService running
- index size identical to the working node
- no anomalies in Get-MailboxDatabaseCopyStatus … -ConnectionStatus
Yet mailbox search failed.
Attempting a catalog reseed:
Update-MailboxDatabaseCopy -Identity DB01\EX1 -CatalogOnly
produced:
WARNING: Seeding of content index catalog for database ‘DB01’ failed.
Please verify that the Microsoft Search (Exchange) and
the Host Controller service for Exchange services are running and try the operation again.
Error: There was no endpoint listening at
net.tcp://localhost:3863/Management/SeedingAgent-032E738E-C721-400D-9C49-4FA2FF3D3E5112/Single
that could accept the message.
This is often caused by an incorrect address or SOAP action. This error points to a failure inside the Ceres Search Engine (internal endpoints, HostController, RPC channels) — not the index files.
🧩 Root Cause
Before the issue appeared, the server had been restored from a VM-level backup / snapshot / image restore.
Such recovery methods are not supported for Exchange.
They often leave internal components (Search, Cluster, IIS, Transport) in an inconsistent state, even if the server appears “healthy”.
The correct supported recovery method is:
✔️ Setup.exe /RecoverServer
Full details and an explanation of why snapshot/image restores are unsupported are available in the dedicated post:
👉 [link to the recovery post]
In this case, the customer understood the risk and opted to try a local repair instead.
🔧 Workaround (Customer Decision)
Although unsupported officially, the customer decided to rebuild the Search subsystem locally.
1. Stop & disable services:
Microsoft Exchange Search
Microsoft Exchange Search Host Controller
2. Remove node data:
C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data\Nodes\Fsis
3. Uninstall Search:
cd “C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Installer”
.\installconfig.ps1 -action U -datafolder “C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data”
4. Reinstall Search:
.\installconfig.ps1 -action I -datafolder “C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data”
5. Start services:
Microsoft Exchange Search Host Controller
Microsoft Exchange Search
Search functionality was restored. Note that in some cases index reseeding can be also required:
Update-MailboxDatabaseCopy -Identity DB01\EX1 -CatalogOnly
🧾 Conclusion
This case shows how an Exchange server restored via an unsupported method may appear healthy yet have broken internal components — Search being one of the first to fail. Another issue in that specific case – was cluster misconfiguration. But that’s another story.
For supported, predictable recovery, always use Setup.exe /RecoverServer.
Details and a full explanation of unsupported recovery methods are in the dedicated post:
👉 Unsupported Exchange Server Recovery Methods
The workaround succeeded here, but it was accepted at the customer’s own risk.
End.
EWS Free Area 
Leave a comment