I'm facing a performance issue with the PowerShell command Get-ADUser, where it takes an unusually long time to return results when using Select-Object. I'm querying around 13,000 users and found that the time it takes can vary dramatically depending on how the commands are structured.
In my first example, I use Get-ADUser and pipe the results to Select-Object after saving to a variable, which completes in under a minute. However, in the second example, I add a server parameter and suddenly it's taking over 30 minutes to run. Meanwhile, in the third example, I piped the command directly to Select-Object, and it finished similarly fast to the first example, despite also including a server parameter.
What's going on here? Why does the variation in code structure have such a drastic impact on processing time, especially when a server parameter is included?
4 Answers
I've hit a similar snag with Get-ADUser. The issue often lies with how the command fetches attributes. When you include Select-Object after piping, PowerShell has to reach out to the domain controller (DC) for the extra attributes. Without the server parameter, it might retrieve more data upfront, making the process quicker. A tip that worked for me was to specify the closest DC with the -Server flag, which speeds things up in my environment. You could also monitor connection via perfmon to see network traffic during these commands.
I think there's definitely something to that. I noticed a massive difference with network traffic when I monitored procmon. The first scenario barely touched the network, while the second triggered a lot more traffic when it hit Select-Object.
From what I've learned, when you run Get-ADUser with specific properties, it tries to fetch these only when accessed, especially in larger sets of data. It’s efficient for one object but not for many. I’ve moved towards using ADSI and ADSISearcher for better performance; you get all attributes in one go rather than piecemeal fetching. This allows for quicker queries since it picks the best DC based on your current location, which helps avoid the slowdowns you're experiencing.
Is that true? The ADSI approach does sound better. I'm just not as familiar with it.
Yeah, it does take some getting used to, but it pays off in speed when dealing with large datasets.
Here's a rule I follow: always try to filter early and only fetch what you need afterward. This can help minimize your processing time significantly. It looks like you could refine your initial command with a filter based on those properties you're interested in. Plus, you might want to double-check if the arrays you're using to specify properties align correctly between methods; that could be skewing results too.
That makes sense! I’ll experiment with filtering right from the start and see how it goes.
Matching those arrays is key here. It’s always easy to overlook those kinds of differences.
It sounds like the ADUser objects are slow to process when using Select-Object. The real bottleneck isn't Select-Object itself, but rather how you're interacting with those ADUser objects. Try creating a mock set of data using a loop to see how quickly Select-Object can handle that. In past tests, I've found that overhead can be caused when fetchings attributes via -Properties, especially if both the alias and the server are in play. Sometimes, stripping down to just what's necessary with Get-ADUser can help.
I agree with your analysis. It’s odd that specifying a server name causes additional delays. I've also found that specifying properties explicitly can sometimes help reduce overhead.
Always great to add mock data for testing; it simplifies the real interaction issues.
But in the first example, you didn’t specify a server and it completed quickly. Why is this different when you include the server in the second case?