Get-GPO is taking forever to return results

[dalebert]

I have this script that is getting a list of policies in the domain. This isn’t complex in any way. I’m running this within VS Code using PS 7.3.9, PS terminal 5.1, and PS Terminal 7.3.9. Here’s the line I’m running (with all the variations I’ve tried):

Get-GPO -All
Get-GPO -All -Domain “DOMAIN”
Get-GPO -All -Domain “DOMAIN” | Where-Object{$.DisplayName -NotLike “-lx-” -AND $.DisplayName -NotLike “*-lx”} | Select DisplayName, @{Name=“GUID”;Expression={$_.ID}} | sort DisplayName

Also, it doesn’t matter if I run it with the -domain flag or not, it takes 6 minutes to return the results if I run the script from within VS Code. If I run that same command, from the same system using either PS terminal, the results are returned in about 2 seconds.

I originally though maybe this was not really taking a long time to return the results and it was getting stuck somewhere else in the script. However, when I step through the code it hits the line to get the policies, it stops and sits for 6 minutes then moves on to return the results.

Anyone have any ideas on how to speed this up?

[dotnVo]

To confirm - It sounds like

Get-GPO -All

is fast in PS 5 but not PS7 correct? If so, I’ve replicated your experience, but to a lesser degree, (1 second, vs 2 minutes, 6 seconds). I’m using Measure-Command as a ‘quick’ way to do that, and without output it might speed things up a bit.

I wonder if this might be due to PS 7’s compatibility layer, where modules not compatible with PowerShell core are loaded in a 5.1 background session: about Windows PowerShell Compatibility - PowerShell | Microsoft Learn. I’d love for others in the community to comment/confirm though, as that is mostly a guess.

I was able to confirm that the GroupPolicy module, which Get-GPO is part of, does appear to use that compatibility session. I tried to manually use the compatibility session as well using Invoke-Command but it was still slow, though testing I did occasionally get it to complete a bit faster (about 1 minute, 34 seconds), but no rhyme/reason why. I’ve had pretty huge variants doing a few tests.

One way you can speed it up - just use 5.1 directly, but you already know that I think. Hopefully someone else has some ideas

[dotnVo]

I just confirmed it is due to the compatibility layer. I did find one way of working around it, but…it’s a use at your own risk situation. Explicitly import the module and use the SkipEditionCheck switch:

Import-Module GroupPolicy -SkipEditionCheck

Then run your command, and it should be fast in PS7 as this won’t use the compatability session. Some commands may not work properly in the GroupPolicy module, I don’t know, but based on a couple of the data outputs, it seems Get-GPO is ok.

[dalebert]

So, it didn’t matter which version of PS I used – when using a terminal. The results came back super-fast (1-2 seconds). It was when I ran it in VS Code that it was taking 6 minutes. Super weird, I thought. It turns out (and I’d like some input from others here as well to verify this thought) that VS Code is NOT importing the GroupPolicy module to do the task automatically. I guess I’m thinking that was the problem the whole time. I had the “#Requires -Modules GroupPolicy” at the top of the script, but that doesn’t import the module. Which was my misunderstanding because I have the #Requires tag for VMWare.VimAutomation.Core as well and I can watch that module load in VS Code when I run the script. I am still a little unclear on that aspect.

Now, I’ve added the -SkipEditionCheck to the module import at the top of the script and there was about a 26 second lag this time returning the results. Huge improvement! So, this is a really nice turn of events. Especially after trying to figure this out for about a week.

[dotnVo]

@dalebert

So, it didn’t matter which version of PS I used – when using a terminal.

So first, #requires just means that the module is needed for the script to run. about Requires - PowerShell | Microsoft Learn

The #Requires statement prevents a script from running unless the PowerShell version, modules (and version), and edition prerequisites are met. If the prerequisites aren’t met, PowerShell doesn’t run the script or provide other runtime features, such as tab completion.

I’m glad my suggestion helped, but again, I think it’s because of what I stated, not really the software being used. Terminal is just that, a terminal (really a terminal emulator) . VSCode obviously is a full suite of software, but it has its own ‘terminal’.

PowerShell is, well, a shell, and is simply being called from these terminals.

FWIW I did try via terminal and it was slow there too when using PS7. PS5 it was fast. I did it in VSCode… same thing, fast in pS5, slower in PS7. That’s not to say there might be some additional slowness in some instances but it’s more about the shell being used. My guess is, when you did it via terminal, it’s defaulting to PowerShell 5 nad you didn’t realize, and in VSCode, it’s defaulting to PS7 and you weren’t aware. Some proof, here’s VSCode using version 5.1:

The same command in PS7 in vscode took much, much longer.

An easy way to check version:

$psversiontable.PSVersion

I’d suggest reading up on module importing, and PS module path, and also look into profiles for different terminals. Calling any cmdlet that in a module that is in the psmodule path will implicitly load that module: Importing a PowerShell Module - PowerShell | Microsoft Learn

Explicity loading the module by adding the Import-Module -SkipEditionCheck , it doesn’t do the lookup to determine if it should use a compatibility layer, so for better (or worse) it just does it without that session.