Solving Configuration Failures with non-admin Nodes in FAST Search for SharePoint

I recently had kind of a tough time getting a non-admin FAST server configured successfully in a pretty vanilla environment, so I wanted to pass on some tips and tricks that got me past it.  In FAST you basically have two types of servers when you are doing a multiple server deployment – your admin server and non-admin servers.  The non-admin servers are typically the ones doing the indexing and searching, and they are the ones that you add to “rows” and “columns” in FAST-speak.

You can follow the step-by-step instructions for installing a farm like this at  In short though, you install and configure your FAST admin server, and then install and configure each non-admin server.  What I was finding was that when I got to the non-admin server, installation went fine but the configuration wizard always failed.  After a lot of trial and error and few suggestions from other folks, I managed to get it configured successfully.  Here’s a checklist that I would run through if the configuration wizard fails on your non-admin server:

1.            Make sure you have Windows Firewall enabled on both the admin and non-admin servers.  Yes, I do mean “enabled”, not “disabled”.  We count on it being on when we’re doing some of the configuration and if it isn’t there then it can cause problems.  I often get lazy and just turn off the Windows Firewall when I’m building out a lab environment, but this is a case where having it off will just cause problems.

2.            Don’t save your Xml deployment file directly from Visual Studio.  If you want to create it in there that’s fine, but copy it and save it notepad.  Visual Studio adds a character to the start of the file that is invisible and unreadable and causes other issues when your non-admin server tries to use the file.

3.            If you install the non-admin server after following steps 1 and 2 and it still fails (as happened to me), then try opening PowerShell and running the Set-FASTSearchIPSec –Create cmdlet.  If this fails it likely means that your deployment.xml file has the extraneous character in it that I mentioned in step 2.  After you do this just try running the configuration wizard again.

After doing steps 1, 2 and 3 I was able to successfully install and configure the non-admin node in my FAST farm.

Comments (6)

  1. alexandrad9x says:

  2. Arby says:

    Steve, when configuring a non-admin FAST server, I get the error:

    PM Error CallExecutable – An error occurred while executing binary C:WindowsSystem32net.exe. Return code is not 0.

    I saved the deployment.xml file on the admin server as ANSI and ran "Set-FASTSearchIPSec -create" on the non-admin server I'm adding. No errors. But when I run the Post install config utility, I get the above error.

    I've also tried saving the file in notepad as UTF-8, but in that case I get an error from the "Set-FASTSearchIPSec -create"  cmdlt:

    Set-FASTSearchIPSec : XML Validation error: Data at the root level is invalid.

    So I don't know where to go from here. Can you advise how I might get past this?

  3. Daniel Webster says:

    Open the deployment.xml in a hex editor and remove the BOM at the beginning of the file.

    Also try installing from commandline. The default logging there is debug mode and the log files actually contain useful info about where it fails. See my blog at…/danielwebster.

  4. John Perigo says:

    Thanks so much, Daniel! The BOM was the cause of my problem.

  5. James Hatfield says:

    I recently came across this issue and used this technote along my way to fixing it. It didn't fix my issue and, on the face of it, what I think did fix it seems stupid but I'm a complete noob so I'm going to add this in case it helps other noobs. Most other technotes got this far and stopped, so I guess people fix their issues and don't post back further resolutions.

    The mistake I made was doing the Admin server config, getting errors when doing non config, having to re-do the Admin server and at this point had a tidy up of the files I had used so far. In doing so, I moved the deploymnet.xml file inadvertently away from the location originally specified. As I said, I'm a noob, but I didn't realise the non-Admin config was still looking for the deployment file in the original location. When I realised I had snce moved it, I put it back and hey presto…. I'll say again, nooby-stuff. But in the hope it saved someone else from going mad in the future I'm happy to lay my mistakes bare!

  6. asdf says:

Skip to main content