SPSearchServiceApp exception creating defaultAccount credential in Get-TargetResource

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

[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.

[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 👍