On an Exchange Server 2013 server that is installed with the Mailbox server role, when you attempt to delete the files and folders for a database or database copy that has been removed, you may receive an error.


The action can’t be completed because the file is open in noderunner.exe
Inside the folders that previously contained the database you will see various subfolders and index files relating to search services.

The issue is that even though the database has been removed the search/index files are still locked by the noderunner.exe process and can’t be deleted.
Using Process Explorer we can see that noderunner.exe is a child process of the Microsoft Exchange Search Host Controller (HostControllerService) service.


To clear the file lock you can restart the HostControllerService service using PowerShell.
PS C:\> Restart-Service HostControllerService
You should now be able to delete the files and folders successfully.
In my own scenario the HostControllerService began consuming a large amount of CPU for a short period of time after the restart, but then calmed down to normal levels again after a few moments.




Thanks. This was useful.
So what is the right way to delete the Exchange files after we remove the MB Database? Do you suggest restarting the host controller service all the time.
I only recommend doing it if you encounter this problem when trying to delete the files.
Apparently it always complains about the files being in use.
I am not too sure what MS recommends to clean up those physical files.
Then I imagine this solution will get a lot of use in coming years
But you know what, the files will be generated later again!
Pretty scary…I believe the FAST cache should be cleared somewhere but MS just didn’t release any information about it…
Yes they will be generated again if you create a database or database copy in that path again.
Hi Paul,
I’m afraid those files will be generated again even if you do NOT create a database in that path again… It seems to me the Search Service creates those files again even if the db is deleted.
This looks like a Microsoft bug to me.
I’ve created a test DB then gone through the removal steps above, and the files are gone and haven’t come back.
What exact steps are you using to reproduce the issue?
Someone said this problem is fixed in CU1. I will try it. Thanks!
Thanks Simon.
Just verified. This problem is fixed in CU1.