The Startup Script is Dead
Get ready to have an opinion! 
Matthew Reynolds (https://twitter.com/MatthewMWR) here with my personal advice (not announcing any product changes) about which configuration vectors are working well and which are not—for today and tomorrow’s enterprises.
Any of these sound familiar?
· “I need to run <insert IT task> on every PC in the organization.”
· “Our startup scripts don’t run reliably”
· “People are complaining about slow logons”
We’ve all faced these scenarios right? In IT we need to run jobs on managed machines—whether to set a registry value, update files, fix a management agent or <insert automation challenge of the week>.
Boot & logon (particularly on client machines, but increasingly even for servers) have become an IT dead zone where automation and configuration vectors fall apart. Meanwhile people are stuck waiting for slow starting machines while traditional IT tasks (whether Foreground Group Policy, auto-start services, boot triggered scheduled tasks, etc.) time-out and fail in the background. No one wins.
How did boot and logon become unreliable triggers for configuration and automation?
Echoing the ghost of autoexec.bat—old school IT folks like me have historically used boot triggered vectors like startup scripts, logon scripts, auto-start services, et al. for jobs that had nothing to do with powering up the machine. Instead we were using startup & logon as a proxy for “do this task periodically.” Modern Windows devices, however, are more likely to sleep or hibernate between user interactions. Traditional boot and logon have become infrequent and irregularly timed for many.
Worse still is the state of corporate network connectivity during startup and logon. Unlike our 1990s open Ethernet LAN where the DC was under a friend’s desk—modern devices are likely to be on a home office, coffee shop, conference center, or airport network during startup and logon. Even in the office or datacenter good connectivity to DCs and other corp resources during boot is no sure bet. Network virtualization, cloud hosting, VLAN switching, 802.1x, IPSec, host based firewall initialization, spanning tree calculation, media sense, duplex negotiation, etc. often result in poor connectivity during startup.
In the past we’ve sometimes encouraged people to turn knobs on the OS like “Always wait for the network…” or “ExpectedDialupDelay” in attempts to resuscitate this zombie. In many cases these just result in ever longer timeouts and productivity delays.
IT culture will have to adapt to the new normal. Moving forward the most productive configuration vectors will be those which are not tied to startup.
Some good alternatives to boot triggered IT automation and configuration
For installing server roles, setting OS configuration, etc. consider Desired State Configuration (DSC)
For the unfamiliar, DSC is like a DevOps version of Group Policy. It allows you to define your desired end state in an easily distributable standards based document, and then say “make it so” to the DSC resources included in or added to the OS. DSC can be used standalone or as an aspect of orchestration frameworks such as Chef (https://redmondmag.com/articles/2015/04/10/devops-automation-and-container-support.aspx).
DSC is Microsoft’s strategic direction for configuration management. Currently DSC culture is Server/cloud/DevOps centric, but I expect usage will grow to encompass more traditional on-prem Server usage. I also expect it will be integrated into many management frameworks, and even become a factor in client device configuration management.
For mapping drives, settings registry values, etc. consider Group Policy Preferences
GPP is old news, but can’t be ignored in this discussion. For many client-centric startup and logon script scenarios there are alternatives like GPP: Registry, GPP: Environment, and so on. The rarely discussed advantage of GPP is that (for the most part) it doesn’t have to block your logon waiting for the network during boot. GPP items can run in the background during the day when the machine is stable and online. Starting with Windows 8.1 even GPP: Drive Maps can run asynchronously (not logon blocking).
For things that traditional Group Policy is good at and don’t require boot time processing Group Policy is still great!
Administrative Templates OS and app settings, User Rights Assignment, Security Options, Audit Policy, et al. on domain joined machines remain great uses of Group Policy. As of today Group Policy covers many areas that DSC does not, and vice-versa. Overlap may increase over the years, but for scenarios that work well there is no need to abandon Group Policy.
There are tasks for which Group Policy was never a good fit (like Software Installation), and there are scenarios which have aged poorly (Startup Scripts), so consider migrating away from these.
As you migrate away from boot/logon time dependencies from Group Policy, also consider retiring settings like “Always wait for the network” and “ExpectedDialupDelay” so GP can happily process in the background without blocking users from doing their jobs.
For installing software, updating antivirus, deploying OSes, etc. use existing management frameworks for jobs they are good at
Robust frameworks exist inside and outside Microsoft for installing software, updating antivirus, deploying OSes with task sequences, etc. In the spirit of https://blogs.technet.com/b/fdcc/archive/2010/10/06/sticking-with-well-known-and-proven-solutions.aspx evaluate your startup scripts (and similar tasks) to see if another good enterprise solution exists already.
Of course as IT folks we often have to be the glue that fills the gaps. Some scripts should remain scripts, but how should we launch them outside the IT dead zone at startup?
For scripts and everything else: Scheduled Tasks can be your secret weapon
Windows scheduled tasks are a flexible and robust way to do IT automation—particularly for one-off cases where a broader framework would be overkill. Scheduled tasks give you fine grained control over scheduling, retries, security context, and conditions (like network connectivity). Task Scheduler is now a core component of Windows relied upon by Plug and Play, Group Policy, Diagnostics, PowerShell jobs, and more. Google relies on Task Scheduler to keep Chrome up to date. Unlike startup and logon scripts scheduled tasks always run independently of your logon critical path. Even if a logon triggered task takes a long time to run it will not block your logon.
To create Scheduled Tasks at scale, you can use one-time fan out approaches (suitable for modest number of reachable online servers) like PowerShell’s New-ScheduledTask. For broader reach you can also use pull based approaches like GPP: Scheduled Tasks.
With GPP: Scheduled Tasks you get all the goodness of Group Policy (e.g., scoping, layering, etc.), Group Policy Preferences (e.g., item level targeting), and the Windows Task Scheduler.
Need to run a script on thousands of machines, but not more than once a month—and it shouldn’t start until the network is online-- and the script needs to do system level stuff without the end-user being a local admin—and the script should never block the user from logging in? GPP Scheduled Tasks can do that.
Creating a GPP Scheduled task
Creating a GPP scheduled task is very similar to creating any ordinary scheduled task through the Task Scheduler user interface.
Naming the task and setting general parameters
Configuring one or more triggers
Configuring one or more actions
Configuring other conditions and settings
A few gotchas to be aware of with GPP: Scheduled Tasks
1) When configuring a GPP scheduled task as part of Computer Configuration, you’ll need to decide what security context it will run under. Typically in the machine context you would use a system account such as one of the following. As always use the account with the least privileges needed to do the task
a. NT AUTHORITY\LOCAL SERVICE
b. NT AUTHORITY\NETWORK SERVICE
c. NT AUTHORITY\SYSTEM
2) Sometimes the user account field doesn’t seem to save correctly when first creating the GPP Scheduled Task item. Try re-opening the item in the editor and fixing the user account information (if needed) after initial creation
3) Sometimes people hit this scenario (seems more likely with older versions of GP editor) where “NT AUTHORITY\SYSTEM” gets saved in the task definition as a group which causes the task item not to be applied. I have not encountered this but be aware: https://trentent.blogspot.com/2014/10/group-policy-preferences-scheduled-task.html
4) Under Conditions > Start only if the following network connection is available the only option in the group policy editor is “any connection”. If you need to configure more specific conditions such as connectivity to a specific corporate network you can use New-ScheduledTask or schtasks.exe instead of GPP: Scheduled Tasks. You might still use GPP: Scheduled Tasks to trigger the launch of a script that creates other more complex tasks.
a. Coincidentally I use this pattern frequently… deploy a simple GPP: Scheduled Task as a scale-out bootstrap more complex actions (which may involve creating additional scheduled tasks)
A few gotchas for scheduled tasks and IT automation in general
1) As with any management tool-- you can easily do more harm than good here. Don’t create expensive tasks or tasks that run frequently.
2) As with any IT automation— take care to not accidentally create an escalation of privilege vector for non-admin end users. If your task will run as a privileged account (typical for system administration tasks), the task must not run any code that could be modified by non-admins such as a script stored in a non-secure location.
3) For tips on managing PowerShell version levels, execution policies, etc. for an enterprise (helpful when launching PowerShell scripts broadly (e.g., using scheduled tasks) see Ashley McGlone’s recent post https://blogs.technet.com/b/ashleymcglone/archive/2015/04/22/pshsummit-managing-powershell-in-the-enterprise-using-group-policy.aspx
May your old Startup and Logon scripts rest in peace.
-Matthew “start me up” Reynolds
https://twitter.com/MatthewMWR