Windows 11 Task Scheduler odd behavior

[samsquared2]

I have a command file (.bat) I run to copy some files from my Windows 11 PC to another PC. When I double-click the .bat file on my PC, it runs and successfully copies the files. When I run it using Task Scheduler, it runs the command file but no files are actually copied. I piped the output to a text file and for each of the 5 xcopy lines it says 0 File(s). It is not the case that files are actually copied when I double-click it and therefore there are no changed files to copy when I use Task Scheduler because for testing I changed the command file to use the /L option to see what would be copied.

The task runs with highest privileges and can run whether or not I am logged in or not. This task ran successfully from a Windows 10 PC for a long time. Initially I exported the task from that machine and imported it to the Win 11 PC. I then disabled that task and set up a new one from scratch but that produced the same results.

What could be causing his behavior?

 

[ChatGPT]

Likely cause: the task runs in a different context than when you double‑click. That usually breaks relative paths and mapped drive letters, so XCOPY doesn’t “see” any files and reports 0 File(s). Fix it in three quick GUI steps and (optionally) harden your .bat.
What to change (GUI only)
1) Set the working folder

• Task Scheduler > your task > Actions > Edit.
• If Program/script points to your .bat, fill Start in (optional) with the folder that contains the .bat (for example, C:\Scripts). This alone fixes most “0 File(s)” cases because scheduled tasks default to C:\Windows\System32.

2) Avoid mapped drive letters

• Edit your .bat to use UNC paths (\OtherPC\Share\Folder) instead of X:\… Mapped letters don’t exist in the non‑interactive/elevated session the task runs in.
• Or schedule the task to Run only when user is logged on for a test; if it then works, it’s a drive‑mapping/credentials issue.

3) Make sure the task’s account can reach the share

• In Task > General: Run whether user is logged on or not (enter that user’s password). The “Run as” account must have read/write on both source and destination shares. If the destination is on another PC/domain, use UNC and ensure that account has permissions there.

Strongly recommended tweaks to the .bat

• Pin the working directory at the start so relative paths work whether run by hand or by Task Scheduler:
  cd /d "%~dp0"
• Prefer ROBOCOPY (more reliable than XCOPY) and use UNC paths. Example:
  robocopy "\MyPC\SourceFolder" "\OtherPC\Share\DestFolder" .docx .xlsx /E /XO /R:1 /W:2 /LOG+:C:\Logs\backup.log /NP
• For passworded shares, either:
  • Run the task as an account that already has access, or
  • Add a one‑time stored credential in Credential Manager on the Win11 PC for \OtherPC, then keep using the UNC path. Avoid putting passwords in the .bat.

Quick diagnostics if it still says 0 File(s)

• Temporarily set General > Run only when user is logged on and click Run from Task Scheduler to watch it.
• Add these lines at the top of the .bat to a log so you can see the context:
  set LOG=C:\Logs\backup_diag.log
  echo %date% %time% >> %LOG%
  whoami >> %LOG%
  echo CD=%CD% >> %LOG%
  dir "\OtherPC\Share\YourFolder" >> %LOG% 2>&1
  If dir shows “Access is denied” or “The system cannot find the path specified,” it’s permissions/UNC; if it lists files when you set Start in correctly, the issue was the working directory.

If you share your current XCOPY lines and the task’s Action fields (Program/script, Add arguments, Start in), I’ll rewrite the exact GUI settings and a ROBOCOPY equivalent for you.

 

[samsquared2]

The output from

dir "\OtherPC\Share\YourFolder" >> %LOG% 2>&1

is "The user name or password is incorrect." I am using UNC paths and the task is set to run with highest privileges and whether logged in or not.

Because it is a permissions issue, I see no reason to try robocopy.

 

[ChatGPT]

You’ve nailed it: the task’s “run-as” account can’t authenticate to the remote share, so every UNC access fails with “The user name or password is incorrect.” When you double‑click, your interactive credentials (or saved creds) are used; Task Scheduler uses the account shown on the task’s General tab.
Do one of these (pick one):
Option A — Run the task as an account that already has access
1) On the destination PC, ensure a user exists that has NTFS + Share permissions on \OtherPC\Share (e.g., BackupUser; must have a non‑blank password).
2) On the source PC, open Task Scheduler > your task > General > “When running the task, use the following user account” = that same user (domain\user or OTHERPC\BackupUser). Keep “Run whether user is logged on or not,” enter the password.
3) Re‑run the task.
Option B — Store credentials for the task’s user (no passwords in scripts)
1) Sign in as the same user the task runs as.
2) Open Control Panel > Credential Manager > Windows Credentials > Add a Windows credential.
3) Internet or network address: \OtherPC (or its hostname).
4) Username:

• If target uses a local account: OTHERPC\BackupUser
• If target uses a Microsoft account: MicrosoftAccountyouremail@example.com
  5) Enter the password, save, then re‑run the task.

Option C — Pre‑auth inside the .bat (quickest, but exposes a password)
Add at the top of your .bat:
net use \OtherPC\Share /user:OTHERPC\BackupUser "P@ssw0rd!" /persistent:no
rem … your XCOPY lines …
net use \OtherPC\Share /delete /y
Avoid this if you can; plaintext creds are risky.
Notes and quick checks

• For a one‑time test, set General > Run only when user is logged on and click Run. If it works, it’s definitely credentials.
• If the destination uses a Microsoft account, the username format matters: MicrosoftAccountyouremail@example.com.
• “Run with highest privileges” is fine, but unrelated to SMB auth.
• Your logging line was perfect; after the change, dir \OtherPC\Share in the task context should list files.

If you tell me which model you prefer (A, B, or C) and what the target account is (local vs Microsoft/domain), I’ll give you the exact fields to fill and a quick permission checklist on the share.