DFS driving me bananas

[guinnessman]

I have installed the DFS that now operates on two DCs.
DFS points to a number of shared files on server1. Each share has an identical replica partner which has been linked and set to automatic replication with an identiacl shared folder on server 2.
The problem is that some clients using Sage Accounts production are not seeing all the newly created files. DFS is creating a new subfolder on the DFS relica (on server2) called NTFRS pre-existing **** and this is where the new files are being replicted to instead of in the original shared folder on server2.
The mapped drives on all clients point to \\domain.com\all data.

The rsult being that some clients are being directed to server2 where the folder only has some original data and new files etc are created in this new NTFRS folder.

It's driving me bananas.

Can anyone tell me why DFS is crating these new folders and why some clients seem to be now accessing the

Remember, it's all just ones and zeros!

 

[1UnixNewbie]

I seem to be having the same issue. Only it is happening spuratically, more recently last night when i needed to reboot our 2 domain controllers, which were done 1 at a time, and a ton of our users now have files saved in the ntfrs_preeixisting folder for that directory. What the heck is the deal here. I dug through that folder and noticed there are other files in there to...

Friggin nightmare!!!

Anybody have suggestions or thoughts???

 

[ReddLefty]

This is MY opinion about DFS, because I never got what you guys are trying to do, to work properly.

I've had both those problems and then some... I finally gave up on trying to use 2 servers at time and simply use the replication to keep a backup server up to date. I turned it into a one-way replication, even if it is still enabled both ways.

The main use of DFS is to synchronize simple files between server across WAN's. If your trying to split your workload, your barking up the wrong tree. Even if MS says it's possible, there are too many things possible on a file/print server for it to like mirroring, which is what you are probably seeking.

If you use applications like Access or accounting softwares like SAGE (I think it's accouting) then DFS cannot replicate the files properly because it can't replicate open files... If you have one user in Server1 and the other in Server2, your gonna get crashes and indexing problems because they won't be synchronzied.

I solved all my problems by not using the dfs in the logon scripts and keeping people mapped onto the same server. That server then replicates to a backup server. The workload is heavy on a network card also, so I added fiber-NIC between the two so they would replicate quietly between themselves and not affect the regular traffic on the LAN.

If your trying to offload your servers, then don't let DFS map your drives, do it the old way, and force them to be mapped at a specific spot. Send SAGE to SERVER1 and all the other stuff to SERVER2 and setup the replication accordingly (Sage will replicate from server1 to server2 and the other stuff from server2 to server1). If one of the server crashes, it only takes 1 minute to change the scripts and tell everyone to log back in.

More input is welcome, i'm just telling you my story, it doesn't mean someone didn't find a better way, but DFS is not all it's built-up to be.



"In space, nobody can hear you click..."

 

[guinnessman]

I gave up on the DFS automatic replication, its a non-runner. No matter what I tried, it just wouldn't work ... well not effectively anyway. I've got all the users using static mapped drives. This doesn't provide an automatic failover solution which was my original intention, but I've written a batch file that copies everything across to Server2 at night through a Gigabit NIC that provides a dedicated connection between the two DCs.
The client is happy anyway ... Yaaayyy!!

Thanks for your input guys. I think the DFS implementation on Windows Server 2003 has been significantly improved but I think I'll let someone else try it first :~)

Remember, it's all just ones and zeros!

 

[mlichstein]

FRS (which is what does the actual replication) is doing exactly what it should do. If you set up replication between two servers that already have a copy of the files, one of those servers will move the files to the pre-existing folder.

The server that moves everything to the pre-existing folder will then replicate all the data in the share from the other server.

This sounds painful, and it is. If you pre-stage the directories beforehand, you can avoid this. FRS will move everything into the pre-existing folder, but then it will compare the data and then move them back into the proper location.

See KB article 266679

http://support.microsoft.com/default.aspx?scid=kb;EN-US;266679

 

[GlenJohnson]

The client is happy anyway ... Yaaayyy!!

That's the bottom line.

Glen A. Johnson
If you're from Northern Illinois/Southern Wisconsin feel free to join the Tek-Tips in Chicago, Illinois Forum.

TTinChicago
Johnson Computers

 

[guinnessman]

Thanks for your input mlichstein, and beleive it or not, I am actually well aware (since starting this DFS endeavour) of the FRS process and the reasoning for the pre-stage folder setup by FRS and if it did just as it was supposed to do, I would have merely needed to wait until all folder contents were matching across the servers (Server1 and Server 2). The problem was that FRS initiated the replication process and created the relevant IDTable and so started the pre-staging process (great)... but once complete, it did not then move the files/folders back into the required target folders on the replica partner, but instead just left the files in the NTFRS pre-existing folders.
This meant that there were some older files in the target folder and all the relevant updated files were unaccessible because they were in the NTFRS pre-existing folders.
Some of the client's applications such as Tempus Pro and Sage, which use static mappings, were mapped to a domain-based DFS share instead of a specific server share (i.e. mapped to \\abc.com\DFS_Share as opposed to being mapped to \\server1\Share) But when network clients used these applications, users were sometimes directed to Server1 with all up to date files and sometimes directed to Server2 with out of date files.
I was able to give the DFS and FRS a whole weekend using a dedicated gigabit connection to replicate fully but alas, all I had was a lot of target folders with NTFRS pre-existing folders in them and a lot of out of date files exterior to the NTFRS pre-existing folders.
This meant that when for example a user (that DFS directed to Server1) setup a new account on the Sage software, then another user (that DFS directed to Server2) came along to edit the account, the account was non-existent.

Remember, it's all just ones and zeros!

 

[mlichstein]

Moving the files into the preexisting directory ususally only takes a few seconds, and then the files will start replicating from the other server into the target folder.

If the files moved into the pre-existing folder and then nothing happened, then it sounds like there is a problem preventing replication from happening, possibly a full staging directory.

Check the file replication logs in event viewer. What kind of warnings if any do you see around the time you tried to set this up?

 

[guinnessman]

No warnings or errors, just information events > FRS initiated blah blah blah, i can't remember the exact phrasing but there were no indications of any specific faults.

Remember, it's all just ones and zeros!

 

[ReddLefty]

It takes 1 day for my replication to start in my Users Home folder... and 2 days for it to complete the replication. The size is about 35Gigs and has a Fiber Gigabit network card between each server, just for replication.

In other words, it sometimes seems like DFS is not working, but it just might be.

For the staging area, the default limit for the staging area is 600M. It will stall and give you a message if it gets filled up, but it's no longer supposed to stop the replication as of service pack 4 (I think.. maybe SP3)



"In space, nobody can hear you click..."

 

[aftertaf]

With DFS, i'm as stuck as i can be....
however, its supposed to be simple.

can Roles enter into the mess i;e; PDC, etc should be on a certain DC for it to work??

i have 2 DCs at work.
DC1 for a while, DC2 installed and dcpromo-ed a month ago. AD replicates fine....

But when i want to create a fault tolerant filesystem, nyet!

what i have tried:
1. Create DFS Domain root, hosted on DC1 (tried since on DC2, same non show)
2. Create links pointing to existing shares on DC1 (fileserver), with data (some, a few meg, another 6Giga...)
3. at this point DFS can be mapped and accessed....
4. Create shared folders on DC2, create replica links pointing to shares.
5. SHared folders on DC2 contain nothing at all.... even after 48hours)

i get nice error messages (ntfrs 13539): The File Replication Service cannot replicate c:\data\docs because the pathname of the replicated directory is not the fully qualified pathname of an existing, accessible local directory.

penelope pitstop stylee . . . 'Heeeeyyyeuuuullpppppp'

 

[guinnessman]

With just two DCs it doesn't really matter which one hosts ths DFS root. That error looks like an erroneous path listing that you've configured for the replica partner. Have you used a UNC path for the replica partner?

Remember, it's all just ones and zeros!

 

[technome]

Anyone with enough resources, NSI's Double-take is a great replication program. Does byte level replication, a full replication of 100 gig takes about 2 hours initially, from there on it just replicates change to files, uses little server CPU power.

 

[aftertaf]

guinnessman:
I use the path \\controleur\ShareName$ (tried without hiddendhare too!!! no joy).. so yes, its UNC

maybe the folders shouldn't be on the DCs involved in DFS replication......
the DFS MMC on my XP shows the replica partner link's status as Not Eligible (Share and NTFS permissions are ok)

stuck !

 

[guinnessman]

As far as I remember, you cannot use administrative shares in a DFS tree, even for replica partners. Try simply sharing the required folders.

Remember, it's all just ones and zeros!

 

[aftertaf]

tried before without the $ ..., still no joy.

Have recreated the shares... and have the message :
The File Replication Service is having trouble enabling replication from DC1 to DC2 for e:\fajd;
with 3 poss. reasons...
1. frs cannot resolve the dns name DC1 from DC2 (both have dns server installed, are Domain COntrollers and the zone is AD integrated)

2. frs service has not started on DC1 (AD replication works fine)

3. AD Topology has not been replicated to all the DCs . . .
(maybe, but once replicated, nuthin happens....!!!!!)

 

[guinnessman]

This guy's advice is starting to look good eh?
technome (IS/IT--Manageme) Jun 24, 2004
Anyone with enough resources, NSI's Double-take is a great replication program. Does byte level replication, a full replication of 100 gig takes about 2 hours initially, from there on it just replicates change to files, uses little server CPU power.

It seems you're at the same stage that I was at. I then gave up on DFS and resorted to plain old ststic mappings.

Remember, it's all just ones and zeros!

 

[aftertaf]

I have a breakthrough!!!!!!

original scenario: DC1 and DC2, AD replication works ok...
DFS not happening

-introduce member server SQL1 to the scene
-do a little net start ntfrs & dfs,
-setup 1 dfs root on DC1, 1 on DC2,
-add new link in each dfs root, pointing to respective local share
-set up SQL1 as replication partner for each dfs share...

-the share corresponding to DC2 replicates, the DC1 share does not, and fills up the ole event log

-conclusion: DC1 is buggy!

got the SOB to work, though! hehe

 

[aftertaf]

thru Ultrasound, also found out that when i try and fail with dfs on DC1, the sysvol replication takes a kick in the teeth too... (i.e. stops replicating)
error being 'The replica set was not defined in the FRS sets table.'

Nice.....

 

[guinnessman]

Well done on getting it working!

Remember, it's all just ones and zeros!