<div>
Weird, but why are you using scheduled tasks in the first place? They are so rarely needed. If you're creating scheduled tasks via GPO, my first question would be why?<br><br>How do you setup machines where an admin NEVER has logged in.
</div>


<div>
You had another question, recently, and there, I linked to my article which describes the reason why startup scripts and scheduled tasks with the "at startup" trigger may fail and what to do against it.<br>So again:&nbsp;<a href="https://www.experts-exchange.com/articles/25279/Overcoming-software-deployment-pitfalls-on-modern-Windows.html" rel="ugc">https://www.experts-exchange.com/articles/25279/Overcoming-software-deployment-pitfalls-on-modern-Windows.html</a>&nbsp;<br>(note: it's about software deployment, but I am talking about scripts and tasks, too and explain why).
</div>


Consultant

hypercube

<div>
kevinhsieh: &nbsp;Thanks for the questions!<br>A good example of using Task Scheduler is to have workstations reboot at 11 p.m.<br>Another is to have a user account log off after an idle period - the Task Scheduler is the only place I can find an actionable "idle" sensor without coding (except for the screen saver settings of course).<br>re: the admin logon. &nbsp;An admin had not logged on *since* the GPO was deployed.<br><br>McKnife: &nbsp;Thanks for the repeated link!
</div>


<div>
McKnife: &nbsp;OK. &nbsp;I read the article and found it very informative. &nbsp;It makes me think that turning off fast startup might be a good idea. &nbsp;We force restart of all the computers every night anyway and don't turn them off. &nbsp;So, "cold" boots (with hibernating kernel) are rarely seen if I understand what you say about that.<br><br>My issue here seems to be about logging on with admin privileges when there's a startup script that will need admin privileges to fully execute - such as with "schtasks". &nbsp;I'm not completely sure but this question is part of figuring it all out.<br>I encountered a computer or two yesterday that had not had GPOs updated since February!! &nbsp;Yet, I've had a number of GPO deployments since. &nbsp;And, since it's my practice to NOT log on with an admin account and to defer to "run as administrator" as much as possible, I rather assumed that was the reason.<br><br>Scribbling out the steps I envision:<br>- Develop GPO with Startup script included. (Startup script creates a scheduled task and a .bat file)<br>&nbsp; (The scheduled task comes from an .xml file. &nbsp;The bat file is simple and is constructed with in-line script code).<br>- Deploy GPO<br>- (Workstation receives GPO ... maybe multiple steps here)<br>- Startup script goes into workstation<br>- Reboot (by demand / not cold)<br>- Startup script runs (as who? permissions? depends on context/commands?<br>&nbsp; &nbsp;Creates a scheduled task - permissions again....<br>&nbsp; &nbsp;Creates a .bat file - permissions again...<br><br>Now, of course, when the workstation is rebooted, it isn't logged onto a User account.<br>So, the next User logon will be whatever human action determines.<br><br>I know I'm missing something here.....<br><br>
</div>


<div>
I'll add more later, when I find the time. For now: startup scripts happen before logon. No connection to the logon, no admin needed.
</div>


<div>
Scheduled tasks can be managed via Group Policy Preferences, which seems like a better framework than a startup script.<br><a href="http://www.mdmarra.com/2014/04/managing-scheduled-tasks-from-group.html" rel="ugc">http://www.mdmarra.com/2014/04/managing-scheduled-tasks-from-group.html</a>&nbsp;
</div>


<div>
kevinhsieh: &nbsp;Thanks for the suggestion!<br>Yes, I had originally started out doing it that way. &nbsp;When it didn't work, it was recommended to use a startup script. &nbsp;Something as a result of a recent Windows update / security.
</div>


<div>
McKnife: &nbsp;While I remain a bit in the fog per my list, I've implemented the "/f" option in schtasks in the scripts and that seems to have solved *that* problem. &nbsp;Thanks for that!
</div>


<div>
McKnife: &nbsp;Thank you! &nbsp;I think part of my confusion was by testing things outside the GPO - so the permissions were likely twisted. &nbsp;This makes it clear.
</div>


<div>
OK. &nbsp;So now I'm seeing the problem of a file being added to the startup but not showing with "show files".<br>Is it better to modify startup files that are in a GPO or start over with a new GPO?<br><br>I have one notion that starting over with a new GPO is desirable:<br>Example:<br>There is a startup script that only works part way. &nbsp;<br>My idea is that if the script is changed in the GPO then it won't be run again - or may not be run again.<br>But, if a new GPO with a new script is introduced and the old one unlinked or deleted, then that has a better chance of working.<br>??
</div>


<div>
Startup scripts run constantly, over and over, on every restart. So there is no need for a new GPO. Change the script anytime a change is needed.
</div>


<div>
McKnife: &nbsp;Thanks! &nbsp;That's helpful. &nbsp;Context like this is a bit hard to find.
</div>


<div>
<div class="content wysiwyg-content">
I'm developing a number of GPOs. &nbsp;Some of them have computer startup scripts and some create Task Scheduler tasks.<br />
I found, to my surprise, and then not so surprising...., that the scripts had not run or, if they did, they didn't create the Task Scheduler tasks running &quot;schtasks&quot; buried in the script.<br />
It seems that's because no one had logged on with local admin privileges - ever.<br />
Once that had been done, it seems that the scripts ran and the Task Scheduler tasks appeared as was the original intent.<br />
<br />
I hadn't anticipated this and now I'm looking for a solution to the rather obvious:<br />
If a workstation is never logged on with a User having admin privileges (or the equivalent), then how does one get the GPO startup or logon scripts and their contents to run successfully?<br />
Or, is the approach to force an admin logon to complete the process?
</div>
</div>


I'm developing a number of GPOs.  Some of them have computer startup scripts and some create Task Scheduler tasks.
I found, to my surprise, and then not so surprising...., that the scripts had not run or, if they did, they didn't create the Task Scheduler tasks running "schtasks" buried in the script.
It seems that's because no one had logged on with local admin privileges - ever.
Once that had been done, it seems that the scripts ran and the Task Scheduler tasks appeared as was the original intent.

I hadn't anticipated this and now I'm looking for a solution to the rather obvious:
If a workstation is never logged on with a User having admin privileges (or the equivalent), then how does one get the GPO startup or logon scripts and their contents to run successfully?
Or, is the approach to force an admin logon to complete the process?

Getting GPO startup/logon scripts to run and to execute their commands

Active Directory (AD) is a Microsoft brand for identity-related capabilities. In the on-premises world, Windows Server AD provides a set of identity capabilities and services, and is hugely popular (88% of Fortune 1000 and 95% of enterprises use AD). This topic includes all things Active Directory including DNS, Group Policy, DFS, troubleshooting, ADFS, and all other topics under the Microsoft AD and identity umbrella.

Active Directory

A scripting language is a programming language that supports scripts, programs written for a special run-time environment that automate the execution of tasks that could alternatively be executed one-by-one by a human operator. Scripting languages are often interpreted (rather than compiled). Primitives are usually the elementary tasks or API calls, and the language allows them to be combined into more complex programs. Environments that can be automated through scripting include software applications, web pages within a web browser, the shells of operating systems (OS), embedded systems, as well as numerous games. A scripting language can be viewed as a domain-specific language for a particular environment; in the case of scripting an application, this is also known as an extension language.