Single site domain root DFS question

Discussion:

(too old to reply)

Newell White

2006-05-02 15:25:02 UTC

Having at last added a 2nd DC to our domain to get a fault tolerant network
(25 LAN workstations, 10 VPN clients), I now want to make our database more
robust.

At present it is a single share of folders on the drive of SERVER1.
If I make it a domain root DFS, and set up replication with a copy of the
folders on SERVER2, can I force DFS to point all referrals to SERVER1 if that
is up, otherwise to SERVER2?
This way I achieve 1-way replication until I restart SERVER1, which can be
done after business hours.

--
Newell White

Jill Zoeller [MSFT]

2006-05-02 21:25:15 UTC

Permalink

When you say you want to make the database more robust, what kind of
database are you talking about? Databases are tricky to replicate because
FRS and DFSR Replication (new in R2) only replicate files after they are
closed, and database files are typically held open.

Assuming you can work around this, what we usually recommend is 2-way
replication between the two members. As far as the namespace goes, you have
a couple choices:

If you aren't using W2K3 SP1 or R2, you can enable/disable referrals for
link targets. For example, keep Server2's referral disabled unless Server1
goes down. THen you can enable Server2's referral.

If you're using W2K3 SP1 or R2 on your root servers, you can use a new
features called target priority, which allows you to (among other choices)
specify a target as "always first" or "always last." You could set Server2's
referral as "always last" and clients will only be referred there if Server1
is down.

You don't mention whether you are using R2 or not. If you are, we highly
recommend DFS Replication over FRS.

You can find more details at www.microsoft.com/dfs.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Post by Newell White
Having at last added a 2nd DC to our domain to get a fault tolerant network
(25 LAN workstations, 10 VPN clients), I now want to make our database more
robust.
At present it is a single share of folders on the drive of SERVER1.
If I make it a domain root DFS, and set up replication with a copy of the
folders on SERVER2, can I force DFS to point all referrals to SERVER1 if that
is up, otherwise to SERVER2?
This way I achieve 1-way replication until I restart SERVER1, which can be
done after business hours.
--
Newell White

Newell White

2006-05-03 09:26:02 UTC

Permalink

Thanks for your help Jill.

Both servers run W2k3 SP1, so target priority sounds ideal.
Database is implemented in Access, of which I am fairly ignorant - sorry -
but I will explain as best I can.

At logon, workstations map I: to a conventional share on SERVER1, and copy
rules.mdb (form & table defs, procedures) to local drive. When they wish to
examine any records, these are filtered from data.mdb which resides on
SERVER1.
If they edit, a lock is set in the .ldb file on SERVER1 until the relevant
record is returned to SERVER1.

For such a small network as ours, we don't need SERVER2 for load sharing.
What I am trying to achieve is a self-activating hot-pluggable almost
up-to-date backup in case SERVER1 goes down while I am relaxing by the
Mediterranean! So I will be happy if replication only happens lunch-time and
evening.

DFS technology appeals because if procedure writers and data authors have
rigorously used I:\ and not \\SERVER1\SHARE\, all I have to do is set up DFS,
then modify the mapping of I:\ in the logon script. If replication can work
for me, it will save me implementing scheduled copying from SERVER1 to
SERVER2.
--
Newell White

Post by Jill Zoeller [MSFT]
When you say you want to make the database more robust, what kind of
database are you talking about? Databases are tricky to replicate because
FRS and DFSR Replication (new in R2) only replicate files after they are
closed, and database files are typically held open.
Assuming you can work around this, what we usually recommend is 2-way
replication between the two members. As far as the namespace goes, you have
If you aren't using W2K3 SP1 or R2, you can enable/disable referrals for
link targets. For example, keep Server2's referral disabled unless Server1
goes down. THen you can enable Server2's referral.
If you're using W2K3 SP1 or R2 on your root servers, you can use a new
features called target priority, which allows you to (among other choices)
specify a target as "always first" or "always last." You could set Server2's
referral as "always last" and clients will only be referred there if Server1
is down.
You don't mention whether you are using R2 or not. If you are, we highly
recommend DFS Replication over FRS.
You can find more details at www.microsoft.com/dfs.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Jill Zoeller [MSFT]

2006-05-03 16:06:25 UTC

Permalink

Hi Newell,

I'm not familiar with Access myself, so I'm not sure if the method you are
using will result in the database being closed and therefore replicated.
Your description sounds like the database will be closed periodically, but
how often and how long will be something you want to investigate. If the
database is closed when users go home at night, then that's when replication
will occur.

Since you are using SP1 and not R2, you'll need to use the command-line tool
dfsutil to set target priority. R2 provides a new snap-in with UI for
enabling this feature.

If you are going to use FRS (which is the case unless you are using R2),
you'll want to check out the monitoring resources and docs on
www.microsoft.com/frs. If the database is large, note that FRS will
replicate the ENTIRE database each time a change occurs (and the database is
closed). This might not be ideal for you or your network. On the other hand,
if you were using R2, you can use the much improved DFS Replication, which
will replicate only the changes to the database. You can find out more at
www.microsoft.com/dfs.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Post by Newell White
Thanks for your help Jill.
Both servers run W2k3 SP1, so target priority sounds ideal.
Database is implemented in Access, of which I am fairly ignorant - sorry -
but I will explain as best I can.
At logon, workstations map I: to a conventional share on SERVER1, and copy
rules.mdb (form & table defs, procedures) to local drive. When they wish to
examine any records, these are filtered from data.mdb which resides on
SERVER1.
If they edit, a lock is set in the .ldb file on SERVER1 until the relevant
record is returned to SERVER1.
For such a small network as ours, we don't need SERVER2 for load sharing.
What I am trying to achieve is a self-activating hot-pluggable almost
up-to-date backup in case SERVER1 goes down while I am relaxing by the
Mediterranean! So I will be happy if replication only happens lunch-time and
evening.
DFS technology appeals because if procedure writers and data authors have
rigorously used I:\ and not \\SERVER1\SHARE\, all I have to do is set up DFS,
then modify the mapping of I:\ in the logon script. If replication can work
for me, it will save me implementing scheduled copying from SERVER1 to
SERVER2.
--
Newell White

Post by Newell White
Having at last added a 2nd DC to our domain to get a fault tolerant network
(25 LAN workstations, 10 VPN clients), I now want to make our database more
robust.
At present it is a single share of folders on the drive of SERVER1.
If I make it a domain root DFS, and set up replication with a copy of the
folders on SERVER2, can I force DFS to point all referrals to SERVER1
if
that
is up, otherwise to SERVER2?
This way I achieve 1-way replication until I restart SERVER1, which can be
done after business hours.
--
Newell White

Newell White

2006-05-05 13:05:02 UTC

Permalink

Jill,
Sorry to be such an ignoramus, but:
I have installed support tools from my W2k3 CD, but after 'dfsutil /?' I
cannot see a parameter that looks as though it will set target priorities.

Is this because I updated to SP1 before I installed support tools?
And if so, should uninstalling and then re-installing SP1 upgrade dfsutil?

Thanks
--
Newell White

Jill Zoeller [MSFT]

2006-05-05 14:55:56 UTC

Permalink

It's the SP1 version of Dfsutil that you want. I need to run to a meeting
but will look into where to download this when I return.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Post by Newell White
Jill,
I have installed support tools from my W2k3 CD, but after 'dfsutil /?' I
cannot see a parameter that looks as though it will set target priorities.
Is this because I updated to SP1 before I installed support tools?
And if so, should uninstalling and then re-installing SP1 upgrade dfsutil?
Thanks
--
Newell White

Newell White

2006-05-05 15:07:02 UTC

Permalink

Thanks, I have found the download site.
--
Newell White

Post by Jill Zoeller [MSFT]
It's the SP1 version of Dfsutil that you want. I need to run to a meeting
but will look into where to download this when I return.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Newell White

2006-05-09 09:12:01 UTC

Permalink

Jill,
I now have a DFS root with 1 target, 2 links to replicas on SERVER1 and
SERVER2.
The Access database only gets replicated each evening, but that is adequate
for the time being.

I haven't messed with dfsutil yet, or mapped my workstations to the DFS yet,
as I am trying to sort out a couple of points.

Permissions - on SERVER1 I cannot change permissions for the target replica
on SERVER1 or subfolders from Explorer - get egg-timer and 'not responding'.
If I call up DFS Admin Tool I cannot change permissions on either replica
(same result).
I am trying to set explicit permissions on this folder, subfolders, and
files for Administrators, System, and our user Security Group so I can
exclude inherited permissions.

Replication staging folders - both servers configured with 1 large SCSI
drive each.
This is resulting in a lot of head movement, and taking up 1.8Gbyte on each
server.
Can I implement staging folders for SERVER1 and SERVER2 as shares on the
drive of a workstation? Provided all 3 computers are on the top level
Gbit/sec network switch this should be fast enough. There is a dearth of info
about the staging folder role in replication.

Thanks,
--
Newell White

Post by Newell White
Thanks, I have found the download site.
--
Newell White

Newell White

2006-05-09 10:35:01 UTC

Permalink

Whoops!

Scrub the permissions question.
It just takes a loooong time, presumably waiting for AD to report that the
changes have been propagated to all replicas of the root. I just couldn't
believe how long on my 2 server network (between 12 and 18 minutes) until I
got called away during my last attempt, and got back to discover changes had
been implemented.
--
Newell White

Post by Newell White
Jill,
I now have a DFS root with 1 target, 2 links to replicas on SERVER1 and
SERVER2.
The Access database only gets replicated each evening, but that is adequate
for the time being.
I haven't messed with dfsutil yet, or mapped my workstations to the DFS yet,
as I am trying to sort out a couple of points.
Permissions - on SERVER1 I cannot change permissions for the target replica
on SERVER1 or subfolders from Explorer - get egg-timer and 'not responding'.
If I call up DFS Admin Tool I cannot change permissions on either replica
(same result).
I am trying to set explicit permissions on this folder, subfolders, and
files for Administrators, System, and our user Security Group so I can
exclude inherited permissions.
Replication staging folders - both servers configured with 1 large SCSI
drive each.
This is resulting in a lot of head movement, and taking up 1.8Gbyte on each
server.
Can I implement staging folders for SERVER1 and SERVER2 as shares on the
drive of a workstation? Provided all 3 computers are on the top level
Gbit/sec network switch this should be fast enough. There is a dearth of info
about the staging folder role in replication.
Thanks,
--
Newell White

Post by Newell White
Thanks, I have found the download site.
--
Newell White

Newell White

2006-05-09 13:29:01 UTC

Permalink

Jill,
There must be something I have overlooked.
I now have permissions OK for Administrators and Security Groups via the DFS
Admin Tool.

But when I map I: to the DFS as \\domain.local\OURdfs, MS office opens every
file as read-only.
If I look at the security tab of the file, I see Administrators, Security
Group, and Account unknown. This last has a GUID which occurs in SERVER1
registry as the value of parameter Group 10 in most keys (all GUIDs) under
HKLM\Software\Microsoft\Windows\CurrentVersion\GroupPolicy

If I map I: to the target share of the DFS as \\SERVER1\ShareName, all files
open as editable in MS office. Despite the same Account Unknown appearing in
the Security tab.

So the restriction must be in the way I have configured DFS, not in the
folders and files of the target.

Is DFS replication the problem? Maybe I should try restrict this to
night-time?
Now if SERVER1 crashes we lose up to a day's work. The business critical
Access db can be restored from the daily transaction log, which I could get
full-time replication of by putting it in SysVol.

But I could achieve this with a scheduled file copying task and dispense
with DFS.
And simulate the target selection I want by a logon script mapping I: to
SERVER1, checking for presence of a persistent folder or file, and mapping to
SERVER2 on failure.
--
Newell White

Jill Zoeller [MSFT]

2006-05-09 23:27:30 UTC

Permalink

Hi Newell,

DFS does not have its own permissions. It just provides referrals to shares,
and the existing NTFS and share permissions come into play. When strange
permission issues happen in namespaces, there is usually a mismatch of
permissions between targets of a link, between share and NTFS permissions,
or a combination of both. For the time being, let's leave FRS out of this.

First, check both NTFS and share permissions on the root folder (the
\\servername\sharename that corresponds to your "OURdfs" root). Anything set
as read-only on the root?

Now, that being said, I have seen an increase in newsgroup reports where
customers have permission issues when accessing the \\domain\root share but
not the underlying target. I have a theory but it might not be valid in your
case. What happens if, instead of mapping to \\domain.local\OURdfs, you map
to \\domain\OURdfs?
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Post by Newell White
Jill,
There must be something I have overlooked.
I now have permissions OK for Administrators and Security Groups via the DFS
Admin Tool.
But when I map I: to the DFS as \\domain.local\OURdfs, MS office opens every
file as read-only.
If I look at the security tab of the file, I see Administrators, Security
Group, and Account unknown. This last has a GUID which occurs in SERVER1
registry as the value of parameter Group 10 in most keys (all GUIDs) under
HKLM\Software\Microsoft\Windows\CurrentVersion\GroupPolicy
If I map I: to the target share of the DFS as \\SERVER1\ShareName, all files
open as editable in MS office. Despite the same Account Unknown appearing in
the Security tab.
So the restriction must be in the way I have configured DFS, not in the
folders and files of the target.
Is DFS replication the problem? Maybe I should try restrict this to
night-time?
Now if SERVER1 crashes we lose up to a day's work. The business critical
Access db can be restored from the daily transaction log, which I could get
full-time replication of by putting it in SysVol.
But I could achieve this with a scheduled file copying task and dispense
with DFS.
And simulate the target selection I want by a logon script mapping I: to
SERVER1, checking for presence of a persistent folder or file, and mapping to
SERVER2 on failure.
--
Newell White

Dave Mills

2006-05-10 06:53:26 UTC

Permalink

I had a similar issue where a file was placed in the DFS root folder by a non
admin. I could not see how this was possible. The permissions were read only. I
eventually discovered that the NTFS permissions on one of the two root replicas
included Users:Write while on the other server it did not. When I looked at the
permissions via DFS I was getting those from server1 which were as expected.
Only when I connected to c$ on each server and looked of the NTFS permission of
the hosting folder did I see the cause.

On Tue, 9 May 2006 16:27:30 -0700, "Jill Zoeller [MSFT]"

Post by Jill Zoeller [MSFT]
Hi Newell,
DFS does not have its own permissions. It just provides referrals to shares,
and the existing NTFS and share permissions come into play. When strange
permission issues happen in namespaces, there is usually a mismatch of
permissions between targets of a link, between share and NTFS permissions,
or a combination of both. For the time being, let's leave FRS out of this.
First, check both NTFS and share permissions on the root folder (the
\\servername\sharename that corresponds to your "OURdfs" root). Anything set
as read-only on the root?
Now, that being said, I have seen an increase in newsgroup reports where
customers have permission issues when accessing the \\domain\root share but
not the underlying target. I have a theory but it might not be valid in your
case. What happens if, instead of mapping to \\domain.local\OURdfs, you map
to \\domain\OURdfs?

--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.

Jill Zoeller [MSFT]

2006-05-10 15:15:51 UTC

Permalink

Good point. I should add that when setting permissions on folders that are
targets in a namespace, always use their physical paths, not their DFS
paths.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Want to learn more about Windows Server file and storage technologies? Visit
our team blog at http://blogs.technet.com/filecab/default.aspx.

Post by Dave Mills
I had a similar issue where a file was placed in the DFS root folder by a non
admin. I could not see how this was possible. The permissions were read only. I
eventually discovered that the NTFS permissions on one of the two root replicas
included Users:Write while on the other server it did not. When I looked at the
permissions via DFS I was getting those from server1 which were as expected.
Only when I connected to c$ on each server and looked of the NTFS permission of
the hosting folder did I see the cause.
On Tue, 9 May 2006 16:27:30 -0700, "Jill Zoeller [MSFT]"

--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.