DFS Migration to another environment

I just have an interesting problem: In a branch office scenario with a
centralized data center (DC) we have a DFS running, where all file data will
be replicated to the DC for backup purposes. Now we need to exclude some
bbranch offices (soled) to a new company and also to a new network. They will
still work in the same manner like before.
We create the new file system and the DFS. But how I can migrate the data now?
Option1 : Perform a migration in the DC and replicate the data back. Because
we have up to 3.5 TB in the branches and only bandwidth for replication by ~2
MBit (QOS), this solution is not really feasible.
Option 2: Migrate the data locally, so that the user can still work with the
data and replicate the data back to the DC. This seems to be a little bit
better for the business continuity, ut we still have the replication issue to
transfer TB of data over the WAN (location are spread up to 2.500 km outside
from the DC).

The best option should be to add the data in the root (DC) and branches in
prallel and re-sync both sides. But this seems not to work, every side claims
the data complete and so it will replicate twice the whole content - even
worst. Is there any option (like pre-staging e.g.) what can be used for a
scenario like this? If not, I need to look for a complete other way (may be
travelling with a server sround, but we have ~60 branches in focus :-( ).

J.

>I just have an interesting problem: In a branch office scenario with a
> centralized data center (DC) we have a DFS running, where all file data
> will
> be replicated to the DC for backup purposes. Now we need to exclude some
> bbranch offices (soled) to a new company and also to a new network. They
> will
> still work in the same manner like before.

Does this mean that those "excluded" servers sold to a new company are going
to be in a new donain or on a different subnet?


> The best option should be to add the data in the root (DC) and branches in
> prallel and re-sync both sides. But this seems not to work, every side
> claims
> the data complete and so it will replicate twice the whole content - even
> worst. Is there any option (like pre-staging e.g.) what can be used for a
> scenario like this? If not, I need to look for a complete other way (may
> be
> travelling with a server sround, but we have ~60 branches in focus :-( ).

To prestage the data you can either restore from backups or use a robocopy
script to prestage the data on the hub server. Setup the replication group
so the branch office is the primary and only the difference will be
replicated to the hub server.


hth
DDS


"Berlin142" <> wrote in message
news:1D66EF34-2CE4-4497-BB43-...
>I just have an interesting problem: In a branch office scenario with a
> centralized data center (DC) we have a DFS running, where all file data
> will
> be replicated to the DC for backup purposes. Now we need to exclude some
> bbranch offices (soled) to a new company and also to a new network. They
> will
> still work in the same manner like before.
> We create the new file system and the DFS. But how I can migrate the data
> now?
> Option1 : Perform a migration in the DC and replicate the data back.
> Because
> we have up to 3.5 TB in the branches and only bandwidth for replication by
> ~2
> MBit (QOS), this solution is not really feasible.
> Option 2: Migrate the data locally, so that the user can still work with
> the
> data and replicate the data back to the DC. This seems to be a little bit
> better for the business continuity, ut we still have the replication issue
> to
> transfer TB of data over the WAN (location are spread up to 2.500 km
> outside
> from the DC).
>
> The best option should be to add the data in the root (DC) and branches in
> prallel and re-sync both sides. But this seems not to work, every side
> claims
> the data complete and so it will replicate twice the whole content - even
> worst. Is there any option (like pre-staging e.g.) what can be used for a
> scenario like this? If not, I need to look for a complete other way (may
> be
> travelling with a server sround, but we have ~60 branches in focus :-( ).
>
> J.