ch09.htm

this describes managing multivendor networks

	In the future (5.0) release of Windows NT, the desktop environment will be Internet
	aware--enabling you to open up a Web page just as easily as you can open a document
	on your hard disk. Furthermore, many of the enhancements to 5.0, including Microsoft's
	new directory services, are only targeted to run under TCP/IP. Microsoft is clearly
	betting that TCP/IP will be the protocol suite of choice in most public and private
	networks. 
<HR>


</BLOCKQUOTE>

<P>Another subtle change that occurred after the 4.0 release of Windows NT was Microsoft's
approach to new products. Prior to 4.0, the details of new products and features
were kept under wraps. After 4.0, however, Microsoft began a massive program of announcing
and releasing beta versions of most of its new products via the Internet. Although
Microsoft originally began this effort to better position its free Internet Explorer
Web browser against Netscape's Navigator web browser, the program has since grown
to epic proportions.</P>
<P>One final key point that separates Windows NT Server from NetWare is that Windows
NT Server is clearly more than just a file and print server--Windows NT Server is
an application server. Unlike NetWare, which requires vendors to write NLMs, Windows
NT Server can host conventional, Windows-based applications. Client/server connections
can be accommodated to these applications using direct program-to-program communication,
ODBC (a distributed data base connection), and more recently ActiveX (a network-based
Object Linking and Embedding solution).</P>
<P>Microsoft's commitment to delivering an application server can be seen in its
investment in the <I>BackOffice suite</I> of programs. BackOffice contains a powerful
database component (SQL Server), a mail/messaging component (Exchange), a legacy
connectivity component (SNA Server), a system management component (SMS), and a fast-growing
variety of Web-based applications built around Microsoft's Internet Information Server.</P>
<P>In fact, for several years Microsoft was willing not to challenge NetWare for
traditional file and print business, concentrating instead on the application server
focus. Microsoft's reasoning was that if it could get a Windows NT Server into a
corporation as a mission-critical application server, the file and print business
would eventually migrate to them anyway. This has proven to be a successful strategy,
although recently Microsoft has become more willing to compete head-to-head with
NetWare for conventional file and print server business.
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Basic Architecture</FONT></H3>
<P>Windows NT Server can be hosted by systems using Intel or DEC Alpha processors.
Earlier in its history, Windows NT Server also supported MIPS processor systems;
however, MIPS will no longer be supported as of the 5.0 release of Windows NT. Support
for NT on the PowerPC has also been phased out by both Motorola and IBM, and it is
unlikely that Microsoft will continue to support the PowerPC architecture in subsequent
releases.</P>
<P>The basic functions of Windows NT Server are consistent across all these types
of systems, but additional application programs might not be available for all processor
types. For this reason, Intel-based machines are deployed in the majority of Windows
NT Server installations.</P>
<P>In addition to supporting different types of systems, Windows NT supports Symmetrical
Multi-Processing (SMP); therefore, Windows NT can immediately take advantage of systems
with multiple CPUs. You can deploy a Windows NT Server in a one- or two-processor
configuration and then upgrade it to a three- or four-processor configuration when
you need additional performance improvements. Obviously, the base hardware system
you're using to host Windows NT Server must support multiple processor configurations
for you to perform this kind of upgrade.</P>
<P>Processor configuration aside, Windows NT Server runs as a non-dedicated operating
system--you can use the same system for desktop applications if you so desire (however,
most corporations prefer to run Windows NT Server as a dedicated system). In fact,
Windows NT Server is very similar to its desktop counterpart, Windows NT Workstation.
Detailed analysis has shown that the operating system kernel is the same for both
products. Windows NT Server has, however, been fine tuned for server performance
and includes additional software not available for Windows NT Workstation.</P>
<P>The fact that Windows NT Server has a full GUI appearance makes it relatively
simple to configure and administer all aspects of the server environment. You can
manage a Windows NT Server from the local keyboard and monitor and, as in the case
of NetWare, you can manage it from other workstations in the network. However, many
of the configuration and testing utilities are still command-line based.</P>
<P>In terms of security, Windows NT offers two types of security models: <I>workgroups</I>
and <I>domains</I>. In a workgroup model, the user authentication process occurs
on each system in the work-group. Other workgroup systems &quot;trust&quot; that
each system has performed the authentication. In a domain model, however, all users
are authenticated by a central server (termed the domain controller). Using a centralized
server provides greater control and security.</P>
<P>From a broader perspective, workgroups are informal groupings of systems that
elect to share resources with one another. Domains, on the other hand, are formal
collections of systems that can be centrally controlled and administered. The informal
nature of workgroups makes it difficult to implement them as large, enterprise-wide
solutions.</P>
<P>Unlike workgroups, domains can be interconnected. When you interconnect domains,
you can establish trust relationships between them so a user logged on to one domain
can access resources in another domain without being forced to log on to the second
domain. Although this approach works well in simple organizations, trust relationships
can grow very complex in large organizations. (For that reason, Microsoft is moving
toward global, NDS-like directory services. These new directory services are planned
for availability in the 5.0 release of Windows NT.)</P>
<P>One of the most unique aspects of Windows NT networking is how Windows NT sepa-
rates client/server and peer-to-peer services from the underlying network protocol.
Under Windows NT, you can choose the protocol you want to use in your network--NetBEUI,
IPX, or TCP/IP--without worrying how it will affect Windows NT services for file
sharing, printer sharing, and program-to-program communications. This flexibility
enables you to construct and administer powerful networks that can address the needs
of your company without being compromised by the demands of your existing client
or server computers.</P>
<P>Microsoft's model for integrating network protocols with network adapters is,
of course, the NDIS model previously discussed in this chapter. Microsoft's implementation
of NDIS has, however, gone through dramatic changes to keep pace with Microsoft's
relentless march of new operating systems.</P>
<P>For example, when NDIS originally started out in the DOS environment, it was a
completely static model where all protocols had to be bound to the network adapters
at boot time via the CONFIG.SYS file and then activated via a &quot;NETBIND&quot;
command in the AUTOEXEC.BAT file. The detailed information about adapter settings
(IRQ, DMA, port address, and so on) and about the protocols was placed in a separate
PROTOCOL.INI file.</P>
<P>After all of the protocols were locked and loaded, you could not add new protocols
nor could you unload any running protocols without reconfiguring your system and
rebooting it. This structure worked fairly well for DOS but it proved to be difficult
to operate under Windows. Therefore, Microsoft made some subtle changes to its NDIS
support when it introduced Windows for Workgroups.</P>
<P>Under Windows for Workgroups, Microsoft moved the PROTOCOL.INI file into the Windows
directory and moved some of the information that had been contained in the file into
some of the standard Windows configurations files (for example, SYSTEM.INI and WIN.INI).
Microsoft also introduced the NDIS <I>Demand Protocol Architecture (DPA).</I> Under
DPA, network interface drivers can be loaded as terminate-and-stay-resident (TSR)
routines from the DOS command line (or AUTOEXEC.BAT file) instead of as device drivers
from the CONFIG.SYS file.</P>
<P>Despite the integration into Windows for Workgroups, NDIS support remained mainly
under the control of DOS. The network protocols were set up and activated before
Windows was even launched. This same strategy could not work under Windows 95 and
Windows NT because neither of those operating systems feature an underlying DOS layer
to handle NDIS functions. As a result, NDIS had to be completely integrated into
Windows 95 and Windows NT. Of course, you still need to reboot your system to activate
any changes you make to your protocol environment.</P>
<P>Windows NT Server contains client software for all PC environments (DOS, Windows,
Windows for Workgroups, and Windows 95). Windows NT Server has the capacity to emulate
a Macintosh file and print server; therefore, some level of integration is available
with Macs without requiring any changes or new software in Mac clients. Support for
UNIX clients and other clients must be obtained from third-party companies.
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">Network Support</FONT></H3>
<P>In order to appreciate the advantages of the Windows NT multi-protocol network
support, you need to look back at the original networking model used by IBM, Microsoft,
and others. This model was created in 1984 when IBM and Sytek released a LAN-based
message interface system named the <I>Network Basic Input/Output System,</I> better
known today as <I>NetBIOS. </I>NetBIOS is a generalized program-to-program communication
facility that enables peer-to-peer and client/server communications between PCs operating
in a LAN environment.</P>
<P>NetBIOS facilitates communication through three key services:

<UL>
	<LI><I>Name service</I>. Each PC using NetBIOS is assigned a logical name (for example,
	MKT1, SALES, KELLY, and so on), and other PCs use that name to communicate with that
	PC. PCs learn about one each others names by listening to announcements PCs make
	when they join the LAN (for example, &quot;MKT1 now available for service&quot;)
	or by broadcasting a discovery request for a name (for example, &quot;KELLY, are
	you there?&quot;). Each PC keeps track of the names of other PCs in a local, dynamic
	table. No centralized name servers are required (or supported).<BR>
	<BR>
	
	<LI><I>Session service</I>. A PC can establish a session with another PC by &quot;calling&quot;
	it by name. After the target PC agrees to communicate with the requesting PC, the
	two PCs can exchange messages with one another until one of them &quot;hangs up.&quot;
	Session service is a connection-oriented service, so while the two PCs are communicating
	with one another, NetBIOS provides message sequencing and message acknowledgments
	to insure that all messages sent are properly received.<BR>
	<BR>
	
	<LI><I>Datagram service</I>. Datagram service is a connectionless service that does
	not require a PC to establish a session with another PC in order to send messages
	and does not guarantee the receipt of any messages sent. Datagram services can be
	used to deliver broadcast or informational messages. Application-level session controls
	and acknowledgments can also be placed on top of datagram services to make them more
	reliable.
</UL>

<P>In addition to these three core services, NetBIOS provides a limited number of
status and control functions. For example, these functions can be used to cancel
a NetBIOS request, discover the current status of the NetBIOS interface, or start
a NetBIOS-level trace.</P>
<P>When NetBIOS was first released, the term NetBIOS encompassed both protocol-level
and service-level functions. As the industry moved toward using well-defined computing
models that separate protocols from services (among other things), the NetBIOS protocol
and service aspects were formally separated and the term <I>NetBIOS Extended User
Interface (NetBEUI)</I> was adopted to define the protocol-level functions.</P>
<P>Microsoft pioneered the usage of the term NetBEUI and included support for the
NetBIOS/NetBEUI combination in its DOS-based LAN Manager product, in its Windows
for Workgroups (WFW) offering, and, of course, in its Windows NT Workstation and
Server products. Unfortunately, while Microsoft clearly distinguishes between the
NetBIOS and NetBEUI functions, many other vendors continue to use the term NetBIOS
to refer to both protocol and service functions.</P>
<P>As noted, NetBIOS provides a generalized interface for program-to-program communications.
NetBIOS does not, however, provide specific services to facilitate file, print, and
other user-related services in a peer-to-peer or client/server LAN. That task falls
on the shoulders of <I>Server Message Blocks (SMB).</I></P>
<P>Like NetBIOS, SMB is an interface system. But where NetBIOS is a generalized interface
system, SMB is a specific interface system that enables file sharing, print sharing,
and user-based messaging. Some of the specific services supported by SMB include:

<UL>
	<LI><I>Connection Related Services</I>
</UL>



<BLOCKQUOTE>
	<P>Start/end connection

</BLOCKQUOTE>


<UL>
	<LI><I>File Related Services</I>
</UL>



<BLOCKQUOTE>
	<P>Get disk attributes</P>
	<P>Create/delete directory</P>
	<P>Search for file name(s)</P>
	<P>Create/delete/rename file</P>
	<P>Read/write file</P>
	<P>Lock/unlock file area</P>
	<P>Open/commit/close file Get/set file attributes

</BLOCKQUOTE>


<UL>
	<LI><I>Print Related Services</I>
</UL>



<BLOCKQUOTE>
	<P>Open/close spool file</P>
	<P>Write to spool file Query print queue

</BLOCKQUOTE>


<UL>
	<LI><I>User Related Services</I>