ch09.htm

this describes managing multivendor networks

</UL>



<BLOCKQUOTE>
	<P>Discover home system for user name</P>
	<P>Send message to user</P>
	<P>Broadcast message to all users</P>
	<P>Receive user message(s)</P>

</BLOCKQUOTE>

<P>In the Windows NT environment, SMB functions are integrated into the operating
system. For example, when you use File Manager to connect to a network drive (or
you issue a &quot;NET USE&quot; command), you are invoking SMB functions. Also note
that NetBIOS and SMB often work together. For example, when you go to connect to
a network drive, you rely on NetBIOS services to find the name of the system sponsoring
the directory you need, but you actually connect to and access that network drive
using SMB services.</P>
<P>As successful as the SMB/NetBIOS/NetBEUI architecture has been, it is not without
its limitations:

<UL>
	<LI>As discussed earlier, NetBIOS uses system names to enable and manage end-to-end
	connections. Under NetBIOS, names are resolved using broadcast-oriented techniques.
	For example, when a system joins the LAN it broadcasts its name and when a system
	wants to establish a connection to a system it has not previously heard from, it
	broadcasts a name discovery message. Unfortunately, broadcasts create overhead in
	a LAN and can negatively affect overall performance.<BR>
	<BR>
	
	<LI>NetBEUI does not use any addresses other than the physical LAN adapter address
	(also known as the <I>Medium Access Control, </I>or<I> MAC,</I> address). In contrast,
	protocols like IPX and TCP/IP add a second level of addressing that defines a network
	address. This second level address enables IPX and TCP/IP to quickly determine if
	a transmitted message needs to be routed to another physical network (because it
	has a different network address) or if it can be serviced on the local network. Because
	NetBEUI does not use a second level address, NetBEUI cannot distinguish between local
	and non-local messages, and is therefore considered a non-routable protocol.
</UL>

<P>When you combine the NetBIOS limitation with the NetBEUI limitation, you end up
with network traffic that is difficult to manage over multiple, interconnected LANs
or in a complex LAN/WAN environment. Specifically, you have NetBIOS generating lots
of broadcast messages to resolve names, and because NetBEUI does not support network
addressing, these broadcasts must be sent to all of the attached LANs. In effect,
NetBIOS and NetBEUI aggravate each other's limitations.</P>
<P>Fortunately, Microsoft recognized the limitations of NetBIOS and NetBEUI and included
alternate approaches in the network architecture for Windows NT. Under Windows NT,
you are not forced to run NetBIOS and SMB over NetBEUI--you can, in fact, choose
the network protocol that makes the most sense for your organization's overall network
composition. Because you are no longer forced to use NetBEUI for native Microsoft
networking traffic, you are no longer constrained by the NetBEUI limitation.</P>
<P>What LAN-level protocols can you choose from? Microsoft provides three protocols
that can be used to carry NetBIOS and SMB traffic:

<UL>
	<LI><I>NetBEUI Frames (NBF)</I>. This is an enhanced version of NetBEUI that supports
	a larger number of systems than the original NetBEUI protocol. Unfortunately, the
	enhanced version does not include any network addresses and therefore still suffers
	from the same internetworking limitation as the original protocol.<BR>
	<BR>
	
	<LI><I>Internetwork Packet eXchange/Sequenced Packet eXchange (IPX/SPX)</I>. As noted,
	IPX and SPX are the main protocols used in Novell NetWare networks. IPX is a connectionless
	protocol with no guaranteed delivery and SPX is a connection-oriented protocol with
	guaranteed delivery.<BR>
	<BR>
	
	<LI><I>Transmission Control Protocol/Internet Protocol (TCP/IP)</I>. TCP/IP is actually
	a suite of protocols that include TCP, IP, the User Datagram Protocol (UDP), and
	several other service protocols. TCP is a connection-oriented protocol with guaranteed
	delivery and UDP is a connectionless protocol with no guarantees. Both TCP and UDP
	rely on IP to resolve network addresses and facilitate the end-to-end delivery of
	messages.
</UL>

<P>As previously noted, TCP/IP and IPX implement network addresses; therefore, they
are both considered routable protocols that can easily be integrated into multi-LAN
environments and large wide area networks. This makes either protocol a superior
choice to NetBEUI for most applications.</P>
<P>Unfortunately, the standard implementations of TCP/IP and IPX do not address the
broadcast-intensive nature of NetBIOS. Because NetBIOS operates above the LAN-layer
protocol, it is isolated from the technical details of the underlying protocol, and
by the some token, the underlying protocol is isolated from the technical details
of NetBIOS. That means that NetBIOS name resolution will, by default, be handled
using broadcast techniques, regardless of which LAN-layer protocol is in use.</P>
<P>Microsoft did, however, address this problem by creating optional enhancements
for the TCP/IP implementation in Windows NT--and only for the TCP/IP implementation.
Specifically, Microsoft borrowed an idea (or two) from the way TCP/IP is implemented
in a UNIX environment and implemented three ways of resolving NetBIOS name requests
without generating broadcasts:

<UL>
	<LI><I>LMHOSTS. </I>You can configure a LMHOSTS file in each Windows NT system. LMHOSTS
	is a simple text file that contains a list of NetBIOS names and the corresponding
	TCP/IP address for each name. This is similar to the way that UNIX hosts use a HOSTS
	file to resolve native TCP/IP name-to-address translations. (You should note that
	Windows NT also supports a HOSTS file for TCP/IP traffic that does not involve NetBIOS.)<BR>
	<BR>
	
	<LI><I>WINS. </I>You can implement a <I>Windows Internet Name Service</I> server.
	A WINS server provides a centralized database that maps NetBIOS names to TCP/IP addresses.
	When a WINS client wants to know the address for a NetBIOS name, it simply asks a
	WINS server. This is similar to the way that UNIX hosts use Domain Name System (DNS)
	or Network Information Service (NIS) name servers.<BR>
	<BR>
	
	<LI><I>DNS. </I>You can also use a DNS server (UNIX or Windows NT Server) to resolve
	NetBIOS names into TCP/IP addresses. Microsoft is currently moving away from WINS
	and toward DNS as its preferred method of NetBIOS name resolution.
</UL>

<P>A given Windows NT system can use any one or a combination of any of these approaches.
In the event none of the above approaches are used, the NT system will resort to
using broadcasts for name resolution. Assuming, however, that one of these approaches
is in place, the TCP/IP software in a Windows NT system will look for NetBIOS name
discovery requests. When it sees such a request, it will send an inquiry request
to a WINS server or look for the name in its local LMHOSTS file.</P>
<P>Finally, please note that the Windows NT implementation of TCP/IP also supports
a dynamic IP address assignment protocol--the <I>Dynamic Host Configuration Protocol
(DHCP).</I> DHCP greatly simplifies the configuration of client systems in a TCP/IP
network. Instead of assigning and configuring unique IP addresses in each client
PC, you simply configure them to use DHCP and they will automatically receive an
IP address assignment from a DHCP server system (typically a Windows NT Server system).</P>
<P>The real beauty (from a networking perspective) of the Windows NT environment
is that it enables you to deploy multiple protocols on a concurrent basis. With Windows
NT you can run native Windows NT networking services over IPX and run native TCP/IP
services (in other words, Telnet, and ftp) over TCP/IP. Alternatively, you can run
native NetWare services over IPX and run native Windows NT networking services over
TCP/IP. You can even deploy all three protocol suites--NetBEUI, IPX, and TCP/IP--and
enable native and non-native services over all of them.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Microsoft and TCP/IP</B></FONT><BR>
	As Microsoft continues to enhance Windows NT, the multi-protocol scenario will begin
	to change because Microsoft is making a greater investment in TCP/IP-based services.
	For example, in the 5.0 release of Windows NT, all of the new directory services
	will only be available if you are using TCP/IP as your primary transport. Microsoft
	clearly believes that TCP/IP will be the de facto network protocol for the majority
	of the industry. You will, of course, still be able to run the other protocols, but
	if you do not run TCP/IP as well, you will find yourself feature-limited. 
<HR>


</BLOCKQUOTE>

<H2><A NAME="Heading7"></A><FONT COLOR="#000077">NetWare/Windows NT Server Integration</FONT></H2>
<P>The reality is that many organizations choose to deploy both NetWare and Windows
NT Server. For example, a company might use NetWare for file and print serving, but
use Windows NT Server as a data base server for client applications. This kind of
coexistence results in a requirement for a client systems to be able to access both
types of servers.</P>
<P>Because Microsoft operating systems control the majority of desktop environments,
it should be no big surprise to discover that Microsoft is the primary provider of
NetWare/Windows NT Server coexistence solutions. NetWare/Windows NT Server coexistence
solutions take on three forms:

<UL>
	<LI><I>Concurrent access.</I> Running two sets of client software in each desktop
	system so each client system can access both servers concurrently.<BR>
	<BR>
	
	<LI><I>Emulation.</I> Using a Windows NT Server to emulate a Novell server so clients
	can use existing NetWare client software to access NT resources.<BR>
	<BR>
	
	<LI><I>Gateway.</I> Using a Windows NT Server as a gateway so that clients see the
	NetWare server as part of the Windows NT Server system.
</UL>

<P>The first solution--running two sets of client software in each desktop system--is
really only practical if the desktops are running Windows for Workgroups, Windows
95, or Windows NT Workstation. These three operating systems can easily support concurrent
access to two different types of servers. You can use Novell-provided client software
in all of these three cases, or you can use the Microsoft-provided NetWare client
software in the Windows 95 and Windows NT Workstation environment.</P>
<P>Although concurrent access to both types of servers is technically possible in
DOS and Windows environments, it is very difficult to implement and manage. If you
are operating in either of these environments, you are better off looking at the
other two approaches.</P>
<P>The second solution--having a Windows NT Server emulate a NetWare server--is accomplished
via the NetWare file and print services included in the 4.0 release of Windows NT
Server. After this software is installed, the Windows NT Server emulates a NetWare
server and clients can connect to it to access file and print resources using standard,
client-side NetWare software. In most cases, this solution is implemented as a migration
strategy--clients are given access to both servers as information is moved from the
NetWare server to the Windows NT Server systems. After everything is moved, the clients
are then switched to native Microsoft client software.</P>

<P>The final solution--using Windows NT Server as a gateway to a NetWare server--is
implemented by using the NetWare gateway software included in the 4.0 release of
Windows NT Server. This software establishes a connection to a NetWare server and
remaps all of the files and printers into native Windows NT Server format--client
systems see the NetWare resources through standard Microsoft client software. This
approach is somewhat limited in that access to the NetWare server is performed via
a single-user id--all of the client systems share the access rights of the gateway
user-id.</P>

<P>Finally, you should note that a wide variety of third-party software is available
to integrate both NetWare and Windows NT Server into UNIX and other operating system
environments. The bottom line is that neither of these products suffer from a lack
of connectivity options--either to one another or to the rest of the world.&#160;<FONT
COLOR="#000077"></FONT></P>
<CENTER>
<P>
<HR>
<A HREF="ch08.htm" tppabs="http://docs.rinet.ru:8080/MuNet/ch08/ch08.htm"><IMG SRC="previous.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="ch10.htm" tppabs="http://docs.rinet.ru:8080/MuNet/ch10/ch10.htm"><IMG
SRC="next.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="index-2.htm" tppabs="http://docs.rinet.ru:8080/MuNet/index.htm"><IMG SRC="contents.gif" tppabs="http://docs.rinet.ru:8080/MuNet/button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <BR>
<BR>
<BR>


<P>&#169; <A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/copy.htm  \n\nThis file was not retrieved by Teleport Pro, because it was deleted using Teleport Pro\'s Delete command.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/copy.htm'" tppabs="http://docs.rinet.ru:8080/MuNet/copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>