DNS and Netbios name

Hello,

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?


Thanks

Hello Pat,

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

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Hello,
>
> 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?
> Thanks
>

Thanks for the reply,
But I don't want to edit the host file on 1000 computers

"Meinolf Weber" wrote:

> Hello Pat,
>
> You can try to modify the "lmhosts" file under %systemroo%\system32\drivers\etc
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and confers
> no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>
> > Hello,
> >
> > 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?
> > Thanks
> >
>
>
>

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
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Thanks for the reply,
> But I don't want to edit the host file on 1000 computers
> "Meinolf Weber" wrote:
>
>> Hello Pat,
>>
>> You can try to modify the "lmhosts" file under
>> %systemroo%\system32\drivers\etc
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>> Hello,
>>>
>>> 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?
>>> Thanks

Hi,
may be the app supports ip adresses, did u check out
jk

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.




"Pat" <Pat@discussions.microsoft.com> wrote in message
news:FDAD1B7A-4426-4CE6-81FF-B1EF6BB3FB08@microsoft.com...
> Thanks for the reply,
> But I don't want to edit the host file on 1000 computers
>
> "Meinolf Weber" wrote:
>
>> Hello Pat,
>>
>> You can try to modify the "lmhosts" file under
>> %systemroo%\system32\drivers\etc
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>
>>
>> > Hello,
>> >
>> > 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?
>> > Thanks
>> >
>>
>>
>>

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


Deji

"JohnB" <jbrigan@yahoo.com> wrote in message
news:eZ3jzYnTJHA.4452@TK2MSFTNGP03.phx.gbl...
> 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.
>
>
>
>
> "Pat" <Pat@discussions.microsoft.com> wrote in message
> news:FDAD1B7A-4426-4CE6-81FF-B1EF6BB3FB08@microsoft.com...
>> Thanks for the reply,
>> But I don't want to edit the host file on 1000 computers
>>
>> "Meinolf Weber" wrote:
>>
>>> Hello Pat,
>>>
>>> You can try to modify the "lmhosts" file under
>>> %systemroo%\system32\drivers\etc
>>>
>>> Best regards
>>>
>>> Meinolf Weber
>>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>>> confers
>>> no rights.
>>> ** Please do NOT email, only reply to Newsgroups
>>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>>
>>>
>>> > Hello,
>>> >
>>> > 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?
>>> > Thanks
>>> >
>>>
>>>
>>>
>
>

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.


"A, Deji" <deji@akomolafe.com> wrote in message
news:OyNNkdoTJHA.6060@TK2MSFTNGP06.phx.gbl...
> 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
>
>
> Deji
>
> "JohnB" <jbrigan@yahoo.com> wrote in message
> news:eZ3jzYnTJHA.4452@TK2MSFTNGP03.phx.gbl...
>> 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.
>>
>>
>>
>>
>> "Pat" <Pat@discussions.microsoft.com> wrote in message
>> news:FDAD1B7A-4426-4CE6-81FF-B1EF6BB3FB08@microsoft.com...
>>> Thanks for the reply,
>>> But I don't want to edit the host file on 1000 computers
>>>
>>> "Meinolf Weber" wrote:
>>>
>>>> Hello Pat,
>>>>
>>>> You can try to modify the "lmhosts" file under
>>>> %systemroo%\system32\drivers\etc
>>>>
>>>> Best regards
>>>>
>>>> Meinolf Weber
>>>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>>>> confers
>>>> no rights.
>>>> ** Please do NOT email, only reply to Newsgroups
>>>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>>>
>>>>
>>>> > Hello,
>>>> >
>>>> > 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?
>>>> > Thanks
>>>> >
>>>>
>>>>
>>>>
>>
>>
>

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

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

Deji

"JohnB" <jbrigan@yahoo.com> wrote in message
news:eZmlDipTJHA.6060@TK2MSFTNGP06.phx.gbl...
> 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.
>
>
> "A, Deji" <deji@akomolafe.com> wrote in message
> news:OyNNkdoTJHA.6060@TK2MSFTNGP06.phx.gbl...
>> 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
>>
>>
>> Deji
>>
>> "JohnB" <jbrigan@yahoo.com> wrote in message
>> news:eZ3jzYnTJHA.4452@TK2MSFTNGP03.phx.gbl...
>>> 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.
>>>
>>>
>>>
>>>
>>> "Pat" <Pat@discussions.microsoft.com> wrote in message
>>> news:FDAD1B7A-4426-4CE6-81FF-B1EF6BB3FB08@microsoft.com...
>>>> Thanks for the reply,
>>>> But I don't want to edit the host file on 1000 computers
>>>>
>>>> "Meinolf Weber" wrote:
>>>>
>>>>> Hello Pat,
>>>>>
>>>>> You can try to modify the "lmhosts" file under
>>>>> %systemroo%\system32\drivers\etc
>>>>>
>>>>> Best regards
>>>>>
>>>>> Meinolf Weber
>>>>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>>>>> confers
>>>>> no rights.
>>>>> ** Please do NOT email, only reply to Newsgroups
>>>>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>>>>
>>>>>
>>>>> > Hello,
>>>>> >
>>>>> > 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?
>>>>> > Thanks
>>>>> >
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>

In news:%23tto4JqTJHA.5200@TK2MSFTNGP05.phx.gbl,
A, Deji <deji@akomolafe.com> requesting assistance, typed the following:
> 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 chain.
>
> Anything "needing" to resolve NetBIOS name will be able to do so
> without WINS if the search list is appropriately populated.
>
> Deji
>

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.


--�
Ace

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

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

"Ace Fekay [Microsoft Certified Trainer]" <firstnamelastname@hotmail.com>
wrote in message news:eWQFyVrTJHA.4744@TK2MSFTNGP05.phx.gbl...
> In news:%23tto4JqTJHA.5200@TK2MSFTNGP05.phx.gbl,
> A, Deji <deji@akomolafe.com> requesting assistance, typed the following:
>> 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 chain.
>>
>> Anything "needing" to resolve NetBIOS name will be able to do so
>> without WINS if the search list is appropriately populated.
>>
>> Deji
>>
>
> 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.
>
>
> --�
> Ace
>
> 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
> numbers.

In news:OUIYdirTJHA.592@TK2MSFTNGP04.phx.gbl,
A, Deji <deji@akomolafe.com> 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_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

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@hotmail.com>
wrote in message news:ejaerF5TJHA.5084@TK2MSFTNGP05.phx.gbl...
> In news:OUIYdirTJHA.592@TK2MSFTNGP04.phx.gbl,
> A, Deji <deji@akomolafe.com> 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_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
>
>
>
>

In news:ua9Ng45TJHA.3952@TK2MSFTNGP06.phx.gbl,
A, Deji <deji@akomolafe.com> requesting assistance, typed the following:
> 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
>

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

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.

Deji

"Ace Fekay [Microsoft Certified Trainer]" <firstnamelastname@hotmail.com>
wrote in message news:eJMQNG%23TJHA.1332@TK2MSFTNGP02.phx.gbl...
> In news:ua9Ng45TJHA.3952@TK2MSFTNGP06.phx.gbl,
> A, Deji <deji@akomolafe.com> requesting assistance, typed the following:
>> 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
>>
>
> 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
>