I'm trying to use dnscmd.exe in a procedure on Server 2008 R2, and it seems like no matter what I do, I get zero output from the command. It doesn't even create the output file from the ">>" redirection.
I tried taking a copy of the prebuilt "Force DNS Scavenging" script, modified it the bare minimum, to use "/enumrecords", same result.
I tried changing the command to "%windir%\system32\finger.exe administrator". Same result. The command appears to succeed, no errors, but zero output. I have other scripts that do produce output.
I'm running these as User or System, BTW. it doesn't seem to matter. It's like some commands will produce output for the Agent, some won't, and that that.
The redirecttion being used is ">> #vAgentConfiguration.AgentTempDir#\results.txt". I've confirmed that the directory is valid. An "execute command" will create an empty file there, I've confirmed that. An straight "execute" won't even do that.
I haven't done much scripting since K2, and things have certainly changed. I frankly don't even care if I get a separate log file -- this is a short-tem need, I just want the output!
If you run the command manually, does it create the file (of course, hard-coding in the temporary folder)?
If the temp folder has a space in the name (e.g. c:\kaseya temp folder) you'll need to run the command like
dnscmd.exe >> "C:\kaseya temp folder\output.txt"
Make sure you're not encapsulating the entire command in quotes, just the target folder and file name.
What I do is copy the exact command that you want to use and write it to the Agent Procedure log, run the script and look at the log entry. Try and run that same output in the log entry with the same credentials on the machine you want to do the command on and see what you get.
If it works that it's more then likely the Agent credentials, alternatively instead of using the "Execute Shell command" try using the "Execute File" option, it will give you more information why the command could not run in the Agent Procedure log.
Remember if used correctly the Agent Procedure log is your friend :)
Ben posed a really good question. I would first ensure that you are gathering output. If you are not even creating an outputfile with a redirection (>>) then I would wonder about the security context you're in while on the server.
Check the agent credentials.
Check UAC on the remote server.
Ensure that you can log into the machine with the credentials used for the Agent and execute the command and still create the outputfile as that account. (Or alternatively, Run-As a cmd.exe session as the identity of your agent while you're logged in with your account)
Once you have your output working there are several options for returning the data to Kaseya. You'll need to evaluate your needs to see which fits you best.
How do you want to work with this data?
Just simple reporting? (Get Variable)
Advanced BI? (Get File and parse locally)
Evaluating the contents to provide additional action? (Get Variable)
Or an alternative that I'm now exploring. Using a generic web service to listen for Kaseya agents and using GetURL to communicate back home to my web service. Using the results captured by Get URL just as return_status
I tried to respond an hour ago, I think it got dropped. Not liking this new web site a lot.
How exactly do you get your output into the log, HardKnoX? AFAIK, you have to redirect the command output to temporary scratch file, copy that file into a variable, and write the file to the log. Or you can copy the file to the agent get files area, and open it from there. What a pain in the butt. Is there no way to just direct output to the log??
Yes, I've tried the command manually on a target server. It works. I've confirmed write access to the file. The same script, same server with different commands (e.g., netsh) works -- I get output.
And this is interesting: the dnscmd works properly on a script on Server 2003, but not on Server 2008. The one on 2003 is in a different directory, Programs Files\Support Tools. I'm starting to think this is specific to dnscmd on Server 2008.
I just want to run the command and check the output. It would be _nice_ if I could send output to Monitor somehow, sometimes, for ongoing monitoring that Monitor doesn't do well, but that's another story.
Oh, and is output redirection the same for Execute File as for Execute Shell Comand?
Look again at UAC (User Account Control). Can you confirm that it is disabled on the Agent's server? The fact that it is only a problem on 2008 really makes me wonder...
You could create a simple .NET app wrapped aroud:
To put the data in the Event Viewer, then use the Log Parser to pluck out the information.
You would, of course, use "Send File" to get the current copy of the .NET app to the Agent's server.
Yes it works was not sure but I tried it with a simple dir command using %COMSPEC% as the file to execute and "/f /c DIR c:\ >>C:\temp\dir.log" (without the quotes) as the arguments (switches) to pass to the executable.
The main reason to try your "Execute Shell Command" command under the "Execute File" is to see if it gives you a different result as the "Execute Shell Command" is not giving you any output.
Just a reminder that if you are using Script, Managed or Kaseya variables make sure to copy your command that you want to execute into the "Write Procedure/Script Log Entry" this will give you the exact command that should have executed and it will help you debug syntax or typo issues.
No way in h*** am I going to disable UAC on a client's server. Not happenin', dude!
for win server 2k8 r2 i find that using path to the exe and path to the output file helps at times
I personally disable UAC on every system I touch along with the useless Interactive services notification. I got along fine without it after using MS Windows for 17 years when it was introduced in Vista.
With that said, UAC has nothing to do with this.
When you are running this command with a standard 'execute shell command' operation unless you set it to 'Execute as user' it runs as the system account and will not be affected by UAC.
Based on your posts:
You can run dnscmd.exe on this exact server where the script is failing and you can successfully direct it's output to a file as follows when running in a shell manually:
dnscmd.exe > "C:\temporary folder\tempfile.txt"
Again, make sure to pay attention to the quotes. It's not "dnscmd.exe > C:\temporary folder\tempfile.txt" and it is not dnscmd.exe ">C:\temporary folder\tempfile.txt"
Despite this working successfully being run manually, running exactly that in a script via 'execute shell command' running as system is failing, and no actual output file is created?
Try a new command manually... "Echo TEST > "C:\tempfolder\tempfile.txt"
Does it create the file?
Try it in a script. Is it created?
Now try it with the temp folder variable (echo TEST > "#vagentconfiguration.agenttempdir#\test").
Obviously in the script itself use >>.
Is the file still created?
It should be.
Anyway, now you need to simulate running a command yourself as the system account to further troubleshoot.
Here's how to do that very easily...
Download psexec.exe to the sysem in question. Run psexec -s cmd.exe.
Wala! Shell access as the system account.
Try running your command here and see if you get your file created. If it is not created, it might be an issue related to the SYSTEM account's default shell environment variables.
I personally don't even have dnscmd.exe loaded on my 2008 R2 server and it looks like I'd have to add it from my install CD or somewhere under Roles/Features.
Now that you know how to run commands as the system account, you can pretty much take Kaseya out of the picture. I've had to do this in the past several times myself, especially with the Java silent installer procedures I wrote.
I wonder if you need to authenticate with a domain account if you do in fact reproduce the output failure when manually running the command as the system account. In this case an Impersonate User step precedes your Execute Shell Command and your Execute Shell Command needs to be set to run as the logged in user, even though it will really use the previously setup account with the Impersonate User step.
In any case, I'm sure some of you have learned a few things-- how to run a command manually as the system account for troubleshooting and how to have a command run as any specific user you wish (local or domain).
Just for giggles, try:
dnscmd /whatever_args_you_use >> "#vagentconfiguration.agenttempdir#\blah.txt" 2>&1
Just to eliminate the remote possibility of a STDOUT and STDERR issue.
"When you are running this command with a standard 'execute shell command' operation unless you set it to 'Execute as user' it runs as the system account and will not be affected by UAC. "
Thanks @Ben, that's good information.