lunanat
asked on
Powershell Invoke-Command headache
Writing a powershell script that I can schedule to run automagically, every couple weeks. Script is to enumerate all servers on the network, enumerate services running with domain accounts, generate a new password, update AD and then update the service.
Through much troubleshooting I've basically identified that one line quite plainly isn't running. Yet when I do it manually it does run.
I have tried the invocations from two methods, which I assume are transparent, but tested anyways:
So, here we go. New-Password is a string generator that I wrote to meet my password requirements. The line which I believe is not working correctly is line 11.
I'm probably doing something stupid. But I can't seem to see it.
Interestingly, the return output for the commands is (apart from the startservice method) entirely what I would expect to see.
It's being tested on a service with a manual startup, presently stopped.
WMI response for the change command is status code 0 (worked?!)
WMI response for the stop command is status code 5 (cannot accept control). That said, if I start the service, it returns status code 0.
WMI response for the start command is status code 15 (invalid login)
If I manually type the new password into the service via the services.msc I am able to start the service
Through much troubleshooting I've basically identified that one line quite plainly isn't running. Yet when I do it manually it does run.
I have tried the invocations from two methods, which I assume are transparent, but tested anyways:
$ses=New-PSSession -ComputerName $service.SystemName
Invoke-Command -Session $ses -ScriptBlock {}
#and
Invoke-Command -ComputerName $service.SystemName -ScriptBlock {}
So, here we go. New-Password is a string generator that I wrote to meet my password requirements. The line which I believe is not working correctly is line 11.
foreach ($service in $managerservices){
Write-Verbose "Beginning Service $($service.name)"
$password = New-Password 10
$secureADpassword = ConvertTo-SecureString -String $password -AsPlainText -force
Set-ADAccountPassword -Identity $service.StartName.Split("\")[1] -NewPassword $secureADpassword -reset
Write-Verbose "Invoking on $($service.SystemName)"
Invoke-Command -ComputerName $Service.SystemName -ScriptBlock {
param($service,$password)
$secureServicepassword= ConvertTo-SecureString -String $password -Force -AsPlainText;
$newservice=get-wmiobject win32_service -filter "name='$($service.name)'";
$newservice.Change($null,$null,$null,$null,$null,$null,$newservice.StartName,$secureServicepassword,$null,$null,$null);#THIS LINE DOES NOT WORK
$newservice.StopService();
$newservice.StartService();
} -ArgumentList $service,$password
write-verbose "Adding $($service.Name) to array"
$servlog = New-Object System.Object
$servlog | add-member -type NoteProperty -name Server -value $service.SystemName
$servlog | add-member -type NoteProperty -name Service -value $service.Name
$servlog | add-member -type NoteProperty -name Username -value $service.StartName
$servlog | add-member -type NoteProperty -name Password -value $password
$servicesmanaged+=$servlog;
$MASTERLIST +=$servlog
}
I'm probably doing something stupid. But I can't seem to see it.
Interestingly, the return output for the commands is (apart from the startservice method) entirely what I would expect to see.
It's being tested on a service with a manual startup, presently stopped.
WMI response for the change command is status code 0 (worked?!)
WMI response for the stop command is status code 5 (cannot accept control). That said, if I start the service, it returns status code 0.
WMI response for the start command is status code 15 (invalid login)
If I manually type the new password into the service via the services.msc I am able to start the service
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
... which means just use $password in the WMI call instead of $secureServicepassword.
ASKER
I guess that's what I get for expecting Microsoft to be secure. Thanks!