none
Exception has been thrown while reading SSA via PowerShell

    Question

  • Hi,

    SharePoint Server standard SP1 updated to June 2012 CU, 2 (WFE + App) servers + 1 DB server. I created Search Service Application (SSA) using Central Admin. Once created the SSA behaves pretty alright. It crawls and the searchadmin page is also normal.

    But when I try to read the SSA via PowerShell:

    $mySSA = Get-SPEnterpriseSearchServiceApplication -Identity "My Search Service App Name"

    I get:

    format-default : Exception has been thrown by the target of an invocation.
     
    + CategoryInfo     :  NotSpecified:  (:) [format-default], TargetInvocationException
     
    + FullyQualifiedErrorId : System.Reflection.TargetInovcationException,Microsoft.PowerShell.Commands.FormatDefaultCommand

    No relevant clue from the App error event log. I can run other PowerShell commandlets just fine. For example Get-SPWebApplication.


    Thanks, Soumya | MCITP, SharePoint 2010

    Thursday, July 26, 2012 2:25 AM

Answers

  • You are working with Application pools right? ... and have a dedicated application pool for your search service application right?

    Then it looks like if your current user which is logged in into the Windows OS isn´t the correct user. Try to login with the user account which is able to manage the application pool, this should work.

    • Proposed as answer by Bastian_W Wednesday, August 01, 2012 6:37 PM
    • Marked as answer by Soumya B Thursday, August 02, 2012 5:08 AM
    Wednesday, August 01, 2012 6:37 PM

All replies

  • Do you have multiple Search Service Applications? If there is only one in the farm, you can run Get-SPEnterpriseSearchServiceApplication with no parameters to return it. 

    Actually, even if you have more than one, what happens when you simply run:

    Get-SPEnterpriseSearchServiceApplication
    ?

    Jason Warren
    Infrastructure Specialist

    Thursday, July 26, 2012 10:03 PM
  • Thanks Jason. Yeah I know that is possible. Same results. If you do Get-SPServiceApplications, the the search service application's GUID is returned. However if I do:

    Get-SPServiceApplication -Identity "Above Guid" same exception.

    So bottom line is no matter how I try it, as soon as I want to read the search service application in a PowerShell variable I get the same exception.


    Thanks, Soumya | MCITP, SharePoint 2010

    Friday, July 27, 2012 3:25 PM
  • What about:

    $mySSA = Get-SPEnterpriseSearchServiceApplication


    Jason Warren
    Infrastructure Specialist

    Friday, July 27, 2012 3:45 PM
  • Hi,

    Oh yeah. Same error.


    Thanks, Soumya | MCITP, SharePoint 2010

    Friday, July 27, 2012 4:46 PM
  • You are working with Application pools right? ... and have a dedicated application pool for your search service application right?

    Then it looks like if your current user which is logged in into the Windows OS isn´t the correct user. Try to login with the user account which is able to manage the application pool, this should work.

    • Proposed as answer by Bastian_W Wednesday, August 01, 2012 6:37 PM
    • Marked as answer by Soumya B Thursday, August 02, 2012 5:08 AM
    Wednesday, August 01, 2012 6:37 PM
  • Hi,

    You are working with Application pools right? Right

     have a dedicated application pool for your search service application right? Right.

    OK about to give it a shot. But did not see the same behavior in many other farms that I provisioned. Interesting. Will keep posted.


    Thanks, Soumya | MCITP, SharePoint 2010

    Thursday, August 02, 2012 4:33 AM
  • Hi,

    You are spot on Bastian. The search service account works just fine. Not only that, the farm account also works just fine. It is the setup account that I was trying so far that did not work. Although the setup account is also a farm admin.


    Thanks, Soumya | MCITP, SharePoint 2010

    Thursday, August 02, 2012 5:08 AM
  • You could also go to Service Applications, highlight the Search Service application and click Administrators, then add yourself as an administrator.  The script will run fine after that.  I was having the same issue and this resolved it.
    Thursday, January 23, 2014 7:49 PM
  • Granting an administrative account ShellAdmin rights as Matthew suggests is a better approach from a security best practices POV than logging in as the application pool identity.

    Thursday, March 27, 2014 10:35 PM
  • The account used in the powershell invite does not have enought SQL rights on the Search Databases... If you usually use the farm account and today try with the setup/install account you encounter this issue.

    Kind regards

    Saturday, October 22, 2016 1:25 PM