Daniel Reed
.NET, SharePoint and Graphic Design
Posted by mirata on Jun 11, 2011 in SharePoint | 2 Comments

I’m making this post because there was no useful information on the Internet about this specific problem. If it helps someone out, please let me know.

Last week we encountered a problem with SharePoint 2010 and FAST Search. In our virtual environments in the office, everything would go fine. The developers and infrastructure guys could install it from the GUI and powershell with no problems. But on the client site, installation would fail every time.

Naturally this leads to suspicion of site-specific nuanaces that lots of places have. Maybe some strange group policy or Active Directory setting. Possibly some sort of firewall setting. But what? A support ticket was raised with Microsoft to investigate the problem, and it was escalated to the developers of the FAST engine, but to no avail. They couldn’t seem to find out what the problem was.


Trawling through the logs, I finally came across what seemed to be the offending line. But the message was less than useful.

Exception - Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.ExecutorException: Command returned non-zero!
   at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.Executor.CheckReturnCode(Int32 returnCode)
   at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.Executor.ExecuteCommand(String command, String arguments, String workingDirectory, Int32 timeout, ILogWriter logWriter)
   at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Utility.Executor.ExecuteCommand(String command, Int32 timeout, ILogWriter logWriter)
   at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Configuration.ConfigurationExecutor.RunExternalConfigurationSteps()
   at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Cmdlets.SetFastSearchServer.RunConfigurationPipeline()
   at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Cmdlets.SetFastSearchServer.ProcessRecord()

Thankfully, the error message was at least useful to indicate the namespace of the error, so I tracked down the associated DLL. I then proceeded to use .NET Reflector to disassemble the code and search for the problem.

Through lots of searching and click-throughs with Reflector I was able to determine that there was only one place it could be failing to produce this error. The DLL was running the following process command:

mstdcsetup.exe -admin

And the associated error code was non-zero, meaning an error. We tried running the command ourselves but received an error.

Error Unable to get a handle to the Transaction Manager on this machine. (8004d01b)

After a bit of research, I found that MSDTC refers to Microsoft’s Distributed Transaction Coordinator, which can be accessed from Component Services. I went to component services and it failed with an error message! So.. An error in Windows. No wonder FAST installation is failing. Time to tweak some settings.. We managed to find a settings page and tried changing the security level of communication.

That seemed to make it work from the command line.

But if we rebooted, the setting would fail again. Eventually we discovered that it was not specifically the reboot, but the fact that group policy is applied. We tested this theory by making MSDTC work, then apply group policy. MSDTC would then fail again.

The Solution

So – everything was pointing to a group policy issue. We managed to talk to the internal IT guys and discovered that only specific accounts were allowed to run MSTDC. We added the NETWORK SERVICE account, and hey presto – a working FAST installation!

  • Outstanding post, I conceive blog owners should larn a lot from this weblog its rattling user friendly .

  • Thank you. I have struggled with this issue now for two days and got to the same point as you. That the issue was related to the MSDTC.
    But I hadn’t got the idea to change the security setting for the DTC.
    Now it is working.


Leave a comment

Spam Protection by WP-SpamFree