WMIC : where statement combined with a wildcard
Hi PDQ team,
recently, I have created a package to start/stop all Citrix services using WMIC command with a wildcard.
All have been tested before creating the package:
wmic service where "DisplayName like '%Citrix%' AND State = 'Running'" call stopservice
wmic service where "DisplayName like '%Citrix%'" call startservice
When sending the command to the remote machine using PDQ inventoryCommand tool, it works.
Deploying same from PDQ deploy package does not work with success code :
C:\Windows\AdminArsenal\PDQDeployRunner\service-1\exec>wmic service where "DisplayName like '' AND State = 'Running'" call stopservice
No Instance(s) Available.
As you can see above the '%Citrix%' wildcard was not passed over.
Can you please advise how to fix my script, so the wildcard does not get discarded?
That's because CMD is interpreting %Citrix% as a variable. You need to escape it to prevent that. I'm a bit rusty with CMD, but I think this is how you do it:
This is one of the MANY reasons why I switched to PowerShell.
It's amazing how stupid easy powershell makes some things. :)
Thanks for your advice, guys! The double %% escape suggestion by Colby worked well.
Indeed, PowerShell is the way to go for many bulk administrative tasks including services or computers restarts, but unfortunately, it does the job very rough without logging and verbosity and I never know if it actually worked or not.
Testing with PowerShell, it did restart most, but not all services and the really important which is responsible for VDA ICA port was skipped.
It might be helpful for someone with Citrix environment, so I will share my script that now works perfectly after the final correction:
<pre>NET stop PorticaService /y
WMICservice where "DisplayName like '%%Citrix%%' AND State = 'Running'" call stopservice
WMIC service where "DisplayName like '%%Citrix%%'" call startservice
Well, once you understand how to make it verbose and to log, you'll unlock doors to places you never knew you had the keys too.
This task is the perfect example.
It's important to know about the Write-Output cmdlet. It simply sends output to the console, and obeys the rules of the pipeline to some extent. You can send it's output to a file with a pipeline redirect
The next thing to know about Write-Output is that in conjunction with a Powershell step they capture that return in their wrapper script and put it into Output.log. So anytime you use Write-Output in a Powershell step, whatever is returned by it be it an object or manually entered text, it will be present in output.log after a deployment, successful or not.
So now that we know that, let's go back to your initial query in which Restart-Service was suggested as a cmdlet.
Powershell has some error handing (actually a lot, but this is a simple example) built in, one of those methods being the try/catch block. In your case we can do the following in a Powershell step:
That will log success, and in the event of a failure it will tell you it failed, and provide only the important bits of the error message.
I'll expand this a bit further in what should be a workable bit of code for a Powershell Step. Since you are doing a like comparison, we can do a bit of filtering and leverage the pipeline to give us a lot better logging.
It's late and I'm tired, and I have no way to test this at the exact moment, so I hope I used the $_ variable correctly in that Write-Output call, but it *should* be right!
Also note, I do not mean for this post to come across as putting anyone down, or belittling someone's ability, but I wanted to write it from the perspective of someone being brand new to Powershell with limited knowledge of the language, the pipeling, and how things work inside it, and also a little bit with how Powershell and PDQ interact with each other. That way if someone stumbles upon this from a Google search or similar, it's helpful to everyone.
Happy PDQ and Powershelling!
Please sign in to leave a comment.