| Author | Messages | |
gabriel/tfi
Posts:425
 | | 10/07/2008 5:04 PM |
| We went through a similar path several years ago, but when we demoted remote
DCs we set those servers to caching-only DNS servers to speed-up name
resolution. to limit the number of hits on HUB DNS servers and lookup
traffic over the WAN, while avoiding zone transfer burden.
Probably with today's WAN performance, we might remove them and users
wouldn't notice the difference.
Gabriele
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-
> owner@mail.activedir.org] On Behalf Of Christine.Allen@salemfive.com
> Sent: lunedì 6 ottobre 2008 21.15
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Decommissioning DC
>
> Hello,
>
> I'm hoping to get some advice.  We have a windows 2003 forest with
> three domains. A empty root, then two child domains, a main office
> domain and a domain for our remote sites.
>
> We currently have 18 domain controllers in the remote sites. Since all
> sites are connected by fast connection, We want to decommission the
> domain controllers and have them as member servers running DNS.
>
> I know the steps on how to decommission the dc's. It should be easy
> since they hold no roles. My question is more on setting up the proper
> dns configuration. I'm going to configure secondary zones for the
> remote domain and locke them down to replicate with the DNS master,
> should I also set up secondary zones for the other child domain and the
> empty root domain?
>
> Any suggestions would be appreciated.
>
>
>
> -Christine
>
> Christine N. Allen
> Sr. Systems Engineer
> Salem Five
> 210 Essex Street
> Salem, MA 01970
> 978-720-5928
> christine.allen@salemfive.com
>
>
> This information may be confidential and/or privileged. Use of this
> information by anyone other than the intended recipient is prohibited.
> If you received this in error, please inform the sender and remove any
> record of this message.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
| gabriel/tfi
Posts:425
| | 10/07/2008 5:10 PM |
| I think SYSVOL (scripts and GPOs) over the WAN is much heavier than Kerberos
and name resolution, even if they hit the network much less frequently.
Gabriele.
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-
> owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
> Sent: martedì 7 ottobre 2008 5.00
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> I see what you are saying, Brian. But that is not the angle from which
> I approached this in my initial response. My approach was whether local
> name resolution of was more optimized and less costly than cross-WAN
> resolution. My response was to the effect that since the servers are
> already there, localized name resolution is more efficient and the
> network cost associated with the zone transfer will be less than that
> associated with clients going across the WAN to a centralized DNS
> server.
>
> >From the angle of "we're already doing cross-WAN authentication", I'd
> like to point out that cross-WAN authentication traffic usually tapers
> off after the initial spike in the morning. For much of the rest of the
> day, you usually have very negligible authentication-related traffic.
> Yes, I know that "it depends" on many factors as well, but generally
> name resolution traffic is a lot more chatty and pervasive than
> authentication traffic.
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon
> ________________________________________
> From: ActiveDir-owner@mail.activedir.org [ActiveDir-
> owner@mail.activedir.org] On Behalf Of Brian Desmond
> [brian@briandesmond.com]
> Sent: Monday, October 06, 2008 7:32 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> However, given that the OP feels it's suitable to run authentication
> traffic over the wire, the logical conclusion here is that there is
> ample bandwidth for name resolution as well. A DNS lookup is far more
> lightweight than everything involved with a user booting a PC and
> logging in to it given it's joined to an AD domain...
>
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-
> owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
> Sent: Monday, October 06, 2008 9:06 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> Unless someone/something is incessantly writing to the zone,
> creating/modifying an inordinately large number of records that is then
> replicated across the wire, it is quite hard to imagine a condition in
> which total bandwidth usage for an IXFR zone replication will surpass
> the total bandwidth usage associated with cross-WAN client resolution
> requests.
>
> If the DNS partners were doing AXFR, then, yeah, it is quite easy to
> eat up a lot of bandwidth doing zone transfer over a period of time.
> With the exception of the seeding stage druing which the secondary
> partner syncs up with the master, there is very little traffic
> associated with a normal DNS replication process in a master/secondary
> topology. Just measure it yourself.
>
> And, no, the consideration of which choices utilizes more bandwidth is
> not "spurious", Robert. At least not in the normal dictionary meaning
> of that word. When you design an enterprise system like DNS, you always
> want to know the cost associated with one choice or the other, not just
> in terms of hardware and maintenance, but also in terms of the network
> bandwidth, among others.
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon
> ________________________________________
> From: ActiveDir-owner@mail.activedir.org [ActiveDir-
> owner@mail.activedir.org] On Behalf Of Robert Singers
> [robert.singers@dbh.govt.nz]
> Sent: Monday, October 06, 2008 5:26 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> It's a spurious comparison.
>
> The real question is what is going to impact users on the remote site
> more. And the answer is that any large transaction across the WAN
> might
> be noticed. So from a end user perspective a zone replication might be
> noticeable, while any number of tiny name resolution requests spread
> across time won't be.
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> Deji
> Sent: Tuesday, 7 October 2008 1:01 p.m.
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> You think that the DNS zone replication traffic will be higher than the
> traffic associated with cross-WAN lookup requests?
>
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon ________________________________________
> From: ActiveDir-owner@mail.activedir.org
> [ActiveDir-owner@mail.activedir.org] On Behalf Of Sabharanjak, Ravi BGI
> SF [Ravi.Sabharanjak@barclaysglobal.com]
> Sent: Monday, October 06, 2008 4:33 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> That will also save on the network replication of the DNS zones to the
> remote sites. The client won't notice that the DNS server is remote.
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
> Sent: Monday, October 06, 2008 1:19 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> I'm missing the point of having local DNS. If your WAN supports having
> the DCs centralized, why can't DNS lookups be centralized too?
>
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> Christine.Allen@salemfive.com
> Sent: Monday, October 06, 2008 2:15 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Decommissioning DC
>
> Hello,
>
> I'm hoping to get some advice. We have a windows 2003 forest with
> three domains. A empty root, then two child domains, a main office
> domain and a domain for our remote sites.
>
> We currently have 18 domain controllers in the remote sites. Since all
> sites are connected by fast connection, We want to decommission the
> domain controllers and have them as member servers running DNS.
>
> I know the steps on how to decommission the dc's. It should be easy
> since they hold no roles. My question is more on setting up the proper
> dns configuration. I'm going to configure secondary zones for the
> remote domain and locke them down to replicate with the DNS master,
> should I also set up secondary zones for the other child domain and the
> empty root domain?
>
> Any suggestions would be appreciated.
>
>
>
> -Christine
>
> Christine N. Allen
> Sr. Systems Engineer
> Salem Five
> 210 Essex Street
> Salem, MA 01970
> 978-720-5928
> christine.allen@salemfive.com
>
>
> This information may be confidential and/or privileged. Use of this
> information by anyone other than the intended recipient is prohibited.
> If you received this in error, please inform the sender and remove any
> record of this message.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
> --
>
> This message and any attachments are confidential, proprietary, and may
> be privileged. If this message was misdirected, Barclays Global
> Investors (BGI) does not waive any confidentiality or privilege. If
> you
> are not the intended recipient, please notify us immediately and
> destroy
> the message without disclosing its contents to anyone. Any
> distribution, use or copying of this e-mail or the information it
> contains by other than an intended recipient is unauthorized. The
> views
> and opinions expressed in this e-mail message are the author's own and
> may not reflect the views and opinions of BGI, unless the author is
> authorized by BGI to express such views or opinions on its behalf. All
> email sent to or from this address is subject to electronic storage and
> review by BGI. Although BGI operates anti-virus programs, it does not
> accept responsibility for any damage whatsoever caused by viruses being
> passed.
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> #######################################################################
> #
> #####################
> This e-mail message has been scanned for Viruses and cleared by NetIQ
> MailMarshal.
> #######################################################################
> #
> ######################
> ############################################################
> PLEASE NOTE:
>
> The information contained in this email message and any
> attached files may be confidential and subject to privilege.
> Any opinions expressed in this message are not necessarily
> those of the Department of Building and Housing. All technical
> opinions are offered on a ?no-liability? basis. This message
> and any files transmitted with it are confidential and solely
> for the use of the intended recipient. If you are not the
> intended recipient, you are notified that any use, disclosure
> or copying of this email is unauthorised. If you have received
> this email in error, please notify us immediately by reply email
> and delete the original and any attachment(s). Thank you.
> ############################################################
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
| robertsingers
Posts:571
| | 10/07/2008 5:39 PM |
| Not to be insulting but terms like "efficient" and "optimal" and "least
costly" are [in my experience] terms that engineering types throw into
arguments before going on to commit any number of logical fallacies.
They're terms that are meant to have meaning but don't unless the
participants come to an agreement of a) what they mean and b) how to
measure them.
You've agreed that bandwidth is a measurement of data over time.
Counting packets gives you the amount of data but it removes the
measurement of time. The amount of data only has a *cost* if you're
paying for the amount of data transferred not buying a fixed amount of
bandwidth.
If you're not paying based on the amount of data being transferred then
you have a fixed resource at your disposal that can be used to support
the business. The cost then becomes the potential for one transaction
across that resource to cause contention with any other. We enter the
realm then of things like Queuing Theory.
Two hundred 1K name resolution request in ten minutes is not directly
equivalent to one 200K. The 200K transaction has a much higher
probability of causing contention for the resource. If there is
contention then latency increases. Most network performance issues are
not caused by low bandwidth or poor throughput but by high latency. Not
to mention the potential for packet loss, or blocking of new
connections.
When these things happen the potential for transactions to fail and for
the perception of poor performance to the end user increases. So in
designing for the Enterprise "network cost" is a measurement of the
potential of one service or transaction to interfere with another.
"Optimal" is designing an architecture that makes the best possible use
of the resource I'm already paying for. And "least costly" is making
sure I match the pricing scheme and circuit type to that optimised
architecture.
So to answer your question I don't use packet counts, I use things like
tools like netflow and mrtg\rrdtool to create views of the traffic flow.
I then analyse those.
Working for the Evil Empire in the Asia-Pacific theatre we did a lot of
it because of the high cost and low bandwidth circuits available. To
solve any problem on the North American continent and in parts of Europe
they just threw extra T1s at a problem. We never had that luxery.
It's also worth pointing out that if Christine's remote sites don't have
fully switched networks, the "network costs" of local vs remote name
resolutions pretty much approach a 1:1 ratio.
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
Sent: Tuesday, 7 October 2008 5:40 p.m.
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
Robert,
I'm not sure meant by "removed the dimension of time", especially since
you then proceeded to concur that bandwidth measurement is done "over
time". When you calculate your TCO, do you just pick a random point in
time, or do you base it on measurable metrics OVER a period of time?
"Counting" packets transmitted is "irrelevant"? Really? What metric do
you typically use when you design these things? If you don't measure
packets, how do you arrive at your conclusions at the end of your
assessment as to which of a host of options is the most optimal and
least costly?
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.name - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon ________________________________________
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Robert Singers
[robert.singers@dbh.govt.nz]
Sent: Monday, October 06, 2008 8:43 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
I've checked the meaning of spurious to make sure and yes it was exactly
the word I wanted. Unless you are paying by the byte for network
transmission your implied definition of network cost is to my mind
faulty when evaluating the issue. Counting the packets transmitted by
each method is irrelevant because you've removed the dimension of time
from the equation. And bandwidth is a measurement of data over time;
both in the dictionary meaning of the word and common parlance. I'm not
a Statistician (although I often play one on the Internet) but my gut
feel is that name resolution traffic is so small as to be statistically
irrelevant when evaluating WAN performance Ώ]. Certainly my experience
of performing network captures for enterprise systems is that
authentication is a far different beast than name resolution when it
comes to network performance ΐ].
I may have totally misjudged what you mean by network cost and would be
happy for you to clarify.
Ώ] Where performance is measured in terms of [business] transactions
being able to be completed in acceptable times.
ΐ] I've yet to meet a pretty woman that will be impressed by the story
about how you diagnosed a SMB negotiation problem and escalated it to
"the Plant".
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
Sent: Tuesday, 7 October 2008 4:00 p.m.
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
I see what you are saying, Brian. But that is not the angle from which I
approached this in my initial response. My approach was whether local
name resolution of was more optimized and less costly than cross-WAN
resolution. My response was to the effect that since the servers are
already there, localized name resolution is more efficient and the
network cost associated with the zone transfer will be less than that
associated with clients going across the WAN to a centralized DNS
server.
>From the angle of "we're already doing cross-WAN authentication", I'd
like to point out that cross-WAN authentication traffic usually tapers
off after the initial spike in the morning. For much of the rest of the
day, you usually have very negligible authentication-related traffic.
Yes, I know that "it depends" on many factors as well, but generally
name resolution traffic is a lot more chatty and pervasive than
authentication traffic.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.name - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon ________________________________________
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
[brian@briandesmond.com]
Sent: Monday, October 06, 2008 7:32 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
However, given that the OP feels it's suitable to run authentication
traffic over the wire, the logical conclusion here is that there is
ample bandwidth for name resolution as well. A DNS lookup is far more
lightweight than everything involved with a user booting a PC and
logging in to it given it's joined to an AD domain...
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
Sent: Monday, October 06, 2008 9:06 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
Unless someone/something is incessantly writing to the zone,
creating/modifying an inordinately large number of records that is then
replicated across the wire, it is quite hard to imagine a condition in
which total bandwidth usage for an IXFR zone replication will surpass
the total bandwidth usage associated with cross-WAN client resolution
requests.
If the DNS partners were doing AXFR, then, yeah, it is quite easy to eat
up a lot of bandwidth doing zone transfer over a period of time. With
the exception of the seeding stage druing which the secondary partner
syncs up with the master, there is very little traffic associated with a
normal DNS replication process in a master/secondary topology. Just
measure it yourself.
And, no, the consideration of which choices utilizes more bandwidth is
not "spurious", Robert. At least not in the normal dictionary meaning of
that word. When you design an enterprise system like DNS, you always
want to know the cost associated with one choice or the other, not just
in terms of hardware and maintenance, but also in terms of the network
bandwidth, among others.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.name - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon ________________________________________
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Robert Singers
[robert.singers@dbh.govt.nz]
Sent: Monday, October 06, 2008 5:26 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
It's a spurious comparison.
The real question is what is going to impact users on the remote site
more. And the answer is that any large transaction across the WAN might
be noticed. So from a end user perspective a zone replication might be
noticeable, while any number of tiny name resolution requests spread
across time won't be.
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe, Deji
Sent: Tuesday, 7 October 2008 1:01 p.m.
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
You think that the DNS zone replication traffic will be higher than the
traffic associated with cross-WAN lookup requests?
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.name - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon ________________________________________
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Sabharanjak, Ravi BGI
SF [Ravi.Sabharanjak@barclaysglobal.com]
Sent: Monday, October 06, 2008 4:33 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
That will also save on the network replication of the DNS zones to the
remote sites. The client won't notice that the DNS server is remote.
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
Sent: Monday, October 06, 2008 1:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Decommissioning DC
I'm missing the point of having local DNS. If your WAN supports having
the DCs centralized, why can't DNS lookups be centralized too?
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
Christine.Allen@salemfive.com
Sent: Monday, October 06, 2008 2:15 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Decommissioning DC
Hello,
I'm hoping to get some advice. We have a windows 2003 forest with
three domains. A empty root, then two child domains, a main office
domain and a domain for our remote sites.
We currently have 18 domain controllers in the remote sites. Since all
sites are connected by fast connection, We want to decommission the
domain controllers and have them as member servers running DNS.
I know the steps on how to decommission the dc's. It should be easy
since they hold no roles. My question is more on setting up the proper
dns configuration. I'm going to configure secondary zones for the
remote domain and locke them down to replicate with the DNS master,
should I also set up secondary zones for the other child domain and the
empty root domain?
Any suggestions would be appreciated.
-Christine
Christine N. Allen
Sr. Systems Engineer
Salem Five
210 Essex Street
Salem, MA 01970
978-720-5928
christine.allen@salemfive.com
This information may be confidential and/or privileged. Use of this
information by anyone other than the intended recipient is prohibited.
If you received this in error, please inform the sender and remove any
record of this message.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
--
This message and any attachments are confidential, proprietary, and may
be privileged. If this message was misdirected, Barclays Global
Investors (BGI) does not waive any confidentiality or privilege. If you
are not the intended recipient, please notify us immediately and destroy
the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it
contains by other than an intended recipient is unauthorized. The views
and opinions expressed in this e-mail message are the author's own and
may not reflect the views and opinions of BGI, unless the author is
authorized by BGI to express such views or opinions on its behalf. All
email sent to or from this address is subject to electronic storage and
review by BGI. Although BGI operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
########################################################################
#####################
This e-mail message has been scanned for Viruses and cleared by NetIQ
MailMarshal.
########################################################################
######################
############################################################
PLEASE NOTE:
The information contained in this email message and any attached files
may be confidential and subject to privilege.
Any opinions expressed in this message are not necessarily those of the
Department of Building and Housing. All technical opinions are offered
on a ?no-liability? basis. This message and any files transmitted with
it are confidential and solely for the use of the intended recipient. If
you are not the intended recipient, you are notified that any use,
disclosure or copying of this email is unauthorised. If you have
received this email in error, please notify us immediately by reply
email and delete the original and any attachment(s). Thank you.
############################################################
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
| robertsingers
Posts:571
| | 10/07/2008 6:03 PM |
| James I'd turn this around slightly and start from the top of the OSI
stack rather than the bottom as it were.
What are the roles of the users on the site, what applications do they
need for those roles, what infrastructure services are needed to support
those applications. If the major line of business applications are all
over the wire, it becomes a question to the business of, if the circuit
goes do you switch to manual processing or do you send everyone home.
That's a much better way of working out the ROI of putting any
infrastructure or service on a site.
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of James Wells
Sent: Tuesday, 7 October 2008 11:47 p.m.
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Decommissioning DC
Yes and no.
I think that for most WAN design - since the bandwidth should generally
increase as you add hundreds or thousands of clients - then DNS traffic
of any kind becomes, to borrow Joe's phrase, a "rounding error" more
than something with an impact.
It's good to know what the impacts of DNS will be...but for most sites,
it just doesn't make a big enough difference.
Add to that the fullhard and soft TCO of a server (even a virtual,
sometimes) and local DNS doesn't always make business sense, depending
on what else is at the site.
So I think the answer USUALLY - what services are still operational when
a WAN link dies? If the answer is none or few, then local DNS probably
isn't a priority.
--James
On 10/7/08, Akomolafe, Deji <deji@readymaids.com> wrote:
> Robert,
>
> I'm not sure meant by "removed the dimension of time", especially
> since you then proceeded to concur that bandwidth measurement is done
"over time".
> When you calculate your TCO, do you just pick a random point in time,
> or do you base it on measurable metrics OVER a period of time?
>
> "Counting" packets transmitted is "irrelevant"? Really? What metric do
> you typically use when you design these things? If you don't measure
> packets, how do you arrive at your conclusions at the end of your
> assessment as to which of a host of options is the most optimal and
least costly?
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon ________________________________________
> From: ActiveDir-owner@mail.activedir.org
> [ActiveDir-owner@mail.activedir.org] On Behalf Of Robert Singers
> [robert.singers@dbh.govt.nz]
> Sent: Monday, October 06, 2008 8:43 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> I've checked the meaning of spurious to make sure and yes it was
> exactly the word I wanted. Unless you are paying by the byte for
> network transmission your implied definition of network cost is to my
> mind faulty when evaluating the issue. Counting the packets
> transmitted by each method is irrelevant because you've removed the
> dimension of time from the equation. And bandwidth is a measurement
> of data over time; both in the dictionary meaning of the word and
> common parlance. I'm not a Statistician (although I often play one on
> the Internet) but my gut feel is that name resolution traffic is so
> small as to be statistically irrelevant when evaluating WAN
> performance Ώ]. Certainly my experience of performing network
> captures for enterprise systems is that authentication is a far
> different beast than name resolution when it comes to network
performance ΐ].
>
> I may have totally misjudged what you mean by network cost and would
> be happy for you to clarify.
>
> Ώ] Where performance is measured in terms of [business] transactions
> being able to be completed in acceptable times.
>
> ΐ] I've yet to meet a pretty woman that will be impressed by the
> story about how you diagnosed a SMB negotiation problem and escalated
> it to "the Plant".
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> Deji
> Sent: Tuesday, 7 October 2008 4:00 p.m.
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> I see what you are saying, Brian. But that is not the angle from which
> I approached this in my initial response. My approach was whether
> local name resolution of was more optimized and less costly than
> cross-WAN resolution. My response was to the effect that since the
> servers are already there, localized name resolution is more efficient
> and the network cost associated with the zone transfer will be less
> than that associated with clients going across the WAN to a
> centralized DNS server.
>
> >From the angle of "we're already doing cross-WAN authentication", I'd
> like to point out that cross-WAN authentication traffic usually tapers
> off after the initial spike in the morning. For much of the rest of
> the day, you usually have very negligible authentication-related
traffic.
> Yes, I know that "it depends" on many factors as well, but generally
> name resolution traffic is a lot more chatty and pervasive than
> authentication traffic.
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon ________________________________________
> From: ActiveDir-owner@mail.activedir.org
> [ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
> [brian@briandesmond.com]
> Sent: Monday, October 06, 2008 7:32 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> However, given that the OP feels it's suitable to run authentication
> traffic over the wire, the logical conclusion here is that there is
> ample bandwidth for name resolution as well. A DNS lookup is far more
> lightweight than everything involved with a user booting a PC and
> logging in to it given it's joined to an AD domain...
>
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> Deji
> Sent: Monday, October 06, 2008 9:06 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> Unless someone/something is incessantly writing to the zone,
> creating/modifying an inordinately large number of records that is
> then replicated across the wire, it is quite hard to imagine a
> condition in which total bandwidth usage for an IXFR zone replication
> will surpass the total bandwidth usage associated with cross-WAN
> client resolution requests.
>
> If the DNS partners were doing AXFR, then, yeah, it is quite easy to
> eat up a lot of bandwidth doing zone transfer over a period of time.
> With the exception of the seeding stage druing which the secondary
> partner syncs up with the master, there is very little traffic
> associated with a normal DNS replication process in a master/secondary
> topology. Just measure it yourself.
>
> And, no, the consideration of which choices utilizes more bandwidth is
> not "spurious", Robert. At least not in the normal dictionary meaning
> of that word. When you design an enterprise system like DNS, you
> always want to know the cost associated with one choice or the other,
> not just in terms of hardware and maintenance, but also in terms of
> the network bandwidth, among others.
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon ________________________________________
> From: ActiveDir-owner@mail.activedir.org
> [ActiveDir-owner@mail.activedir.org] On Behalf Of Robert Singers
> [robert.singers@dbh.govt.nz]
> Sent: Monday, October 06, 2008 5:26 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> It's a spurious comparison.
>
> The real question is what is going to impact users on the remote site
> more. And the answer is that any large transaction across the WAN
> might be noticed. So from a end user perspective a zone replication
> might be noticeable, while any number of tiny name resolution requests
> spread across time won't be.
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> Deji
> Sent: Tuesday, 7 October 2008 1:01 p.m.
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> You think that the DNS zone replication traffic will be higher than
> the traffic associated with cross-WAN lookup requests?
>
>
> Sincerely,
> _____
> (, / | /) /) /)
> /---| (/_ ______ ___// _ // _
> ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
> (_/ /)
> (/
> Microsoft MVP - Directory Services
> www.akomolafe.name - we know IT
> -5.75, -3.23
> Do you now realize that Today is the Tomorrow you were worried about
> Yesterday? -anon ________________________________________
> From: ActiveDir-owner@mail.activedir.org
> [ActiveDir-owner@mail.activedir.org] On Behalf Of Sabharanjak, Ravi
> BGI SF [Ravi.Sabharanjak@barclaysglobal.com]
> Sent: Monday, October 06, 2008 4:33 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> That will also save on the network replication of the DNS zones to the
> remote sites. The client won't notice that the DNS server is remote.
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
> Sent: Monday, October 06, 2008 1:19 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Decommissioning DC
>
> I'm missing the point of having local DNS. If your WAN supports having
> the DCs centralized, why can't DNS lookups be centralized too?
>
> Thanks,
> Brian Desmond
> brian@briandesmond.com
>
> c - 312.731.3132
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of
> Christine.Allen@salemfive.com
> Sent: Monday, October 06, 2008 2:15 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Decommissioning DC
>
> Hello,
>
> I'm hoping to get some advice. We have a windows 2003 forest with
> three domains. A empty root, then two child domains, a main office
> domain and a domain for our remote sites.
>
> We currently have 18 domain controllers in the remote sites. Since
> all sites are connected by fast connection, We want to decommission
> the domain controllers and have them as member servers running DNS.
>
> I know the steps on how to decommission the dc's. It should be easy
> since they hold no roles. My question is more on setting up the proper
> dns configuration. I'm going to configure secondary zones for the
> remote domain and locke them down to replicate with the DNS master,
> should I also set up secondary zones for the other child domain and
> the empty root domain?
>
> Any suggestions would be appreciated.
>
>
>
> -Christine
>
> Christine N. Allen
> Sr. Systems Engineer
> Salem Five
> 210 Essex Street
> Salem, MA 01970
> 978-720-5928
> christine.allen@salemfive.com
>
>
> This information may be confidential and/or privileged. Use of this
> information by anyone other than the intended recipient is prohibited.
> If you received this in error, please inform the sender and remove any
> record of this message.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
> --
>
> This message and any attachments are confidential, proprietary, and
> may be privileged. If this message was misdirected, Barclays Global
> Investors (BGI) does not waive any confidentiality or privilege. If
> you are not the intended recipient, please notify us immediately and
> destroy the message without disclosing its contents to anyone. Any
> distribution, use or copying of this e-mail or the information it
> contains by other than an intended recipient is unauthorized. The
> views and opinions expressed in this e-mail message are the author's
> own and may not reflect the views and opinions of BGI, unless the
> author is authorized by BGI to express such views or opinions on its
> behalf. All email sent to or from this address is subject to
> electronic storage and review by BGI. Although BGI operates
> anti-virus programs, it does not accept responsibility for any damage
> whatsoever caused by viruses being passed.
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> ######################################################################
> ##
> #####################
> This e-mail message has been scanned for Viruses and cleared by NetIQ
> MailMarshal.
> ######################################################################
> ##
> ######################
> ############################################################
> PLEASE NOTE:
>
> The information contained in this email message and any attached files
> may be confidential and subject to privilege.
> Any opinions expressed in this message are not necessarily those of
> the Department of Building and Housing. All technical opinions are
> offered on a ?no-liability? basis. This message and any files
> transmitted with it are confidential and solely for the use of the
> intended recipient. If you are not the intended recipient, you are
> notified that any use, disclosure or copying of this email is
> unauthorised. If you have received this email in error, please notify
> us immediately by reply email and delete the original and any
attachment(s). Thank you.
> ############################################################
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ma/default.aspx
>
--
Sent from my mobile device
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
|
|