I know there is the GPO setting "Computer Configuration => Admin. Templates => System => Scripts => Run logon scripts synchronously". This, however, ensures that logon scripts run before Windows Explorer starts loading (when enabled).

I need the opposite thing. I want to ensure that the explorer.exe has loaded successfully and execute the PowerShell logon script afterwards. This is due to some weired dependencies of an application I need to trigger.

I tried disabling the setting which according to the description should allow running file explorer and the script simultaneously. Unfortunately, it does not (yes, I did reboots and gpupdates...)

So I tried to add a function called wait-for-explorer() to my PowerShell logon script. It sleeps in a while loop until explorer.exe is running. However, this seems not to work right.

What is the best and cleanest way to solve this? Is there a GPO setting I am overlooking?

This is what the code looks like:

Function Wait-For-Explorer
    $process = 'explorer.exe'
    $waitTime = 1

    While ($owner.User -ne $env:USERNAME) 
            $owner = (Get-WmiObject -class win32_process | where { $_.ProcessName -eq $process }).GetOwner() | Select -Property User
            Write-Host "Zzzzz...."
            Start-Sleep -Seconds $waitTime

    Write-Host "Process ${process} is running..."


I found the answer to my question and why there is no such option provided by Microsoft. The reason is that according to the Technet article How Core Group Policy Works, the processing of Group Policy is synchronous, which means that computer Group Policy is completed before the logon dialog box is presented, and user Group Policy is completed before the shell is active and available for the user to interact with it. This in turn means there is no (direct) possibility for the group policy engine to start a process after the user shell has been loaded...

  • 1
    what does your wait-for-explorer function look like? your approach is correct, i don't think there is an out of the box solution for what you need – Raf Apr 4 '14 at 13:39
  • It would be better if you moved the last part to the answer. – Peter Mortensen Feb 22 '15 at 13:41

Have you tried running it as a scheduled task with a trigger of "user logon"? This might eliminate the need for a function like that.

SCHTASKS /Create [/S system [/U username [/P [password]]]]
    [/RU username [/RP password]] /SC schedule [/MO modifier] [/D day]
    [/M months] [/I idletime] /TN taskname /TR taskrun [/ST starttime]
    [/RI interval] [ {/ET endtime | /DU duration} [/K] [/XML xmlfile] [/V1]]
    [/SD startdate] [/ED enddate] [/IT | /NP] [/Z] [/F]

    Enables an administrator to create scheduled tasks on a local or
    remote system.

Parameter List:
<...many switches delted...>
/SC   schedule     Specifies the schedule frequency.
                   Valid schedule types: MINUTE, HOURLY, DAILY, WEEKLY,

enter image description here

  • Awesome idea! However this becomes very messy, as i need to create a startup script which then adds a schedulded task which then calls my logon script... holy moly... i am wondering why there is no such option... is it because microsoft wants me to set this on the user object? – Matze Apr 4 '14 at 14:31
  • logon scripts, that are configured within the ad user object always run after windows explorer has loaded... so i am going this path even though it generats more work for me... – Matze Apr 4 '14 at 14:54
  • You can create and manage scheduled tasks from group policy. No need for hacky startup scripts. – MDMarra Apr 5 '14 at 11:36

I just stumbled above the following setting:

User Configuration => Policies => Administrative Templates => System => Logon => Run these programs at user logon

When calling my scripts from here everything works. This (seems to) act in the same way as the "Logon Script" within the AD user object does. It waits for the File Explorer to finish loading and afterwards executes the scripts... so mission accomplished! Thanks to all!


If you look at how MDT (http://technet.microsoft.com/en-us/windows/dn475741.aspx) does this, it places as shortcut in the user's "startup" folder. That way you're pretty much guaranteed that the script won't run until the user has logged on and the desktop is presented. If you dig a bit in the MDT scripts folder you'll find ready-made scripts for creating these shortcuts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.