$PSCredential- round two

Jonathan.Engstrom

Looking at your example, I am not sure how it could work. Your TargetOU is not in distinguished name format. Should be something like "'CN='Users',DN='Domain',DN='Test'". Did you move the computer object from one OU to another? I am curious about the results there.

rhessinger

Hi @Jonathan-Engstrom ,

The $TargetOU was intentionally malformed to force a configuration drift. In the Configure property, it did not matter because I did not actually run the MoveTo operation. That was the only thing I didn't actually do. But according to your error:

Exception calling "FindAll" with "0" argument(s): "An operations error occurred.
"
You cannot call a method on a null-valued expression.`.

The only line that could have caused that error was ([adsisearcher]"samaccountname=$($ServerName)$").FindOne(). I actually decompiled the MoveTo method from Microsoft to verify that it did not call a FindAll or FindOne method. I did verify that Microsoft calls FindAll from within FindOne by decompiling FindOne.

If you are trying to verify which line it actually threw the error on, you could use Write-Host in your PowerShell between each line and enable Debug and Verbose on your PSEnsure operation. The execution log will then show you the Write-Host outputs.

Currently, my best guess is that the machine and user combination that you are remotely attempting to run this on either does not have access to query/update the domain or does not have adsisearcher library installed on that machine for that user.

Thanks,
Rich

Jonathan.Engstrom

Strange. I am running the code locally on the target server in powershell, and it is working flawlessly. The FindOne and FindAll work to limit the machine. Intellisense also auto completes these, so they are present and working.

([adsisearcher]"samaccountname=$($env:computername)$").FindOne()

works fine and returns the result on the sql machine I am targeting the psensure configuration on. I am not changing the code or machine I am testing on; changing anything or introducing variables would not constitute a very scientific observation. Same code, same machine. When run locally, works fine. When run in Otter, it does not work. I am guessing it is how Otter formats things sometimes; that would be my guess. But Otter is not handling this line of code. and it would help to understand why.

rhessinger

Hi @Jonathan-Engstrom ,

I have noticed the $ServerName uses the name of my server configured in Otter, not the actual computer name. Have you tried running the remediation using $env.computername instead of $ServerName? Or can you verify the Server Name in Otter matches the computers name?

Thanks,
Rich

Jonathan.Engstrom

That's a good idea, but I actually started off using the $env:computername and switched to $servername thinking that maybe somehow Otter wasn't using the $env:computername variable, but it didn't make any difference.

rhessinger

Hi @Jonathan-Engstrom ,

What version of PowerShell do you have installed on your SQL server? I'm running 5.1.18362.628.

Thanks,
Rich

Jonathan.Engstrom

It's a 2016 Server, so it comes preinstalled with 5.1. 5.1.14393.3471 is the specific version.

atripp

@Jonathan-Engstrom said in $PSCredential- round two:

Same code, same machine.

Same user?

@Jonathan-Engstrom said in $PSCredential- round two:

it would help to understand why.

FYI -- Otter doesn't format PowerShell; it parses the PowerShell script (using MIcrosoft's parser), looks for variable tokens, and "injects" a variable into the runtime if there's a matching variable.

The interactive Powershell Host (which you're using, ps.exe) also does things differently. There's a ton of layers-upon-layers with active directory. so it'll take some trial/error to find out what's happening.

Jonathan.Engstrom

Yes, same user. Like I said, I have taken great care to eliminate variables trying to understand what is going on.

rhessinger

Hi @Jonathan-Engstrom ,

Have you tried wrapping your PSEnsure inside of a with block to force everything to run as a specific Resource Credential?

Example using a resource credential named AdAdminResourceCredentials:

with credentials = AdAdminResourceCredentials
{
	PSEnsure
	(
	    Key: RSHStuff,
	    Value: True,
	    Collect: >>

	        $ErrorActionPreference = 'SilentlyContinue'
	        $TargetOU = 'Users'
	        $Value = (Get-ADComputer -Identity $env:COMPUTERNAME).DistinguishedName -match $TargetOU
	        $CurrentValue = (Get-ADComputer -Identity $env:COMPUTERNAME).DistinguishedName
	        ((($Value -eq $true) -and (($env:COMPUTERNAME) -match 'MyComputerName')) -or ($env:COMPUTERNAME -notmatch 'MyComputerName')) 
	        >>,
	    Configure: >>
	                
	        $samAccountName = $ServerName
	        $newOU = [adsi]"LDAP://$TargetOU"
	        $comp= ([adsisearcher]"samaccountname=$($ServerName)$").FindOne()
	        Write-Host $comp.GetDirectoryEntry()
	                                
	                                >>,
	    Debug: true,
	    Verbose: true
	);
}

Please note that my PowerShell in collect and configure is not 1 to 1 with yours, I would replace my PowerShell script with yours in those two properties.

I also was talking with one of the solutions architects on a similar Otter execution question. He suggested that sometimes it is easier to figure out PowerShell issues by running PSExec under the local system account and attempting to run your PowerShell commands that way. It will sometimes show you more detailed errors than Otter. I would try running PSExec -s powershell, which will open up a PowerShell console as the local system account, and then typing in the lines of PowerShell you have had trouble with.

Thanks,
Rich