{"id":52213,"date":"2009-10-20T00:01:00","date_gmt":"2009-10-20T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2009\/10\/20\/hey-scripting-guy-part-2-how-can-i-make-sure-that-a-wmi-provider-exists-before-using-it-in-a-script\/"},"modified":"2009-10-20T00:01:00","modified_gmt":"2009-10-20T00:01:00","slug":"hey-scripting-guy-part-2-how-can-i-make-sure-that-a-wmi-provider-exists-before-using-it-in-a-script","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/hey-scripting-guy-part-2-how-can-i-make-sure-that-a-wmi-provider-exists-before-using-it-in-a-script\/","title":{"rendered":"Hey, Scripting Guy! Part 2: How Can I Make Sure That a WMI Provider Exists Before Using It in a Script?"},"content":{"rendered":"

\"Bookmark<\/a> <\/p>\n

(Editor’s note<\/strong>: This is part 2 of a two-part article originally intended for TechNet Magazine<\/em>. Part 1 was published yesterday<\/a>.) <\/p>\n

 <\/p>\n

To obtain information about the provider for a WMI class, you will need to open the class. Click the Open Class<\/b> button, and type the name of the WMI class in the box that appears. We are looking for the provider name for the Win32_Product<\/b> WMI class, and that is the name that you should type here. Click the OK<\/b> button after you have typed and submitted the class name. The object editor for the Win32_Product<\/b> WMI class now appears. This is seen in the following image. The first box of the object editor for Win32_Product<\/b> lists the qualifiers. Provider<\/b> is one of the qualifiers. WbemTest tells you the provider for Win32_Product<\/b> is MSIProv<\/b>.<\/p>\n

\"Image<\/a><\/p>\n


You then assign the name of the WMI provider to the $providerName<\/b> variable as seen here: <\/p>\n

$providerName = “MSIProv”<\/span><\/p>\n

<\/span><\/font><\/p>\n

The resulting object is stored in the $provider<\/b> variable. This is seen here: <\/p>\n

 $provider =  Get-WmiObject -Class __provider -filter “name = ‘$providerName'”<\/span><\/p>\n

<\/span><\/font><\/p>\n

If the provider was not found, there will be no value in the $provider<\/b> variable. You can therefore see if the $provider<\/b> variable is null. If the $provider<\/b> variable is not equal to null, the class ID of the provider is retrieved. The class ID of the WMI provider is stored in the clsID<\/b> property. This is seen here: <\/p>\n

 If($provider -ne $null)<\/font><\/span>
<\/span>   {<\/font><\/span>
<\/span>    $clsID = $provider.clsID<\/span><\/p>\n

<\/span><\/font><\/p>\n

If the function was run with the verbose parameter, the $VerbosePreference<\/b> variable is set to Continue<\/b>. When the value of $VerbosePreference<\/b> is equal to continue<\/b>, the Write-Verbose<\/b> cmdlet will display information on the console. On the other hand, if the value of the $VerbosePreference<\/b> variable is equal to SilentlyContinue<\/b>, the Write-Verbose<\/b> cmdlet does not display anything. This makes it easy to implement tracing features in a function without needing to create extensive test conditions. When the function is called with the Verbose<\/b> parameter, the class ID of the provider is displayed. This is seen here: <\/p>\n

    Write-Verbose “$providerName WMI provider found. ClsID is $($clsID)”<\/font><\/span>
<\/span>   }<\/span><\/p>\n

<\/span><\/font><\/p>\n

If the WMI provider is not found, the function returns false<\/b> to the calling code. This is seen here: <\/p>\n

 Else<\/font><\/span>
<\/span>   {<\/span><\/font>
<\/span>     Return $false<\/font><\/span>
<\/span>   }<\/span><\/p>\n

<\/span><\/font><\/p>\n

The next thing the function does is check the registry to ensure the WMI provider has been properly registered with DCOM. Once again, the Write-Verbose<\/b> cmdlet is used to provide feedback about the status of the provider check. This is seen here: <\/p>\n

   Write-Verbose “Checking for proper registry registration …”<\/span><\/p>\n

<\/span><\/font><\/p>\n

To search the registry for the WMI provider registration, the Windows PowerShell registry provider is used. By default, there is no Windows PowerShell drive for the HKEY_CLASSES_ROOT<\/b> registry hive. However, it is not a given that one would not have created such a drive in their Windows PowerShell profile. To avoid a potential error that might arise when creating a Windows PowerShell drive for the HKEY_CLASSES_ROOT<\/b> hive, the Test-Path<\/b> cmdlet is used to check to see if a HKCR:<\/b> drive exists. If the HKCR:<\/b> drive does exist, it will be used and the Write-Verbose<\/b> cmdlet is used to display a status message that states the HKCR:<\/b> drive was found and that the search is commencing for the class ID of the WMI provider. This is seen here: <\/p>\n

   If(Test-Path -path HKCR:)<\/font><\/span>
<\/span>      {<\/font><\/span>
<\/span>        Write-Verbose “HKCR: drive found. Testing for $clsID”<\/span><\/p>\n

<\/span><\/font><\/p>\n

To detect if the WMI provider is registered with DCOM, all that is necessary is to see if the class ID of the WMI provider is present in the CLSID section of HKEY_CLASSES_ROOT<\/b>. The best way to check for the presence of the registry key is to use the Test-Path<\/b> cmdlet. This is seen here: <\/p>\n

        Test-path -path (Join-Path -path HKCR:CLSID -childpath $clsID)<\/font><\/span> 
<\/span>      }<\/span><\/p>\n

<\/span><\/font><\/p>\n

On the other hand, if there is no HKCR:<\/b> drive on the computer, you can go ahead and create one. You could search for the existence of a drive that is rooted in HKEY_CLASSES_ROOT<\/b>, and if you found it, you could then use the Windows PowerShell drive in your query. To find if there are any Windows PowerShell drives rooted in HKEY_CLASSES_ROOT<\/b>, you could use the Get-PSDrive<\/b> cmdlet as seen here: <\/p>\n

Get-PSDrive | Where-Object { $_.root -match “classes” } |<\/font><\/span>
<\/span>Select-Object name<\/span><\/p>\n

<\/span><\/font><\/p>\n

But to be honest, it is more trouble than it is worth. There is nothing wrong with having multiple Windows PowerShell drives mapped to the same resource. Therefore, if there is not an HKCR:<\/b> drive, the Write-Verbose<\/b> cmdlet is used to display a message that the drive does not exist and will be created. This is seen here: <\/p>\n

   Else<\/font><\/span>
<\/span>     {<\/font><\/span>
<\/span>      Write-Verbose “HKCR: drive not found. Creating same.”<\/span> <\/p>\n

<\/span><\/font><\/p>\n

To create a new Windows PowerShell drive, you use the New-PSDrive<\/b> cmdlet to specify the name for the Windows PowerShell drive and the root location of the drive. Because this is going to be a registry drive, you will use the registry provider. When a Windows PowerShell drive is created, it displays feedback on the Windows PowerShell console. This feedback is seen here: <\/p>\n

PS C:AutoDoc> New-PSDrive -Name HKCR -PSProvider registry -Root Hkey_Classes_Ro
ot<\/font><\/span><\/p>\n

<\/span>Name       Provider      Root                                   CurrentLocation
—-       ——–      —-                                   —————
HKCR       Registry      Hkey_Classes_Root<\/span><\/p>\n

<\/span><\/font><\/p>\n

The feedback from creating the registry drive can be distracting. To get rid of the feedback, you can pipe the results to the Out-Null<\/b> cmdlet: <\/p>\n

      New-PSDrive -Name HKCR -PSProvider registry -Root Hkey_Classes_Root | Out-Null<\/span><\/p>\n

<\/span><\/font><\/p>\n

After the Windows PowerShell registry drive has been created, it is time to check for the existence of the WMI provider class ID. Before that is done, the Write-Verbose<\/b> cmdlet is used to provide feedback about this step of the operation: <\/p>\n

      Write-Verbose “Testing for $clsID”<\/span> <\/p>\n

<\/span><\/font><\/p>\n

The Test-Path<\/b> cmdlet is used to check for the existence of the WMI provider class ID. To build the path to the registry key, the Join-Path<\/b> cmdlet is used. The parent path is the HKCR:<\/b> registry drive CLSID hive, and the child path is the WMI provider class ID that is stored in the $clsID<\/b> variable. This is seen here: <\/p>\n

      Test-path -path (Join-Path -path HKCR:CLSID -childpath $clsID<\/span>)  <\/p>\n

<\/span><\/font><\/p>\n

After the Test-Path<\/b> cmdlet has been used to check for the existence of the WMI provider class ID, the Write-Verbose<\/b> cmdlet is used to display a message stating that the test is complete: <\/p>\n

      Write-Verbose “Test complete.”<\/span><\/p>\n

<\/span><\/font><\/p>\n

It is a best practice to not make permanent modifications to the Windows PowerShell environment in a script. Therefore, you will want to remove the Windows PowerShell drive if it was created in the script. The Write-Verbose<\/b> cmdlet is employed to provide a status update, and the Remove-PSDrive<\/b> cmdlet is used to remove the HKCR:<\/b> registry drive. To avoid cluttering the Windows PowerShell console, the result of removing the HKCR:<\/b> registry drive is piped to the Out-Null<\/b> cmdlet. This is seen here: <\/p>\n

      Write-Verbose “Removing HKCR: drive.”<\/font><\/span>
<\/span>      Remove-PSDrive -Name HKCR | Out-Null<\/span><\/font>
<\/span>     }<\/span><\/p>\n

<\/span><\/font><\/p>\n

The last thing that needs to be done is to set the $VerbosePreference<\/b> back to the value that was stored in the $oldVerbosePreference<\/b>. This line of code is executed even if no change to the $VerbosePreference<\/b> is made. This is seen here: <\/p>\n

  $VerbosePreference = $oldVerbosePreference
} #end Get-WmiProvider function<\/span><\/p>\n

<\/span><\/font><\/p>\n

The entry point to the script assigns a value to the $providerName<\/b> variable: <\/p>\n

$providerName = “msiprov”<\/span><\/p>\n

<\/span><\/font><\/p>\n

The Get-WmiProvider<\/b> function is called and it passes both the WMI provider name that is stored in the $providerName<\/b> variable and the verbose<\/b> switched parameter. The if<\/b> statement is used because the Get-WmiProvider<\/b> function returns a Boolean value (true or false): <\/p>\n

 if(Get-WmiProvider -providerName $providerName  -verbose )<\/span> <\/p>\n

<\/span><\/font><\/p>\n

If the return from the Get-WmiProvider<\/b> function is true, the WMI class supported by the WMI provider is queried by using the Get-WMiObject<\/b> cmdlet. This is seen here: <\/p>\n

  {<\/font><\/span>
<\/font><\/span>
    Get-WmiObject -class win32_product<\/font><\/span>
<\/span>
  }<\/font><\/span> <\/p>\n

<\/font><\/span><\/p>\n

If the WMI provider is not found, a message that states the WMI provider is not found is displayed on the console: <\/p>\n

else<\/font><\/span>
<\/span>  {<\/font><\/span>
<\/span>   “$providerName provider not found”<\/font><\/span>
<\/span>  }<\/span><\/p>\n

<\/span><\/font><\/p>\n

The entire Get-WmiProviderFunction.ps1 script is shown here:<\/p>\n

Figure 3  Get-WmiProviderFunction.ps1<\/strong><\/p>\n

Function Get-WmiProvider([string]$providerName, [switch]$verbose)<\/font><\/span>
<\/span>{<\/font><\/span>
<\/span> $oldVerbosePreference = $VerbosePreference<\/font><\/span>
<\/span> if($verbose) { $VerbosePreference = “continue” }<\/font><\/span>
<\/span> $provider =  Get-WmiObject -Class __provider -filter “name = ‘$providerName'”<\/font><\/span>
<\/span> If($provider -ne $null)<\/font><\/span>
<\/span>   {<\/font><\/span>
<\/span>    $clsID = $provider.clsID<\/font><\/span>
<\/span>    Write-Verbose “$providerName WMI provider found. ClsID is $($clsID)”<\/font><\/span>
<\/span>   }<\/font><\/span>
<\/span> Else<\/font><\/span>
<\/span>   {<\/span><\/font>
<\/span>     Return $false<\/font><\/span>
<\/span>   }<\/font><\/span>
<\/span>   Write-Verbose “Checking for proper registry registration …”<\/font><\/span>
<\/span>   If(Test-Path -path HKCR:)<\/font><\/span>
<\/span>      {<\/font><\/span>
<\/span>        Write-Verbose “HKCR: drive found. Testing for $clsID”<\/font><\/span>
<\/span>        Test-path -path (Join-Path -path HKCR:CLSID -childpath $clsID)<\/font><\/span> 
<\/span>      }<\/span><\/font>
<\/span>   Else<\/font><\/span>
<\/span>     {<\/font><\/span>
<\/span>      Write-Verbose “HKCR: drive not found. Creating same.”<\/font><\/span>
<\/span>      New-PSDrive -Name HKCR -PSProvider registry -Root Hkey_Classes_Root | Out-Null<\/span><\/font>
<\/span>      Write-Verbose “Testing for $clsID”<\/font><\/span>
<\/span>      Test-path -path (Join-Path -path HKCR:CLSID -childpath $clsID)<\/span><\/font> 
<\/span>      Write-Verbose “Test complete.”<\/span><\/font>
<\/span>      Write-Verbose “Removing HKCR: drive.”<\/font><\/span>
<\/span>      Remove-PSDrive -Name HKCR | Out-Null<\/span><\/font>
<\/span>     }<\/font><\/span>
<\/span>  $VerbosePreference = $oldVerbosePreference<\/font><\/span>
<\/span>} #end Get-WmiProvider function<\/font><\/span><\/p>\n

<\/span># *** Entry Point to Script ***<\/font><\/span>
<\/span>$providerName = “msiprov”<\/font><\/span>
<\/span> if(Get-WmiProvider -providerName $providerName  -verbose )<\/font><\/span>
<\/span>  {<\/span><\/font>
<\/span>    Get-WmiObject -class win32_product<\/span><\/font>
<\/span>  }<\/span><\/font>
<\/span>else<\/span><\/font>
<\/span>  {<\/span><\/font>
<\/span>   “$providerName provider not found”<\/span><\/font>
<\/span>  }<\/span><\/p>\n

<\/span><\/font><\/p>\n


We hope you will find these techniques useful and that you will incorporate them into your daily scripting needs. We invite you to join us on the Script Center<\/a> for the daily Hey, Scripting Guy! Blog post<\/a><\/span>. If you would like to be among the first to be informed about everything that is happening on the Script Center, you can follow us on Twitter<\/a>. We also make postings over on the Scripting Guys group on Facebook<\/a>. If you get stuck some night while you are working on a script, you can post to the Official Scripting Guys Forum<\/a>. We have an excellent group of moderators and other active members who are always willing to help other scripters. Of course, if you have questions, suggestions, or comments, you can always send us e-mail at scripter@microsoft.com<\/font><\/a>.<\/span>
<\/p>\n

Ed Wilson and Craig Liebendorfer, Scripting Guys<\/span><\/b><\/p>\n

<\/span><\/b><\/p>\n","protected":false},"excerpt":{"rendered":"

(Editor’s note: This is part 2 of a two-part article originally intended for TechNet Magazine. Part 1 was published yesterday.)    To obtain information about the provider for a WMI class, you will need to open the class. Click the Open Class button, and type the name of the WMI class in the box that […]<\/p>\n","protected":false},"author":595,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[3,4,45,6],"class_list":["post-52213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell","tag-wmi"],"acf":[],"blog_post_summary":"

(Editor’s note: This is part 2 of a two-part article originally intended for TechNet Magazine. Part 1 was published yesterday.)    To obtain information about the provider for a WMI class, you will need to open the class. Click the Open Class button, and type the name of the WMI class in the box that […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/52213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/595"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=52213"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/52213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=52213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=52213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=52213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}