none
Failed to read gpt.ini event ID 1058

    Question

  • Hi all,

    We're currently experiencing some intermittent problems with some group policies not being applied properly.  It's intermittent, and has been difficult to pin down, however we keep seeing an error log with event id 1058 in some machines' system event logs (and a very similar error occasionally when doing a gpupdate), the description of the error is:

    The processing of Group Policy failed. Windows attempted to read the file \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\gpt.ini

    I've spent a lot of time trying to find information on this problem, and I came across this article (http://is.gd/8IVSYd) which tells me about three specific error codes found in the Details tab for the error.  However, we're not getting any of those error codes, what we're getting (in the details tab) is:

    ErrorCode: 1808

    ErrorDescription: The account used is a computer account. Use your global user account or local user account to access this server. 

    This sounds like the computer account doesn't have permission to access the policy, but that doesn't make sense to me, because this is intermittent, and surely the computer can either access the file, or it can't!  The policy in question works, most of the time, so what's going on here?

    Could someone help me here, this is sending me insane (or more insane)!?

    Thanks.

     

    Wednesday, March 02, 2011 2:45 AM

Answers

  • Hi,

    According to the ouput of ldifde for the computer object, the useraccountcontrol flag is correct.

    >This to me means that I should be testing accessing the gpt.ini with a computer account, but I'm not sure if this is possible.

    You can try to use PsExec tool and let me know the result.

    Running a CMD prompt as System.
    http://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system/

    PsExec
    http://www.windowsitpro.com/article/remote-computing/psexec.aspx

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


    Brent,

    I've continued doing some testing on network, trying to determine whether, as you suggested, networking issues might be part of this problem.  In testing I found that the problem seemed to disappear if the client machine had a static IP rather than getting an IP from DHCP.  I did some further research and found this posting on Facebook (of all places) referring to the DhcpConnForceBroadcastFlag registry entry.  The symptoms and the network setup (using DHCP helpers) in that post seem to match what we've got happening on our network.  We're currently trialing the use of this registry entry to see if it consistently fixes the problem.  At this stage it seems the errors we were seeing have at least reduced in frequency, although I'm not convinced they've stopped altogether.

    I wondered if you had any thoughts on this?

    Thanks.

    Tuesday, March 22, 2011 1:00 AM
  • Hi Speculator,

    According to the case number you provided, the issue has been identified that the Boot time policy drops the unicast response from the DHCP relay agent and that is the reason dhcp client never receives the ACK. As soon as the Firewall service is started and the profiles are loaded the DHCP ACK is allowed because the firewall allows DHCP traffic.

    The problem can be solved by one of the following workarounds.

    • Set the reigstry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\GUID\DhcpConnForceBroadcastFlag = 1. However, this can be done on every interface and if your reset or reinstall the adapter it sets the registery back to 0 so its not reliable.
    • Turn off Public profile of the firewall or disable the firewall. Not recommended.
    • You can follow this article http://support.microsoft.com/kb/840669  to set the  group policy “Startup Policy processing wait time” (computer configuration->policies->administrative template->system->group policy) which corresponds to this registry "GpNetworkStartTimeoutPolicyValue"
      Windows 7 Clients intermittently fail to apply group policy at startup
      http://support.microsoft.com/kb/2421599

    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, March 28, 2011 4:09 AM
    Moderator
  • Hi Speculator,

    According to the case number you provided, the issue has been identified that the Boot time policy drops the unicast response from the DHCP relay agent and that is the reason dhcp client never receives the ACK. As soon as the Firewall service is started and the profiles are loaded the DHCP ACK is allowed because the firewall allows DHCP traffic.

    The problem can be solved by one of the following workarounds.

    • Set the reigstry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\GUID\DhcpConnForceBroadcastFlag = 1. However, this can be done on every interface and if your reset or reinstall the adapter it sets the registery back to 0 so its not reliable.
    • Turn off Public profile of the firewall or disable the firewall. Not recommended.
    • You can follow this article http://support.microsoft.com/kb/840669  to set the  group policy “Startup Policy processing wait time” (computer configuration->policies->administrative template->system->group policy) which corresponds to this registry "GpNetworkStartTimeoutPolicyValue"
      Windows 7 Clients intermittently fail to apply group policy at startup
      http://support.microsoft.com/kb/2421599

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

    Thanks for all your help Brent,

    I've found that only one of those suggestions actually works consistently for me, and that is setting the DhcpConnForceBroadcastFlag and DhcpConnEnableBcastFlagToggle registry values.  We still have a problem very much the same manifesting itself for all machines using their wireless interfaces, but this isn't fixed by any of these workarounds, and doesn't appear to be related.  We'll try wireless supplicants to remedy this.

    I've created an entry in my blog explaining this issue, for future reference, and to get the info out there.  This has been something of an ordeal to troubleshoot, but we seem to be making some progress now.

    Thanks again.

     

    Wednesday, April 13, 2011 1:58 AM
  • for this to work consistently you can follow these setps.

    Go to the registry  (where 00ab is the adapter no. corresponding to your physical adapter wired or wireless) and not the value of mediatype and physicalmediatype

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\ {4D36E972-E325-11CE-BFC1-08002BE10318}\00ab\MediaType

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\ {4D36E972-E325-11CE-BFC1-08002BE10318}\00ab\ PhysicalMediaType

    Then create following registry key

    HKLM\System\CurrentControlSet\services\Dhcp\Parameters\DhcpGlobalForceBroadcastFlag\<mediatype>\<physicalmediatype>=dword:00000001

    For example: This is for Ethernet adapter. 0 is the mediatype and 14 is physical media type HKLM\System\CurrentControlSet\services\Dhcp\Parameters\DhcpGlobalForceBroadcastFlag\0\14 =dword:00000001 

    For detailed values of NDIS_MEDIUM and NDIS_PHYSICAL_MEDIUM  http://msdn.microsoft.com/en-us/library/aa814491(VS.85).aspx

     

     Delete existing broadcast flag keys per interface

            i.            GO HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID>DhcpConnForceBroadcastFlag

          ii.            Restartthe machine and on boot registry of the interface will be HKLM\System\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID>\ DHCPConnForceBroadcastFlag=1.

     

     

     If you do not want to restart the machine then you have to first disable and stop DHCP client service and then delete the interface specific key as DHCP client service back’s up the registry when the service is stopped and started.

     

    Wireless Adapter

      for wireless adapter you have to go to every cached Wireless SSID key and delete the broadcast flag from there too apart from the interface GUID. then it will pull it from the global setting.

    HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID>\<wirelessSSID>\DHCPConnForceBroadcastFlag.

    Thursday, April 14, 2011 4:27 PM

All replies

  • Hello,

    would be nice if you can start with used OS version and SP/patch level.

    Then post an unedited ipconfig /all from the problem machine and your DC/DNS servers of the domain, at least from the same subnet.


    Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
    Wednesday, March 02, 2011 7:14 AM
  • Thanks for your reply.  I should've provided more information, so sorry for that.  We're running Windows 2008 R2 (no service pack) DC's, and a mix of XP SP3 and Win 7 (no service pack) clients.  We don't believe we're seeing the problem with Win XP clients, however they are a minority on our network.  The following is an ipconfig /all from a Win 7 client experiencing the problem (domain name has been changed to domain.local remove identifying information):


    Windows IP Configuration

       Host Name . . . . . . . . . . . . : LAB1-005-STU-DS
       Primary Dns Suffix  . . . . . . . : domain.local
       Node Type . . . . . . . . . . . . : Peer-Peer
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : domain.local

    Ethernet adapter Local Area Connection:

       Connection-specific DNS Suffix  . : domain.local
       Description . . . . . . . . . . . : Intel(R) 82566DM-2 Gigabit Network Connection
       Physical Address. . . . . . . . . : 00-21-86-17-C1-38
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::dc7b:acc3:3d17:32f2%11(Preferred)
       IPv4 Address. . . . . . . . . . . : 10.4.4.162(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.0.0
       Lease Obtained. . . . . . . . . . : Thursday, 3 March 2011 9:26:47 AM
       Lease Expires . . . . . . . . . . : Friday, 11 March 2011 11:22:41 AM
       Default Gateway . . . . . . . . . : 10.4.0.1
       DHCP Server . . . . . . . . . . . : 10.0.0.6
       DHCPv6 IAID . . . . . . . . . . . : 234889606
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-F3-AB-03-00-21-86-17-C1-38
       DNS Servers . . . . . . . . . . . : 10.0.0.14
                                           10.0.0.6
       Primary WINS Server . . . . . . . : 10.0.0.2
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.domain.local:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : domain.local
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

     

    Here's an ipconfig /all from a DC, which also hosts DNS (it's in a different subnet to the client):


    Windows IP Configuration

       Host Name . . . . . . . . . . . . : MIMAS
       Primary Dns Suffix  . . . . . . . : domain.local
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : domain.local

    Ethernet adapter Local Area Connection 2:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #2
       Physical Address. . . . . . . . . : 00-50-56-BD-50-3D
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::49a5:4a2c:d2de:c405%14(Preferred)
       IPv4 Address. . . . . . . . . . . : 10.0.0.14(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.0.0
       Default Gateway . . . . . . . . . : 10.0.0.254
       DHCPv6 IAID . . . . . . . . . . . : 285233238
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-81-DF-A4-00-50-56-BD-4E-6D
       DNS Servers . . . . . . . . . . . : ::1
                                           10.0.0.6
                                           10.0.0.14
                                           127.0.0.1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.{FE6C4793-CFD3-478B-864B-8ED8A5EE7CAA}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Local Area Connection* 11:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    I should finally point out that this problem is intermittent, in that it doesn't always occur.  Plus, here's some further background info:

    I've recently run DCDIAG /V on both DC's.  They pass all tests except for NCSecDesc, but we don't plan to use RODC's so we can safely ignore that according to this article .

    The problem is affecting Win 7 machines, both desktops, and wireless laptops, from varying vendors.

    If you need any further information I'll be happy to provide it.

    Thanks.

     

    Thursday, March 03, 2011 12:54 AM
  • Hi,

    To verify the permission of share folder, please post the following output of icacls:

    icacls \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921} /t

    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. ”
    Thursday, March 03, 2011 7:14 AM
    Moderator
  • Hi Brent,

    I assume you mean cacls, so I've used that to produce this output, hope it helps, if not I'm happy to provide any further info:

     

    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921} CREATOR OWNER:(OI)(CI)(IO)F 
                                            NT AUTHORITY\Authenticated Users:(OI)(CI)R 
                                            NT AUTHORITY\SYSTEM:(OI)(CI)F 
                                            MARIST\Domain Admins:(OI)(CI)F 
                                            MARIST\Enterprise Admins:(OI)(CI)F 
                                            NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\GPT.INI BUILTIN\Administrators:(ID)F 
                                                NT AUTHORITY\Authenticated Users:(ID)R 
                                                NT AUTHORITY\SYSTEM:(ID)F 
                                                MARIST\Domain Admins:(ID)F 
                                                MARIST\Enterprise Admins:(ID)F 
                                                NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine BUILTIN\Administrators:(ID)F 
                                                CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\User BUILTIN\Administrators:(ID)F 
                                              CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                              NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                              NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                              MARIST\Domain Admins:(OI)(CI)(ID)F 
                                              MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                              NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Microsoft BUILTIN\Administrators:(ID)F 
                                                     CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                     NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                     NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                     MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                     MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                     NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Scripts BUILTIN\Administrators:(ID)F 
                                                    CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                    NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                    NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                    MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                    MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                    NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Microsoft\Windows NT BUILTIN\Administrators:(ID)F 
                                                          CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                          NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                          NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                          MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                          MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                          NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Microsoft\Windows NT\SecEdit BUILTIN\Administrators:(ID)F 
                                                              CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                              NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                              NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                              MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                              MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                              NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf BUILTIN\Administrators:(ID)F 
                                                                    NT AUTHORITY\Authenticated Users:(ID)R 
                                                                    NT AUTHORITY\SYSTEM:(ID)F 
                                                                    MARIST\Domain Admins:(ID)F 
                                                                    MARIST\Enterprise Admins:(ID)F 
                                                                    NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Scripts\Shutdown BUILTIN\Administrators:(ID)F 
                                                        CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                        NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                        NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                        MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                        MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                        NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\Machine\Scripts\Startup BUILTIN\Administrators:(ID)F 
                                                        CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                        NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                        NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                        MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                        MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                        NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\User\Documents & Settings BUILTIN\Administrators:(ID)F 
                                                         CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                         NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                         NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                         MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                         MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                         NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\User\Scripts BUILTIN\Administrators:(ID)F 
                                                  CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                  NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                  NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                  MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                  MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                  NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\User\Scripts\Logoff BUILTIN\Administrators:(ID)F 
                                                      CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                      NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                      NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                      MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                      MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                      NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    \\domain.local\SysVol\domain.local\Policies\{52621A7A-E1C9-4522-BA52-E4E4C0295921}\User\Scripts\Logon BUILTIN\Administrators:(ID)F 
                                                     CREATOR OWNER:(OI)(CI)(IO)(ID)F 
                                                     NT AUTHORITY\Authenticated Users:(OI)(CI)(ID)R 
                                                     NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F 
                                                     MARIST\Domain Admins:(OI)(CI)(ID)F 
                                                     MARIST\Enterprise Admins:(OI)(CI)(ID)F 
                                                     NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)(ID)R 
    
    

    Thanks.

    Friday, March 04, 2011 2:52 AM
  • Hi,

    It seems that the permissions of share folder is no problem. Please try to remove the affected GPO {52621A7A-E1C9-4522-BA52-E4E4C0295921} from GPMC, and re-create a new GPO instead to see if it works.

    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. ”
    Friday, March 04, 2011 3:25 AM
    Moderator
  • Hi,

    It seems that the permissions of share folder is no problem. Please try to remove the affected GPO {52621A7A-E1C9-4522-BA52-E4E4C0295921} from GPMC, and re-create a new GPO instead to see if it works.

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

    Hi,

    I have deleted and recreated the GPO in question, the machines still produce the same error, only now referencing the new GPO, rather than the one listed above.

    Thanks.

    Monday, March 07, 2011 6:11 AM
  • Hi,

    To get a complete overview, please upload the following output files (zip files) to our workspace:

    ipconfig /all >c:\ipconfig.txt (from working windows XP)
    dcdiag /v /c /d /e /s:dcname >c:\dcdiag.txt
    repadmin /showrepl dc* /verbose /all /intersite >c:\repl.txt  ["dc* is a place holder for the starting name of the DCs if they all begin the same (if more then one DC exists)]
    dnslint /ad /s "DCipaddress" (http://support.microsoft.com/kb/321045)
    nltest /dsgetdc:domainname /force > c:\nltest.txt

    Workspace URL: (https://sftasia.one.microsoft.com/ChooseTransfer.aspx?key=e328cab0-cad0-4490-aaef-e115f0531b59)
    Password: 6#pMuccrvZ

    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, March 07, 2011 7:22 AM
    Moderator
  • Hi,

    To get a complete overview, please upload the following output files (zip files) to our workspace:

    ipconfig /all >c:\ipconfig.txt (from working windows XP)
    dcdiag /v /c /d /e /s:dcname >c:\dcdiag.txt
    repadmin /showrepl dc* /verbose /all /intersite >c:\repl.txt  ["dc* is a place holder for the starting name of the DCs if they all begin the same (if more then one DC exists)]
    dnslint /ad /s "DCipaddress " (http://support.microsoft.com/kb/321045 )
    nltest /dsgetdc:domainname /force > c:\nltest.txt

    Workspace URL: (https://sftasia.one.microsoft.com/ChooseTransfer.aspx?key=e328cab0-cad0-4490-aaef-e115f0531b59 )
    Password: 6#pMuccrvZ

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


    Brent,

    The requested files have been uploaded to your workspace as one zipfile, called Speculator.zip.

    Thanks again.

     

    Tuesday, March 08, 2011 6:00 AM
  • Hi,

    According to output of dcdiag, there is no problem on domain controller. Can you collect application,system and group policy logs from event viewer on Windows 7 computer and upload them to our workspace. Thanks.

    Group Policy Logging on Windows Vista
    http://blogs.technet.com/b/askperf/archive/2008/03/11/group-policy-logging-on-windows-vista.aspx

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

    Tuesday, March 08, 2011 8:21 AM
    Moderator
  • Hi,

    According to output of dcdiag, there is no problem on domain controller. Can you collect application,system and group policy logs from event viewer on Windows 7 computer and upload them to our workspace. Thanks.

    Group Policy Logging on Windows Vista
    http://blogs.technet.com/b/askperf/archive/2008/03/11/group-policy-logging-on-windows-vista.aspx

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

     

    Brent,

    Logs have been uploaded, filename was speculator-win7logs.zip.  I hope this helps shed some light on this particularly strange problem.

    Thanks for all your assistance, it's greatly appreciated.

    Speculator.

     

    Tuesday, March 08, 2011 10:21 PM
  • Hi,


    According to the log you provided, I found it logs 5719 in the event viewer below, a Netlogon 5719 event indicates that the client component of Netlogon was unable to locate a DC for the domain it was trying to perform an operation against.

    Netlogon 5719

    ==================

    This computer was not able to set up a secure session with a domain controller in domain MARIST 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. 

    ==================

     

    It seems that the affected computer has been experiencing a network issue.  Network devices (Switches/Routers/Firewalls) on the way are also on the list of prime suspects behind Netlogon 5719 events.  That includes the NIC drivers on both the client logging the event and DC's it is trying to reach.

     

    I suggest installing the latest updates on the affected computer, updating NIC drives and make sure to enable PORTFAST on all the ports except uplink and fiber trunks, etc.

     

    For more detail information, please refer to:

     

    Event 5719 Netlogon Problem

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/87982335-b32c-4f5f-9c95-e9b6582d1bb6/

     

    Also check each item of my suggestion in the thread below.

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/3071c9cc-d554-4697-bbe8-0db5fdca2e0b/


    Meanwhile, please answer and provide the following items:

    ·         Can you access the gpt.ini file from the affected computer? Please run \\MI****. co****.m** \SysVol\ co****.m**\Policies\{77C44327-3E91-400A-B4D9-7FBA531E93FB}\gpt.ini on the client computer and let us know the result.

    ·         Please check the secure channel between the client computer and the DC.

    nltest /sc_query:domain.com

    ·         Please export the LAB1-005-STU-DS computer object form the database by using ldifde utility.
    http://technet.microsoft.com/en-us/library/bb727091.aspx#ECAA

     

    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. ”
    Wednesday, March 09, 2011 6:17 AM
    Moderator
  • Hi,


    According to the log you provided, I found it logs 5719 in the event viewer below, a Netlogon 5719 event indicates that the client component of Netlogon was unable to locate a DC for the domain it was trying to perform an operation against.

    Netlogon 5719

    ==================

    This computer was not able to set up a secure session with a domain controller in domain MARIST 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. 

    ==================

     

    It seems that the affected computer has been experiencing a network issue.  Network devices (Switches/Routers/Firewalls) on the way are also on the list of prime suspects behind Netlogon 5719 events.  That includes the NIC drivers on both the client logging the event and DC's it is trying to reach.

     

    I suggest installing the latest updates on the affected computer, updating NIC drives and make sure to enable PORTFAST on all the ports except uplink and fiber trunks, etc.

     

    For more detail information, please refer to:

     

    Event 5719 Netlogon Problem

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/87982335-b32c-4f5f-9c95-e9b6582d1bb6/

     

    Also check each item of my suggestion in the thread below.

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/3071c9cc-d554-4697-bbe8-0db5fdca2e0b/


    Meanwhile, please answer and provide the following items:

    ·          Can you access the gpt.ini file from the affected computer? Please run \\MI****. co****.m** \SysVol\ co****.m**\Policies\{77C44327-3E91-400A-B4D9-7FBA531E93FB}\gpt.ini on the client computer and let us know the result.

    ·          Please check the secure channel between the client computer and the DC.

    nltest /sc_query: domain.com

    ·          Please export the LAB1-005-STU-DS computer object form the database by using ldifde utility.
    http://technet.microsoft.com/en-us/library/bb727091.aspx#ECAA

     

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


    Hi Brent,

    I've confirmed that I can access the gpt.ini of that policy from the client computer.  I can open and read the file in Notepad.  However, that was accessing the file logged on using a user account.  I'm concerned that the original error accessing the gpt.ini contained the text "The account used is a computer account. Use your global user account or local user account to access this server".  This to me means that I should be testing accessing the gpt.ini with a computer account, but I'm not sure if this is possible.

    Anyway, the result of nltest was:

    Flags: 30 HAS_IP  HAS_TIMESERV
    Trusted DC Name \\M***S.c***s.mrc
    Trusted DC Connection Status Status = 0 0x0 NERR_Success
    The command completed successfully

    The output of ldifde for the client in question was:

    dn: CN=LAB1-005-STU-DS,OU=Lab1,OU=Student Computers,DC=c***s,DC=m**
    changetype: add
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: user
    objectClass: computer
    cn: LAB1-005-STU-DS
    distinguishedName:
     CN=LAB1-005-STU-DS,OU=Lab1,OU=Student Computers,DC=c***s,DC=m**
    instanceType: 4
    whenCreated: 20101209233814.0Z
    whenChanged: 20110310010110.0Z
    displayName: LAB1-005-STU-DS$
    uSNCreated: 119280
    uSNChanged: 1104707
    name: LAB1-005-STU-DS
    objectGUID:: cKpoqRn6rU+Ucf3pUjEmdg==
    userAccountControl: 4096
    badPwdCount: 0
    codePage: 0
    countryCode: 0
    badPasswordTime: 0
    lastLogoff: 0
    lastLogon: 129442037718060246
    localPolicyFlags: 0
    pwdLastSet: 129427344568928400
    primaryGroupID: 515
    objectSid:: AQUAAAAAAAUVAAAAACAgGGB60iO8bIIAe1QAAA==
    accountExpires: 9223372036854775807
    logonCount: 37
    sAMAccountName: LAB1-005-STU-DS$
    sAMAccountType: 805306369
    operatingSystem: Windows 7 Professional
    operatingSystemVersion: 6.1 (7600)
    dNSHostName: LAB1-005-STU-DS.c***s.m**
    servicePrincipalName: HOST/LAB1-005-STU-DS.c***s.m**
    servicePrincipalName: RestrictedKrbHost/LAB1-005-STU-DS.c***s.m**
    servicePrincipalName: RestrictedKrbHost/LAB1-005-STU-DS
    servicePrincipalName: HOST/LAB1-005-STU-DS
    objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=c***s,DC=m**
    isCriticalSystemObject: FALSE
    dSCorePropagationData: 20101209234512.0Z
    dSCorePropagationData: 16010101000001.0Z
    lastLogonTimestamp: 129441924702835854
    msDS-SupportedEncryptionTypes: 28

    Another note - today I've been able to confirm this problem on desktop computers with very different hardware types (an AMD based clone PC with an nvidia chipset, and an Intel based Lenovo PC), so I think this might rule out hardware drivers as being the problem. 

    Also, portfast is enabled, it has to be, otherwise our PXE booting that we use with Symantec Ghost will fail.

    I am working through some of the links you mentioned.

    Thanks again for your help!

     

     

    Thursday, March 10, 2011 5:11 AM
  • Hi,

    According to the ouput of ldifde for the computer object, the useraccountcontrol flag is correct.

    >This to me means that I should be testing accessing the gpt.ini with a computer account, but I'm not sure if this is possible.

    You can try to use PsExec tool and let me know the result.

    Running a CMD prompt as System.
    http://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system/

    PsExec
    http://www.windowsitpro.com/article/remote-computing/psexec.aspx

    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. ”
    Thursday, March 10, 2011 5:44 AM
    Moderator
  • Hi,

    According to the ouput of ldifde for the computer object, the useraccountcontrol flag is correct.

    >This to me means that I should be testing accessing the gpt.ini with a computer account, but I'm not sure if this is possible.

    You can try to use PsExec tool and let me know the result.

    Running a CMD prompt as System.
    http://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system/

    PsExec
    http://www.windowsitpro.com/article/remote-computing/psexec.aspx

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


    Brent,

    I've continued doing some testing on network, trying to determine whether, as you suggested, networking issues might be part of this problem.  In testing I found that the problem seemed to disappear if the client machine had a static IP rather than getting an IP from DHCP.  I did some further research and found this posting on Facebook (of all places) referring to the DhcpConnForceBroadcastFlag registry entry.  The symptoms and the network setup (using DHCP helpers) in that post seem to match what we've got happening on our network.  We're currently trialing the use of this registry entry to see if it consistently fixes the problem.  At this stage it seems the errors we were seeing have at least reduced in frequency, although I'm not convinced they've stopped altogether.

    I wondered if you had any thoughts on this?

    Thanks.

    Tuesday, March 22, 2011 1:00 AM
  • Hi,

    Based on the following blog, this issue does not occur in Windows 7, the registry key DhcpConnEnableBcastFlagToggle is set to 1 by default. In Windows 7, the behaviour change introduced would try with both the values for the broadcast flag (toggling between '0' & '1') and also would cache the last successful broadcast bit setting for which the client received IP address.  By setting "DhcpConnEnableBcastFlagToggle" to 1, Windows 7 will first try to obtain an IP address by using the BROADCAST flag in DHCP Discover packets. If that fails, it will try to obtain an IP address without using the BROADCAST flag in DHCP Discover packets. 

    To identify the root cause, you may verify the broadcast flag settings by using network monitor.

    1. Install the latest network monitor
      http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
    2. Apply filter ‘DHCP’ and start capturing the packets.
    3. In an elevated command prompt, do ipconfig /release “Name of Interface”, specify the interface name in which you want to verify.
    4. Then, do ipconfig /renew  “Name of Interface”
    5. You can find that DHCP packets are getting captured on network monitor. Expand the flags field of DHCP DISCOVER packet, the first bit of this field denotes the broadcast flag set.
    6. By default, you should be seeing 8 DISCOVER packets for a total duration of 2 mins. The first 4 DISCOVER packets will have the flag set to "0" and the next 4 will have the flag set to "1".

    DHCP Broadcast flag handling in Windows 7
    http://blogs.technet.com/b/teamdhcp/archive/2009/02/12/dhcp-broadcast-flag-handling-in-windows-7.aspx

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

    Tuesday, March 22, 2011 3:16 AM
    Moderator
  • Hi,

    Based on the following blog, this issue does not occur in Windows 7, the registry key DhcpConnEnableBcastFlagToggle is set to 1 by default. In Windows 7, the behaviour change introduced would try with both the values for the broadcast flag (toggling between '0' & '1') and also would cache the last successful broadcast bit setting for which the client received IP address.  By setting "DhcpConnEnableBcastFlagToggle" to 1, Windows 7 will first try to obtain an IP address by using the BROADCAST flag in DHCP Discover packets. If that fails, it will try to obtain an IP address without using the BROADCAST flag in DHCP Discover packets. 

    To identify the root cause, you may verify the broadcast flag settings by using network monitor.

    1. Install the latest network monitor
      http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
    2. Apply filter ‘DHCP’ and start capturing the packets.
    3. In an elevated command prompt, do ipconfig /release “Name of Interface”, specify the interface name in which you want to verify.
    4. Then, do ipconfig /renew  “Name of Interface”
    5. You can find that DHCP packets are getting captured on network monitor. Expand the flags field of DHCP DISCOVER packet, the first bit of this field denotes the broadcast flag set.
    6. By default, you should be seeing 8 DISCOVER packets for a total duration of 2 mins. The first 4 DISCOVER packets will have the flag set to "0" and the next 4 will have the flag set to "1".

    DHCP Broadcast flag handling in Windows 7
    http://blogs.technet.com/b/teamdhcp/archive/2009/02/12/dhcp-broadcast-flag-handling-in-windows-7.aspx

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

     

    Brent,

    I have performed the DHCP capture you suggested, and I don't see the 4 DISCOVER packets indicated.  I just see one from the MAC address of the PC I was using to test.

    I notice now, that despite setting the DhcpConnForceBroadcastFlag to 1 I'm still seeing instances of the NETLOGON error you pointed out previously, AND instances of event ID 50024 in the dhcp-client operational event log.

    However, I think this all might be redundant anyway, as it seems that someone else might have already done the troubleshooting for me, and logged a case with Microsoft.  It seems this has been confirmed as a bug, according to this forum post - http://www.edugeek.net/forums/windows-7/60087-win-7-dhcp-netlogon-firewall-microsoft-confirm-bug.html are you able to confirm this?  Post #12 in that thread gives the case number and MS rep.  The events described match exactly what we're seeing, and the symptoms of the bug are also similar, particularly that of inconsistently applied GP's.

    Thanks.

     

    Monday, March 28, 2011 1:48 AM
  • Hi Speculator,

    According to the case number you provided, the issue has been identified that the Boot time policy drops the unicast response from the DHCP relay agent and that is the reason dhcp client never receives the ACK. As soon as the Firewall service is started and the profiles are loaded the DHCP ACK is allowed because the firewall allows DHCP traffic.

    The problem can be solved by one of the following workarounds.

    • Set the reigstry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\GUID\DhcpConnForceBroadcastFlag = 1. However, this can be done on every interface and if your reset or reinstall the adapter it sets the registery back to 0 so its not reliable.
    • Turn off Public profile of the firewall or disable the firewall. Not recommended.
    • You can follow this article http://support.microsoft.com/kb/840669  to set the  group policy “Startup Policy processing wait time” (computer configuration->policies->administrative template->system->group policy) which corresponds to this registry "GpNetworkStartTimeoutPolicyValue"
      Windows 7 Clients intermittently fail to apply group policy at startup
      http://support.microsoft.com/kb/2421599

    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, March 28, 2011 4:09 AM
    Moderator
  • Hi Speculator,

    According to the case number you provided, the issue has been identified that the Boot time policy drops the unicast response from the DHCP relay agent and that is the reason dhcp client never receives the ACK. As soon as the Firewall service is started and the profiles are loaded the DHCP ACK is allowed because the firewall allows DHCP traffic.

    The problem can be solved by one of the following workarounds.

    • Set the reigstry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\GUID\DhcpConnForceBroadcastFlag = 1. However, this can be done on every interface and if your reset or reinstall the adapter it sets the registery back to 0 so its not reliable.
    • Turn off Public profile of the firewall or disable the firewall. Not recommended.
    • You can follow this article http://support.microsoft.com/kb/840669  to set the  group policy “Startup Policy processing wait time” (computer configuration->policies->administrative template->system->group policy) which corresponds to this registry "GpNetworkStartTimeoutPolicyValue"
      Windows 7 Clients intermittently fail to apply group policy at startup
      http://support.microsoft.com/kb/2421599

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

    Thanks for all your help Brent,

    I've found that only one of those suggestions actually works consistently for me, and that is setting the DhcpConnForceBroadcastFlag and DhcpConnEnableBcastFlagToggle registry values.  We still have a problem very much the same manifesting itself for all machines using their wireless interfaces, but this isn't fixed by any of these workarounds, and doesn't appear to be related.  We'll try wireless supplicants to remedy this.

    I've created an entry in my blog explaining this issue, for future reference, and to get the info out there.  This has been something of an ordeal to troubleshoot, but we seem to be making some progress now.

    Thanks again.

     

    Wednesday, April 13, 2011 1:58 AM
  • for this to work consistently you can follow these setps.

    Go to the registry  (where 00ab is the adapter no. corresponding to your physical adapter wired or wireless) and not the value of mediatype and physicalmediatype

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\ {4D36E972-E325-11CE-BFC1-08002BE10318}\00ab\MediaType

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\ {4D36E972-E325-11CE-BFC1-08002BE10318}\00ab\ PhysicalMediaType

    Then create following registry key

    HKLM\System\CurrentControlSet\services\Dhcp\Parameters\DhcpGlobalForceBroadcastFlag\<mediatype>\<physicalmediatype>=dword:00000001

    For example: This is for Ethernet adapter. 0 is the mediatype and 14 is physical media type HKLM\System\CurrentControlSet\services\Dhcp\Parameters\DhcpGlobalForceBroadcastFlag\0\14 =dword:00000001 

    For detailed values of NDIS_MEDIUM and NDIS_PHYSICAL_MEDIUM  http://msdn.microsoft.com/en-us/library/aa814491(VS.85).aspx

     

     Delete existing broadcast flag keys per interface

            i.            GO HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID>DhcpConnForceBroadcastFlag

          ii.            Restartthe machine and on boot registry of the interface will be HKLM\System\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID>\ DHCPConnForceBroadcastFlag=1.

     

     

     If you do not want to restart the machine then you have to first disable and stop DHCP client service and then delete the interface specific key as DHCP client service back’s up the registry when the service is stopped and started.

     

    Wireless Adapter

      for wireless adapter you have to go to every cached Wireless SSID key and delete the broadcast flag from there too apart from the interface GUID. then it will pull it from the global setting.

    HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID>\<wirelessSSID>\DHCPConnForceBroadcastFlag.

    Thursday, April 14, 2011 4:27 PM