Administrators who write scripts to manage files and folders typically use the FileSystemObject rather than WMI. This is due more to familiarity than to anything else; most of the same core capabilities are available using either the FileSystemObject or WMI. The leads to an obvious question: when should you use the FileSystemObject, and when should you use WMI? Or does it even matter?

There is no simple answer to that question; instead, the best approach usually depends on what your script needs to accomplish. When choosing a method for managing files and folders, you should consider the impact of:

Error Handling

The FileSystemObject sometimes provides a faster solution; it rarely, if ever, provides a more robust solution. The FileSystemObject provides no ability to recover from an error, even if your script includes the On Error Resume Next statement.

For example, suppose you have a script designed to delete 1,000 files from a computer. If an error occurs with the very first file, the script fails, and no attempt is made to delete any of the remaining files. If an error condition occurs, the FileSystemObject — and the script — immediately terminates. If an error occurs partway through an operation, you will have to manually determine which portions of the procedure succeeded and which portions did not.

WMI is better able to recover from a failed operation. If WMI is unable to delete the first of the 1,000 files, it simply reports an error condition and then attempts to delete the next file in the collection. By logging any errors that occur, you can easily determine which portions of a procedure succeeded and which ones did not.

Note

You can log these individual errors because WMI treats each file operation separately; if you have 1,000 files, WMI treats this as 1,000 separate deletions. The FileSystemObject, by comparison, treats each file operation as one procedure, regardless of whether you have 1 file, 10 files, or 1,000 files.

WMI is also able to more intelligently deal with file and folder access permissions. For example, suppose you write a script to enumerate all the files on a hard drive. If WMI encounters a folder that you do not have access to, the script simply skips that folder and continues. The FileSystemObject, however, attempts to list the files in that folder. That operation will fail because you do not have access to the folder. In turn, the FileSystemObject, and your script, will also fail. This is a problem with Windows 2000–based computers because they typically include a System Volume Information folder that, by default, grants access only to the operating system. Without taking precautions to work around this folder, any attempt to enumerate all the files on a computer using the FileSystemObject is guaranteed to fail.

strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:" & "!\" & strComputer & "
ootcimv2")

strComputer = "atl-dc-01"
Set objWMIService = GetObject _
    ("winmgmts:" & "!\" & strComputer & "
ootcimv2")

"SELECT * FROM CIM_DataFile WHERE Extension = 'MP3'"

As demonstrated in the preceding script, WMI can be used to bind to and retrieve the properties from a specific file system folder. In addition, WMI can be used to retrieve the properties for all the folders in the file system, allowing you to easily map the layout of your disk drives. Although you probably do not need to enumerate all the folders on a regular basis, carrying out this task on occasion can help you spot anomalies in the file system, including such things as folders that:

To retrieve a list of all the folders on a computer, use the following WQL query:

"SELECT * FROM Win32_Directory"

If you want to limit data retrieval to a single disk drive, include a Where clause specifying the drive letter. For example, this query returns a list of all the folders on drive C:

"SELECT * FROM Win32_Directory WHERE Drive = 'C'"

If you need to enumerate all the folders on a computer, be aware that this query can take an extended time to complete. For example, on a Windows 2000—based computer with 5,788 folders, a script that returns the name of each folder required 429 seconds to complete.

Scripting Steps

Listing 11.2 contains a script that returns a list of all of the folders on a computer. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFolders = objWMIService.ExecQuery("SELECT * FROM Win32_Directory")
 5 For Each objFolder in colFolders
 6     Wscript.Echo objFolder.Name
 7 Next

Instead of enumerating all the folders and subfolders on a computer, a more common task is examining the subfolders for a single folder. For example, you might have a folder named Users, and you might encourage your users to store their documents in this folder. Enumerating the subfolders within the Users folder can tell you which users have set up personal folders within that parent folder.

The Win32_Subdirectory class is an association class that allows you to associate a folder with its subfolders (or with its parent folder). Association classes typically have very few properties; their purpose is simply to derive the associations between objects. The Win32_Subdirectory class, for example, has only two properties:

To return a collection of subfolders for a folder, create an association query that sets the ResultRole to PartComponent. This indicates that all the items in the returned collection must play the role of a PartComponent, or subfolder, of the folder object. To return the parent folder for a folder, set the ResultRole to GroupComponent.

Figure 11.3 shows a sample folder structure. In this example, the associations for the folder Subfolder 1 are:

Figure 11.3. Sample Folder Structure

The Win32_Subfolder class works only on the file system level immediately above or immediately below the specified folder. If you retrieve the subfolders for the folder Scripts shown in Figure 11.3, the following two items are returned:

However, the subfolders of those subfolders (for example, Subfolder 1A and Subfolder 1B) are not included in the returned collection. This is because these folders are not directly contained within Scripts. To enumerate subfolders of subfolders, you need to create a recursive function that:

The recursion continues until every subfolder has been queried.

Note

For information about creating recursive functions, see “VBScript Primer” in this book.

Scripting Steps

Listing 11.3 contains a script that returns a list of all subfolders within the folder C:Scripts. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colSubfolders = objWMIService.ExecQuery _
 5     ("ASSOCIATORS OF {Win32_Directory.Name='c:scripts'} " _
 6         & "WHERE AssocClass = Win32_Subdirectory " _
 7             & "ResultRole = PartComponent")
 8 For Each objFolder in colSubfolders
 9     Wscript.Echo objFolder.Name
10 Next

The previous two topics — generating a list of all the folders on a computer, and generating a list of all the subfolders contained in a specified folder — illustrate basic forms of folder management. Unfortunately, real-world folder management does not always fall into such tidy categories. Instead, folder management often requires you to search through the entire file system looking for folders that meet specific criteria.

For example, you might need to return a list of all the encrypted folders or all the compressed folders on a computer, regardless of their physical location. With the FileSystemObject, this type of task can be achieved only by methodically retrieving each folder on each drive and then checking to see whether it meets the criteria.

WMI makes it much easier to return a list of folders meeting specific criteria; all you have to do is include the criteria within your WQL query. For example, this query returns a collection of all the compressed folders on a computer:

SELECT * FROM Win32_Directory WHERE Compressed = True

Scripting Steps

Listing 11.4 contains a script that returns a list of all the hidden folders on a computer. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFiles = objWMIService.ExecQuery _
 5     ("SELECT * FROM Win32_Directory WHERE Hidden = True")
 6 For Each objFile in colFiles
 7     Wscript.Echo objFile.Name
 8 Next

Folder date properties — CreationDate, LastAccessed, and LastModified — are very useful in managing folders. For example, you might use the CreationDate property to return a list of all the folders created in the past week. O,r you might use the LastAccessed property to identify rarely used folders, folders that might be candidates for compression or for removal from the file system.

The primary complication in working with folder dates is the fact that WMI stores date and time information using the UTC (Universal Time Coordinate) format. In this format, dates are displayed as yyyymmddHHMMSS.xxxxxx±UUU, where:

For example, in UTC format, a folder created on October 18, 2002, at 10:45:39 A.M. Pacific Standard Time returns this CreationDate value:

20021018104539.000000–480

This means that you cannot specify a standard date, such as 10/18/2002, in your search query; WMI will not be able to interpret this date. Instead, you will need to convert any dates used in your queries to UTC format. Your converted date should use the items in Table 11.4 in each character position in the 25-character UTC string.

You can determine the offset from Greenwich mean time by using this script:

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
Set colTimeZone = objWMIService.ExecQuery _
    ("SELECT * FROM Win32_TimeZone")
For Each objTimeZone in colTimeZone
    Wscript.Echo "Offset: "& objTimeZone.Bias
 Next

To search for folders using the date October 18, 2002, you would use a value similar to this (depending on your time zone):

20021018000000.000000–480

Scripting Steps

Listing 11.5 contains a script that returns a list of all the folders on a computer that have been created since March 1, 2002. To carry out this task, the script must perform the following steps:

 1 dtmTargetDate = "20020301000000.000000-420"
 2 strComputer = "."
 3 Set objWMIService = GetObject _
 4     ("winmgmts:" & "!\" & strComputer & "
ootcimv2")
 5 Set colFolders = objWMIService.ExecQuery _
 6     ("SELECT * FROM Win32_Directory WHERE CreationDate > '" & _
 7         dtmtargetDate & "'")
 8 For Each objFolder in colFolders
 9     Wscript.Echo objFolder.Name
10 Next

The Windows operating system includes a number of special folders, folders that have a well-defined purpose and are generally present on all computers. These special folders include virtual folders, such as My Documents and Recycle Bin, as well as physical file system folders such as Program Files and Fonts. Because of the importance of these folders, it is useful for a system administrator to be able to locate and, if necessary, manipulate these folders on any computer.

However, there are at least two problems with identifying special folders on a computer. First, the location of these folders can vary. Mary might have her My Documents folder on drive C, Ken might have his My Documents folder on drive D, while Mike might have his My Documents folder located on a network drive. In addition, there is no guarantee that these three folders are all named My Documents. Special folders can be renamed; Mary might retain the name My Documents for this folder, but Ken might have renamed his My Documents folder to Ken Myer’s Personal Folder.

Fortunately, the operating system does not use physical locations or names to keep track of special folders. Instead, special folders are tracked using CSIDLs, a standard method for identifying these objects regardless of their name or location. For example, the CSIDL for the Recycle Bin is this:

{645FF040-5081-101B-9F08-00AA002F954E}

Other special folders have similar CSIDLs.

Windows Script Host (WSH) can be used to retrieve the location of many of these special folders, particularly those that have a physical location. WSH can retrieve these locations by specifying a folder mnemonic (StartMenu, MyDocuments, Fonts). However, WSH cannot retrieve the location of all the special folders, particularly virtual folders (such as My Network Places) that do not have a physical location. In addition, WSH can only return the location of special folders; it cannot be used to enumerate the items within those folders or to perform any action on those folders.

If you need to locate any special folder on the computer or if you need to perform an action on a particular special folder, you can use the Shell object instead. The Shell object includes a number of predefined constants that can be passed to the Namespace method and return a folder object for a special folder. For example, the constant &H21& represents the Cookies folder; this code returns a folder object for the Cookies folder:

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(&H21&)

A list of Shell special folder constants and their Windows Script Host equivalents (where applicable) is shown in Table 11.5. WSH has one advantage over the Shell object: the WSH mnemonics (Programs for the Programs folder, MyDocuments for the My Documents folder) are easier to use and easier to remember than the Shell object constants. However, the Shell object can enumerate many more special folders than WSH can.

Not all computers have each of the special folders shown in Table 11.5. However, even if a folder does not exist, the name and location of that folder are predefined by the operating system. As a result, a script that attempts to enumerate special folders does not fail even if some of these folders do not exist.

Scripting Steps

Listing 11.6 contains a script that returns the path to the My Pictures folder. To carry out this task, the script must perform the following steps:

1 Const MY_PICTURES = &H27&
2 Set objShell = CreateObject("Shell.Application")
3 Set objFolder = objShell.Namespace(MY_PICTURES)
4 Set objFolderItem = objFolder.Self
5 Wscript.Echo objFolderItem.Name & ": " & objFolderItem.Path

After you have connected to a special folder, you can enumerate the items within the folder the same way you enumerate the files found in a standard file system folder. This allows you to do such things as identify the administrative tools or the control panel applications that are installed on a computer.

For example, Listing 11.7 contains a script that lists the administrative tools installed on a computer. To carry out this task, the script must perform the following steps:

1 Const ADMINISTRATIVE_TOOLS = &H2f&
2 Set objShell = CreateObject("Shell.Application")
3 Set objFolder = objShell.Namespace(ADMINISTRATIVE_TOOLS)
4 Set colTools = objFolder.Items
5 For Each objTool in colTools
6     Wscript.Echo objTool
7 Next

Folder management scripts are often designed to work against any folder on a computer. Because of this, folder names and paths are typically not hard-coded into the script; instead, these values must be typed in as command-line arguments each time the script is run. This provides your script with the flexibility to work against any folder on a computer; however, it also requires you to know the exact location of each folder you want to manage and to correctly type that location before the script can run. This can be particularly cumbersome if the folder you want to manage has a name such as C:System AdministrationAdministrator ToolsDiagnosticsScriptsNetworkIP Configuration.

If you are working with a single folder at a time, the Shell’s Browse For Folder dialog box provides a graphical alternative to command-line arguments. Instead of requiring you to type in a folder path, the Browse For Folder dialog box (shown in Figure 11.4) allows you to select the folder from a standard Windows Explorer–like tree control.

Figure 11.4. Browse For Folder Dialog Box

After you select a folder and click OK, your script is bound to the Folder object for the selected folder. If you are using a Shell object script, you can proceed to carry out the desired actions on that folder. If you want to pass the selected folder to the FileSystemObject or to WMI, your script can:

To display the Browse for Folder dialog box, use the Shell object’s BrowseForFolder method along with the parameters shown in Table 11.6.

For example, the following code displays the Browse For Folder dialog box with these options:

Set objFolder = objShell.BrowseForFolder _
    (0, "Select a folder to compress:", 0, "D:")

Scripting Steps

Listing 11.8 contains a script that uses the Browse For Folder dialog box to return the path of a selected folder. To carry out this task, the script must perform the following steps:

 1 Const WINDOW_HANDLE = 0
 2 Const NO_OPTIONS = 0
 3 Set objShell = CreateObject("Shell.Application")
 4 Set objFolder = objShell.BrowseForFolder _
 5     (WINDOW_HANDLE, "Select a folder:", NO_OPTIONS, "C:Scripts")
 6 Set objFolderItem = objFolder.Self
 7 objPath = objFolderItem.Path
 8 objPath = Replace(objPath, "", "\")
 9 strComputer = "."
10 Set objWMIService = GetObject _
11     ("winmgmts:" & "!\" & strComputer & "
ootcimv2")
12 Set colFiles = objWMIService.ExecQuery _
13     ("SELECT * FROM Win32_Directory WHERE Name = '" & objPath & "'")
14 For Each objFile in colFiles
15     Wscript.Echo "Readable: " & objFile.Readable
16 Next

Standardization helps facilitate system administration. For example, having a standard set of folder names makes it easier to run scripts that verify that the proper set of files has been installed on a computer. With standard folder names, scripts such as these can simply connect to the desired folders without needing a list of unique folder names and locations for each individual computer.

Scripts can help you implement standardized naming schemes on computers throughout your organization. For example, the Win32_Directory class provides a Rename method that allows you to rename a folder. Thus, you can write a script that connects to all the domain controllers in your organization and renames the folder C:Stuff to C:Administrative Scripts.

To rename a folder, first bind to the folder in question and then call the Rename method. As the sole parameter to the method, pass the new name for the folder as a complete path name. For example, if the folder in the C:ScriptsLogsBackup is to be renamed C:ScriptsArchive, you must pass C:ScriptsArchive as the complete folder name. Passing only the folder name — Archive — results in an Invalid path error.

Scripting Steps

Listing 11.9 contains a script that binds to the folder C:Scripts and renames the folder C:Script Repository. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFolders = objWMIService.ExecQuery _
 5     ("SELECT * FROM Win32_Directory WHERE Name = 'c:\Scripts'")
 6 For Each objFolder in colFolders
 7     errResults = objFolder.Rename("C:Script Repository")
 8     Wscript.Echo errResults
 9 Next

The Win32_Directory class does not provide a one-step method for moving folders. Instead, moving a folder generally involves two steps:

The one exception to this two-step process involves moving a folder to a new location on the same drive. For example, suppose you want to move C:Temp to C:ScriptsTemporary FilesArchive. As long as the current location and the new location are on the same drive, you can move the folder by simply calling the Rename method and passing the new location as the method parameter. This approach effectively allows you to move the folder in a single step. However, the script fails if the current drive and the new drive are different. An attempt to rename C:Temp to D:Temp fails with a “Drive not the same” error.

Scripting Steps

Listing 11.10 contains a script that moves the folder C:Scripts to C:AdminsDocumentsArchiveVBScript. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFolders = objWMIService.ExecQuery _
 5     ("SELECT * FROM Win32_Directory WHERE Name = 'c:\Scripts'")
 6 For Each objFolder in colFolders
 7     errResults = objFolder.Rename("C:AdminsDocumentsArchiveVBScript")
 8     Wscript.Echo errResults
 9 Next

Folders often need to be copied from one location to another. For example, you might copy a folder from one server to another to create a backup copy of that folder. Or you might have a templates folder that needs to be copied to user workstations, or a scripts folder that should be copied to all of your DNS servers.

The Win32_Directory Copy method enables you to copy a folder from one location to another, either on the same computer (for example, copying a folder from drive C to drive D) or on a remote computer. To copy a folder, you return an instance of the folder to be copied and then call the Copy method, passing as a parameter the target location for the new copy of the folder. For example, this line of code copies a folder to the Scripts folder on drive F:

objFolder.Copy("F:Scripts")

WMI will not overwrite an existing folder when executing the Copy method. This means that the copy operation fails if the destination folder exists. For example, suppose you have a folder named Scripts and you attempt to copy that folder to a remote share named \atl-fs-01archive. If a folder named Scripts already exists on that share, the copy operation fails.

Scripting Steps

Listing 11.11 contains a script that copies the folder C:Scripts to D:Scripts. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFolders = objWMIService.ExecQuery _
 5     "SELECT * FROM Win_32 Directory" WHERE Name = 'c:\Scripts'")
 6 For Each objFolder in colFolders
 7     errResults = objFolder.Copy("D:Archive")
 8     Wscript.Echo errResults
 9 Next

WMI has several limitations when copying folders. For one, WMI provides no built-in method for tracking script progress. Although many system administration scripts have no user interface and are designed to run silently, there might be times when you would like to follow the progress of a script. For example, you might want to visually track a script that copies a large number of files and folders from one computer to another. That way, you can verify that the script is proceeding as expected.

A second limitation of the WMI Copy method is that a folder-copying script fails if the destination folder already exists. For example, you might want to periodically copy a folder named DiskPerformance to an archive folder named Monitoring. The first time you run the script, the copy operation will succeed. The next time you run the script, however, the folder MonitoringDiskPerformance already exists. As a result, the copy operation fails unless you include extra code within the script to test for the existence of the DiskPerformance folder and then rename either that folder or the new folder being copied.

In addition, the WMI Copy method is an all-or-nothing method: It works only if the destination folder does not exist, and only if you copy over the entire source folder. WMI does not allow you to merge folders; that is, you cannot copy over new items without also deleting all the existing items in the destination folder.

The Shell Folder object includes a CopyHere method that allows you to overcome these limitations. First, the CopyHere method enables you to optionally display the Copying dialog box as the script runs. This dialog box is shown in Figure 11.5.

Figure 11.5. Copying Dialog Box

Another optional parameter allows you to copy a folder without overwriting the contents of the target folder. For example, suppose you have a target folder named E:Scripts. You can copy a second folder named Scripts to that same location without losing the data in the original target folder. Instead, the new folder is automatically named Copy (1) of Scripts. If you copy another folder, it is named Copy (2) of Scripts. This allows you to copy folders from multiple computers without having to worry about providing those folders with unique names.

Finally, the CopyHere method supports merging folders. For example, suppose you have target and source folders with the file sets shown in Table 11.7.

When you copy the source folder to the target folder, the file sets are merged, and the new folder contents look like those shown in Table 11.8.

Note

If the target folder already has files named SourceFile1 and SourceFile2, those files are replaced by the versions being copied from the source folder.

To copy a folder using the CopyHere method, you need to create an instance of the Shell object, and then use the Namespace method to bind to the target folder (the location where the folder will be copied). You then call the CopyHere method, passing the path of the source folder (the folder being copied) as a required parameter. In addition, you can pass one or more of the optional constants shown in Table 11.9.

For example, this line of code copies the folder C:Scripts while displaying a simple progress dialog box:

objFolder.CopyHere "C:Scripts", &H100&

Scripting Steps

Listing 11.12 contains a script that copies a folder to a new location, displaying the Copying dialog box as it carries out the procedure. To carry out this task, the script must perform the following steps:

1 Const FOF_CREATEPROGRESSDLG = &H0&
2 ParentFolder = "D:Archive"
3 Set objShell = CreateObject("Shell.Application")
4 Set objFolder = objShell.NameSpace(ParentFolder)
5 objFolder.CopyHere "C:Scripts", FOF_CREATEPROGRESSDLG

The Shell method MoveHere is similar to the CopyHere method; the only difference is that MoveHere moves a folder from one location to another, whereas CopyHere copies the folder (resulting in two identical folders). Otherwise, MoveHere is called in the same manner as CopyHere and accepts the same set of optional parameters found in Table 11.9.

Scripting Steps

Listing 11.13 contains a script that moves a folder to a new location, displaying the Move Files dialog box as it carries out the procedure. To carry out this task, the script must perform the following steps:

1 Const FOF_CREATEPROGRESSDLG = &H0&
2 TargetFolder = "D:Archive"
3 Set objShell = CreateObject("Shell.Application")
4 Set objFolder = objShell.NameSpace(TargetFolder)
5 objFolder.MoveHere "C:Scripts", FOF_CREATEPROGRESSDLG

Folders are not necessarily permanent additions to a file system. At some point, folders might need to be deleted, perhaps because they are no longer required, because the role of the computer has changed, or because the folders were created by mistake.

The Win32_Directory class includes a Delete method that allows you to delete folders: you simply bind to the folder in question and then call the Delete method. After the Delete method is called, the folder is permanently removed from the file system; it is not sent to the Recycle Bin. In addition, no confirmation notice (“Are you sure you want to delete this folder?”) is issued. Instead, the folder is immediately removed.

You cannot delete read-only folders using the FileSystemObject; however, this can be done using WMI. If your script uses WMI and you do not want to remove a read-only folder, you must use the Readable property to check the folder status before deleting it.

Scripting Steps

Listing 11.14 contains a script that deletes the folder C:Scripts. To carry out this task, the script must perform the following steps:

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFolders = objWMIService.ExecQuery _
5     ("SELECT * FROM Win32_Directory WHERE Name = 'c:\Scripts'")
6 For Each objFolder in colFolders
7     errResults = objFolder.Delete
8     Wscript.Echo errResults
9 Next

Compression provides a way to free additional storage space on a disk drive without purchasing new hardware and without removing files or folders. Depending on the size of your hard disk and the type of files stored on that disk, you might be able to recover hundreds of megabytes of disk space and thus preclude the need to purchase a new hard drive and to take the computer offline until the new drive is installed.

The Win32_Directory class includes a Compress method that compresses all the files and subfolders within a specified folder. In addition, the class also includes an Uncompress method that removes compression from all the files and subfolders in a folder. Similar methods are also provided with the CIM_Datafile class. This allows you to selectively compress or uncompress specific files within a folder.

Because compression imparts a slight performance penalty, it is not recommended for files or folders that are accessed on a routine basis; for example, you probably do not want to compress database files, log files, or user profile folders. Better candidates for compression are files and folders that are not accessed very often. For example, you might write a script to return a collection of folders on a drive that have not been accessed for a month or more and then compress each of those folders.

The amount of disk space freed by compressing folders varies depending on the type of files stored in that folder. For example, .jpg files are already compressed, and further compression has little effect on the size of the file. With other file types, however, the savings can be considerable. For example, a new folder was created on a Windows 2000-based test computer, and 33 Microsoft Word documents, taking up a total of 15 megabytes (MB) of disk space, were copied into that folder. When the documents were compressed, the folder took up only 7 MB of disk space.

Scripting Steps

Listing 11.15 contains a script that compresses the folder C:Scripts. To carry out this task, the script must perform the following steps:

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFolders = objWMIService.ExecQuery _
5     ("SELECT * FROM Win32_Directory WHERE Name = 'c:\Scripts'")
6 For Each objFolder in colFolders
7     errResults = objFolder.Compress
8     Wscript.Echo errResults
9 Next

To uncompress a folder, follow exactly the same procedure, but call the Uncompress method rather than the Compress method. For example, the script shown in Listing 11.16 uncompresses the folder C:Scripts.

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFolders = objWMIService.ExecQuery _
5     ("SELECT * FROM Win32_Directory WHERE Name = 'c:\Scripts'")
6 For Each objFolder in colFolders
7     errResults = objFolder.Uncompress
8     Wscript.Echo errResults
9 Next

When you right-click a file in Windows Explorer and select Properties from the shortcut menu, a dialog box displays basic properties for that file, including such things as file name, file size, and the file creation, last access, and last modification dates. In addition to these basic properties, the Windows operating system also tracks a number of extended file properties. These properties are typically hidden; to display them in Windows Explorer, you must click View, click Choose Details, and then select the desired properties from the resulting dialog box (shown in Figure 11.7).

Figure 11.7. Choose Details Dialog Box

The Shell FolderItems object includes a GetDetailsOf method that allows you to access these extended properties. These properties, and their associated index numbers, are shown in Table 11.10.

To access any one of these properties, call the GetDetailsOf method, passing two parameters: the name of the file and the index number of the property to be retrieved. For example, the following code snippet echoes the Duration property for a media file:

Wscript.Echo objFolder.GetDetailsOf(strFileName, 21)

Scripting Steps

Listing 11.18 contains a script that retrieves all the extended properties for each file in the folder C:Scripts. To carry out this task, the script must perform the following steps:

 1 Dim arrHeaders(35)
 2 Set objShell = CreateObject("Shell.Application")
 3 Set objFolder = objShell.Namespace("C:Scripts")
 4 For i = 0 to 34
 5     arrHeaders(i) = objFolder.GetDetailsOf(objFolder.Items, i)
 6 Next
 7 For Each strFileName in objFolder.Items
 8     For i = 0 to 34
 9         Wscript.Echo i & vbtab & arrHeaders(i) _
10             & ": " & objFolder.GetDetailsOf(strFileName, i)
11     Next
12 Next

The CIM_Datafile class provides access to all the files stored on a computer, including those stored on hard disks, floppy disks, and CD-ROM drives. This means that you can use WMI and the CIM_Datafile class to retrieve a list of all the files stored on a computer.

Admittedly, retrieving a list of all the files on a computer rarely has any practical value. Queries such as this can take an extremely long time to complete; on a large file server, for example, it might take several hours to return such a list; even then, the query will complete only if there is enough memory on the computer to carry out the request. This is due to the way standard WMI queries operate. As objects (such as files) are enumerated, they are queued in memory and then reported in batches. If too many objects are found, memory can exhausted before the entire list has been generated.

In addition, a query such as this typically returns far more information than is useful. After all, even a typical user workstation might contain some 50,000 files.

Although enumerating all the files on a computer might have little practical value, it does provide an introduction to the CIM_Datafile class and emphasizes the importance of using targeted queries when working with this class. Unlike many other WMI classes, some care must be taken when using CIM_Datafile. For example, when you return a list of services on a computer using WMI, a script completes in approximately the same time regardless of whether you return the entire set of services or some subset of services (for example, all the services currently running). This is not true of CIM_Datafile. Returning a list of all the files on a computer might take hours; returning a list of all the files with the .jpg extension might take just a few seconds.

Scripting Steps

Listing 11.19 contains a script that returns a list of all the files on a computer. To carry out this task, the script must perform the following steps:

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFiles = objWMIService.ExecQuery _
5     ("SELECT * FROM CIM_Datafile")
6 For Each objFile in colFiles
7     Wscript.Echo objFile.Name
8 Next

The script for enumerating all the files on a computer (as shown in Listing 11.19) works as long as there is sufficient memory to maintain a list of all the files on a computer. For example, on a Windows 2000–based computer with 128 MB of RAM and approximately 22,000 files, the enumeration script completed successfully. On a similar computer with approximately 82,000 files, however, the script exhausted available memory and failed.

With a standard query, data retrieval can tie up available memory and slow system performance. If you expect your file query to return a large amount of data, you might find it more expedient to use an asynchronous query, even if you are returning only a subset of files on a computer (for example, a query that returns several thousand .doc files from a file server). With an asynchronous query, objects are retrieved and reported one at a time. This allows the script to proceed with other tasks; equally important, it allows data retrieval to take place in the background, lessening the system load.

Scripting Steps

Listing 11.20 contains a script that uses an asynchronous query to return a list of all the files on a computer. To carry out this task, the script must perform the following steps:

 1 Const POPUP_DURATION = 120
 2 Const OK_BUTTON = 0
 3 Set objWSHShell = Wscript.CreateObject("Wscript.Shell")
 4 strComputer = "."
 5 Set objWMIService = GetObject("winmgmts:" _
 6     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 7 Set objSink = WScript.CreateObject("WbemScripting.SWbemSink","SINK_")
 8 objWMIService.ExecQueryAsync objSink, "SELECT * FROM CIM_DataFile"
 9 objPopup = objWshShell.Popup("Starting event retrieval", _
10     POPUP_DURATION, "Event Retrieval", OK_BUTTON)
11 Sub SINK_OnObjectReady(objEvent, objAsyncContext)
12     Wscript.Echo objEvent.Name
13 End Sub

Although it is possible to enumerate all the files on the computer, this procedure can be extremely slow, and typically yields far more information than you can make use of. A faster, and generally more useful, approach is to enumerate all the files in a particular folder. This allows you to do such things as verify that each of your servers has a Scripts folder containing a full set of system administration scripts. Likewise, you might want to connect to an application folder and verify the version number for each .dll file stored there.

To enumerate all the files in a folder, you can use a script similar to the one shown in Listing 11.19. The only difference is that you include a Where clause in your WQL query to restrict data retrieval to those files found in the specified folder.

Scripting Steps

Listing 11.21 contains a script that returns a list of all the files in the folder C:Scripts. To carry out this task, the script must perform the following steps:

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFiles = objWMIService.ExecQuery _
5     ("SELECT * FROM CIM_DataFile WHERE Path = '\Scripts'")
6 For Each objFile in colFiles
7     Wscript.Echo objFile.Name
8 Next

One of the advantages of using WMI as a file management tool is the fact that WMI allows you to locate all the files that meet a specified set of criteria, regardless of the physical location of those files. For example, you can return a collection of all the files consisting of a particular file name extension, all the read-only files, or all the files created on a specified date. After these files are enumerated, you can carry out various operations on the entire collection, including copying, deleting, or renaming each of the files.

Tip

If you want to limit your search to a particular drive, include the appropriate Where clause in your query. For example, the clause Where Drive = ’C’ limits the search to files found on drive C.

Scripting Steps

Listing 11.22 contains a script that returns a set of all the files with a file size larger than 1,000,000 bytes. To carry out this task, the script must perform the following steps:

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFiles = objWMIService.ExecQuery _
5     ("SELECT * FROM CIM_DataFile WHERE FileSize > 1000000")
6 For Each objFile in colFiles
7     Wscript.Echo objFile.Name & " — " & objFile.FileSize
8 Next

It is not unusual for files to be given new names. Sometimes this is done to provide a file with a more descriptive name (for example, changing 03b4cast.xls to Budget Forecast for 2003.xls). At other times, this is done to ensure that data is not lost or that other operations can proceed. For example, you might have a script that backs up the Application event log to a file named ApplicationBackup.evt. If that file already exists, the backup operation fails. Consequently, you might want to rename the existing version of ApplicationBackup.evt before running the backup script. This, and any other renaming operation, can be carried out using the CIM_Datafile Rename method.

When renaming a file, you must specify the complete path name. For example, to rename a file in the C:ScriptsLogs folder, you must include the entire path name as the parameter:

errResult = objFile.Rename("C:ScriptsLogsNewName.vbs")

Passing only the file name results in an error. For example, this line of code results in an “Invalid name” error:

errResult = objFile.Rename("NewName.vbs")

Scripting Steps

Listing 11.23 contains a script that renames a file. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFiles = objWMIService.ExecQuery _
 5     ("SELECT * FROM Cim_Datafile WHERE Name = " _
 6         & "'c:\scripts\toggle_service.vbs'")
 7 For Each objFile in colFiles
 8     errResult = objFile.Rename("c:scripts	oggle_service.old")
 9     Wscript.Echo errResult
10 Next

Using a script to rename a single file is inefficient; usually, it is faster to carry out this task using Windows Explorer or a command-line tool. A more practical operation might be to use a script to change the extensions of all the files in a folder. For example, you might have a folder containing numerous log files on a computer, all with the extension .log. Using a script, you can change the extension for all of these .log files to .txt or .bkp or anything else. These repetitive tasks represent the kinds of things that scripts do best.

When changing file name extensions using WMI, it is important to keep in mind that the Rename method requires a complete path. This means that you cannot simply specify a new file name extension for the file. Instead, you must construct an entire path.

For example, suppose you have a file named Performance.log in the C:LogsMailServer folder. To rename this file to Performance.bkp, you need to pass C:LogsMailServerPerformance.bkp as the Rename parameter. This new path can be constructed by combining:

Scripting Steps

Listing 11.24 contains a script that changes the file name extensions of all the .log files in a specified folder to .txt. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set FileList = objWMIService.ExecQuery _
 5     ("ASSOCIATORS OF {Win32_Directory.Name='c:Scripts'} Where " _
 6         & "ResultClass = CIM_DataFile")
 7 For Each objFile In FileList
 8     If objFile.Extension = "log" Then
 9         strNewName = objFile.Drive & objFile.Path & _
10             objFile.FileName & "." & "txt"
11         errResult = objFile.Rename(strNewName)
12         Wscript.Echo errResult
13     End If
14 Next

In addition to copying entire folders, you often need to copy individual files or specific sets of files. For example, you might need to copy a particular template to each computer or copy all .vbs files to a new administrator workstation. The CIM_Datafile Copy method can be used to copy individual files or a set of files from one location to another.

This ability to copy individual files (as opposed to entire folders) is especially powerful when combined with WMI’s ability to locate all the files of a specified type regardless of their location in the file system. This allows you to perform such tasks as automatically searching for all .log files and copying them to a central monitoring station, or searching for all Microsoft Word files and copying them to a document repository.

You can use the CIM_DataFile class and the Copy method to copy either a single file or a set of files to a new location.

Scripting Steps

Listing 11.25 contains a script that copies all the Microsoft® Windows Media® files on a computer to a specified folder. To carry out this task, the script must perform the following steps:

 1 strComputer = "."
 2 Set objWMIService = GetObject("winmgmts:" _
 3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
 4 Set colFiles = objWMIService.ExecQuery _
 5     ("SELECT * FROM CIM_DataFile WHERE Extension = 'wma'")
 6 For Each objFile in colFiles
 7     strCopy = "C:Media Archive" & objFile.FileName _
 8         & "." & objFile.Extension
 9     objFile.Copy(strCopy)
10 Next

Deleting files is as an integral part of file management. Files need to be deleted for many reasons: to free up disk space; to remove outdated files; to remove inappropriate files. WMI is a powerful tool for deleting files because it allows you to select a specified set of files (regardless of their physical location in the file system) and then delete all those files in a single operation.

For example, you might have a policy that prohibits users from storing media files on a particular file server. A WMI script can be scheduled to run each night, search for a specific set of files (for example, .mp3 or .wma files), and then delete all instances of that file type.

Unlike the FileSystemObject, the WMI Delete method automatically deletes read-only files. If you do not want to delete read-only files, you have to construct your query in such a way as to exclude these files from the returned collection (for example, by including the clause Where Readable = True).

Scripting Steps

Listing 11.26 contains a script that deletes all the Windows Media files from a computer. To carry out this task, the script must perform the following steps:

1 strComputer = "."
2 Set objWMIService = GetObject("winmgmts:" _
3     & "{impersonationLevel=impersonate}!\" & strComputer & "
ootcimv2")
4 Set colFiles = objWMIService.ExecQuery _
5     ("SELECT * FROM CIM_DataFile WHERE Extension = 'wma'")
6 For Each objFile in colFiles
7     objFile.Delete
8 Next

When you right-click a Shell object in Windows Explorer, a shortcut menu appears showing actions that can be performed on that object. For example, when you right-click a VBScript file, you see such options as Open, Edit, Print, Create Shortcut, and Delete.

Within the Shell nomenclature, each of the commands that appear on a shortcut menu is known as a verb. A verb is a text string in the registry that specifies the command to be run when the menu item is clicked. Different objects have a different set of verbs. The Recycle Bin, for example, does not have a Print option, but it does have an Empty Recycle Bin option.

The FolderItem object features an InvokeVerbEx method that allows you to execute any of the verbs associated with an object. For example, this command opens the associated file:

objFile.InvokeVerbEx("Open")

Calling InvokeVerbEx without specifying a verb automatically invokes the default verb for the object. For example, with a Windows Media file, the default verb is Play; for a folder, the default verb is Open.

Be aware that verbs always function in exactly the same way they do when clicked in Windows Explorer. If you right-click a file and select Open, the file automatically opens. If you select Delete, however, a confirmation box is displayed before the file is deleted. This same confirmation box appears if you attempt to delete any object using InvokeVerbEx. For example, using the Delete verb on a file results in a dialog box similar to the one shown in Figure 11.8.

Figure 11.8. Confirmation Dialog Box

By comparison, right-clicking a file and selecting Print does not display a dialog box; instead, the file is automatically printed to the default printer. If you use InvokeVerbEx to print a file programmatically, that file is automatically printed to the default printer without displaying a dialog box of any kind.

Scripting Steps

Listing 11.27 contains a script that prints all the files in the folder C:Logs. To carry out this task, the script must perform the following steps:

1 TargetFolder = "C:Logs"
2 Set objShell = CreateObject("Shell.Application")
3 Set objFolder = objShell.Namespace(TargetFolder)
4 Set colItems = objFolder.Items
5 For Each objItem in colItems
6     objItem.InvokeVerbEx("Print")
7 Next

One potential problem with carrying out actions using Shell object verbs is knowing which verbs, and thus which actions, are available to you. Fortunately, each Shell object exposes its verbs as a collection that can be enumerated programmatically. To identify the verbs for a particular Shell object, obtain a FolderItem object and then use the Verbs method to return a collection of all the verbs for that object. You can then list each verb in the collection.

Scripting Steps

Listing 11.28 contains a script that returns a list of all the Shell Object verbs that can be used with the Recycle Bin. To carry out this task, the script must perform the following steps:

1 Const RECYCLE_BIN = &Ha&
2 Set objShell = CreateObject("Shell.Application")
3 Set objFolder = objShell.NameSpace(RECYCLE_BIN)
4 Set objFolderItem = objFolder.Self
5 Set colVerbs = objFolderItem.Verbs
6 For Each objVerb in colVerbs
7     Wscript.Echo objVerb
8 Next

Folders are published in Active Directory to make it easier to identify all the shares on your network. After a folder is shared and published, you can locate it using tools such as Active Directory Users and Computers.

In addition, ADSI can be used to retrieve a list of all the folders that have been published in Active Directory. This can be done by constructing a script that returns all instances of the Volume class.

Scripting Steps

Listing 11.39 contains a script that enumerates the shared folders published in Active Directory. To carry out this task, the script must perform the following steps:

 1 On Error Resume Next
 2 Const ADS_SCOPE_SUBTREE = 2
 3 Set objConnection = CreateObject("ADODB.Connection")
 4 Set objCommand =   CreateObject("ADODB.Command")
 5 objConnection.Provider = "ADsDSOObject"
 6 objConnection.Open "Active Directory Provider"
 7 Set objCOmmand.ActiveConnection = objConnection
 8 objCommand.CommandText = "SELECT Name, unCName, ManagedBy FROM " _
 9     & "'LDAP://DC=Fabrikam,DC=com' WHERE objectClass='volume'"
10 objCommand.Properties("Timeout") = 30
11 objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
12 objCommand.Properties("Cache Results") = False
13 Set objRecordSet = objCommand.Execute
14 objRecordSet.MoveFirst
15 Do Until objRecordSet.EOF
16     Wscript.Echo "Share Name: " & objRecordSet.Fields("Name").Value
17     Wscript.Echo "UNC Name: " & objRecordSet.Fields("uNCName").Value
18     Wscript.Echo "Managed By: " & objRecordSet.Fields("ManagedBy").Value
19     objRecordSet.MoveNext
20 Loop

Retrieving a list of all the folders that are published in Active Directory is obviously useful. At the same time, in a large organization a list such as this might contain hundreds or even thousands of shares. Having to read through a list that large to find a particular folder or two would be very inefficient.

Fortunately, you can also search Active Directory for only those published folders that meet specific criteria. For example, you might search for a folder named FinanceShare, for all the folders managed by Ken Myer, or for all the folders that have “finance” as one of their keywords. By combining criteria, you can create targeted searches that help you quickly and easily locate only the published folders you are most interested in.

Scripting Steps

Listing 11.40 contains a script that searches for a published folder in Active Directory. To carry out this task, the script must perform the following steps:

 1 On Error Resume Next
 2 Const ADS_SCOPE_SUBTREE = 2
 3 Set objConnection = CreateObject("ADODB.Connection")
 4 Set objCommand =   CreateObject("ADODB.Command")
 5 objConnection.Provider = "ADsDSOObject"
 6 objConnection.Open "Active Directory Provider"
 7 Set objCOmmand.ActiveConnection = objConnection
 8 objCommand.CommandText = "SELECT Name, unCName, ManagedBy FROM " _
 9     & "'LDAP://DC=fabrikam,DC=com'" _
10         & " WHERE objectClass='volume' AND Keywords = 'finance*'"
11 objCommand.Properties("Timeout") = 30
12 objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
13 objCommand.Properties("Cache Results") = False
14 Set objRecordSet = objCommand.Execute
15 objRecordSet.MoveFirst
16 Do Until objRecordSet.EOF
17     Wscript.Echo "Share Name: " & objRecordSet.Fields("Name").Value
18     Wscript.Echo "UNC Name: " & objRecordSet.Fields("uNCName").Value
19     Wscript.Echo "Managed By: " & objRecordSet.Fields("ManagedBy").Value
20     objRecordSet.MoveNext
21 Loop

Because a published folder is simply an Active Directory object, it can be deleted using an ADSI script: You bind to the object and then use the DeleteObject method to remove it from Active Directory.

Deleting a published folder does not delete the contents of that folder, nor does it stop the sharing of that folder. Instead, it merely removes the folder from Active Directory.

Scripting Steps

Listing 11.41 contains a script that deletes a published folder from Active Directory. To carry out this task, the script must perform the following steps:

1 Set objContainer = GetObject("LDAP://CN=FinanceShare, " _
2     & "OU=Finance, DC=fabrikam, DC=com")
3 objContainer.DeleteObject (0)