Windows Task Scheduler quirks; Changing what happens when a laptop lid is closed … (part 3)

The other day I posted on how I use Task Scheduler to run a batch file that changes what happens to a laptop when the lid is closed depending on where it is located.

I have been fiddling with the Task Scheduler since then and thinking of how I can use it for other tasks. Specifically, at work we have a lot of add-in issues with Office products wherein every so often Word/ Excel/ Outlook/ PowerPoint give a message when launching that such and such add-in caused issues and it is recommended the user disables them; users click “Yes” to such messages inadvertently or intentionally, after which whatever functionality the add-in provides does not work any more and we at IT get calls! I had an idea to create a PowerShell script that will re-enable the add-in in such cases and maybe use Task Scheduler to hook into any Event Log entries that are generated when add-ins are disabled to trigger the running of this script. That’s the topic of another post however but as a result of exploring this I have been playing with Task Scheduler a bit and revisited the Task Scheduler entry I made for the laptop lid closing problem.

First off, here’s an exported version of the Task Scheduler entry I created:

Note the highlighted lines:

  • Line 5 – the “Author” – doesn’t matter much. It merely specifies who the author of the Task is.
  • Line 23 – the “UserID” – matters. This is the user ID under which the task runs. If you specify a user ID here, you must use the same ID when importing the task. You could specify a user ID here and specify a different ID when importing (via schtasks /ru ...) and the latter will over-ride the ID in the XML file. If you will always be specifying a user ID when importing, you can skip the user ID in the XML file too. I chose to leave it commented so I remember it for later.
  • Line 17 – yet another “UserID” – matters. This user ID is to do with the “run when a user logs in” trigger. If your task doesn’t have such a trigger this user ID won’t be present. You have two choices here really: either you could specify a user ID and that is the user account whose login will trigger the task, or you could skip that tag (remove the whole line) and the task will trigger when any user account logs in. The latter has a catch though. If you do this, then you cannot skip the UserID of line 23. In my case I chose to use a marker here “–REPLACE–” and modify the XML file to replace this with a user ID later on (see below).

Gist of the matter for my specific scheduled task entry is that I can’t import this task willy for any user. When importing I have to (1) specify the user in whose context the task will run – I must do that via schtasks /ru ... or modify the XML file directly – and (2) if I am not modifying the XML file in the previous step, I can’t leave the UserID element of line 17 blank and so I must modify the XML file to put a user ID here. This user ID would be that of the user I am installing it for of course.

To that end I modified the install batch file I had created:

The important bit here is the 4th line, where I use PowerShell to read the XML file and replace the bit that says “–REPLACE–” (which is the marker I use at line 17 of the XML file) with the user ID of the user I am installing this task for. Apart from that, on line 6 when I import the task I get the user ID from the environment variables and prompt for a password. This way the install batch file and task XML files are generic and I can run them for any user.

That’s all for now!

Update: I realized I could simplify things further since I am using PowerShell any ways to replace text in the task scheduler XML file. I can specify the “run as” user too and thus avoid prompting for a password when installing! :)

Notice I have set the marker “–REPLACE–” in two places now. Both will get replaced while installing. The batch file can be modified as below to omit the /RU & /RP switches: