"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/

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

Drive Formatting 16K Cluster to Avoid Loss of Volume Shadow Copy Snapshots

Recommended Reading: Shadow copies may be lost when you defragment a volume
http://support.microsoft.com/kb/312067/ – MS document on VSS 16KB cluster best practice

Well, after seeing System Error 25 VolSnap too many times and realizing each time it appears all  Volume Shadow Copy snapshots were being dumped, I decided to dig into this.  Why?  Because those VSS snapshots are very valuable safety nets that users rely on.  Things like redirected My Documents …etc are highly valuable and worth having an extra version to fall back to.

What I discovered is that whenever a defragmenter runs against the default 4 KB (SBS/Win2k3) cluster size these events occur.  I experienced this testing out Diskeeper and then PerfectDisk (Raxco) but also see this when running the native Microsoft defragmenter.  Further research shows that the cluster size needs to be 16 KB for VSS.

So next time you create a data partition my best practice advise to you is to raise the cluster size up from the default to 16 KB (or a greater size).

Although this blog was written a couple of years ago for Windows Server 2003 this still applies in the Server 2008 product.  How do I know?  I asked the Server 2008 VSS team in their blog at the time of launch earlier this year.  What was amazing is that they gave me the impression by the tone of their response that didn’t seem to understand that this issue was relevant or significant.

Here’s the 3/24/2008 response I got from Greg Jacklin via Jim Benton:

“Although volsnap and defrag/ntfs do their best to get along, it is still
best to format with a 16K cluster size for performance.
-Greg”

BTW if you think your heard about this before but you can’t remember where perhaps it was via Wayne Small or Microsoft.  Below are these historical references:

• Hack#95 – Work with Shadow Copies
• KB833167 – A Volume Shadow Copy Service (VSS) update package is available for Windows Server 2003

 

There are some other planning & “hot fix” articles from MS that address some aspects of snapshot dumping; nevertheless, remember that the root cause is that your cluster size isn’t large enough.

Overview Info:

• Default cluster size for FAT and NTFS
• How Shadow Copies for Shared Folders Work
• Volume Shadow Copy Service Technical Reference (Oct’03)
• Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 (for larger than SBS environs)

 

Hotfixes:

• A Volume Shadow Copy Service (VSS) update package is available for Windows Server 2003 (Oct ‘05)
• Time-out errors occur in Volume Shadow Copy service writers, and shadow copies are lost during backup and during times when there are high levels of input/output

Reserving a TCP Port in Windows

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts

Above is the registry key that needs tweaked in order to reserve a TCP port. This will protect this port from any inadvertent randomn future assignment by software, patch, or service as what has happened over this past week with the DNS patch.

http://blogs.technet.com/sbs/archive/2008/07/17/some-services-may-fail-to-start-or-may-not-work-properly-after-installing-ms08-037-951746-and-951748.aspx

http://support.microsoft.com/kb/812873