3

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.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
Jim Lawhon
  • 71
  • 5
  • I've given the answer to this one here: http://serverfault.com/questions/378182/windows-7-blocks-network-access-to-network-installed-apps/627243#627243 – Kjartan Sep 09 '14 at 11:54

2 Answers2

1

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.

Ngugi Kimani
  • 11
  • 2
  • 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](http://blog.serverfault.com/2011/06/09/press-the-green-button-twice/). Can you explain *why* this worked? – voretaq7 Jan 31 '13 at 16:18
0

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

Chris Thorpe
  • 9,953
  • 23
  • 33
  • 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 08:21
  • Try adding it in UNC format \\server\share – Chris Thorpe Apr 10 '11 at 09:21
  • Tried UNC file:////\\server\share as well as a few other variants. Still no go. – Jim Lawhon Apr 11 '11 at 05:34
  • If you map a drive to the share, do the programs run? – Chris Thorpe Apr 11 '11 at 05: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 02:20
  • Ok, put wget on a couple other servers and I'm able to execute the directly and correctly from those servers. When I execute them directly file-shares on the servers in the DFS, it works correctly. So it just seems to fail when using the DFS UNC path or DFS mapped drive. Guess I need to learn a bit about DFS. – Jim Lawhon Apr 12 '11 at 02:23