Issue is with a Windows 7 system with latest updates, on a network with Windows 2008r2 server in an non-AD non-domain environment.

From File Explorer, or within an application, I can access \\server\share using saved credentials. I have read/write access according to rights of account for user on server. From a command window, I can type "net use \\server\share" and will get some details, followed by "command completed successfully".

From a CMD batch file launched from scheduled task, net use \\server\share will sometimes hang the script because it is prompting for username and password.

I can see the failed schedule task window frozen with the prompt. I can launch another command window and type "net use \\server\share" and it works.

When run as a scheduled task: enter image description here

When I find the stalled task and run from a command window: enter image description here

If I re-run the scheduled task from Task Scheduler it will run successfully and not hang on Net Use. Only when the task is started by the system does it seem to have problems with logging in.

Why does net use sometimes ask for credentials (which are saved on the local machine)? How can I cause this schedule task to run reliably?

  • are you positive it's net use prompting for credentials and not the task itself? – mael' Jul 3 '19 at 18:06
  • also, if net use is using current credentials to map a network drive, are your users logging in with a username/password or a token/password? or is net use passing a username and password that exists only on the server? – mael' Jul 3 '19 at 18:15
  • See edits above with screen captures. The Scheduled task stops for credentials. The same net use command from cmd.exe works. – tim11g Jul 4 '19 at 16:29
  • The difference is the schedule task runs with elevated privileges. If it it not elevated, the image backup program triggers UAC which also hangs the unattended scheduled task. – tim11g Jul 4 '19 at 16:31
  • I thought maybe the elevated scheduled task was running as system, so it didn't have access to the stored credentials for the normal user account. I put "whoami" in the scheduled task script, and it reports the same computername\user that is reported when I run whoami from the cmd.exe window. – tim11g Jul 4 '19 at 16:38

The issue seems to be that after some recent Windows Update, elevated scheduled tasks are no longer able to reliably use stored credentials for network access, even though they are running as the primary User and not as System.

I didn't want to disable UAC globally on the machine for this issue. I didn't want to put the username and password in the task's CMD file.

My compromise solution to create a new account with specific, limited privileges on the server for this task. I created a new share on the server for the specific resource needed by this task. (specialshare) In the scheduled task, I delete any existing logins (since they seem to be present sometimes), then connect to the server with the limited account credentials (in the CMD file).

NET USE \\server /D
NET USE \\server /U:limiteduser junkpassword
... run the rest of the scheduled task, perform network access to \\server\specialshare...
NET USE \\server /D

Not ideal, but it seems to work. If you have a better approach, please comment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.