Login Scripts vs Start-Up Scripts

This isn't aimed at anyone in particular, but to a lot of folks in general that seem to be confused about the intent and differences of using login scripts versus start-up scripts. If you think I'm aiming this at *you* in particular, I apologize, not my intention. In any case, I find myself in the middle of explaining the differences quite often, as well as helping friends resolve problems with both. Some very common issues seem to occur with these which are usually simple to avoid or solve. In the simplest terms...

Login Scripts are executed each time a user logs onto a computer.

Start-up Scripts are executed each time a computer is powered on.

Login Scripts:

• 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
  

Start-Up Scripts:

• 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...)
  

If a user does not have elevated permissions (i.e. is not a member of Administrators or Power Users group) the Login script can only do so much. It won't be able to stop privileged processes or threads, install or uninstall software, modify privileged services, modify protected folders and files or modify system registry keys (e.g. HKEY_LOCAL_MACHINE, etc.). If the user has administrative rights, the script can do pretty much anything. (note: God, I really hope you don't routinely give users administrative rights. There's rarely any reason for that nowadays. There are many options available.)

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!