Export/Import Scheduled Tasks in bulk

kitpzyxmsir,

Your second post indicated that you have already dealt with the job of [bulk] backing up of tasks so I will not address that any further.

I do not bulk restore tasks so all I can offer are guides to the viable approaches that you might choose

Try3 said:

I have not done any mass importation but would look to the SchTasks command for that.

SchTasks /Create /?
schtasks - SS64
schtasks MSDocs

or I'd examine PowerShell's capabilities in this respect

Task Scheduler cmdlets - SS64
Scheduler error codes - SS64
Get-ScheduledTask - MSDocs
Get-ScheduledTaskInfo - MSDocs
Set-ScheduledTask - MSDocs

together with the warnings that

Try3 said:

If you merely copy them back into C:\Windows\System32\Tasks on the new computer then TS will detect them as having been tampered with and it will refuse to run them.

and

Try3 said:

With some exceptions, importing the task definition within TS on another computer requires that the whole <UserId> line of the backed up task definition be deleted first. I just do this manually within Notepad.

- This applies to the tasks you have created yourself.
- I've transferred task run by the System 'user' without having had to remove that line.
You'll have to deal with the issue of user accounts within task definitions one way or another.


That's all I have to contribute,
Best of luck,
Denis

avada said:

So there's no convenient way to copy my task as they are with folder structure preserved?

SchTasks allows you to import them into specific folders of your choosing. See the links I posted earlier.

avada said:

Can't I get windows to treat them as valid by some means, like also importing some registry keys (I imagine).

I have never seen any such method.


I have also replied to a TS question of yours in the TS tutorial thread.


Denis

Try3 said:

SchTasks allows you to import them into specific folders of your choosing. See the links I posted earlier.

I know I have imported into a specific folder and have been checking my notes to check the syntax but I cannot find what I wanted.
I think the syntax was merely in the /TN bit - instead of

Code:

/TN TaskName

it was, I think,

Code:

/TN FolderName\TaskName

That is certainly consistent with how an exported task from a folder would look. If, just for example, you go to the TS Task library folder \Microsoft\Windows\Chkdsk and export the ProactiveScan task from there, its exported .xml file contains the line <URI>\Microsoft\Windows\Chkdsk\ProactiveScan</URI>, i.e. Foldername\TaskName, whereas a task in the highest level of the TS Task library would have the line <URI>\TaskName</URI>

What a fool I am at times. Knowing that I had done this in the past, I was checking back through my own notes. I have only just noticed that Brink used a SchTasks xml import into a specific folder example in Option 2 of the TS tutorial that both of us recently posted in.


Best of luck,
Denis

It's entirely up to you but I am only interested in backing up the tasks I have created and I know which folders they are in.
I use RoboCopy commands to copy
- tasks from the main TS Task library into my TaskBackup folder
- tasks from the MyFolder I created for some of my own tasks into my TaskBackup\MyFolder folder.
I also include RoboCopy switches to skip tasks created by applications e.g. /XF "C:\Windows\System32\Tasks\Intel PTT EK Recertification"


Denis

What a fool I am at times. Knowing that I had done this in the past, I was checking back through my own notes.

I have only just noticed that Brink used a SchTasks xml import into a specific folder example in Option 2 of the TS tutorial that both of us recently posted in.

But do note what I said in that thread about deleting the whole line<UserId>...</UserId> because that avoids your having to mess about with specifying users & passwords. The task is imported for the user who is running the command.



And thanks for the rep,
Best of luck,
Denis

This seems to have worked if anyone's interested:

Code:

chcp 65001
set d=b:\OS\tasks\Saját\
set "u=%computername%\%username%"
set "psCommand=powershell -Command "$password = read-host 'Please enter the run as password for %u%' -AsSecureString ; ^
    $BSTR=[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($password); ^
        [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)""
for /f "usebackq delims=" %%p in (`%psCommand%`) do set password=%%p
for /f "usebackq delims=|" %%f in (`dir /b "\\?\%d%"`) do (
  schtasks /create /tn "\Saját\%%~f" /ru "%u%" /rp "%password%" /xml "%d%\%%~f"
)

I still don't know why the \\?\ was there. Or what is the ">nul" part is supposed to do so I removed them.
The error about account names and security identification went away with the username/password now added.
The access denied part was (unsurprisingly) because of the lacking elevated rights originally.
Also one of the access denied errors was for a folder, because I have a subfolder for my tasks. So I guess I'll have to modify the script for this sub-folder. (easier than modifying it to work recursively, and create TS folders accordingly)

PS: I ran it in Powershell.

- - - Updated - - -

Uh-oh. Something went very wrong.

The programs started TS are running but are invisible to me. No UI, or notification area icons.
And when I start them manually another instance is started, which they are specifically set not to do, or don't allow by default.
For the two different instances Process Explorer shows my username, identical between to the two instances, also the SID. But it's as if they are running under a different account. Not clue what's happening.

- - - Updated - - -

I compared the new task in system32/tasks and the backup of the old one:

I see that the original had an SID as a user ID the imported one merely has my computer\username.
Is this the big difference?
(Ugh. Got fed up and imported all of them manually. What a waste of time this was...)

It is normal for the task definition itself to show the username but the exported xml to show the SID.

The difference that strikes me is that you have set the left-hand one to run whether or not the user was logged in.
If so, you might well not see any interface for the task as it runs. The interface would only be shown to the not-logged in user, who has no interface because they are not logged in.
I have not played around with 'Run whether user is logged in or not' for years so my memories of it are extremely sketchy.

All the best,
Denis