Windows Thread, Always wait for the network GPO setting being ignored in Technical; In the past we have had "Always wait for the network at computer startup and logon" set at the default ...
Always wait for the network GPO setting being ignored
In the past we have had "Always wait for the network at computer startup and logon" set at the default domain policy, this has meant immediately after a machine has been imaged and ran through sysprep the machine reads any MSI installation GPO's and installs them immediately (not after the second reboot) since we upgraded our Domain Functional Level to 2008 R2 (we are still using Win XP SP3 clients) this settings appears to be ignored and is taking 2 or more restarts to install MSI GPO's - We cant seem to track down the issue and have spent hours trying to sort the issue, Win 7 clients (which are in test phase, apply the software installation on first boot into windows)
I have tried everything I can think of including:
Fresh install from non patched Win XP SP3
Fully patched Windows XP SP3
Isolated test domain with Server 2003 R2 << this is what we had before and it *used* to work! and Server 2008 R2 Domain Functional Level
Registry setting to disable mediasense
Registry setting to delay the group policy processing (waiting for network card)
Remove, re-apply the setting
Recreate the policy
Delete the OU and recreate
Different NIC card/Updated drivers
Applied the setting directly on the OU and blocked inheritance
All of the above tests result in the machine applying policies *whilst* at the login prompt not delaying the login prompt and processing the software installations first, resulting in two sometimes three reboots needed to install software.
We are now looking at paying for Microsoft Support, but I am just wondering what happens with other peoples experience of this setting? Is it only supposed to work after the second reboot and somehow its been working after the first reboot for us?
Attached is a screenshot of the error, which to me means its ignoring the setting to disable fast login optimisation, I have also enabled full verbose logging on the client but the userenv.log isnt proving very helpful
What switches do you have? We had a similar problem with an IT room. I enabled portfast on the ports on the switch and it sorted it out. This was with Windows 7 Clients Server 2008 R2 servers.
ive hadsome pcs do this (old dells mainly intel gb cards) where the cards take longer to detect nic speed (1gb cards 100mb switch hp 2124 probaby) flashing the swich solved this as did setting a pc to 100mb 1/2 duplex manually. There is also a reg file i use o make it wait even longer that can help (assuming xp DONT USE THIS ON WIN7)
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"GpNetworkStartTimeoutPolicyValue"=dword:0000003c
What switches do you have? We had a similar problem with an IT room. I enabled portfast on the ports on the switch and it sorted it out. This was with Windows 7 Clients Server 2008 R2 servers.
We have 3COM switches, what is portfast supposed to do? We haven't changed anything else other than raised the domain functional level and changed to DFRS for sysvol, all the DCdiag and repadmin tests result in no issues.
ive hadsome pcs do this (old dells mainly intel gb cards) where the cards take longer to detect nic speed (1gb cards 100mb switch hp 2124 probaby) flashing the swich solved this as did setting a pc to 100mb 1/2 duplex manually. There is also a reg file i use o make it wait even longer that can help (assuming xp DONT USE THIS ON WIN7)
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"GpNetworkStartTimeoutPolicyValue"=dword:0000003c
We have tried that registry tweak, but alas no change - this is happening on brand new Viglens and other machines of varying ages across site
I've had exactly the same problem as you and what I do now is, before I sysprep a machine, I always make sure I have enabled the 'Always wait for the network at computer startup and logon' through gpedit.msc. This ensures that when ever a workstation is rebuilt it will always install software and any other GPO settings first time round.
I would suggest you try that before exhausting yourself for more solutions.
I've had exactly the same problem as you and what I do now is, before I sysprep a machine, I always make sure I have enabled the 'Always wait for the network at computer startup and logon' through gpedit.msc. This ensures that when ever a workstation is rebuilt it will always install software and any other GPO settings first time round.
I would suggest you try that before exhausting yourself for more solutions.
Thank you for your post, I have actually tried that and as you say it works, but we have never done this before on any of our previous builds (I build them personally) and it has been working which has us all stumped!
Do you experience the same issue of it taking two logons to process software installation settings if this is not changed on the image and only on the domain GP?
If this were a switch or NIC timeout issue (which I have experienced) I would be expecting the errors to be more about not being able to contact a DC in the timeout period rather than reporting that logon optimisation is enabled. At some point the machines would refresh GP and pick up that setting. It kinda looks more like the machines simply are not picking up that setting.
My starting point would be to take a look at the .pol file located at %systemroot%\System32\GroupPolicy\Machine\registry .pol with a viewer such as GPOGUY.COM -- Registry.Pol Viewer Utility and see if the effected machines are getting the setting when GP is applied.
Last edited by sparkeh; 16th September 2011 at 11:49 AM.
Reason: Is is affected or effected? Who knows?
Thank you for your post, I have actually tried that and as you say it works, but we have never done this before on any of our previous builds (I build them personally) and it has been working which has us all stumped!
Do you experience the same issue of it taking two logons to process software installation settings if this is not changed on the image and only on the domain GP?
I only experienced this issue the moment I installed 2008 R2 servers and upgraded both the Domain and Forest Functional Levels. When I was running 2003 servers I never had this problem, ever. In some instances no matter how many time I rebooted the workstation the software would never install and none of the GPO settings would apply. Simply enabling the 'Always wait...' setting in gpedit.msc did the trick and fixed my problem.
If this were a switch or NIC timeout issue (which I have experienced) I would be expecting the errors to be more about not being able to contact a DC in the timeout period rather than reporting that logon optimisation is enabled. At some point the machines would refresh GP and pick up that setting. It kinda looks more like the machines simply are not picking up that setting.
My starting point would be to take a look at the .pol file located at %systemroot%\System32\GroupPolicy\Machine\registry .pol with a viewer such as GPOGUY.COM -- Registry.Pol Viewer Utility and see if the effected machines are getting the setting when GP is applied.
We can see the registry entry being applied at "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Wi ndows NT\CurrentVersion\Winlogon" with registry value "SyncForegroundPolicy"=dword:00000001
We have found you cant enter this manually before joining to a domain as the keys aren't there when its not joined to a domain.
I am currently looking at your suggestion of the registry .pol viewer.
ive hadsome pcs do this (old dells mainly intel gb cards) where the cards take longer to detect nic speed (1gb cards 100mb switch hp 2124 probaby) flashing the swich solved this as did setting a pc to 100mb 1/2 duplex manually. There is also a reg file i use o make it wait even longer that can help (assuming xp DONT USE THIS ON WIN7)
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"GpNetworkStartTimeoutPolicyValue"=dword:0000003c
We had to use this on the last 2 batches of pcs as they are too fast for the network or they would not pick up group policy. We appear to have this on machines that 100 meg network cards plugged into 1 gig switches as they are too fast we also had to put in a gpo wait for network I think it is here Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for network