Scripts: Create a list of email addresses in use by the organization

I had a client ask for this the other day… while I had a few things that I probably could have used for a template, I decided to skim though the Microsoft Script Center repository, and found something close in their AD section. After checking the MSDN site, I found the attribute I was looking for, “mail”. Modified the script a bit – and it worked.

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE

objCommand.CommandText = _
"SELECT givenName, sn, Mail, homeDirectory FROM 'LDAP://dc=domain,dc=local' WHERE objectclass='user' "
Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst
Do Until objRecordSet.EOF
strGivenName = givenName
Wscript.Echo "Name: " & objRecordSet.Fields("givenName").Value
Wscript.Echo "Last Name: " & objRecordSet.Fields("sn").Value
Wscript.Echo "EMail: " & objRecordSet.Fields("Mail").Value
Wscript.Echo "Home Drive: " & objRecordSet.Fields("homeDirectory").Value
Wscript.Echo " "
objRecordSet.MoveNext
Loop


AD-COIT v2.546 Released - Adds basic command line functionality

This release adds basic command line functionality to the script, which includes options to enable/disable main inventory logic, FSMO role detection, and select output to CSV as an option. Also added to the main inventory logic is SQL server detection/status.

The command line functionality should make the script easier to use, and reduce some confusion associated with having to change the LDAP path, and path to the CSV output. You still need to make sure your LDAP path reflects reality, and that the path to your CSV output file actually exists (i.e. c:\scripts\output.csv), but it's more prominently displayed in the help.

As always, you can find the latest release on Sourceforge.

Scripting: PowerShell Released

If you haven’t heard yet, PowerShell 1.0 was released yesterday (and yes, the downloads work now). As the name might lead you to believe, it's a new more powerful shell - or command-prompt - and a scripting environment for Windows, built on top of the .NET CLR and the .NET framework.

I'm starting to work though the getting started document, but already it looks and feels a bit like a bash shell. You can use cmdlets to do work, like "get-service", and then pipe the output though another cmdlet, like so:

"get-service findstr "Task"" (my pipe character keeps disappearing which I'm sure is because I'm doing something wrong with quoting in HTML, but there should be a pipe character "" between service and findstr).

Which would gather the services on your local box, and filter to display a line containing "Task". As I said, I'm just getting started. But from most accounts this is the future of scripting on the Windows platform, and Exchange 2007 will rely on it for doing work.

Also - The Script Center did a series of webcasts last week on PowerShell.

Scripts: Why more SBSers should be writing scripts!

Right to the point…

More SBSers should be writing scripts!

In the past I’ve posted snippets from a number of scripts that I’ve written… from checking Antivirus definition dates, to detecting Virtual Servers, to calculating free space, to querying for FSMO roles… (all right, so that last one isn’t exactly a common need for the average SBSer). But in case I haven’t made it abundantly clear already…

Scripting rocks!

Now I know what you’re thinking, and I’ve heard the excuses, scripting is… too hard, too time consuming, or even the wrong tool for the job in the SBS world. If that sounds anything like you, then let me let you in on a little secret... you don’t have to be a programmer to write useful scripts. You don’t even have to do it on a regular basis… you just need some exposure! Personally, between the stuff that I’ve already written and the community resources that are available, I don’t have to re-invent the wheel very often.

What I like to do is start with something simple, and write a small single-purpose script. Then maybe a few weeks later I come across another need, and write another single-purpose script to handle that task. After doing so, I’ll combine both of those scripts to handle some more complicated task. And that’s how my tool kit grows… I keep writing these little one-off scripts, and incorporating them as subs or functions into more complicated tools. It all keeps building.

Now go and get started… look at what’s available on the Scriptcenter, find something that you want to be able to do… maybe you want to bounce the Print Spooler, or something like that… then mash a few of their scripts together until they do more useful things for you. After you’ve done that… start tweaking… write another script to email you when an event happens… then add that email script as a sub or a function to the script that you created to bounce the print spooler… and just keep growing your tool set.

Remember, you don’t have to be a programmer, and you don’t have to crank out new scripts every day to add-value. Scripting is just another useful tool in your arsenal.

Patching: MSIE VML Exploit Continued

I just noticed that Jesper did a really detailed post on unregistering the VGX.DLL using a script. He's obviuosly been tracking this issue closley all week, and goes into a lot of detail - besides explaining step-by-step how to apply it via a GPO, he also included a very important component that I ignored in my post yesterday - error handling and reporting. Even if you've already mitigated against this risk you might learn something from his approach.

Patching: Mitigating against MSIE VML Exploit

SANS ISC has raised the InfoCon level to yellow today, after news that the Microsoft Internet Explorer VML exploit is becoming more widespread. SANS, Microsoft, and others are recommending to unregister the VGX.DLL to mitigate against the risk until a patch is available. Obviously, unregistering this DLL will disable the rendering of VML by your web browser, and other applications. So use this as appropriate for your environment.

The command looks like this: "regsvr32 /u "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll"

I rolled this into a GPO applied computer startup script that I'm using internally.


Set objShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")

strUnregCommand = "regsvr32 -u -s ""%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"
strComputer = objshell.ExpandEnvironmentStrings("%COMPUTERNAME%")

Set objExec = objShell.Exec(strUnregCommand)
strExecResults = LCase(objExec.StdOut.ReadAll)



WMI: TechNet Script Center Community Submitted Scripts Feed

If you’ve been reading my blog for a while, you’ve probably seen my links to Microsoft's TechNet Script Center . If you’re not familiar with the Script Center yet, it’s an excellent resource for system administration scripting, and really worth checking out. Even for if you don’t have much of a programming or scripting background, you can use some of their code snippets to start building some really useful tools.

Even more exciting, is that they recently started adding Community-Submitted scripts. So anybody with a useful tool that they’ve built, can submit it to the Community site. They also added an RSS feed for the recently added scripts that gets updated every Monday. So just load up your favorite feed reader, and point it at the Community submitted scripts feed .

And while you're at it, subscribe to my feed too!

WMI: Get a list of installed applications

Have you ever needed to get a list of applications that are installed on a workstation? I can think of a number of situations where this might be useful… Maybe you’re trying to get an application count as part of a Software Asset Management (SAM) project, or maybe because you’ve been tasked with determining the popularity of something inside your organization, say RSS Bandit (keep in mind that this list only includes applications installed by the Windows Installer).

Personally, I’ll be adding this as a function to my inventory script - because right now, I need this list for an audit I'll be conducting at a customer site.

Let’s just quickly review how this works…

First we declare a string (strComputer), and assign a value to it (ComputerName). Next, we connect to the \root\cimv2 namespace, query the “Win32_Product” class, and get a collection of items (colItems). Finally, we loop though the collection and echo the objItem.Descriptions and objItem.Versions.


strComputer = "computerName"
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_Product")

For Each objItem in colItems
wscript.echo objItem.Description & " (v." & objItem.Version & ")"
Next




WMI: Getting started with WMI

Wondering how I figured out how to retrieve the Dell express service tag information? It’s actually pretty easy. First, grab a copy of Microsoft’s “ScriptomaticV2.hta” tool; download it, and bring up the interface. On opening, it automatically loads the “root\CIMV2” namespace, which contains all of the WMI classes that you’re going to want to query.

Next, I opened the WMI Class drop down box and poked around a bit… working under the assumption that any Dell-specific information is going to be hidden inside the “Win32_BIOS” class. Next, I ran the automatic script that Scriptomatic generated, and skimmed the output looking for a 7-digit express service tag number. Sure enough, “objItem.SerialNumber” pulls out the information I wanted.

Finally, I grabbed a copy of another script I had written to take command-line arguments, replacing what I had been using to some other work, with a Wscript.echo command for objItem.SerialNumber.

Between having a few scripts on hand that already do some useful stuff, and tools like Scriptomatic, you can really build some powerful little scripts that can have an immediate impact, without hours and hours worth of effort. Granted, this is a pretty basic script, but I can’t tell you how often it comes in handy.