如何优化PowerShell查询AD中重复EmployeeID用户的效率？

Great question—dealing with large AD datasets can be frustrating when the initial query drags on, especially when you already know the attribute is indexed in the GC. Let’s break down some actionable optimizations to speed up your process:

1. Use the Underlying DirectorySearcher API (Fastest Option) #

The Get-ADUser cmdlet is a convenient wrapper around .NET's DirectorySearcher, but it adds overhead for processing user-specific properties and PowerShell pipeline semantics. For large datasets, directly using DirectorySearcher cuts out this middle layer and is significantly faster. It also lets you process results incrementally, reducing memory usage compared to loading all 200K+ records into memory first.

Here’s a refactored version of your logic using DirectorySearcher:

$gcServer = $server_AD_GC
$outputPath = "C:\Users\me\op_GetADUser_w_EmpID_Dupes_EntireForest - $([datetime]::Now.ToString("MM-dd-yyyy_hhmmss")).csv"

# Initialize DirectorySearcher for Global Catalog
$searchRoot = New-Object System.DirectoryServices.DirectoryEntry("GC://$gcServer")
$searcher = New-Object System.DirectoryServices.DirectorySearcher($searchRoot)
$searcher.Filter = "(&(ObjectCategory=Person)(objectclass=user)(employeeid=*))"
# Load ONLY the properties you need (minimize data transfer)
$searcher.PropertiesToLoad.AddRange(@("employeeid", "samaccountname", "name", "distinguishedname"))
$searcher.PageSize = 1000 # Match your original page size
$searcher.SizeLimit = 0 # Return all matching results

# Track EmployeeIDs and their associated users incrementally
$empIdGroups = @{}
$processedCount = 0

foreach ($result in $searcher.FindAll()) {
    $processedCount++
    # Update progress in batches to avoid overhead per-object
    if ($processedCount % 1000 -eq 0) {
        Write-Progress -Activity "(1/3) Retrieving AD Users" -Status "Processed $processedCount records"
    }

    $empId = $result.Properties["employeeid"][0]
    # Map result to a custom object with your required fields
    $userObj = [PSCustomObject]@{
        EmployeeID = $empId
        SamAccountName = $result.Properties["samaccountname"][0]
        Name = $result.Properties["name"][0]
        DistinguishedName = $result.Properties["distinguishedname"][0]
        # Add any other properties you need here
    }

    # Build groups of users by EmployeeID
    if ($empIdGroups.ContainsKey($empId)) {
        $empIdGroups[$empId] += $userObj
    } else {
        $empIdGroups[$empId] = @($userObj)
    }
}

# Filter and export duplicates
Write-Progress -Activity "(2/3) Filtering Duplicates" -Status "Scanning $($empIdGroups.Count) unique EmployeeIDs"
$duplicateUsers = $empIdGroups.Values | Where-Object { $_.Count -gt 1 } | Select-Object -ExpandProperty Value

Write-Progress -Activity "(3/3) Exporting Results" -Status "Writing $($duplicateUsers.Count) duplicate records"
$duplicateUsers | Export-Csv $outputPath -NoTypeInformation

Write-Progress -Completed -Activity "Process Finished"

2. Minimize Returned Properties #

Your original Get-ADUser call uses $properties—double-check that this variable only includes the exact properties you need for the final CSV. Loading unnecessary properties (like computed attributes such as LastLogonDate) adds significant overhead, as AD has to compute or fetch extra data for every record.

If you only need a handful of fields, explicitly list them instead of using a broad $properties variable:

# Example: Only load critical properties
Get-ADUser -LDAPFilter "(&(ObjectCategory=Person)(objectclass=user)(employeeid=*))" -Properties EmployeeID, SamAccountName, Name -Server $server_AD_GC -ResultPageSize 1000

3. Skip Pipeline Progress for the Initial Query #

Your Show-Progress function runs once per user object in the pipeline, which adds overhead when processing 200K+ records. Instead, update progress in batches (like the DirectorySearcher example above) or disable progress for the initial query entirely to save time.

4. Verify GC Server Performance & Network #

Even with indexed attributes, an overloaded GC server or slow network connection can bottleneck your query. Try:

• Running the script directly on a domain controller (eliminates network latency for data transfer)
• Testing a different GC server in your forest to see if performance improves
• Checking the GC server’s event logs for replication or performance issues

Why This Works #

• DirectorySearcher avoids the PowerShell cmdlet overhead and lets you process records as they’re returned, reducing memory pressure
• Limiting properties cuts down on the amount of data transferred from AD to your script
• Batch progress updates reduce the number of UI/console operations, which are surprisingly slow at scale

内容的提问来源于stack exchange，提问作者Karthick Ganesan