Richard Siddaway's Blog : PowerShell and WMI

WMI migration

RichardSiddaway — Mon, 14 Dec 2009 18:16:19 GMT

In case you were wondering why the WMI based posts seem to have dried up – I have opened a new blog

http://itknowledgeexchange.techtarget.com/powershell/

Just for PowerShell and WMI.

I figure there is enough subject matter in the topic to support a separate site.

I will be covering the rest of the PowerShell world from here.

Technorati Tags: PowerShell,WMI

WMICookbook: Read Routing Table

RichardSiddaway — Fri, 20 Nov 2009 16:59:33 GMT

When we need to troubleshoot networking problems we will sometimes need to read the routing table on a machine. The routing table contains the information on the routes known to the network interfaces. This can be created automatically or manually . On the local machine we can use the route command to find this information – but how do we find it on a remote machine. WMI has a class that enables us to read the routing table.

            001              
002               
003               
004               
005               
006               
007               
008               
009               
010               
011               
012               
013               
014               
015               
016               
017               
018               
019               
020               
021               
022               
023               
024               
025               
026               
027               
028               
029               
030               
031               
032               
033               
034               
035               
036               
037               
038               
039               
040               
041               
042               
043               
044               
045               
046               
047               
048               
049               
050               
051               
052               
053               
054               
055               
056               
057               
058               
059               
060               
061               
062               
063               
          function Get-RouteTable {               
param (               
    [parameter(ValueFromPipeline=$true)]               
    [string]$computer="."               
)               
              
## create class for object               
$source=@"                
public class WmiIPRoute                 
{                 
    private string _destination;                 
    private string _mask;                 
    private string _nexthop;                 
    private string _interface;                 
    private int _metric;                 
    
     public string Destination {                 
        get {return _destination;}                 
        set {_destination = value;}                 
    }                 
    
    public string Mask {                 
        get {return _mask;}                 
        set {_mask = value;}                 
    }                 
    
    public string NextHop {                 
        get {return _nexthop;}                 
        set {_nexthop = value;}                 
    }                 
    
    public string Interface {                 
        get {return _interface;}                 
        set {_interface = value;}                 
    }                 
    
    public int Metric {                 
        get {return _metric;}                 
        set {_metric = value;}                 
    }                 
}                 
"@               
Add-Type -TypeDefinition $source               
              
    $data = @()               
    Get-WmiObject -Class Win32_IP4RouteTable -ComputerName $computer| foreach {               
        $route = New-Object -TypeName WmiIPRoute               
        $route.Destination = $_.Destination               
        $route.Mask        = $_.Mask               
        $route.NextHop     = $_.NextHop               
        $route.Metric      = $_.Metric1               
                      
        $filt = "InterfaceIndex='" + $_.InterfaceIndex + "'"                
        $ip = (Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter $filt -ComputerName $computer).IPAddress               
              
        if ($_.InterfaceIndex -eq 1) {$route.Interface = "127.0.0.1"}               
        elseif ($ip.length -eq 2){$route.Interface = $ip[0]}               
        else {$route.Interface = $ip}               
                      
        $data += $route               
    }               
    $data | Format-Table -AutoSize                
} 
       
 

Our function takes a single parameter – a computer name (or IP address) I’ve used the advanced function parameters to this function operates on the pipeline. We then create a .NET class to hold our data – we will be accessing a couple of WMI classes so we’ll make the presentation neat. The class is added using Add-Type.

As an aside I really like this technique for collecting data together into a single object. Its neater and easier to use than Add-Member.

We can then use Get-WmiObject -Class Win32_IP4RouteTable -ComputerName $computer to retrieve the routing information. We create an instance of our object and populate the properties. One thing we need to know is the Interface ie which address on our machine is using this route, We can find this from the Win32_NetworkAdapterConfiguration class. There isn’t an association but we can find the address by using the InterfaceIndex as a filter – its the same value in both classes. if the InterfaceIndex = 1 its the Loopback Adapter on 127.0.0.1

We can then add our route to the data. When all the routes are collected we can display the data. The data could be output onto the pipeline but at the moment I can’t think what else to do with it so we’ll leave it like this for now.

Note: Win32_IP4RouteTable is only available on Windows 2003 and later

Technorati Tags: PowerShell,WMI,Networking,Routing Table

WMI CookBook: WMI Presentation

RichardSiddaway — Tue, 17 Nov 2009 19:13:36 GMT

As with other PowerShell objects there is a default format for the display of WMI objetcs. If we look at the NetworkAdapter class

PS> Get-WmiObject -Class Win32_NetworkAdapter -Filter "DeviceId='11'"

ServiceName      : athr
MACAddress       : 00:00:00:00:00:00
AdapterType      : Ethernet 802.3
DeviceID         : 11
Name             : Atheros AR5007 802.11b/g WiFi Adapter
NetworkAddresses :
Speed            : 54000000

You didn’t think I’d really give you my MAC address did you?

If we want to see all of the properties we can do this

Get-WmiObject -Class Win32_NetworkAdapter -Filter "DeviceId='11'" | select -Property *

but we get a few ugly looking entries

__GENUS
__CLASS
__SUPERCLASS
__DYNASTY
__RELPATH
__PROPERTY_COUNT
__DERIVATION
__SERVER
__NAMESPACE
__PATH

that we may not actually want or need.

We can easily filter them out if desired

Get-WmiObject -Class Win32_NetworkAdapter -Filter "DeviceId='11'" | select -Property * -ExcludeProperty "__*"

The ExcludeProperty takes a wild card to identify the properties with two underscore characters at the front.

Simple but effective.

Technorati Tags: PowerShell,WMI,Property Selection

WMI CookBook: Associators Pt I

RichardSiddaway — Mon, 16 Nov 2009 21:03:30 GMT

WMI is a wonderful thing and like many people I have a love-hate relationship with it. It is incredibly powerful, and can take you deep into the system, but it is not easy to find your way.

I have decided to spend some time digging into WMI and will document the findings in a (long) series of blog posts. I also intend to pull the information together into a document that will be available for download. The scripts will end up in PowerShell modules that will also be available for download.

I am doing this with PowerShell v2 on Windows 7. Where necessary, and wherever possible, I will give alternatives that can be used with PowerShell v1.

The main trick with WMI is finding out the class or classes we need to actually use. The standard PowerShell way of searching for classes is to use the –List parameter. Network Adapters are common items we need to deal with so we’ll see what WMI can tell us. First, what WMI classes deal with Network Adapters. One thing we can do with –List is give a partial class name and a wildcard to restrict the results (otherwise we get lots, and lots of classes returned). To begin with I’m only interested in the name of the class. I’m working in the default name space so don’t need to mention it.

PS> Get-WmiObject -List "Win32_NetworkAdapter*" | Select Name

Name
----
Win32_NetworkAdapter
Win32_NetworkAdapterConfiguration
Win32_NetworkAdapterSetting

We could now go off to MSDN and check what these classes do but we can find that information directly. As Jeffrey showed recently http://blogs.msdn.com/powershell/archive/2009/08/30/exploring-wmi-with-powershell-v2.aspx we can use the –Amended parameter to show the description property.

            001              
002               
003               
          Get-WmiObject -List "Win32_NetworkAdapter*" | foreach {               
    (( Get-WmiObject -List $_.Name  -Amended ).Qualifiers | Where {$_.Name -eq "Description"}).Value               
} 
       
 

This gives use this information for the three classes.

The Win32_NetworkAdapter class represents a network adapter on a Win32 system.
The Win32_NetworkAdapterConfiguration class represents the attributes and behaviors of a network adapter. This class has been extended to include extra properties and methods that support the management of the TCP/IPprotocols (and are independent of the network adapter).
The Win32_NetworkAdapterSetting class represents an association between a network adapter and its configuration settings.

If we look at Win32_NetworkAdapterSetting

Get-WmiObject Win32_NetworkAdapterSetting

we will see an entry for each adapter that links the adapter with its configuration. This information is paired like this:

Element : \\RSLAPTOP01\root\cimv2:Win32_NetworkAdapter.DeviceID="11"
Setting : \\RSLAPTOP01\root\cimv2:Win32_NetworkAdapterConfiguration.Index=11

If we look at the adapter and its configuration

Get-WmiObject -Class Win32_NetworkAdapter -Filter "DeviceID='11'"

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "Index='11'"

we can see the individual information. Going through the Win32_NetworkAdapterSetting class is tedious but now we now that the adapter’s DeviceId is linked to the Configurations Index we can use this ASSOCIATION via a bit of WQL.

Get-WmiObject -Query "ASSOCIATORS OF {Win32_NetworkAdapter.DeviceID='11'} WHERE ResultClass=Win32_NetworkAdapterConfiguration"

DHCPEnabled      : True
IPAddress        : {192.168.196.138, fe80::6d95:b824:6a72:a0a9}
DefaultIPGateway : {192.168.196.1}
DNSDomain        :
ServiceName      : athr
Description      : Atheros AR5007 802.11b/g WiFi Adapter
Index            : 11

The other thing to think about is what other associations exist.

PS> Get-WmiObject -Query "ASSOCIATORS OF {Win32_NetworkAdapter.DeviceID='11'} " | Select __CLASS -Unique

__CLASS
-------
Win32_PnPEntity
Win32_ComputerSystem
Win32_NetworkAdapterConfiguration
Win32_IRQResource
Win32_DeviceMemoryAddress
Win32_NetworkProtocol
Win32_SystemDriver

So we have a set of classes that are all associated through the network adpater device id. In the next few posts we will dig into this web and see what we can discover and how we can use these associations to help us understand our system.

Technorati Tags: PowerShell,WMI,Network

PowerShell WMI events

RichardSiddaway — Sat, 07 Nov 2009 21:29:51 GMT

In my previous post ( http://richardsiddaway.spaces.live.com/blog/cns!43CFA46A74CF3E96!2598.entry or http://richardsiddaway.spaces.live.com/blog/cns!43CFA46A74CF3E96!2598.entry ) I started to look at WMI events in PowerShell v2. The win32_process class was used but all that showed us was that a process had started. We need a bit more information. A bit of digging brought up the Win32_ProcessStartTrace class that seems to do what we want.

Register-WMIEvent allows us to specify the class we want to use rather than a query – however if we try that we don’t get anything returned - oops.

Looking through the help for Register-WMIEvent shows that we have the possibility of performing an action when the event occurs. The action scriptblock can use a number of variables including $Event, $EventSubscriber, $Sender, $SourceEventArgs, and $SourceArgs automatic variables. Wanting to understand these variables I tried dumping it though get-member.

PS> Register-WmiEvent -Query "Select * FROM Win32_ProcessStartTrace" -Action {$Event | gm}

Id              Name            State      HasMoreData     Location             Command
--              ----            -----      -----------     --------             -------
2               c1016218-f80... NotStarted False                                $Event | gm

The subscription runs as a PowerShell job. Using the opening of Notepad to trigger the event we can see that data is returned.

PS> Get-Job

Id              Name            State      HasMoreData     Location             Command
--              ----            -----      -----------     --------             -------
2               c1016218-f80... Running    True                                 $Event | gm

And see that we have a few properties to play with. ComputerName may come in useful if we are dealing with remote machines.

PS> Receive-Job -Id 2

TypeName: System.Management.Automation.PSEventArgs

Name             MemberType Definition
----             ---------- ----------
Equals           Method     bool Equals(System.Object obj)
GetHashCode      Method     int GetHashCode()
GetType          Method     type GetType()
ToString         Method     string ToString()
ComputerName     Property   System.String ComputerName {get;}
EventIdentifier Property   System.Int32 EventIdentifier {get;}
MessageData      Property   System.Management.Automation.PSObject MessageData {get;}
RunspaceId       Property   System.Guid RunspaceId {get;}
Sender           Property   System.Object Sender {get;}
SourceArgs       Property   System.Object[] SourceArgs {get;}
SourceEventArgs Property   System.EventArgs SourceEventArgs {get;}
SourceIdentifier Property   System.String SourceIdentifier {get;}
TimeGenerated    Property   System.DateTime TimeGenerated {get;}

The properties look similar to those we saw in the last post. Lets dig into SourceEventArgs

PS> Register-WmiEvent -Query "Select * FROM Win32_ProcessStartTrace" -Action {$Event.SourceEventArgs | gm}

Id              Name            State      HasMoreData     Location             Command
--              ----            -----      -----------     --------             -------
3               8d4246a5-5f8... NotStarted False                                $Event.SourceEventArgs...

PS> Get-Job

Id              Name            State      HasMoreData     Location             Command
--              ----            -----      -----------     --------             -------
3               8d4246a5-5f8... Running    True                                 $Event.SourceEventArgs...

PS> Receive-Job -Id 3

TypeName: System.Management.EventArrivedEventArgs

Only thing here that look interesting is NewEvent

PS> Register-WmiEvent -Query "Select * FROM Win32_ProcessStartTrace" -Action {$Event.SourceEventArgs.NewEvent | gm}

Id              Name            State      HasMoreData     Location             Command
--              ----            -----      -----------     --------             -------
4               0857a744-1d3... NotStarted False                                $Event.SourceEventArgs...

PS> Receive-Job -Id 4

TypeName: System.Management.ManagementBaseObject#\Win32_ProcessStartTrace

Name                MemberType Definition
----                ---------- ----------
ParentProcessID     Property   System.UInt32 ParentProcessID {get;set;}
ProcessID           Property   System.UInt32 ProcessID {get;set;}
ProcessName         Property   System.String ProcessName {get;set;}
SECURITY_DESCRIPTOR Property   System.Byte[] SECURITY_DESCRIPTOR {get;set;}
SessionID           Property   System.UInt32 SessionID {get;set;}
Sid                 Property   System.Byte[] Sid {get;set;}
TIME_CREATED        Property   System.UInt64 TIME_CREATED {get;set;}
__CLASS             Property   System.String __CLASS {get;set;}
__DERIVATION        Property   System.String[] __DERIVATION {get;set;}
__DYNASTY           Property   System.String __DYNASTY {get;set;}
__GENUS             Property   System.Int32 __GENUS {get;set;}
__NAMESPACE         Property   System.String __NAMESPACE {get;set;}
__PATH              Property   System.String __PATH {get;set;}
__PROPERTY_COUNT    Property   System.Int32 __PROPERTY_COUNT {get;set;}
__RELPATH           Property   System.String __RELPATH {get;set;}
__SERVER            Property   System.String __SERVER {get;set;}
__SUPERCLASS        Property   System.String __SUPERCLASS {get;set;}

Now we have got to the information we need. So how can we use this. Up to now we have just allowed the job to run and then picked the data from the job. One option is to write the data to the prompt as shown in this example http://blogs.msdn.com/powershell/archive/2009/08/30/exploring-wmi-with-powershell-v2.aspx. A lot of this digging was because I didn’t understand how this was put together. PowerShell really is the best way to discover how to use PowerShell!!

This gets us to this script which is modified from the PowerShell Team blog

            001              
002               
003               
004               
005               
006               
007               
008               
009               
010               
011               
          ## query               
$q = "Select * from Win32_ProcessStartTrace"               
## action script block               
$a = {               
    $eSEANE = $Event.SourceEventArgs.NewEvent               
    $str = 'Computer {0},ID {1}, Name "{2}", Time {3}, Source {4}'                
    $data = $str -f $Event.Sender.Scope.Path.Server, $eSEANE.ProcessId, `               
      $eSEANE.ProcessName, $Event.TimeGenerated, $Event.SourceIdentifier               
    Write-Host $data               
}               
Register-WmiEvent -Query $q -SourceIdentifier "Process Start" -Action $a 
       
 

Turns out the ComputerName parameter doesn’t work but a comment on the blog shows how Jeffrey Hicks solved the problem.

What we get now is a listing at our PowerShell prompt when a new process starts. We can keep working and the data comes through when the prompt is idle.

Next we will look at closing a process and recording the data in a log

Technorati Tags: PowerShell v2,WMI,Events

PowerShell Eventing

RichardSiddaway — Sat, 07 Nov 2009 14:41:38 GMT

This isn’t the latest sport added for the 2012 Olympics but a way to dig deeper into what is happening on your machine. There is a continuous stream of events occurring on a computer – programs stop or start, files open or close etc etc. Some, but all, of these events are recorded in the event logs. If we want to understand what is happening we can track this using the PowerShell Event engine that is introduced in PowerShell v2.

Three types of events can be registered – PowerShell engine, .NET and WMI using the following cmdlets respectively

We can use the following cmdlets to discover the events that actually happen.

Get-Event
Get-EventSubscriber
New-Event
Remove-Event
Unregister-Event
Wait-Event

We’ll start by looking at WMI events. We can use Register-WmiEvent to register the event we want to track. In this case we want to know when new processes are started. We can create an event registration using

Register-WmiEvent -Query "Select * from __instancecreationevent within 5 where targetinstance isa 'Win32_Process'" -MessageData "Process Started" -SourceIdentifier "New Process"

__instancecreationevent is a WMI System Class. 5 refewrs to the system being scanned every 5 seconds

WMI System classes are created on a per WMI namespace basis i.e. a new set of system classes is created for each WMI namespace. The full list of WMI system classes can be seen at http://msdn.microsoft.com/en-us/library/aa394583(VS.85).aspx or can be browsed using PowerGUI's WMI browser.

We can view the system classes relating to WMI events.

Get-WmiObject -Namespace 'root\cimv2' -List "__*Event"

and we will see that there is a __InstanceDeletionEvent class as well. if we want to track process creation and deletion (program open and close) we will need to register this as well.

Register-WmiEvent -Query "Select * from __instancedeletionevent within 5 where targetinstance isa 'Win32_Process'" -MessageData "Process Stopped" -SourceIdentifier "End Process"

When we run these commands nothing seems to happen. We can see the event registrations (or subscriptions)

PS> Get-EventSubscriber

SubscriptionId   : 1
SourceObject     : System.Management.ManagementEventWatcher
EventName        : EventArrived
SourceIdentifier : New Process
Action           :
HandlerDelegate :
SupportEvent     : False
ForwardEvent     : False

SubscriptionId   : 2
SourceObject     : System.Management.ManagementEventWatcher
EventName        : EventArrived
SourceIdentifier : End Process
Action           :
HandlerDelegate :
SupportEvent     : False
ForwardEvent     : False

If we start notepad and and then check the process

PS> Get-Process notepad | select name, starttime

Name                                                        StartTime
----                                                        ---------
notepad                                                     07/11/2009 14:20:19

we can compare this to the event information

PS> Get-Event -SourceIdentifier "New Process"

ComputerName     :
RunspaceId       : 2a581963-55cd-4e46-82ab-ddb6a38fa9a2
EventIdentifier : 27
Sender           : System.Management.ManagementEventWatcher
SourceEventArgs : System.Management.EventArrivedEventArgs
SourceArgs       : {System.Management.ManagementEventWatcher, System.Management.EventArrivedEventArgs}
SourceIdentifier : New Process
TimeGenerated    : 07/11/2009 14:20:23
MessageData      : Process Started

Which doesn’t seem to tell is much beyond the fact that a process has started – it specifically doesn’t tell us which process has started.

Similarly when we stop a process

PS> Stop-Process -Name notepad
PS> Get-Event -SourceIdentifier "End Process"

ComputerName     :
RunspaceId       : 2a581963-55cd-4e46-82ab-ddb6a38fa9a2
EventIdentifier : 29
Sender           : System.Management.ManagementEventWatcher
SourceEventArgs : System.Management.EventArrivedEventArgs
SourceArgs       : {System.Management.ManagementEventWatcher, System.Management.EventArrivedEventArgs}
SourceIdentifier : End Process
TimeGenerated    : 07/11/2009 14:27:47
MessageData      : Process Stopped

We get a message that the process has stopped but no identification as to which process.

Events only exist in the current session and the subscriptions are lost if the PowerShell session is closed.

Couple of quick points

The event queue can be quickly cleaned using

Get-Event | Remove-Event.

We can remove event subscriptions using

Unregister-Event -SourceIdentifier "New Process"
Unregister-Event -SourceIdentifier "End Process"

We will dig further into the eventing capabilities in future posts

Technorati Tags: PowerShell v2,WMI,Events

System Up Time

RichardSiddaway — Wed, 12 Aug 2009 23:11:22 GMT

The PowerShell team have just posted about obtaining system up time using a .NET class to convert the WMI date format to something thats readable

http://blogs.msdn.com/powershell/archive/2009/08/12/get-systemuptime-and-working-with-the-wmi-date-format.aspx

There is a WMI only way of doing this

$os = Get-WmiObject -Class Win32_OperatingSystem
$os.ConvertToDateTime($os.LastBootUpTime)

But this gives the date and time the system was last booted. If you want the actual up time then use

(get-date) - $os.ConvertToDateTime($os.LastBootUpTime)

which generates a timespan object

Days              : 0
Hours             : 1
Minutes           : 53
Seconds           : 8
Milliseconds      : 461
Ticks             : 67884618000
TotalDays         : 0.0785701597222222
TotalHours        : 1.88568383333333
TotalMinutes      : 113.14103
TotalSeconds      : 6788.4618
TotalMilliseconds : 6788461.8

which gives the actual up time. The .NET method can be substituted for the WMI method if required

Technorati Tags: PowerShell,WMI,UpTime

Creating a process

Richard's space — Tue, 28 Apr 2009 21:03:25 GMT

I've looked at creating a process before - using [WMIClass]. With CTP3 we have a few more options Start-Process -Filepath notepad.exe Invoke-WMIMethod -Class Win32_process -Name Create -ArgumentList notepad.exe Set-WMIinstance -Class Win32_process...(read more)

WMI Methods and Properties

Richard Siddaway's Blog — Tue, 17 Mar 2009 17:58:48 GMT

Its odd how we discover things. I need to check the WMI classes for network adapters so used Get-WmiObject -List -Class *network* I intended to check out the data returned so used Get-WmiObject -List -Class win32_networkadapterconfiguration Notice I’ve...(read more)

Discovering WMI

Richard Siddaway's Blog — Thu, 19 Feb 2009 20:19:29 GMT

One thing that seems to come up rather frequently on the newsgroups is what WMI class do I need to use to do X. The really confusing thing about WMI is knowing just what is available. I have done far more with WMI since discovering PowerShell than I ever...(read more)

W2KSG: Unique file names

Richard Siddaway's Blog — Thu, 16 Oct 2008 16:46:53 GMT

Having seen how to back up our event logs we will need to do this periodically so we need to create unique file names for the backups. The obvious candidate is to base it on the date. Listing 12.7 $date = Get-Date Get-WmiObject -Class Win32_NTEventLogFile...(read more)

W2KSG: Triggered Event Log backups

Richard Siddaway's Blog — Thu, 16 Oct 2008 16:38:17 GMT

We have seen how to backup and clear the event log. What about checking all of the event logs and doing a backup and clear if they have reached a certain size Listing 12.6 Get-WmiObject -Class Win32_NTEventLogFile | Where {$_.FileSize -gt 10MB} | Foreach...(read more)

W2KSG: Backup Event Log

Richard Siddaway's Blog — Tue, 14 Oct 2008 19:27:22 GMT

We have see how to modify event log properties - lets look at backing them up and clearing out the entries. Preferably in that order. Listing 12.5 $log = Get-WmiObject -Class Win32_NTEventLogFile -Filter "LogFileName = 'Application'"...(read more)

W2KSG: Log Properties

Richard Siddaway's Blog — Mon, 13 Oct 2008 19:11:20 GMT

Having seen how to view the log properties lets see how we can change them. One possibility is with WMI. Lets start by viewing the event logs Get-WmiObject -Class Win32_NTEventLogFile one thing to note is that the property with the log file name is LogFileName...(read more)

W2KSG: Page File

Richard Siddaway's Blog — Fri, 10 Oct 2008 07:33:49 GMT

In theory Listing 10.19 Get-WmiObject -Class Win32_PageFile | Select CreationDate, Description, Drive, FileName, FileSize, InitialSize, InstallDate, MaximumSize,Name, Path should return information about the page file. On my Vista machine it doesn't...(read more)

W2KSG: File System Type

Richard Siddaway's Blog — Fri, 10 Oct 2008 07:14:38 GMT

Skipping forward to Listing 10.16 Get-WmiObject -Class Win32_LogicalDisk | Select DeviceId, FileSystem We can quickly scan the disks for the file system. One interesting point from this is that offline files are given a file system type of CSC-CACHE Share...(read more)

W2KSG: Free Disk Space

Richard Siddaway's Blog — Thu, 09 Oct 2008 17:56:57 GMT

Nope - not a 1960's political slogan. Previously we found out how to discover the logical disk drives on our machines. Having found them we want to know how much free space is available. Listing 10.6 $HardDisk = 3 Get-WmiObject -Class Win32_LogicalDisk...(read more)

W2KSG: Logical disks

Richard Siddaway's Blog — Thu, 09 Oct 2008 07:46:17 GMT

Physical disks support partitions and logical disks. To discover the logical disks on a machine we would use Listing 10.3 Get-WmiObject -Class Win32_LogicalDisk | Select Compressed,Description, DeviceID, DriveType, FileSystem, FreeSpace, MediaType, Name...(read more)

W2KSG: Disk Partitions

Richard Siddaway's Blog — Wed, 08 Oct 2008 07:13:28 GMT

After we have found the physical drives we need to think about the partitions on those drives Script Center Home > Microsoft Windows 2000 Scripting Guide > Scripting Solutions for System Administration > Disks and File Systems > Managing and...(read more)

W2KSG: Physical Disk Drive Properties

Richard Siddaway's Blog — Tue, 07 Oct 2008 10:28:19 GMT

Lets stick with WMI and jump forward to chapter 10 where we will concentrate on disks and the file system Starting point is physical disks. The WMI class the logically named Win32_DiskDrive. If you want to see all properties use Get-WmiObject Win32_DiskDrive...(read more)