How are logon scripts affected? Logon scripts defined in Group Policy by default run asynchronous and invisible to the end user. Asynchronous logon scripts run in parallel with the user logging on. In this way other processes do not have to wait until the script(s) finishes. The default behavior of logon scripts imply that the scripts are actually background processes and will be handled as such in terms of thread and I/O priority. This means that logon script by default will be started at the "Low" priority thread level and the " Very low I/O priority" level. This is also true when you decide to run the script visible.

In the case of our logon script, not being able to use the file cache severely harms the performance of the script when it writes data to the local disk.

Where the thread priority of the first category of startup programs changes to normal after 60 seconds, the thread priority of logon scripts defined Group Policy stays "Low" forever just as the I/O priority level that stays "very low".

Scripts running at "very low i/o priority" has serious impact on disk write operations initiated from the script. Writing data does not perform as fast as the process expects. This causes the script to try a write operation and then see that it does not complete within the expected time, then wait for a certain time (50ms) and try again. This is very clear when you monitor the behavior of such a script with Process Monitor (from Sysinternals on the MS website). Process Monitor reports the script is running with very low IO priority and is not allowed to use fast file IO (using the file cache). Because of the very slow file IO you also see a lot of File Lock Conflict messages caused by subsequent write operations that fail because the earlier write operation did not end within the expected time frame.

Full Article

Microsoft, Windows Vista, Logon, Scripts, Troubleshooting, Knowledgebase

Pages: 1 2