Microsoft's official enterprise support blog for AD DS and more
Hello folks, Ned here again. Recently I was asked to provide a technical assessment of the risks of continuing to use the File Replication Service (FRS) and the benefits of migrating to DFSR, all regarding SYSVOL on domain controllers. I thought I’d find a decent set of documentation on TechNet, polish it up and send it along – I was wrong; I had to spend several hours coming up with a complete list.
Now you can reap the benefits. Hopefully this helps you convince yourself or your management that the time has come to cut the cord on FRS, especially if you have already deployed your Windows Server 2008 DC’s.
I sure hope you like bullet points!
Here’s a different way of looking at it, as I know executives love their matrices:
Description
FRS
DFSR
Reliable, fast, scalable, and continually improving
No
Yes
Is deader than fried chicken
Now go migrate. For most customers it will be a few hours of work. Your manager may not even have time to buy you lunch on a Saturday.
Stay tuned for another article about the benefits of using FRS. Its title will be “the shortest blog post ever written” and will contain only a picture of my dogs eating their toys. Here’s a preview.
A special thanks to Mahesh from the DFSR product team for his timely review and contributions to this write up. You rock dude.
Until next time,
Ned “nom nom nom” Pyle
How can we achieve "Staging compression can be controlled on a per-file type basis?"
I got it whey you say "Staging compression can be controlled on a per-file type basis" you are referring to your kb 951003
(msDFSR-DefaultCompressionExclusionFilter )
I did not catch the per-file TYPE basis and interpreted as per-file basis.
Thanks and Regards.
WOW..This is Excellent information...Great Work
I'm pretty shocked that 9 months after server 2008 R2 release that MS hasn't released the SCOM MP for file replication. Whatever happened to MS shipping SCOM MPs with the product or within 60 days of launch?
Product teams don't seem to put a priority on creating MPs in a timely fashion for customers. I'm seriously reconsidering the enterprise use of SCOM because product groups like this take forever to release native MPs.
Get with the program and provide timely MPs or don't release the product at all.
To clarify - what do you mean by "don't release the product at all?" Not releasing MP's at all, not releasing SCOM at all? That sounds kind of self defeating - maybe I am misunderstanding.
I agree that MP's are often delayed. The 2008 R2 file MP will actually be out pretty soon. There are a number of factors for these delays:
1. MP's are created by the same team coding the real component, not a dedicated MP team. This means that the limited team resources are used to create the component, and cannot be used to work on the MP until after release. So immediate release or 60 days are not feasible timelines logistically (heck, 60 days would be the inside of testing).
2. Most customers do not immediately deploy a new server OS within 60 days of RTW. Most not within one year actually, especially in the SCOM enterprise space. So most customers don't care or complain, and that is the bottom line that drives the money and effort. It would cost a lot more to get MP's out the door faster, so if most customers don't mind waiting, we don't mind saving that dough.
3. The way to vote here is with your feet - if you are finding 3rd parties that compete with SCOM and release MP's at the same time as Windows OS releases or within 60 days, tell your MS TAM/Sales/Partners/other channels that you are finding better service elsewhere. Purchase that product and move forward. Threats don't work, but if you move off SCOM people here will certainly notice!
Thanks for the feedback,
Ned