Run logon scripts synchronously policy does not work when logging on for the first time
When a new user logs on for the first time, the desktop is loaded at the same time as our vbs logonscript is run. So the desktop does not wait for the loginscript to finish processing. When the user then logs of and logs on again, windows does wait for the loginscript to finish before loading the desktop (explorer). This is strange since the "Run logon scripts synchronously" policy is enabled. Is this a bug or something that can be solved?
December 3rd, 2010 4:32pm

Hi, Thanks for posting in Microsoft TechNet Forum. First of all, we can try to configure the Fast Logon setting by GPO to check the result: Computer configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon. Enable this policy, check what the result is. For more information about Fast Logon, you could refer to the following link: Troubleshooting the intermittent slow logon or slow startup - AD Troubleshooting - Site Home - TechNet Blogs Description of the Windows XP Professional Fast Logon Optimization feature Alex Zhao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 6th, 2010 12:48pm

We had already enabled that GPO, it makes no difference.
December 6th, 2010 12:55pm

Is this a bug then? Can anyone reproduce this problem?
Free Windows Admin Tool Kit Click here and download it now
December 9th, 2010 1:19am

Hi, First, a little background about login scripts in general: There are two ways to set up login scripts on a Windows system: You can use the user account properties in AD, which causes the script location to be read by Winlogon when the user is authenticated and in turn causes the script to process after the profile has been loaded. Or you can add the login scripts to a group policy object. When you do this, the group policy scripts client-side extension processes the login script as part of group policy processing. In very rough terms, when you log in to a computer, here's what happens: Authentication -> Winlogon pre-processing -> Profile Load -> Group Policy -> Winlogon post-processing (scripts/startup applications) -> Shell load -> User logged in The difficulty with either method described above is that while we can control when a script is launched, we can't control how long it takes to complete, and we have no way to know when it is finished executing. So if you have a script called login.vbs, winlogon/group policy will begin execution of the script, but since we can't track if it's complete, we will then move on to the next item that needs to be executed. The "Run logon scripts synchronously" option works as follows: When you don't have the option defined, any logon scripts will be executed asynchronously, meaning that we won't pay attention to the order we launch them in, and will just kick them off all at once, and then go ahead and load the desktop The design assumption here is that your login scripts all do different things, and don't rely on each other, so it shouldn't matter what order they execute in. When you have the option selected, we will attempt to execute the scripts in order, and make sure that they have all begun execution prior to loading the desktop - under the assumption that you might need a script to complete before another one launches or before an application can be used. However we still have the limitation noted above - we aren't able to track whether a script is actually finished or not. And worse, if that script calls another script or executable, we have no knowlege of that process's execution at all. The end result is that the timing of login scripts in Windows operating systems is never guaranteed. Regardless of whether the synchronous option is selected or not, there is always the possibility that a script execution may overlap the desktop load. Your case is a little unusual since on most systems, a load of a new profile for a new user will take longer than a load of an existing profile (due to the translation that has to occur in order to generate a new profile). Anyway, with all that said, you have a few options here: The first thing to look at is what your script is doing, and what might slow it down. For example if your .vbs script has some logic in it that kicks off other scripts, this may cause it to take longer when the profile doesn't already exist (because we are waiting on returns from the underlying OS that would normally already be cached in memory). The best thing to do if you find this is the case is to try and break anything out that needs to be done before the desktop loads into its own script, or use GP Preferences as described below. The other option you have is to try to move the things within your script to Group Policy Preferences instead. If you're not familiar with GP Preferences, start here: http://technet.microsoft.com/en-us/library/cc731892(WS.10).aspx GP Preferences is a free technology that can be used in Windows XP, Windows Vista, or Windows 7 clients (as well as server operating systems) to do things that were previously only really possible with login scripts via group policy objects instead. This is helpful for two reasons: First, because we use a set of client-side extensions to manage GP Preferences, we have much more control over how they get executed during login. We can set up dependencies so that items execute in the correct order, or don't execute if a previous item fails. We can also set up filtering so that items only apply to the correct users/computers, based on any criteria we select, such as group membership, network address, even down to the type of hardware. Second, group policy processing is generally more efficient and faster than login script processing, because it's more tightly integrated with the OS. We normally see that when login scripts are moved to GP Preference items, users see a gain in login performance. From our perspective here at Microsoft, troubleshooting issues with GP Preferences is also far easier than troubleshooting problems with a script, again because we have that granular control.David Beach - Microsoft Online Community Support
December 11th, 2010 12:06am

Hi David, Thank you for your elaborate response, i really appreciate it. Even though i am surprised that windows has such difficulty with keeping track of the execution duration of loginscripts, it has been functioning quite satisfactory on windows xp and in windows 7 from the second time you login also. Very interesting that the "Run logon scripts synchronously" will only help out if you have more then one loginscript. We have only one loginscript, so the "Run logon scripts synchronously" is apparently of no use to us. F.Y.I our loginscript is configured by GPO and not in ADUC. There are a number of reasons why we prefer not to use gp preferences: 1. From testing it appeared that GP preferences is slower when mapping drives then the vbs loginscript is. 2. We use the loginscript to show a message with the TOS the user has to agree with by clicking on OK. 3. Special conditions exist in the loginscript of which i have found no way to integrate them in gp preferences. Regarding your remark that the problem could be related to the loginscript itself i've done a test. I replaced the loginscript with a vbs script with this simple contents: wscript.echo "hello world" Even with that simple loginscript the desktop starts loading in de background right away at first logon (i can see the "Setting up personalized settings.. first time message), even though the "hello world" message of the login script is clearly visible. So i guess i can safely conclude that it is not the contents of the loginscript that causes this behaviour. Now, i am wondering, are we the only enterprise with this problem, or is this by design or a bug maybe?
Free Windows Admin Tool Kit Click here and download it now
December 13th, 2010 1:03pm

Hi ruudboek, Thanks for the additional info - unfortunately there's no way to tell without debugging the problem whether you're running into an actual bug in code or not. In order to do that, we'd need to get you to open a support case so that our engineers could work with you directly. I can tell you that the behavior you're seeing is not what I would personally expect, but we'd need to have specific data showing the issue in order to see whether anything is actually not functioning as intended, and to file a bug or change request. If you have a support contract with us, just contact your technical account manager to set up a case. Otherwise, you can look here for how to open a support case: http://support.microsoft.com/default.aspx?scid=fh;EN-US;OfferProPhoneDavid Beach - Microsoft Online Community Support
December 13th, 2010 5:12pm

We are having the same issues. We are setting our proxy settings and other user settings thru GPP and also have the "Run logon scripts synchronously" set to enabled and yet, the user policy still does not take effect until the 2nd login. We have been working with Microsoft on this issue and there response is that the "Run logon scripts synchronously" setting does not take effect until the 2nd logon. This make absolutly no sense to me, since it is defeating the purpose of this. we are trying to eliminate our log on script and use GPP and GP for everything, but the user GP and GPP's do not happen until the 2nd logon. this is not acceptable since we are trying to tell our end users how much more efficient windows 7 is. a fix for this issue would be helpful.....
Free Windows Admin Tool Kit Click here and download it now
December 17th, 2010 8:18pm

Hi there appv-newbie, From your post it looks like you have a support case open with us already. Can you tell me the number of that support case so that I can follow up internally?David Beach - Microsoft Online Community Support
December 17th, 2010 8:38pm

I'm really happy that i'm not alone here ;) I still have to ask my manager, i am not sure if i am allowed to have a case created of this, since there are costs involved. I really need a fix for this as well. @appv-newbie, i totally agree with your conclusion on the response of Microsoft on your case confirming that "Run logon scripts synchronously" setting only takes takes effect until the 2nd logon, is completely unacceptable and doesn't make any sense to me either. In Windows XP this never has been an issue, so windows 7 is apparently a step backwards when it comes to properly supporting login scripts? Could you please reply in this topic what the outcome of your support case will be?
Free Windows Admin Tool Kit Click here and download it now
December 19th, 2010 5:03pm

Hi appv-newbie, did your maybe already get a response from microsoft on a possible fix for this problem?
January 11th, 2011 6:12pm

sorry all for the delay in response, been out of town. Here is the Microsoft case # REG: 110122864368700 and this issue has not been resolved yet. Seems that everything is applying except the home page settings. Here is an email received from the Escalation Engineer yesterday. I’m still working with the deployment team to identify methods of modifying the deployment and I’ll update you as soon as I have a list of options for you. Additionally, I’ve reproduced the scenario in my lab and I’ve identified the list of registry entries that get written when the rundll32.exe command executes. The registry entries that are written are few and unnecessary to allow Internet Explorer to run correctly. · Under the Internet Explorer\Main key it sets the “Start Page” and "DisableFirstRunCustomize" Dword value to 3. · Under the Internet Explorer\Toolbar key it sets the “Locked" dword value to 0. · Under the Internet Explorer\Main\Default Feeds it creates the default feeds. Workaround: Delete the Active Setup key under HKLM that launches the BrandIEActiveSetup SIGNUP command. - This would prevent the home page and the above settings from getting written and does not affect the browser’s functionality. Export and delete the following keys and test: HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components\>{60B49E34-C7CC-11D0-8953-00A0C90347FF} And HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\>{60B49E34-C7CC-11D0-8953-00A0C90347FF} Alternatively, you can export the following keys from a logged on user, import them into the default user profile and test: (I have not tested this yet, but this should prevent the ActiveSetup command from executing. I plan on testing this further tomorrow) HKCU\Software\Wow6432Node\Microsoft\Active Setup\Installed Components\>{26923b43-4d38-484f-9b9e-de460746276c} HKCU\Software\Wow6432Node\Microsoft\Internet Explorer Let me know if you have any questions. Sincerely,
Free Windows Admin Tool Kit Click here and download it now
February 8th, 2011 5:17pm

Thanks appv-newbie, i've tried your suggestion and deleted the HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\>{60B49E34-C7CC-11D0-8953-00A0C90347FF} key. Then restarted and logged on on with a user that logs on for the first time, but the desktop is still loaded before the logonscript finishes. So the workaround that you suggest doesn't seem to work for me. Please do keep us informed if a solution is proposed by microsoft though.
February 8th, 2011 6:54pm

I've created a case for this problem at microsoft and microsoft has now released a hotfix to fix this issue. I anyone wants to know, the hotfix can be found here: http://support.microsoft.com/kb/2550944/en-us
Free Windows Admin Tool Kit Click here and download it now
June 22nd, 2011 6:25pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics