So breaking down your error message you get the following PowerShell
error(s)
FINDSTR: Bad command line
Stop-Service : Cannot find any service with service name 'ColdFusion 9 - '.
At C:\Users\Administrator\Documents\servicerestart.ps1:7 char:1
+ Stop-Service -Name "ColdFusion 9 - $ServiceName"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (ColdFusion 9 - :String)
[Stop-Service], ServiceCommandException
+ FullyQualifiedErrorId :
NoServiceFoundForGivenName,Microsoft.PowerShell.Commands.StopServiceCommand
Start-Service : Cannot find any service with service name 'ColdFusion 9 - '.
At C:\Users\Administrator\Documents\servicerestart.ps1:8 char:1
+ Start-Service -Name "ColdFusion 9 - $ServiceName"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (ColdFusion 9 - :String)
[Start-Service], ServiceCommandException
+ FullyQualifiedErrorId :
NoServiceFoundForGivenName,Microsoft.PowerShell.Commands.StartServiceCommand
The first error 'FINDSTR: Bad command line' is saying that the call to
findstr in your script didn't have a valid argument. My guess is that 'findstr
$SITE' is the culprit and '$SITE' isn't actually set to anything hence it's
just calling findstr with no arguments. The remaining 2 errors are due to
it trying to restart the service 'ColdFusion 9 - ' with not service name at
the end because the first command failed to find a value. My advice to you
is to keep things simple and stop mixing files and technologies. You should
- Stop using findstr and focus on pure PowerShell cmdlets
- Get-Website produces an object so there's no reason to parse text as
an output making findstr or other string matching tools unneeded at all
- Matching strings can also be dangerous as sometimes strings don't
match the output you expect, a new entry might shift things to places
that
you weren't checking before
- By utilising PowerShell's object handling you shouldn't have to
match strings unless the object value itself is a string
- While it can be possible just embed the script contents in the
win_shell task instead of relying on the file being present on the remote
host
So what I would do is the following win_shell task
- name: restart website service
win_shell: |
$site = Get-Website -Name '*cdu*' | Where-Object {
$_.Bindings.Collection.bindingInformation -like '*:80:*' }
$serviceName = "ColdFusion 9 - {0}" -f $site.Name.Split(' ')[0]
Stop-Service -Name $serviceName
Start-Service -Name $serviceName
This will get any site that matches the name '*cdu*' and has a binding on
port 80. I'm not sure where the findstr production aspect comes here so if
you need any futher help filtering the object I would need to know more
information about the environment. I also used the yaml multiline string
format 'key: |' where the next indented lines are treated like a normal
string value. This pretty much enables you to inline the PowerShell script
in the task itself keeping the task closer to what it is actually doing.
On Monday, July 27, 2020 at 2:29:32 PM UTC+10 [email protected] wrote:
> Hello All,
>
> I have a PowerShell script that actually takes an argument and
> stops/starts a service based on the argument passed.
>
> The script works well on the Windows machine when running locally. But
> fails when attempted to run via Ansible playbook.
> I am posting a stack overflow link in the email which has full details of
> the issue.
>
>
> https://stackoverflow.com/questions/63100158/powershell-script-runs-locally-fine-but-throws-error-when-executed-via-ansibble?noredirect=1#comment111595021_63100158
> Any support on this would be much appreciable.
>
> Sorry for not including all the details on the email. I believe it is more
> readable on stack-overflow.
>
> Regards,
> Darshan
>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/08901d38-7b40-4288-bd7b-bdbbf70c0d08n%40googlegroups.com.
