Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2126
  • Last Modified:

Windows 7 can't get GPOs from Server 2003

I have a domain with a single Server2003 DC and mixed workstations. The XP machines are updating group policies fine, but the Win7 are not. I get this message when trying to force a gpupdate on a Win7 workstation, even while logged in with the domain admin account:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\SysVol\domain.local\Policies\{E92B369E-7226-45F6-95A8-B01EECD69F43}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

The error ID is 1058 and the details tab gives error 1326 (bad username/password) - see error details below for more.

If I try to UNC to the gpt.ini file from the workstation using the FQDN, it prompts for a user/pass and denies access, even with the domain admin creds. However, I can UNC to the gpt.ini file if I use the server name instead of the FQDN.

Asks for login then denies access:

Works without asking for login:

Obviously the machine is trying to use the FQDN path as the error shows, but why would it be denied access on Win7 machines only? Thanks for any help.

Event error details:
Log Name:      System
Source:        Microsoft-Windows-GroupPolicy
Date:          5/29/2013 4:20:36 PM
Event ID:      1058
Task Category: None
Level:         Error
User:          SYSTEM
Computer:      computer-name.domain.local
(see error pasted above)

Event Xml:
<Event xmlns="">
    <Provider Name="Microsoft-Windows-GroupPolicy" Guid="{AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}" />
    <TimeCreated SystemTime="2013-05-29T22:20:36.526579500Z" />
    <Correlation ActivityID="{C827131F-AC1E-45A7-9B01-16034CDB2117}" />
    <Execution ProcessID="1072" ThreadID="3620" />
    <Security UserID="S-1-5-18" />
    <Data Name="SupportInfo1">4</Data>
    <Data Name="SupportInfo2">816</Data>
    <Data Name="ProcessingMode">0</Data>
    <Data Name="ProcessingTimeInMilliseconds">687</Data>
    <Data Name="ErrorCode">1326</Data>
    <Data Name="ErrorDescription">Logon failure: unknown user name or bad password. </Data>
    <Data Name="DCName">\\servername.domain.local</Data>
    <Data Name="GPOCNName">cn={E92B369E-7226-45F6-95A8-B01EECD69F43},cn=policies,cn=system,DC=domain,DC=local</Data>
    <Data Name="FilePath">\\FQDN\SysVol\FQDN\Policies\{E92B369E-7226-45F6-95A8-B01EECD69F43}\gpt.ini</Data>
  • 6
  • 4
  • 3
  • +2
2 Solutions
Check if Policies folder have "DOMAIN USERS" and "DOMAIN COMPUTERS" as read and execute permissions.
Do the Windows 7 clients  get any other GPO's applied? If you create a test GPO, can you see if it applies to a Win 7 client?

Also, when you try to UNC to the gpt.ini file using the FQDN, at what point does it prompt you for creds? Is it right when you type in \\DC_Name?
My GPT.ini files have authenticated users (not domain users). It has read and read & execute. Check the permissions.
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

benconnectedAuthor Commented:
I have made sure that domain users, domain computers, and authenticated users have read & execute permissions from the Windows\SYSVOL folder all the way down.

Some of the Win7 machines do get the Domain Security Policy I created because the screensavers lock and password complexity is enforced. But not all the Win7 machines.

There are three policies in place, all at the domain level, and some Win7 machines can't get any of them. I tried activating each gpo individually and they all fail on some Win7 clients. When I disable all three then the gpupdate will complete, but only if all three GPOs are disabled.

When UNCing with the FQDN, the point where it prompts for user/pass is at \\domain.local\sysvol. I think this is the issue. If I could get these machines to access the gpt.ini file via the FQDN path then it would probably be resolved. But for some reason, it won't let the client access past \\domain.local\sysvol with any creds I try.

I read through that thread, dstewartjr, and I don't think I'm doing anything that is specific to either XP or 7. The three GPOs are:

- Default Domain Policy (I don't believe there are any policies applied here)
- Domain Security Policy (password complexity and screensaver locking)
- Software Deploy Policy (Java, Flash, and Reader .msi installers)

Some Win7 clients get the security policy, but some don't get any of them. If we had a spare Server2008 or Win7 box I'd set it up and just fix the problem that way, but we don't. Right now the only option is getting these GPOs to work.
On the clients that are not working, can you check to see if the Windows FW is enabled?
Also, check the Share permissions (not Security permissions) on \\DC\sysvol

It should look like this:

Everyone - Read
Authernticated Users - Full Control
benconnectedAuthor Commented:
The firewall is off for all network types on the clients.

I verified that the share permissions are set up as you specified. But I also just noticed that I can't access any of the other shares on the server either while using the FQDN. Only if I use the server name.
When you say it works using the server name, do you mean it works when typing \\servername\c$, right?

Is the FW enabled on the DC?
What happens if you create a folder on the DC and share it. Can you access it?
Probably this will fix your problem:
benconnectedAuthor Commented:
Yes, gguadmin, these paths work:

This path does not (prompts for login and denies access):

If I go to \\domain.local I can see all the shares on the server, but I get the same problem when trying to open any of them.

jprlopes - I did the Windows 7 equivalent of that link you gave to remove offline files, and even tried disabling them completely. There was no change.
I remember something that could be the issue with Windows 7 machines.

You should extend the schema of the AD. I think that will allow some fixes regarding Windows 7 machines.

Give it a try.
DonNetwork AdministratorCommented:
You have to use RSAT in order manage Windows 7 group policies

"New Windows Vista–based or Windows Server 2008–based policy settings can be managed only from Windows Vista–based or Windows Server 2008–based administrative computers running the GPMC and the Local Group Policy Editor. Such policy settings are defined only in ADMX files and are not exposed on the Windows Server 2003, Windows XP, or Windows 2000 versions of these tools. An administrator will need to use the GPMC and the Local Group Policy Editor from a Windows Vista–based or Windows Server 2008–based administrative computer to configure new Windows Vista–based Group Policy settings."
Windows 7 is more picky than XP with the two options to always wait for the network, and waiting time for processing policies.
Before switching to Window 7 I didn't understand why so many people insist that these options must be set. Everything worked fine without them. But when the machines with Win 7 came, they received gpo very unreliably. Setting these two options fixed it.
P.S. the precise names of the two options are:
Always wait for the network at computer startup and logon to the computer
Maximum wait time for Group Policy scrips
both are in Computer Configuration\Administrative Templates\System\Logon
The value for the second one is not very important, it won't actually take that long, but it should be set to some value, e.g. 30 seconds. Just don't make it too small.
benconnectedAuthor Commented:
Well guys I'm not sure what fixed it but it's working now.

msifox - I added a GPO with those settings and it wasn't working at first, but now it is. I'm not sure if that's what did it but it looks like the most likely option since it's the last thing I changed.

Thanks for everyone's help, I really appreciate it.
The machines first need to get this new setting once, which can take a few reboots, but once they have it, they should work reliably.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

  • 6
  • 4
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now