/build/static/layout/Breadcrumb_cap_w.png

Issues running scripts on 6.4 with user other than local system

Hello,

I have been battling a frustrating issue with KACE lately. We are on version 6.4.120.261. We mainly use KACE for Windows Server patching and scripting. What I've noticed is that the success of KACE running scripts against servers using an account other than the local system account is hit and miss. It works sometimes, but other times it does not.

For example, we have a script that backs up the print queues on all of our print servers. In total we have about 65 servers that this script runs against. About 45 of these are 2008 OS and 20 of these are 2012 OS. To run this script, I am using a domain admin account that I have setup in KACE. Last night I ran the script and it completed on 44 of 65 servers. The servers it failed on were both 2008 servers and 2012 servers. It wasn't limited to just one OS.

Here is another thing I have found in testing. If I login to a server via RDP (with any account that has admin privileges to the server) where the KACE script failed and run the script against this server using KACE, the script runs fine. The minute I log out of this server and try running the KACE script against this server it fails. I have confirmed that the "allow run without a logged-in user" box is checked. I can consistently replicate this behavior. If I am rdp'd to a server that has failed previously and run the KACE script against it using KACE it always works.

This tells me that there is not a problem with my script and it is odd that it has worked on 44 of the 65 without issue. This is an online kScript using the run a batch file task.

I've talked to support and it sounds like they are aware of issues when running scripts as a specific user. Here is what they told me:

Sorry for the inconvenience. After further digging on the issue I found a previous bug issue that occurred on previous version 6.2 and 6.3 that may be related to the issue on 6.4.120261. As it turns out there is not workaround or fix yet but provided below are the details.

Online KScript fails when "Run As specific User" is specified

1.  Launching cmd.exe as the SYSTEM user works fine and as expected, the cmd.exe windows shows up. The problem is that the cmd.exe windows does not show up as soon as you will use a RunAs account under the RunAs options
2.  A Batch Kbot with the following line "whoami > test.txt"… If you run this kbot as SYSTEM, all worked fine, however, running this kbot as someone else using the RunAs option (such as local admin or domain admin) does not even produce the output file (we also tried to product the txt file in other directories to exclude permission issues or otherwise)

Below are the 3 scenarios that have been tested:
1.  Configure a RunAs account to be the local admin or domain admin on the target machine
2.  Configure the kbot to run a batch file and add some line to it that pipes the stdout into a txt file
3.  Another test is the test where you simple want to launch a program (cmd.exe) as another user and the window does not open
Expected Results: Cmd.exe window opens in scenario 1 above and the whoami output is created in the text file/the text file is created when doing batch scripts.
Actual Results: We do not see a cmd.exe window and the batch script does not seem to run meaning no stdout is piped into a text file.

Have any of you experienced issues like this when running scripts as a specific user and not as local system. I would love to get your thoughts and what you did to resolve this issue.

Thanks

Tony

1 Comment   [ + ] Show comment
  • I should add that we are running agent version 6.4.180 - tonymctone 8 years ago

Answers (2)

Posted by: tonymctone 7 years ago
White Belt
0
jsnyder,

I asked support this same question and unfortunately there is no easy way to roll back. Here was the response:

My question:
Can I readvertise the 6.3.314 agent in KACE and apply it to specific labels so that the servers in the specified labels roll back to this agent version? Or does KACE automatic agent deployment only support going ahead in versions? Thanks"

Support Response:
As it turns out, KACE updates settings only upgrades the versions and does not downgrade. So if you advertise 6.3.314 agents, the workstations agents would have to be below  x < 6.3.314. The only solution I can think of if you provision uninstall of agents then provision agents towards 6.3.314. 
Posted by: MAXintosh 8 years ago
Senior Purple Belt
0
tonymctone,

We're also on v6.4SP2 and have noticed the same issue on our end for a while now (at least since v6.4?) and have not found a reasonable resolution. Our issue may go further in that we have a 100% fail rate when we select Credentials for the Windows Run As option. Even though the credentials are correct and we tried username + password and domain\username + password.

Comments:
  • I am glad to hear it is not just us experiencing this issue. Does it work for you when you have an RDP session open on the server you are trying to run against? Support said to try installing the 6.3.314 agent on some of the problem servers and see if that gives better results. I will be trying that tonight. - tonymctone 8 years ago
    • I can report that I installed the older agent on 8 servers and the script worked on all 8. Therefore, it does seem to be a problem with the 6.4 agent - tonymctone 8 years ago
      • tonymctone,

        Would never have thought that the Agent would have been the cause. Thank you for letting us know a solution that worked for you. I will try intalling 6.3.314 on few machines and try it out. - MAXintosh 8 years ago
      • Is there a way to roll back all agents to a version that works and prevent them from updating? - jsnyder 7 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ