Using PowerShell Grid View for User Info

Doctor Scripto

Summary: Learn how to use the Windows PowerShell grid view to display user information in this guest post by Tim Bolton and Don Walker.

Microsoft Scripting Guy, Ed Wilson, is here. Welcome back guest blogger, Tim Bolton

Hi all,

This project was a joint effort with my coworker, Don Walker (@EngineeringDon). In my current work environment, the character set used for user IDs that are stored in Active Directory can be a mixed bag of uppercase letters, lowercase letters, or a mix of both. This is due in part to a large Active Directory merger project that is currently underway.

Due to that condition and the numerous applications that we use (which are case sensitive), one of the most asked daily questions we get is, “Can you tell me if this user ID is uppercase or lowercase?”

Normally, this will be followed by being asked to check the user principal name (UPN), lockout status, email address, and so on.  Initially, I would output this information to a text file and send it to the requester by Instant Messenger or email.

However, this would open the door to check for the groups that the user is a member of and inevitably, “Can you get a list of all of the members of <Group>?”

You may be asking, "Why not tell them to use Windows PowerShell?"

Well, yes, we have instructed the requesters on how to load Windows PowerShell and how they could get this information themselves, but the lack of a GUI is almost an impossible sell point for some people. So we used this as an opportunity to teach and assist them at the same time.

I recently came across a couple of articles by Ed Wilson (Microsoft Scripting Guy), Jeff Hicks (The Lonely Administrator), and Mike F Robbins (Computing Solutions) where they demonstrated using Out-GridView with –Passthru so that you can select properties within GridView and pass them to the pipeline. Those articles inspired this little project we called “Get-UserInfo”—or as Adam Bertram ‏(@adbertram) referred to it, “The poor man’s forms.” Thanks for the advice on this, Adam!

How it works…

The function is stored in the requester’s Windows PowerShell profile, so they simply need to open a Windows PowerShell session and type Get-UserInfo and then enter the user ID.

Note  RSAT and Window PowerShell 4.0 are needed on the computer.

Image of command output

The user ID is passed as $Identity where Get-ADUser is used to gather the user’s information. Note the -OutPutMode Single parameter. This is used to allow the requester to select a user in GridView, and it passes that information to the next piece of the script.

Image of command output

As shown here, you now can see the basic (most requested) information of the user:

Image of command output

When you select a user and select OK, you can use the Get-ADPrincipalGroupMembership cmdlet to display the groups that the user is a member of:

Image of command output

Notice that the title will display the user ID with a message for the requester to select an Active Directory group and select OK if they want to see all of the group’s members.

Image of command output

When you select a group and select, the members of the group you selected using (Get-ADGroup <name> -Properties Members).Members is displayed.

Image of command output

Why did we use Get-ADGroup Members instead of Get-ADGroupMember? Remember I mentioned a large Active Directory merger project that is currently underway? Unfortunately, not all of the group members are in the main domain where the group resides, and Get-ADGroupMember will fail if it runs into any foreign security principals.

This took a while to figure out because Dsmod worked as did (Get-ADGroup <name> -Properties Members). I could also see the members in Active Directory Users and Computers.

Image of command

Here is the end result. Notice that the title will have the name of the group you looked up:

Image of command output

For now, this is what the requesters are using. So far, they really appreciate the GUI look and feel. We are making updates daily including:

  • Error handling for empty input
  • Error handling for empty Active Directory objects
  • Functions for formatting string output
  • Custom objects with custom names (because I like them that way)
  • Orphaned security identifiers excluded from results
  • More verbose commenting

Future enhancement ideas include (if desired):

  • Switch to form user interface (UI) if more complexity is required
  • Move actions into their own function for flexibility and expanded UI
  • Create additional output functions such as exporting to CSV and gather additional information about the selected user

~Tim and Don

Thanks Tim and Don. Looking forward to seeing your future ideas at work.

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

Ed Wilson, Microsoft Scripting Guy


Discussion is closed.

Feedback usabilla icon