SPSearchServiceApp exception creating defaultAccount credential in Get-TargetResource

[ronx]

Details of the scenario you try and problem that is occurring: During the last phase of my SP2016 DSC rollout, the SPSearchServiceApp resource is throwing an exception. The exception is:

PowerShell DSC resource MSFT_SPSearchServiceApp failed to execute Test-TargetResource functionality with error message: Exception calling ".ctor" with "2" argument(s): "Cannot process argument because the value of argument "userName" is not valid. Change the value of the "userName" argument and run the operation again."

I traced this down to line 94 in Get-TargetResource (the last line here):

$c = [Microsoft.Office.Server.Search.Administration.SearchContext]::GetContext($serviceApp.Name)
$sc = New-Object -TypeName Microsoft.Office.Server.Search.Administration.Content `
    -ArgumentList $c; 
$dummyPassword = ConvertTo-SecureString -String "-" -AsPlainText -Force 
$defaultAccount = New-Object -TypeName System.Management.Automation.PSCredential `
    -ArgumentList @($sc.DefaultGatheringAccount, $dummyPassword)

My resource block looks like this:

SPSearchServiceApp SearchServiceApp
{
    Name = 'Search Service Application'
    DatabaseName = 'SP_Search'
    DatabaseServer = 'SPSQL'
    ApplicationPool = $serviceAppPoolName
    DefaultContentAccessAccount = $ContentAccessAccount
    CloudIndex = $false
    PsDscRunAsCredential = $SPSetupAccount
    DependsOn = '[WaitForAll]WaitForMainServiceAppPool'
}

I'm going to try to replicate in my Azure lab to see if I get the same results, but wanted to go ahead and post this here to get some eyes on it in case I'm doing something wrong and/or there's an easy fix.

The DSC configuration that is using the resource:

Version of the Operating System and PowerShell the DSC Target Node is running: WS2012R2; PS 5.1.14409.1005

Version of the DSC module you're using: 1.6.0.0

[ronx]

I noticed some strange things in this farm that probably happened because of timing. I was using some WaitForAll resources to be able to run multiple installations in parallel. I think I kicked off my 2nd app server configuration too soon after APP01 where Central Admin is. Even though CA was running on APP01 like it should, the CentralAdministrationUrl property in the registry was pointing to APP02, and the AAM was redirecting there as well.

I manually deleted the Search Service Application via PS and am pushing the config again now (I had pushed an updated one while I was testing, so pushing the original now). It seems to be creating the search service properly now.

I'm going to test this again from start to finish in my lab this evening and will wait until APP01 gets to its WaitForAll ServersToJoinTheFarm before starting the rest of the configs. I'll report back later. Stay tuned.

[ronx]

Okay, so in my lab, I let the first app server pull its config and gave it plenty of time to run before publishing any other server configs. I did not encounter this error in my lab, so I'm pretty sure it was a timing issue. However, I still think some error checking would be beneficial here.

Because of the strange situation where I ended up with a misconfigured SSA, I tried to use DSC to start over by setting the SPSearchServiceApp Ensure to Absent and force-pushing to the problem server. However, since Test-TargetResource calls Get-TargetResource, and Get-TargetResource throws an exception when trying to create this credential from an incomplete service application, it never gets to the part where Ensure = Absent will attempt to remove the service.

I apologize that I'm not well versed enough in DSC resource coding to suggest a viable solution (yet), but I hope I've provided enough information for you guys to discuss a potential solution. Feel free to close this if you think it's a low percentage occurrence, but I think this will come up again because of the way the PLA scripts are currently being written.

[BrianFarnhill]

OK so I don't think this a timing issue - looking at the root issue I can see its got an issue pulling out the default content access account. Do you still have access to a broken environment or can we replicate it? I want to try to step through that get method and look at why it can't get a user name out of the service app

[ronx]

After I fixed the CentralAdmin stuff and manually deleted the SSA and let DSC re-provision it, it configured properly so I don't currently have a broken environment to play with. I might be able to replicate the issue by running the install on APP01 and APP02 again pretty close together. Since APP01 is doing the setup of all the central services and initializing the farm, APP02 should still finish first and cause all farm servers to think that APP02 is the Central Admin server even though RunCentralAdmin is set to $false for its SPFarm resource. I'm troubleshooting another issue in this environment at the moment, so I'm not sure when I'll be rolling back the servers to start over.

[andikrueger]

I'm able to reproduce this error in a SharePoint 2013 Farm. In the SPSearchServiceApp resource a new instance of PSCredential is created (Line 98):

 $defaultAccount = New-Object -TypeName System.Management.Automation.PSCredential `
                                         -ArgumentList @($sc.DefaultGatheringAccount, $dummyPassword)

The first argument of PSCredential "userName" equals $null. These are the contents of $sc:

$sc = New-Object -TypeName Microsoft.Office.Server.Search.Administration.Content `
                             -ArgumentList $c;

PS C:\Users\sp_admin\Documents> $sc
DefaultGatheringAccount    : 
ClientCertificateNames     : 
ContentSources             : 
ExtensionList              : 
CrawlRules                 : 
CrawlMappings              : 
Parent                     : Microsoft.Office.Server.Search.Administration.SearchContext
SearchApplication          : SearchServiceApplication Name=Search Service Application
ActiveDocuments            : 
RetryLimit                 : 
LotusNotesConfigured       : 
ListKnownLotusNotesServers : 

I did check the Search Service Application via central admin. The Search System Status is "All Errors".

Just a quick update: Running 'Initialize-SPResourceSecurity' did solve some of the "All Errors" messages and the DefaultGatheringAccount is no longer $null. This looks like a permission problem.

The DSC configuration that is using the resource: Version of the Operating System and PowerShell the DSC Target Node is running: WS2012R2; PS 5.1.14409.1012

Version of the DSC module you're using: 1.8.0.

[matthorgan]

Hi @andikrueger, did you find a solution for this issue in your testing? I tried running the Initialize-SPResourceSecurity command but I'm still running into the error:

Exception calling ".ctor" with "2" argument(s): "Cannot process argument because the value of argument "userName" is not valid. Change the value of the "userName" argument and run the operation again.

I'm using the same SPFarm account for all resources and this is the only one complaining with this error.

[andikrueger]

I did no further testing. I'm wondering, why there is an error in the end. If I'm not mistaken: This error can only occur, when a previous provisioning attempt of the Search Service Application did not succeed.

https://github.com/PowerShell/SharePointDsc/blob/eb52d57c419caabfa85f1c2b77009613227cb16c/Modules/SharePointDsc/DSCResources/MSFT_SPSearchServiceApp/MSFT_SPSearchServiceApp.psm1#L84-L100

Reviewing these lines of code, there has to be service application in place, that matches the name.

Can you try to delete the Search Service Application and re-provision it?

[matthorgan]

Hi @andikrueger, you're right - that's my fault for leaving my lab in a half-way provisioned state. When I run it on a clean build, it actually fails with The search service instance on this server is not online which is a different issue entirely. I'll troubleshoot and raise a separate issue if I can't get it fixed 👍

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[ykuijs]

Is this issue still existing? Or can we close the issue now and reopen if it occurs again in the future?

[snd3r]

I can reproduce the error on my farm. In the case that the script is run from the user sp_farm or sp_admin, then the data is get correctly, and if the script run from the user who is in the Farm Administrators group, but not the default admin account, this error occurs. Fixed by explicitly setting the access rights to the search service.

[ykuijs]

Issue is related to issue #837 for which I have implemented a fix in PR #838. This does not fix the entire issue, just prevents the error message thrown in the Get method.

We will have to investigate the cause of the failing creation of the service accounts.

[ykuijs]

Does anybody know exactly what permissions are required to properly provision the Search service application?

If so: We can add a check to make sure the account has the correct permissions before provisioning the service application.

[rurikon]

I'm not sure if this is related, but I noticed problems with database rights when creating the search service in SharePoint 2019. I have deleted Search Service Application many times and let DSC recreate it, but every time I get "Sorry, something went wrong. Exception from HRESULT: 0x80131904" in Central Administrator when accessing some of the pages, like content sources or crawl log.

Yesterday we found out it was an issue with database rights. When the search service is created, it seems to create a database role called SPSearchDBAdmin. The service account is supposed to have that role for the search service, analytics reporting, crawl store and links store databases. All the others are correct, but the account doesn't have that role in the search service database. Adding it will make the error disappear.

Creating the Search Service Application manually from Central Admin will set the roles correctly.

My settings:

SPSearchServiceApp SearchServiceApp { Name = "Search Service Application" DatabaseName = "Search_Service" ApplicationPool = $serviceAppPoolName DefaultContentAccessAccount = $SearchCrawlAccount Ensure = "Present" PsDscRunAsCredential = $SetupAccount }