| Author | Messages | |
deji
Posts:140
 | | 05/03/2008 11:42 PM |
| Your consultants have probably read some of the KB articles that "support" the misinformation that Exchange (or XYZ application/tool/process) REQUIRE WINS. There is a popular one that pretends to EXPLAIN the "requirement" by also throwing in further misinformation about subnet and geographical dispersion. One document I have found that authoritatively disabuses this misconception is http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cncf_imp_absq.mspx?mfr=true
Exchange and those other applications/processes NEED to be able to locate SOMETHING. Exchange clients NEED to be able to Locate Exchange Server. Exchange Servers NEED to locate DCs, clients, other Exchange servers, etc.
I contend that none of them cares HOW it is able to satisfy the NEED. Each will be happy even if the location/resolution facility that helps it find whatever it is looking for is a microwave, a fly saucer, a wad of bubble gum, DNS, WINS, or a bowl of cereal. They don't care. And, seriously, it does not matter whether the name we are looking for is directly attached by a cross-over cable to the computer looking for the name, or whether it is located in walawala.
Your Exchange server looks for "DC1". If it can't find it, it'll try "DC1"+suffix(if one exist) or it will ask for "DC1"+Primary DNS Suffix. As long as Exchange server and "DC1" are in the same domain and DNS zone, Exchange will be able to locate "DC1".
Where Exchange and "DC1" are not in the same zone or domain, Exchange will ask for "DC1"+(EACH-suffix-configured-in-the-suffix-search-list) UNTIL it hits one where "DC1" is located. If the suffix in which "DC1" is located is NOT included in the suffix search list on the Exchange Server, then it will not be able to locate "DC1". THAT is NOT an Exchange problem, it is YOUR mis-configuration issue.
IF you have "DC1" in various parts of your naming zone (multiple domains environment) and you've configured suffix search list on the Exchange to include all the zones, then Exchange will locate the "DC1" located in the highest-ranked suffix in the list. This may not be the "DC1" that you wanted Exchange server to talk to, but Exchange has found a "DC1", and is starting to talk to it. This is NOT an Exchange problem, it is YOUR naming standards mis-configuration issue.
Suffix Search List is an integral part of Windows name resolution. In a single name space, its importance is not very obvious because this is usually the same as the Primary DNS suffix. In a single name space, its use is not very obvious because the resolution process of appending suffixes to single-label names is usually not transparent to the end user.
In a complex, multiple (or disjointed) name space, it is a CRITICAL component. The primary reason for name resolution failure in this situation is the misconfiguration of the search list. The secondary reason is lack of uniqueness in naming standard, even when search list is diligently followed. In the latter case, there reason wasn't a resolution "failure" - the wrong computer just happens to be the first to respond to the call. This scenario is prevented by the logic in WINS which does not permit name duplication. This is the same logic that is presented by the new GNZ option of Microsoft DNS.
IMO, if you have correctly configured your suffix search list, and adhered to good naming convention that avoids name collision, anyone who tells you that you need WINS for anything in a single/multiple domain infrastructure or namespace (however many subnets are in the picture) is propagating a myth.
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
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Gabriele Scolaro
Sent: Saturday, May 03, 2008 7:05 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
I am sorry, I wrote about _WINS_ not needed by Clustering2008/Exchange2007,
but my brain was thinking of _NetBIOS_!
Over the last years, since the release of Win2K and AD, I have been pursuing
the way of a "pure DNS environment" for a couple of very pragmatic reasons:
a) AD heavily relies on DNS, thus DNS is a requirement (e.g. Kerberos).
b) DNS is the standard name resolution mechanism for *nix world and the
Internet
So I asked myself: "DNS is required by Windows today and also it is the
standard for the rest, then why not using a single technology for name
resolution instead of keeping two mechanisms that have the same goal?".
I answered myself: "Let's try with DNS and dismiss WINS!", being conscious
DNS was more complex but more feature-rich such as the delegation capability
and specifically ADI Windows DNS has the _secure_ dynamic update feature
that I'm not 100% sure you can achieve with WINS registration (of course it
is arguable if storing DNS data into an application partition in the DIT is
good or not).
Next step was analyzing the potential issues that could arise from
applications using the NetBIOS API for name resolution.
At that point I asked myself another question: "Do I really need NetBIOS? Do
I really need an additional interface that requires all those ports for name
service (UDP 137), connection service ("session", TCP 139) and
connectionless service ("datagram", UDP 138)? Can I live without it?".
I answered myself: "Probably I don't need it anymore today, but it really
depends on my applications".
I also wondered... if NBT was later introduced (RFC1001/1002) probably the
reason is that originally NetBIOS was not intended for large geographically
distributed networks (see RFC 1001 - 5. OVERVIEW OF NetBIOS: "NetBIOS was
designed for use by groups of PCs, sharing a broadcast medium"," One of the
first implementations was for personal computers running the PC-DOS and
MS-DOS operating systems").
In addition I supposed there would not be NBT for IPv6 in the future, so I
came to the conclusion to dismiss WINS _AND_ NetBIOS! They both smelled like
an old fish (=legacy) to me.
The first good finding was that SMB in Win2K and later versions can work
without NetBIOS as SMB can be directly hosted in TCP port 445 (that is the
default), my further investigation showed up that all our production
applications were not using the NetBIOS interface for communication (to be
honest I never performed network trace, just disabled NBT at both
endpoints).
Re. name resolution, I verified that all production applications were
demanding name resolution to the underlying OS when they had to contact a
server by its name (again no network trace, but server were placed in a
difference broadcast domain) - DNS worked smoothly also for short-name
resolution by properly creating a client-local DNS suffixes search list
(it's RFC'ed for intranet use).
So I started to disable NetBIOS on any machine starting from clients up to
server with any means: DHCP Ώ], scriptΐ] or pre-configured OS images.
A nice side effect was the "need" to disable the NetBIOS browsing "crap"
service as well (yet another redundant list of host names) Α]!!
Finally I switched WINS off.
Frankly speaking.. the choice for a pure DNS environment has been a great
driver to dismiss all pre-Win2K machines such as the Win9x! ;-)
Summarizing...
Yesterday: I had DNS, WINS, NBT and NBB (NetBIOS Browsing, newly coined)
Today: I have DNS and everything works. Period.
Of course I am not saying I did it the best, wrongly does the rest, or "GO
and DO the same!", I've just told my experience and the value I gained as
today I have "less pieces" to maintain/troubleshoot and invested more time
in DNS competence that can be reused for non-Windows universe (*nix,
Internet, etc...).
Let me also explain the reason of my post re. WINS (ehm...NetBIOS!) not
needed by Clustering2008/Exchange2007.
Recently some external consultants (I am a poor internal employer!)
challenged my decision of a WINS-less pure-DNS environment by asserting that
some applications such as Microsoft Exchange and Microsoft cluster have some
heavy dependencies on WINS/NetBIOS (e.g.
http://support.microsoft.com/kb/837391).
Well, besides the answer was quite easy for me "We lock into the DNS-only
environment as we do not use either Exchange or MSCLuster!" (we use Notes...
sigh ..), this made me wonder if latest version of both products have fully
removed the reliance on WINS/NetBIOS (hard to verify by myself as I do not
use/know none of them).
So I came across some MS readings stating that MS removed all those
dependencies:
- http://www.microsoft.com/windowsserver2008/en/us/high-availability.aspx
("Network Improvements" section).
- http://safari.oreilly.com/0672329204/ch06 (ops... could not find the MS
link! But this is the concept: "Exchange 2007 has removed its reliance on
NetBIOS and WINS for its networking services and is now very dependent upon
the successful operation of Active Directory and DNS").
Sorry, the script is pretty long and I farfetched things a bit!;-)
Regards - Gabriele.
Ώ] Microsoft Windows Vendor class - "001 Microsoft Disable NetBIOS Option"
- "type 0x2"
ΐ] (c) ActiveXperts
On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colNetCards = objWMIService.ExecQuery ("Select * From
Win32_NetworkAdapterConfiguration Where IPEnabled = True")
For Each objNetCard in colNetCards
objNetCard.SetTCPIPNetBIOS(1)
Next
Α]
http://support.microsoft.com/servicedesks/webcasts/en/transcripts/wct061003.
asp?SD=gn&LN=en-us&gssnb=1
Otto: What happens in a pure DNS environment, such as found in an Active
DirectoryR network that doesn't happen to use WINS? Does Browsing still work
and is it even needed?
Tim: Right. That's a good question. The short answer is Browsing, if it is a
wide area network with multiple segments and you don't have a WINS
infrastructure, Browsing will be broken. NetBIOS name resolution is
absolutely required for Browsing to work in a multi-segment environment.
As far as Active Directory goes in DNS, DNS is the cornerstone of the Active
Directory and is a requirement for Active Directory to run. Active Directory
is really meant to be the replacement for NetBIOS Browsing, and NetBIOS
Browsing has been included in products where Active Directory has been
implemented just for backward compatibility.
Our customers generally love NetBIOS Browsing and that's why it's included
in the product, so yes, AD is supposed to really replace NetBIOS Browsing,
but in a pure DNS environment with no WINS and no Lmhost files, no name
resolution infrastructure, browsing is going to be very, very poor. It is
required for browsing in a multi-segment environment, as I mentioned.
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-
> owner@mail.activedir.org] On Behalf Of joe
> Sent: sabato 3 maggio 2008 17.19
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
>
> I can't speak to clustering because I didn't ever do network traces on
> it
> but Exchange doesn't actually have a WINS requirement; never did. It
> doesn't
> know how to directly go ask WINS for something, it does all resolution
> through the OS. So the issue is that it is a shorthostname resolution
> requirement. I have seen it in action on network traces. Exchange would
> ask
> for a DC Name or some other resource service provider, get back a FQDN
> for a
> resource, then it would chop that FQDN into a shorthostname and try to
> resolve that. It goes to DNS and if you have a flat DNS hierarchy it
> should
> work. If not... Well then you better have WINS or LMHOSTS laying about
> or
> the name better be in the broadcast subnet or else bam it breaks.
>
> I saw the same issue on XP clients at times as well. Haven't watched
> the
> name res on Vista yet. Obviously the fix in the application is don't
> chop
> FQDNs to shorthostnames but workarounds can be configured that don't
> require
> WINS. This problem and how people describe and what they think it
> actually
> is speaks volumes to the lack of understanding of name resolution in
> general
> and just one more reason why I really liked - again... Complexity
> involved.
> People didn't have to think about suffix search orders (and impact of
> adding
> a bunch to your clients), DNS devolution, search scopes, etc. The name
> was
> directly resolvable or not. I can't count the number of times I have
> heard
> the statement, the name is in DNS, I can see it *right there*, how come
> the
> machine can't resolve it!?! Globalized standards are a nice thing but
> in the
> real world, how often does a client machine somewhere on an intranet
> truly
> have to resolve something off the internet that it couldn't resolve
> through
> a proxy that is there to filter things anyway or through WINS? We have
> solutions that have been in place and working for some time. Some part
> of me
> wonders if the switch to DNS was more due to whining by people who
> didn't
> have a clue that were saying WINS isn't standard than there being a
> real
> actual good reason to do so. It allowed MSFT to then say, see, we
> listened
> to you guys, we don't use that <cough> proprietary name resolution
> anymore
> <cough>. And when they did you get a resounding cheer from a bunch of
> people
> who never even thought to look at the underlying implementations of
> things
> just because they are now using a <cough>standard<cough> name
> resolution
> mechanism.
>
> Anyway, back to the Exchange and WINS thing... sometimes it is
> interesting
> just to do network traces and watch traffic when things are supposedly
> running properly so you can see what exactly is going wrong that is
> being
> crutched in some other way to make it work. Also it helps people
> understand
> how things really work versus just listening to some few people who say
> one
> thing or another. I would rather people go figure it out and see how
> things
> work than listen to me and take my word for it. If they take my word
> for it,
> who knows who else's words they are taking at face value. Any one of us
> could be wrong. Anyway, I encourage people to go out and watch the
> actual
> DNS and WINS name res requests on the network for a while. See what you
> learn from it. While you are at it ask yourself... Why isn't there an
> LDAPS
> SRV record? What SRV records are clients really using to figure out
> where
> DCs are or where to change passwords? Why?
>
> As an aside, Dean brought up Global Name Zones. That is another aspect
> that
> makes me chuckle and anyone who starts saying how great it is... I will
> just
> know that they secretly like WINS... I am not saying they like the RPC
> requirement, I hate all RPC requirements, wish it would crawl into a
> hole
> and dieΏ]. But they like the concept behind NBNS/WINS and
> shorthostname
> resolution even if out of the other side of their mouth they are
> complaining
> about it. I kind of expect people to bitch about GNZ's more than WINS
> down
> the road when they really start using it with how it is being
> implemented. I
> don't know, we shall see. I won't go into it, I don't want to put words
> into
> anyone's mouth about it, let them like it or not based on their own
> experiences.
>
> joe
>
>
> Ώ] This is more due to dealing with firewalls and reverse proxies etc
> than
> anything else. Now that we have DNS everywhere we theoretically
> shouldn't
> need RPC... The whole idea right is to map services to ports... Well
> what
> are SRV records for? Should be able to get rid of all sorts of server
> based
> repointing/remapping services due to DNS and SRV records.... Weighting
> is
> all there, priority is there, target, port, etc etc etc.
>
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
> -----Original Message-----
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Gabriele
> Scolaro
> Sent: Friday, May 02, 2008 9:29 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
>
> I do agree that DNS is more complex than NBNS (nobody would argue on
> that)
> and it is also true that host name uniqueness is a must-have whether
> DNS or
> WINS is in place, so ideally I agree with Joe that WINS is able to
> address
> name resolution needs in a Windows intranet environment...
> ....BUT I see a great value in adopting DNS that is using a
> _unique_standard_ name resolution mechanism that works anywhere-anyway,
> whether the hosts run Windows, *nix, "anyOS" or they stay on the
> Intranet,
> Internet, DMZ, "anynet"....
> Standardization sometimes has a price and sometimes it is complexity!
>
> I recently read that MS removed all WINS dependencies in Exchange 2007
> and
> Windows Server 2008 (clustering service), so it's clearly moving to a
> "pure"
> DNS world, so we must accept the inevitable, WINS will be (is?) "dead
> meat".
>
> Gabriele.
>
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-
> > owner@mail.activedir.org] On Behalf Of joe
> > Sent: sabato 3 maggio 2008 1.37
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
> >
> > I won't argue whether or not WINS in NT3.5 days was difficult or not;
> > no experience with it. My experience that I am willing to quote from
> > began with
> > NT4 SP3 at which point was substantial and solid. Anything else prior
> > to that was playing around and not true enterprise use experience.
> >
> > Agreed on the dedicated DNS teams point, there are other reasons for
> > it but arguably the complexity that is inherent in a hierarchical
> > model over the flat model plays into it as well. Something that maybe
> > helps DNS now though is the dynamic updates you mention which in a
> > properly designed WINS architecture was pretty much the whole
> picture,
> > static entries were a bane.
> > Anyway, no one I ever spoke with thought to stick WINS into its own
> > support group even though by far the largest number of machines in
> > most any org were dependent on that versus DNS. Again, *nix and
> > everything else tends to be a rounding error in terms of sheer
> numbers
> > though there was a different operating model.
> >
> > The DNS issues, primarily configuration, did not surprise me as most
> > places
> > (tm) I think were very homogenious and WINS was the big name res
> > system and DNS might have sort of have been there for internet stuff
> > if the company didn't rely on external DNS. In larger orgs, DNS was
> > old hat and once they figured out the zones and capabilities needed,
> > likely didn't have many issues but then again they likely weren't
> > Windows DNS shops either.
> > Then you
> > have a hodgepodge mixture of places that started mixing and matching
> > either because the Windows guys didn't want their name resolution in
> > the hands of those Unix guys and/or the Unix guys didn't want to get
> > stuck dealing with the Windows guys so you started doing various
> > forums of zone delegation etc which presented its own complications
> > and showed how much most Windows people don't understand DNS. Config
> > issues weren't the only issues though, any one of us if we look
> around
> > can find DNS issues other than config such as the island issues and
> > more than once I have been involved in environments where all of the
> > DNS entries "disappeared" because something got confused and DNS
> > didn't know where to read the data from in an ADI environment.
> > The
> > fun in troubleshooting those is great because, again, of the added
> > complexity that is there over WINS.
> >
> > WINS was very simple. That again is what I liked about it. Tiny code
> > base, even someone who couldn't read code normally could follow it,
> > not so with the DNS code base. Fewer lines of code, fewer the likely
> > issues and caveats, etc. Lots of features and functionality and
> > complexity. DNS can be deployed very simply or very complex using
> this
> > that or those features, WINS will be likely deployed very simply as
> > there aren't a lot of features. The most complex thing will be how
> you
> > set up the replication or static entries.
> > I
> > never said it was robust, never thought that, just don't think that
> > internal Windows implementations need lots of complexity and
> > robustness. Start talking internet and DMZ and things like that, WINS
> > falls down fast.
> >
> >
> > joe
> >
> >
> > --
> > O'Reilly Active Directory Third Edition -
> > http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Darren Mar-
> > Elia
> > Sent: Friday, May 02, 2008 1:03 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
> >
> > Joe-
> > The combination of the length of your response, and the fact that
> your
> > Pistons slaughtered my Sixers, has put me in a bad mood. But I will
> > rise above it and say that I value your experiences with DNS more
> than
> > mine, so I respect your points. Much of my experience with WINS came
> > from its early, early days (and since I'm older than you, those were
> > *early* days) and it has definitely improved. My early experience
> with
> > WINS was anything but "set it and forget it". Mind numbing is a good
> > word to describe WINS then and my experiences were also across
> > multiple large environments. One thing I will say is that many large
> > companies have dedicated DNS teams because DNS has traditionally
> > played a MUCH larger role in those environments (long before Windows
> > arrived) where mission critical apps running on Unix and the
> mainframe
> > relied on it, so I don't count that as an indicator of the difficulty
> > of DNS. In fact, in one large environment I worked in, DNS ran like
> > clockwork (pre-AD days) and was managed by one guy for an
> organization
> > with thousands of servers.
> >
> > I will say that I heard in the not-too-distant past that DNS was MS'
> > number
> > 1 support issue, which surprised me, but then again, AD being as
> > critical as it is in most companies, I can understand it.
> >
> > As for hierarchical vs. flat, for me it has less to do machine name
> > uniqueness than organizational (as in ability to organize) benefits
> > and, as you mention, delegation. But this discussion didn't start as
> a
> > feature comparison, so I won't dwell too much on that. Bottom line is
> > that both WINS and MS-DNS as they are often used today are
> > multi-master replicated, distributed databases that (typically) rely
> > on client machines self-registering (and un-registering) with them
> > dynamically and are responsible for their own grooming. That set of
> > technologies is just a recipe for complexity and the only thing that
> > will save either technology is good tight management and monitoring.
> >
> >
> > Darren "Wait til next year Chauncy" Mar-Elia
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
> > Sent: Thursday, May 01, 2008 8:09 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
> >
> > Your comments don't reflect my experience with it; especially when
> > compared to DNS and I deal with many very large environments and have
> > substantial daily experience with them in everyone's favorite Fortune
> > 5.... Err Fortune 10 company (they were Fortune 5 when I worked
> there,
> > teaches them for letting me go). I have dealth with far more mind
> > numbing DNS issues over the last 10 years than WINS issues.
> >
> > My experience with WINS is you tend to set it up (i.e. Install and
> > select one or more replication partners) and off it goes.
> Occasionally
> > you might jetpack the DBs. The big issues seem to be around
> > misconfigured client machines (both servers and workstations). The
> > biggest issues I have ever really had with it were darn SAMBA boxes
> > and admins who didn't know how to configure resource servers (usually
> > they installed WINS service).
> >
> > As an aside, I have never seen a company with a dedicated WINS
> support
> > group... Just about every company I deal with has a dedicated DNS
> > support group.
> >
> > Never really had issues with replication other than network problems,
> > if that occurred then you scheduled a pull as soon as the network
> > issue was cleared up (WINS doesn't really ever push, it is all pull
> > replication).
> >
> > I think one of the big issues most people had with WINS is that they
> > didn't monitor it. Likely because they couldn't figure out how to
> > monitor it.
> > Again
> > MSFT wasn't so kind there. So things that were little issues turned
> > into mountain issues and even if WINS went months without any problem
> > the resulting issue that occurred got to be so big it left a mark on
> > people.
> >
> > This isn't just me feeling it was better; we would do ticket reviews
> > looking back over periods of time and WINS was never even a blip on
> > the radar for issue to be dealt with in some comprehensive manner.
> >
> > Agreed there was no CNAME functionality, had shorter names, the
> > suffixes to me are no different than the SRV records and I don't
> agree
> > with the generally speaking as I mentioned before I occasionally had
> > to jetpack.
> > It
> > was so infrequently my team mates didn't even know about the tool.
> > Worse
> > comes to worse with the DB you delete the file and pull a new one
> from
> > your partner or even worse comes to worse you pop your servers with a
> > NetBIOS name registration refresh request.
> >
> > I don't care about the CNAME and shorter names for the WINS problem
> > scope because it really didn't much matter. It is an intranet tool, I
> > am not saying use it for internet use. Use it for internal resources
> > for your internal users - probably about 90% of the work done in most
> > IT groups.
> > I
> > know I know, not all environments are homogenious, in fact, I
> > personally have never worked on a homogeniuous network. The networks
> I
> > have worked on have had everything from every flavor of Windows to
> > every flavor of Cray to every flavor of just about every vendor's
> UNIX
> > and most flavors of mainframes and miniframes with giant teradata
> data
> > mining systems and engineering super computers that calculate car
> > crash results and everything else but in every case, every case, the
> > number of non-windows machines was barely a rounding error. DNS was
> > available for them just the same.
> >
> > The flat namespace... Well that is a fun one right? What is WINS used
> > for?
> > Resolution of machine names. In general, and I say in general, in the
> > Windows world the design goal is a single domain forest. That would
> > mean all of the machines if done in a standard MSFT way were in a
> flat
> > namespace as well. Take it further and go with a multidomain forest
> > environment and you still can't properly reuse the same machine name
> > in multiple domains in the forest, so flat namespace still works
> fine.
> > But even if you say wow we can do the same machine name in different
> > name spaces, I don't think it is a very good idea within a company,
> it
> > is a great way to confuse the heck out of people because, just as it
> > was 10 years ago, users still think in terms of short host names
> > within the confines of the intranet. Even admins do it... Go into any
> > company and ask one of the admins, what DC or what file and print
> > server is in site XYZ... I expect the most popular answer will be a
> > single host name response, not an FQDN.
> >
> >
> > "Some of the folks" seem to be thinking I am saying dump DNS for
> > WINS... Or WINS rocks, DNS is for losers. I am not, I am saying I
> like
> > WINS over DNS for intranet Windows purposes. I like WINS because it
> is
> > a very simple design and most companies do not need a complicated
> name
> > resolution infrastructure design for Windows. The one cool thing DNS,
> > IMO, has over WINS for Windows intranets is a hierarchy that would be
> > cool for administrative access delegation and they don't even have
> the
> > tools set up to take advantage of it.
> >
> >
> > joe
> >
> >
> > --
> > O'Reilly Active Directory Third Edition -
> > http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Darren Mar-
> > Elia
> > Sent: Thursday, May 01, 2008 11:58 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] WINS? Ick. WAS [OT] introduction
> >
> > Actually, I don't really understand that. Is it because the WINS
> > namespace is flat and so somehow that is simpler to manage? Because
> my
> > experience with WINS management is that it was not easy (at least in
> a
> > large
> > environment)
> > and required quite a bit of expertise and baby-sitting to keep it
> > healthy.
> > Things like replication that are handled for you today with AD-
> > integrated DNS had to be manually managed in WINS and were fraught
> > with peril if not designed well. Also, WINS was/is completely
> > inflexible with respect to functionality equivalent to CNAMES, had
> > issues with name lengths, required you to keep track of a myriad of
> > ridiculous suffixes and generally speaking was constantly requiring
> > database maintenance.
> >
> > Darren
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Wells, James
> > Arthur
> > Sent: Thursday, May 01, 2008 8:51 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > That might be the case - but I think the point is that WINS is less
> > complex to manage.
> >
> > So it'll take fewer admins/lower TCO/fewer operational risks vs. DNS,
> > given the same quality admins.
> >
> >
> >
> > --James
> >
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> > Deji
> > Sent: Thursday, May 01, 2008 9:22 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > You cleverly side-stepped the question, joe.
> >
> > If you truly believe that the health of a WINS implementation is
> > directly proportional to the "quality" of its
> > implementor/administrator, then is it not logical to assume the same
> > of DNS?
> >
> > 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 joe
> > [listmail@joeware.net]
> > Sent: Thursday, May 01, 2008 6:20 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > You know we didn't run Windows DNS at all. We needed functionality
> > that MSFT didn't put in because they thought they knew what we were
> > doing...
> >
> >
> > --
> > O'Reilly Active Directory Third Edition -
> > http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> > Deji
> > Sent: Thursday, May 01, 2008 1:17 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > Did I just hear you say "DNS worked very well for us on NT4 (and
> > beyond).
> > Possibly it was simply the quality of the admins running it"?
> >
> > Does that mean you are going to stop dumping on DNS now?
> >
> >
> > 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 joe
> > [listmail@joeware.net]
> > Sent: Wednesday, April 30, 2008 10:09 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > Maybe because you are recalling this poorly Deji.
> >
> > I wasn't always chasing errant 1C/1B records, I wasn't ever chasing
> > errant 1B/1C records but then you weren't involved in the Enterprise
> > domain stuff where we worked, you worked on resource dp,aom servers.
> > We occasionally has Samba boxes hijacking 1C records and I had a
> > script that monitored that so when it happened we had it fixed in
> very
> > short order. Outside of that the biggest issue was "admins"
> > miscofiguring servers to either not point at the proper WINS servers
> > or loading and running the WINS Service on them.
> > Got to
> > the point where when someone would call with a WINS issue my team
> > would first check the member server in question to make sure it was
> > configured properly and it usually wasn't. Didn't matter how many
> > times we tried to explain you couldn't configure WINS on a server
> than
> > then point it at another WINS server for name res and have it work
> > properly.
> >
> > WINS worked very well for us on NT4. Possibly it was simply the
> > quality of the admins running it.
> >
> >
> >
> > --
> > O'Reilly Active Directory Third Edition -
> > http://www.joeware.net/win/ad3e.htm
> >
> >
> > -----Original Message-----
> > From: ActiveDir-owner@mail.activedir.org
> > [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Akomolafe,
> > Deji
> > Sent: Thursday, May 01, 2008 12:29 AM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > Even in NT 4.0. joe just wouldn't admit that it was a kludge, even
> for
> > someone with his expertise. He was always chasing after some errant
> 1C
> > and 1B (or is it 3x) records that periodically go missing for no
> > reason.
> >
> > 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 Darren Mar-Elia
> > [darren@sdmsoftware.com]
> > Sent: Wednesday, April 30, 2008 9:23 PM
> > To: ActiveDir@mail.activedir.org
> > Subject: RE: [ActiveDir] [OT] introduction
> >
> > Brandon-
> >
> > Apparently you never used WINS in NT 3.50... :-)
> >
> > Darren Mar-Elia
> > CTO & Founder
> > SDM Software, Inc.
> > "The Group Policy Experts"
> > www.sdmsoftware.com
> >
> > -----Original Message-----
> > From: "Brandon Shell" <tshell@gmail.com>
> > To: ActiveDir@mail.activedir.org
> > Sent: 4/30/2008 6:53 PM
> > Subject: Re: [ActiveDir] [OT] introduction
> >
> > The suffering point was that DNS is harder to configure, Manage, and
> > troubleshoot than WINS.
> >
> > But I agree... lets move on 
> >
> > On Wed, Apr 30, 2008 at 9:43 PM, Akomolafe, Deji
> <deji@readymaids.com>
> > wrote:
> >
> > > You've completely lost me, and I still don't understand the
> > "suffering"
> > > part of your original statement. And you still haven't explained
> how
> > MS'
> > > decision to adopt Kerberos was the beginning of your woes,
> > > especially
> > since
> > > you just stated that other Kerberos implementations depend on DNS
> as
> > wellList 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
> >
> > 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
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
| | | |
|
|