Is there any difference between a scheduled task run by the system account and a scheduled task run by your own account?

msigunner

I have a script whose role is to create a new folder with today's date, and then delete the folder more than 4 days apart from the current date. The specific content of the script is as follows:
On Error Resume Next
a = Date
b = Replace(a, "-", "_")
delDate=4

Set oShell = WScript.CreateObject("WScript.Shell")
Set fs = CreateObject("Scripting.FileSystemObject")

If Not fs.FolderExists ("D:\backup\"&b) Then
fs.CreateFolder("D:\backup\"&b)
End If

Set fd = fs.getfolder("D:\backup")
for each sbfd in fd.subfolders
     if (date-CDate(replace(sbfd.name,"_","-")))> delDate then
         fs.DeleteFolder(sbfd.name)
     end if
next

Set oshell = nothing
Set fd = nothing
Set fs = nothing

Execute this script directly under the command line and it can succeed. Then I directly created a task to execute the script in the "Control Panel" -> "Scheduled Tasks" (this task is run by my own account), and executed the task successfully. Then I used the at command to create a new scheduled task (at 15:00 d:\backup\backup.vbs, the task is run by the system account by default), but when the task is executed, only a new folder can be created, and the file cannot be deleted Folder, I double-checked and found that the "fs.DeleteFolder(sbfd.name)" statement could not be executed smoothly. The security permissions of my folders are set to full control by everyone. The operating system is windows server. Why can't the scheduled task run with the system account execute this statement? What is the difference between running a scheduled task with the system account and running a scheduled task with a normal account? Can the scheduled tasks executed by the system account fail to execute certain tasks?

sh280303120

The security permissions of my folders are set to full control by everyone
----------------
You can add the system account to the folder permissions first. It is possible that the system account does not exist in the everyone group.

Local System account
A predefined local account used to start the service and provide the security context of the service. The account name is NT AUTHORITY\System. This account has no password, and any password information you provide is ignored. The local system account has full access to the system (including the directory service on the domain controller). Since the local system account is used as a network computer, it has access to network resources.

msigunner

I tried this, but it still doesn't work

yemingopo

The original poster is really good-_-!!! The idea of ​​opening a SYSTEM account is coming.

I would like to ask you what was filled in the password when you specified the SYSTEM account to run the scheduled task? Haha, in fact, you can create a new account to replace it, isn't it all right?

msigunner

When using the at command to create a scheduled task, you do not need to provide a password. The generated scheduled task is run by the system account by default. The key is I want to know what are the limitations of scheduled tasks performed by system users?

waterfish

The administrator has a subordinate relationship with the user created by himself. Under normal circumstances, you can see your user and guest from the administrator, and you can change the attributes inside, but you can't change the administrator.

ricoll

When you use the SYSTEM user in the scheduled task, how much do you fill in the password? Don't say it is blank. In that way, you actually become the guest executing