none
Group Policy software installation fails to install on Windows 7

    Question

  • We have a domain with Windows 2003 R2 and Windows 2008 R2 DCs (PDC is a Windows 2008 R2 machine), and Windows XP and Windows 7 clients.

    Using the software installation facilities in Group Policy Objects we have several packages pushed onto the Windows XP and Windows 7 clients. The Windows XP clients apply these packages without problems and at the first reboot/gpupdate; but the Windows 7 clients do not. In the case of the Windows 7 clients it takes multiple reboots (or gpupdate /force /boot) for the packages to apply to the machines (and at any one time no more than three machines can apply the packages (!?); Windows XP machines will update in dozens without problems). When the application of the packages fails, there are several event errors on the client machine:

    Log Name:      System
    Source:        Application Management Group Policy
    Date:          22/09/2010 14:47:39
    Event ID:      101
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          SYSTEM
    Computer:      lab03.stats.ox.ac.uk
    Description:
    The assignment of application 7-Zip 4.65 (x64 edition) (STATS) from policy computer Software (7-Zip x64) Installation GPO (2010) failed.  The error was : %%1274

    followed by

    Log Name:      System
    Source:        Application Management Group Policy
    Date:          22/09/2010 14:47:39
    Event ID:      103
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          SYSTEM
    Computer:      lab03.stats.ox.ac.uk
    Description:
    The removal of the assignment of application 7-Zip 4.65 (x64 edition) (STATS) from policy computer Software (7-Zip x64) Installation GPO (2010) failed.  The error was : %%2

    and ending in

    Log Name:      System
    Source:        Application Management Group Policy
    Date:          22/09/2010 14:47:39
    Event ID:      108
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          SYSTEM
    Computer:      lab03.stats.ox.ac.uk
    Description:
    Failed to apply changes to software installation settings.  The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon.  The error was : %%1274

    and

    Log Name:      System
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 14:47:39
    Event ID:      1112
    Task Category: None
    Level:         Warning
    Keywords:     
    User:          SYSTEM
    Computer:      lab03.stats.ox.ac.uk
    Description:
    The Group Policy Client Side Extension Software Installation was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.

    The "Always wait for the network at computer startup and logon" policy is already applied through another GPO (at least it seems so...).

    Using "gpresult /r" shows all the machines detect that the GPOs apply to them.

    As an example, one morning I started applying GPOs to 20 machines, and it took 3 hours and 20-30 "gpupdate /force /boot" for 17 of them to apply the packages in question. The remaining 3 took another 15 reboots after that. If this were Windows XP systems it would have taken 1 (maybe 2) reboots for the packages to be applied to all the systems.

    Am I doing something wrong or is Windows 7 that flaky applying software installation GPOs? Has anyone else found this behaviour?

    Thank you for your help.

    Yours,

    FD

    Friday, September 24, 2010 9:41 AM

Answers

  • You can use rsop.msc on the client system to make sure that the network setting is being applied (sorry I missed that point in your original post).

     

    The additional events definitely point to a network issue. Is the behavior the same for all of the Windows 7 systems? are there any other network or AD related issues on these systems?

     

    I also found this related post with a recommendation for another setting to try: http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/ee7cb4e4-7d14-4f1c-86a6-c93463acd9d3.

     

    Thanks,

    Guy

    • Marked as answer by FDDCH Friday, October 29, 2010 9:35 AM
    Friday, September 24, 2010 9:46 PM
  • Sorry for the delay in answering, but it was the beginning of term here last week.

    The "Startup policy processing wait time"=20secs DOES solve the problem with the software GPOs on Windows 7.

    I have now built a new system (I am afraid that the original ones are now in use and I cannot just go around rebooting when the students are using them) in a similar way to the old ones, but cannot reproduce the problem with or without the "Startup policy processing wait time"=20secs policy. I still get a few Event ID 7000, 7017 and 7320 errors in the logs, but the software gets installed anyway. One difference between the old and the new systems is that I used the WDS automatic-domain-join to build the first ones, and I am now manually domain-joining for this last one. Could that have caused these problems? Users can log in to both new and old machines, so AD thinks they are part of the domain, but...

    Thank you for your help.

    David

    • Marked as answer by FDDCH Friday, October 29, 2010 9:35 AM
    Thursday, October 14, 2010 11:57 AM

All replies

  • Hi,

     I've seen this behavior happen when group policies start before the network stack is fully up. There is a setting that can fix that: Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon.

     

    Try to set this for your Windows 7 computers and see if it helps,

     

    If you still have issue, check the Group Policy log under Applications and Services Logs on a Windows 7 system to see if there is more information.

     

    Guy

    Friday, September 24, 2010 6:03 PM
  • As I said in my original posting, 'the "Always wait for the network at computer startup and logon" policy is already applied through another GPO.' Is there a way of checking if the policy has actually applied?

    I looked at the Group Policy Event Log and found some more errors:

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:26
    Event ID:      6323
    Task Category: None
    Level:         Warning
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    Group Policy dependency (Network Location Awareness) did not start. As a result, network related features of Group Policy such as bandwidth estimation and response to network changes will not work.

     

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:33
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 6474 milliseconds.

     

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:33
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 16 milliseconds.

     

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:34
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 0 milliseconds.

     

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:34
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 0 milliseconds.

     

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:34
    Event ID:      7320
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    Error: Retrieved account information. Error code 0x54B.

     

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          22/09/2010 23:22:35
    Event ID:      7000
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab14.stats.ox.ac.uk
    Description:
    Computer boot policy processing failed for STATS\LAB14$ in 8 seconds.

     

    They seem to be there for each gpupdate reboot I made on the machines. Any ideas as to what they may mean? The Network Location Awareness service seems to be up, but still the problem persists.

    FD

    Friday, September 24, 2010 9:38 PM
  • You can use rsop.msc on the client system to make sure that the network setting is being applied (sorry I missed that point in your original post).

     

    The additional events definitely point to a network issue. Is the behavior the same for all of the Windows 7 systems? are there any other network or AD related issues on these systems?

     

    I also found this related post with a recommendation for another setting to try: http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/ee7cb4e4-7d14-4f1c-86a6-c93463acd9d3.

     

    Thanks,

    Guy

    • Marked as answer by FDDCH Friday, October 29, 2010 9:35 AM
    Friday, September 24, 2010 9:46 PM
  • I have just run rsop.msc on the client system and it definitely shows "Always wait for the network at computer startup and logon" to be applied. Cool; I did not know rsop.msc was so neat!

    Yes, all the Windows 7 systems show this problem to some degree (some take a couple of reboots to apply the GPOs, but most take 5+ reboots to do so, and a few 20+). The Windows XP systems do NOT have any problems, but all the Windows 7 ones do. No other AD-related problems that I have found. By the way, could this have something to do with the fact that some of our DCs are 2003 R2 instead of 2008 R2? I have noticed that a one of the systems that took longer to apply the software GPOs seemed to try to bind to one of the 2003 servers rather than the 2008 ones (which is curious, since the 2008 servers should have more bandwidth).

    Those articles sound familiar; I will try the "Startup policy processing wait time" set to 5 seconds.

    Thanks.

    FD

    Friday, September 24, 2010 10:16 PM
  • That's an interest thought, I don't know of a reason that would happen but you could compare access times to the sysvol share (the policy folders in particular) for DCs with both OSes - just open \\dcname\sysvol\domain\policy and see if there is a difference in access time. Another way to test for this would be to move one DC and one client to a different IP subnet and configure that subnet in AD as a new site, the client should prefer a DC in its site for all communication.

     

    Guy

    Friday, September 24, 2010 10:54 PM
  • I have tried installing some software using a GPO on 4 Windows 7 machines after applying the "Startup policy processing wait time" set to 5 seconds. I am afraid that it did not work and I still get the following errors in the Group Policy\Operational event log:

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:24
    Event ID:      6323
    Task Category: None
    Level:         Warning
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    Group Policy dependency (Network Location Awareness) did not start. As a result, network related features of Group Policy such as bandwidth estimation and response to network changes will not work.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:25
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 609 milliseconds.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:25
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 188 milliseconds.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:26
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 78 milliseconds.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:27
    Event ID:      7017
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The system call to get account information completed. The call failed after 16 milliseconds.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:27
    Event ID:      7320
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    Error: Retrieved account information. Error code 0x54B.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:27
    Event ID:      7000
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    Computer boot policy processing failed for STATS\LAB05$ in 3 seconds.

    Also I get the follwing errors in the System event log:

    Log Name:      System
    Source:        NETLOGON
    Date:          26/09/2010 00:08:25
    Event ID:      5719
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      lab05.stats.ox.ac.uk
    Description:
    This computer was not able to set up a secure session with a domain controller in domain STATS due to the following:
    There are currently no logon servers available to service the logon request.
    This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

    Log Name:      System
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:08:27
    Event ID:      1129
    Task Category: None
    Level:         Error
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has succesfully processed. If you do not see a success message for several hours, then contact your administrator.

    Log Name:      System
    Source:        Application Management Group Policy
    Date:          26/09/2010 00:09:32
    Event ID:      101
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The assignment of application R 2.12.0 alpha for Windows (x32/x64 on x64) (STATS) from policy computer Software (R Latest) Installation GPO (2010) failed.  The error was : %%1274

    Log Name:      System
    Source:        Application Management Group Policy
    Date:          26/09/2010 00:09:32
    Event ID:      103
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The removal of the assignment of application R 2.12.0 alpha for Windows (x32/x64 on x64) (STATS) from policy computer Software (R Latest) Installation GPO (2010) failed.  The error was : %%2

    Log Name:      System
    Source:        Application Management Group Policy
    Date:          26/09/2010 00:09:32
    Event ID:      108
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    Failed to apply changes to software installation settings.  The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon.  The error was : %%1274

    Log Name:      System
    Source:        Microsoft-Windows-GroupPolicy
    Date:          26/09/2010 00:09:32
    Event ID:      1112
    Task Category: None
    Level:         Warning
    Keywords:     
    User:          SYSTEM
    Computer:      lab05.stats.ox.ac.uk
    Description:
    The Group Policy Client Side Extension Software Installation was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.

    If I set up the "Startup policy processing wait time" policy to 15 seconds the software installs on all the 4 Windows 7 machines after one reboot.

    There seems to be some kind of networking problem, but I can log in to those systems with a domain account, so the systems must have a way to contact a DC. Anyone have any idea what is going on? Any solutions?

    Thank you for your help.

    FD

    Saturday, September 25, 2010 11:53 PM
  • To make sure I understand correct, are you saying that a delay of 15 seconds allowed everything to work?

     

    I'd say you have a network problem accessing your DCs. Note that logging in with a domain account isn't a good indicator if the account has been used on the machine since the credentials are cached. use dcdiag on the client systems to verify connectivity to a domain controller and check for other DNS or AD related events. Note that this can also happen if your sites configuration is not correct and the clients are trying to use a DC from another site across a slow link.

     

    Thanks,

    Guy

    Monday, September 27, 2010 5:01 PM
  • Nearly; 15 seconds made 17 out of 20 apply on the first reboot. 20 seconds' delay made all 20 apply a software GPO at the first reboot.

    As they eventually all manage to apply the GPOs it would seem the problem is accessing the DCs at startup. Is there a way to find to which DC a client is using?

    All my DCs are on the same server room, though they are connected to different switches.

    FD

    Monday, September 27, 2010 5:22 PM
  • Since the errors don't indicate a DC name, the issue is probably still at the stage of looking for a DC. Is it possible that it takes that long to get a DHCP address or that the DNS server specified on the client takes that long to answer? There might be events in the system log if any of these are timing out.

     

    You can try running diagnostic commands (dcdiag, ipconfig, etc) into a log file using a startup script, try commands like:

     

    dcdiag /s:dcname > c:\dcdiag.log 

    ipconfig /all >c:\ipconfig.log

     

    Thanks,

    Guy

    Monday, September 27, 2010 7:55 PM
  • But if the problem is with the DHCP/DNS, why do the Windows XP systems have no problems? It is the Windows 7 and Windows 2008 systems that are new to the network, and it seems they are the ones having/causing problems; the old systems (XP/2003) seem to be happy.

    FD

    Monday, September 27, 2010 10:04 PM
  • I don't have a direct answer to this, but the netlogon 5719 event you are seeing is unrelated to GPOs and indicates a DC communication issue. Perhaps there is something in the configuration of the network, XP or 7 machines that causes this problem to appear with Windows 7. 

     

    I would eliminate factors by shortcutting the startup process - you can assign a static address to eliminate DHCP. 

     

    Is there anything else in common to only the Windows 7 systems? changes from default configuration, subnet placement, switch or room placement, etc.

    Also, are there other errors in the system event log related to AD access, DNS or time?

     

    Thanks,

    Guy

    Monday, September 27, 2010 10:20 PM
  • Hello FDDCH,

    >Is there a way to find to which DC a client is using?

    You can run nltest /dsgetdc:domainname or set logon.

    Please upload GPRESULT /H GPReport.html and Gpsvc.log file to SkyDrive for further research.

    userenvlog for Windows Vista/2008/Win7
    http://blogs.technet.com/b/mempson/archive/2010/01/10/userenvlog-for-windows-vista-2008-win7.aspx

    Group Policy Slow Link Detection Using Windows Vista and Server 2008
    http://support.microsoft.com/kb/2008977

    Brent Hu,


    Please 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. ”

    Tuesday, September 28, 2010 9:55 AM
  • >>Is there a way to find to which DC a client is using?
    >You can run nltest /dsgetdc:domainname or set logon.

    Is it normal for those commands to show different results on the same machine at the same time?

    C:\Windows\system32>set logon
    LOGONSERVER=\\BLUEWYRM

    C:\Windows\system32>nltest /dsgetdc:stats.ox.ac.uk
               DC: \\stats-win-svr1.stats.ox.ac.uk
          Address: \\163.1.210.4
        Dom Name: stats.ox.ac.uk
      Forest Name: stats.ox.ac.uk
     Dc Site Name: Default-First-Site-Name
    Our Site Name: Default-First-Site-Name
            Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
    The command completed successfully

    FD

    Tuesday, September 28, 2010 10:32 AM
  • Hello FDDCH,

    The “set logon” command retrieves the current logon DC; while the “nltest /dsgetdc:<>” command is used to exercise the locator to find the domain controller for the domain. As the network environment might be different when a user logs on and when you run the nltest command, it is possible that you may get two different DCs in multiple DC environment. 

    I would be glad to help you troubleshoot the issue if you could upload the information I mentioned.

    Brent Hu,
    Please 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. ”
    Wednesday, September 29, 2010 9:48 AM
  • Dear Mr Hu,

    For the test, do you want the "Startup policy processing wait time" policy set to 20 seconds (which makes the GPOs to apply successfully and may not show many errors), or left unset so as to reproduce the initial condition?

    Why would the clients always use the Win2003R2 DCs instead of the newer Win2008R2 DCs for applying software GPOs; this has me really worried as I will have to switch the Win2003R2 DCs one of these days...

    FD (just call me David)

    Wednesday, September 29, 2010 2:22 PM
  • David,

     Do you have subnets defined in AD sites and services? If you have no subnets defined, clients will choose random DCs and can take a long time to select one.

     

    Guy

    Wednesday, September 29, 2010 4:08 PM
  • Guy,

    No, I do not have any subnets defined. But shouldn't that affect the Windows XP machines as well?

    David

    Wednesday, September 29, 2010 6:44 PM
  • It would, I'm just trying to narrow the problem down. It's possible that XP and 7 interact differently with the 2003 DCs. I agree that this is a long shot, but you appear to have a network issue on this configuration and I'm trying to rule out potential components.

     

    Guy

    Wednesday, September 29, 2010 9:37 PM
  • Hello David,


    Please try to configure Startup policy processing wait time setting and set it to 20 seconds under Computer Configuration\Administrative Templates\System\Group Policy node, and then restart the windows 7 machine to check if these errors would be going away.

    Brent Hu,


    Please 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. ”   

    Thursday, September 30, 2010 2:38 AM
  • Hello David,

    If the problem is still not resolved, we will need to collect Network Monitor trace to identify the root cause. You can upload the log file to SkyDrive for further troubleshooting.

    1.Please install Netmon 3.3 on your domain controllers and the remote server in the branch office.
    Microsoft Network Monitor 3.3
    http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
    2.Right-click the Netmon icon and select Run as Administrator to launch NetMon3.3 on domain controllers and the remote server in the branch office.
    3.In the Microsoft Network Monitor 3.3 window, click Create a new capture tab.
    4.In the new tab, select all the Network Adapters in the Select Networks window.
    5.Press F10 to start NetMon.
    6.On the remote server, try to join the domain to reproduce the issue.
    7.After the issue occurs, please go back to the NetMon window and press F11 to stop the NetMon on both computers.
    8.Press Ctrl+S to save the Netmon files.

    Meanwhile, please try to disable Media Sense to check whether the issue can be resolved.

    How to disable Media Sense in Windows 7?
    http://social.answers.microsoft.com/Forums/en-US/w7desktop/thread/18277955-3f2c-4328-bd87-d3567579b645

    Brent Hu,


    Please 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. ”
    Monday, October 04, 2010 8:26 AM
  • Sorry for the delay in answering, but it was the beginning of term here last week.

    The "Startup policy processing wait time"=20secs DOES solve the problem with the software GPOs on Windows 7.

    I have now built a new system (I am afraid that the original ones are now in use and I cannot just go around rebooting when the students are using them) in a similar way to the old ones, but cannot reproduce the problem with or without the "Startup policy processing wait time"=20secs policy. I still get a few Event ID 7000, 7017 and 7320 errors in the logs, but the software gets installed anyway. One difference between the old and the new systems is that I used the WDS automatic-domain-join to build the first ones, and I am now manually domain-joining for this last one. Could that have caused these problems? Users can log in to both new and old machines, so AD thinks they are part of the domain, but...

    Thank you for your help.

    David

    • Marked as answer by FDDCH Friday, October 29, 2010 9:35 AM
    Thursday, October 14, 2010 11:57 AM
  • Thank you for this. I want to confirm I was having the %1274 errors and %2 for Applications as well as the following:

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Level:         Error
    Event ID:      7320
    Error: Retrieved account information. Error code 0x54B.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Event ID:      6323
    Level:         Warning
    Description:
    Group Policy dependency (Network Location Awareness) did not start. As a result, network related features of Group Policy such as bandwidth estimation and response to network changes will not work.

    Log Name:      Microsoft-Windows-GroupPolicy/Operational
    Source:        Microsoft-Windows-GroupPolicy
    Event ID:      7000
    Task Category: None
    Level:         Error
    Description:
    Computer boot policy processing failed for xxxxx in 1 seconds.

    Just enabling the Startup policy wait time and setting it to 30 seconds fixed the problem for me. Ironic that it says unconfigured defaults to 30 seconds but that doesnt seem to be the case if just enabling it fixes it. I have now verified that it works on pretty much every machine in the domain. They are installing software and running startup scripts now.

    Only notice this problem on Win7.. XP is fine. Oh, and I also had 'wait for network' configured as well before changing this.

    Friday, October 29, 2010 7:36 PM
  • I am glad your problem is solved; but we still do not know why exactly this is happening.
    Friday, October 29, 2010 9:04 PM
  • Hello Fddch,

    Windows XP, and Windows 2000 Group Policy uses the ICMP protocol to determine a slow link between the Group Policy client and the domain controller, However, Windows 7 and Windows Vista these new operating systems implement a new slow link detection mechanism that does use NLA instead of using ICMP, please refer to the following:

    Group Policy Slow Link Detection Using Windows Vista and Server 2008
    http://support.microsoft.com/kb/2008977

    Brent
    Please 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. ”
    Monday, November 01, 2010 2:10 AM
  • I had a machine that was working flawlessly with its GPO-deployed apps that just kinda suddenly went AWOL refusing to process any updates/removals/deployments.  I was also getting a chain of these %%1274 errors in tandem with the %%2 errors.

    Tried a bunch of the stuff here but ultimately resolved the symptom by renaming the HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Group Policy key and rebooting.  I believe this triggers a re-synching of the assigned GPOs to the machine as if it is happening for the first time.  At times I have also (I think, just from memory) cleaned out the HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Group Policy/AppMgmt subkey instead of the whole /GroupPolicy key.

    Whatever the source cause, I have had to do this in the past when machines fall victim to asyncrhonous processing of GPOs.  This may not be elegant, but it has been effective in a handful of situations where I was getting so fed up I was considering re-imaging a system.

    Monday, February 18, 2013 4:29 PM