Failed to read gpt.ini event ID 1058
-
Wednesday, March 02, 2011 2:45 AM
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.
- Changed Type Brent HuModerator Monday, March 07, 2011 1:21 PM
All Replies
-
Wednesday, March 02, 2011 7:14 AM
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. -
Thursday, March 03, 2011 12:54 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 . . . . : YesHere'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 7:14 AMModerator
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. ” -
Friday, March 04, 2011 2:52 AM
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)RThanks.
-
Friday, March 04, 2011 3:25 AMModeratorHi,
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. ” -
Monday, March 07, 2011 6:11 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. ”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 7:22 AMModerator
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. ” -
Tuesday, March 08, 2011 6:00 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. ”
Brent,The requested files have been uploaded to your workspace as one zipfile, called Speculator.zip.
Thanks again.
-
Tuesday, March 08, 2011 8:21 AMModerator
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 10:21 PM
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.
-
Wednesday, March 09, 2011 6:17 AMModerator
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
Also check each item of my suggestion in the thread below.
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#ECAABrent
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:11 AM
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
Also check each item of my suggestion in the thread below.
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#ECAABrent
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 successfullyThe 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: 28Another 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:44 AMModeratorHi,
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. ” -
Tuesday, March 22, 2011 1:00 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. ”
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.
- Marked As Answer by Brent HuModerator Friday, March 25, 2011 1:24 AM
-
Tuesday, March 22, 2011 3:16 AMModerator
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.- Install the latest network monitor
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f - Apply filter ‘DHCP’ and start capturing the packets.
- In an elevated command prompt, do ipconfig /release “Name of Interface”, specify the interface name in which you want to verify.
- Then, do ipconfig /renew “Name of Interface”
- 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.
- 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. ” - Install the latest network monitor
-
Monday, March 28, 2011 1:48 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.- Install the latest network monitor
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f - Apply filter ‘DHCP’ and start capturing the packets.
- In an elevated command prompt, do ipconfig /release “Name of Interface”, specify the interface name in which you want to verify.
- Then, do ipconfig /renew “Name of Interface”
- 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.
- 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.
- Install the latest network monitor
-
Monday, March 28, 2011 4:09 AMModerator
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. ”- Marked As Answer by Brent HuModerator Wednesday, April 13, 2011 5:21 AM
-
Wednesday, April 13, 2011 1:58 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. ”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
DhcpConnForceBroadcastFlagandDhcpConnEnableBcastFlagToggleregistry 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.
- Marked As Answer by Brent HuModerator Wednesday, April 13, 2011 5:23 AM
-
Thursday, April 14, 2011 4:27 PM
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.
- Proposed As Answer by kapil Thacker [MSFT] Thursday, April 14, 2011 4:28 PM
- Edited by kapil Thacker [MSFT] Thursday, April 14, 2011 4:29 PM correction
- Marked As Answer by Brent HuModerator Thursday, April 21, 2011 4:20 AM
.png)
