Today, lets discuss a WMI class which you will need for interacting with the registry - and the class is StdRegProv.

A little bit of details on the StdRegProv class before we start:

StdRegProv has been a part of Root\Default WMI namespace. However, starting from Windows Vista it is also a part of Root\CIMV2 namespace. Therefore, one can create an instance of StdRegProv class from Root\CIMV2 or Root\Default Namespace. Consider using the Root\Default namespace, if you want your script to be compatible with older versions of Windows Operating System as well.

There is one more thing I want to focus your attention to about this class. You will need following specific numeric values to interact with specific registry hives. Below are the hives and their corresponding numeric values:

 Name                                        Value

HKEY_CLASSES_ROOT          2147483648

HKEY_CURRENT_USER         2147483649

HKEY_LOCAL_MACHINE        2147483650

HKEY_USERS                          2147483651

HKEY_CURRENT_CONFIG     2147483653

Not to digress, but while writing these values I just realized that this one makes for an excellent example of use of HashTable, doesn't it! Just create a HashTable with the keys as the hive names and assign the corresponding number as the value of each key. Below is an example of what I am talking about:

Now, it indeed becomes easy to access the numeric value of any hive (e.g. $regkey["HKEY_CLASSES_ROOT"] )

Having understood the important pieces of the StdRegProv class, now lets proceed with looking at some useful methods of this class. For this post, I am using the class from Root\Default namespace. Following are the two ways in which we can create a reference to this WMI class:

1.

2.

If you have any doubts on the above 2 methods of referencing a WMI class please refer to my "Introduction to WMI" (https://blogs.msdn.com/b/vishinde/archive/2012/09/15/introduction-to-wmi.aspx) blog post.

The advantage of using Get-WMIObject over [WMIClass] type accelerator is that Get-WMIObject has a -ComputerName parameter. That means you can fetch registry information from a remote machine very easily using the Get-WMIObject cmdlet. That is:

Using a Get-Member on the $regClass will list all the static members of the class:

Formatting this output in a tabular format and wrapping the contents will list all the parameters which are expected by this method as well ( $regClass | Get-Member | Format-Table -Wrap ).

We can use any of the Get.. methods in order to get a value from the registry. Lets say we want to retrieve a String value from the registry, in that case we will use the GetStringValue method. In the example below, we are reading the value of ExecutionPolicy key in the Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell folder. As a reminder, $regkey  is a HashTable we created earlier and HKEY_LOCAL_MACHINE is one of the keys of the HashTable.

In the output, ReturnValue 0 tells us that the operation was successful and sValue is the actual value. If you want to read just the ouptut, you can Select sValue from the output as shown in the example above.

Just like you can read different types of values using this class, you can read the keys and the values as well using this class. Example:

sNames is an array returned by EnumKey, hence we chose to use the ExpandProperty parameter on sNames to display all the Keys on a particular path. (Not sure what ExpandProperty parameter does? Check out my blog post on ExpandProperty parameter).

Just like you have EnumKey, there is also an EnumValue method, which lists the Valuenames in a particular key.

I think this post would remain incomplete if I didn't mention Invoke-WMIMethod cmdlet. Since we are calling static methods on the WMI class, we can also use Invoke-WMIMethod to call all the methods we have discussed in this post. I want to give you one example of using the Invoke-WMIMethod (to call EnumValues method). Just like we could call EnumValues, we can call any of the methods we have discussed in this blogpost.

According to me, one of the most important advantage offered by these cmdlets (Get-WMIObject and Invoke-WMIMethod) is that you have a -ComputerName and a -Credential parameter. That means you can connect to a remote machine using different credentials when you are using these WMI cmdlets.

Hopefully, this post gave you a good enough idea of how to interact with the registry on local or remote machine using WMI. Using this class you can create as well as delete keys or values. Doing a Get-Member along with a Format-Table -Wrap on the output will give you a good enough understanding of leveraging the different methods further. Just keep in mind that whenever you see hDefKey (Int32) parameter for any of these methods, you are supposed to pass the numeric value of a registry hive to that method.

This approach should be useful if you want to interact with registry on remote machines and don't have PowerShell v2 Remoting enabled on your remote machine yet. If you have PowerShell v2 Remoting enabled, its just about using *-Item and *-ItemProperty related cmdlets to interact with the Registry instead of doing this!

In this blog post, we will focus on Get-WMIObject, Invoke-WMIMethod and [WMIClass] type accelerator.

Lets start with Get-WMIObject first. Get-WMIObject is used to create instances of WMI classes. Using this cmdlet, we can create objects of WMI classes and start using members (methods and properties) of the WMI objects.

Example, lets create an instance of win32_process class. Once you do a Get-Member on that object, you will get a list of instance members you can access on that object. Also, if you refer to the example below, you will see that the Type of the object  is System.Management.ManagementObject. In other words, we created an "object" of win32_process WMI class. All the members are instance members and we can access them using the win32_process object e.g. $procObj.ProcessName.

Now lets look at [WMIClass]. [WMIClass] is a type accelerator for creating ManagementClass. What's the need of referring to a class? In WMI, there are instance members and static members. Static members are accessed on the class itself. So, if you want to access any static members of a WMI class you could use the WMIClass type accelerator. In the example below, you can see that [WMIClass] creates a System.Management.ManagementClass type. Apart from that, also notice that this time the members which you see are static members of the win32_process class. Now we can call the Create static method by using $processClass.Create, because $processClass is a class and static members can be referred to on a class. That is, we can say:

$processClass.Create("notepad.exe").

Now lets look at a different way of referencing a WMI class - using Get-WMIObject cmdlet. Along with creating instance of a WMI class, the Get-WMIObject cmdlet can also used for listing the WMI classes using the -list parameter. Once we have that list, we can filter any of the specific classes we want through this list. That selected class would be our reference of a WMI class. Lets look at an example of that:

So you will notice that the class type is same as the type name generated by the [WMIClass] type accelerator. There is a huge advantage in using this method over [WMIClass] and we will look into this when we discuss different examples of WMI (Hint: Think Remoting to different machines).

Now we can use the Static method "Create" of the Win32_Process class using the class reference $procClass:

That's one way of calling static members of a WMI class. However, PowerShell also gives you a cmdlet of calling methods of WMI classes, and the cmdlet is Invoke-WMIMethod. Following example shows use of Invoke-WMIMethod:

We provide the WMI class name to -Class parameter, method name to -Name parameter and parameters for the method to the -ArgumentList parameter. It also has a parameter which may be of amazing interest to you -ComputerName. Using this cmdlet, you can run methods on remote machines as well.

Hopefully, this article gave you a good overview of different ways of interacting with WMI classes. There are other WMI type accelerators as well, such as [WMISearcher], but we should be good to start interacting with WMI with an understanding of what we discussed in this blog. Again, I will refer you to this post, when needed, while discussing about different WMI classes.

Before diving into examples, lets go through the Get-Help information of ExpandProperty parameter of Select-Object cmdlet. It states - Specifies a property to select, and indicates that an attempt should be made to expand that property.

In other words - ExpandProperty expands the collections. That is, it will output the properties of every object in the collection.

Following examples will make ExpandProperty more clear. Let's start with Get-Process cmdlet.

Get-Process | Get-Member gives us different properties of "process" object. Let's focus on  the Modules property which is a ProcessModuleCollection:

Now, lets select the property Modules:

You will see that the output does not seem to be complete. That's because Modules is a collection and it has a collection of objects inside it. In order to display each object and its properties, you will have to use the ExpandProperty parameter of Select-Object. Let's look at the output generated using -ExpandProperty parameter before we discuss more about it:

Now you can see that since we used the ExpandProperty parameter, Select-Object "expanded" on the collection and displayed properties (Size, ModuleName and FileName) of each object inside the collection.

(Just a note: In the above example, I used Get-Process notepad just to reduce the output on my screen (by getting only notepad process related information) to give you a better view of what was happening. If you are using the same example, be sure to start a notepad process on your machine. Get-Process | Select-Object -ExpandProperty Modules would also give us a similar result, just that in that case it would be a lot of data outputted).

Let's look at another example here. Lets look at DependentServices property of "service" object. Let's start with Get-Service | Get-Member:

You see that DependentServices is an array of "service" (ServiceController) object. In other words, it can be looked at as a collection of service objects. That's the reason if we try to just Select-Object -Property DependentServices on Get-Service, we wont be able to get a complete view of the DependentServices.

Now. let's use the ExpandProperty on DependentServices and see the difference..

Because we used ExpandProperty we are able to see the expanded collection.

(Another note: In this case, rather than getting all the services, I just got the "samss" service (Get-Service samss), that's just to give you a better view of how the ExpandProperty parameter works. The service name is not important in this example, however what is important is that you need to get service which has some dependent services. In case you don't have the same service or if you want to check the property for some other service, here is a statement to fetch the services which have some dependent services:

Get-Service | Where-Object { $_.DependentServices }

To get an even better view you can fetch services which have more than 1 dependent services. For that, you can use the following statement:

Get-Service | Where-Object { ($_.DependentServices).count -gt 1 } )

Hopefully, these examples gave you a good understanding of ExpandProperty parameter of Select-Object cmdlet.

There is one another interesting and useful aspect to the ExpandProperty parameter. Till now, we applied ExpandProperty to the properties which were "collection" of some kind. If you apply ExpandProperty to a property which is not a collection, it gives you just the values not the object with properties. This example below should make it more clear:

If you pipe this is to Get-Member cmdlet, you will be able to see that the output is of "string" type and not anymore a "selected" object with "name" as a property of that object. And if you pipe this output to Get-Member you will see that the output is of type string.

You can use this output in multiple ways,depending on your requirements. One example would be - check if any service related cmdlets (Start-Service, Stop-Service) have parameter which "Accepts Pipeline Input" by value in "string" type. Now you can pipe this string output into your specific *service cmdlet and generate the required result. Once you go through my "Pipeline in PowerShell" blog, I am sure you will get why Accept Pipeline by value will work..

Another example of ExpandProperty on similar lines: This time lets expand the Id property of Get-Process cmdlet. Before that, let's do a Get-Member on Get-Process and take a look at the Id property:

Get-Process | Get-Member:

So we know that Id is a property of "process" object and it is of type integer. Now, lets expand the property and check the output:

This time as well, you see that we get the Id of processes as values not as properties of "selected" object. Pipe this output to Get-Member and you will see that the values are of type int.

Now you can see that when ExpandProperty is applied on properties which are not collections, we get the values (not "selected" objects with properties) and the values retain the original datatype of the properties. 

Hopefully, these examples helped you to understand in detail the ExpandProperty parameter of Select-Object cmdlet.

As a PFE, I travel quite a bit to different customer locations. Today, while sitting at the airport waiting to board my flight, I started wondering about the pipeline in PowerShell. If you think of it, the airplane could be correlated to a pipeline from which we humans and other objects (such as bags etc.) are passed from one place to another. Yeah, too much of PowerShell could do that to you.. you start seeing objects and pipeline everywhere! :)

On that thought, I decided to blog about pipeline in PowerShell while waiting to be "piped" from my current location to my destination!

There are a few aspects of pipeline which I'd like to discuss in this blog post. Firstly, what is passed through the pipeline and when can you use pipeline. To begin with, let's look into what passes through the pipeline...

Since this blog's scope is pipeline and not cmdlets, I am not going into detail of following cmdlets which I am using for demonstration - Get-Process, Foreach-Object, Start-Sleep and Import-CSV.

Let's start with one of the well-known cmdlets - Get-Process. Get-Process returns "process" objects, we can verify that by using Get-Process | Get-Member. The result will tell you that the cmdlet outputs
"Process" objects:

Now lets pipe this output into the foreach-object cmdlet:

Get-Process | Foreach-Object { $_ }

The output seems the same if compared with the output from Get-Process cmdlet:

Let's do some changes to the statement above to get a better understanding of what exactly is happening. Let’s add a delay of 1 second to the output by using Start-Sleep -seconds 1 cmdlet:

Get-Process | Foreach-Object { Start-Sleep -seconds 1; $_ }

This might give you a better view of the fact that objects are being passed through the pipeline and worked on asynchronously by the foreach-object cmdlet. However, you saw only ProcessName, WS, VM etc. in
the header of the output. Does that mean only these pieces of objects were passed through the pipeline? Certainly not, PowerShell is just displaying the specific properties of the "process" objects. We can confirm that by using Get-Member on our sequence of cmdlets:

Get-Process | Foreach-Object { $_ } | Get-Member

The above statement will display all the properties of the process object. If you compare, the output is similar to Get-Process | Get-Member. This demonstrates that entire process object is passed from the source
to destination cmdlet.

 Now that we understand objects are passed through the pipeline, let’s move on to the next objective of this blog – ‘when can you use the pipeline’.

Let’s take an example of Start-Service cmdlet and focus our attention on the "Name" parameter of the Start-Service cmdlet.

Let's do Get-Help Start-Service -Parameter Name to get only "Name" related help information.

Accept Pipeline Input - true - tells us that information can be piped into this parameter. We can see that there are two ways of passing these parameter values - "ByPropertyName" and "ByValue".
Let’s start with "By Value". As the name suggests, the value can be passed through the pipeline. That is, these two statements are equivalent..

Start-Service -Name bits

"bits" | Start-Service

where "bits" is the name of the service. Instead of passing value through the parameter, we passed the value through a pipeline as the parameter accepts pipeline input "by value". While piping, the datatype of the value was matched with the datatype of the parameter. The string datatype in this case matched with the datatype of the parameter “Name” and hence the statement was successful in starting the service named “bits”.
Now let’s look at other piece of the "Accepts Pipeline Input" - "By PropertyName". As the name suggests, we need to pass objects to the cmdlet and these objects should have property with the same name as the name of the parameter in the cmdlet. (This will be explained in the following example).

That is, in our example, we need to have an object with a property "name" (same as parameter "Name") to pass to the Start-Service cmdlet There are multiple ways of creating objects or properties in PowerShell, but that is outside the scope of this blog post.
Let’s use the Import-CSV cmdlet to create an object having property called "Name". For that, we will create a service.csv file with the following text:

name,description
bits,description of the service

Import-CSV on that file will give you the following output. An object has been created with "name" as one of its properties:

To make it simpler, lets use Get-Member to check the properties of the object. Lets do Import-CSV proc.csv | Get-Member -MemberType *Property to list all the properties of the object:

We can see that an object exists with "name" as one of its properties. Now, we will pass this object to Start-Service cmdlet.

Import-CSV service.csv | Start-Service

Once we do that, we will see that the "bits" service is started.

What happens behind the scenes is: the object generated from Import-CSV was passed to the Start-Service cmdlet. This object had a property called "name" which matched with the parameter called "Name" of Start-Service cmdlet. The property name had a value called "bits", therefore Start-Service started the "bits" service.

Hopefully, these examples should have given you a good understanding of the fundamentals of pipeline in PowerShell.

See you in my next topic of PowerShell. Till then, keep scripting! :)