DFS question

[Sinix]

I've got a small issue which I can't get around.
- Lets say I have 3 sites.
Site A 10.1.1.1
Site B 10.1.1.2
Site C 10.1.1.3
- Each site has a server Windows 2008.
- DFS is set up between all 3 sites.
- Login script maps their local server as H:\

Everything works fine, however - when a user from site A emails a link from outlook to users at site B & C, the location of the file points to Site A.
Example:
H:\file.txt converts to file:///10.1.1.1/file.txt is there any way round this so that the link can point to a local mapped drive?

[Iceman]

How are your users getting the server-specific link to the file? Are you allowing them to browse direct to \\10.1.1.1\share as well as \\dfs.namespace\share ?

[Sinix]

They are only browsing directly to \\10.1.1.1\share H:\ Drive

http://www.msoutlook.info/question/310
Now I'm wondering if maybe I can disable the UNC substitute in outlook.

I'm not sure if asking all the users to type:
file://<hyperlink>

is the way to go =\

[tensop]

how have you mapped your shares... they shouldnt really be seeing an IP iirc

should be \\dfs.namesspace.blah\

[Iceman]

Originally Posted by tensop

how have you mapped your shares... they shouldnt really be seeing an IP iirc

should be \\dfs.namesspace.blah\

This, outlook is behaving correctly, if you tell me your files live on H:\server - that is of no use to me unless H: is mapped consistently to the same thing on every single workstation - outlook is fixing this meatspace error for you.

Essentially still doing DFS wrong if your clients are ever seeing \\local.server instead of \\domain.name for DFS shares. I think you might be doing this as a way to ensure you're hitting the on-site server as opposed to the one on the other end of a WAN link?

While I haven't looked at it in 3 or 4 years .. I recall DFS is squirrelly when it comes to picking a server to access. There was a particular problem with it using the IP address to determine if the DFS server was local or not (it didn't measure bandwidth or latency for example, just went 'if it's not in my subnet, it's remote' which is a problem if you do the common thing of stretching your basic 192.168.1.1/24 IP range across two sites via a transparent VPN - DFS does not know the other server is far away and clients should prefer yours.

Any of this sound like your problem?

[Sinix]

Iceman; that's correct.

Currently DFS can't pickup the correct local server, this is because our AD sites and services is still configured as one big site, DEFAULT-SITE.
We are in the process of making the changes, hopefully this will resolve it.