PowerShell to Deploy an SSA Across Multiple Servers (v2.0)

A few years back, I published a PowerShell script to deploy a SharePoint Search Service Application across multiple servers, but it admittedly had a few quirks in regards to Index path location… until now.

Below, I’ve attached the new/updated version 2.0 of the deploy script (and will also upload to the TechNet Scripts center soon) and have a screen shot below. From the screen shot, notice the prompts in yellow that occurred when I configured a path for my Index that did not exist. With confirmation, the script will then create any paths that did not exist on a remote or local servers.


Also, this easily handles the provisioning single server deployments, multi-server SSAs, and even high density scenarios with multiple Index replicas per server. Like in the previous version of the script, all you need to do is edit the configuration at the top of script to fit your needs, save it, and then run (but in this version, you can run it on ANY server in the farm.

And, I want to thank Jon Waite for a contribution on this script... now, you can also configure the Default Content Access Account (aka: the "crawl account"). After the SSA is fully provisioned, you'll get prompted for the credentials.

I hope this help...

As always, this comes with my standard disclaimer: 

ALL information in this blog is provided "AS IS" with no warranties and confers no rights. This blog does not represent the thoughts, intentions, plans or strategies of my employer. All content is solely my opinion and provided with a best effort to be based in reality. All examples, code samples, demonstrations, or anything resembling a “how-to” are provided "AS IS" without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose. Inappropriate comments will be deleted at the authors discretion. And yes, the spelling of strategery was intentional. 


Comments (7)

  1. The script works perfectly. Thank you for making it Brian. You rock!



  2. bspender says:

    Just found "contosoadminAccount" hardcoded in the part that changes the service account. I fixed the script (e.g. replace that with $ssaConfig.srchServiceAccount  ) and re-uploaded it here…

  3. fbrunken says:

    Awesome script! The script works just great.

  4. SPCHOBO says:

    Thank you very much for this awesome script!

  5. Bobby Lawrence says:

    Brian – Great script. I have a question: Can you point me to the Best Practice literature that upholds this warning? “FarmServiceInstanceOnline Warning Outside of best practices: XXXXAPP1QA, XXXXWFE1QA, XXXXAPP2QA, XXXXWFE2QA
    * WFE Service Instance is on a Search server (*acceptable on Crawlers)
    * SQ&SS Instance is on a server without a QPC
    – XXXXAPP2QA, XXXXAPP1QA” I have not been able to find any.

    1. bspender says:

      This isn’t documented anywhere as a best practice… but I’ve had to troubleshoot enough issues and worked with many others in the Search community to be comfortable making this claim. We also mention this in our Ignite 2015 presentation ( https://channel9.msdn.com/Events/Ignite/2015/BRK3176 ).

      In a nutshell, the SQ&SS [in SP2013] essentially acts as a shim in front of the QPC and provides backwards compatibility for the Web Application to invoke Search (via the SearchService.svc WCF endpoint). The SQ&SS then routes queries to the least busy QPC. In SP2013/16, the SQ&SS was not intended to be managed by users – instead, the system automatically starts one automatically on a QPC and it really should not be running anywhere else.

      (*in SP2010, the SQ&SS was effectively the Query Component and the QC was more closely analogous to the Index Component in SP2013)

  6. Thank you for sharing Brian!

Skip to main content