You could use ldifde to export an importable version of the offending object prior to deleting it.
That's what I'd do followed by whacking it in AD and bouncing the NTFRS service. Thanks, Brian Desmond [email protected] c - 312.731.3132 -----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Monday, August 24, 2009 10:40 PM To: NT System Admin Issues Subject: FRS won't stop trying to replicate a folder 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
