June 24th, 2008

Hey, Scripting Guy! How Can I Change a Registry Value Named (Default)?

Hey, Scripting Guy! Question

Hey, Scripting Guy! I am trying to change a registry value that has the name (Default). I can change any registry value that has a “real” name, but I can’t figure out how to change one with the name (Default). If I export the value the name shows up as @, but that doesn’t work in my script, either. How do I change a registry value named (Default)?

— TL

SpacerHey, Scripting Guy! AnswerScript Center

Hey, TL. Well, it’s Monday morning as this column is being written, and that comes as a surprise to at least a few people, most notably the Scripting Editor; after all, she didn’t think the Scripting Guy who writes this column would even be alive come Monday morning, let alone be able to come in to work and write this column. That’s because, for his weekend chore, the Scripting Guy who writes this column decided to buy a machete and attack the blackberry bushes that have been growing maniacally in the field behind his house.

“A machete?!?” the Scripting Editor remarked when she heard of his plans. “Those things are dangerous. Do you have any idea what you’re doing?”

“What difference does that make?” replied the Scripting Guy who writes this column. “When do I ever have any idea what I’m doing?”

“Good point,” said the Scripting Editor.

But all’s well that ends well, right? The Scripting Guy who writes this column spent a good 4 or 5 hours hacking away at blackberry bushes on Sunday, and by the time he was done the blackberries had been defeated. (Well, temporarily; if you’ve ever had to deal with blackberry bushes you know that they can never truly be defeated.) In addition to that, the Scripting Guy who writes this column managed to make it into work on time Monday morning.

Oh, and just to put a little icing on the cake, he also had enough fingers and toes left to enable him to write a script that changes a registry value with the name (Default):

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."

Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

strKeyPath = "ScriptCenter"
strValueName = ""
strValue = "http://www.microsoft.com/technet/scriptcenter/default.mspx"

objRegistry.SetStringValue HKEY_CURRENT_USER, strKeyPath, strValueName, strValue

There’s not much to this script, and for good reason: as it turns out, it isn’t very hard to modify the value of a (Default) key in the registry; you just need to know a little trick that lets you get at that value.

So what is that trick? Be patient; we’ll get to that in a second. First, however, we need to note that we’re assuming that you have a registry key named ScriptCenter that lives in the HKEY_CURRENT_USER registry hive. That explains why we start our script off by defining a constant named HEY_CURRENT_USER and setting the value to &H80000001: we’ll need this constant to tell the script which registry hive we want to work with.

After defining the constant our next step is to connect to the WMI service on the local computer, taking care to reference the root\default namespace when binding to the StdRegProv class. Can we use this came script to modify a (Default) key on a remote computer? You already know the answer to that one: of course we can. All we have to do is assign the name of that remote computer to the variable strComputer:

strComputer = "atl-ws-001"

After we connect to the WMI service we then assign values to three different variables:

strKeyPath = "ScriptCenter"
strValueName = ""
strValue = "http://www.microsoft.com/technet/scriptcenter/default.mspx"

strKeyPath is simply the path to the registry key where the (Default) value lives. What if our registry key was something like Software\Internal\ScriptCenter? No problem; we simply assign that entire path to the variable strKeyPath:

strKeyPath = "Software\Internal\ScriptCenter"

strValue is the value we want to assign to (Default); in this case, we’re simply assigning (Default) the URL to the Script Center home page.

That’s cool, but what about this:

strValueName = ""

As it turns out, this is the trick we were talking about. strValueName represents the name of the registry value we want to change. And you’re right: we didn’t actually assign strValueName a name, did we? And that’s the trick: if you set strValueName to an empty string, then WMI will work against the (Default) registry value. Why does it work this way? Beats us. But it does work.

Note. So do the Scripting Guys know stuff like this because they are highly-trained, highly-paid professionals who have to know stuff like this? No, not really. Instead, several years ago the Scripting Guy who writes this column was trying to write a script that would read information from the registry. Each time he ran the script, however, he got some very strange, very unexpected results. Eventually, he figured out that he had forgotten to assign the variable strValueName a value. Because of that, his script was reading the (Default) value instead. That’s how he learned about this little trick.

Needless to say, it’s a good thing the Scripting Guys make as many mistakes as we do; otherwise, we wouldn’t know much of anything!

At that point all we have to do is call the SetStringValue method and let SetStringValue do its thing:

objRegistry.SetStringValue HKEY_CURRENT_USER, strKeyPath, strValueName, strValue

Is that really going to work? If it doesn’t, then the Scripting Guy who writes this column’s name isn’t the Scripting Guy who writes this column.

Note. Well, OK, technically his name isn’t the Scripting Guy who writes this column. But you know what we mean.

And sure, you can use this exact same approach to read the (Default) value in a registry key. Give this script a try and see for yourself:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

strKeyPath = "ScriptCenter"
strValueName = ""

objRegistry.GetStringValue HKEY_CURRENT_USER, strKeyPath, strValueName, strValue

Wscript.Echo strValue

That should do it, TL; like we said, this was actually an easy one, once you knew the trick. As it turns out, wielding a machete was equally easy (and surprisingly fun). Which, needless to say, came as a major disappointment to the Scripting Editor. After all, if anything ever happened to the Scripting Guy who writes this column, the Scripting Editor would finally be able to fulfill her lifelong dream: she would become the Scripting Guy who writes this column! Sorry, Scripting Editor; not this time.

Editor’s Note. The Scripting Editor can’t imagine anyone in their right mind actually wanting to be the Scripting Guy who writes this column. Granted, the Scripting Editor isn’t always in her right mind (she spends a limited amount of time in her left mind, and even more time out of her mind completely), but she’s never been so far away from her right mind that she’d want to be the Scripting Guy who writes this column.

But don’t give up: after all, the Scripting Guy who writes this column still has to climb up on the roof and take care of a few things up there. You might still get your chance after all.

Note. The Scripting Guy who (still) writes this column was really only interested in cutting down blackberry bushes. However, it turns out that machetes are also useful against zombies and vampires. For example, according to the Federal Vampire and Zombie Agency “A zombie without hands or fingers is much less of a threat, so aim your slashes for the zombie’s outstretched hands. Hacking at the hands will also help you avoid getting the blade stuck inside the zombie. As always, your objective should be to buy enough time to escape.”

Of course the Federal Vampire and Zombie Agency also says that “The long knob on the handle minimizes the chance of a machete slipping from the hand at the completion of a slashing blow.” Obviously they haven’t seen the Scripting Guy who writes this column in action, have they?

Author

0 comments

Discussion are closed.