Microsoft Filtering Management Service won't start on Exchange 2013
In a recent case, the transport service on an exchange 2013 server was failing to start due to a dependency failure (Error 1068: The dependency service or group failed to start). As it turned out, it was dependent on the Microsoft Filtering Management Service (FMS.exe), and that was the service that was having trouble starting. Since it didn't start, Transport couldn't start.
As it turns out, the customer had several third party add-ons, some of which inventoried or in some other way touched the files in the Exchange environment. Many third party applications are not Exchange Aware and can lock those files when the server is trying to use or update them and this can lead to corruption. Put on top of that some problematic iSCSI connections and it is a recipe for disaster. This can come in the form of permissions being broken, XML files being corrupted, binaries corrupting.
So, what can you do about it?
Well, if you have more than one server and it is not broken on one of the other servers that are on the same Cumulative Update version as the affected server, you can replace the existing FIP-FS folder with the one from the working server. We will go over those steps in the a moment.
If you only have one server, you can remove the dependency on the Microsoft Filtering Management Service so Transport can come up with out it. To do this, simply run the following from Powershell that is running as Administrator from the C:\Program Files\Microsoft\Exchange Server\V15\Scripts folder:
When that completes, the Transport service should be able to come up, but it may require a reboot first to ensure all memory hooks are released. To get Microsoft Filtering Management Service fixed, your best option is to apply a newer cumulative update(CU) (preferably the latest), as you have nothing to compare permissions to, nor do you have a working copy to replace your corrupted copy with. Cumulative updates in Exchange 2013 are complete refreshes of the Exchange server so should remove any of the corrupted file structure and replace it with a fresh new copy. If you are already at the latest CU, you will likely need to stand up a new Exchange server and move everything to it, or wait for the next quarterly CU. A disaster recovery (DR) restore might alleviate the issue, but those tend to be tedious and can lead to data loss.
Now, on to how you would perform the copy from a working system.
- Disable anti-malware scanning using the .\Disable-AntimalwareScanning.ps1 found in the C:\Program Files\Microsoft\Exchange Server\V15\Scripts folder to make sure it is no longer connected into exchange. A reboot may be necessary.
- Disable all exchange and Microsoft Filtering Management services on the affected server and reboot.
- Stop and Disable Microsoft Filtering management service on working server.
- Rename C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS subfolders (Bin and Data) on affected server to something like Bin-old and Data-old.
- Copy FIP-FS subfolders from working server to affected server.
- Set Microsoft Filtering management service to automatic and start transport on working server.
- On affected server, set full control permissions for LOCAL SERVICE and NETWORK SERVICE accounts on the BIN and DATA folders and let it replicate to all subfolders.
- Set all exchange and Microsoft Filtering management services to automatic and reboot the affected server.
- Run the enable-antimalwarescanning.ps1 script on the affected server.
- Set the DependOnService to include FMS on the MSEXCHANGETRANSPORT service in the registry (HKLM\SYSTEM\CurrentControlSet\services\MSExchangeTransport).
- Reboot the affected server one more time.
From this point, your Transport service should be dependent on FMS again, and both should be starting successfully. Now to keep it working, I would highly recommend limiting, if not removing, all 3rd party applications that are not Exchange Aware or appropriately set to exempt all Exchange processes, files and folders. If you are having disk issues, or connectivity issues to a SAN, those really need to be addressed, otherwise, eventually, the corruption is likely to return.