Answered by:
DFS shares disappear intermittently
Question
-
Environment:
2 Parent DC's (Server 2008 R2 native). Also running DNS and DHCP. No clients in parent domain.
2 Child DC's (Server 2008 R2 native). Both host DFS namespace. All clients reside in this domain.
Clients: Mix of Windows XP and Windows 2000 (I know, I know, I'm workin' on it)
DFS namespace:
\\Domain.Local\DFS$
\\Domain.Local\DFS$\Profiles
\\Domain.Local\DFS$\Redirected Documents
There is only 1 replica of the DFS root which lives on our primary file server (2003). We are only using DFS so that we can have a generic, non-server name specific UNC path to use when referencing roaming profiles or redirected documents.
There are a series of problems happening which I believe are related to DFS. All users have roaming profiles which are directed to a share in the DFS namespace. In the last 2-3 weeks, users have reported errors stating that their profile could not be located. Windows would log them in with a temporary profile.
In troubleshooting I noticed that these users could open the DFS root (\\Domain.Local\DFS$), but the folder would be empty. Since their profile and redirected documents live in subfolders of the DFS root, that would explain why their profile could not be found. But why don't they see the subfolders in the DFS root in the first place?
So here's the weird part. This problem is intermittent. If the user reboots, or waits 10-15 minutes before logging on again, they will log on with their roaming profile just fine. When that happens, the DFS root can be opened and they will be able to access all of the expected subfolders.
No major changes have been made in this environment within the last 2 weeks. I have disregarded a handful of these issues over the last couple months (since we upgraded the domain to 2008 R2) as simple network connectivity issues. But the whole problem seems to have blown up since I rebooted one of the child DCs almost 2 weeks ago.
I don't know if it's related, but for some reason our environment doesn't take kindly to one of the 2 domain controllers going down. When 1 machine is down, there are reports of extremely slow network access, failed logons, and all other signs that the domain is completely down. All of that will be fixed if they simply reboot their computer. But we have 2 DCs! Why can't the client connect to the DC that is still up and running without requiring a reboot? And is this related to the DFS issues I am having?
For most of our users, DFS and the roaming profiles work fine. In fact, for those who are having problems, if you wait long enough, the problems seem to fix themselves. So it is very hard to nail down a good example of a machine/user that is experiencing the problem so I can troubleshoot it. But it is getting bigger and bigger by the day. Can anyone help?
Answers
-
Hello
First I will start by checking the health of all the DCs by running the dcdiag /v and also repadmin /showreps commands and look for any errors. Because if one DC is down and users are having issue, it might be problems that the other DCs are not functioning properly.
For the DFS taking 10-15 mins or a reboot to resolve issue, make sure that the share/access permissions are consistent accross all the shares and namespaces.
Isaac Oben MCITP:EA, MCSE- Marked as answer by Duct tape and super glue Tuesday, July 13, 2010 12:23 AM
-
Hey what-do-you-know...our DFS Namespace is still running in Windows 2000 Server mode. I'm going to try deleting the namespace entirely and recreating it. Hopefully that will create the objects I'm missing.
- Marked as answer by Duct tape and super glue Tuesday, July 13, 2010 12:23 AM
All replies
-
Hello
First I will start by checking the health of all the DCs by running the dcdiag /v and also repadmin /showreps commands and look for any errors. Because if one DC is down and users are having issue, it might be problems that the other DCs are not functioning properly.
For the DFS taking 10-15 mins or a reboot to resolve issue, make sure that the share/access permissions are consistent accross all the shares and namespaces.
Isaac Oben MCITP:EA, MCSE- Marked as answer by Duct tape and super glue Tuesday, July 13, 2010 12:23 AM
-
Hello, thank you for your response. I've been looking through logs and diagnostics all morning. I ran the utilities you listed above, the repadmin command shows all replication happening successfully. The dcdiag did show a failed test when it ran the VerifyEnterpriseReferences test. Here's the output:
Starting test: VerifyEnterpriseReferences
The following problems were found while verifying various important DN references. Note, that
these problems can be reported because of latency in replication. So follow up to resolve the
following problems, only if the same problem is reported on all DCs for a given domain or if the
problem persists after replication has had reasonable time to replicate changes.[1] Problem: Missing Expected Value
Base Object: CN=SODC2,OU=Domain Controllers,DC=domain
Base Object Description: "DC Account Object"
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862
[2] Problem: Missing Expected Value
Base Object: CN=SODC1,OU=Domain Controllers,DC=domain
Base Object Description: "DC Account Object"
Value Object Attribute Name: msDFSR-ComputerReferenceBL
Value Object Description: "SYSVOL FRS Member Object"
Recommended Action: See Knowledge Base Article: Q312862
LDAP Error 0x20 (32) - No Such Object.
......................... SODC1 failed test VerifyEnterpriseReferencesI opened those objects up with ADSI Edit, and the attribute mentioned in the output (msDFSR-ComputerReferenceBL) is in fact "<not set>". I also looked up the KB article mentioned in the output. It references an object within AD that I don't have: cn=DFS Volumes,cn=File Replication Service, cn=<var>system</var>,dc=<var>domain.</var> The "File Replication Service" object is there, but not the "DFS Volumes" object.
I did some more digging and ended up looking through the DFS logs located at C:\Windows\Debug\Dfsr0000#.log. There is a set of errors that seem to happen every 5 minutes:
- 20100708 11:55:23.882 2028 CFAD 2159 [ERROR] Config::AdQuery::Search Failed to ldap_search_ext_s(). Error:No Such Object base:cn=DFSR-GlobalSettings,cn=system,DC=domain
- 20100708 11:55:23.882 2028 CFAD 12129 [ERROR] Config::AdReader::GetSysVolGlobalFlags Failed to GetGlobalSettings(). settingsDnAddr:cn=DFSR-GlobalSettings,cn=system,DC=domain
I tried looking through ADSI Edit for this DFSR-GlobalSettings object, but it doesn't seem to exist. So, the KB article above gives me steps on how to manually recreate the DFS Volumes object I seem to be missing, but it makes no mention of the DFSR-GlobalSettings object listed in the log file. I'm a little nervous about following the steps to manually recreate the DFS Volumes object because 1) The article says it applies to Windows 2000 and 2003 servers and I'm running 2008 R2. And 2) I'm not sure if those objects are supposed to be in AD at all since I only have 1 DFS share located on 1 file server, and all of these settings seem to apply to replication partners. If I'm not replicating the share anywhere, should those settings still exist in AD?
This AD environment was originally created in Windows 2000. It has since been upgraded to 2003, and then to 2008 R2. At some point in time (I believe it was when the domain was a 2003 domain), 2 additional domain controllers had been promoted, but never properly demoted. I had to remove them manually. Maybe somewhere along the line something got deleted that shouldn't have.
-
I just did another search on the msDFSR-ComputerReferenceBL attribute and came up with this article (if you're using IE8 you have to use the compatibility view to see the text properly):
According to this article, it says that the proper value of that attribute should some setting within the DFSR-GlobalSettings object I'm missing! So there's the link between those two errors. (At least some of this stuff is starting to come together).
So I guess the question is...how do I recreate the DFSR-GlobalSettings object? Could this be as simple as uninstalling and reinstalling DFS or something like that?
-
Hey what-do-you-know...our DFS Namespace is still running in Windows 2000 Server mode. I'm going to try deleting the namespace entirely and recreating it. Hopefully that will create the objects I'm missing.
- Marked as answer by Duct tape and super glue Tuesday, July 13, 2010 12:23 AM
-
Hey, it looks like that did the trick!
Running dcdiag gave me the clues I needed to figure out that current namespace was not only missing AD objects, but it was also running in Windows 2000 mode. I deleted the namespace and recreated the same namespace using 2008 mode. Once I did that, all the necessary AD objects showed up just like I was expecting them to. Thanks Isaac for pointing me in the right direction!