Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


DFS shares not showing up with \\domain.local, but work \\domain.local\share

Posted on 2014-03-19
Medium Priority
Last Modified: 2014-03-27
I set up a new DFS namespace that shows up as \\domain.local\apps. This is a single server and the files are all located on the C: drive under C:\DFSRoots\apps. I can go to \\domain.local\apps and see all the files, but if I go to \\domain.local I don't see \apps. I only see \NETLOGON, \SYSVOL and a couple of printers. I am not doing any replication. I do see the share on the server under Share and Storage Management.

There are 3 DCs in this environment and all are running 2008 R2. I recently upped the forest and domain functional level to 2008 R2.

Is there something I am missing to publish this to \\domain.local ?
Question by:mvalpreda
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2

Expert Comment

ID: 39939913
Do you have the Apps folder shared? If it's shared it should show up under \\domain.local

Author Comment

ID: 39939920
I know it should show up under \\domain.local.....but it's not. \apps is shared and I can get to it via \\domain.local\apps. If I go to Start, Run, \\domain.local I only see \SYSVOL, \NETLOGON, and a few printers.

Expert Comment

ID: 39939925
Check the permissions on it, see if they match the Sysvol and netlogon folder.
You don't have to do anything special to see that folder other than share it in my experience.
Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.


Author Comment

ID: 39939935
The permissions are fine. Domain Admins - Full Control, Domain User - Read, Domain Computers - Read.

In looking around, I might need to reboot the DCs after moving them to 2008 R2 functional forest\domain level.
LVL 37

Expert Comment

ID: 39940181
If you open \\domain.local from any client machine, are you able to view apps shared folder ?

According to me it is by default published in domain and you don't have to do explicitly any thing

I can see it by default in my domain and i have checked all settings

make sure that on apps shared folder has everyone read share permissions
On DFS server navigate to HLKM\software\Microsoft\dfs\roots\domain or domainv2 and check if you are able to locate root share and logical share registry

Also check ADUC \ domain.local\system\DFSConfiguration and check there DFS root is showing (Apps in your case)

If you used domain admins for installing DFS, the above entry must be there in ADUC


Author Comment

ID: 39940244
I see apps in ADUC under \domain.local\system\DFSConfiguration.

Under HKLM\SOFTWARE\Microsoft\DFS\Roots\domainV2\apps I have
LogicalShare: apps
RootShare: apps

Since I have 3 DCs on this network, I added the other two servers under the "Namespace Servers" tab so now I have \\dc01\apps, \\dc02\apps, \\dc03\apps. \\dc01\apps is where the files are.

Now when I go to \\domain.local, I see \apps no matter what machine I go to, but the directory is empty sometimes. I know I am connected to one of the other DCs that don't have those files. Do I need to make a symlink? Or is there a cleaner way to do this so the files show up every time and I can see the share from \\domain.local ?

I know I said single server before, should have clarified the 3 DCs and no DFS replication.
LVL 37

Expert Comment

ID: 39941562
The purpose of multiple name space server is to build redundancy
Below is true in your case:
You are having DFS and shared folder links on the same server
Also shared folder residing on single server (dc1)
In that case if you setup multiple name space servers it will not help, because every name space server will create apps shared folder on his root drive (C:\DFSRoot\Apps) which is empty and by entering \\domain.local\apps will get connected to any one name space server due to DNS round robin \ name space server in same site as client computer (I guess all of 3 servers in same site)

If you have shared folders on different file servers other than DFS name space servers, then you will get benefit of having multiple name space servers
In that case if one name space server goes down, you will get connected to another name space server

When you enter \\domain.local\apps, it will connect to any one server of three

You are able to see DFS name space with \\domain.local because now all DCs are name space servers and got Apps shared folder (C:\DFSRoot\Apps)
Previously hitting \\domain.local is getting connected to any random server (DC2 and DC3 where you don't have Apps shared folder)

In my setup DFS is installed on both domain controllers (those are also name space servers) hence I am able to view Corp (DFS name space) when browsing \\

Also I have tried to create DFS name space on standalone member server, now I am unable to view DFS name space when I enter \\ because on domain controller I don't have shared folder for that DFS Root

If you really wanted \\domain.local\Apps to be browsed with multiple name space servers with data, then there are two ways.
Setup replication in mesh topology between all 3 servers through DFS replication console for your shared folder and add \\DC1\Apps, \\DC2\apps and DC3\apps as folder targets in DFS name space.
Now if you type \\domain.local, you will see and can connect to live data (Apps)

Normally DFS replication will be setup between two production sites OR production and DR site as DFS is AD site aware application

The another way is to simply remove another two name space servers from DFS and browse DFS name space through \\domain.,local\Apps and then use backup solution to backup shared folder data


Author Comment

ID: 39942282
It sounds like what I want to do won't work without the data being replicated. I'm thinking you can't have multiple DCs and have the root level of \\domain.local have the shares if they are not replicated

I think I would need to create a new namespace \\domain.local\shares and then have \apps under there. Then have all the namespace servers listed since it creates a symlink to \\server\share

The end game on this was to set up \\domain.local for a client that doesn't map drives and goes straight to \\server to access shares. That server is going away and was trying to make it uniform going forward by using \\domain.local. I would do replication as that is part of the plan also....but someone (well before me) made their Exchange server a DC or this would have worked out.
LVL 37

Accepted Solution

Mahesh earned 2000 total points
ID: 39943238
You can do \\domain.local\shares with multiple name space servers and then add \\DC1\apps as folder target.
Then it will work
Again if server holding share get down, multiple name space servers will useless in that case

According to me if you don't setup DFS replication, then simply \\dc1\apps will be better option


Featured Post

Ransomware: The New Cyber Threat & How to Stop It

This infographic explains ransomware, type of malware that blocks access to your files or your systems and holds them hostage until a ransom is paid. It also examines the different types of ransomware and explains what you can do to thwart this sinister online threat.  

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Active Directory can easily get cluttered with unused service, user and computer accounts. In this article, I will show you the way I like to implement ADCleanup..
A bad practice commonly found during an account life cycle is to set its password to an initial, insecure password. The Password Reset Tool was developed to make the password reset process easier and more secure.
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …
Suggested Courses

719 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question