Hi all,
Windows 2000 Server, Service Pack 4
Some names have been changed to protect the guilty (me).
We've got three Windows servers total. One is a utility server and
irrelevant to this. The other two are both does-everything servers.
Both are DCs. Both host a directory full of miscellaneous utilities
named "BIN". We had an AD domain DFS root, "FooDFS", such that
"\\ad.foocorp.com\FooDFS\BIN" could get to the utilities and changes
would replicate automatically. I wanted to move "BIN" to a different
partition on one server, and I guess I did something wrong, because
now FRS is slightly borken.
On server LION, BIN was on C:\BIN and I wanted to move it to D:\BIN.
What I did was to ROBOCOPY the "BIN" directory from one partition to
another, unshare "BIN", then re-share it with the same share name but
new directory location. Then I removed the old directory. FRS began
complaining about C:\BIN missing. I guess FRS looks at local paths,
not share names. Oops.
I went into DFSGUI, opened the "BIN" link, and removed \\LION\BIN\
from the replica set, leaving just \\PUMA\BIN\ there. I was hoping
that would clue FRS on LION into realizing that it should give up on
C:\BIN now. No such luck. If I create a new C:\BIN\ then FRS stops
complaining about it missing, but that doesn't really fix the problem.
And the following warning continues to appear (Event ID 13562 from
NtFrs):
The nTFRSSubscriber object
cn=foodfs|bin,cn=foodfs,cn=b581537a-8d68-44fc-adf2-873ef722c631,cn=dfs
volumes,cn=ntfrs subscriptions,cn=lion,ou=domain
controllers,dc=ad,dc=foocorp,dc=com has a invalid value for the
attribute frsMemberReference.
If I open up ADSIEDIT and navigate to Domain NC -> DC=ad.foocorp.com
-> OU=Domain Controllers, I see a container named "CN=NTFRS
Subscriptions" under each DC. For PUMA (the server I wasn't messing
with), I see something about SYSVOL (good), and no sub-folders (good,
I think). For LION (the server I borked) I see a similar thing for
SYSVOL, but I also have a sub-container named "CN=DFS Volumes". Under
that there's a sub-container with what looks like a GUID for a name --
it matches the above. Under *that*, there's a notepad icon named
"CN=FooDFS|BIN". I presume that's where LION is getting the
out-of-date info from. If I view the properties on that guy, the
"fRSMemberReference" attribute says it is "<not set>".
FRS seems to be working okay otherwise. In particular, SYSVOL
replication between the two servers seems to be working just fine. A
file created on NETLOGON on one server appears on the other within
seconds. NETDIAG and DCDIAG all say everything is peachy. No other
relevant trouble that I know of.
I've found various stuff with Google, but most of it seems to be
people who have broken their SYSVOL. Like I said, ours still seems to
be working. For us, it's another, unrelated directory that just
happens to be on a Domain Controller.
I've found MSKB 312862, but it's talking about what to do when AD is
missing FRS objects that you need. I've got FRS objects I don't need.
I've considered using ADSIEDIT to simply delete the extra stuff
under LION, but everything I've read has huge screaming warnings
saying that DFS will kill your family if you go mucking around with
that stuff, so I'm rather hesitant to do so.
I'm wondering if anyone else here knows how to get me out of this
minor mess? If not, I'll call MS PSS, but if there's an easy fix, I'd
like that. :)
advTHANKSance
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
