Windows Server


FRS usage scenarios    



FRS usage scenarios




FRS usage scenarios


FRS usage scenarios

Number  : SOX031031700031

Created  : 10/31/2003

Region  : US


TITLE: FRS usage scenarios

Problem Windows 2000 Server

ID: SOX031031700031 CRT: Oct 31 2003 MOD: Oct 31 2003


Problem Description

FRS is not well suited for all replication needs.




The following information is from the Ultrasound Help file:


Appropriate Scenarios for Using FRS


FRS works well in the following scenarios.

When the data is read-only or changes infrequently

Because changes occur infrequently, the data is usually consistent. In addition,

FRS has less data to replicate, so network bandwidth is not heavily affected.

When the sites are geographically dispersed and consistency is not an issue

Geographically dispersed sites might have slower bandwidth connections, but if your

organization does not require the data in those sites to always be consistent with

each other, you can configure replication in those sites on a schedule that make

sense for your organization. For example, if your organization has sites in Los

Angeles and Zimbabwe, you can place one or more replicas of the data in servers in

those sites and schedule replication to occur at night or during periods of low

bandwidth use. Because in this scenario replication could take hours or days to

update every member, the delay must be acceptable to your organization.

When each file is changed by only one person from one location

Replication conflicts rarely occur if only a single user changes a given file from

a single location. Some common scenarios for single authorship are redirected My

Documents folders and other home directories. Conversely, if users roam between

sites, replication latency could cause the file to be temporarily inconsistent

between sites.

When replication takes place among a small number of servers in the same site

Replication latency is reduced by frequently replicating data using high-speed

connections. As a result, data tends to be more consistent.

As a file server fail over configuration, if some data inconsistency between

servers can be tolerated

It is possible to use DFS and FRS to replicate read-write user data so that if one

file server fails, another can take its place. However, before deploying such a

scenario, the following factors must be taken into account to determine if DFS and

FRS are appropriate in the context of the planned scenario.

The issues to consider are:

DFS does not guarantee which file server a client will be referred to; there are

clear rules around how DFS load balancing and site selection work, but depending on

transient network issues, a DFS client might attach to any candidate server that

advertised the file share used by an enabled DFS link target.

The FRS last-writer-wins conflict resolution model means that if two client

computers (with either the same or different users logged in) access a replicated

DFS link and are directed to different link targets, then these two clients can

make changes to the two copies of the same file without being aware of each others’

locks on the files. One of these two clients will silently lose the changes they


FRS can only replicate file changes after the file is closed.

FRS replicates whole files each time; if a file is only modified in one small area,

then FRS still transmits the complete file. This is acceptable for many files, but,

depending on bandwidth, may not be appropriate for files such as .PST files, which

are large but typically undergo change in small areas of the file.

In some scenarios, this can still be acceptable. The key question is how likely it

is that conflicting edits may be made by two different client computers to the same

file before the data has had time to replicate.

Another concept is to consider a mechanism (such as scripts) whereby only one of

the link targets raises its shared folder at a time. In this case, DFS can only

ever successfully route a client computer to one file server, and so such write

conflicts cannot occur. In this case, failover is provided by deciding one other

member of the replication set can raise its file share, and the failing member is

disconnected and has its file share lowered.

The final issue to consider in this scenario is bandwidth usage. Because users are

updating files, there is no clear bound to how much replication traffic they may

generate, and this should be considered carefully in replica sets that are intended

to span a wide area network (WAN).


Inappropriate Scenarios for Using FRS


Replication should not be used in the following scenarios.

In organizations with no operations group or dedicated administrators

Organizations that do not have the staff or the time to monitor FRS event logs on

each replica member should not implement FRS. Organizations must also have

well-defined procedures in place to prevent the accidental or unintentional

deletion of data in the replica set, because deleting a file or folder from one

replica member causes the file or folder (and its contents) to be deleted from all

replica members. In addition, if a folder is moved out of the replica tree, FRS

deletes the folder and its contents on the remaining replica members.


In Windows Server 2003, to avoid having to restore the files or folders from

backup, you can enable shadow copies on some of the replica members so that you can

easily restore a file or folder that was accidentally deleted.

In organizations that do not update virus signatures or closely manage folder


A virus in FRS-replicated content can spread rapidly to replica members and to

clients that access the replicated data. Viruses are especially damaging in

environments where the Everyone group has share permissions or NTFS permissions to

modify content. To prevent the spread of viruses, it is essential that replica

members have FRS-compatible, up-to-date virus scanners installed on the servers and

on clients that access replicated data.

For information about running antivirus software on SYSVOL, see article 822158,

"Virus Scanning on a Domain Controller." For information about antivirus software

that is compatible with FRS, see 815263, "Antivirus, Backup, and Disk Optimization

Programs That Are Compatible with the File Replication Service."

When the rate of change exceeds what FRS can replicate

If you plan to schedule replication to occur during a specified replication window,

verify that FRS can replicate all the changed files within the window. Replication

throughput is determined by a number of factors:

The number and size of changed files

The speed of the disk subsystem

The speed of the network

Whether you have optimized the servers by placing the replica tree, the staging

directory, and the FRS data on separate disks.

Each organization will have different FRS throughput rates, depending on these

factors. In addition, if your data compresses extremely well, your file throughput

will be higher. To determine the replication rate, perform testing in a lab

environment that resembles your production environment.

If the amount of data changes exceeds what FRS can replicate in a given period of

time, you need to change one of these factors, such as increasing the speed of the

disk subsystem (number of disks, mechanical speed, or disk cache) or network. If no

change is possible, FRS is not recommended for your organization.

In organizations that always use clustered file servers

Some organizations use clustered file servers regardless of whether the server

contains business-critical data. Although it might seem that storing FRS-replicated

content on the shared cluster storage of a clustered file server would increase the

availability of the data even more, combining clustering and FRS is not recommended

because you then have the weaker guarantees of asynchronous file replication, but

the more stringent configuration requirements of a cluster. In addition, Windows

Server 2003 and Windows 2000 Server do not support configuring FRS to replicate

data on cluster storage.

In organizations that use Remote Storage

Remote Storage is a feature that automatically copies infrequently used files on

local volumes to a library of magnetic tapes or magneto-optical disks.

Organizations that use Remote Storage must not use FRS on the same volume.

Specifically, do not perform any of the following tasks:

Do not create a replica set on a volume that is managed by Remote Storage.

Do not add a volume that contains folders that are part of an FRS replica set to

Remote Storage.

If you use Remote Storage for volumes that contain FRS replica sets, backup tapes

might be damaged or destroyed if FRS recalls a large number of files from Remote

Storage. The damage occurs because FRS does not recall files in media order. As a

result, files are extracted randomly, and the process can take days to complete and

might damage or destroy the tape in the process. Random extraction from

magneto-optical disks can also be extremely time consuming.

When locks by users or processes prevent updates to files and folders

FRS does not replicate locked files or folders to other replica members, nor does

FRS update a file on a replica member if the local file is open. If users or

processes frequently leave files open for extended periods, consider using

clustering instead of FRS.

FRS does not replicate files until the file has been closed for 3 seconds. If files

are changed but are then held open (or reopened) exclusively, before FRS is able to

create a staging file of that change, then FRS cannot replicate the file until it

has been closed again.

When the data to be replicated is on mounted drives

If a mounted drive exists in a replica tree, FRS does not replicate the data in the

mounted drive.

When the data to be replicated is encrypted by using EFS

FRS does not replicate files encrypted by using EFS, nor does FRS warn you that

EFS-encrypted files are present in the replica set.

When the FRS jet database, FRS logs, and staging directory are stored on volumes

where NTFS disk quotas are enabled

If you plan to store a replica set on a volume where disk quotas are enabled, you

must move the staging directory, FRS jet database, and FRS logs to a volume where disk quotas are disabled.


More FRS info can be found at:








No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3099

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011