Give the My Computer Icon a User Name
It is handy to be able to just look up at the My Computer icon and see where you are and what name you are using.
>Last month, we created a script that used Windows Management Instrumentation (WMI) to manage Registry permissions. While it didn’t allow changing those permissions (a limitation of the WMI Standard Registry provider—StdRegProv), it did provide useful functionality to determine the rights of the current user. Furthermore, it got me thinking about how often I find myself digging into the Registry and how limited the “standard” scripting tools are at providing this capability.
I’ve covered the topic of editing the Registry via scripting a few times over the years and have always relied on one of two methods:
The WshShell Object—In addition to managing
special folders, logging events, creating shortcuts and other assorted
responsibilities, the WshShell object has two methods for managing the
registry: RegRead and RegWrite. While it’s fast and easy to use, it isn’t
well suited for anything but the simplest Registry editing tasks.
The WMI StdRegProv—WMI is virtually god-like
in its capabilities. Unfortunately, it’s quite complex and can be daunting
to anyone who hasn’t devoted at least six weeks to learning its extensive
object model. The WMI Object Browser doesn’t make things any easier, either.
You’re probably thinking, “What’s a burgeoning scripter supposed to do?
Is there no middle ground?” Indeed, there is!
Component-Based Registry Scripting
The Registry Object (RegObj.dll) is an ActiveX component created by Microsoft
that allows you to manipulate the Registry from within your scripts in
a straightforward but flexible manner. It blows away the WshShell object
in terms of capability and is much easier to use than WMI. In fact, about
the only Registry editing function WMI can perform that RegObj can’t is
|RegObj.dll has objects for
each part of the Registry, including constants. (Click image to view
Before you can write a script with this little gem, you need to download
it. One place to get the component is from http://cwashington.netreach.net.
It’s packaged as registry_object.zip, and it needs to be extracted to
your system32 directory and registered:
Once the component is registered, you can access it from within your
scripts—just like any other component—either by using the CreateObject
statement in the script code or by referencing it using the
tag in the XML portion of your .WSF scripts. I recommend the latter, for
reasons that will become apparent. You can view the RegObj type library
from within XRay.exe (my favorite free type library viewer). Load the
component into XRay (or your preferred object browser) and take a minute
to get familiar with the RegObj object model.
Now that you’ve downloaded, installed and registered this component,
let’s get right into using it.
This script changes the text displayed under the 'My Computer'
icon from "My Computer" to the name of the currently logged
on user, the computer or both.
Script changing My Computer
to current user or computer
helpstring="'U' for username; 'C' for computername;
'B' for both"
What’s Your Name?
This script performs one of my favorite Registry tweaks: changing the
name displayed under the “My Computer” icon on the desktop (and inside
Windows Explorer) to the name of the user who is currently logged on,
the computer name or both (displaying just the user name is the most useful
for me). How this is accomplished depends upon which version of Windows
you’re running (see the “References” sidebar in the online version of
this article), but this script can be quite useful! As administrators,
we often go from server to desktop to server logging in and out under
a variety of names. Sometimes we log on as ourselves, sometimes as the
local administrator, and sometimes under the domain admin account. It’s
handy to be able to just look up at the My Computer icon and see where
you are and what name you’re using.
|The good news is that, regardless of which version of Windows you use, the “My Computer” text information is stored in the same Registry key (that long CLSID key listed in the script). This simplifies things somewhat. Under NT 4.0, Ref1, the text is stored in the default value of this key. To use an environment variable in the Registry, the value type must be REG_EXPAND_SZ (a variable length string). Alas, the current value type is set as REG_SZ (a fixed length string) because the length of the string—”My Computer”—doesn’t change! With Regedit, once a value has been created, you can’t change the value type. You can only delete the old value and create a new one of the appropriate type. RegObj allows you to change the value type of the default value to REG_EXPAND_SZ. You can then change the data to display the appropriate text.
With Windows 2000, Ref2, this text is stored in the
“LocalizedString” value (also having the value type REG_SZ). You don’t want to change the entire string, just the last bit, so you put the data from this value into a temporary string and replace the last 11 characters (“My Computer”) with the appropriate text, and change the type to REG_EXPAND_SZ.
Windows XP, Ref3, uses the same value as Win2K and is ahead of the game in that the value type is already set as REG_EXPAND_SZ. However, with XP, you delete all the old data in the value and replace it only with the appropriate environment variables. In order to revert to the standard “My Computer” at a later date, you must save the existing data in a separate value. (With NT 4.0 and Win2K, all you have to do is change the appropriate value back to “My Computer” and change the value type back to REG_SZ.) In this case, you just create a new value called “LocalizedString.old” to store the original data.
Always Check Your References
If you think back to last month’s script, the first thing I did was set
up constants for both the root keys and permissions that mapped to the
appropriate hex values used by WMI. I only set up the ones I was using
in the script, so it was no big deal. However, if I were building a script
to have any degree of flexibility, I’d be required to set up all those
values as constants. A slightly bigger deal, no?
Remember earlier when I said that I recommend using the
tag to reference the RegObj component? Well, this is so important because
it allows me to use the reference attribute in the object declaration.
This gives me access to all the constants included in the RegObj component.
Bottom line: You don’t have to declare a bunch of constants. You can reference
the constants in the type library directly by name and be assured they
hold the correct values.
This script still has some areas where it can be improved. First, if the data in the key doesn’t match the expected default values, the script quits without making any changes. Second, it performs no verification that the OS specified in the argument is, indeed, the correct OS. See what you can do to correct these issues.