4

I'm trying to put in place some monitoring for Windows Task Scheduler, I have a Powershell script that runs the following:

$serverName = hostname
$schedule = new-object -com("Schedule.Service")
$schedule.connect($serverName)
$tasks = $schedule.getfolder("\").gettasks(0)
$tasks |select name, lasttaskresult, lastruntime

This returns a list of scheduled tasks on the server it is run on, the last task result and last run time. The purpose for this is to return a dataset to our monitoring solution (Geneos) which we can use for alerting.

We have a large Win2008 estate, so I want the script centralised allowing any of the Geneos probes to call it and return a dataset for their host. To do this I wrapped the powershell in a .bat file which does the following:

\\fileserverhk\psexec.exe -accepteula -u admin -p "pwd" powershell.exe cpi \\fileserverhk\scripts\TaskSchedulerMonitor.ps1 -Destination C:\Monitor\TaskSchedulerMonitor.ps1
\\fileserverhk\psexec.exe -accepteula -u admin -p "pwd" powershell.exe -ExecutionPolicy Bypass -File C:\Monitor\TaskSchedulerMonitor.ps1

The First step copies the .ps1 file locally to get around Powershell not trusting UNC paths and the second part runs the script.

If I run the .bat file manually from a test server it executes fine (this is logged in under an admin account). However, when I fire the .bat file via Geneos (which runs under the SYSTEM account) I get:

Access is denied.
PsExec could not start powershell.exe:

So basically my question is, how do I get PsExec to switch user when it is run under the SYSTEM account? Even though PsExec has the credentials set for another account, there is obviously something preventing it from changing when run under system.

I read to try running it with the -h switch but I get the below error:

The handle is invalid.
Connecting to local system...


Starting PsExec service on local system...

Connecting with PsExec service on <server>...

Starting powershell.exe on <server>...

Error communicating with PsExec service on <server>:

In addition to the above error, I end up with the PSExec and powershell processes hung on the remote machine. The interesting part is I can see the PSExec and PSEXEC.SVC running under SYSTEM and the powershell running under admin, so it's almost there, but something isn't quite right there.

Mohammad Nadeem
  • 9,134
  • 14
  • 56
  • 82
Phlebass
  • 91
  • 2
  • 10
  • +1 Interesting question! I think I can answer but first I need you to run with Geneos (never heard of it before...) as before, but replace the PowerShell commands with a simple one like CMD, so it doesn't traverse the network. If it doesn't work, then add a *-s* right after the PSEXEC statement to ensure PSEXEC is run with the system account. Also, I'm not positive PSEXEC can run with a *-* in front of 'accepteula' instead of a */*... Might want to try both ways. – Lizz Nov 10 '12 at 07:35
  • Thanks for the feedback. I can confirm that I can spin up a cmd.exe process using psexec, I can run it under the original supplied admin account (if I supply **-h**) or as system (using **-s**) without problem. I forgot to add that the original PSEXEC that copies the .ps1 script locally works OK. I've tried both / and - for accepteula and both seem OK, this only applies on the first run though (originally used - which cleared up an initial issue I was seeing with the psExec process just hanging i.e. the EULA was popped up in the background and not getting accepted) – Phlebass Nov 12 '12 at 02:00
  • Is there any specific reason for not using powershell remoting iso psexec? – Bas Bossink Nov 13 '12 at 00:27
  • The powershell remoting almost got us there. We eventually got the output to Geneos using a .vbs wrapper on the Windows schtasks.exe command. Details in answer. – Phlebass Nov 13 '12 at 09:24
  • Thanks for the results of that test. I'm guessing that if you had the file 'TaskSchedulerMonitor.ps1' available on the local host, then the second PSEXEC/PowerShell command line you launch (above) works - correct? If so, then the solution is likely to be one where you specify the PowerShell credentials. Can you try that? – Lizz Nov 15 '12 at 07:37
  • You're correct, once copied locally the .ps will execute. In the end we moved from Powershell to a vb script, the ps StdOutput wasn't compatible with Geneos (it was returning a fixed width record set for lasttaskresult and lastruntime) unfortunately we'd spent too long on this already and had to move on, so never got to the bottom of that. – Phlebass Nov 19 '12 at 07:01

1 Answers1

2

We managed to get there using a powershell wrapper on the Windows schtasks command (link here). Schtasks can be run under the SYSTEM account and will return all the necessary task information, so we no longer needed to faff about with permissions, and no more clear text passwords on the environment (bonus).

We wrapped:

schtasks.exe Query /FO CSV

in a powershell script, and used PS to format the output into the csv style expected by Geneos.

Phlebass
  • 91
  • 2
  • 10
  • I glad you have this solution. However, creating and maintaining scheduled tasks can introduce unexpected issues in the future - like depending on scheduled tasks, which may not always be there. My thought at this point is the creds being used by PowerShell (see my comment, above). – Lizz Nov 15 '12 at 07:39