Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a bunch of desktops that are members of a domain. There's a couple of group policy items set on these, and some of these involve copying files from a network share locally (things like config files etc.)

All of my desktops work perfectly, except for one, which was recently rebuilt. For some reason, this loses the ability to be able to access the network share while it is updating its Computer group policy. I noticed this because all of the GP-managed config files were missing from the desktop, and a bunch of entries existed in the EventLog similar to:

The computer 'example-config.cfg' preference item in the 'Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9}' Group Policy object did not apply because it failed with error code '0x80070040 The specified network name is no longer available.' This error was suppressed.

The network share is accessed through an IP address, rather than a DNS name (I know, I know), so I don't think this is a DNS issue.

The strange part of this is if I RDP to the desktop, I can navigate to the network share containing the config files just fine. However, if I open a cmd prompt and hit gpupdate /force, I'm suddenly not able to access the network share. It basically times out. The gpupdate process then runs for far longer than usual, and once it's complete I can access the network share again.

The only thing that's different about this desktop is that the hardware is different (NIC, Gfx, motherboard etc.) How would I go about diagnosing what the problem is here?

share|improve this question
I'm curious, you say it loses network connection during it's "computer group policy" but then you say you just run gpupdate /force. That will update both computer and user GPOs. Have you tried running gpupdate with /target:computer and /target:user one at a time to confirm it loses connection with just one of those? – Jordan W. Jul 28 '11 at 17:08
Good spot - I'll test it tomorrow. – growse Jul 28 '11 at 19:53

The PC connects to the network shares for part of Group Policy using the computer's account. something like MACHINE$. Detach the box from the domain and reboot, rename it MACHINEA or something and reboot, then reattach it and boot again. Move the computer account to the right OU, wait 15 minutes, then boot again.

About 90% of the time that sorts out GP issues at the Computer level.

share|improve this answer
I'll give that a go. I should mention that these machines have just been freshly joined to the domain, the network share is on a box not on the domain and that the share is available via guest access. Seems odd I should have to take it off the domain and join it back just for GP to work. – growse Jul 28 '11 at 19:58
up vote 0 down vote accepted

I have a kind of solution, but it's not a very satisfying one.

The network share was being hosted by a Solaris 11 box, running the SMB daemon. If I switched my network share to a Windows box, the problem was fixed. I have no idea why this is the case, but I'll make sure that all my GPO files are hosted by a Windows box in future.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.