Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Under Windows Server 2008 I'm unable to run many utilities that use network resources. This works just fine under Windows Server 2003.

For example:

  • \\domain\dfs\tools$\bin\sendmail.exe ...
  • \\domain\dfs\tools$\bin\psexec.exe ...
  • echo %_metric% %_value% %_unixtime% | \\domain\dfs\bin\foo$\nc graphite.domain 2003 -w1

Reproducing and maintaining this folder on a large number of servers/vm's is not desirable. Is there a way to allow Windows Server 2008 to run these tools? If so, can this be enabled via GPO or in a fashion that can be scripted during automated builds?

Edit: The commands/tools do work just fine, when run from local drives.

Edit2: Wget example:

d:\scripts\helpers>z:\bin\wget http://www.google.com
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = z:/etc/wgetrc
--2011-04-11 00:32:15--  http://www.google.com/
Resolving www.google.com... failed: Host not found.
z:\bin\wget: unable to resolve host address `www.google.com'

wget can neither use DNS to resolve the IP nor can it use HTTP if provided an IP directly.

Edit3: The problem seems to be tied to DFS/DFS shares. Tools run correctly from other normal windows-server file-shares. They also run correctly when run directly from the file-servers behind the DFS. They only fail when we attempt to run them from the DFS UNC path or mapped drives.

share|improve this question
    
I've given the answer to this one here: serverfault.com/questions/378182/… –  Kjartan Sep 9 at 11:54

2 Answers 2

I was facing the same problem but it was resolved when I disabled access-based enumeration for this namespace.

You may want to try the same.

share|improve this answer
    
Welcome to Server Fault. We prefer answers that include some kind of explanation as to why they work, otherwise your answer may make the problem go away, but it's not really helpful - it's Voodo System Administration. Can you explain why this worked? –  voretaq7 Jan 31 '13 at 16:18

Add the remote share into IE's Trusted sites zone.

share|improve this answer
    
Tried that. Added *.domain to local intranet, also tried trusted sites and with explicit server names. Same results, exe runs, but can't open sockets/network resources. DEP disabled, UAC disabled, domain,public, private firewall policies disabled. Tools are on a DFS, tried to hit the file-servers behind that directly also. No luck. –  Jim Lawhon Apr 10 '11 at 8:21
    
Try adding it in UNC format \\server\share –  Chris Thorpe Apr 10 '11 at 9:21
    
Tried UNC file:////\\server\share as well as a few other variants. Still no go. –  Jim Lawhon Apr 11 '11 at 5:34
    
If you map a drive to the share, do the programs run? –  Chris Thorpe Apr 11 '11 at 5:47
    
The programs run, but again something is blocking outbound connectivity. Wget runs, but is unable to connect out to do DNS lookups or HTTP calls. –  Jim Lawhon Apr 12 '11 at 2:20

Your Answer

 
discard

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.