OK so here is my agent prodedure. It is the 3rd of 3 procedures in a job. The first two work perfect. When I run this procedure Kaseya says it was successful but then when i check in services.msc, the service is not there.
If I run the same commands in command prompt manually they work and the service is installed.
Any help would be greatly appreciated.
The procedure did run successfully - it just didn't do what you expected it to do. For example, the command shell command successfully sent to the system - but that doesn't mean that the command returned the results you wanted it to. Taking a quick look at your AP, I'd guess one place you may be running into an issue is with the command you're sending over. You have nested double quotes, which isn't always interpreted as you want them to be. Change the inner quotes to single quotes. In step 3, that would look like "'C:\Program Files...' -service start" rather than ""C:\Program Files..." -service start" (do the same in step 5).
For testing, you might try using just a couple of the steps at a time. Get those couple of lines working successfully (where upon examination of the endpoint, you see what you expect to see) and then add additional lines. This makes troubleshooting the procedure much easier.
You could also add in some checks along the way. You're requesting the service be started. You might then add a step to verify the service in question has started. The executeShellCommand is not "smart" in that it will send the command but doesn't verify what you asked was actually accomplished. The process is complete when the command is sent; in many cases, an error returned by the cmdShell does not cause the actual procedure to fail. You could add an echo or output the results of the command to a file or to a global variable (executeShellCommandToVariable) and then write that information to the agent procedure log to see what the endpoint is actually returning.
Hope that helps get you going in the right direction.
Thanks so much I will give this a try when i have some time today.
Can you explain your last paragraph more? I am sort of new to kaseya and do not know how to write code to output the errors or a log. Thank you!
Let's look at the command to view a list of started services. In a command window on a local machine, you'd simply type:
To output the results of that command to a file, in a Command window on the local machine you might type:
net start > c:\services.txt
This would create a text file on your local c:\ drive with the results of the command request. It will type into that .txt file whatever the results of your command were, whether it's the information you expected or an error.
To do the same thing via a Kaseya AP, you would use the executeShellCommand() step. Because the <, >, and # are reserved characters, you must enter them twice when you want them to actually be interpreted as part of a cmd shell command (or anywhere else EXCEPT when being used to call a variable). Therefore, using the executeShellCommand() step, the actual command you'd enter into your script would be:
net start >> c:\services.txt
If instead of creating a text file, you wanted to just write the info into the Agent Procedure log, you would use the executeShellCommandToVariable() step. Your entry would just be:
but the output would be gathered into the variable called #global:cmdresults#. You could then use the writeProcedureLogEntry() step to post the output into the AP log. Instead of typing in a random message into the writeProcedureLogEntry() step, you would type in #global:cmdresults#. This will result in the AP log being updated with the output of the net start command.
However, with all of that said, I wouldn't bother trying to work all of this detail in until you get the most basic form of the procedure working. If you try to add in a bunch of complexity, you're going to spend a lot of time troubleshooting. Get the basics working, then add the fluff.
Ok so I did what you said. I split up the procedures so each step was its own procedure...Still not installing the service. I also tried exporting the results to .txt....it creates the txt file but there is nothing in it. its blank.
There is nothing in the event logs either
What is happening on the endpoint when you run this from cmd prompt and the service is then installed?
Are there any dialog boxes, windows, prompts, user interaction required?
The below is a guess as to what is trying to be achieved here - let me know if I am incorrect in my assumptions.
It seems, that your other procedures may be laying down the framework for graylog collector on devices.
To get a better understanding, you have already silently deployed the installer at this point and are trying to register the system service which is the step that we are stuck on?
Use the Windows installer, it can be run interactively:
or in silent mode with:
$ collector_sidecar_installer.exe /S
Edit C:\Program Files\graylog\collector-sidecar\collector_sidecar.yml and register the system service:
$ C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe -service install
$ C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe -service start
Ok so the first procedure installs a program called nxlog and then disables the service
The second procedure installs sidecar.
The third procedure is supposed to install the sidecar service
The forth procedure starts the sidecar service
If I run these commands manually below they work perfectly. There are no prompts or interaction involved. Type the command and press enter and its done 1 second later.
Now for some reason when I tried running all of these procedures on a fresh PC the nxlog service wasnt installing but sidecar was. I will post all of my prodedures here for you to take a look.
C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe -service install
C:\Program Files\graylog\collector-sidecar\graylog-collector-sidecar.exe -service start
Attached are images of the procedures. I did not post #3 since procedure 3 is essentially procedure 4 and 5 combined. Procedure 3 is not needed when 4 and 5 are being used. I know its a bit confusing but once i get this working I will get it cleaned up.
I am going to also try to write a windows batch file to complete this. wish me luck LOL
Bump. ANY help is greatly appreciated.
I think you're quotes were correct in the original. I've never had issues with the "double double quote" at the beginning, but what Brande was stating was replace the inner set of double quotes with a single quote.
Whichever quote you decide to use, there still needs to be a quote there.
Assuming your original quoting was correct, that puts you back to square one...except capturing the output as Brande mentioned. This is a critical step for troubleshooting APs.
How did your batch script go? Did you execute for a path without spaces, eliminating the need for any quotes in AP? If your batch works, try executing it using executeShellCommandToVariable(c:\test.bat) and writing the output, #global:cmdresults#, to the procedure log. If I were debugging this, I would make the very first line of the batch echo text, just to ensure the batch is at least starting and I'm getting some output.
I'm not sure how much more help anyone on the forum can be without actually logging in and getting their hands on it. Just a couple things my experience has taught me, YMMV:
I've had better luck executing things with hstart.exe to force an elevated command shell. It shouldn't be necessary, but it guarantees that every command is executed with elevated permissions. I will say, quoting inside hstart commands can be tricky. Here is an example with quoted arguments changing a service logon account:
Keep in mind, the outer most quotes are added by the AP UI. After the /SILENT switch, the command to execute goes in as a large, quoted, single argument, and you can insert quotes inside that one argument. I know that is confusing to read, so hopefully the picture makes it easy enough.
When we tried to do the sc.exe command directly from the AP on servers that had UAC disabled, it still didn't work for us. Once we used hstart to launch it as elevated, it worked fine. Necessary or not, it has become our default.
Since troubleshooting and debugging APs is so cumbersome and slow, my procedures almost always follow this pattern:
1) Set necessary variables (kworking directory, target directory etc.)
2) write files down to kworking necessary for the procedure
3) execute a script (batch for VERY simple things, but generally PowerShell)
4) Get output of script
5) Write output to procedure log.
This allows me to to the bulk of the work inside the PowerShell script. This allows me to test and debug a PowerShell script, which is significantly faster than APs. I normally output to a log file directly from the PowerShell script, then grab the contents of the log file in the AP.
Here is an example of using hstart to launch a PowerShell script that has quoted arguments:
I hope this helps and good luck.