Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm not very familiar with how DFS works, and since someone else administers the servers in question I don't know what the DFS setup looks like. I'm just wondering if something is possible.

Basically we have 3 servers setup as a replication group with 1 folder, that folder being the root of a .NET webapp setup in IIS. When we deploy changes to the application we do so to one server, Server #1, and allow DFS to propagate the changes across the group to the other two servers. There is a lot of odd behavior with the environment after deployments, where the application is taking a lot of time to come back up, but nothing in the IIS logs indicate that the app pool cycling is the part that's taking a long time. I'm thinking it may be due to odd DFS Replication behavior so I requested the admin provide me with a DFSR Health Report and Propagation Report. The Propagation report indicates quick replication, <1 sec for everything.

The Health report shows 1 error on 1 server: Due to ongoing sharing violations, DFS Replication cannot replicate files in the replicated folders listed above. This problem is affecting 114 files in 1 replicated folders. Event ID: 4302

The MS KB here: http://support.microsoft.com/kb/968429 says the 4302 event is for errors during the "Receiving" of files, which is what worries me since this error is happening on Server #1 which is what should be sending the files to the other two servers.

Is it possible that DFSR is attempting to replicate files BACK to the source server after getting one of the other two servers in sync and getting permission denied because replication to the 3rd server is still ongoing? Or is there something else I can look for in the logs to see how long replication is actually taking between the servers to try to get an accurate timeline of what happens between the end of MSDeploy and the application being available again?

share|improve this question

1 Answer 1

DFS may replicate back to the source server if the files were changes on one of the other member servers. Remember that even though DFS has a primary server that server is only used for the initial replica set to be copied and distributed to other new member servers. After that yes, files can be replicated back to the host machine.

A good possibility might be any log files or data files that are stored in your App_Data directory could be getting sync'd up to all of the other servers in the replication group.

In general DFS is not the recommended method to deploy updates and application changes to multiple web servers. You might want to have a look into the Microsoft Web Farm Framework which does a much better job managing replication and deployment of application files and other server related settings. It actually does more than DFS is capable of doing in that sense.

share|improve this answer
    
The files that are in the list in the report are mostly static image resources. Some are RequestReduce generated CSS files...one or two DLLs, but the majority is PNGs. I'd highly doubt they're even changed during the deployment. I suppose I can check updated times on some of the files. In theory the deployment is the only thing that is capable of touching these files, and it only deploys to the one server. –  Sloloem Aug 6 '12 at 17:18
    
Yea, regardless it is possible for files to get pushed back. You might also want to look into DFSUtils if thats still arround I remember that being helpful: weblogs.asp.net/owscott/archive/2006/06/07/… –  Brent Pabst Aug 6 '12 at 17:20
    
The other potential problem is your AppPool is being told to recycle every time a new file arrives or is updated in your application directory. In other words DLL file 1 arrives, app pool recycles, while it does DLL 2 arrives which triggers another recycle. That could be causing some issues. –  Brent Pabst Aug 6 '12 at 17:28
    
Interesting. I tried to remove the explicit recycle step from our deployment scripts but it didn't change anything. Do you think if I stopped the app pool, deployed the new package then started the app pool again at the very very end of deployment, I might be able to avoid the issue somewhat? –  Sloloem Aug 8 '12 at 14:53
    
Possibly but I'm not sure to be honest. Hard to say at this point without seeing the environment. Either way figuring our DFS issues is usually fun regardless. –  Brent Pabst Aug 8 '12 at 15:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.