I'm working on a Powershell script that is to be tasked with the job of auditing scheduled tasks that are defined on a number of Servers in our environment.
I've managed to get it working pretty well and it even includes the ability to audit multiple actions and multiple targets. It also will audit targets with different scheduling parameters.
All is working fine but I just can't figure out how to audit a trigger which is defined as 'On a schedule' where the interval is set to 'Monthly'.
When you do this the resultant CIM object has the type 'MSFT_TaskTrigger'. I've tried using the object reference but none of the child objects seem to actually have any values associated with them. This is despite me create a sample test which has both Months and Days specified.
Does anyone else know of a way of achieving this?
Right now I use the New-CimSession cmdlet to first get a valid connection to the remote machine. Then I use Get-ScheduledTask to retrieve the appropriate tasks.
From there I can enumerate the triggers using the $scheduledTask.Triggers collection. It seems to work for all triggers but i'm struggling to get the extended information about the trigger schedule when the type is MSFT_TaskTrigger.
Grateful for any pointers or advice that people might have.
Thanks in advance,
I don't think Microsoft exposes the information you are looking for with that trigger type. And some tasks that use that type can't even be modified with the Task Scheduler. This may be a case where the command line tool is better.
PS Scripts:\> schtasks /query /tn test /v /fo listFolder: \HostName: WIN81-ENT-01TaskName: \testNext Run Time: N/AStatus: DisabledLogon Mode: Interactive onlyLast Run Time: N/ALast Result: 1Author: WIN81-ENT-01\JeffTask To Run: notepadStart In: N/AComment: N/AScheduled Task State: DisabledIdle Time: DisabledPower Management: Stop On Battery Mode, No Start On BatteriesRun As User: WIN81-ENT-01\JeffDelete Task If Not Rescheduled: DisabledStop Task If Runs X Hours and X Mins: 72:00:00Schedule: Scheduling data is not available in this format.Schedule Type: MonthlyStart Time: 10:00:00 AMStart Date: 7/31/2016End Date: N/ADays: 32Months: JAN, JUL, DECRepeat: Every: DisabledRepeat: Until: Time: DisabledRepeat: Until: Duration: DisabledRepeat: Stop If Still Running: Disabled
And you can use it to export to a CSV file.
schtasks /query /v /fo csv | out-file c:\work\tasks.csv
Which you can then re-import into PowerShell.
$tasks = Import-csv c:\work\tasks.csv
$tasks | group "Schedule Type" -NoElement | sort countCount Name----- ---- 1 Monthly 1 Weekly 3 One Time Only 6 Scheduling data is not... 6 One Time Only, Hourly 6 At idle time 13 At system start up 19 Undefined 29 At logon time 29 When an event occurs 35 Daily 53 On demand only 76 Schedule Type
$servername = "yourmachinename";
$taskname = "yourtaskname";
$schserv = new-object -com("schedule.service");
$task = $schserv.getfolder("\").gettask($taskname);
### This will list out the xml for the entire task.
From the xml, you should see something like:
I think the bottom line is that the ScheduledTasks cmdlets are not "feature-complete".
Jeffery Hicks said:I think the bottom line is that the ScheduledTasks cmdlets are not "feature-complete".
Haha, you're not kidding. Another interesting 'feature' i've discovered is that there's one specific Trigger property outside of the schedule which for some reason is not exposed if the trigger type is MSFT_TaskTrigger. In that case you also find that the RandomDelay property isn't visible.
Thanks for the comments guys. I've only just checked back today and i've pretty much done what you describe.
My routine now follows this flow:
1. Bind to the trigger collection and enumerate each.
2. If the trigger type is anything other than MSFT_TaskTrigger then I can build the description of the trigger using just the regular object module.
3. In the case of MSFT_TaskTrigger I build a scriptblock which runs SchTasks and reads back the XML into an object. From there I parse the XML and dynamically build an object which is returned to the calling routine. I can then use the Invoke-Command to run the script block on the remote machine with the required credentials.
4. I also did some coding in the routing so that the original Trigger is updated so that the RandomDelay attribute can be read. It looks like the routine is working now as expected and it's quite robust.
I'd rather not post code fragments but if anyone is interested in the completed script once it's done then i'll happily post it here. The intention is that you can run it against one or more hosts and have it build a nicely formatted XLSX document which describes the scheduled tasks, their configuration and state.
It started off as a relatively quick job but the more i've dug into the Task Scheduler the more i've come to appreciate it's complexities and the plethora of options it offers. I'd say the script should be done early next week.
In the meantime, I suggest you go to the Connect site and file a bug. Once you've done that, report back here and we'll "vote it up."
That's a great suggestion.
I'll get the issue reported and come back with the details once i've got them.
Unfortunately it would seem that Microsoft Connect only allows submission of bug reports for specific products and I can't see any that would be relevent for me to file against in this case :-(