DNS and Netbios name

Discussion in 'DNS Server' started by Pat, Nov 24, 2008.

  1. Pat

    Pat Guest


    I have an application that uses the NetBios name to make a connection.
    FQDN works fine but not the NetBios name. We manage 2 domains in our
    enviorment and the application resides in the other domain. I dont want to
    edit host files. and we don't use WINS. Is there a way to set up a host
    record that points to a netbios name?

    Pat, Nov 24, 2008
    1. Advertisements

  2. Hello Pat,

    You can try to modify the "lmhosts" file under %systemroo%\system32\drivers\etc

    Best regards

    Meinolf Weber
    Meinolf Weber, Nov 24, 2008
    1. Advertisements

  3. Pat

    Pat Guest

    Thanks for the reply,
    But I don't want to edit the host file on 1000 computers
    Pat, Nov 24, 2008
  4. Hello Pat,

    Sorry i missed the part "I don't want". I think you can not just add a record
    in DNS pointing to a NetBios name, think you have to use a WINS server.

    Best regards

    Meinolf Weber
    Meinolf Weber, Nov 24, 2008
  5. Hi,
    may be the app supports ip adresses, did u check out
    Juergen Kluth, Nov 24, 2008
  6. Pat

    JohnB Guest

    You're going to have to make some kind of concession. There's no magic wand
    you can wave over it to make it work.

    If using a WINS server is out of the question, your only other choice, if
    NetBios name resolution is a must, is to edit the LMhosts file.
    There's an option in DNS where, if DNS name resolution fails, you can
    specify a WINS server to attempt name resolution using the NetBios name.
    Maybe that's what you're thinking?

    If you don't want to use a WINS server, you can always create a batch file
    that will update the LMhosts file on every computer, and run that from a
    login script. That's fairly easy.
    JohnB, Nov 24, 2008
  7. Pat

    A, Deji Guest

    You don't need to edit host files. On the client that you are using for this
    test, add the domain suffix of the other domain to the suffix search list of
    the client's TCP/IP. Then restart DNS client and try again. You will see
    that the problem is resolved.

    So, the solution is to ensure that the clients have the domain suffix of the
    other domain in their suffix search list. If all of your clients are XP and
    above, you can globally configure the suffix in GPO by following the steps
    here: http://support.microsoft.com/default.aspx/kb/294785

    A, Deji, Nov 24, 2008
  8. Pat

    JohnB Guest

    The OP stated that he had an app that needed to resolve NetBios names, and
    WINS wasn't running on the network.

    And I suggested installing WINS or, edit the LMhosts file.

    I'm not sure what you're referring to.
    JohnB, Nov 25, 2008
  9. Pat

    A, Deji Guest

    I didn't think I was "referring to" you, JohnB. Although I posted directly
    underneath your response, I was replying to the OP w/o starting another

    Anything "needing" to resolve NetBIOS name will be able to do so without
    WINS if the search list is appropriately populated.

    A, Deji, Nov 25, 2008
  10. In
    The one exception I see to this is if the app uses the Browser service for
    any portion of its functionality. The OP didn't mention the app he in
    question, but one example is Symantec Corp AV. I guess another is SQL. So I
    guess it would be safe to say, it really depends on the app and how it uses
    NetBIOS. If it's simply looking for resolution, and no other NetBIOS related
    function, additional suffixes would be sufficient.


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

    Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCT
    Microsoft Certified Trainer

    For urgent issues, you may want to contact Microsoft PSS directly.
    Please check http://support.microsoft.com for regional support phone
    Ace Fekay [Microsoft Certified Trainer], Nov 25, 2008
  11. Pat

    A, Deji Guest

    Hi, Ace. Long time.

    Having run Symantec products for a long time, I must say that I have not run
    into a situation where it depends on WINS for name resolution. Is your
    experience different, in that the Corp AV is not able to rely on the
    underlying Windows lookup functionalties to sufficiently meets its
    requirements without WINS?

    There is a lot of myths regarding SQL, Cluster, etc NEEDING WINS, but it's
    actually just myth, in my experience.

    A, Deji, Nov 25, 2008
  12. In
    Hi Deji,

    Yes, a very long time! I'm trying to get back into posting more on a regular
    basis. I hope all is well with you and your family!

    WINS provides NetBIOS name resolution support across routers. I don't think
    I implied that SQL, Cluster, etc, needs WINS, as well as Backup Exec, but
    rather needs NetBIOS resolution. I apologize if I implied that.

    The problem I found was Corp AV finding machines across router in other
    locations for remote client installs. I've found it uses NetBIOS broadcasts
    to find them like Backup Exec. Have you seen otherwise where NetBIOS is not
    required? I looked it up, and found the following page that mentions NetBIOS
    is not recommended for name resolution, but then in their previous sentence,
    it says WIND or DNS is required for the Discovery Service as well as DNS,
    HOST or LMHOSTS files. I think it;s a little confusing.

    System requirements for Symantec AntiVirus Corporate Edition 9.0

    The following article was from an older version of BackupExec that states
    NetBIOS is required:

    They also have a method for specifying a dynamic port range to overcome
    NetBIOS use, so in essence you can get away without NetBIOS in Backup Exec.
    Not sure how you would do that with Corp AV.

    Ace Fekay [Microsoft Certified Trainer], Nov 26, 2008
  13. Pat

    A, Deji Guest

    Hi Ace, all is well here. Hope it's the same with you.

    I would have PM'ed you on this response, but I want it to be public in the
    hope that we could get a few contributions on from others on it. I know that
    you did not mention SQL, Cluster, etc. I lumped those in there because they
    are the most frequently mentioned when people talk about
    applications/services/processes that NEED WINS.

    I have found the claim of WINS dependency to be quite unsupportable in all
    cases I have investigated. I know that there are a number of articles,
    including KBs, out there that make this claim, and what I'm trying to do
    here is publicly challenge those claims. An application/process/whatever
    just wants to be able to locate a corresponding partner on the other end of
    whatever conversation/transaction it is engaged in at the time. If there is
    any process/application that is specifically coded to REQUIRE a specific
    method of locating such partners, I say that is a coding error (an anomaly)
    and that the vendor needs to be presured to re-code in a way that leverages
    the native name resolution scheme of the underlying client OS.

    It should NOT matter to the requesting party whether or not the record is
    located on the other end of a cross-over cable or across the ocean, it
    should simply request whatever it is looking for and let the
    location/resolution facility built into the OS take care of fulfilling the
    request. In all of the cases I have personally looked at, this IS the
    behaviour. I cannot tell you how many "Exchange NEEDS WINS" issues I have
    seen and resolved by encouraging the responsible admin to simply add the
    Exchange Server's domain to the requesting client's search list.

    It is quite simple, really - at least IMO. The case is usually in a forest
    with more than one domain, with the server/process/application in one domain
    and the requesting client in the other. Server is named (let's say)
    ServerA.DomainA.Forest.TLD and client is named ClientB.DomainB.Forest.TLD.
    Client or server tries to talk to the other using NetBIOS name.

    Because Client is in DomainB.Forest.TLD, it will say "give me ServerA in
    ..DomainB.Forest.TLD". Since ServerA is NOT in DomainB.Forest.TLD, ServerA
    doesn't receive that message. Client will ultimately try to broadcast to
    whoever is within earshot that it is looking for ServerA. Because
    ..DomainB.Forest.TLD is the ONLY search suffix that ClientB has, it will
    NEVER know to say "give me ServerA in .DomainB.Forest.TLD". And, it does not
    matter if both ClientB and ServerA were in the same network segment. ServerA
    will not know that ClientB was desperately looking for it.

    Now, add .DomainA.Forest.TLD to the suffix search list on ClientB and see
    what happens. ClientB will now say "give me ServerA in .DomainB.Forest.TLD".
    It will not find it, so it will go "OK, how about ServerA in

    Why does ClientB find ServerA when there is WINS in the picture? Simple.
    Because ServerA publishes its record in WINS, and ClientB is configured to
    ALSO ask WINS for records it is looking for. Depending on the configuration,
    ClientB will usually either go straight to WINS before asking DNS and then

    Another question - why does ClientB ALWAYS find everything it is looking
    for, even in a geographically-dispersed, WINS-less, single-domain
    environment? Think about it.

    Now, consider where there is WINS in the infrastructure BUT ClientB is NOT
    configured to use WINS. ClientB will NEVER find ServerA, regardless of how
    many WINS servers are in the infrastructure. So, what is happening is not a
    WINS magic, it is just a resolution thing whereby client will append the
    suffixes configured on them to every query they issue, and will loop through
    all the configured suffixes until they find the partner they are seeking.

    This is what GNZ does in Windows Server 2008 DNS. It is a replacement for
    WINS, although it is not automated in the same fashion as WINS.

    My long-winded diatribe is my way of saying that IF the client is given a
    way to locate the records it is looking for, it does NOT care whether or not
    there is WINS anywhere. All it wants to do is find a record. So, I'd be VERY
    VERY surprised IF Symantec actually coded an application that insists on one
    particular for of naming resolution facility. But, since I can't claim to
    have seen it all, I look forward to your response, and may even try to see
    about getting a Beta version of the product in question to verify.

    Take care, man.

    A, Deji, Nov 26, 2008
  14. In
    Hey, things aren't too bad on this end, other than just getting laid off
    this morning! Budgets... oh well. Expert help comes with a price! :)

    I agree 100% with your assessments and explanation. Understanding
    infrastructure resolution, it makes total sense. I hope everyone understands
    and helps them in their initial or decisions to change their designs.

    Just to add, you mentioned the numerous articles out there concerning
    NetBIOS requirements. I think they were written based on making it easier
    for most admins to get it to work instead of the KBs going into detail
    trying to explain search suffixes, forwarding and other DNS resolution
    criteria. It makes sense and don't see why it wouldn't work. That one
    article I read about Backup Exec's ability to specifiy port ranges hints
    towards that as well without spelling it out.

    The only thing that I had questions about is NetBIOS services and legacy
    applications. I remember years ago some apps looked for those NetBIOS
    specific services, but then again, being around all these years, it still
    sticks to the back of my mind, and newer and current apps now just look for
    a resolution, as you've stated. So I am happy with knowing and feeling like
    the current app devs no longer look for that. It's all well and good, and
    matter of fact simplifies name resolution across an infrastructure when you
    are using only one means to resolve, and that is DNS, since it's required by
    DNS, and will work with anything else if designed correctly with suffixes,
    forwarding, delegation, stubs, etc, where appropriate.

    The only thing the client will miss, that is if they are used to it, is
    Network Neighborhood. They'll be able to access resources on their own via
    the neighborhood, but not if they are on other subnets. Printer browsing can
    be done by AD, so the Browser service wouldn't be needed in that case, but
    the neighborhood is the only exception.

    Cheers man!

    Ace Fekay [Microsoft Certified Trainer], Nov 26, 2008
  15. Pat

    A, Deji Guest

    Oh, S^%$#@!

    There is never a good time to get laid off, and it is even more horrible
    happening so close to the holidays. I am truly sorry to hear this, and I
    hope you land right back on your feet in no time at all. Anything I can do,
    please let me know. Wish you and your family the best.

    A, Deji, Nov 26, 2008
  16. In
    Thanks, Deji. I appreciate the help. I'm plugging along with a few leads.
    I'll let you know how I make out.

    Thanks again!

    Ace Fekay [Microsoft Certified Trainer], Nov 27, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.