Discussion:
DFS, cheap DR How to...?
(too old to reply)
DaSaint
2009-02-24 19:42:06 UTC
Permalink
We currently have the following setup:
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
Isaac Oben [MCITP,MCSE]
2009-02-24 20:57:23 UTC
Permalink
Hello DaSaint,
I can't see any problem after Server1 is offline. Server2 will still
maintain the Server2\DFSRoot(folder)\DFShareA and
Server2\DFSRoot(folder)\DFShareB shares and there is no need creating a
second namespace on Server2. All you have to do is make sure users have
access to Server2 for dfs or change the priority to make Server2 the
highest.
--
Isaac Oben [MCTIP, MCSE]
Post by DaSaint
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
DaSaint
2009-02-25 16:57:01 UTC
Permalink
Isaac,

Thanks for your reply. I'm still a little in the dark, but it may be due to
our implementation. We set this up strictly for offsite replication, so
currently we don't have both folders available to users (hence, no Priority).
What I'm struggling with (my DFS knowledge is limited) is what needs to be
done on Server2, or in DFS, to make it look like \\domain.com\DFShareA still
exists?
Would I add a second namespace server pointing to the path on Server2? When
I start that process, and edit Settings, it provides me with multiple Shared
folder permission options. I don't want to change anything with permissions
since they appear to be replicated from the source.
Is there a different way to approach this? If this is the correct way, can I
simply remove the second namespace when we're done so no one accesses the
replicated share?
Isaac Oben [MCITP,MCSE]
2009-02-25 17:24:31 UTC
Permalink
Hello DaSaint,
I am assuming you have a domain based namespace and Server1 and Server2 are
both AD servers? If this correct, I will suggest you create a Fault
Tolerance on Server2 by creating the same namespace and share that exists on
server1. To do this, create an identical share on Server2 "DFShareA" and
give the exact permissions that DFShare have on Server1 to Server2. Then use
the dfsutil command to create ft on server2. To do this: at command prompt:
dfsutil.exe /addftroot /server:Server1 /share:DFShareA and hit enter. This
will create exact replica (ft) of Server1 and Server2 for DFShareA. Now you
can take server1 offline and server2 will act as \\domain.com\DFShareA.
After your DR test, if you need to take Server2 out, just remove the ft.
dfsutil.exe /remftroot /server:Server1 /share:DFShareA
I hope this helps,
--
Isaac Oben [MCTIP, MCSE]
Post by DaSaint
Isaac,
Thanks for your reply. I'm still a little in the dark, but it may be due to
our implementation. We set this up strictly for offsite replication, so
currently we don't have both folders available to users (hence, no Priority).
What I'm struggling with (my DFS knowledge is limited) is what needs to be
done on Server2, or in DFS, to make it look like \\domain.com\DFShareA still
exists?
Would I add a second namespace server pointing to the path on Server2? When
I start that process, and edit Settings, it provides me with multiple Shared
folder permission options. I don't want to change anything with permissions
since they appear to be replicated from the source.
Is there a different way to approach this? If this is the correct way, can I
simply remove the second namespace when we're done so no one accesses the
replicated share?
DaSaint
2009-02-26 21:07:03 UTC
Permalink
Thank you Isaac. I think I follow everything now, but I wanted to clarify two
things:
When I run the /addftroot, this won't try to copy all the files from
Server1, will it? I assume that a different function related to replication.
Also, assuming that a file copy will not try to take place, I should be able
to create this shortly before our test begins? My primary concern is that
staff are not accessing files on Server2 outside of the test window.
I really appreciate the responses!
Darryl
Post by Isaac Oben [MCITP,MCSE]
Hello DaSaint,
I am assuming you have a domain based namespace and Server1 and Server2 are
both AD servers? If this correct, I will suggest you create a Fault
Tolerance on Server2 by creating the same namespace and share that exists on
server1. To do this, create an identical share on Server2 "DFShareA" and
give the exact permissions that DFShare have on Server1 to Server2. Then use
dfsutil.exe /addftroot /server:Server1 /share:DFShareA and hit enter. This
will create exact replica (ft) of Server1 and Server2 for DFShareA. Now you
can take server1 offline and server2 will act as \\domain.com\DFShareA.
After your DR test, if you need to take Server2 out, just remove the ft.
dfsutil.exe /remftroot /server:Server1 /share:DFShareA
I hope this helps,
--
Isaac Oben [MCTIP, MCSE]
Post by DaSaint
Isaac,
Thanks for your reply. I'm still a little in the dark, but it may be due to
our implementation. We set this up strictly for offsite replication, so
currently we don't have both folders available to users (hence, no Priority).
What I'm struggling with (my DFS knowledge is limited) is what needs to be
done on Server2, or in DFS, to make it look like \\domain.com\DFShareA still
exists?
Would I add a second namespace server pointing to the path on Server2? When
I start that process, and edit Settings, it provides me with multiple Shared
folder permission options. I don't want to change anything with permissions
since they appear to be replicated from the source.
Is there a different way to approach this? If this is the correct way, can I
simply remove the second namespace when we're done so no one accesses the
replicated share?
Isaac Oben -MCSE, MCITP
2009-02-28 16:27:41 UTC
Permalink
Darryl,
The /addftroot will copy all the files from the specified share folder. In
this case:DFShareA. Everything on DFShareA will be copied over.

Isaac
Post by DaSaint
Thank you Isaac. I think I follow everything now, but I wanted to clarify two
When I run the /addftroot, this won't try to copy all the files from
Server1, will it? I assume that a different function related to replication.
Also, assuming that a file copy will not try to take place, I should be able
to create this shortly before our test begins? My primary concern is that
staff are not accessing files on Server2 outside of the test window.
I really appreciate the responses!
Darryl
Post by Isaac Oben [MCITP,MCSE]
Hello DaSaint,
I am assuming you have a domain based namespace and Server1 and Server2 are
both AD servers? If this correct, I will suggest you create a Fault
Tolerance on Server2 by creating the same namespace and share that exists on
server1. To do this, create an identical share on Server2 "DFShareA" and
give the exact permissions that DFShare have on Server1 to Server2. Then use
dfsutil.exe /addftroot /server:Server1 /share:DFShareA and hit enter. This
will create exact replica (ft) of Server1 and Server2 for DFShareA. Now you
can take server1 offline and server2 will act as \\domain.com\DFShareA.
After your DR test, if you need to take Server2 out, just remove the ft.
dfsutil.exe /remftroot /server:Server1 /share:DFShareA
I hope this helps,
--
Isaac Oben [MCTIP, MCSE]
Post by DaSaint
Isaac,
Thanks for your reply. I'm still a little in the dark, but it may be
due
to
our implementation. We set this up strictly for offsite replication, so
currently we don't have both folders available to users (hence, no Priority).
What I'm struggling with (my DFS knowledge is limited) is what needs to be
done on Server2, or in DFS, to make it look like \\domain.com\DFShareA still
exists?
Would I add a second namespace server pointing to the path on Server2? When
I start that process, and edit Settings, it provides me with multiple Shared
folder permission options. I don't want to change anything with permissions
since they appear to be replicated from the source.
Is there a different way to approach this? If this is the correct way,
can
I
simply remove the second namespace when we're done so no one accesses the
replicated share?
DaveMills
2009-03-01 09:49:15 UTC
Permalink
On Tue, 24 Feb 2009 14:57:23 -0600, "Isaac Oben [MCITP,MCSE]"
Post by Isaac Oben [MCITP,MCSE]
Hello DaSaint,
I can't see any problem after Server1 is offline. Server2 will still
maintain the Server2\DFSRoot(folder)\DFShareA and
Server2\DFSRoot(folder)\DFShareB shares and there is no need creating a
second namespace on Server2. All you have to do is make sure users have
access to Server2 for dfs or change the priority to make Server2 the
highest.
As you have observer in you own thread priority is not a reliable way to ensure
the client is directed only to ServerA
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
DaveMills
2009-03-01 09:47:28 UTC
Permalink
Post by DaSaint
Win 2003 R2 Domain
Namespace http://technet.microsoft.com/en-us/library/cc782417.aspx
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Do you mean that all your data is physically in the DFSShareA folder, i.e. you
has created a DFS Share and instead of creating links to other shared folders
you have actually copied the data to the DFSRoot folders. If so this is a very
bad idea. The design concept is that the DFSRoot will contain only "Links" that
point to shares (which may be on the same server as the DFSRoot). If you read
"How DFS Works" (http://technet.microsoft.com/en-us/library/cc782417.aspx) you
will find all the limitations on the number of folders supported in the DFSRoot.

If the data is stored in a linked shared folder then you should be able to
simply enable/disable the links to switch users between servers.

Example:
Share the data folders as \\serverA\Data$ and \\ServerB\Data$
Users can access data via ether share (avoiding DFS) so hide the shares by
adding "$"
Set up a DFSR replication between the two above shares.

Create a DFSRoot folder: \\domain.com\DFSRoot
Add a folder in the DFSRoot called "Data" and link it to the two above shares.
Users will now be able to access the data using the DFS path \\domain.com\data.
They will either be redirected to \\serrverA\Data$ or to \\serverB\Data$.
You then disable the link to ServerB and the users can only be directed to
\\ServerA\Data$. When you wish to switch the users simple disable the link to
\\ServerA\Data$ and enable the link to \\ServerB\Data$. Wait for all client to
switch over (takes up to 1800 seconds by default). Note that older XP and W2K
will never do this switch without a reboot.

As to one way replication. You are assuming that the users will not try to
change the data when you have the using ServerB. You would need to set the share
permission on \\ServerB\Data$ to ensure this is the case. Users will not do this
reliable otherwise. But why stop them? They can continue to access the data on
serverB updating it as needed. When you eventually switch them back to ServerA
the data will be up to date if you had two way replication in place.

Watch out for Quotas though as two way replication can run into serious problems
if quotas are in use.
Post by DaSaint
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
DaSaint
2009-03-03 13:30:01 UTC
Permalink
Gentlemen,
To clarify (I hope):
Fileserver1 has a volume with a folder on it named DFSRoot. Below that is a
shared folder (DFShareA) where all our regional files are located. There is a
namespace setup for this shared folder named Domain.com\DFShareA.
Fileserver2 also has a volume on it with a folder named DFSRoot. Below that
is a shared folder (DFShareB) where a different region's files are located.
There is a namespace setup for this shared folder named Domain.com\DFShareB.
Clients connect to needed resources by mapping to \\domain.com\DFShareaA (or
B)\folder\etc.
There are 2 replication groups setup: Home-Remote replicates DFShareA files
from Server1 to a folder named DFShareA on Server2. Remote-Home replicates
DFShareB files from Server2 to a folder named DFShareB on Server1.
So I have a complete copy of each of the shared folders on the opposite
server, including all permissions except for the root. The copy(s) are not
currently shared.
Looking at the replication console, my replicated folders are listed as Not
Published.
Is the solution as simple as publishing these folders?
Creating the FTRoot is not an option as we have about 700GB of data that
would have to be re-replicated to a server that already has it.
My short-term goal is to have a place for staff to connect (and not make
changes) to data on Server2. My longer term goal is to have files available
for changes in the event of an actual disaster, and update Server1 with
changes when it is back online.
Post by DaSaint
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
Isaac Oben [MCITP,MCSE]
2009-03-03 22:18:41 UTC
Permalink
DaSaint,
Thank you for giving these detail description about your environment. I have
setup something similar as yours in my test lab and this is the suggestion I
have for you.

On the \\domain.com\DFShareB on Server2 add a link name DFShareA and path
should be \\Server2\DFShareA (This should be the replicated content (copy)
from Server1\DFShareA).
Make sure replication is current from Server1\DFShareA to Server2\DFShareA.
and then shutdwon Server1 for your DR test.Once server1 is offline, users
can access by: \\domain.com\DFShareB (this will list all files and folders
including DFShareA) or they can access direct by
\\domain.com\DFShareB\DFShareA.

Publishing these folders is not a bad idea, all it will enable network users
to be able to search for shares more easily.

For the long run, though, I will suggest you create a fault tolerrance. have
a single domain namespace say \\domain.com\DFShare on both servers and then
include the DFShareA and DFShareB on this. That way if any of the servers is
down, client can still access any othe shares.
Or
Do the samething above on Server1 as well with a two-way replication
On the \\domain.com\DFShareA on Server1 add a link name DFShareB and path
should be \\Server2\DFShareB (This should be the replicated content (copy)
from Server2\DFShareB).
--
Isaac Oben [MCTIP, MCSE]
Post by DaSaint
Gentlemen,
Fileserver1 has a volume with a folder on it named DFSRoot. Below that is a
shared folder (DFShareA) where all our regional files are located. There is a
namespace setup for this shared folder named Domain.com\DFShareA.
Fileserver2 also has a volume on it with a folder named DFSRoot. Below that
is a shared folder (DFShareB) where a different region's files are located.
There is a namespace setup for this shared folder named
Domain.com\DFShareB.
Clients connect to needed resources by mapping to \\domain.com\DFShareaA (or
B)\folder\etc.
There are 2 replication groups setup: Home-Remote replicates DFShareA files
from Server1 to a folder named DFShareA on Server2. Remote-Home replicates
DFShareB files from Server2 to a folder named DFShareB on Server1.
So I have a complete copy of each of the shared folders on the opposite
server, including all permissions except for the root. The copy(s) are not
currently shared.
Looking at the replication console, my replicated folders are listed as Not
Published.
Is the solution as simple as publishing these folders?
Creating the FTRoot is not an option as we have about 700GB of data that
would have to be re-replicated to a server that already has it.
My short-term goal is to have a place for staff to connect (and not make
changes) to data on Server2. My longer term goal is to have files available
for changes in the event of an actual disaster, and update Server1 with
changes when it is back online.
Post by DaSaint
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
DaveMills
2009-03-03 23:00:30 UTC
Permalink
Sorry DaSaint I am a little confused so I will defer to Isaac who seems to
understand what you are saying.
Post by DaSaint
Gentlemen,
Fileserver1 has a volume with a folder on it named DFSRoot. Below that is a
shared folder (DFShareA) where all our regional files are located. There is a
namespace setup for this shared folder named Domain.com\DFShareA.
Fileserver2 also has a volume on it with a folder named DFSRoot. Below that
is a shared folder (DFShareB) where a different region's files are located.
There is a namespace setup for this shared folder named Domain.com\DFShareB.
Clients connect to needed resources by mapping to \\domain.com\DFShareaA (or
B)\folder\etc.
There are 2 replication groups setup: Home-Remote replicates DFShareA files
from Server1 to a folder named DFShareA on Server2. Remote-Home replicates
DFShareB files from Server2 to a folder named DFShareB on Server1.
So I have a complete copy of each of the shared folders on the opposite
server, including all permissions except for the root. The copy(s) are not
currently shared.
Looking at the replication console, my replicated folders are listed as Not
Published.
Is the solution as simple as publishing these folders?
Creating the FTRoot is not an option as we have about 700GB of data that
would have to be re-replicated to a server that already has it.
My short-term goal is to have a place for staff to connect (and not make
changes) to data on Server2. My longer term goal is to have files available
for changes in the event of an actual disaster, and update Server1 with
changes when it is back online.
Post by DaSaint
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
DaSaint
2009-03-04 12:16:02 UTC
Permalink
Thanks for all the input. I know this is a confusing setup, but this is the
road we were led down by the consultant that came in to get us going.
I'm hoping Isaac's last post works out for us.
Darryl
Post by DaveMills
Sorry DaSaint I am a little confused so I will defer to Isaac who seems to
understand what you are saying.
Post by DaSaint
Gentlemen,
Fileserver1 has a volume with a folder on it named DFSRoot. Below that is a
shared folder (DFShareA) where all our regional files are located. There is a
namespace setup for this shared folder named Domain.com\DFShareA.
Fileserver2 also has a volume on it with a folder named DFSRoot. Below that
is a shared folder (DFShareB) where a different region's files are located.
There is a namespace setup for this shared folder named Domain.com\DFShareB.
Clients connect to needed resources by mapping to \\domain.com\DFShareaA (or
B)\folder\etc.
There are 2 replication groups setup: Home-Remote replicates DFShareA files
from Server1 to a folder named DFShareA on Server2. Remote-Home replicates
DFShareB files from Server2 to a folder named DFShareB on Server1.
So I have a complete copy of each of the shared folders on the opposite
server, including all permissions except for the root. The copy(s) are not
currently shared.
Looking at the replication console, my replicated folders are listed as Not
Published.
Is the solution as simple as publishing these folders?
Creating the FTRoot is not an option as we have about 700GB of data that
would have to be re-replicated to a server that already has it.
My short-term goal is to have a place for staff to connect (and not make
changes) to data on Server2. My longer term goal is to have files available
for changes in the event of an actual disaster, and update Server1 with
changes when it is back online.
Post by DaSaint
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
DaveMills
2009-03-10 12:22:25 UTC
Permalink
Post by DaSaint
Thanks for all the input. I know this is a confusing setup, but this is the
road we were led down by the consultant that came in to get us going.
I'm hoping Isaac's last post works out for us.
Darryl
Well if the consultant has put your data in the DFSRoot folder you need a new
consultant.
Post by DaSaint
Post by DaveMills
Sorry DaSaint I am a little confused so I will defer to Isaac who seems to
understand what you are saying.
Post by DaSaint
Gentlemen,
Fileserver1 has a volume with a folder on it named DFSRoot. Below that is a
shared folder (DFShareA) where all our regional files are located. There is a
namespace setup for this shared folder named Domain.com\DFShareA.
Fileserver2 also has a volume on it with a folder named DFSRoot. Below that
is a shared folder (DFShareB) where a different region's files are located.
There is a namespace setup for this shared folder named Domain.com\DFShareB.
Clients connect to needed resources by mapping to \\domain.com\DFShareaA (or
B)\folder\etc.
There are 2 replication groups setup: Home-Remote replicates DFShareA files
from Server1 to a folder named DFShareA on Server2. Remote-Home replicates
DFShareB files from Server2 to a folder named DFShareB on Server1.
So I have a complete copy of each of the shared folders on the opposite
server, including all permissions except for the root. The copy(s) are not
currently shared.
Looking at the replication console, my replicated folders are listed as Not
Published.
Is the solution as simple as publishing these folders?
Creating the FTRoot is not an option as we have about 700GB of data that
would have to be re-replicated to a server that already has it.
My short-term goal is to have a place for staff to connect (and not make
changes) to data on Server2. My longer term goal is to have files available
for changes in the event of an actual disaster, and update Server1 with
changes when it is back online.
Post by DaSaint
Win 2003 R2 Domain
Namespace \\domain.com\DFShareA
Server1\DFSRoot(folder)\DFShareA replicates to
Server2\DFSRoot(folder)\DFShareA.
Namespace \\domain.com\DFShareB
Server2\DFSRoot(folder)\DFShareB replicates to
Server1\DFSRoot(folder)\DFShareB.
Only the source share is available to the end-user; we are a single AD site,
multiple locations. The intent was that if Server1 went down, we could
manually changeover to Server2 with minimal effort.
So now we have a DR test scheduled, and we're scratching our heads saying
"How do we do this?"
We want to take down Server1 and have staff connect to DFShareA on Server2.
They would not be changing any data for the test, so the one-way replication
should be OK(?)
If I create a second namespace to Server2\DFSRoot(folder)\DFShareA, will it
alter the contents/permissions of the files there? Will it then be
potentially used for production work after the test?
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
Continue reading on narkive:
Loading...