Scheduled task schtasks.exe /create with AT account

Question

in windows 2008 and earlier environment we could use SOON.exe to create scheduled tasks and it’ll automatically schedule with the already configured AT service account.

Now that we cannot use SOON.exe in Windows 2012 but schtasks.exe I’d like to understand how can I make schtasks.exe /Create to use the configured account from AT task configuration.

Answer 1

Hello @Yankee30

Please check if this schtasks commands could help you.

Best Regards
Karlie

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

What is the "AT account"? Since AT no longer works, I can't create a task to see what its settings are. Is it the SYSTEM account?

C:\>at /?
The AT command has been deprecated. Please use schtasks.exe instead.

If your task does not need to access any network shares, and you don't have any security concerns with the program that the task will execute, then just use SYSTEM. No password is needed.

Answer 3

So you have different domains? Or a server that is not a member of the domain?

As long as all machines are members of the same domain, you should be able to use the servername$ account and have the task that runs as SYSTEM authenticate to the other servers.

Another option would be for your task to run a Powershell script that would map a "New-PSDrive -Credentials $cred" to the 2 network servers and then do whatever other processing it does.

https://purple.telstra.com.au/blog/using-saved-credentials-securely-in-powershell-scripts

You can store that string into a text file, and when needed, read it back in and reverse it back into a ‘Secure String’ object and feed into a credential object creation by doing the following:

What is effectively happening here is that PowerShell is using the native Windows Data Protection API (DAPI) functionality to encrypt the password from the ‘secure string’ into a text string. This string can be written to a plain text file, but the way that DAPI works is that the encryption is such that only the original user on the original machine the encryption was performed on can decrypt the string back into a ‘Secure string’ to be reused.

Step 1 would be to write a Powershell script (use the sample code from that site) that saves the password in a plain text file. Then create a scheduled task that runs as SYSTEM and executes the script. You will end up with an encrypted password in a file that only the SYSTEM account on that machine can decrypt.

The application task can then be created by schtasks..exe to run as the SYSTEM account. The key is that the task needs to execute a Powershell script that would read in the encrypted password and use it map a network drive. The PS script can execute whatever else your application does.