Tag Archives: Get-ADPrincipalGroupMembership

Give a Parameter a Default Value (Part III)

Part II: http://tommymaynard.com/quick-learn-give-a-parameter-a-default-value-part-ii-2015

Didn’t know I’d be back for a third installment of this topic, but the $PSDefaultParameterValues variable is still such a huge convenience. While punching out commands today, I had a thought: Can $PSDefaultParameterValues be a bit more dynamic?

I’m not going to fully introduce the $PSDefaultParameterValues again, but I’ll leave a quick explanation. This hash table allows us to instruct cmdlets and functions to use a default value for one of their parameters. Here’s a couple examples borrowed from the first two $PSDefaultParameterValues posts. To read the first two posts, follow the links at the bottom of this post. Both of these examples do the same thing, outside of the fact they’re written for different cmdlets.

$PSDefaultParameterValues.Add('Test-Connection:Count','1')
$PSDefaultParameterValues = @{'Get-Help:ShowWindow' = $true}

After our variable is set, anytime I use the Test-Connection cmdlet, it will include the -Count parameter with the parameter value of 1. Additionally, when I use Get-Help, it will always include the -ShowWindow parameter, without the need to enter it myself. The examples show how to set the variable both by using the Add method, and as a hash table — which is really all the variable is anyway.

I had a recent need to ensure the -Server parameter value on the Get-ADPrincipalGroupMembership cmdlet used the PDC Emulator. If you see the error: “The operation being requested was not performed because the user has not been authenticated, then you may need to ensure you’re using the PDCE when using this cmdlet, too. Anyway, I didn’t want to hard code the PDCE value in $PSDefaultParameterValues, so I tried something new, and you’re reading this today, because it worked. Here’s how I updated the $PSDefaultParameterValues variable to dynamically obtain the value it should use.

$PSDefaultParameterValues.Add('Get-ADPrincipalGroupMembership:Server',"$((Get-ADDomain).PDCEmulator)")
$PSDefaultParameterValues | Format-Table -AutoSize

Name                                  Value
----                                  -----
Get-ADPrincipalGroupMembership:Server DC01.mydomain.com

Now, whenever I run the Get-ADPrincipalGroupMembership cmdlet (inside the PowerShell session where the $PSDefaultParameterValues has been set), it’ll include the -Server parameter and the value of the PDCE — which ever server that is, and without the need to hard code its name. So yeah, we can use dynamic content in $PSDefaultParameterValues.

Part I: http://tommymaynard.com/quick-learn-give-a-parameter-a-default-value-2015
Part II: http://tommymaynard.com/quick-learn-give-a-parameter-a-default-value-part-ii-2015

An Enhanced Active Directory Group Membership Compare

Like everyday, there was a Windows PowerShell question on the Internet today. While I may not have provided everything the original poster was asking for, I rather like what I had accomplished. Being that I have a website that resolves around PowerShell 100% of the time, it seemed like a good little chunk of code to share. I’m going to want it one day, I just know it, and I’m not going to want to rewrite it.

What we’ve done is compared the Active Directory (AD) group memberships of two different users using Get-ADPrincipalGroupMembership and the Compare-Object cmdlet. Stay tuned, this isn’t the standard Compare-Object output you might be used to seeing. I’m doing this much like the original forum question, so l stored the SamAccountName of two AD users, in two different variables.

PS> $FirstUser = 'tommymaynard'
PS> $SecondUser = 'lanceandrews'

With the variables set, we’ve used them as part of our Get-ADPrincipalGroupMembership commands below. In this example, you can see two ways of accomplishing the same thing — useful stuff, really.

PS> $FirstUserGroups = Get-ADPrincipalGroupMembership $FirstUser | Select-Object -ExpandProperty Name
PS> $SecondUserGroups = (Get-ADPrincipalGroupMembership $SecondUser).Name

With this second set of variables assigned, we’ve set up the command below to obtain the differences and store those in a variable we’ve called $Difference. Including the -IncludeEqual parameter has allowed us to be able to see the group memberships that both users share.

PS> $Difference = Compare-Object -ReferenceObject $FirstUserGroups -DifferenceObject $SecondUserGroups -IncludeEqual

Next, we put together some calculated properties from our $Difference variable. If calculated properties are new to you, be sure to do some additional research. They can be used to simply rename properties, but also, like I’ve demonstrated below, they can include conditional logic. You might consider copying and pasting the example somewhere else, so you can better digest what’s happening. We’ve created three calculated properties: the first is renaming the InputObject property to Group. The next two properties write one of two things: either that the user is a member, or that they’re not, by entering two, side-by-side dashes. See the image further below.

PS> $Difference | Select-Object @{N='Group';E={$_.InputObject}},@{N='First User';E={If ($_.SideIndicator -eq '<=' -or $_.SideIndicator -eq '==') {'Member'} Else {'--'}}},@{N='Second User';E={If ($_.SideIndicator -eq '=>' -or $_.SideIndicator -eq '==') {'Member'} Else {'--'}}}

This modification of the standard Compare-Object output reminds us which user is which. The standard output uses arrows. A left arrow indicates the first user is a member and a right arrow indicates the second user is a member. Because we’re using the -IncludeEqual parameter, we can distinguish when both users are a member of the same AD group, and that, without the double equal sign, as the indicator.

compare-active-directory-membership-between-two-users01

Neat. I’ll be back to visit you later, modified Compare-Object command. Thanks for reading, everyone.