Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to determine who has permissions to a shared folder.
Microsoft Scripting Guy, Ed Wilson, is here. It is finally the weekend here in Charlotte, North Carolina in the United States. It has seemed like a rather long week, in part due to several meetings, plus I took time out to record a show for TechNet Radio. Ironically, considering that we had two days off this week, the time has seemed compressed, and therefore, longer. Anyway, as I said earlier, it’s the weekend!
As someone who has written several thousand VBScript scripts in my lifetime, I do not consider it bad form to recycle some of that content when it comes time to create a new Windows PowerShell script. After all, when I leave the neighborhood of Windows PowerShell modules, snap-ins, cmdlets, and associated technology, an answer still may arise to a problem that involves Windows Management Instrumentation (WMI) or some other interface.
I was looking around to figure out a way to find out who has permissions to a particular shared folder on a remote server. Of course, I can target the Computer Management snap-in to a remote computer, but that is really slow. In fact, because the account I am logged on with does not have permissions to the remote server, it took me nearly 15 minutes to finally connect to the remote server (including several minutes of watching snap-ins initialize, the event log initialize, and a whole bunch of other hour glasses).
Surely, there has got to be a better way. Then it dawned on me…
I wrote a script to do this in the past…yes, long ago, I used to write VBScript code. Because I used Windows Search to index the full content of both VBS files and PS1 files, it was a simple matter to find the script I sought. The script I found is a VBScript file. I wrote the script on July 17, 2005 (as a matter of fact, I was in Montreal when I wrote the script).
I have written several Hey, Scripting Guy! Blog posts that talk about migrating VBScript code to Windows PowerShell code. Here, I am not really talking about migrating VBScript code to Windows PowerShell code, but I am talking about taking the essential hard part of the VBScript code and using that in Windows PowerShell. In fact, the Associators Of WMI query is essentially the same (this is great news because there are numerous Hey, Scripting Guy! Blog posts that feature an Associators Of WMI query. In fact, I have one article in particular where I talk specifically about issues involved in migrating WMI queries to Windows PowerShell). It a bit difficult to translate the query because of the concatenation and the line continuation characters from the VBScript script.
The complete Get-ShareUsers.ps1 script is shown here. For ease of use and copying, I have uploaded this script to the Scripting Guys Script Repository.
Get-ShareUsers.ps1
$cred = Get-Credential -Credential iammred\administrator
$share = "data"
$cn = "hyperv1"
$query = "Associators of {win32_LogicalShareSecuritySetting='$share'}
Where resultclass = win32_sid"
Get-WmiObject -query $query -cn $cn -cred $cred |
Select-Object -Property @{LABEL="User";EXPRESSION=
{"{0}\{1}" -f $_.ReferencedDomainName, $_.AccountName}}, SID
The first thing I do is use the Get-Credential cmdlet to get the credentials to use to make the remote connection. I specify the user name and domain, but this is not a requirement in the script. You can have it prompt you and not supply any information to it by default. To do this, use Get-Credential with no parameters. The code for this is shown here.
$cred = Get-Credential
The credential dialog box is shown in the following image.
Next, I add two additional variables. The first one is the name of the share to retrieve security information about, and the second variable is the name of the remote computer. In the code that follows, I assign a value of data and a computer name of hyperv1 to the two variables. These two lines of code are shown here.
$share = "data"
$cn = "hyperv1"
Obviously, you will need to modify these two lines of code prior to using the script. An improvement to the script would be to prompt for the name of the share and the name of the computer. This would keep me from having to edit the script prior to running it.
Next, I have the Associators Of WMI query. In this query, I look for associations between the Win32_LogicalShareSecuritySetting WMI class and the Win32_Sid WMI class. Here is the code that performs this action.
$query = "Associators of {win32_LogicalShareSecuritySetting='$share'}
Where resultclass = win32_sid"
It is now time to get the WMI information. To do this, I use the Get-WMIObject cmdlet. This command is shown here. (One thing to keep in mind is that alternate credentials cannot be supplied to a local WMI connection. This is a limitation of WMI, not Windows PowerShell.)
Get-WmiObject -query $query -cn $cn -cred $cred
I use the Select-Object cmdlet to retrieve three properties: the ReferencedDomainName, the AccountName, and the SID. I use a hash table to create a custom property called User that displays the user name and domain name in the form domainname\username. This portion of the script is shown here.
Select-Object -Property @{LABEL="User";EXPRESSION=
{"{0}\{1}" -f $_.ReferencedDomainName, $_.AccountName}}, SID
When I run the script via the Windows PowerShell ISE, the user names and their associated SID appear in the output pane. This output is shown in the following image.
To double check that the script works properly, I use the Computer Management tool, and I examine the share properties. This appears in the following image.
Well, that is about all there is to using Windows PowerShell to perform an Associators Of query to retrieve information about user’s access to a shared folder. Join me tomorrow as I modify this script a bit to make it more user friendly. Until then, have a great day.
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