Getting GPO startup/logon scripts to run and to execute their commands
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?
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?
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.
So again: https://www.experts-exchange.com/articles/25279/Overcoming-software-deployment-pitfalls-on-modern-Windows.html
(note: it's about software deployment, but I am talking about scripts and tasks, too and explain why).
So again: https://www.experts-exchange.com/articles/25279/Overcoming-software-deployment-pitfalls-on-modern-Windows.html
(note: it's about software deployment, but I am talking about scripts and tasks, too and explain why).
ASKER
kevinhsieh: Thanks for the questions!
A good example of using Task Scheduler is to have workstations reboot at 11 p.m.
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).
re: the admin logon. An admin had not logged on *since* the GPO was deployed.
McKnife: Thanks for the repeated link!
A good example of using Task Scheduler is to have workstations reboot at 11 p.m.
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).
re: the admin logon. An admin had not logged on *since* the GPO was deployed.
McKnife: Thanks for the repeated link!
ASKER
McKnife: OK. I read the article and found it very informative. It makes me think that turning off fast startup might be a good idea. We force restart of all the computers every night anyway and don't turn them off. So, "cold" boots (with hibernating kernel) are rarely seen if I understand what you say about that.
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". I'm not completely sure but this question is part of figuring it all out.
I encountered a computer or two yesterday that had not had GPOs updated since February!! Yet, I've had a number of GPO deployments since. 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.
Scribbling out the steps I envision:
- Develop GPO with Startup script included. (Startup script creates a scheduled task and a .bat file)
(The scheduled task comes from an .xml file. The bat file is simple and is constructed with in-line script code).
- Deploy GPO
- (Workstation receives GPO ... maybe multiple steps here)
- Startup script goes into workstation
- Reboot (by demand / not cold)
- Startup script runs (as who? permissions? depends on context/commands?
Creates a scheduled task - permissions again....
Creates a .bat file - permissions again...
Now, of course, when the workstation is rebooted, it isn't logged onto a User account.
So, the next User logon will be whatever human action determines.
I know I'm missing something here.....
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". I'm not completely sure but this question is part of figuring it all out.
I encountered a computer or two yesterday that had not had GPOs updated since February!! Yet, I've had a number of GPO deployments since. 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.
Scribbling out the steps I envision:
- Develop GPO with Startup script included. (Startup script creates a scheduled task and a .bat file)
(The scheduled task comes from an .xml file. The bat file is simple and is constructed with in-line script code).
- Deploy GPO
- (Workstation receives GPO ... maybe multiple steps here)
- Startup script goes into workstation
- Reboot (by demand / not cold)
- Startup script runs (as who? permissions? depends on context/commands?
Creates a scheduled task - permissions again....
Creates a .bat file - permissions again...
Now, of course, when the workstation is rebooted, it isn't logged onto a User account.
So, the next User logon will be whatever human action determines.
I know I'm missing something here.....
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.
Scheduled tasks can be managed via Group Policy Preferences, which seems like a better framework than a startup script.
http://www.mdmarra.com/2014/04/managing-scheduled-tasks-from-group.html
http://www.mdmarra.com/2014/04/managing-scheduled-tasks-from-group.html
ASKER
kevinhsieh: Thanks for the suggestion!
Yes, I had originally started out doing it that way. When it didn't work, it was recommended to use a startup script. Something as a result of a recent Windows update / security.
Yes, I had originally started out doing it that way. When it didn't work, it was recommended to use a startup script. Something as a result of a recent Windows update / security.
ASKER
McKnife: 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. Thanks for that!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
McKnife: Thank you! I think part of my confusion was by testing things outside the GPO - so the permissions were likely twisted. This makes it clear.
ASKER
OK. So now I'm seeing the problem of a file being added to the startup but not showing with "show files".
Is it better to modify startup files that are in a GPO or start over with a new GPO?
I have one notion that starting over with a new GPO is desirable:
Example:
There is a startup script that only works part way.
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.
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.
??
Is it better to modify startup files that are in a GPO or start over with a new GPO?
I have one notion that starting over with a new GPO is desirable:
Example:
There is a startup script that only works part way.
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.
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.
??
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.
ASKER
McKnife: Thanks! That's helpful. Context like this is a bit hard to find.
How do you setup machines where an admin NEVER has logged in.