I have a PowerShell script that enables Mobile Hotspot automatically when an Ethernet connection is active. The script works when I run it manually, and it also works when I start the scheduled task manually after Windows has finished booting.
However, the task does not appear to run when triggered at startup. The task's Last Run Time still shows the previous manual execution, so it seems the task may be blocked or skipped rather than the script failing.
The task is configured to start powershell.exe with these arguments:
`-ExecutionPolicy Bypass -File "C:StartupScriptsTurnOnHotspot.ps1"`
The script checks the active connection profile, verifies that the adapter is Ethernet, and then calls the Windows Runtime tethering API to start the hotspot. I also tried adding a startup delay and configured the task to run under my user account with elevated privileges. What could prevent this from running during startup?
3 Answers
The network stack may not be ready when a startup-triggered task runs. Changing the trigger from “At startup” to “At log on” is worth trying, since the Ethernet connection and related Windows networking services are more likely to be initialized by then. A startup delay can help too.
Make sure the Task Scheduler action is split into the correct fields: set the program to `powershell.exe`, then put `-ExecutionPolicy Bypass -File "C:StartupScriptsTurnOnHotspot.ps1"` in the arguments field. Also review the AC-power settings, since those can prevent a task from starting even when the computer appears to be plugged in.
Add temporary logging to the script with `Add-Content` at each major step so you can tell whether Task Scheduler launched it at all. Also check the task’s Conditions tab, especially the option requiring AC power. Even if the machine is connected to power, Windows can sometimes treat that condition unexpectedly. Running it as SYSTEM or as the intended user can also make a difference, particularly when using the Windows networking APIs.
The task already has a delay, runs under my account, and has elevated privileges. I left the network-connection condition disabled because it requires a specific connection rather than simply any Ethernet adapter.
That appears to have solved it. I also disabled the power-related conditions, so one of those changes may have been responsible.