{"id":2456,"date":"2013-12-08T00:01:00","date_gmt":"2013-12-08T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2013\/12\/08\/weekend-scripter-who-are-the-administrators\/"},"modified":"2013-12-08T00:01:00","modified_gmt":"2013-12-08T00:01:00","slug":"weekend-scripter-who-are-the-administrators","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/weekend-scripter-who-are-the-administrators\/","title":{"rendered":"Weekend Scripter: Who are the Administrators?"},"content":{"rendered":"

Summary<\/strong>: Guest blogger, Bill Stewart, talks about using Windows PowerShell to find administrators.\nMicrosoft Scripting Guy, Ed Wilson, is here. Hello everyone. It is the weekend, and guest blogger, Bill Stewart<\/a> is going to share his time and knowledge today. Bill is a scripting guru and a moderator for the Official Scripting Guys Forum…\nAs you know, an administrator of a Windows computer is a member of the computer’s local Administrators group. This is a special built-in group, so any user or group that’s a member of this special group is an administrator on the computer. We can see who the members of this group are by typing the command net localgroup Administrators<\/strong> at a cmd.exe or Windows PowerShell prompt.<\/p>\n

Get local group membership by using ADSI<\/h2>\n

But what if we want to get the members of the local Administrators group on a remote computer? We can’t use the net localgroup<\/strong> command because it works only on the local computer. Since we’re talking Windows  PowerShell, you might be aware that you can use the [ADSI]<\/strong> type accelerator to connect to a group on a computer; for example:<\/p>\n

$localAdminGroup = [ADSI] “WinNT:\/\/remotecomputer\/Administrators,Group”\nThis creates a System.DirectoryServices.DirectoryEntry object that references the local Administrators group on the computer RemoteComputer<\/strong>. This is an object, so we should be able to call its Members<\/strong> method to view the members of the group:<\/p>\n

$localAdminGroup.Members()\nHowever, this produces some peculiar output:<\/p>\n

System.__ComObject<\/p>\n

…\nThe members of the group are COM objects, but Windows PowerShell doesn’t know what to do with them because there’s no type library that tells Windows PowerShell the interface for the objects (that is, what the properties and methods are). The workaround is to call the InvokeMember<\/strong> method of each COM object’s base type to retrieve the name property, like this:<\/p>\n

$localAdminGroup.Members() | ForEach-Object {<\/p>\n

  $_.GetType().InvokeMember(“Name”, “GetProperty”, $NULL, $_, $NULL)<\/p>\n

}\nIt’s ugly, but it works. But we have another issue. What if you’re using a non-English version of Windows? Or what if the Administrators group has been renamed? In either case, the ADSI technique isn’t going to work because the group might not be named Administrators<\/em>.<\/p>\n

Get Administrators group name by using WMI<\/h2>\n

The alternative is to use WMI. By using WMI, we can ask for the group by its SID, S-1-5-32-544, rather than by its name:<\/p>\n

Get-WMIObject -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -Computer remotecomputer\nThis gives us output like this:<\/p>\n

Caption                        Domain          Name            SID<\/p>\n

——-                        ——          —-            —<\/p>\n

REMOTECOMPUTERAdministrators  REMOTECOMPUTER  Administrators  S-1-5-32-544\nGet-WMIObject<\/strong> supports credentials, so if you’re signed in with an account that doesn’t have permission to access the remote computer, you can create a credential object to make the connection:<\/p>\n

$credential = Get-Credential<\/p>\n

Get-WMIObject -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -ComputerName remotecomputer `<\/p>\n

  -Credential $credential<\/p>\n

Combine ADSI and WMI?<\/h2>\n

Now that we’ve connected to the actual Administrators group, we can use the Name<\/strong> property, with ADSI and script in the previous section, to get the members of the group:<\/p>\n

$credential = Get-Credential<\/p>\n

$computerName = “remotecomputer”<\/p>\n

$wmiObject = Get-WMIObject `<\/p>\n

  -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -ComputerName $computerName `<\/p>\n

  -Credential $credential<\/p>\n

$adminGroupName = $wmiObject.Name<\/p>\n

$adminGroup = [ADSI] “WinNT:\/\/$computerName\/$adminGroupName,Group”<\/p>\n

$adminGroup.Members() | ForEach-Object {<\/p>\n

  $_.GetType().InvokeMember(“Name”, “GetProperty”, $NULL, $_, $NULL)<\/p>\n

}\nNow we’re getting somewhere. The output of this script is a list of names like this:<\/p>\n

Administrator<\/p>\n

Domain Admins<\/p>\n

kendyer<\/p>\n

…\nThis is good, but we’re missing something. We know that Administrator is probably a local account and Domain Admins is probably a domain group. But we don’t know if kendyer is a local account or a domain account. To avoid confusion, it would be really helpful if the output contained the domain name for domain accounts.\nAlso, there’s another issue with this approach: It’s relatively inefficient. We’re making an initial WMI connection to the remote computer to retrieve the Administrators group name, and then we’re making a second connection (connecting to the ADSI group object) to retrieve the group members. This may not be an issue on a fast network, but over slower connections, it doesn’t scale very well.<\/p>\n

Use WMI to get members<\/h2>\n

To avoid making two separate connections to each remote computer, we can stick with WMI. When we connect to a computer and retrieve its Administrators group, we’re retrieving a .NET ManagementObject object:<\/p>\n

$credential = Get-Credential<\/p>\n

$computerName = “remotecomputer”<\/p>\n

$wmiObject = Get-WMIObject `<\/p>\n

  -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -ComputerName $computerName `<\/p>\n

  -Credential $credential<\/p>\n

“.NET object type: {0}” -f $wmiObject.GetType().FullName<\/p>\n

“WMI class: {0}” -f $wmiObject.__CLASS\nThe output of this command is:<\/p>\n

.NET object type: System.Management.ManagementObject<\/p>\n

WMI class: Win32_Group\nWMI objects can be related to each other by using associator classes; in this case, WMI relates the Win32_Group class with its members by using the Win32_GroupUser<\/strong> associator class. The WMI GetRelated<\/strong> method can use the Win32_GroupUser<\/strong> class to retrieve the group’s members, like this:<\/p>\n

$credential = Get-Credential<\/p>\n

$computerName = “remotecomputer”<\/p>\n

$wmiObject = Get-WMIObject `<\/p>\n

  -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -ComputerName $computerName `<\/p>\n

  -Credential $credential<\/p>\n

$wmiObject.GetRelated(“Win32_Account”)\nWhen I run this on my computer, though, the script seems to hang, and it never finishes. There are simply too many relationships in WMI for this call to the GetRelated<\/strong> method to complete in a reasonable amount of time. To get around this issue, I need to specify the parameters to the GetRelated<\/strong> method to tell WMI that I only want the members of this specific group—not every possible relationship:<\/p>\n

$credential = Get-Credential<\/p>\n

$computerName = “remotecomputer”<\/p>\n

$wmiObject = Get-WMIObject `<\/p>\n

  -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -ComputerName $computerName `<\/p>\n

  -Credential $credential<\/p>\n

$wmiObject.GetRelated(“Win32_Account”,”Win32_GroupUser”,””,””,<\/p>\n

  “PartComponent”,”GroupComponent”,$FALSE,$NULL)\nIn this case, I use all eight parameters for the GetRelated<\/strong> method to focus on the exact relationship between the Win32_Group<\/strong> object instance (in the variable $wmiObject<\/strong>) and its related Win32_Account<\/strong> object instances. When I run the previous script, I get the desired output:<\/p>\n

AccountType : 512<\/p>\n

Caption     : REMOTECOMPUTERAdministrator<\/p>\n

Domain      : REMOTECOMPUTER<\/p>\n

SID         : S-1-5-21…<\/p>\n

FullName    :<\/p>\n

Name        : Administrator<\/p>\n

Caption : FABRIKAMDomain Admins<\/p>\n

Domain  : FABRIKAM<\/p>\n

Name    : Domain Admins<\/p>\n

SID     : S-1-5-21…<\/p>\n

Improve WMI performance<\/h2>\n

I’ve run into a final snag, though. When I connect to a remote computer over a slow network connection, I get the group members, but the GetRelated<\/strong> method only outputs one group member at a time. To speed things up, I would prefer to retrieve multiple members at a time; say, in batches of 50 members.\nTo do this, I need to create a System.Management.EnumerationOptions object, set its BlockSize<\/strong> property to 50, and use this object as the final parameter of the GetRelated<\/strong> method:<\/p>\n

$wmiEnumOpts = new-object System.Management.EnumerationOptions<\/p>\n

$wmiEnumOpts.BlockSize = 50<\/p>\n

$credential = Get-Credential<\/p>\n

$computerName = “remotecomputer”<\/p>\n

$wmiObject = Get-WMIObject `<\/p>\n

  -Class Win32_Group `<\/p>\n

  -Filter “LocalAccount=TRUE and SID=’S-1-5-32-544′” `<\/p>\n

  -ComputerName $computerName `<\/p>\n

  -Credential $credential<\/p>\n

$wmiObject.GetRelated(“Win32_Account”,”Win32_GroupUser”,””,””,<\/p>\n

  “PartComponent”,”GroupComponent”,$FALSE,$wmiEnumOpts)\nNow, I get the same output, but it runs faster because the GetRelated<\/strong> method retrieves the local Administrator group’s membership in batches of 50 instead of one at a time.<\/p>\n

User friendly output<\/h2>\n

When I use the GetRelated<\/strong> method, the object instances are output by the default formatter in Windows PowerShell. These output objects provide a lot of detail, but I only want to know three things:<\/p>\n