In This Chapter
Learning to use IPv6.
Making your network more secure.
Leveraging Universal Plug and Play.
Taking advantage of Routing and Remote Access.
Windows Server 2003 introduces a whole new array of networking and communications technologies. In keeping with the traditions of networking and communications, most of these new technologies are referred to by incomprehensible acronyms: UPnP, SIPS, BITS, and so forth. In this chapter, however, we'll lift the veil of mystery and show you how these new technologies will make an impact on your network.
Perhaps the most important new networking technology in Windows Server 2003 is IPv6. You're no doubt familiar with TCP/IP, but you're most likely familiar only with IPv4, the version of the IP protocol that has been around since the explosive growth of the Internet in the early 1990s. Although that explosive growth made IP familiar to millions of people, it also presented some significant challenges. Most importantly, everyone realized that the IPv4 protocol's addressing scheme wasn't designed to support the number of computers that are now on the Internet. As a result, the number of available IP addresses has been rapidly decreasing over the past few years, requiring many Internet service providers (ISPs) to severely ration the IP addresses they issue and requiring networking innovators to create many new technologies to work around the lack of available addresses. IPv6 is designed to fix all that, with an enormous new addressing space and, of course, new concepts to remember.
Windows Server 2003 also includes all the networking improvements originally introduced in Windows XP Professional, such as improved wireless support, new networking diagnostic tools, and much more. Many of these features are more suitable for a client operating system such as Windows XP Professional than for a server, but you might find applications for them in your environment. Some of the most important new Windows Server 2003 networking technologies include
Support for the IPSec network security protocol over Network Address Translation (NAT)—. This is a capability that improves the security of virtual private networks (VPNs) and other communications. Windows Server 2003 also supports IPSec with the included Network Load Balancing (NLB) service, allowing farms of Windows Server 2003 computers to receive IPSec traffic.
Support for Point-to-Point over Ethernet (PPPoE)—. This allows Windows Server 2003 to connect directly to many broadband service providers, especially cable and xDSL providers, without the need for additional software. PPPoE is a popular protocol in the broadband market because it enables providers to dynamically provide IP addressing information to clients over a high-speed Ethernet connection.
Enhancements to the Internet Authentication Service (IAS), Windows's bundled RADIUS-compatible authentication service.
The initial goal of IPv6 was simply to address the problem of IP address depletion that has become common with the older, familiar IPv4 protocol suite. As you'll see in a bit, IPv6 addresses that problem with a massive new addressing scheme that should provide ample addresses far into the future. However, once underway, the developers of IPv6 also decided to address some other problems that new and innovative uses of the Internet were making apparent, including broadcast and multicast support, security, addressing boundaries, and more. In this section, we'll provide you with an overview of how IPv6 works in general and some specifics about the IPv6 implementation in Windows Server 2003.
If you can't wait for the day when IPv6 becomes an everyday reality, don't hold your breath. Although the IT industry in general has committed to moving to IPv6, doing so is going to make the Year 2000 crisis look like a walk in the park. Nearly every single network device in the world, from desktop computers to servers, from routers to Web-capable cell phones, and many more, will have to be upgraded to support IPv6. Certainly, the process is well underway, with major vendors such as Microsoft and Cisco including IPv6 support in their new products. Additionally, IPv6 provides backward-compatibility with IPv4, enabling older devices to function while the transition is underway. Even so, the move to IPv6 remains slow (the protocol has existed for more than five years already), and it will likely be a few more years before you can forget everything you know about IPv4.
Perhaps the easiest place to begin a discussion on IPv6 is with addressing. Rather than the four-octet, dotted-decimal IP addresses you're accustomed to, such as 192.168.0.52, IPv6 uses hexadecimal addresses like this: 21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A. For simplification, you can remove any leading 0s for any segment of the address, resulting in something similar to this: 21DA:D3:0:2F3B:2AA:FF:FF228:9C5A. IPv6 addresses are roughly four times longer than IPv4 addresses, and, whereas IPv4 addresses provide for 4.2 billion possible addresses, IPv6 can support 3.4x1038 addresses (that's like a trillion quadrillion quadrillion addresses, or about a million quadrillion addresses for every square meter of the earth's surface). Just as IPv4 addresses were divided into classes (Class A, Class B, and so forth), IPv6 addresses are also divided. For example, approximately 1/256 of the IPv6 address space is reserved for multicast addresses, another 1/1024 is reserved for local site unicast addresses, and so forth. About 15% of the address space is available for unicast, or single-host, addresses. Because so much of the address space is reserved for particular uses, and because IPv6 allows addresses to be compressed, or expressed in shorthand, so that 0s aren't displayed, you might find yourself working with addresses such as FF02::02, which is a shortened version of FF02:0:0:0:0:0:0:2. Basically, you just leave out all the contiguous 0s and include a double colon in their place, compressing the address down to a much more manageable size. You can remove only one contiguous series of 0s, meaning compressed addresses such as FF02::5::2 aren't legal.
In IPv4, you use a subnet mask to specify which portion of an IP address is the host address and which portion is the network address. IPv6 doesn't use subnet masks. Instead, it relies on a prefix to specify which portion of the address is the network's ID number. Prefixes are identical to the Classless Interdomain Routing (CIDR) notation you might already use for subnet masks. For example, 21DA:D3:0:2F3B::/64 specifies a 64-bit mask, which represents a particular subnet on a network.
IPv6 supports three distinct types of addresses:
Unicast—. Represents a single network interface, which might be a network adapter in a computer.
Multicast—. Identifies multiple interfaces. Packets sent to a multicast address are delivered to all interfaces, or network adapters, that subscribe to the multicast address. Multicasts are most often used to distribute videoconferencing audio and video streams.
Anycast—. Similar to a multicast, except that the data is delivered only to the nearest interface using the address, rather than to all interfaces using the address. Whereas multicast is used for one-to-many conversations, anycast is used for one-to-”one of many” conversations.
Notice that IPv6 does not define a broadcast address, like IPv4 does. Under IPv6, all broadcasts are conducted as multicasts. The IPv6 specification includes special multicast addresses to which all IPv6 interfaces must subscribe, enabling subnet-specific broadcasts, site-wide broadcasts, and so forth. IPv6 does define a couple of special addresses. The unspecified address, used in routing calculations, is simply ::, or 0:0:0:0:0:0:0:0, which is equivalent to IPv4's 0.0.0.0 address. IPv6's loopback address is ::1, which is equivalent to IPv4's 127.0.0.1 loopback address.
To provide backward-compatibility with IPv4, IPv6 specifies compatibility addresses. For example, 0:0:0:0:0:0:192.168.0.2 supports the IPv4 address 192.168.0.2 and also can be expressed as ::192.168.0.2. When these compatibility addresses are used, the computer encapsulates all IPv6 header information into an IPv4 packet, allowing the IPv6 packet to be carried by an older IPv4 network. Compatibility addresses are used by computers that support both IPv6 and IPv4.
For an IPv6 computer to address an IPv4-only computer, it must used mapped addresses, such as 0:0:0:0:0:FFFF:192.168.10.5, or simply ::FFFF:192.168.10.5. This internal IPv6 representation of an IPv4 address tells the computer that, when sending packets to that destination, it must fall back to the pure IPv4 protocol and not attempt to send IPv6 packets.
Interestingly, computers on an IPv6 network usually have multiple addresses, even if they have only a single network adapter. These addresses include
A link-local unicast address—. It allows the computer to communicate with other hosts on the same network subnet. This is a nonroutable address and is similar to the Automatic IP Addressing (APIPA) addresses, in the
169.254.0.0range, that IPv4 defines. Windows Server 2003's IPv6 stack automatically creates a unique link-local address for each network adapter in the computer.A site-local unicast address—. It is similar to the private IP address ranges (such as
192.168.0.0) used in IPv4. This address is routable only within a private network and cannot be used on the global Internet. Different private networks can reuse the same site-local addresses.A global unicast address—. It is similar to a public IP address under IPv4. These addresses are routable across the entire Internet.
The purpose of these different addresses is to help conserve address space and to make routers' jobs easier. A major problem with IPv4 is that the simple volume of IP traffic makes it tough for routers to keep up because they must analyze a great deal of traffic simply to see whether that traffic needs to be routed. IPv6's use of specific classes of address, some of which are routable and some of which aren't, helps routers perform their tasks more efficiently. Also, computers won't necessarily have one of each type of address. For example, a computer within a large enterprise network might have a link-local and site-local address but no global address. Instead, only the network's boundary devices—such as firewalls—would use global addresses, performing the IPv6 version of NAT to provide Internet access to internal clients.
There's plenty more to the IPv6 protocol, of course, including complex new packet headers, routing tables, and so on. For details, connect to www.microsoft.com/ipv6, where you'll find several detailed technical documents regarding IPv6.
Windows Server 2003 contains the first production version of Microsoft's IPv6 stack (Windows XP includes a similar, prerelease version of the stack). The stack contains all the features to operate on a pure IPv6 network or a combined IPv4/IPv6 network, including
6to4 tunneling—. Allows IPv6 hosts to communicate with one another over an older, IPv4 network.
PortProxy-enabled communications for applications that cannot select a specific IP stack—. PortProxy provides proxying from IPv4 to IPv6 and vice versa, as well as proxying from IPv4 to IPv4 and from IPv6 to IPv6. This capability is critical for computers that need to access services provided by a computer offering a different version of the IP stack. You can configure PortProxy by using the
netsh interface portproxycommand from a command line.Dynamic registration of IPv6-compatible host (“AAAA”) records—. Both the DNS Client service and the DNS Server included with Windows Server 2003 support this.
For more information on changes to DNS in Windows Server 2003, see “WINS, DHCP, and DNS,” p. 126.
IPSec now supports IPv6 in several configurations—. Plus, Windows Server 2003 includes a new tool,
IPsec6.exe, which enables you to manually configure security policies, associations, and encryption keys for IPv6.Windows's native Remote Procedure Call (RPC) protocol uses Windows Sockets—. This has been updated to support both IPv4 and IPv6 connections.
Internet Explorer, Telnet, FTP, IIS 6.0, file and print sharing, Windows Media Services, and Network Monitor—. These are all included with Windows Server 2003, and they all fully support IPv6.
Windows Server 2003 supports IPv6 routing through the use of the
netsh interface ipv6 routecommand—. This command enables you to configure a Windows Server 2003 computer with static IPv6 routes, thus allowing the computer to act as a rudimentary IPv6 router.
To install and configure the IPv6 stack on Windows Server 2003, follow these steps:
Open the properties for the network connection you want to use IPv6.
Click the Install button and select Protocol from the list.
Select Microsoft TCP/IP Version 6 from the protocol list, and click OK.
Unlike the IPv4 stack, which includes a complete GUI for configuring IP addresses and other information, IPv6 is configured entirely from the command line by using the netsh interface ipv6 command. For example, netsh interface ipv6 add address "Internal" AEB0::2 adds the address AEB0::2 to the network interface named Internal. Other commands enable you to add DNS server information, interfaces, routes, prefix policies, 6to4 tunnel settings, and so forth. Of course, configuring IPv6 settings from a command line is definitely a step backward, when everyone has become used to automatic configuration through DHCP. There is a specification for DHCPv6—the IPv6 update to DHCP—which provides full automatic configuration. Unfortunately, Windows Server 2003 does not include a DHCPv6-compatible DHCP service, nor does Windows Server 2003's IPv6 stack include DHCPv6 support. By default, Windows Server 2003's IPv6 stack creates a unique local-link address automatically (similar to APIPA in IPv4), removing a minor piece of manual configuration effort. Also, all IPv6 hosts listen for advertisement messages sent by IPv6 routers and use those messages to configure their default router, the location of a DHCPv6 server (assuming one exists and the stack supports its use), and other information. On a network with multiple IPv6 subnets, you'll likely have to perform some manual configuration, especially if your routers aren't configured to send IPv6 router advertisements.
First introduced in Windows 2000, IPSec has undergone a number of improvements to make it more usable and more secure. One of the major drawbacks of IPSec in Windows 2000, for example, is the fact that IPSec/L2TP VPN tunnels cannot traverse a NAT device. This requires administrators to use their Internet firewalls (which usually perform NAT for network clients) as the endpoint of all L2TP/IPSec VPNs or to use the somewhat-weaker PPTP protocol for VPNs because PPTP could pass through NAT under certain circumstances. Windows Server 2003, however, extends the IPSec protocol to comply with new Internet Engineering Task Force (IETF) drafts that provide support for passing IPSec/L2TP tunnels through NAT devices. This new capability enables completely secure VPNs to originate behind NAT devices (most often firewalls) and to be directed to destinations behind NAT devices, creating more secure point-to-point tunnels of encrypted data.
Similarly, the Enterprise and Datacenter editions also provide NLB support for IPSec/L2TP tunnels, allowing you to create a farm of multiple VPN endpoint servers by using Windows Server 2003's bundled NLB software. This capability means that you can now create clusters of VPN servers to handle incoming user VPN connections; these clusters can be fault tolerant and will balance the incoming workload between themselves. If a user establishes a connection with a particular server and that server fails, another server in the cluster will be capable of adopting the connection and provide uninterrupted services to the user.
Another common problem with IPSec policies under Windows 2000 is that they have to be configured with specific IP addresses, making it impossible to create policies for servers that use DHCP to obtain dynamic IP addresses. In Windows Server 2003, source and destination addresses can be set to a specific IP address or be set to the DHCP server, DNS server, default gateway, or WINS server, enabling policies to automatically adjust to computers with dynamic IP addresses. Figure 10.1 shows the new configuration dialog box, including the new dynamic addresses. You can use the new dynamic policies to, for example, ensure packet encryption between any DNS or WINS server. This new capability is supported only by Windows Server 2003; these dynamic addresses are ignored by Windows 2000 and Windows XP computers, which can result in inconsistent application of your IPSec policies within your domain.
The IP Security Policies snap-in can now map computer encryption certificates to computer accounts in Active Directory, which is the same SChannel certificate mapping IIS and other PKI-enabled applications already use. After they're mapped, you can set up access controls using the settings for network logon rights. For example, an administrator can restrict access to a particular computer to other computers from a specific domain, computers with a certificate from a particular certification authority (CA), a specific group of computers, or a single computer. Only computers running Windows Server 2003 have this capability; computers running Windows XP or Windows 2000 ignore this extension to IPSec policy.
Finally, Windows Server 2003 includes support for 2,048-bit Diffie-Hellman key exchange, as described in the Internet draft, “More MODP Diffie-Hellman Groups for IKE.” The practical upshot of this support is stronger encryption keys. The IP Security Policies snap-in provides the interface to configure this new setting for both local and domain-based IPSec policy. This support is provided only in Windows Server 2003; Windows 2000 and Windows XP computers ignore this setting. Figure 10.2 shows the new Diffie-Hellman group, which you can add as an active Internet Key Exchange (IKE) method by using the IP Security Policies snap-in.
Figure 10.2. 2,048-bit encryption is roughly twice as strong as the strongest encryption previously available in Windows.
As shown in Figure 10.3, Windows Server 2003 also sports an all-new IPSec Monitor snap-in, providing a better administrative interface for monitoring IPSec policies and security associations. Windows Server 2003 also include the IP Security Policies console, which enables you to actually configure and manage IPSec policies, manage filter lists and actions, and so forth. The IP Security Policies snap-in is included in the Local Security Policy console, which is listed in the Start menu's Administrative Tools folder.
To use the new snap-in, do the following:
Select Run from the Start menu.
Type
mmcand press Enter.From the File menu, select Add/Remove Snap-in.
Click Add.
Locate the IP Security Monitor in the list and double-click it.
Close all dialog boxes, and you'll be ready to work with the IP Security Monitor.
The Windows 2000 Server Resource Kit includes Ipsecpol.exe, a command-line tool for administering IPSec policies. Windows Server 2003 replaces this tool by bundling IPSec administration into the Netsh.exe command-line tool. You can now use Netsh.exe to configure main-mode policies, quick-mode policies, settings, rules, and other parameters. Just open a command-line window and run netsh –c ipsec to enter configuration mode.
First introduced in Windows XP, Universal Plug and Play (UPnP) promises to change a lot about the way we use computers. You're already familiar with basic Plug and Play (PnP), which enables Windows to automatically recognize and use hardware devices such as modems, printers, monitors, and more. UPnP extends the PnP concept to include network devices, allowing Windows to discover and use devices present on your network. One of the best current examples of UPnP in action is Windows's own Internet Connection Sharing (ICS) service. ICS provides UPnP discovery information, enabling UPnP clients to discover the presence of the gateway and request services from it. Hardware gateways, such as a cable or xDSL modem, could function similarly (and, in fact, UPnP-compatible gateways are now becoming available to purchase), allowing your client computers to automatically discover and take advantage of the gateway's capabilities.
Future applications of UPnP will likely eliminate the need to connect devices directly to your computer. Instead, devices will connect to your network, where they will be accessible to all networked computers. For example, a new printer could be plugged directly into your network. Client computers would immediately detect the new printer's presence, query the printer for its capabilities (whether it supports color, the paper sizes it can handle, and so forth), and set up an icon for the printer. Instantly, you could begin using the printer without any further configuration.
Traditionally, unconnected devices could use UPnP for new levels of technology integration. Your home stereo receiver, for example, could connect to your network, exposing its power, tuning, and volume controls to your client computers and enabling you to control the receiver from any desktop or laptop on your home network. Your DVD player could perform similar functions, streaming video from DVDs to any network-attached computer for a completely distributed home entertainment system. Other applications might include controllable lights, sprinklers, and other appliances. Although all devices must be connected to the network to operate, bear in mind that wireless networking, such as 802.11b or Bluetooth, are becoming less expensive and more common every day.
On a corporate network, UPnP offers better centralized management of networked devices. UPnP's protocols include authentication and security provisions, ensuring that only designated administrators can control UPnP devices. Windows Server 2003's UPnP support makes it ready to support UPnP devices as they are released; with the UPnP support also included in Windows XP, such devices will now start hitting the marketplace in force.
Windows Server 2003 now includes the Internet Connection Firewall (ICF), an entry-level firewall designed to protect specified network adapters from unauthorized network traffic. This feature is most frequently used in small environments, in conjunction with ICS. The combination of ICF and ICS provides small offices with the capability to share a single Internet connection through Windows Server 2003, while also providing protection from Internet-based hackers. Note that ICF is not available in the 64-bit edition of Enterprise Edition or in any edition of Datacenter Edition. As shown in Figure 10.4, ICF can be enabled by simply selecting a check box in the network connection's properties dialog box.
By default, ICF allows all outgoing traffic to pass through the firewall, and allows all replies to outgoing traffic to enter the network. This behavior accommodates the most common use of ICF, which is to protect an internal network from the Internet. You can also configure ICF to permit specific types of traffic, allowing ICF to protect an internal Web or mail server, if desired. Figure 10.5 shows the Advanced Settings dialog box, which you access by clicking the Settings button in the network connection's Properties dialog box.
The Advanced Settings dialog box includes three tabs:
Services—. This tab enables you to specify the network protocols, such as HTTP or FTP, that ICF should allow into your network from the outside. The list includes several common protocols, and you can add your own to accommodate specific applications available on your network.
Security Logging—. This tab allows you to enable ICFG logging and select a location for the log file. You can configure ICF to log all successful connections and dropped connections, providing a comprehensive log of firewall activity.
ICMP—. This tab allows you to configure the Internet Control Message Protocol (ICMP) traffic that ICF will allow to enter your network. ICMP is the protocol behind common troubleshooting tools such as ping, and blocking ICMP traffic prevents outsiders from gaining information about your internal network's infrastructure. However, you might need to temporarily enable ICMP traffic to troubleshoot connectivity problems.
The Routing and Remote Access Service (RRAS) included in Windows Server 2003 provides several functions that enable Windows to accept VPN connections, accept dial-up connections, act as a network router, provide Internet connectivity to an entire network (including NAT), and much more. Additionally, RRAS's snap-in has received a minor facelift for Windows Server 2003, making the service easier to configure and manage.
As always, RRAS includes robust remote access policies to control access to the server's connectivity features, static routing capability, dynamic routing protocols, a variety of remote access authentication protocols, and so forth.
Note
To learn more about RRAS and how it works, go to the book's product page at www.informit.com/store/product.aspx?isbn=0789728494. Click the Extras tab and locate article ID# A011001.
You can also configure RRAS as a NAT/firewall server by using the new Manage Your Server application, shown in Figure 10.6. This capability lets administrators configure their servers' operations from a single application and reduces the complexity of many basic configuration tasks. The Manage Your Server application also provides buttons that open the traditional management consoles, providing a central location for new administrators to locate Windows Server 2003's various management tools.
Figure 10.6. Manage Your Server enables you to configure a server for new roles, automatically adding new services (such as RRAS) and software as required.
Some of RRAS's other significant improvements include
Better EAP-TLS configuration—. A new dialog box allows you to more easily configure smart card and other certificate properties for RRAS authentication parameters. You can now configure multiple RADIUS servers and multiple root certification authorities, providing better integration with multiple networks or very large networks.
RRAS includes a new NetBIOS over TCP/IP proxy—. This provides remote access clients with name resolution capabilities without having to use a discreet DNS or WINS server. Using the proxy, RRAS can receive name resolution requests from the client, resolve those requests internally, and pass the response back to the client—all without the need to deploy a WINS or DNS server on the network. This new feature is especially useful to small businesses that would otherwise not require a DNS or WINS server.
Demand-dial connections can now use PPPoE in addition to regular modems and Ethernet connections—. This enables RRAS to automatically create network connections over broadband services, such as cable modems or xDSL modems. This feature lets you easily establish VPNs over a cable or xDSL connection or utilize RRAS's NAT and firewall capabilities to share a single cable or xDSL connection with an entire small network. Figure 10.7 shows a new demand-dial interface being created to use a PPPoE interface.
A major new functional improvement in RRAS is the NAT/Basic Firewall feature. This feature combines the ICS and ICF features into a single interface, allowing you to designate a particular network interface as a shared Internet connection and provide basic firewall capabilities for it. Unlike the basic ICS feature, NAT/Basic Firewall provides you with full control over RRAS's DHCP allocator, enabling you to customize the IP addresses RRAS provides to network clients. To create a new NAT/Basic Firewall interface, right-click Nat/Basic Firewall in the RRAS snap-in and select New Interface from the pop-up menu. You'll see a configuration dialog box similar to the one shown in Figure 10.8, which enables you to configure the interface as a shared connection, a shared connection with firewall capabilities, or a basic firewall. Although these capabilities aren't new to Windows, having them available from a single, unified interface with such easy administration is definitely a major improvement.
Figure 10.8. The new NAT/Basic Firewall interface makes configuring shared Internet connections for smaller offices easy.
RRAS also includes a number of VPN-specific enhancements. In Windows 2000, VPN servers dynamically register the names and IP addresses for all network interfaces with a DNS server. This creates problems when internal clients attempt to access server resources because they can receive the server's external IP address in a DNS query. Additionally, Windows 2000 enables NetBIOS on all network interfaces, which presents potential security problems if the server's external interface is connected to an unsecured network. In Windows Server 2003, the default registration behavior is changed, so dynamic DNS registration is disabled for both internal and external interfaces, and NetBIOS is disabled for the external interface. This new behavior requires you to manually create DNS host entries for your VPN servers but gives you full control over the IP address internal clients receive when they query the server's name. The new behavior also improves security by automatically disabling NetBIOS on the external interface.
Note
To learn more about VPNs and how they work, go to the book's product page at www.informit.com/store/product.aspx?isbn=0789728494. Click the Extras tab and locate article ID# A011002.
Another improvement isn't specifically targeted at VPNs, but rather at all demand-dial connections, including client-to-server VPN connections. In Windows 2000, RRAS could bridge from its external interface—including dial-up connections—only to its internal interface, which connects to the corporate network. In the case of an Internet-connected server, RRAS could not provide both corporate network and Internet access to demand-dial clients. In Windows Server 2003, however, RRAS has been extended so that its internal interface can be added as a private interface to the NAT service included in RRAS. The practical effect of this change is that RRAS can provide NAT services for both internal clients and demand-dial clients, including VPN clients.
One “disimprovement” for VPN support comes in Windows Server 2003 – Web Edition, which can support only one VPN connection using either L2TP/IPSec or PPTP. All other editions of Windows Server 2003 can support multiple simultaneous VPN connections. The intent of this change is to allow Windows Server 2003, Web Edition to accept a VPN connection for administrative purposes, but to otherwise function solely as a Web server.
One of the coolest new networking features is the Networking tab on the Windows Task Manager. As shown in Figure 10.9, this new tab displays a real-time graphical chart of network utilization, as well as summary statistics for all network interfaces in the computer. You can use the new tab to easily see which network adapters in your servers are working the hardest, spot initial signs of over utilization, and so forth.
Figure 10.9. The new Networking tab is just one of the additions to the Windows Server 2003 Task Manager.
Windows Server 2003 includes several networking enhancements that were originally introduced in Windows XP. Remember, Windows XP is the client equivalent of Windows Server 2003, so a great deal of feature parity exists between the two operating systems, despite their dissimilar names and user interfaces. The major enhancements are discussed next.
Windows Server 2003 is capable of notifying applications when network settings change. Some built-in services, such as Internet Connection Sharing, disable themselves when the computer is moved to a different network. This behavior ensures that applications function only when attached to the network for which they are configured and provides a more seamless experience on computers that are frequently moved between different networks.
These new policies, which are applicable to Windows Server 2003 and Windows XP computers, allow administrators to designate specific users as members of the Network Configuration Operators Group. Members of this group can modify their local TCP/IP properties, giving advanced users the flexibility to manually configure the network connections. You can also use the new group policies to block the local Administrators group of a computer from modifying ICS, ICF, network bridging, and general network settings, providing better control of computer configurations.
This new support eliminates the need for third-party software when connecting Windows Server 2003 to PPPoE connections, which are most often broadband cable or xDSL connections. By including PPPoE support in Windows Server 2003, Microsoft hopes to improve the stability and reliability of these broadband connections, which previously had to rely on poorly written software provided by ISPs. Native PPPoE support also makes leveraging other native features, such as ICS and ICF, with broadband connections easier.
Network bridging allows Windows Server 2003 to act as a bridge between dissimilar network architectures. For example, a small office might support both a wired network and a wireless network. By attaching a Windows Server 2003 computer to both networks and bridging the connections, Windows Server 2003 can join the two networks to create a single logical network. Any native network connection can be bridged, including Ethernet, wireless, phone line, and IEEE-1394 (FireWire). To bridge two connections, simply select them both in the Connections Manager window, right-click, and select Bridge Connections from the pop-up menu.
This new feature allows Windows Server 2003 to treat IEEE-1394 connections as network connections. Although this feature is often more useful on client computers (support is also included in Windows XP), IEEE-1394 networking support can be invaluable during server migration or consolidation. IEEE-1394 provides a fast, 400Mbps connection, enabling extremely fast file copy operations from one computer to another. This high-speed connectivity is ideal when moving large quantities of files from one server to another during a migration or consolidation and can, in many cases, be the fastest way to move those files.
Automatic configuration kicks in whenever a Windows Server 2003 computer is configured to obtain IP addressing information via DHCP but cannot contact a DHCP server. By default, Windows Server 2003 automatically generates an APIPA address in the 169.254.0.0/16 range, without a DNS server, default gateway, or other information. You can also manually configure alternative IP configuration settings to be used when a DHCP server is unavailable. Although this feature is most useful for client computers running Windows XP, you need to be aware of this feature's operation. For example, if you find that a server is using a 169.254.x.x IP address, you know that it was unable to contact your DHCP server.
The new Netstat tool can display active TCP connections, along with the process ID (PID) of the process handling the connection. This enormously useful new feature can enable you to track down IP ports that aren't supposed to be open, troubleshoot connectivity problems, and much more. Simply run Netstat and, as shown in Figure 10.10, the output will include process IDs for each open connection.
Built-in native support for xDSL recognizes the growing popularity of xDSL connections for branch offices and other business applications. The new support, referred to as permanent virtual circuit encapsulation, includes an intermediate device driver that appears to the operating system as an Ethernet interface but actually uses a DSL/Asynchronous Transfer Mode (ATM) permanent virtual circuit (PVC) to carry TCP/IP frames. This is a common implementation used by many xDSL carriers and enables Windows Server 2003 to support TCP/IP over PPP over ATM and TCP/IP over PPPoE, using vendor-supplied DSL/ATM miniport drivers. The practical advantage of all this is that future xDSL implementations will be of dispensing with specialized DSL modems and will rely on less expensive add-in cards, which will connect Windows Server 2003 directly to the DSL network.
Windows Server 2003 also sports a host of wireless networking improvements. Many of these improvements are better used on client computers than on servers because servers tend to be connected to high-speed wired networks. However, smaller environments can use wireless-connected servers and can benefit from these enhancements:
Support for 802.1X—. This is a standard for wireless port-based network access control that provides better network security.
Wireless Zero Configuration—. Allows Windows Server 2003 to automatically configure supported wireless network adapters, select a wireless network connection, and automatically switch to ad-hoc networking mode when an infrastructure network is unavailable.
Better roaming support—. This includes the ability to automatically request DHCP information when associating with a new wireless network, reauthenticating automatically when necessary, and so forth.
Group policy support for wireless network policies—. Allows centralized configuration of wireless networking policies. These policies can include preferred networks, privacy settings, and 802.1X settings. These settings can be applied along with other group policies to members of a site, a domain, or an organizational unit (OU) through Active Directory. Figure 10.11 shows the new policies in the Group Policy snap-in.
Finally, a few older networking protocols were removed from Windows Server 2003: The Direct Link Control (DLC) protocol, which was primarily used to connect to older Hewlett-Packard JetDirect network print servers, and the NetBEUI protocol. Note that NetBIOS still exists; NetBIOS is a session-level protocol. NetBEUI was a nonroutable, nonconfigurable transport protocol. The 64-bit editions of Windows Server 2003 also remove support for IrDA, an infrared communications protocol; IPX/SPX (and all IPX/SPX-dependent services); and the Open Shortest Path First (OSPF) routing protocol.
Additionally, Microsoft has removed support for RPC over NetBEUI, RPC over NetBIOS over TCP/IP, RPC over NetBIOS over IPX, RPC over IPX, and RPC over MSMQ. The 64-bit editions also eliminate RPC over SPX and RPC over AppleTalk.