Re: DNS and Netbios name

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 ..DomainA.Forest.TLD".

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 broadcasting.

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.

Deji

"Ace Fekay [Microsoft Certified Trainer]" <firstnamelastname@xxxxxxxxxxx> wrote in message news:ejaerF5TJHA.5084@xxxxxxxxxxxxxxxxxxxxxxx
In news:OUIYdirTJHA.592@xxxxxxxxxxxxxxxxxxxx,
A, Deji <deji@xxxxxxxxxxxxx> requesting assistance, typed the following:
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.

Deji

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
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2004031913593948?Open&dtype=corp&tdir=reg_eu&tpre=reg_eu&src=ent_tutweb_eu

The following article was from an older version of BackupExec that states NetBIOS is required:
http://seer.entsupport.symantec.com/docs/192740.htm

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.
http://seer.entsupport.symantec.com/docs/255831.htm

Ace





.

Relevant Pages

  • Re: DNS and Netbios name
    ... it will say "give me ServerA ... ClientB has, it will NEVER know to say "give me ServerA in ... 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 ...
    (microsoft.public.windows.server.dns)
  • Re: DNS and Netbios name
    ... It should NOT matter to the requesting party whether or not the ... it will say "give me ServerA ... ClientB has, it will NEVER know to say "give me ServerA in ... what is happening is not a WINS magic, it is just a resolution thing ...
    (microsoft.public.windows.server.dns)
  • Re: proxy via ssh
    ... > I have a question about the proxy through ssh, ... > ssh client configured to connect serverA ... > for ClientB, ... > HTTP/1.0 400 Bad Request ...
    (comp.security.ssh)
  • Re: Adding a sucsriber
    ... Looking for a SQL Server replication book? ... ClientA (subscriber) and now I want to add another subscriber ClientB ... ClientB or I have to do something to the Publication on ServerA ...
    (microsoft.public.sqlserver.replication)