Before .NET and PowerShell were dreamt of, VBScript and COM objects were the most powerful scripting tools available in a vanilla Windows install. Using Microsoft’s default facilities is worthwhile because it obviates the need to deploy additional software and cope with that software’s life cycle and incompatibilities. For instance, a script written for Windows 2000 is likely to continue working in Windows Server 2008 x64 Edition. I use PowerShell/.NET for Windows scripting now, but I still regularly use VBScripts which are several years old. Here are several of these simple scripts.

Backgrounder

First, a backgrounder — VBScript has been installed by default since Windows ‘98. The core language is limited, and it relies on objects to perform any actual work. Even file I/O or regular expressions require object creation. Several class libraries exist for more involved tasks, such as e-mail (CDO), XML (Msxml2), and Windows Management (WMI).

Two of the larger class libraries are offered by Windows Management Instrumentation (WMI) and Active Directory Services Integration (ADSI). WMI provides a consistent interface to Windows’ hardware and software configuration, while ADSI manipulates accounts, computers, and other objects in Active Directory. Combined, these facilities can systematically perform the bulk of system administration tasks.

This zip file contains the following VBScripts to perform simple administrative tasks. They are in the Windows Scripting File (WSF) format, which is an XML format that encapsulates scripts in XML while adding support for type libraries and limited self-documentation and help facilities. The WMI and ADSI scripts can run locally or on a remote machine.

Download WSF Collection

The ZIP file includes the following scripts:

Windows Management Instrumentation (WMI)

adapt.wsf

View or change network configuration, including IP address and
DNS/WINS servers. Operates locally or remotely. Note that no changes
take place without the “/set” option.

rdp.wsf

Display, enable, or disable Remote Desktop on a Windows XP computer. Unlike
the registry edit, this script can remotely enable RDP without a reboot.

specs.wsf

Display basic tech specs of the passed computer / domain

who.wsf

Display who is logged in to Windows’ console.

Active Directory Services Interface (ADSI)

addtoadmin.wsf

Add specified user (/user:userid) to the local administrators group of the
specified computer(/computer:hostname).

openfiles.wsf

List files opened through Windows file sharing.

user2sid.wsf

Print the decimal style SID of an user.

Other COM Objects

msxml.wsf

Basic XML manipulation: validation, XPath filtering, and XML style sheet
transformations.

wmail.wsf

Generate a MIME mail message and send using raw SMTP or place in IIS
pickup directory.

Yesterday Microsoft released their new command shell, Windows PowerShell (via Aaron Tiensivu). This next-generation shell offers an administrative environment that strives to replace a jumble of administrative commands with a consistent, extensible interface.

Consider traditional Windows system administration tools — it is possible to automate administrative tasks with powerful commands like sc, netsh, and cacls. But each of these commands presents an esoteric interface with inconsistent command line options, and built-in documentation is sparse at best. Likewise, scripting with VBScript/JScript has good potential, but interaction with executables requires excessive housekeeping, and COM object interfaces are also inconsistent.

Unlike Windows’ monolithic commands, *nix has long offered a wide range of simple commands whose text input/output is easily strung together to perform useful tasks. Certain command line options are consistent enough (e.g. “-v”), and the man/info help system facilitates on-line documentation.

Enter PowerShell, which evolves *nix pipe concept to process .NET objects rather than simple text. The basic element of PowerShell’s object-oriented pipeline is the cmdlet (pronounced “command-let”). These simple commands follow a verb-noun naming convention that indicates their purpose. For example, Get-Service outputs the services on the local machine as service objects; Set-Date sets the clock. Functionality is so granular that output formatting is isolated to format- cmdlets, and output is the responsibility of output- cmdlets. For example:

PS C:\> Get-Process notepad | Stop-Process

Get-Process notepad passes a list of .NET process objects named “notepad” (specifically, System.Diagnostics.Process), and passes them to Stop-Process, which kills them. It would be just as easy to access any of the other Process properties or methods.

Extensive built-in help is available. The command Get-Help details it’s own options, and is a good place to start. Combined with the integrated scripting language, PowerShell + .NET is a clean alternative to VBScript/JScript + COM.

PowerShell 1.0 is available for download. Microsoft’s What Can I Do with Windows PowerShell? offers basic examples to get started. I also recommend the documentation pack, which includes a more extensive 32-page Getting Started Guide as well as a 116-page primer. full documentation is available on MSDN.

A:\File\by\Any\Other\Name would smell as sweet… Symbolic links have been a *NIX staple since the earliest iterations. Windows finally began supporting the concept with NTFS5, introduced in Windows NT4SP4 and included with Windows 2000. Unfortunately Windows built-in toolset is somewhat lacking, and there are a few gotchas.

Hard Link

A hard link is a file system level shortcut. For all intents and purposes, a hard link is no different from any other file. Each hard link, including the original file name is a reference to a single set of underlying data. Edit one file and all of it’s hard links instantly reflect the change – likewise, the data remains available until the last remaining hard link is deleted. Hard linking is available for files but not directories. Windows XP and above include the command line utility fsutil, whose usage is straightforward

fsutil hardlink create c:new.txt c:existingfile.txt

After this command, c:\new.txt and c:\existing\file.txt are conjoined – changes made to new.txt are instantaneously reflected in file.txt, and new.txt remains in tact if file.txt is deleted.

Soft Link

The Windows-centric term is junction point, but the terms are interchangeable. While a hard link points directly to raw blocks on a disk, a junction point refers to a file name. As such, the junction point does not keep up if the underlying file name changes. The feature is implemented by a file system filter, which transparently redirects I/O as directed by a chunk of data attached to the file. Windows supports junctions only for folders.

Unfortunately, the OS doesn’t include any mechanism to create them. You can use a command-line tool like Sysinternals’ Junction:

junction c:newdir x:anexistingdir

After this command, c:\new\dir will be transparently routed to x:\an\existing\dir. Deleting c:\new\dir\file.txt is synonymous with deleting x:\an\existing\dir\file.txt.

Microsoft’s fsutil can view junction points, but it cannot create them:

fsutil reparsepoint query c:newdir

As with a *NIX soft link, be aware that any actions you take underneath the junction point directly affect the contained files. It is safe to delete the junction point itself, but be careful not to SHIFT-delete a junction point or it’s parents – this will delete the files in the actual directory. Ironically, deletes using the Recycle Bin or rmdir /s do not recurse into junction points.

GUI

When looking for a GUI, I came across Link Shell Extension via Greg’s Cool [Utility] of the day. This handy utility adds a chain icon to junction points in Explorer, and allows for the creation of both hard links and junction points. The stateful context menu uses familiar copy-and-paste semantics.

Update: I just installed NTFS Links. This utility adds “Create Soft Link Here” to a drag-and-drop with the alternate button, hooks Windows copy-and-paste with a dialogue box prompting to paste a soft/hard link, and more. Neat stuff!