Archive for September, 2011

Using Autoruns to disable GPO application upon login

September 25, 2011 Leave a comment

The Autoruns tool from Microsoft Windows Sysinternals is able to identify the scripts that run upon machine start up and user login. I discovered this as I was trying to understand the long login times I was experiencing in our domain.

From the scan of the Autorun tool, it was reported that GPOs that triggered the run of scripts were set in two keys in the Registry. The HKLM\Software\Policies\Microsoft\Windows\System\Scripts\Startup key runs the GPOs upon machine start up while the HKCU\Software\Policies\Microsoft\Windows\System\Scripts\Logon key runs the GPOs upon user login.

We have DCs distributed globally, and the way our AD Sites and Directories was setup, or not setup as the case may be, is such that we were getting logged-in to DCs outside of our region, and the connectivity and latency of such plays a role in the long login times. The additional insight obtained from Autoruns was that the script files referenced could not be found, possibly either because they no longer existed or there were issues with the connectivity to the DC hosting them.

Autoruns showing GPOs applied (redacted)

To solve the problem of slow login times to the domain, we need to have some control over where our machines pull our scripts both for machine start up and user login. Essentially when users login to the domain, they should be logging in to a DC close to their respective country. There are two possible ways to do this: (1) Change the DC weight and priority of our DCs, and (2) Tweak AD Sites and Directories to point to a closer DC. The first option will affect all users who login to the domain; it might solve the slow login times for users in our region but will cause problems for others, so this may not be the best option in this case. (Besides, our local network team does not have the rights to make such a configuration.) For our particular case, it looks like the latter option is the best approach.

As our local network team looks into this some more, for now the workaround is to disable the application of such GPOs, which unfortunately will have to be done on a per-user basis. This can be done by using Autoruns, by simply un-checking the GPO listed in its scans. Inspection of the Registry will show that these GPOs have been moved to a new subkey where its application is disabled.

Registry subkey for disabled autorun items


NOTE: This workaround will only work if there are connectivity issues.  Once connectivity issues have been resolved, the domain will be able to override Autoruns and re-enable the disabled GPOs. This is behaviour I have observed once I was able to successfully connect and login to a DC.


Key lessons learned from this investigation:

  1. Upon logging in to the domain, entries are created in the HKLM\Software\Policies\Microsoft\Windows\System\Scripts\Startup and HKCU\Software\Policies\Microsoft\Windows\System\Scripts\Logon keys for machine and user login, respectively.
  2. Using Autoruns, one is able to disable such scripts from running such that upon next login, such were skipped. The relevant subkeys created under each key were moved into a new subkey called AutorunsDisabled. (Again, note that this workaround is only effective if you have connectivity issues to a DC.)
  3. AD Sites and Directories need to be configured correctly to account for the geographic placement of the subnets assigned to country such that users from said country will login to a DC close to them, thereby mitigating any slowness in the login process because of latency and connectivity issues in applying GPOs.