This week's article covers an introduction to Windows 2000 Server Networking Services. This includes a look at NetWare connectivity components, as well as an introduction to DHCP and DNS in Windows 2000.
by Dan DiNicolo
Welcome to article number 9 in my 70-240 in 15 minutes a week series. This week's article covers an introduction to Windows 2000 Server Networking Services. This includes a look at NetWare connectivity components, as well as an introduction to DHCP and DNS in Windows 2000. This article again ties into the Windows 2000 Server portion of the series. Note that the level of detail covered in this article (especially with respect to DNS and DHCP) will be supplemented later in more depth, during the portion of the series that corresponds to the networking services exam.
The material that this article will cover includes:
- NetWare connectivity in Windows 2000
- Client Services for NetWare
- Gateway Services for NetWare
- Introduction to Windows 2000 DHCP
- Introduction to Windows 2000 DNS
NetWare Connectivity in Windows 2000
Windows 2000 still supports some of the NetWare connectivity elements that you may be familiar with from Windows NT 4. The three main elements that you'll need to be aware of are the configuration of NWLink, Client Services for NetWare (CSNW), and finally Gateway Services for NetWare (GSNW).
NWLink is Microsoft's version of Novell's IPX/SPX transport protocol, the native transport protocol in releases of NetWare prior to version 5. Since IPX/SPX is still run in many enterprise networks, it is important to know how Windows 2000 communicates with systems running the IPX/SPX protocol. NWLink is configured in Windows 2000 by choosing to install the protocol in the properties of a connection object, such as a Local Area Connection.
Once the protocol is added, it can be configured by accessing its properties. Note that adding NWLink to a system only makes that computer capable of communicating with another IPX/SPX or NWLink-based system. It does not mean that this computer can access the file system of another IPX based system. That level of access requires that an appropriate client redirector be installed, which will be discussed in a moment.
Once NWLink has been installed, it might be appropriate to check your network binding order, in order to ensure that it is optimized correctly for your network. For example, if TCP/IP is listed first in your binding order and NWLink second, a client will always try to communicate using TCP/IP first, followed by NWLink. If IPX/SPX is the primary protocol used on your network, this may not be appropriate, and may cause unnecessary network traffic. The binding order for a connection is set via the Advanced Settings option under the Advanced menu item in Network and Dial-up Connections. The binding order is controlled according to the adapter and then the client or service, and can be changed via the up or down arrows to the right. An example of the binding order for the Microsoft Client on the Local Area Connection is shown below:
The configurable elements of the NWLink protocol break down into three main areas. The frame type to be used, the network number, and the internal network number can all be configured, with each described below.
Frame Type: This element designates the format in which packets should be sent. The reason this must be configured is that different versions of NetWare can use different packets types which are incapable of communicating with one another. By default, Windows 2000 is configured to automatically detect the frame type used on the network. However, it does this by configuring itself to use the first frame type it comes across. If you have a NetWare network that uses multiple frame types, Windows 2000 would not be capable of communicating with both unless it were manually configured to use both frame types (since it would auto-configure itself to use only the first type that it would come across by default). As an example, NetWare 3.11 used ethernet 802.3 as the standard frame type, while versions 3.12 and later used 802.2 as the default. Frame types can be configured manually by choosing the 'Manual frame type detection' option in the NWLink Properties, as shown below.
Network number: The NWLink network number (also sometimes called the external network number) is very similar to the network portion of an IP address, in that is represents a network or a subnet. This number is actually a 32-bit number, but is represented as an 8-digit hexidecimal value. The network number must be the same in order for computers on the same network segment using the same frame type to communicate. The network number is also configured as part of the properties of a frame type, as shown below:
network number: The internal network number is used for internal
routing purposes, to designate the most efficient route to a program or
service (for example, one that uses the Service Advertising Protocol, SAP)
running on an IPX-based server. By default this number is all 0s (it is
also a hexidecimal number), and can remain as such, unless the system is
running a SAP-based application, File and Print Services for NetWare, or
as an RRAS-based IPX router. The Internal network number is configured in
the properties of NWLink, as shown below.
Gateway (and Client)
Services for NetWare
Often referred to by its acronym
CSNW, Client Services for NetWare is a client redirector, which allows a
Windows 2000-based system to connect and authenticate to a NetWare-based
server and access the file system. CSNW should be installed when clients
need to regularly access NetWare file or print servers. Often, CSNW is not
installed in favor of the native Novell client for NetWare, which ships
with the Netware product. Installing CSNW is accomplished by choosing to
install a Client in the properties of a connection object, as shown below:
It is worth noting that the installation of CSNW on a Windows 2000 Server is actually done as part of the installation of Gateway Services for NetWare, or GSNW. GSNW will also automatically install NWLink if it hasnt already been installed on the system. On a Windows 2000 Professional system, an option exists for installing CSNW alone.
Once installed, configuration of the client and gateway elements is actually handled via the GSNW applet in Control Panel. The configuration includes the selection of either a preferred server (in a bindery-based NetWare environment) or of a default tree and context (in an NDS-based environment).
Gateway Services for NetWare is meant to be used in environments in which clients require less frequent access to NetWare-based servers. GSNW makes a Windows 2000 Server act as a gateway (or access point) to resources located on a NetWare server. Using GSNW allows you to eliminate the need for each client system to have CSNW or NWLink installed. Instead, clients access a shared folder on the Windows 2000 system running GSNW, which in turn allows them access to files and folders on the associated NetWare server. In order to configure Windows 2000 as a gateway, a gateway account must be configured using GSNW in Control Panel, as shown below:
account used must exist on the NetWare server, and must be a member of a
group created on the NetWare server called NTGATEWAY. You must also
ensure that the NTGATEWAY group has appropriate trustee rights to access
resources on the NetWare server. Once the account has been set up, one
or more shares must be created that access the netware server, as shown
In this example, when users access the share called 'netware' on the Windows 2000 server, they will actually be accessing the folder 'resources' on NetWare server NW1.
Introduction to DHCP in Windows 2000
The Dynamic Host Configuration Protocol is a core networking service offered in Windows 2000 Server used to dynamically allocate IP addresses and associated information to TCP/IP-based clients. Although the function provided by DHCP is similar to what was provided in NT 4, a number of minor changes have taken place that you should be aware of. Again, note that this section is meant as an introduction to DHCP, and is provided as a basis for the Server portion of the exam. A much more detailed explanation of the configuration of DHCP will be covered during the networking services exam portion of the series.
The DHCP Server service is installed automatically by Windows 2000 Server, but is not configured (and may even be disabled) without further input. It can be removed or added if necessary, using the Add/Remove Windows Components option in Add/Remove Programs in Control Panel (it falls under Networking Services). Once installed, the DHCP server is configured using the DHCP MMC snap-in, which can be found under Administrative Tools. If the server running Windows 2000 is part of a workgroup or non-Windows 2000 domain, the DHCP service will be started, but you will need to manually configure scopes of addresses for the DHCP service to hand out (more on this in a bit). If DHCP is installed on a system that is part of a Windows 2000 domain, the DHCP service cannot be started until the DHCP server is authorized in Active Directory. The authorization of a DHCP server in Active Directory can only be done by a member of the Enterprise Admins group. This is meant to be used as a control mechanism in order to alleviate the problems caused by people (such as other administrators) installing rogue DHCP servers which end up having an impact on the configuration of a TCP/IP-based network (since a client receives an IP address from the first server that responds to its request). In a Windows 2000 Active Directory domain, only authorized Windows 2000 DHCP servers can hand out IP addresses. Note that this only works in conjunction with Windows 2000. A Windows NT 4 DHCP server can (and will) still hand out addresses, and will not be impacted by authorization. However, if another administrator tried to install a Windows 2000 DHCP server and start the service without it being authorized, the server would query AD, and then not start the service since it would find it is not authorized on the network. Note that an unauthorized DHCP server appears in the DHCP tool with a downwards-pointing red arrow (which can also mean that the service is not started, or a scope is not configured), as shown below:
order to authorize a DHCP server, right-click on the server and choose
Authorize. To manage authorized DHCP servers (including adding or removing
authorized servers), right click the DHCP icon, and choose Manage
Authorized Servers, as shown below:
Note that a DHCP server still doesn't do anything
until you configure a scope, the set of configuration settings that will
be handed out to a group of clients. Like many things in Windows 2000, the
scope creation process is handled via a wizard. In order to create a
scope, right-click on the DHCP server and choose New Scope. The wizard
will walk you through the entire process, including the configuration of a
valid range of IP addresses, subnet mask, and options such as a default
gateway (Router), DNS Servers to be used, and so forth. After the scope is
configured, it still needs to be activated (right-click and choose
Activate). The properties of the scope will be displayed categorized
according to address pool, active leases, reservations, and scope options
included, as shown below (scope options highlighted):
Note that after the server is authorized and a scope is configured, the arrow on the server icon above has changed to green and now points upwards. A few additional notes about scopes under Windows 2000:
- scopes can be aggregated or combined in order to create Superscopes. This would allow you to hand out IP addresses in non-contiguous ranges to hosts on a given subnet if necessary.
- If you want to change the subnet mask value associated with a scope, you'll need to delete and recreate the scope.
- The default lease time for addresses in a scope is 8 days. This is different that the NT 4 default of 72 hours, but can be changed to meet the needs of your environment.
- Ranges of IP addresses should be present only in a single scope. Since DHCP servers do not coordinate with one another, if two servers both have the same range of addresses in their scopes, duplicate IP addresses could be handed out on the network. Also be sure to exclude any statically-assigned IP addresses from scopes.
- In order to create fault-tolerant scopes, configure 2 (or more) DHCP servers, and split the range of addresses in each scope between them. In this configuration if one server fails, the other will still be capable of handing out valid IP addresses to clients.
- Options can be handed out at 4 different levels: Server (which impact all scopes), Scope (which impact only that scope), Client (set on a client reservation), and Class (for computers that fall into a defined class grouping). More on this later in the series, just be aware of the levels at which options can be assigned for now.
Introduction to Windows 2000 DNS
The Domain Name System is the Internet-standard name service used by Windows 2000 to help clients resolve host names to IP addresses and find services on the network. Before getting into the details of what is new in Windows 2000 DNS, I think we should first review how DNS itself works.
DNS is a distributed system of name servers. In this system, groups of name servers are responsible for records relating to hosts in domains and or subdomains. These groups are called zones. Zones are authoritative, or responsible for, the records relating to a given domain or group of domains. For example, Microsoft might have a few servers responsible for the microsoft.com domain, and all associated subdomains might be part of the same zone. The DNS servers that carry the host records relating to Microsoft.com are said to have authority for that domain. As such, if these servers could not provide an answer for the IP address associated with bluescreen.microsoft.com, it is assumed not to exist.
Name servers hold what are referred to as resource records. A resource record maps a hostname to an IP address, or a particular service to a hostname. For example, a DNS server might contain a host record (called an A record) for a server called server2 that resolves to IP address 126.96.36.199. If a client or another DNS server were to ask for the associated IP address, it would be found and returned. By the same token, a mail server might query DNS looking for the mail server associated with the win2000trainer.com domain. In this case, it is querying DNS for the mail exchanger record (an MX record), which would provide the fully qualified name of the mail server, which could then be resolved to an IP address and contacted.
Let's try the longest example possible first. Let's say that I am sitting at my client computer, running Internet Explorer, and I want to view www.win2000trainer.com. My client cannot contact this server until the name is resolved to an IP address. As much, my client queries my local DNS server (whichever DNS server is specified in the TCP/IP properties) and asks for the IP address associated with www.win2000trainer.com. Since my local DNS server is not responsible (authoritative) for the win2000trainer.com domain, it passes the query to a root server. The root server gets the query, but only processes it partially. It sends my local DNS server back an answer on where to find a name server that know all about things that end in .com. My local name server caches this information, and then queries the .com name server, asking for the IP address associated with www.win2000trainer.com. Again, the .com name server gives only a partial answer, sending back the information on where to find the name server that knows all about things that end in win2000trainer.com. My local name server then caches this information, and queries the win2000trainer.com name server, looking for the IP address associated with a host called www. The name server looks up this record (since it is authoritative for things that end in win2000trainer.com) and returns the IP address 188.8.131.52 to my local DNS server. This information is cached, and then passed to the client (who also caches it), and the client can now communicate with www.win2000trainer.com directly. How long are those records that were cached stored for? I don't know. However long the name server who gave me the answer says they can be stored for. Who knows better than the name server that is resposible for win2000trainer.com how often the name to IP address mappings change? Usually the records are cached for around a day, but sometimes less, especially if changes happen frequently. As such, if someone else were to query my local name server 3 hours later looking for www.win2000trainer.com, the answer would be provided immediately from cache. By the same token, if my mail server were looking for the mail.win2000trainer.com server, it would simply query my local DNS server, who would query the win2000trainer.com DNS server (since it has recently cached where this is located), who could provide the information relating to a host called mail. Note that another type of DNS server exists that is not responsible for any zone. These are called caching-only servers - they simply forward queries to other name servers and cache answers as outlined above, but are not authoritative for any zone. DNS is actually quite simple and straighforward. Don't let the fact that you may never have used it before bother you. If you understand what I've outlined above, you understand how it works. We'll worry about configuring it later.
DNS is implemented as a service in Windows 2000 Server, and as such can be started or stopped like any other service. It can also be added or removed using the Add/Remove Programs Windows Components Wizard. DNS is not installed automatically when you install Windows 2000, so it needs to be added manually. The number of DNS servers present on your network will depend a number of factors including your needs for fault tolerance, performance, and so forth. DNS is required in order to install Active Directory, since Active Directory domains follow DNS naming conventions. Note that the previous example was talking about DNS resolution out on the Internet. In the same manner, DNS can be used strictly for internal hosts, or a combination of both, so keep this is mind.
In a tradition DNS configuration, you have a set of at least 2 DNS servers who are responsible, or authoritative, for a zone. A zone is an administrative unit of DNS, and is represented by a set of DNS servers who are responsible for maintaining information relating to one or more domains or subdomains. One server in the setup acts as a primary name server, and this is the only server which carries a writable copy of the zone file. Periodically, the primary name server replicates its zone file to another server (or servers) designated as secondary name servers. These also carry a copy of the zone file, but the copy is read-only. The replication process is referred to as a zone transfer. The primary reason for having 2 or more DNS servers be responsible for a zone is to ensure that should one fail, another will be available to answer queries relating to the domains stored in the zone file.
This type of configuration continues to be supported in Windows 2000, and is referred to as being a 'standard' DNS setup. However, Windows 2000 also supports another type of DNS configuartion, which is new in Windows 2000. This configuration is called Active Directory Integrated DNS. In this setup, information about a DNS zone is stored in Active Directory, instead of being in a separate set of files. As such, DNS information is replicated automatically as part of Active Directory replication, and does not require a separate replication topology setup. This does not mean that every domain controller automatically becomes a DNS server. Instead, it means that every domain controller is capable of becoming a DNS server, if the DNS service is installed on that machine. Active Directory integrated DNS also has a number of other benefits, including the fact that every DNS server is writable, meaning that should a single one fail, DNS updates can still continue to be made. This is not true of a standard DNS setup, where updates cannot be made if the primary server goes offline.
Another big feature of the Windows 2000 DNS is that it is dynamic. That is, hosts can register and unregister records for themselves in DNS, including host name to IP address (A) records and service records (these will be discussed in a bit). The benefit of dynamic DNS is obviously the fact that previous versions of DNS did not support this, and as such, all records needed to be configured manually which could be very time consuming. Many people compare this functionaility with WINS. While the idea is similar, remember that the purpose of WINS is to register NetBIOS names to IP addresses, while DNS maps host names to IP addresses.
DNS is not only used in Windows 2000 to resolve host names to IP addresses. It is also used to allow a system to find services on the network, such as the authentication service of a domain controller. When a person tries to log on to a domain, their Windows 2000 system will query DNS, and try to find a list of one or more domain controllers in the same physical site. A domain controller automatically registers itself in DNS, but also registers records relating to some of the services it is running. In the same manner, a Windows 2000 client can register itself with DNS, but this can also be handled by the DHCP server who gave the client its address. Both of these elements deserve more attention, and will be covered in more details later in the series.
Although this section is only meant as an introduction to DNS, there are a couple of additional notes about DNS that are important:
- Windows 2000 DNS supports IXFR, or incremental zone transfers. In this setup, when a change is made to a zone file, only the changes are replicated to other DNS servers. To contrast, Windows NT DNS only supported AXFR, or full zone transfers, under which any change to a zone file meant that the entire zone file would be replicated to all secondaries.
- If you are using Active Directory integrated DNS, it is possible to enforce something called Secure Dynamic Updates. In this setup, a DNS server will only allow updates or record registrations from systems that have a valid Active Directory computer account. If this is not enforced, any system can make an update to DNS, which could represent a security threat.
And there again is another week on the road to 240 done and gone. Next week I plan to tackle the basics of Active Directory administration, as well as an introduction to DFS and Terminal services if it all fits. I hope you are all enjoying the series and finding it useful - thanks for all the wonderful feedback. In the meantime, if you have any questions or comments, feel free to contact me - I look forward to hearing from you. Also, please be sure to check out my website and free practice exams. I can't say anything yet, but big big changes are coming to the website, ones that I feel will make it a much more well-rounded daily must-see! In the meantime, best of luck with your studies this week.