Discover Which PowerShell Providers Support Credentials

Discover Which PowerShell Providers Support Credentials

  • Comments 3
  • Likes

Summary: Microsoft Scripting Guy Ed Wilson shows how to discover which Windows PowerShell providers support credentials.

Microsoft Scripting Guy, Ed Wilson, here. When I was in Redmond, Washington a couple of weeks ago teaching a Windows PowerShell class to a group of Microsoft networking engineers, a question came up about using alternate credentials. For example, the New-Item cmdlet has a credential parameter. The New-Item cmdlet can be used when operating the different PS drives that are supplied with the PS Provider. The cool thing about this is that I should be able to use New-Item to create a new file, and I should be able to supply credentials to this operation. This would enable me to create files in locations where the current user did not have rights.

Unfortunately, that exact scenario does not work. I remembered a “Lessons Learned” sidebar that I wrote in my Microsoft Press book, Windows PowerShell 2.0 Best Practices, and I referred the student to that page in my book. Since then, the question has come up again via the scripter@microsoft.com email alias. Therefore, I decided to share my sidebar with you here today.

The –credential switch was present in Windows PowerShell 1.0 in only one cmdlet: Get-WmiObject. This switch allows for the use of alternate credentials when making remote connections. This switch has been added to several cmdlets such as Add-Content and Get-Content. However, when I tested this by trying to access a file on a remote computer, it came back with the error message shown here.

Image of error

We can investigate this by examining the capabilities of the providers. First we need to see what types of capabilities the providers could support. To do this, we use the GetValues() static method from the System.Enum .NET Framework class. The GetValues() method takes one argument, the name of the .NET Framework class where it is to retrieve the enumeration values. The System.Management.Automation.Provider.ProviderCapabilities class contains the enumeration values that we are interested in. The code that obtains these values is shown here.

[enum]::getValues(“System.Management.Automation.Provider.ProviderCapabilities")

We obtain the following list of provider capabilities.

None

Include

Exclude

Filter

ExpandWildcards

ShouldProcess

Credentials

Transactions

Now that we have a listing of the capabilities available to providers, we need to see which default Windows PowerShell 2.0 providers support the Credentials capability. To see this, we can use the Get-PsProvider cmdlet. As seen here, none of the default Windows PowerShell 2.0 providers support the use of capabilities.

Get-PSProvider

Name                 Capabilities                            Drives

----                 ------------                            ------

Alias                ShouldProcess                           {Alias}

Environment          ShouldProcess                           {Env}

FileSystem           Filter, ShouldProcess                   {C, D, dle, apw...}

Function             ShouldProcess                           {Function}

Registry             ShouldProcess, Transactions             {HKLM, HKCU, HKCR}

Variable             ShouldProcess                           {Variable}

Certificate          ShouldProcess                           {cert, certCU}

WSMan                None                                    {WSMan}

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks for this post. But I think there are two open questions:

    Why decided Microsoft to not support the Credentials capability in the default providers?

    What is the recommended way to archive this behaviour anyway? Start a new PS process under different credentials?

  • @Martin It was not in scope for this release. There is always something else that can be added to a product, and if one is to ever ship the software, one must choose what features will be use the most, and will have the greatest impact. The easiest way to achieve this capability is to start a new instance of Windows PowerShell under alternate credentials ... RunAs makes this easy to do.

  • Thanks for this post, actually I am writing a script for multiple server, my script would be check the ADMIN permission for multiple server, I can pass server list as a text file. could you please help me on this?