Managing Windows with WMI

Set DiskSet =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecQuery("select FreeSpace,Size,Name from Win32_LogicalDisk where
DriveType=3")
for each Disk in DiskSet
If (Disk.FreeSpace/Disk.Size) < 0.20 Then
WScript.Echo "Drive " + Disk.Name + " is low on space."
End If
Next

You might notice that in this query the exact properties needed to build the script are requested, not everything in the Win32_LogicalDisk class. In order to just get the information for local hard drives, the WHERE clause limits the query to only that drive type (DriveType=3). Without this filter floppy drives, CD-ROM drives, and network shares would also get included in the check, which would probably not be desired. The Name property is also retrieved and used when a low space message needs to be displayed.

Setting the Operating System Boot Delay

In this script we use the Win32_ComputerSystem class to modify the delay setting used at boot time to give the user time to choose a different boot option than the default operating system. The major difference in this script is that a property in the Win32_ComputerSystem class is being modified and then written back to WMI, which in turn updates the operating system setting:

Set CompSysSet =
GetObject("winmgmts:{impersonationLevel=impersonate}"
.ExecQuery("select * from Win32_ComputerSystem")
for each CompSys in CompSysSet
CompSys.SystemStartupDelay = 20
CompSys.Put_()
next
WScript.Echo "Boot up delay time set"

To accomplish this task, the Win32_ComputerSystem class is enumerated with a query as before. The script iterates through each instance (in the case of this class, there is always just one instance because there is only one computer system instance for a given machine) and sets the SystemStartupDelay property value in the temporary variable to the desired setting. Finally, to write the instance back with the changed value, the Put_() method is invoked. It should be noted that several properties in the instance could have been updated simultaneously with the same Put_() call. The same mechanism can be used for any write-enabled property supported by WMI.

A value of 20 seconds is written to the property, which can be verified after running the script in the Control Panel->System applet under the Advanced tab Startup and Recovery options, as shown in Figure 2.

Figure 2 Startup and Recovery options

Backing Up the Application Event Log

The Win32_NTEventLogFile class models the event logs in Windows NT 4.0 and Windows 2000. By default, there are three standard event logs: System, Security, and Application. In this example the method to back up one of these logs is invoked. Methods in WMI are simply function calls that are applied to particular managed objects; here, the backup method is applied to an instance of a Windows NT Event Log object:

LogFileSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(Backup)}")
.ExecQuery("select * from Win32_NTEventLogFile where
LogfileName=''''Application''''")
for each Logfile in LogFileSet
RetVal = LogFile.BackupEventlog("c:\BACKUP.LOG")
if RetVal = 0 then WScript.Echo "Log Backed Up"
next

The basics remain the same here, in that a query is run against the Win32_NTEventLogFile class, filtering for the specific log file of interest, "Application." Note the addition of the statement "(Backup)" in the GetObject() call. In order to back up an event log file, the "Backup" privilege must be assigned to your account. Members of the Administrators and Backup Operators NT security groups have this privilege by default. Even so, having a privilege assigned to you is not enough to make use of it. When executing a privileged operation such as backup, the privilege must be explicitly enabled by the user before it is used. If "(Backup)" had not been specified in the GetObject() call, the script would receive an "Access Denied" message when the BackupEventlog() method was invoked and the operation would not be performed. The BackupEventlog() method takes the path and name of the backup file as its only parameter.

To clear the entries in the Application event log after it is backed up, the script requires only a simple modification, shown in bold:

LogFileSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(Backup)}")
.ExecQuery("select * from Win32_NTEventLogFile where
LogfileName=''''Application''''")
for each Logfile in LogFileSet
RetVal = LogFile.BackupEventlog("c:\BACKUP.LOG")
if RetVal = 0 then WScript.Echo "Log Backed Up"
RetVal = LogFile.ClearEventlog()
if RetVal = 0 then WScript.Echo "Log Cleared"
next

The bolded area in the updated example adds the functionality required to clear the log file by calling the ClearEventlog() method and, upon a successful result, displays a message.

Reboot a Remote Machine

Remote operations on WMI are virtually identical to those performed locally. All of the previous examples could be easily modified to specify a remote machine as the target instead of defaulting to the local system. Other than calling out a particular target machine, nothing else about dealing with WMI is any different. This is no small point because it means any instrumented property or method can be accessed across individually or across an entire enterprise using a very simple script. Here, we reboot a remote system using the Reboot() method in the Win32_OperatingSystem class:

Set OpSysSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(RemoteShutdo
wn)}//alexn-pc ").ExecQuery("select * from Win32_OperatingSystem
where Primary=true")
for each OpSys in OpSysSet
OpSys.Reboot()
Next

To build this script, we have to query the remote machine for the instance of the operating system it is running, in this case the one with a Primary flag set to TRUE. Naturally, the name of the machine, alexn-pc, needs to be specified so the method is directed to the correct system. Other than specifying the target machine, nothing is different about how information is retrieved in this case than from a local machine.

Again, notice that this is a privileged operation. (I must be part of the Administrator''''s group on the remote machine to successfully use it.) For the script to work, I must have the privilege to perform a remote shutdown assigned to me on the remote system and explicitly enable it using "(RemoteShutdown)" before attempting the privileged operation. Remember, as discussed earlier, all permissions and privileges are based on who the logged-in user is that runs the scripts; your abilities as currently defined by your user account are impersonated by WMI such that only the information and actions you are allowed to perform are available.

Launch Notepad Through WMI

In this example we launch a new process through a WMI method in the Win32_Process class. I have chosen a relatively innocuous application, Notepad, for the purpose of demonstration, but any executable can be substituted here. This capability can be extremely powerful for support personnel dealing with relatively inexperienced users. For example, rather than guide an end user through the user interface, menus, and so on to run a diagnostic tool, the support person can simply pop the tool up on the user''''s system using a script that invokes it remotely via WMI. This alone can be a big timesaver:

set process =
GetObject("winmgmts:{impersonationLevel=impersonate}
!Win32_Process")
result = process.Create ("notepad.exe",null,null,processid)
WScript.Echo "Method returned result = " & result
WScript.Echo "Id of new process is " & processed

There are a couple of new concepts in this example. The first new development is the use of the COM moniker notation in the GetObject() call when asking for the Win32_Process class. A moniker is a COM standard mechanism for encapsulating the location and binding of another COM object. This lets you get back a particular object based on the display name. Next, rather than submitting a query through ExecQuery() to get back instances of the Win32_Process class, I have asked to get back the class object itself. The reason for this is fairly simple, but may not be obvious. Creating a new process is not really an action to be taken against an existing process instance. Which currently running process should be the one to launch the new one? Because there is no consistent answer to this issue, it becomes apparent that creating a process is really creating a new instance of the Win32_Process class. Therefore, the concept of a static method, one defined against the class definition itself instead of its instances, is needed. The Create() method for Win32_Process is an example of such a static method; previous method examples have all been dynamic methods—those that operate against individual instances. Incidentally, the Delete() method is a dynamic method because it typically applies to particular instances rather than the class as a whole.

The Create() method takes several input parameters, but in the example I simply supply the name of the executable I wish to launch, "notepad.exe." Aside from returning a value for success or failure of the operation, the method also returns the ID of the new process that was created. The script displays the method execution results and process ID values after the method is executed and, of course,

上一页  [1] [2] [3] [4]  下一页

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18