Is it necessary to upgrade to R2 to get the new DFS Management snap-in?

[mwest]

I have win2k3 R1 DC's and am trying to get DFS working as described in "How
DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT dependant
on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?

PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[Ned Pyle (MSFT)]

Hi MWest,

The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you browse
the namespace. In the legacy DFS console, you see no namespaces with no
errors - as you probably already know!

To explain why the PDCE is used:

Domain-based DFS stores its namespace information in a binary blob attribute
in AD called 'pKT'. Since this is a single attribute, it's necessary to
force all the standard management tools to go to a single DC for editing
purposes. Otherwise if we had two admins editing DFS at the same time, on
two different DC's, the admin that saved last would overwrite all the
changes made by the other admin when replication converged.

I hope this answered your question - if not, let me know,

Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in "How
DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[mwest]

Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no end
users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[Ned Pyle (MSFT)]

Ah, understood. That would not be expected behavior - your PDCE being
offline should have no effect on client connectivity. Do you get a specific
error when your clients try to connect to that drive? Also, are your clients
XP SP2?

Ned

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no
end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[mwest]

Hi,
If memory serves correctly when it is offline they get the standard
"inaccesible" message, even though there still is a running DC (I'll have to
test this weekend for sure).
The login mapping is \\Domain\DFSRoot.
Below that are links to shares on various servers.
Each DFS root provides the links needed by the group that has it mapped.
DC replication, when initiated through AD Sites & Services works fine.
The following command does not display any errors:
dcdiag /s:SERVER /fix /c /v /a
We run 2kp and xp-sp2 both with identical results.
We also have a WUS server so all the latest fixes issued are applied.
Would it matter that the mapping is to \\domain\DFSRoot and not
\\domain.com\DFSRoot

Post by Ned Pyle (MSFT)
Ah, understood. That would not be expected behavior - your PDCE being
offline should have no effect on client connectivity. Do you get a
specific error when your clients try to connect to that drive? Also, are
your clients XP SP2?
Ned

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no
end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but
the same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through
the snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single
DC for editing purposes. Otherwise if we had two admins editing DFS at
the same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[Ned Pyle (MSFT)]

Interesting. I reproed to make sure I was not losing my mind (used 2003 Sp1
and XP Sp2, with \\fabrikam\public) and it worked without issues. Using
netbios vs FQDN should not matter. Naturally, I could not manage DFS at all
when it was offline, but I could still get to my target folders and such.

Let us know what your repro shows.

Post by mwest
Hi,
If memory serves correctly when it is offline they get the standard
"inaccesible" message, even though there still is a running DC (I'll have
to test this weekend for sure).
The login mapping is \\Domain\DFSRoot.
Below that are links to shares on various servers.
Each DFS root provides the links needed by the group that has it mapped.
DC replication, when initiated through AD Sites & Services works fine.
dcdiag /s:SERVER /fix /c /v /a
We run 2kp and xp-sp2 both with identical results.
We also have a WUS server so all the latest fixes issued are applied.
Would it matter that the mapping is to \\domain\DFSRoot and not
\\domain.com\DFSRoot

Post by Ned Pyle (MSFT)
Ah, understood. That would not be expected behavior - your PDCE being
offline should have no effect on client connectivity. Do you get a
specific error when your clients try to connect to that drive? Also, are
your clients XP SP2?
Ned

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no
end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but
the same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue
to work as a system, but you will no longer be able to manage it
through the snap-in. In the new DFS management console you get an error
on this (specified domain does not exist or could not be contacted)
when you browse the namespace. In the legacy DFS console, you see no
namespaces with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single
DC for editing purposes. Otherwise if we had two admins editing DFS at
the same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[mwest]

Me too, the file servers are accessible, but DFS seems to be a
"Single-Point-of-Failure" system dependant on the PDC.
This means VERY little when you have a building full of secretaries
screaming "I can't get to my K drive."
Would you know if this is fixed in "R2?"
Is the fix called "DFSR?"
If so, can I "upgrade" to DFSR without "upgrading" to "R2?"
...I'm just trying to plan out my next few weekends...

Post by Ned Pyle (MSFT)
Interesting. I reproed to make sure I was not losing my mind (used 2003
Sp1 and XP Sp2, with \\fabrikam\public) and it worked without issues.
Using netbios vs FQDN should not matter. Naturally, I could not manage DFS
at all when it was offline, but I could still get to my target folders and
such.
Let us know what your repro shows.

Post by mwest
Hi,
If memory serves correctly when it is offline they get the standard
"inaccesible" message, even though there still is a running DC (I'll have
to test this weekend for sure).
The login mapping is \\Domain\DFSRoot.
Below that are links to shares on various servers.
Each DFS root provides the links needed by the group that has it mapped.
DC replication, when initiated through AD Sites & Services works fine.
dcdiag /s:SERVER /fix /c /v /a
We run 2kp and xp-sp2 both with identical results.
We also have a WUS server so all the latest fixes issued are applied.
Would it matter that the mapping is to \\domain\DFSRoot and not
\\domain.com\DFSRoot

Post by Ned Pyle (MSFT)
Ah, understood. That would not be expected behavior - your PDCE being
offline should have no effect on client connectivity. Do you get a
specific error when your clients try to connect to that drive? Also, are
your clients XP SP2?
Ned

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline
no end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a
drive letter to the appropriet DFS root.
That works, depending on who you login as you have different links but
the same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue
to work as a system, but you will no longer be able to manage it
through the snap-in. In the new DFS management console you get an
error on this (specified domain does not exist or could not be
contacted) when you browse the namespace. In the legacy DFS console,
you see no namespaces with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single
DC for editing purposes. Otherwise if we had two admins editing DFS at
the same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have
enough identical copies of the same data.

[Ned Pyle (MSFT)]

No difference with DFS (Now referred to as DFSN, for Namespaces) in R2 - if
there was an issue before, it will still be there. DFSR only affects
replication, so nothing to do with 'DFS' as it was perceived in Windows
2000, 2003. DFSR replaces FRS only.

PDCE down should definitely not be causing your whole DFS system to unravel
like this. We can dig further when you repro, although at that point I might
recommend actually opening a case with us to get into very indepth
troubleshooting. I can say with complete confidence that this should not be
acting like this, and that when I repro your issue I can have my PDCE
totally turned off and get into DFS with no issues, getting referrals from
one of the other DC's as expected.

Looking forward to hearing about your results! :)

Ned

Post by mwest
Me too, the file servers are accessible, but DFS seems to be a
"Single-Point-of-Failure" system dependant on the PDC.
This means VERY little when you have a building full of secretaries
screaming "I can't get to my K drive."
Would you know if this is fixed in "R2?"
Is the fix called "DFSR?"
If so, can I "upgrade" to DFSR without "upgrading" to "R2?"
...I'm just trying to plan out my next few weekends...

Post by Ned Pyle (MSFT)
Interesting. I reproed to make sure I was not losing my mind (used 2003
Sp1 and XP Sp2, with \\fabrikam\public) and it worked without issues.
Using netbios vs FQDN should not matter. Naturally, I could not manage
DFS at all when it was offline, but I could still get to my target
folders and such.
Let us know what your repro shows.

Post by mwest
Hi,
If memory serves correctly when it is offline they get the standard
"inaccesible" message, even though there still is a running DC (I'll
have to test this weekend for sure).
The login mapping is \\Domain\DFSRoot.
Below that are links to shares on various servers.
Each DFS root provides the links needed by the group that has it mapped.
DC replication, when initiated through AD Sites & Services works fine.
dcdiag /s:SERVER /fix /c /v /a
We run 2kp and xp-sp2 both with identical results.
We also have a WUS server so all the latest fixes issued are applied.
Would it matter that the mapping is to \\domain\DFSRoot and not
\\domain.com\DFSRoot

Post by Ned Pyle (MSFT)
Ah, understood. That would not be expected behavior - your PDCE being
offline should have no effect on client connectivity. Do you get a
specific error when your clients try to connect to that drive? Also,
are your clients XP SP2?
Ned

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline
no end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a
drive letter to the appropriet DFS root.
That works, depending on who you login as you have different links but
the same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue
to work as a system, but you will no longer be able to manage it
through the snap-in. In the new DFS management console you get an
error on this (specified domain does not exist or could not be
contacted) when you browse the namespace. In the legacy DFS console,
you see no namespaces with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a
single DC for editing purposes. Otherwise if we had two admins
editing DFS at the same time, on two different DC's, the admin that
saved last would overwrite all the changes made by the other admin
when replication converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described
in "How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have
enough identical copies of the same data.

[Rob]

When the PDC goes down, could you modify the logon scripts such that users'
Q drive (or whatever) will point to \\server\share instead of
\\domain.com\share. You lose the failover aspect, but as long as the data
is replicating properly and not backlogged, they should see all the data.
Users probably don't care what the "share" on "server" says, they just know
"this data is on Q, that data is on H, this other data is on R...."

Then when the PDC comes back online, you can modify the logon scripts again
to point to the \\domain.com\share root.

HTH,
Rob

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no
end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[mwest]

Hi,
Please don't take this the wrong way, but:
1) The DC outages are not planned.
2) The "link targets" are different for each DFSRoot/group
3) The "link targets" are on different servers.
4) Would require everyone in the building to log back in.
I would sooner go to a different topology... one that would work as
advertised.

Post by Rob
When the PDC goes down, could you modify the logon scripts such that
users' Q drive (or whatever) will point to \\server\share instead of
\\domain.com\share. You lose the failover aspect, but as long as the data
is replicating properly and not backlogged, they should see all the data.
Users probably don't care what the "share" on "server" says, they just
know "this data is on Q, that data is on H, this other data is on R...."
Then when the PDC comes back online, you can modify the logon scripts
again to point to the \\domain.com\share root.
HTH,
Rob

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no
end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but
the same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through
the snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single
DC for editing purposes. Otherwise if we had two admins editing DFS at
the same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[Rob]

No problem. Oh, you're outages aren't planned (wink wink)?

I had the same problem with a few users so I decided to rearrange my
topology and logon scripts just in case they couldn't contact the PDC.

Good luck.

-Rob

Post by mwest
Hi,
1) The DC outages are not planned.
2) The "link targets" are different for each DFSRoot/group
3) The "link targets" are on different servers.
4) Would require everyone in the building to log back in.
I would sooner go to a different topology... one that would work as
advertised.

Post by Rob
When the PDC goes down, could you modify the logon scripts such that
users' Q drive (or whatever) will point to \\server\share instead of
\\domain.com\share. You lose the failover aspect, but as long as the
data is replicating properly and not backlogged, they should see all the
data. Users probably don't care what the "share" on "server" says, they
just know "this data is on Q, that data is on H, this other data is on
R...."
Then when the PDC comes back online, you can modify the logon scripts
again to point to the \\domain.com\share root.
HTH,
Rob

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no
end users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but
the same drive letter.
But if the PDC is offline you can't access that drive letter.

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue
to work as a system, but you will no longer be able to manage it
through the snap-in. In the new DFS management console you get an error
on this (specified domain does not exist or could not be contacted)
when you browse the namespace. In the legacy DFS console, you see no
namespaces with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single
DC for editing purposes. Otherwise if we had two admins editing DFS at
the same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[Dave Mills]

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no end
users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

I might be missing something here but I think you are saying you have 3 DFS
roots with different links etc. All defined on the PDC. It does not sound like
you have any replica DFS roots for these. Thus if the PDC fails so does the DFS
Root. Hence while the other DCs can resolve the Domain/DRFRoot namespace it
points only to the PDCs DFSRoot for the content. Thus nobody can resolve the
namespace to a working DFS Root server (it is the PDC). For Fault Tolerance you
need 2 or more DCs and 2 or more DFR root servers for each DFS Root.

Post by mwest

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

[mwest]

I've heard tale of something called a "DFS Root replica."
How to I setup "DFS Root replicas?"
The "dfsgui.msc" doesn't seem to have that option.

Post by Dave Mills

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no end
users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

I might be missing something here but I think you are saying you have 3 DFS
roots with different links etc. All defined on the PDC. It does not sound like
you have any replica DFS roots for these. Thus if the PDC fails so does the DFS
Root. Hence while the other DCs can resolve the Domain/DRFRoot namespace it
points only to the PDCs DFSRoot for the content. Thus nobody can resolve the
namespace to a working DFS Root server (it is the PDC). For Fault Tolerance you
need 2 or more DCs and 2 or more DFR root servers for each DFS Root.

Post by mwest

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

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

[Ned Pyle (MSFT)]

It's just another term for 'DFS root target'. When a client wants to get to
DFS, it queries a DC for the blob and finds the root target (replicas, if
there are more than one). You then get referred to one of those servers to
get referrals for links and link targets.

If you wanted to add more (from the old DFSGUI.MSC), right click your DFS
namespace, then choose 'new root target'. Specify another 2003 server (does
not have to be a DC necessarily), specify the folder it will share for the
root, click finish, then you're all set. Fault tolerant replicated roots.

This is the step we'd take if the previous question about your PDCE being
the only current root turns out to be the case.

Post by mwest
I've heard tale of something called a "DFS Root replica."
How to I setup "DFS Root replicas?"
The "dfsgui.msc" doesn't seem to have that option.

Post by Dave Mills

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no end
users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

I might be missing something here but I think you are saying you have 3 DFS
roots with different links etc. All defined on the PDC. It does not sound like
you have any replica DFS roots for these. Thus if the PDC fails so does the DFS
Root. Hence while the other DCs can resolve the Domain/DRFRoot namespace it
points only to the PDCs DFSRoot for the content. Thus nobody can resolve the
namespace to a working DFS Root server (it is the PDC). For Fault Tolerance you
need 2 or more DCs and 2 or more DFR root servers for each DFS Root.

Post by mwest

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

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

[Ned Pyle (MSFT)]

I'm liking where Dave's going with this - that might certainly explain it.
One way you can confirm this for us is (on any 2003 DC with support tools
installed) execute from a CMD prompt:

dfsutil /root:\\domain\root /view

This would give us something like this (in my sample it was a domain called
'alpineskihouse' and a root called 'public'):

============

Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.

Domain Root with 2 Links [Blob Size: 1054 bytes]
Root information follows


Root Name="\\ALPINESKIHOUSE\public" State="1" Timeout="300"
Target Server="2003SRV50" Folder="public" State="2" [Site:
Default-First-Site-Name]
Target Server="2003SRV51" Folder="public" State="2" [Site:
Default-First-Site-Name]


Link Name="link1" State="1" Timeout="1800"
Target Server="2003srv50" Folder="link1" State="2" [Site:
Default-First-Site-Name]


Link Name="link2" State="1" Timeout="1800"
Target Server="2003srv51" Folder="link2" State="2" [Site:
Default-First-Site-Name]


Root with 2 Links [Blob Size: 1054 bytes]

=================

If the 'Target Server' for 'Root Name' is only one line, and it's just the
PDCE DC in your environemnt, you would definitely see DFS connectivity
issues when that particular server (which just happens to be the PDCE,
purely coincidentally) is down.

Post by Dave Mills

Post by mwest
Hi,
What I meant was I have it setup on a win2k3 PDC and if it is offline no end
users {or anyone else) can make use of DFS.
I created three different root with different links in each.
I then used different group policies for different groups to map a drive
letter to the appropriet DFS root.
That works, depending on who you login as you have different links but the
same drive letter.
But if the PDC is offline you can't access that drive letter.

I might be missing something here but I think you are saying you have 3 DFS
roots with different links etc. All defined on the PDC. It does not sound like
you have any replica DFS roots for these. Thus if the PDC fails so does the DFS
Root. Hence while the other DCs can resolve the Domain/DRFRoot namespace it
points only to the PDCs DFSRoot for the content. Thus nobody can resolve the
namespace to a working DFS Root server (it is the PDC). For Fault Tolerance you
need 2 or more DCs and 2 or more DFR root servers for each DFS Root.

Post by mwest

Post by Ned Pyle (MSFT)
Hi MWest,
The behavior is unchanged - if the PDCE is offline, DFS will continue to
work as a system, but you will no longer be able to manage it through the
snap-in. In the new DFS management console you get an error on this
(specified domain does not exist or could not be contacted) when you
browse the namespace. In the legacy DFS console, you see no namespaces
with no errors - as you probably already know!
Domain-based DFS stores its namespace information in a binary blob
attribute in AD called 'pKT'. Since this is a single attribute, it's
necessary to force all the standard management tools to go to a single DC
for editing purposes. Otherwise if we had two admins editing DFS at the
same time, on two different DC's, the admin that saved last would
overwrite all the changes made by the other admin when replication
converged.
I hope this answered your question - if not, let me know,
Ned

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in
"How DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT
dependant on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.

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

[mwest]

Hi,
Below I have the results of that command.
I read in this article
http://www.microsoft.com/resources/documentation/msa/edc/all/solution/en-us/pak/build/edcbld09.mspx?mfr=true

In the section called "Creating DFS Root Replicas"
Step 13...
On the Action menu, click New Root Replica.
I don't see the option...

******* Is there an address I could send a screen shot of my dfsgui.msc and
the action? ********

======================================================================
C:\>dfsutil /root:\\MyDomain\test /view

Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.

Domain Root with 7 Links [Blob Size: 2764 bytes]
Root information follows

Root Name="\\MyDomain\Test" Comment="Network Areas for the Test Department"
State="1" Timeout="300"
Target Server="ORION" Folder="Test" State="2" [Site:
Default-First-Site-Name]

Link Name="Public" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Public" State="2"
[Site: Default-First-Site-Name]

Link Name="Test Public" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Test" State="2" [Site:
Default-First-Site-Name]

Link Name="Doc_System" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Docs" State="2" [Site:
Default-First-Site-Name]

Link Name="Archive" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Arc" State="2" [Site:
Default-First-Site-Name]

Link Name="Sunhome" State="1" Timeout="1800"
Target Server="Tserver" Folder="Sunday" State="2" [Site:
Default-First-Site-Name]

Link Name="Home" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="HOME" State="2" [Site:
Default-First-Site-Name]

Link Name="Manufacturing" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Manacoti" State="2"
[Site: Default-First-Site-Name]

Root with 7 Links [Blob Size: 2764 bytes]

NOTE: All site information shown was generated by this utility.
Actual DFS behavior depends on site information currently in use by
DFS service, and may not reflect configuration changes made recently.

Done processing this command.

[Dave Mills]

Post by mwest
Hi,
Below I have the results of that command.
I read in this article
http://www.microsoft.com/resources/documentation/msa/edc/all/solution/en-us/pak/build/edcbld09.mspx?mfr=true
In the section called "Creating DFS Root Replicas"
Step 13...
On the Action menu, click New Root Replica.
I don't see the option...
******* Is there an address I could send a screen shot of my dfsgui.msc and
the action? ********
======================================================================
C:\>dfsutil /root:\\MyDomain\test /view
Microsoft(R) Windows(TM) Dfs Utility Version 4.0
Copyright (C) Microsoft Corporation 1991-2001. All Rights Reserved.
Domain Root with 7 Links [Blob Size: 2764 bytes]
Root information follows
Root Name="\\MyDomain\Test" Comment="Network Areas for the Test Department"
State="1" Timeout="300"
Default-First-Site-Name]

Above is your single point of failure, for the whole namespace. If ORION is down
so is the namespace. Or course existing referrals will continue working but no
new referrals can be obtained nor can failover happen. Create one or more
replica namespace servers.

You also have single points of failure for each of the links below but that may
be what you want. I am not going to introduce Link Replicas as a first step. I
will first have a replica of my Support folder then add others as my experience
with R2 grows.

Post by mwest
Link Name="Public" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Public" State="2"
[Site: Default-First-Site-Name]
Link Name="Test Public" State="1" Timeout="1800"
Default-First-Site-Name]
Link Name="Doc_System" State="1" Timeout="1800"
Default-First-Site-Name]
Link Name="Archive" State="1" Timeout="1800"
Default-First-Site-Name]
Link Name="Sunhome" State="1" Timeout="1800"
Default-First-Site-Name]
Link Name="Home" State="1" Timeout="1800"
Default-First-Site-Name]
Link Name="Manufacturing" State="1" Timeout="1800"
Target Server="MyFileServer" Folder="Manacoti" State="2"
[Site: Default-First-Site-Name]
Root with 7 Links [Blob Size: 2764 bytes]
NOTE: All site information shown was generated by this utility.
Actual DFS behavior depends on site information currently in use by
DFS service, and may not reflect configuration changes made recently.
Done processing this command.

[rnitsch [msft]]

Hi

I actually can't recall if the new UI can BUT I do know that you can
activate it with DFSUtil:

/Root:<DfsName> /RootScalability /Enable|Disable|Display [/Verbose]

This works since 2003 server.

Roland

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Visit our team blog at http://blogs.technet.com/filecab/default.aspx.

Post by mwest
I have win2k3 R1 DC's and am trying to get DFS working as described in "How
DFS Works."
In particular I'm trying to make it so the Domain based DFS is NOT dependant
on the PDC being up.
Currently if the PDC goes offline so does DFS.
Will the new DFS Management snap-in make this possible?
PS I'm not interested in file replication I run RAID51 and have enough
identical copies of the same data.