again, only recommended if running Premium with ISA installed...otherwise not necessarily recommended and certainly not required

--
Cris Hanna [SBS-MVP]
------------------------------------------
MVPs Do Not Work For Microsoft
-----------------------------------------------------
Please do not contact me directly. Please post only in the newsgroup so all can benefit


"Teneo" <not@here.com> wrote in message news:u$l1m0hrIHA.524@TK2MSFTNGP05.phx.gbl...
As per microsoft 'recommended'
http://www.microsoft.com/Windowsserv.../default..mspx

Also in the installation guides, but who reads them... :-)

I too support enterprise, Exchange is not recommended on a DC outside of SBS
land but we all know the SBS team have done a terrific job.

But as Charlie points out ... things are changing in 2008


"Lanwench [MVP - Exchange]"
<lanwench@heybuddy.donotsendme.unsolicitedmailatya hoo.com> wrote in message
news:Oe$V2ChrIHA.4788@TK2MSFTNGP03.phx.gbl...
> Teneo <not@here.com> wrote:
>> Just to add, I disagree with SINGLE NIC..., Hi Lanwench... lol
>>
>> Make your own decision whether you go single nic or 'as recommended by
>> microsoft / sbs ' dual nic.
>>
>> Ciao
>
> Yes, of course, but I don't know that Microsoft officially recommends two
> NICs (esp. if you've got a decent firewall, which you absolutely should in
> any case).
>
> Note that I work not only with SBS but with the enterprise products in
> plenty of my clients' offices. Outside of SBS-land, two NICs in a domain
> controller/DNS server is considered bad practice.
>
>
>>
>>
>> "Lanwench [MVP - Exchange]"
>> <lanwench@heybuddy.donotsendme.unsolicitedmailatya hoo.com> wrote in
>> message news:%23Oayo2frIHA.3900@TK2MSFTNGP05.phx.gbl...
>>> Terry <Terry@discussions.microsoft.com> wrote:
>>>> OK but as I said the IPS owns the router, it was like pulling teeth
>>>> to have them point the first DNS IP to the server. THey will NOT
>>>> allow us to remove it form doing DNS
>>>
>>> Have them undo what they did. You need your *own* router/firewall
>>> appliance between your network & their equipment - something that
>>> does NAT. You haven't mentioned whether you'r running ISA or not,
>>> but if you aren't, use a single NIC in your server and plug it, and
>>> your clients, and *your* firewall/router, into the same Ethernet
>>> switch.
>>>>
>>>> "Lanwench [MVP - Exchange]" wrote:
>>>>
>>>>> Terry <Terry@discussions.microsoft.com> wrote:
>>>>>> I have a new Windows 2003 Business Server. Everything seems to
>>>>>> work, can get to the web do updates, etc.
>>>>>> However none of the workstations can join the Domain, I have the
>>>>>> DNS on the work stations pointing to the new server. The
>>>>>> workstations cannot ping the server. However the Server CAN ping
>>>>>> the work stations. What am I missing?
>>>>>
>>>>> 1) It's best to post SBS questions in
>>>>> microsoft.public.windows.server.sbs - SBS does many things its own
>>>>> way
>>>>>
>>>>> 2) DNS must be handled by your SBS box alone, not your router (the
>>>>> CEICW will prompt you for your ISP's DNS servers)
>>>>>
>>>>> 3) DHCP should be handled by your SBS box, not your router
>>>>>
>>>>> 4) You need to use the setup wizards for *everything* in SBS- do
>>>>> not try to join computers to the domain the non-SBS way or you
>>>>> will end up with problems.
>>>>>
>>>>> I'm setting up my reply to crosspost to the SBS group for your
>>>>> convenience in this thread - but again, post all future SBS
>>>>> questions in there for the best results, even if you also crosspost
>>>>> (not multipost!) to other groups.
>
>
>

Joe wrote:
> Terry wrote:
>> OK but as I said the IPS owns the router, it was like pulling teeth to
>> have them point the first DNS IP to the server. THey will NOT allow us
>> to remove it form doing DNS
>>
> That doesn't really matter, there can be any number of DNS servers in a
> network. It's up to a client which server it uses. It's DHCP where only
> a single server is practical, and if your SBS has two NICs then it
> doesn't matter whether the router is a DHCP server or not, as the
> workstations won't see it. Nor does the router need to use SBS as its
> DNS server, but the SBS and all its domain member computers *must* do so.
>
> That point cannot be overemphasised. The SBS and all its domain member
> clients must shown *only* the SBS LAN IP address under DNS servers as
> listed by an ipconfig command. The SBS DNS server provides
> domain-specific information which no public DNS server can possibly have.
>
> The SBS may use either a local router, the ISP's DNS servers (which the
> router probably uses anyway), any other public DNS servers, or none at
> all as its DNS *forwarders*, for lookups of public Internet IP
> addresses, and these addresses are entered (or not) in the CEICW wizard.
>
> Under normal conditions, the SBS runs both DHCP and DNS servers for its
> workstations, which are all set to get IP address and DNS server
> information automatically. No domain machine should ever need or get IP
> or DNS server addresses set manually in TCP/IP properties. If any need
> fixed addresses, find out their MAC addresses and set up DHCP
> reservations for them.
"The SBS and all its domain member clients must shown *only* the SBS LAN
IP address under DNS servers"

This is wrong. You obviously put the SBS box in there first but having
other external DNS IPs allows the clients to resolve and still use the
Internet if the server is down. Also if there is a second domain
controller that would be listed.

Note that if you use the 2 NIC solution then you will not be able to get
to any DNS servers of course - but that way of setting up SBS is
completely wrong as far as I'm concerned in most installs. Thank
goodness MS has seen sense and scrapped this idea with SBS 2008.

aus <aus@aus.net> wrote:

<snipped for length>
>
> This is wrong. You obviously put the SBS box in there first but having
> other external DNS IPs allows the clients to resolve and still use the
> Internet if the server is down.

No, Joe was correct. You never put an external DNS server's IP in your
client or server IP configuration, ever. This is a huge no-no in AD, whether
using SBS or not.
http://support.microsoft.com/default...b;en-us;300202


> Also if there is a second domain
> controller that would be listed.

Only if it's running DNS for the internal zone and also has forwarders /
root hints.

>
> Note that if you use the 2 NIC solution then you will not be able to
> get to any DNS servers of course - but that way of setting up SBS is
> completely wrong as far as I'm concerned in most installs

Lanwench [MVP - Exchange] wrote:
> aus <aus@aus.net> wrote:
>
> <snipped for length>
>> This is wrong. You obviously put the SBS box in there first but having
>> other external DNS IPs allows the clients to resolve and still use the
>> Internet if the server is down.
>
> No, Joe was correct. You never put an external DNS server's IP in your
> client or server IP configuration, ever. This is a huge no-no in AD, whether
> using SBS or not.
>
>
>


No, he isnt and you should know better than repeat mis-advice.

Yes you need DNS in AD to log on properly but if your SBS server is down
then that's irrelevant - having secondary DNS specified allows you to
access the Internet still. If you don't then clients cant get off the LAN.

If you think this causes an issue you need to explain technically why.
It doesnt cause an issue, but Id like to know your logic.


>> Also if there is a second domain
>> controller that would be listed.
>
> Only if it's running DNS for the internal zone and also has forwarders /
> root hints.
>

Yes, DNS needs to be running on a server for you to use it - maybe some
wouldnt realise that(!)



>> Note that if you use the 2 NIC solution then you will not be able to
>> get to any DNS servers of course - but that way of setting up SBS is
>> completely wrong as far as I'm concerned in most installs
>
>
>
>
>
>

aus <aus@aus.net> wrote:
> Lanwench [MVP - Exchange] wrote:
>> aus <aus@aus.net> wrote:
>>
>> <snipped for length>
>>> This is wrong. You obviously put the SBS box in there first but
>>> having other external DNS IPs allows the clients to resolve and
>>> still use the Internet if the server is down.
>>
>> No, Joe was correct. You never put an external DNS server's IP in
>> your client or server IP configuration, ever. This is a huge no-no
>> in AD, whether using SBS or not.

>
> No, he isnt and you should know better than repeat mis-advice.

Again: I'm correct, as is Joe. Sorry. If you don't understand this bit, you
don't understand how DNS &
AD work.
>
> Yes you need DNS in AD to log on properly

> not just for login.

> but if your SBS server is
> down

(which it shouldn't be, but that's not really germane here)

> then that's irrelevant - having secondary DNS specified allows
> you to access the Internet still. If you don't then clients cant get
> off the LAN.
>
> If you think this causes an issue you need to explain technically why.

I *need* to? Perhaps English isn't your first language, but note that your
"tone" in this thread is bordering on belligerent - be polite.

Here's the basics: If the client for *any* reason cannot at some moment
successfully interrogate the internal/primary DNS server (as in, your
internal DNS server isn't quite fast enough to respond - not necessarily
that it's offline), it will happily flip over to the next (secondary). It
will continue to use the secondary until it is rebooted or otherwise forced
to do otherwise. And while it is using the secondary, it will no longer be
able to communicate properly with the domain controller(s) via DNS, which
will cause a slew of problems.

> It doesnt cause an issue,

Yes, it does - see above.

> but Id like to know your logic.

Try posting in microsoft.public.windows.server.dns and
microsoft.public.windows. for more info, if the KB
article I gave you (and your own innate ability to google) were insufficient
to get you started.

http://www.google.com/search?q=DNS+A...L_enUS249US249
may .

>
>
>>> Also if there is a second domain
>>> controller that would be listed.
>>
>> Only if it's running DNS for the internal zone and also has
>> forwarders / root hints.
>>
>
> Yes, DNS needs to be running on a server for you to use it - maybe
> some wouldnt realise that(!)

Well, it's important to mention. Remember, not all DCs are DNS servers, nor
need they be.

This is now veering way off topic and I need to wrap it
up in this thread.

aus wrote:
> Lanwench [MVP - Exchange] wrote:
>> aus <aus@aus.net> wrote:
>>
>> <snipped for length>
>>> This is wrong. You obviously put the SBS box in there first but
>>> having other external DNS IPs allows the clients to resolve and
>>> still use the Internet if the server is down.
>>
>> No, Joe was correct. You never put an external DNS server's IP in
>> your client or server IP configuration, ever. This is a huge no-no
>> in AD, whether using SBS or not.
>>
>>
>>
>
>
> No, he isnt and you should know better than repeat mis-advice.

You are getting sound advice on SBS and relevant to all other AD client DNS
configurations.

Look into it. If you need the MS KB that describes the issues with DNS
client fallback, I'm sure one of us can dig it up for you.

(Just adding my vote of confirmation to those before me)

--
/kj

slight mod:

the DNS client continues to use the alternate DNS server until:
1) the DNS client is restarted.
2) the DNS client fails to get a reply from the alternate DNS server
3) a time period passes (I think default is 15min, can't find article)

NOTE: it is 'failure to receive a reply', not negative reply, that causes
the change. (Lanwench knows this, I just wanted to clarify for the OP)

"Lanwench [MVP - Exchange]"
<lanwench@heybuddy.donotsendme.unsolicitedmailatya hoo.com> wrote in message
news:uUMc19srIHA.5060@TK2MSFTNGP03.phx.gbl...
> aus <aus@aus.net> wrote:
>> Lanwench [MVP - Exchange] wrote:
>>> aus <aus@aus.net> wrote:
>>>
>>> <snipped for length>
>>>> This is wrong. You obviously put the SBS box in there first but
>>>> having other external DNS IPs allows the clients to resolve and
>>>> still use the Internet if the server is down.
>>>
>>> No, Joe was correct. You never put an external DNS server's IP in
>>> your client or server IP configuration, ever. This is a huge no-no
>>> in AD, whether using SBS or not.
>
>>
>> No, he isnt and you should know better than repeat mis-advice.
>
> Again: I'm correct, as is Joe. Sorry. If you don't understand this bit,
> you don't understand how DNS &
> AD work.
>>
>> Yes you need DNS in AD to log on properly
>
>> not just for login.
>
>> but if your SBS server is
>> down
>
> (which it shouldn't be, but that's not really germane here)
>
>> then that's irrelevant - having secondary DNS specified allows
>> you to access the Internet still. If you don't then clients cant get
>> off the LAN.
>>
>> If you think this causes an issue you need to explain technically why.
>
> I *need* to? Perhaps English isn't your first language, but note that your
> "tone" in this thread is bordering on belligerent - be polite.
>
> Here's the basics: If the client for *any* reason cannot at some moment
> successfully interrogate the internal/primary DNS server (as in, your
> internal DNS server isn't quite fast enough to respond - not necessarily
> that it's offline), it will happily flip over to the next (secondary). It
> will continue to use the secondary until it is rebooted or otherwise
> forced to do otherwise. And while it is using the secondary, it will no
> longer be able to communicate properly with the domain controller(s) via
> DNS, which will cause a slew of problems.
>
>> It doesnt cause an issue,
>
> Yes, it does - see above.
>
>> but Id like to know your logic.
>
> Try posting in microsoft.public.windows.server.dns and
> microsoft.public.windows. for more info, if the KB
> article I gave you (and your own innate ability to google) were
> insufficient
> to get you started.
>
> http://www.google.com/search?q=DNS+A...L_enUS249US249
> may .
>
>>
>>
>>>> Also if there is a second domain
>>>> controller that would be listed.
>>>
>>> Only if it's running DNS for the internal zone and also has
>>> forwarders / root hints.
>>>
>>
>> Yes, DNS needs to be running on a server for you to use it - maybe
>> some wouldnt realise that(!)
>
> Well, it's important to mention. Remember, not all DCs are DNS servers,
> nor
> need they be.
>
> This is now veering way off topic and I need to wrap it
> up in this thread.
>

closest article so far

http://support.microsoft.com/kb/291382/en-us
Answer: The most common mistakes are: . The domain controller is not
pointing to itself for DNS resolution on all network interfaces.
. The "." zone exists under forward lookup zones in DNS.
. Other computers on the local area network (LAN) do not point to the
Windows 2000 or Windows Server 2003 DNS server for DNS.



"kj [SBS MVP]" <KevinJ.SBS@SPAMFREE.gmail.com> wrote in message
news:eotRYGtrIHA.800@TK2MSFTNGP02.phx.gbl...
> aus wrote:
>> Lanwench [MVP - Exchange] wrote:
>>> aus <aus@aus.net> wrote:
>>>
>>> <snipped for length>
>>>> This is wrong. You obviously put the SBS box in there first but
>>>> having other external DNS IPs allows the clients to resolve and
>>>> still use the Internet if the server is down.
>>>
>>> No, Joe was correct. You never put an external DNS server's IP in
>>> your client or server IP configuration, ever. This is a huge no-no
>>> in AD, whether using SBS or not.
>>>
>>>
>>>
>>
>>
>> No, he isnt and you should know better than repeat mis-advice.
>
> You are getting sound advice on SBS and relevant to all other AD client
> DNS configurations.
>
> Look into it. If you need the MS KB that describes the issues with DNS
> client fallback, I'm sure one of us can dig it up for you.
>
> (Just adding my vote of confirmation to those before me)
>
> --
> /kj
>

Lanwench [MVP - Exchange] wrote:
> aus <aus@aus.net> wrote:
>> Lanwench [MVP - Exchange] wrote:
>>> aus <aus@aus.net> wrote:
>>>
>>> <snipped for length>
>>>> This is wrong. You obviously put the SBS box in there first but
>>>> having other external DNS IPs allows the clients to resolve and
>>>> still use the Internet if the server is down.
>>> No, Joe was correct. You never put an external DNS server's IP in
>>> your client or server IP configuration, ever. This is a huge no-no
>>> in AD, whether using SBS or not.
>
>> No, he isnt and you should know better than repeat mis-advice.
>
> Again: I'm correct, as is Joe. Sorry. If you don't understand this bit, you
> don't understand how DNS &
> AD work.
>> Yes you need DNS in AD to log on properly
>
>> not just for login.
>
>> but if your SBS server is
>> down
>
> (which it shouldn't be, but that's not really germane here)
>
>> then that's irrelevant - having secondary DNS specified allows
>> you to access the Internet still. If you don't then clients cant get
>> off the LAN.
>>
>> If you think this causes an issue you need to explain technically why.
>
> I *need* to? Perhaps English isn't your first language, but note that your
> "tone" in this thread is bordering on belligerent - be polite.
>
> Here's the basics: If the client for *any* reason cannot at some moment
> successfully interrogate the internal/primary DNS server (as in, your
> internal DNS server isn't quite fast enough to respond - not necessarily
> that it's offline), it will happily flip over to the next (secondary). It
> will continue to use the secondary until it is rebooted or otherwise forced
> to do otherwise. And while it is using the secondary, it will no longer be
> able to communicate properly with the domain controller(s) via DNS, which
> will cause a slew of problems.
>
>> It doesnt cause an issue,
>
> Yes, it does - see above.
>
>> but Id like to know your logic.
>
> Try posting in microsoft.public.windows.server.dns and
> microsoft.public.windows. for more info, if the KB
> article I gave you (and your own innate ability to google) were insufficient
> to get you started.
>
> http://www.google.com/search?q=DNS+A...L_enUS249US249
> may .
>
>>
>>>> Also if there is a second domain
>>>> controller that would be listed.
>>> Only if it's running DNS for the internal zone and also has
>>> forwarders / root hints.
>>>
>> Yes, DNS needs to be running on a server for you to use it - maybe
>> some wouldnt realise that(!)
>
> Well, it's important to mention. Remember, not all DCs are DNS servers, nor
> need they be.
>
> This is now veering way off topic and I need to wrap it
> up in this thread.
>
>

Sorry, didn't mean to appear 'belligerent'(!) Many quote MS articles
without engaging thought or have experience of the wider world of real
and varied implementation. The SBS board is a bit like Stepford on
occasion.. (some here will know exactly what I mean)..

'Microsoft Says so its TURE!..', 'You must use the Wizard damn you..'
'Shame on you, you will die if you have a second Exchange server'


The point is a wider one that many never consider.

On a 75 user network DNS should never be busy - well I've never seen it
or heard it mentioned. Out of all the services MS has blessed us with
DNS is actually one of the most reliable.

The DNS time out on Windows client side is 17 seconds, so quite a long
"moment" (and thats after the client resolver cache has been checked).
If a client can't get to DNS on a properly running SBS LAN in that time
DNS almost certainly not running - not busy.

Far more likely is that the the SBS server is down - which every network
has from time to time - planned or not. With only the SBS DNS available
no client has Internet access. Having an external DNS, if you dont have
an internal backup, gives users that Internet access.

If you don't care about Internet access when SBS is down then ok, but
most users do want this as it gives some continuity of business, which
IS the whole point. The SBS server never going down isn't reality.

If you do actually see DNS time outs on your networks then you will
indeed be seeing many other issues anyway. But its not reality or do you
actually get these?

But lets say your client is timing out, so the client switches to the
external secondary (that can't resolve to AD) - it eventually times out
(another 17 seconds) and then locally resolves the name anyway using
local broadcast as NBT is on by default. You would see a long delay but
the client wouldn't fail resolution on the local SBS subnet.

However as I have this setup at multiple sites over the last few years I
know this scenario doesn't happen. If you were somehow experiencing this
you can set the DNS client service to try the full list each time (ie.
start with the primary each time and not switch to the secondary for the
duration of the session) - but I have never had to do this.


Stop, think, and then test it and see the advantage (for your clients)
rather than an MS article.


(And not all DCs are DNS, but its a very good idea that they are for
redundancy, specially if you only use one DNS on SBS.)

and there's some discussion here:

http://support.microsoft.com/kb/825036/en-us
Best practices for DNS client settings in Windows 2000 Server and in Windows
Server 2003

"SuperGumby [SBS MVP]" <not@your.nellie> wrote in message
news:eLTirOwrIHA.2188@TK2MSFTNGP04.phx.gbl...
> closest article so far
>
> http://support.microsoft.com/kb/291382/en-us
> Answer: The most common mistakes are: . The domain controller is not
> pointing to itself for DNS resolution on all network interfaces.
> . The "." zone exists under forward lookup zones in DNS.
> . Other computers on the local area network (LAN) do not point to the
> Windows 2000 or Windows Server 2003 DNS server for DNS.
>
>
>
> "kj [SBS MVP]" <KevinJ.SBS@SPAMFREE.gmail.com> wrote in message
> news:eotRYGtrIHA.800@TK2MSFTNGP02.phx.gbl...
>> aus wrote:
>>> Lanwench [MVP - Exchange] wrote:
>>>> aus <aus@aus.net> wrote:
>>>>
>>>> <snipped for length>
>>>>> This is wrong. You obviously put the SBS box in there first but
>>>>> having other external DNS IPs allows the clients to resolve and
>>>>> still use the Internet if the server is down.
>>>>
>>>> No, Joe was correct. You never put an external DNS server's IP in
>>>> your client or server IP configuration, ever. This is a huge no-no
>>>> in AD, whether using SBS or not.
>>>>
>>>>
>>>>
>>>
>>>
>>> No, he isnt and you should know better than repeat mis-advice.
>>
>> You are getting sound advice on SBS and relevant to all other AD client
>> DNS configurations.
>>
>> Look into it. If you need the MS KB that describes the issues with DNS
>> client fallback, I'm sure one of us can dig it up for you.
>>
>> (Just adding my vote of confirmation to those before me)
>>
>> --
>> /kj
>>
>
>

NO. In this scenario the DNS request for AD records does not timeout, it
gets a negative reply.

Don't kick yourself too hard, the incidence of people misunderstanding the
operation of the DNS client is high.

If an AD member (Server or workstation) is configured to use an AD aware
server as primary and a non-AD aware server as secondary 3 things can happen
to a query:
1) the query is satisfied (either correctly or incorrectly). Client: where
is this name please? Server: it is here.
2) the query is responded to in the negative. Client: where is this name
please? Server: name does not exist in DNS.
3) a timeout occurs, the query is not satisfied within the DNS client
timeout.

only action 3 causes the DNS client to consult it's list of DNS servers and
possibly change server.

The problem comes when the alternate (non AD aware) server is queried.
Queries for AD resources are 'responded to in the negative' because the non
AD aware server believes the names do not exist. The DNS client, having
received a reply (name does not exist in DNS), does not attempt resolution
via other listed servers.

The 'fix' is to reduce the DNS client ServerPriorityTimeLimit, possibly to
zero. I _DO NOT_ endorse this action.

"aus" <aus@aus.net> wrote in message
news:%239NoGRwrIHA.484@TK2MSFTNGP04.phx.gbl...
<snip>

> The DNS time out on Windows client side is 17 seconds, so quite a long
> "moment" (and thats after the client resolver cache has been checked). If
> a client can't get to DNS on a properly running SBS LAN in that time DNS
> almost certainly not running - not busy.
>
> Far more likely is that the the SBS server is down - which every network
> has from time to time - planned or not. With only the SBS DNS available no
> client has Internet access. Having an external DNS, if you dont have an
> internal backup, gives users that Internet access.
>
> If you don't care about Internet access when SBS is down then ok, but most
> users do want this as it gives some continuity of business, which IS the
> whole point. The SBS server never going down isn't reality.
>
> If you do actually see DNS time outs on your networks then you will indeed
> be seeing many other issues anyway. But its not reality or do you actually
> get these?
>
> But lets say your client is timing out, so the client switches to the
> external secondary (that can't resolve to AD) - it eventually times out
> (another 17 seconds) and then locally resolves the name anyway using local
> broadcast as NBT is on by default. You would see a long delay but the
> client wouldn't fail resolution on the local SBS subnet.
>
> However as I have this setup at multiple sites over the last few years I
> know this scenario doesn't happen. If you were somehow experiencing this
> you can set the DNS client service to try the full list each time (ie.
> start with the primary each time and not switch to the secondary for the
> duration of the session) - but I have never had to do this.
>
>
> Stop, think, and then test it and see the advantage (for your clients)
> rather than an MS article.
>
>
> (And not all DCs are DNS, but its a very good idea that they are for
> redundancy, specially if you only use one DNS on SBS.)
>
>

SuperGumby [SBS MVP] wrote:
> and there's some discussion here:
>
> http://support.microsoft.com/kb/825036/en-us
> Best practices for DNS client settings in Windows 2000 Server and in Windows
> Server 2003
>
> "SuperGumby [SBS MVP]" <not@your.nellie> wrote in message
> news:eLTirOwrIHA.2188@TK2MSFTNGP04.phx.gbl...
>> closest article so far
>>
>> http://support.microsoft.com/kb/291382/en-us
>> Answer: The most common mistakes are: . The domain controller is not
>> pointing to itself for DNS resolution on all network interfaces.
>> . The "." zone exists under forward lookup zones in DNS.
>> . Other computers on the local area network (LAN) do not point to the
>> Windows 2000 or Windows Server 2003 DNS server for DNS.
>>
>>
>>
>> "kj [SBS MVP]" <KevinJ.SBS@SPAMFREE.gmail.com> wrote in message
>> news:eotRYGtrIHA.800@TK2MSFTNGP02.phx.gbl...
>>> aus wrote:
>>>> Lanwench [MVP - Exchange] wrote:
>>>>> aus <aus@aus.net> wrote:
>>>>>
>>>>> <snipped for length>
>>>>>> This is wrong. You obviously put the SBS box in there first but
>>>>>> having other external DNS IPs allows the clients to resolve and
>>>>>> still use the Internet if the server is down.
>>>>> No, Joe was correct. You never put an external DNS server's IP in
>>>>> your client or server IP configuration, ever. This is a huge no-no
>>>>> in AD, whether using SBS or not.
>>>>>
>>>>>
>>>>>
>>>>
>>>> No, he isnt and you should know better than repeat mis-advice.
>>> You are getting sound advice on SBS and relevant to all other AD client
>>> DNS configurations.
>>>
>>> Look into it. If you need the MS KB that describes the issues with DNS
>>> client fallback, I'm sure one of us can dig it up for you.
>>>
>>> (Just adding my vote of confirmation to those before me)
>>>
>>> --
>>> /kj
>>>
>>
>
>

Hi, thanks for those - a very good place to read about DNS (hope others
here read them!). Note that these are talking about DNS settings on
Windows Servers mainly, which I DONT advocate should have an external
DNS specified.

Client PCs should indeed have internal servers as their Primary but its
perfectly legitimate to use the secondary set to an external one as a
backup so Internet access is retained when the SBS is off.

Essentially if this didn't work I wouldn't use it but some wont think
through how it works and the advantages, but that's their network at the
end of the day!


And I had forgotten that the DNS provider order is reset after 15 mins
anyway - and not held for the complete session.

SuperGumby [SBS MVP] wrote:
> NO. In this scenario the DNS request for AD records does not timeout, it
> gets a negative reply.
>
> Don't kick yourself too hard, the incidence of people misunderstanding the
> operation of the DNS client is high.
>
> If an AD member (Server or workstation) is configured to use an AD aware
> server as primary and a non-AD aware server as secondary 3 things can happen
> to a query:
> 1) the query is satisfied (either correctly or incorrectly). Client: where
> is this name please? Server: it is here.
> 2) the query is responded to in the negative. Client: where is this name
> please? Server: name does not exist in DNS.
> 3) a timeout occurs, the query is not satisfied within the DNS client
> timeout.
>
> only action 3 causes the DNS client to consult it's list of DNS servers and
> possibly change server.
>
> The problem comes when the alternate (non AD aware) server is queried.
> Queries for AD resources are 'responded to in the negative' because the non
> AD aware server believes the names do not exist. The DNS client, having
> received a reply (name does not exist in DNS), does not attempt resolution
> via other listed servers.
>
> The 'fix' is to reduce the DNS client ServerPriorityTimeLimit, possibly to
> zero. I _DO NOT_ endorse this action.
>
> "aus" <aus@aus.net> wrote in message
> news:%239NoGRwrIHA.484@TK2MSFTNGP04.phx.gbl...
> <snip>
>
>> The DNS time out on Windows client side is 17 seconds, so quite a long
>> "moment" (and thats after the client resolver cache has been checked). If
>> a client can't get to DNS on a properly running SBS LAN in that time DNS
>> almost certainly not running - not busy.
>>
>> Far more likely is that the the SBS server is down - which every network
>> has from time to time - planned or not. With only the SBS DNS available no
>> client has Internet access. Having an external DNS, if you dont have an
>> internal backup, gives users that Internet access.
>>
>> If you don't care about Internet access when SBS is down then ok, but most
>> users do want this as it gives some continuity of business, which IS the
>> whole point. The SBS server never going down isn't reality.
>>
>> If you do actually see DNS time outs on your networks then you will indeed
>> be seeing many other issues anyway. But its not reality or do you actually
>> get these?
>>
>> But lets say your client is timing out, so the client switches to the
>> external secondary (that can't resolve to AD) - it eventually times out
>> (another 17 seconds) and then locally resolves the name anyway using local
>> broadcast as NBT is on by default. You would see a long delay but the
>> client wouldn't fail resolution on the local SBS subnet.
>>
>> However as I have this setup at multiple sites over the last few years I
>> know this scenario doesn't happen. If you were somehow experiencing this
>> you can set the DNS client service to try the full list each time (ie.
>> start with the primary each time and not switch to the secondary for the
>> duration of the session) - but I have never had to do this.
>>
>>
>> Stop, think, and then test it and see the advantage (for your clients)
>> rather than an MS article.
>>
>>
>> (And not all DCs are DNS, but its a very good idea that they are for
>> redundancy, specially if you only use one DNS on SBS.)
>>
>>
>
>

As mentioned, I never see any client get to this stage - which you have
made me think about again, and it does happen as you mention (ie. failed
lookup isn't failover).

As the client resources are on the SBS server (almost universally) there
is no difference in the result - you cant get to what is required until
the SBS is up. But as to the overall result, clients can still get to
the Internet, which is my point with an external DNS.

Only if you say the SBS is up bu say stopped SBS DNS, then a client
performed a lookup on a non cached entry (ie. non the SBS server) to a
local resource would there be an issue. But with DNS down SBS starts to
misbehave so the client issues would be the lesser problem at that point
anyway.


As you mention previously - the 15 minute timeout that resets the DNS
order is about how long it would take to reboot the server.

aus wrote:
> Lanwench [MVP - Exchange] wrote:
>> aus <aus@aus.net> wrote:
>>> Lanwench [MVP - Exchange] wrote:
>>>> aus <aus@aus.net> wrote:
>>>>
>>>> <snipped for length>
>>>>> This is wrong. You obviously put the SBS box in there first but
>>>>> having other external DNS IPs allows the clients to resolve and
>>>>> still use the Internet if the server is down.
>>>> No, Joe was correct. You never put an external DNS server's IP in
>>>> your client or server IP configuration, ever. This is a huge no-no
>>>> in AD, whether using SBS or not.
>>
>>> No, he isnt and you should know better than repeat mis-advice.
>>
>> Again: I'm correct, as is Joe. Sorry. If you don't understand this
>> bit, you don't understand how DNS &
>> AD work.
>>> Yes you need DNS in AD to log on properly
>>
>>> not just for login.
>>
>>> but if your SBS server is
>>> down
>>
>> (which it shouldn't be, but that's not really germane here)
>>
>>> then that's irrelevant - having secondary DNS specified allows
>>> you to access the Internet still. If you don't then clients cant get
>>> off the LAN.
>>>
>>> If you think this causes an issue you need to explain technically
>>> why.
>>
>> I *need* to? Perhaps English isn't your first language, but note
>> that your "tone" in this thread is bordering on belligerent - be
>> polite. Here's the basics: If the client for *any* reason cannot at some
>> moment successfully interrogate the internal/primary DNS server (as
>> in, your internal DNS server isn't quite fast enough to respond -
>> not necessarily that it's offline), it will happily flip over to the
>> next (secondary). It will continue to use the secondary until it is
>> rebooted or otherwise forced to do otherwise. And while it is using
>> the secondary, it will no longer be able to communicate properly
>> with the domain controller(s) via DNS, which will cause a slew of
>> problems.
>>> It doesnt cause an issue,
>>
>> Yes, it does - see above.
>>
>>> but Id like to know your logic.
>>
>> Try posting in microsoft.public.windows.server.dns and
>> microsoft.public.windows. for more info, if the KB
>> article I gave you (and your own innate ability to google) were
>> insufficient to get you started.
>>
>> http://www.google.com/search?q=DNS+A...L_enUS249US249
>> may .
>>
>>>
>>>>> Also if there is a second domain
>>>>> controller that would be listed.
>>>> Only if it's running DNS for the internal zone and also has
>>>> forwarders / root hints.
>>>>
>>> Yes, DNS needs to be running on a server for you to use it - maybe
>>> some wouldnt realise that(!)
>>
>> Well, it's important to mention. Remember, not all DCs are DNS
>> servers, nor need they be.
>>
>> This is now veering way off topic and I need to wrap it
>> up in this thread.
>>
>>
>
> Sorry, didn't mean to appear 'belligerent'(!) Many quote MS articles
> without engaging thought or have experience of the wider world of real
> and varied implementation. The SBS board is a bit like Stepford on
> occasion.. (some here will know exactly what I mean)..
>
> 'Microsoft Says so its TURE!..', 'You must use the Wizard damn you..'
> 'Shame on you, you will die if you have a second Exchange server'
>
>

The fact that you are providing for an alternate DNS server for your client
workstations to use isn't the "bad thing". The issue is that any alternate
DNS server provided for the workstations need to have the full AD zone for
the domain. That can be provided from many sources, even an ISP, but I've
never seen that happen.

Can you 'get away with it'? Wouldn't be the first time I've seen it. Will
there be transient problems locating Domain rescource, group policy
failures, logon scripts not running correctly, DFS issues, etc, etc,
etc..... Yes, count on it.

If these are acceptable tradeoffs for having the clients surf the web when
the server is down...then that's your call.

> The point is a wider one that many never consider.
>
> On a 75 user network DNS should never be busy - well I've never seen
> it or heard it mentioned. Out of all the services MS has blessed us
> with DNS is actually one of the most reliable.
>
> The DNS time out on Windows client side is 17 seconds, so quite a long
> "moment" (and thats after the client resolver cache has been checked).
> If a client can't get to DNS on a properly running SBS LAN in that
> time DNS almost certainly not running - not busy.
>
> Far more likely is that the the SBS server is down - which every
> network has from time to time - planned or not. With only the SBS DNS
> available no client has Internet access. Having an external DNS, if
> you dont have an internal backup, gives users that Internet access.
>
> If you don't care about Internet access when SBS is down then ok, but
> most users do want this as it gives some continuity of business, which
> IS the whole point. The SBS server never going down isn't reality.
>
> If you do actually see DNS time outs on your networks then you will
> indeed be seeing many other issues anyway. But its not reality or do
> you actually get these?
>
> But lets say your client is timing out, so the client switches to the
> external secondary (that can't resolve to AD) - it eventually times
> out (another 17 seconds) and then locally resolves the name anyway
> using local broadcast as NBT is on by default. You would see a long
> delay but the client wouldn't fail resolution on the local SBS subnet.
>
> However as I have this setup at multiple sites over the last few
> years I know this scenario doesn't happen. If you were somehow
> experiencing this you can set the DNS client service to try the full
> list each time (ie. start with the primary each time and not switch
> to the secondary for the duration of the session) - but I have never
> had to do this.
>
> Stop, think, and then test it and see the advantage (for your clients)
> rather than an MS article.
>
>
> (And not all DCs are DNS, but its a very good idea that they are for
> redundancy, specially if you only use one DNS on SBS.)

--
/kj

wasn't keeping up on what was officially public, so being careful.

--
Charlie.
http://msmvps.com/blogs/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"Cris Hanna [SBS-MVP]" <crisnospamhanna@cpunospamservices.net> wrote in
message news:O3GOT%23hrIHA.4876@TK2MSFTNGP02.phx.gbl...
"may change" ? :-)
http://sbs.seandaniel.com/2008/05/pr...for-small.html



Single nic is the only "supported" scenario for SBS 2008


--
Cris Hanna [SBS-MVP]
------------------------------------------
MVPs Do Not Work For Microsoft
-----------------------------------------------------
Please do not contact me directly. Please post only in the newsgroup so all
can benefit


"Charlie Russel - MVP" <charlie@mvKILLALLSPAMMERSps.org> wrote in message
news:8F46A1CA-987D-4AEB-8FCD-586FB6D06B90@microsoft.com...
But understand that future versions of SBS may change what you have to do...

--
Charlie.
http://msmvps.com/blogs/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel


"Teneo" <not@here.com> wrote in message
news:ur5ldhgrIHA.3456@TK2MSFTNGP05.phx.gbl...
> Just to add, I disagree with SINGLE NIC..., Hi Lanwench... lol
>
> Make your own decision whether you go single nic or 'as recommended by
> microsoft / sbs ' dual nic.
>
> Ciao
>
>
> "Lanwench [MVP - Exchange]"
> <lanwench@heybuddy.donotsendme.unsolicitedmailatya hoo.com> wrote in
> message news:%23Oayo2frIHA.3900@TK2MSFTNGP05.phx.gbl...
>> Terry <Terry@discussions.microsoft.com> wrote:
>>> OK but as I said the IPS owns the router, it was like pulling teeth
>>> to have them point the first DNS IP to the server. THey will NOT
>>> allow us to remove it form doing DNS
>>
>> Have them undo what they did. You need your *own* router/firewall
>> appliance between your network & their equipment - something that does
>> NAT. You haven't mentioned whether you'r running ISA or not, but if you
>> aren't, use a single NIC in your server and plug it, and your clients,
>> and *your* firewall/router, into the same Ethernet switch.
>>
>>
>>>
>>> "Lanwench [MVP - Exchange]" wrote:
>>>
>>>> Terry <Terry@discussions.microsoft.com> wrote:
>>>>> I have a new Windows 2003 Business Server. Everything seems to work,
>>>>> can get to the web do updates, etc.
>>>>> However none of the workstations can join the Domain, I have the DNS
>>>>> on the work stations pointing to the new server. The workstations
>>>>> cannot ping the server. However the Server CAN ping the work
>>>>> stations. What am I missing?
>>>>
>>>> 1) It's best to post SBS questions in
>>>> microsoft.public.windows.server.sbs - SBS does many things its own
>>>> way
>>>>
>>>> 2) DNS must be handled by your SBS box alone, not your router (the
>>>> CEICW will prompt you for your ISP's DNS servers)
>>>>
>>>> 3) DHCP should be handled by your SBS box, not your router
>>>>
>>>> 4) You need to use the setup wizards for *everything* in SBS- do not
>>>> try to join computers to the domain the non-SBS way or you will end
>>>> up with problems.
>>>>
>>>> I'm setting up my reply to crosspost to the SBS group for your
>>>> convenience in this thread - but again, post all future SBS
>>>> questions in there for the best results, even if you also crosspost
>>>> (not multipost!) to other groups.
>>
>>
>>
>
>

aus <aus@aus.net> wrote:
> SuperGumby [SBS MVP] wrote:
>> and there's some discussion here:
>>
>> http://support.microsoft.com/kb/825036/en-us
>> Best practices for DNS client settings in Windows 2000 Server and in
>> Windows Server 2003
>>
>> "SuperGumby [SBS MVP]" <not@your.nellie> wrote in message
>> news:eLTirOwrIHA.2188@TK2MSFTNGP04.phx.gbl...
>>> closest article so far
>>>
>>> http://support.microsoft.com/kb/291382/en-us
>>> Answer: The most common mistakes are: . The domain controller is not
>>> pointing to itself for DNS resolution on all network interfaces.
>>> . The "." zone exists under forward lookup zones in DNS.
>>> . Other computers on the local area network (LAN) do not point
>>> to the Windows 2000 or Windows Server 2003 DNS server for DNS.
>>>
>>>
>>>
>>> "kj [SBS MVP]" <KevinJ.SBS@SPAMFREE.gmail.com> wrote in message
>>> news:eotRYGtrIHA.800@TK2MSFTNGP02.phx.gbl...
>>>> aus wrote:
>>>>> Lanwench [MVP - Exchange] wrote:
>>>>>> aus <aus@aus.net> wrote:
>>>>>>
>>>>>> <snipped for length>
>>>>>>> This is wrong. You obviously put the SBS box in there first but
>>>>>>> having other external DNS IPs allows the clients to resolve and
>>>>>>> still use the Internet if the server is down.
>>>>>> No, Joe was correct. You never put an external DNS server's IP in
>>>>>> your client or server IP configuration, ever. This is a huge
>>>>>> no-no in AD, whether using SBS or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> No, he isnt and you should know better than repeat mis-advice.
>>>> You are getting sound advice on SBS and relevant to all other AD
>>>> client DNS configurations.
>>>>
>>>> Look into it. If you need the MS KB that describes the issues with
>>>> DNS client fallback, I'm sure one of us can dig it up for you.
>>>>
>>>> (Just adding my vote of confirmation to those before me)
>>>>
>>>> --
>>>> /kj
>>>>
>>>
>>
>>
>
> Hi, thanks for those - a very good place to read about DNS (hope
> others here read them!). Note that these are talking about DNS
> settings on Windows Servers mainly, which I DONT advocate should have
> an external DNS specified.


> Client PCs should indeed have internal servers as their Primary but
> its perfectly legitimate to use the secondary set to an external one
> as a backup

Just because you've managed to get away with it doesn't make it a legitimate
config.

> so Internet access is retained when the SBS is off.

The internal DNS server should *not* be off in the middle of the workday, of
course.

What you're advocating is deliberately botching up the way the clients will
communicate with the domain. It isn't worth it for the perceived
convenience.
>
> Essentially if this didn't work I wouldn't use it but some wont think
> through how it works and the advantages, but that's their network at
> the end of the day!

And if I'm responsible for it, it's being set up the way I say, or I'm no
longer responsible for it. :-)
>
>
> And I had forgotten that the DNS provider order is reset after 15 mins
> anyway - and not held for the complete session.

I'm not aware of that detail but it's good to know (although my networks
will not be affected by it).

Lanwench [MVP - Exchange] wrote:
> aus <aus@aus.net> wrote:
>> SuperGumby [SBS MVP] wrote:
>>> and there's some discussion here:
>>>
>>> http://support.microsoft.com/kb/825036/en-us
>>> Best practices for DNS client settings in Windows 2000 Server and in
>>> Windows Server 2003
>>>
>>> "SuperGumby [SBS MVP]" <not@your.nellie> wrote in message
>>> news:eLTirOwrIHA.2188@TK2MSFTNGP04.phx.gbl...
>>>> closest article so far
>>>>
>>>> http://support.microsoft.com/kb/291382/en-us
>>>> Answer: The most common mistakes are: . The domain controller is
>>>> not pointing to itself for DNS resolution on all network
>>>> interfaces. . The "." zone exists under forward lookup zones
>>>> in DNS. . Other computers on the local area network (LAN) do
>>>> not point to the Windows 2000 or Windows Server 2003 DNS server for
>>>> DNS.
>>>>
>>>>
>>>>
>>>> "kj [SBS MVP]" <KevinJ.SBS@SPAMFREE.gmail.com> wrote in message
>>>> news:eotRYGtrIHA.800@TK2MSFTNGP02.phx.gbl...
>>>>> aus wrote:
>>>>>> Lanwench [MVP - Exchange] wrote:
>>>>>>> aus <aus@aus.net> wrote:
>>>>>>>
>>>>>>> <snipped for length>
>>>>>>>> This is wrong. You obviously put the SBS box in there first but
>>>>>>>> having other external DNS IPs allows the clients to resolve and
>>>>>>>> still use the Internet if the server is down.
>>>>>>> No, Joe was correct. You never put an external DNS server's IP
>>>>>>> in your client or server IP configuration, ever. This is a huge
>>>>>>> no-no in AD, whether using SBS or not.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> No, he isnt and you should know better than repeat mis-advice.
>>>>> You are getting sound advice on SBS and relevant to all other AD
>>>>> client DNS configurations.
>>>>>
>>>>> Look into it. If you need the MS KB that describes the issues with
>>>>> DNS client fallback, I'm sure one of us can dig it up for you.
>>>>>