When dealing with Group Policy logon scripts, many administrators face the limitation that scripts execute before the Windows Explorer shell initializes. This becomes problematic when your PowerShell script has dependencies on fully loaded Explorer components.

# Common symptom: Script runs before shell is ready
Start-Process "dependency.exe"  # Fails because Explorer context isn't available

Microsoft's Core Group Policy architecture mandates synchronous processing:

• Computer policies complete before logon UI appears
• User policies complete before shell activation
• No native mechanism for post-shell execution

1. Scheduled Task Trigger Approach

Create a scheduled task that triggers when explorer.exe starts:

# PowerShell to create the scheduled task
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File C:\\scripts\\postlogon.ps1"
$Trigger = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$Settings = New-ScheduledTaskSettingsSet -StartWhenAvailable -DontStopOnIdleEnd
Register-ScheduledTask -TaskName "PostLogonScript" -Action $Action -Trigger $Trigger -Settings $Settings -Force

2. Improved Process Waiting Script

Enhance your wait-for-explorer function with better process detection:

function Wait-ExplorerReady {
    param(
        [int]$Timeout = 120,
        [int]$Interval = 2
    )
    
    $timer = [System.Diagnostics.Stopwatch]::StartNew()
    $explorerReady = $false
    
    while (-not $explorerReady -and $timer.Elapsed.TotalSeconds -lt $Timeout) {
        try {
            $shell = Get-Process explorer -ErrorAction Stop
            $owner = (Get-WmiObject -Class Win32_Process -Filter "ProcessId=$($shell.Id)").GetOwner()
            if ($owner.User -eq $env:USERNAME) {
                $explorerReady = $true
                break
            }
        }
        catch {
            Start-Sleep -Seconds $Interval
        }
    }
    
    if (-not $explorerReady) {
        throw "Explorer didn't start within timeout period"
    }
    
    # Additional stability check
    Start-Sleep -Seconds 5
}

3. Registry Run Key Alternative

Deploy via GPO to place script in HKCU Run key:

# Registry path: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
$RunKey = "Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run"
Set-ItemProperty -Path $RunKey -Name "PostLogonScript" -Value "powershell.exe -WindowStyle Hidden -File "C:\scripts\postlogon.ps1""

When choosing your approach, consider:

• User Context: Scheduled tasks run in different contexts than logon scripts
• Timing Windows: Some methods may still execute slightly before full shell readiness
• Error Handling: Implement robust logging for troubleshooting

# Example logging addition
Start-Transcript -Path "C:\logs\postlogon_$(Get-Date -Format 'yyyyMMdd').log"
try {
    Wait-ExplorerReady
    # Your main script logic here
}
catch {
    $_ | Out-File "C:\logs\postlogon_errors.log" -Append
}
finally {
    Stop-Transcript
}

Windows Group Policy has an inherent design characteristic where logon scripts execute before Explorer.exe initializes. This becomes problematic when you need to run scripts that depend on Explorer or user-shell components being fully loaded. The GPO setting "Run logon scripts synchronously" actually enforces this pre-shell execution behavior rather than solving our requirement.

The default asynchronous script execution (when disabling the synchronous setting) doesn't guarantee Explorer readiness because:

• GP client-side extension (CSE) processing completes before shell activation
• There's no native GPO mechanism for post-shell script execution

Here's an improved PowerShell detection approach that handles multiple edge cases:

function Wait-For-InteractiveShell {
    param(
        [int]$Timeout = 120,
        [int]$Interval = 2
    )
    
    $stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
    $shellReady = $false
    
    while (-not $shellReady -and $stopwatch.Elapsed.TotalSeconds -lt $Timeout) {
        try {
            # Check for Explorer process with correct session and owner
            $explorerProcess = Get-CimInstance -ClassName Win32_Process -Filter "Name='explorer.exe'" |
                Where-Object { 
                    ($_.SessionId -eq (Get-Process -Id $PID).SessionId) -and
                    (($_.GetOwner().User -eq $env:USERNAME) -or 
                     (Test-Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"))
                }
                
            if ($explorerProcess) {
                # Additional check for stable shell state
                $shellFolders = Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" -ErrorAction SilentlyContinue
                if ($shellFolders -and (Test-Path $shellFolders.Desktop)) {
                    $shellReady = $true
                    Write-Verbose "Interactive shell detected after $($stopwatch.Elapsed.TotalSeconds) seconds"
                }
            }
        }
        catch {
            Write-Debug "Detection attempt failed: $_"
        }
        
        if (-not $shellReady) {
            Start-Sleep -Seconds $Interval
        }
    }
    
    if (-not $shellReady) {
        throw "Shell detection timeout reached"
    }
    
    return $shellReady
}

Task Scheduler Approach

Create a scheduled task triggered by user logon with a delay:

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File "C:\scripts\postlogon.ps1""
$trigger = New-ScheduledTaskTrigger -AtLogOn -RandomDelay 00:01:00
Register-ScheduledTask -TaskName "PostLogonScript" -Action $action -Trigger $trigger -RunLevel Highest -Force

Registry Run Key with Delay

Combine with a starter script that handles the delay:

# Starter script (add to HKCU\...\Run registry key)
Start-Process powershell.exe -ArgumentList @"
    -NoProfile -ExecutionPolicy Bypass -Command 
    "Start-Sleep -Seconds 30; & 'C:\scripts\mainlogon.ps1'"
"@

For domain environments, consider these deployment options:

• Create a GPO that deploys the scheduled task via Group Policy Preferences
• Use a logon script that copies and registers the delayed execution script
• Implement a wrapper EXE that handles the shell-ready detection more reliably

Common pitfalls and solutions:

# 1. Verify script execution context
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

# 2. Check for multiple Explorer instances
Get-Process explorer | Where-Object { $_.SessionId -eq (Get-Process -Id $PID).SessionId }

# 3. Test shell readiness markers
Test-Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"