"Run" command discovery – aha! that’s how

A simple task, …I wanted to pull up some system information quickly to check what memory exists on a server and so brought up Run in Windows Server 2003. Then I thought the command was “System32” so I entered that; the result I got was unexpected but nevertheless cool. (BTW “msinfo32” would have been the correct command) I was instead taken directly to C:\Windows\System32.

What I then wondered is what other such alias paths might exist. Is this simply a result of the Path variable? What makes this work and can I add my own shortcut/aliases. Is the plural form of alias – aliases or aliai? …but I digress

So I Googled this for myself … and learned some interesting stuff which I’ll share:

http://weblogs.asp.net/whaggard/archive/2004/04/11/111232.aspx

The run command (ShellExecute, as you said) also supports keyword expansion, so you can type any special path that’s in your environment variables and go the the appropriate directory:
My Documents
System32
Temp
ProgramFiles
HomePath
AppData
etc.
To see what’s in your list: win-r, cmd, set.

And also this quote off that same page:

After thinking about if awhile I hunted down how the run command works.  It turns out that it makes a call to ShellExecute, which I guess is not too surprising.  The next thing I wanted to find out was exactly how the commands are resolved. The following is an ordered list of how they are resolved ([1]):

· The current working directory

· The Windows directory (no subdirectories are searched)

· The Windows\System32 directory

· Directories listed in the PATH environment variable

· The App Paths registry key

And here are lists of several hundred commands that can be invoked via Run:

· http://www.usp.br/fzea/admin/files/2061_Windows Run Commands.htm

Blackberry Server Software, MDS, & Java Update Mayhem

A fundamental relationship exists between BlackBerry server software and Java Runtime Engine software.  This relationship specifically relates to the BlackBerry MDS Connection Service.   This becomes very apparent if ever on the related server you update Java to a current version and remove the older version(s).  Now Java does this cleanup of older versions automatically with the introduction of Java version 6.10.  Without the correct pointer to the latest changed Java version, the BlackBerry MDS Connection Service will become effectively broken.  The pointer is a registry entry that refers to the associated jvm.dll file of a version of Java you have installed.  Note – if you have multiple versions of Java then you have multiple jvm.dll files on your system.

It’s been a little while since I originally posted on this; in fact, since then RIM has introduced some new server products that are basically all the same code foundation.  This means that the same solution still applies wherever MDS is involved.  Perhaps in the future RIM will find a way to automatically make the adjustment, but for now you will have to do the steps yourself.  The nice thing, as you will see below, is that Java may help by using a consistent path with updates of the same version.

The path to the Java jvm.dll file has been changed; the new path is:

C:\program files\java\jre6\bin\client\jvm.dll

Use this link to the previous article for the outline of the registry editing steps involved:

http://duitwithsbs.wordpress.com/2008/08/05/bmds-errors-galore-after-removing-old-java-version-from-bes-server/

Hyper-V Management Configuration Made Easy

For those who wish to use and deploy Hyper-V, this ‘freeware’ tool helps make the management UI configuration a cinch.

http://code.msdn.microsoft.com/HVRemote

The author, John Howard, is a Program Director in the Hyper-V team. He created this over a recent vacation and just published it for public download. This makes the configuration of Hyper-V Remote Management Tools a far easier experience than what is was prior; in fact John claims it takes but seconds now!

If you invest any time reading his blog you quickly realize how greatly he has mastered the usage of and written the guiding instructions for its adoption.  This tool is a further of extension of his outstanding community commitment to helping this product find its way.

This covers both the client (Vista SP1) & server (Win2008) and both domain & workgroup scenarios …in other words, all the bases

http://blogs.technet.com/jhoward/archive/2008/11/14/configure-hyper-v-remote-management-in-seconds.aspx

Microsoft Certified Professional Magazine Online | Feature Article: Automate Your Security

This is still very helpful though written 4 years back.  The script that brought this article to my attention involves automating the routine of replacing local administrator passwords. The suggestions of using error handling and an output txt list of the failed computer accounts so that you correctly and completely standardize the passwords at some future time.  A heterogeneous password environment could be nightmarish to manage.

Automate Your Security
Many security-related tasks can be tedious—and, therefore, overlooked. Using these 10 scripts can make your life easier, while simultaneously locking down your network.
by Don Jones

Security, of course, has become a lot more important than it used to be in the “old days,” when we were merely concerned about keeping all the servers up and running. Unfortunately, much of security involves routine, repetitive tasks, like backing up event logs, keeping track of service account passwords and so on. There’s a growing market of third-party utilities out there to help manage those tasks, but the concern about security has coincided with reductions in IT budgets, making it difficult to buy every new tool that promises to do the job for you.

Fortunately for the harried administrator, Windows comes with two perfect built-in tools that can handle much of your security automation: Windows Script Host (WSH), and VBScript. While I won’t promise that WSH can stop hackers and take your next certification exam for you, it certainly can remove the monotony out of many security-related tasks. In fact, simply having some automation around makes it more likely that you’ll do these boring tasks to begin with, thereby making your environment that much more secure.

Changing the Local Administrator Password
Enough with services and service accounts. Another tedious task is periodically changing the local Administrator password on every computer in your company. You know you should do it, but who has that kind of time? Scripts do! Once again, start with an input text file that lists one computer per line. In case you’re wondering, it’s also possible to retrieve a list of computers from AD, an NT domain or even a database, with a little bit of extra programming.

This script starts out similarly to the last, by opening a text file and using a “Do…Loop” construct to iterate through each line of the file. However, this script doesn’t connect to a WMI provider on each computer. It relies on the Active Directory Scripting Interface, or ADSI, to connect. Wait a sec—ADSI? Does this only work on 200x domain controllers? Nope, this script will run against everything from NT 4.0 on up, including NT Workstation, 2000 Pro, and XP Pro, because all NT-based operating systems have an NT domain-like Security Accounts Manager (SAM). Notice how the ADSI connection uses the “WinNT://” moniker, which tells ADSI to stay NT-compatible.

The ADSI connection specifically queries a user account named “Administrator,” and then changes its password and saves the change back to the SAM. You can run this script on a monthly basis, if you like, with a word of warning: As written, the script doesn’t include any error handling, so it will crash if one of the specified computers isn’t available at the time. A quick and dirty way to bypass the crash is to add:

On Error Resume Next

As the first line of script code. This will cause the script to ignore any errors and try the next computer in sequence. If you want to be a bit more thorough, you could save the failed computer names to a new text file, which could be used to run the script again the next day.

‘Create a FileSystemObject
Set oFS = CreateObject(“Scripting.FileSystemObject”)

‘Open a text file of computer names
‘with one computer name per line
Set oTS = oFS.OpenTextFile(“c:\computers.txt”)

‘go through the text file
Do Until oTS.AtEndOfStream

  ‘get the next computer name
  sComputer = oTS.ReadLine

  ‘retrieve that computer’s local Admin
  Set oUser = GetObject(“WinNT://” & _
  sComputer & “/Administrator, user”)

  ‘reset the password
  oUser.SetPassword “New!Ad3in”

  ’save the change
  oUser.SetInfo
Loop

‘close the text file
oTS.Close

Microsoft Certified Professional Magazine Online | Feature Article: Automate Your Security