Mapped drives and elevated tasks

While setting up the Night Shift Runner, I ran into a Windows trap that has nothing to do with InDesign but can break any scheduled script: a mapped network drive that’s right there in Explorer, but doesn’t exist for the scheduled task. The main script then reports that its Templates folder doesn’t exist, and in unattended mode it just stops. InDesign opens and closes, and that’s it.

What is an elevated program?

Even if you log in as an administrator, Windows doesn’t give programs full admin rights by default. This is how User Account Control (UAC) works. When you log in, Windows creates two “keys” (tokens) for your session:

a normal key with limited rights. Everything you start usually runs with this one: Explorer, InDesign, Excel, the browser;
an admin key with full rights: changing system files, installing software, editing protected parts of the registry. Windows hands it out only when a program needs it — that’s the “Do you want to allow this app to make changes to your device?” prompt. After you click Yes, the program runs elevated.

You see elevation in a few places: a small shield icon on a button, Run as administrator in the context menu, “Administrator: Command Prompt” in a window title — and in the Task Scheduler, the Run with highest privileges checkbox, which runs the task with the admin key without asking.

Why it matters for mapped drives

Windows treats the two keys almost like two separate sessions. A drive mapped in the normal session (by you in Explorer, or reconnected by Windows at login) belongs to the normal key only. An elevated program doesn’t see it: for that program, the drive simply doesn’t exist.

There’s a second side effect for scripts like mine: an elevated program and a normal one can’t talk to each other through COM. If InDesign is already open normally and an elevated runner calls GetObject(, "InDesign.Application"), it doesn’t find it, and may start a second InDesign or fail.

Other ways a drive disappears for a task

“Run whether user is logged on or not”. The task runs in a background session that has no mapped drives at all (and InDesign can’t work properly there anyway).
The drive is “disconnected”. Windows reconnects mapped drives lazily. After a reboot or a long idle time, a drive may show a red cross until someone opens it in Explorer, and a script’s first access fails.
The other computer is asleep. If the drive is on another PC and that PC sleeps at night, the drive is gone at 3 a.m. This one, of course, can’t be reproduced in a daytime test.

How to check

Make the runner write down what the task actually sees. A few lines before DoScript are enough:

Dim p, oExec
For Each p In Array("H:\Templates", "H:\Schools", scriptPath)
    Log "Exists? " & (fso.FolderExists(p) Or fso.FileExists(p)) & " - " & p
Next
Set oExec = CreateObject("WScript.Shell").Exec("cmd /c net use")
Log "net use:" & vbCrLf & oExec.StdOut.ReadAll

net use lists every mapped drive with its real network path (for example, H: \\OFFICE-PC\Data) and its state: OK, Disconnected or Unavailable. Run the task once from the Task Scheduler (right-click > Run) and read the log. Then compare with a run of the same script by hand in a normal Command Prompt: if it works by hand but not as a task, the cause is the task’s context.

How to solve it