Let's break down your questions step by step, starting with clarifying ReferenceObject vs DifferenceObject, then digging into why swapping them fixed your result, and finally giving you a reliable way to achieve your end goal.

1. What's the Difference Between ReferenceObject and DifferenceObject? #

Think of ReferenceObject as your "baseline" or "source of truth" collection—it’s the set you’re using as a benchmark for comparison. DifferenceObject is the secondary collection you’re checking against that baseline.

The SideIndicator property tells you where each item lives:

• <=: Item exists only in the ReferenceObject
• =>: Item exists only in the DifferenceObject
• ==: Item exists in both collections (only visible if you use -IncludeEqual)

In theory, finding intersections (==) shouldn’t depend on order—but as you discovered, custom objects can throw a wrench into this. Let’s explain why.

2. Why Did Swapping the Objects Fix Your Result? #

The core issue is how Compare-Object handles PSCustomObject comparisons by default. When you pass entire objects to the cmdlet, it compares every property of the object—not just the ID property you care about. Even though both your sets have an ID property, the underlying objects might have hidden metadata (like subtle differences in their PSObject structure) that make Compare-Object see them as unequal, even when their ID values match.

Swapping the order might have accidentally aligned the cmdlet’s matching logic with your expected results, but this isn’t a reliable fix. The real problem is you’re comparing entire objects when you only need to compare their ID values.

3. A Reliable Way to Find the Intersection & Remove Users from the AD Group #

Instead of relying on quirky Compare-Object behavior, focus on comparing ID values directly. Here are two solid approaches:

Approach 1: Use a Hash Set for Fast Lookups #

Hash sets enable near-instant lookups, which is efficient even for large user lists:

# Create a hash set of leaver IDs for quick matching
$LeaverIDs = [System.Collections.Generic.HashSet[string]]$Leavers.ID

# Filter pilot users who are also in the leaver list
$UsersToRemove = $PilotUsers | Where-Object { $LeaverIDs.Contains($_.ID) }

Approach 2: Use Compare-Object with Explicit Property Targeting #

If you prefer to stick with Compare-Object, explicitly tell it to only compare the ID property—this eliminates issues with hidden object metadata:

$UsersToRemove = Compare-Object -ReferenceObject $PilotUsers -DifferenceObject $Leavers -Property ID -IncludeEqual | 
                 Where-Object { $_.SideIndicator -eq '==' } |
                 Select-Object -ExpandProperty ID

With -Property ID, the cmdlet ignores all other object properties, so order won’t affect your intersection results.

Finally, Remove Users from the AD Group #

Once you have your target list, use Remove-ADGroupMember to clean up the Licensing_Pilot Users group. Always use -WhatIf first to test without making changes:

# Get the target AD group
$PilotGroup = Get-ADGroup -Filter "Name -eq 'Licensing_Pilot Users'"

# Test the removal first (remove -WhatIf to execute the actual changes)
$UsersToRemove | ForEach-Object {
    Remove-ADGroupMember -Identity $PilotGroup -Members $_.ID -Confirm:$false -WhatIf
}

Key Takeaways #

• When comparing custom objects, always specify the exact property(s) you want to check with -Property in Compare-Object to avoid unexpected behavior.
• Hash sets are far more efficient than looping for large datasets when you need to check membership.
• Always test destructive commands like Remove-ADGroupMember with -WhatIf to prevent accidental data loss.

内容的提问来源于stack exchange，提问作者Tony W