Hold your horses, Explorer!

By Jacques Bensimon –

We’re all familiar in our Remote Desktop Services and XenApp builds with the necessity of using the “Run logon scripts synchronously” policy to ensure that the user environment is properly set up (drive mappings, per-user application tweaks, etc.) before the Explorer desktop or first published application is launched.

This has traditionally worked just fine on all the server platforms used for RDS and XA.  Note that, in those environments, this policy has the desirable effect of waiting not only for traditional logon scripts (legacy and GPO) to finish executing but also for the RDS-specific UsrLogon.cmd (the root “application compatibility script” triggered by the AppInit Registry entry at key “HKLM\Software\Microsoft\Windows\ NTCurrentVersionWinlogonAppSetup”) to terminate.

 

I noticed years ago, without at first paying it too much attention, that Windows XP did not seem to obey this policy, at least during the first user logon after startup, despite the fact that the policy description claimed that it applied to all Windows platforms.  On a private single-user workstation, this did not seem to matter much since drive mappings would become available soon enough, generally before the user had a chance to launch an app (no published applications to worry about here) and most per-user application tweaks had likely already been applied during previous logons and were still present in the user’s local or roaming profile.  However, with the advent of VDI and XenDesktop, along with their various enabling technologies like Citrix Provisioning Services, virtual machine pools (often configured to restart the VM at logoff), all manner of fancy profile strategies (like mandatory profiles supplemented by AppSense Environment Manager or other third-party product), the new XenApp capability of publishing applications that execute on XenDesktop pools, etc., the need to coordinate logon time script activities on workstation platforms during all logons has become much more critical, and the apparent failure of the “Run logon scripts synchronously” policy to have the promised effect much more annoying.

 

For Windows XP (and in theory subsequent workstation platforms), the explanation and solution were provided by KB304970 — Scripts May Not Run Before Windows Explorer Starts Even Though the "Run Logon Scripts Synchronously" Setting is Enabled.  In short, the additional “Always wait for the network at computer startup and logon” policy must also be enabled in order for the original policy to apply during the first logon after startup.

So, this also works in Windows 7, right?  Not quite.  Whether by omission or by design, this stopped working in Windows 7 until a hotfix was made available via KB2550944 — Group Policy logon scripts do not run in Windows 7 or in Windows Server 2008 R2.  Note that the hotfix applies whether or not Service Pack 1 is installed and that it is *not* provided via Windows Update.  Surprisingly, as the KB article’s title indicates, it appears to also be required on Windows Server 2008 R2 – frankly, I hadn’t noticed the issue there (the first user of the day never mentioned anything! J), but I’ll be applying it religiously from now on.

 

Windows 8?  Windows Server 2012?  I don’t yet know, but I’m keeping my fingers crossed that the above hotfix found its way into the code.

Later,

J3

Follow Jacques @JacqBens