Lately I have been exploring the powerful capabilities of Scripting and WMI. It was very exciting to discover that it is very easy to convert VBScript for WMI into VBA code that works just like the scripts. While there are a few VBSript functions that cannot be used in VBA, most scripts can be easily modified to run from Access or other Office Applications. Why am I excited? With VBA and WMI you can do many things that are not possible using Windows API’s. WMI is so powerful one needs to be careful not to do some serious damage to your local Computer, a remote PC. or Windows Server!

Why is WMI so powerful? “…WMI is the core management-enabling technology built into Windows 2000, Windows XP, and the Windows Server 2003 family of operating systems. Based on industry standards overseen by the Distributed Management Task Force (DMTF), WMI is the instrumentation and plumbing through which all—well, almost all—Windows resources can be accessed, configured, managed, and monitored.” The last sentence is the one that lays out the power of WMI, which you, yes you, have in your VBA typing fingertips!

Using VBA and WMI here are a few of the things you can do on Local or Remote Computers:

• Manage Users and Group Policies
• Read and save Event Logs to files
• Get the size of a hard drive’s free Memory
• Get the Version of Microsoft Office
• Get the attributes of Printers
• Get the Operating System Service Pack Version (CSDVersion–ServicePackLast)
• Get the Operating System Name
• Get the Operating System Version Number
• Get the Operating System Build Number
• Windows Operating System Product/Serial Number
• Get Scheduled Jobs
• Count Running Processes
• List Running Processes
• Terminate Processes
• Delete software
• Install software
• Upgrade software
• List all Windows installed software
• List Microsoft software Product IDs
• Get the Registered User

In fact, the greatest difficulty with using WMI is there are thousands of Properties and Methods that are available for you to access. WMI has Classes, Properties, and Methods and its own VBScript query dialect called WQL. WMI uses the Common Information Model (CIM) to access information and perform actions. The CIM grants us access to almost everything about a PC. You can learn more about CIM here.

The following is an example of VBA code using WMI. This code gets the ProcessorIDs of a local computer which can be very useful. This code can be used as a template of sorts to access much of the information you will want to get using WMI.

Function ProcessorIDs() As String

    ' Using late binding to avoid a Reference problem
    Dim strComputer As String
    Dim objWMIService As Object
    Dim colItems As Object
    Dim objItem As Object
    Dim strProcessorIDs As String

    strComputer = "."

    Set objWMIService = GetObject("winmgmts:" _
        & "{impersonationLevel=impersonate}!\\" _
        & strComputer & "\root\cimv2")

    Set colItems = objWMIService.ExecQuery( _
        "SELECT * FROM Win32_Processor", , 48)

    For Each objItem In colItems
        strProcessorIDs = strProcessorIDs & ";" & Nz(objItem.ProcessorID, "")
    Next

    ' Remove the leading ; from the string
    Do While Left(strProcessorIDs, 1) = ";"
        strProcessorIDs = Right(strProcessorIDs, (Len(strProcessorIDs) - 1))
    Loop

    ProcessorIDs = strProcessorIDs

    Set objItem = Nothing
    Set colItems = Nothing
    Set objWMIService = Nothing

End Function

How does the code work?

After declaring some variables, we create an instance of a WMI Object using GetObject(“winmgmts:”)

Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" _
    & strComputer & "\root\cimv2")

We use winmgmts, the CIM Object Manager, to access the “root” (“\root\cimv2″) of the CIM library. If we are accessing a remote computer “{impersonationLevel=impersonate}!\\” grants us access if we have the right security credentials.

The strComputer variable is given a value of “.” when we are accessing the local computer. If we want to access a remote computer, instead of using “.” we need to use the path and name of the remote computer:

GetObject(“winmgmts:\TargetComputer”) or GetObject(“winmgmts:\DomainName\TargetComputer”).

Next we instantiate a collection of properties of the WMI Win32_Processor Class.

Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_Processor", , 48)

We use a WQL query to select all the Properties in the Class. You can learn more about WQL, the WMI Query Language, here.

For Each objItem In colItems
    ProcessorID = Nz(objItem.ProcessorID, 0)
Next

Getting the ProcessorIDs can help provide some level of security, enabling us to know if the database has been copied to a different computer. If we have already saved at least one of the ProcessorIDs to a Custom Database Property we can check to see if the value has changed using the following code which can be called by the AutoExec Macro or a Splash Form. Warning: Make backup copy of your database files before using the following code.

Function StartSafe() As Boolean
    Dim strProcessorID As String

    ' Get the stored ProcessorIDs from
    ' the custom Database property
    strProcessorID = GetDBPropValue("dbPrpProcessorID")

    If InStr(1, ProcessorIDs, strProcessorID) > 0 Then
        StartSafe= True
    Else
        StartSafe= False
        ' The database has been copied to an unauthorized computer!
        ' Delete the Back End Database to protect your data
        ' Uncomment the next line of code to delete the back end database
        'Kill (CurrentProject.Path & "\BackEndDB.mdb")
        ' If this is the back end add code to Delete all tables
        ' Add code to Delete all Modules
        DoCmd.Quit
    End If
End Function

You can get the code for the GetDBPropValue Function and other Database Properties Functions at
Custom Database Properties Creation and Use.

In our next article we will learn more about using the power of WMI with VBA.