Login Scripts are executed each time a user logs onto a computer.
Start-up Scripts are executed each time a computer is powered on.
- Run under the context of the user who is logged on
- They have the same permissions and "reach" as the user
- Since the user has network access, so does the script
- Run under the Local "SYSTEM" user context prior to the login screen
- They run in SYSTEM context
- Since the SYSTEM account has no network access, neither does the script (by default, but please read on...)
With start-up scripts, the processing occurs after the Windows kernel is loaded and initialized, but prior to the CTRL-ALT-DEL prompt. It runs under the local "SYSTEM" account context, so it has local administrative rights. However, by default, it does not have any rights outside of the computer. Whereas a user account typically is domain-based, it has rights to at least some remote resources (shares, folders, files) over the network. The SYSTEM account does not. There is another local account which is intended for such uses, named "Network" or "Network Service" (depending upon which Windows version you're using).
From the perspective of an Active Directory or NetBIOS (workgroup) environment, when a task runs as SYSTEM and tries to reach out to remote resources, it is seen as COMPUTER$ (where COMPUTER is the NetBIOS name of the computer). This account exists in Active Directory for the purposes of establishing and maintaining trusts and delegation rights to enable the computer to participate within the domain. Computer accounts are only added to the "Domain Computers" group, which in turn is NOT added to any other groups - by default. Therefore, it has no inherent (explicit or implicit) rights to anything over the network. This is the single-most often troublesome issue for people wanting to use start-up scripts. They forget to grant permissions to remote shares/folders for either the explicit COMPUTER$ account, or the "Domain Computers" group. Once that's done, things usually work well.
Anyone who has rolled out SMS 2003 or SCCM 2007 knows this all too well. The AD schema extension is only part of the work. Then you have grant permissions to the System Management container so that the SMS/SCCM server can "publish" things into it. This is because the service itself is running under the local SYSTEM context and reaches out as COMPUTER$ to touch things. I'm a HUGE proponent for using this same approach to all automation tasks. No more managing passwords or worrying who knows the password. Just restrict admin rights to the computer itself and it takes care of the rest. Simple. Clean. Reliable.
Back to the original rant.
If you need to run a script to perform tasks that are beyond the rights of the users who logon, you may want to consider a start-up script. If you want to run things within the bounds of what the users can do, a login script is fine.
Now, all that blabbering aside: If the computers you are dealing with are all desktops and servers, normally connected and powered on at all times, you can also employ a centralized script approach, where you run a script "on demand" from your workstation, to reach out and touch all the other computers. However, if you have an environment where some computers are often "off the network" (read: laptops), then a start-up or login script is probably a better approach. Because it essentially waits for the computer (or user) to invoke it, rather than taking the shotgun approach and risking a failure when the remote client is unavailable.
Phew. I'm done. I hope this makes sense and helps someone. I'm sure many of you will roll your eyes and think "I already know this" which is fine. I was aiming this at anyone who still isn't clear about these issues. I need to get something to eat now. Cheers!