Mr. Script

Stopping Startups

When software clogs up your system tray, it's time to pull out this Roto-Rooter of a script.

One of the most irritating things about working on a computer all day is dealing with software that insinuates itself into everything. I’ve only had my current notebook computer a few months and already the number of applets running in my system tray is in the double digits! Some of these applets are important, and I like the convenience of having them. Some are completely worthless and really get on my nerves. Every time I play a RealMedia file, for example, RealPlayer puts an icon in my tray. No matter how many times I close it, it returns upon reboot. It’s become second nature to simply remove the “Run” entry from the registry after I close down the player.

But users, on the other hand, likely don’t know how to (and shouldn’t) delete a registry entry (or ever, ever edit the registry at all). Unless you work for a company that has figured out the magic spell to keep users from installing additional software on their machines, chances are you regularly receive calls to help someone figure out why their computer is, “so slow,” only to get to their desk and find that their system tray is so clogged with useless tripe that it’s a wonder anything works at all. As administrators, it’s our job to keep our users up and running efficiently. And instructing your users to, “check with me before you install anything,” just ain’t gonna cut it. Besides, some of this “system tray junk” comes from applications we installed!

The challenge is to find all these startup items and get rid of the ones users don’t need. Now, you could use regedit to search both the HKEY_LOCAL_MACHINE and HKEY_USERS “Run” keys in the registry, then look at the startup menu (not forgetting to check the “All Users” profile), but there’s an easier way.

<?xml version="1.0" ?>
<package>
<comment>
EnumStartup.wsf
This script enumerates all startup commands for a local or remote machine.
</comment>

   <job>
      <runtime>
      <description>

      This script uses WMI to connect to the local or remote computer
      and return a list of startup commands. This list includes all
      items in the startup menu as well as the registry "Run" keys.
      </description>
      <example>

      C:\cscript EnumStartup.wsf /Target:value /File:value
      </example>
      <named
        name="
Target"
        helpstring="
The name of the target computer"
        type="
string"
        required="
true"
      />

      <named
        name="
File"
        helpstring="
The name of the text file to store the data"
        type="
string"
        required="
true"
      />
      </runtime>
      <object id="
objFSO" progid="Scripting.FileSystemObject"/>
      <script language="VBScript">

      <![CDATA[
      Option Explicit
      CONST ForAppending=8
      Dim strComputer, strFile, objFile, objWMI, colStartUp, objItem
      strComputer = Wscript.Arguments.Named.Item("Target")
      strFile=WScript.Arguments.Named.Item("File")
      Set objWMI = GetObject("winmgmts:{impersonationLevel=
                   impersonate}!\\" & strComputer & "\root\cimv2")
      Set colStartUp = objWMI.ExecQuery("Select * from
                       Win32_StartupCommand")

      Set objFile=objFSO.OpenTextFile(strFile, ForAppending, True)
          For Each objItem in colStartUp
             objFile.WriteLine "Command: " & objItem.Command
             objFile.WriteLine "Description: " & objItem.Description
             objFile.WriteLine "Location: " & objItem.Location
             objFile.WriteLine "Name: " & objItem.Name
             objFile.WriteLine "SettingID: " & objItem.SettingID
             objFile.WriteLine "User: " & objItem.User
             objFile.WriteLine
          Next
          objFile.Close
          Set objFile=Nothing
      ]]>

      </script>
   </job>
</package>

How It Works
This script uses WMI and the FileSystemObject to collect the information from the target computer and place it into a nicely formatted listing in a text file. I passed the path and name of the text file as an argument, as well as the name of the target computer. I took this approach because it’s likely this script will be used “on request,” meaning you probably won’t ever need to run it against a lot of computers at one time. You can even change it to simply echo the information to the screen rather than write it to a file. If you decide that you need to run this script on many or all computers in your organization, the script can be easily modified to get the list of computers from a file rather than a command-line argument.

Once you have the information safely tucked away in a text file, it’s a (relatively) simple task to look through and determine what doesn’t belong. I say “relatively” because I’ve seen some huge listings come from running this script. It never ceases to amaze me how bloated some users allow their computers to get!

The GUI Way vs. the Scripting Way
In the paragraph before the script listing, I misled you a bit. I made it seem like the process of manually finding startup items was difficult. On the contrary, the Windows System Information applet lists this very information under “Software Environment _ Startup Programs.” If all you need to do is find what’s starting on your own machine (or if you’re already at the user’s desk), this is definitely the way to go. However, it’s more likely that the need to perform this search on a user’s machine will be the result of the aforementioned, “Why is my computer so slow?” request. Using WMI allows you to perform this task remotely.

Now that you’ve gotten rid of the useless startup items, you need to check your users’ machines for unauthorized/useless/outdated applications. Next month, I’ll show you a script to do just that. Don’t touch that dial!

Note: It’s actually very easy to disable the tray icon of RealPlayer from the context menu. But, hey, I needed a dramatic example to get your attention, didn’t I?

About the Author

Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].

comments powered by Disqus
Most   Popular

Upcoming Training Events