Wow, joe and Deji both agreed with me and in the same day
:)
I am at peace :-^
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: 31 July 2006 20:24
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] DNS suffix resolution..
One word... disjoint name space.
AD itself doesn't
need WINS unless DNS is broken because it uses FQDNs. It is everything else. If
you have a simple single domain setup, you are probably going to be able to
remove WINS requirements unless you have legacy apps that actually force a
lookup of a specific type of NetBIOS record or do the lookups themselves with
the NetBIOS calls. As you add more domains it becomes more complicated. As you
add more trees or go to disjoint namespaces the work required isn't worth the
benefit.
Personally I like WINS, I have had very very few issues
with it even at the Enterprise scale.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
Sent: Monday, July 31, 2006 2:06 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] DNS suffix resolution..
This is probably going to be
a "hit-and-run" reply from me. I just have to jump in because whenever I
see a "Need WINS" argument, I feel the urgent need to burst a ventricle or
two.
if you don't have a wins server specified and don't have the dns
suffix search order, then name resolution won't work by simply typing in the
netbios name -- that can't be default behavior for a windows domain that
purportedly doesn't "need" wins.
[Neil Ruston] Who says 'doesn't need'? Perhaps if you had a single domain forest with no Exchange and other apps you may live without WINS. Otherwise, you need to engineer builds etc very carefully to live without WINS.
[Neil Ruston] Who says 'doesn't need'? Perhaps if you had a single domain forest with no Exchange and other apps you may live without WINS. Otherwise, you need to engineer builds etc very carefully to live without WINS.
IF "need" is the operative word, even a multi-domain Forest does NOT NEED
WINS for NetBIOS name resolution. Will such Forest benefit from WINS
availability? Sure, but only IF the Forest has been configured in such a way
that makes WINS presence beneficial. Does this mean that WINS is required? No.
It means that the said Forest requires WINS due to configuration decisions made
at some point in time, not because of technical or technological dependencies
imposed by the Operating System.
IF you have a properly defined naming convention (that is to say all your
kids are not named "joe") AND you utilize a logical and effective suffix search
list (that is to say everyone in your family tree knows everybody else's
surname), then your FOREST does not NEED WINS - multi-domain or not, and
regardless of the NetBIOS-consumption-propensity of any
application.
Now you can argue that "proper naming convention" is too fluid and highly
unrealistic, and I may not argue with you. You may point out that "appropriate
suffix list" in a Forest that has a bazillion and one domain is impractical, and
I may let it slide. But ..... both arguments do not support the assertion that
"AD NEEDS WINS". WINS is necessary where both conditions are not met. Where that
is not the case, you can happily give the middle finger to
WINS.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.com - we know IT
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon
From: [EMAIL PROTECTED]
Sent: Mon 7/31/2006 8:44 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] DNS suffix resolution..
from the machines, i can defintely ping the FQDN.
[Neil Ruston] indeed - that should always work unless you have basic DNS issues
If you have hundreds even thousands of workstations, the easiest way to distribute dns suffix search order listing is thhrough group policy ?
[Neil Ruston] most likely or some kind of login script.
if you don't have a wins server specified and don't have the dns suffix search order, then name resolution won't work by simply typing in the netbios name -- that can't be default behavior for a windows domain that purportedly doesn't "need" wins.
[Neil Ruston] Who says 'doesn't need'? Perhaps if you had a single domain forest with no Exchange and other apps you may live without WINS. Otherwise, you need to engineer builds etc very carefully to live without WINS.
its for this purpose i still use wins.
[Neil Ruston] As above, you can design the need for WINS out.
how are your clients tcp/ip properties set at child domains ? at HQ sites ?
[Neil Ruston] It depends upon the requirements of each location. In summary - add all suffices needed to each machine in each region. If I assume you have an HQ and branch locations, then consider adding appropriate suffices for the HQ machines and (different?) appropriate suffices for each branch.
i'm curious to know how other admins are setting up dns/tcpip properties in their network/domain.
[Neil Ruston] As ever - 'it depends' :)
On 7/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
just as an FYI:If you specify suffix search list it will override the searching of appending the parent suffix of primary DNS suffix.So if you just specify:and notit will not search domain1.com since it is not specified in the Suffix Search List.So if you want to still search the parent suffix, be sure to include it in the SSL.Jef----- Original Message -----From: Matheesha WeerasingheSent: Monday, July 31, 2006 4:13 AMSubject: Re: [ActiveDir] DNS suffix resolution..I assume you are using WINS and the DCs of child and parent domains are registered there. Therefore the netbios names are resolving.What happens when you try to ping the FQDN of the child domain server? Does that work? I think your issue is you want the child domain suffix to be appended automatically. My understanding is that it doesnt happen by default. However the reverse is true. If you are in a child domain and ping or attempt to resolve a name, it tries its own domain suffix before attempting to append the parent domain suffixes. This is true as long as you havent disabled the default behaviour, havent modified this through GPOs etc...You can also specify a list of search suffixes to go through in a certain order if you wish.
M@
On 7/30/06, HBooGz <[EMAIL PROTECTED]> wrote:I have a Forrest with one forest root and one child domain.
The child domain is running windows 2000 SP4 and the HQ sites are running windows 2003 R2 standard.
I have the the child domain controller setup as an AD-integrated zone and i have the 2003 DNS servers setup to receive that zone as a secondary zone.
if i don't include the suffix search order on the nic cards' dns entry page, i just resolve the netbios names of the hosts at the remote site. for example.
hq = company.com
child domain = sales.company.com
when i initiate a ping from any host at HQ to a host in the child domain i only resolve the netbios name.
how can i resolve this ?
I've tried setting up dns name delegation in the past when i was running a full 2000 domain, but that name resolution never worked right and it wasn't timely.
thanks,
--
HBooGz:\>
--
HBooGz:\>
PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this
message or any attachment(s) to it. If verification of this
email is sought then
please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment research;
(2) contains views or opinions that are solely those of
the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or
offer to buy or sell
securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT No.
447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A
member of the Nomura group of companies.
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.