New Networking Features in Windows Server 2008 and Windows Vista

Article
05/23/2012

Abstract

Microsoft® Windows Server® 2008 and Windows Vista™ include many changes and enhancements to networking technologies. This article describes the changes to protocols and core networking components, wireless and 802.1X-authenticated wired technologies, and network infrastructure components and services in Windows Server 2008 and Windows Vista.

Introduction

Networking and communications are critical for organizations to meet the challenge of competing in the global marketplace. Employees need to connect to the network wherever they are and from any device. Partners, vendors, and others outside the network need to interact efficiently with key resources, and security is more important than ever.

This article is a technical overview of networking and communications enhancements in Windows Server 2008 and Windows Vista to address connectivity, ease of use, management, reliability, and security. With Windows Server 2008 and Windows Vista, IT administrators have greater and more flexible options for managing networking infrastructure, protecting their networks by requiring computers to prove their system health, deploying settings for authenticated wireless and wired connections through Group Policy or scripts, and deploying protected traffic scenarios.

Protocols and Core Networking Components

Windows Server 2008 and Windows Vista include many changes and enhancements to the following protocols and core networking components:

Next Generation TCP/IP Stack
Domain Name System
Quality of Service
Server Message Block 2.0
Computer Browser Service
Http.sys enhancements
WinINet enhancements
Windows Sockets enhancements
Network Device Interface Specification (NDIS) 6.0 and 6.1
Network Awareness
Windows Peer-to-Peer Networking enhancements
Windows Firewall enhancements
Internet Protocol security (IPsec) improvements

Next Generation TCP/IP Stack

Windows Server 2008 and Windows Vista include a new implementation of the TCP/IP protocol stack known as the Next Generation TCP/IP stack. The Next Generation TCP/IP stack is a complete redesign of TCP/IP functionality for both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) that meets the connectivity and performance needs of today's varied networking environments and technologies.

For a complete list of resources, see the Next Generation TCP/IP Stack Web page.

Receive Window Auto Tuning

The TCP receive window size is the amount of data that a TCP receiver allows a TCP sender to send before having to wait for an acknowledgement. To correctly determine the value of the maximum receive window size for a connection based on the current conditions of the network, the Next Generation TCP/IP stack supports Receive Window Auto-Tuning. Receive Window Auto-Tuning continually determines the optimal receive window size on a per-connection basis by measuring the bandwidth-delay product (the bandwidth multiplied by the latency of the connection) and the application retrieve rate, and automatically adjusts the maximum receive window size on an ongoing basis.

With better throughput between TCP peers, the utilization of network bandwidth increases during data transfer. If all the applications are optimized to receive TCP data, then the overall utilization of the network can increase substantially, making the use of Quality of Service (QoS) more important for networks that are operating at or near capacity. For more information, see "Quality of Service" in this article.

For more information about Receive Window Auto-Tuning, see Performance Enhancements in the Next Generation TCP/IP Stack and TCP Receive Window Auto-Tuning.

Compound TCP

For TCP connections with a large receive window size and a large bandwidth-delay product, Compound TCP (CTCP) in the Next Generation TCP/IP stack aggressively increases the amount of data sent at a time by monitoring the bandwidth-delay product, delay variations, and packet losses. CTCP also ensures that its behavior does not negatively impact other TCP connections. In testing performed internally at Microsoft, large file backup times were reduced by almost half for a 1 Gigabit per second connection with a 50 millisecond round-trip time. Connections with a larger bandwidth-delay product can have even better performance.

Receive Window Auto Tuning optimizes receiver-side throughput and CTCP optimizes sender-side throughput. By working together, they can increase link utilization and produce substantial performance gains for large bandwidth-delay product connections.

CTCP is enabled by default for computers running Windows Server 2008 and disabled by default for computers running Windows Vista. You can enable CTCP with the netsh interface tcp set global congestionprovider=ctcp command and disable CTCP with the netsh interface tcp set global congestionprovider=none command.

ECN Support

When a TCP segment is lost, TCP assumes that the segment was lost due to congestion at a router and performs congestion control, which dramatically lowers the TCP sender’s transmission rate. With Explicit Congestion Notification (ECN) support (RFC 3168) on both TCP peers and the routers in the routing infrastructure, routers experiencing congestion mark the packets as they forward them. TCP peers receiving marked packets lower their transmission rate to ease congestion and prevent segment losses. Detecting congestion before packet losses are incurred increases the overall throughput between TCP peers. Windows Server 2008 and Windows Vista support ECN, but it is disabled by default. You can enable ECN support with the netsh interface tcp set global ecncapability=enabled command.

For more information, see Explicit Congestion Notification (ECN) for TCP/IP.

Enhancements for High-loss Environments

The Next Generation TCP/IP stack supports the following RFCs to optimize throughput in high-loss environments:

RFC 2582: The NewReno Modification to TCP's Fast Recovery Algorithm

The NewReno algorithm provides faster throughput by changing the way that a sender can increase their sending rate when multiple segments in a window of data are lost and the sender receives a partial acknowledgement (an acknowledgement for only part of the data that has been successfully received).
RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP

SACK, defined in RFC 2018, allows a receiver to indicate up to four noncontiguous blocks of received data. RFC 2883 defines an additional use of the fields in the SACK TCP option to acknowledge duplicate packets. This allows the receiver of the TCP segment containing the SACK option to determine when it has retransmitted a segment unnecessarily and adjust its behavior to prevent future retransmissions. The fewer retransmissions that are sent, the better the overall throughput.
RFC 3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP

The implementation of TCP/IP in Windows Server 2003 and Windows® XP uses SACK information only to determine which TCP segments have not arrived at the destination. RFC 3517 defines a method of using SACK information to perform loss recovery when duplicate acknowledgements have been received, replacing the fast recovery algorithm when SACK is enabled on a connection. The Next Generation TCP/IP stack keeps track of SACK information on a per-connection basis and monitors incoming acknowledgements and duplicate acknowledgements to more quickly recover when multiple segments are not received at the destination.
RFC 4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)

Spurious retransmissions of TCP segments can occur when there is a sudden and temporary increase in the round trip time (RTT). The F-RTO algorithm prevents spurious retransmission of TCP segments. The result of the F-RTO algorithm is that for environments that have sudden and temporary increases in the RTT, such as when a wireless client roams from one wireless access point (AP) to another, F-RTO prevents unnecessary retransmission of segments and more quickly returns to its normal sending rate.
RFC 3042: Enhancing TCP's Loss Recovery Using Limited Transmit

With Limited Transmit, when TCP has additional data to send on a connection and two consecutive duplicate ACKs have been received, TCP can send additional segments on the connection when the receiver's advertised window allows the transmission of the additional segments and when the additional segments contain data that is within two segments beyond the current congestion window. The ability of TCP to send additional segments helps ensure that fast retransmit can be used to detect segment losses, rather than waiting for an RTO timer expiration.

For more information about these enhancements, see Performance Enhancements in the Next Generation TCP/IP Stack.

For more information about TCP connections, data flow, and retransmission and timeout behavior, see the Windows Server 2008 TCP/IP Protocols and Services book from Microsoft Press.

Neighbor Unreachability Detection for IPv4

Neighbor Unreachability Detection is a feature of IPv6 in which a node tracks whether a neighboring node is reachable, providing better error detection and recovery when a neighboring node suddenly becomes unavailable. The Next Generation TCP/IP stack also supports Neighbor Unreachability Detection for IPv4 traffic by tracking the reachable state of IPv4 neighbors in the Address Resolution Protocol (ARP) cache. IPv4 Neighbor Unreachability Detection determines reachability through an exchange of unicast ARP Request and ARP Reply messages or by relying on upper layer protocols such as TCP. With IPv4 Neighbor Unreachability Detection, IPv4-based communications benefit by determining when neighboring nodes such as routers are no longer reachable.

For more information about Neighbor Unreachability Detection for IPv4, see Performance Enhancements in the Next Generation TCP/IP Stack.

Fail-back Support for Default Gateway Changes

Dead gateway detection in TCP/IP for Windows Server 2003 and Windows XP provides a fail-over function, but not a fail-back function in which a dead gateway is tried again to determine whether it has become available. The Next Generation TCP/IP stack provides fail-back for default gateway changes by periodically attempting to send TCP traffic through the previously detected unavailable gateway. If the TCP traffic sent through the previous gateway is successful, the Next Generation TCP/IP stack switches the default gateway back to the previous default gateway. Support for fail-back to primary default gateways can provide faster throughput by sending traffic through the primary default gateway on the subnet.

Changes in PMTU Black Hole Router Detection

Path maximum transmission unit (PMTU) discovery, defined in RFC 1191, relies on the receipt of Internet Control Message Protocol (ICMP) Destination Unreachable-Fragmentation Needed and Don’t Fragment (DF) Set messages from routers containing the MTU of the next link. However, in some cases, intermediate routers silently discard packets that cannot be fragmented. These types of routers are known as black hole PMTU routers. Additionally, intermediate routers might drop ICMP messages because of configured packet filtering rules. The result is that TCP connections can time out and terminate because intermediate routers silently discard large TCP segments, their retransmissions, and the ICMP error messages for PMTU discovery.

PMTU black hole router detection senses when large TCP segments are being retransmitted and automatically adjusts the PMTU for the connection, rather than relying on the receipt of the ICMP Destination Unreachable-Fragmentation Needed and DF Set messages. With TCP/IP in Windows Server 2003 and Windows XP, PMTU black hole router detection is disabled by default because enabling it often yielded false positive results, lowering the MTU unnecessarily and decreasing performance.

With increasing use of packet filtering rules on routers to drop ICMP traffic, the Next Generation TCP/IP stack enables PMTU black hole router detection by default to prevent TCP connections from terminating and uses an improved method of detecting PMTU black home routers. PMTU black hole router detection is triggered on a TCP connection when it begins retransmitting full-sized segments with the DF flag set. TCP resets the PMTU for the connection to 536 bytes and retransmits its segments with the DF flag cleared. This maintains the TCP connection, although at a possibly lower PMTU size than actually exists for the connection.

This behavior also applies to IPv6 traffic. For IPv6, the PMTU is set to 1220 bytes if a PMTU black hole router is detected.

Network Diagnostics Framework Support

The Network Diagnostics Framework is an extensible architecture that helps users recover from and troubleshoot problems with network connections. For TCP/IP-based communication, the Network Diagnostics Framework prompts the user through a series of options to eliminate possible causes until the root cause of the problem is identified or all possibilities are eliminated. Specific TCP/IP-related issues that the Network Diagnostics Framework can diagnose are the following:

Incorrect IP address
Default gateway (router) is not available
Incorrect default gateway
Network Basic Input/Output System (NetBIOS) over TCP/IP (NetBT) name resolution failure
Incorrect Domain Name System (DNS) settings
Local port is already being used
The Dynamic Host Configuration Protocol (DHCP) Client service is not running
There is no remote listener
The media is disconnected
The local port is blocked
Low on memory

For more information, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.

ESTATS Support

The Next Generation TCP/IP Stack supports the "TCP Extended Statistics MIB" Internet draft (draft-ietf-tsvwg-tcp-mib-extension-15.txt), which defines extended performance statistics for TCP. By analyzing ESTATS on a connection, it is possible to determine whether the performance bottleneck for a connection is the sending application, the receiving application, or the network. ESTATS is disabled by default and can be enabled per connection. With ESTATS, third-party independent software vendors (ISVs) can create powerful diagnostics and network throughput analysis applications. Tcpanalyzer.exe, available in the Windows Vista SDK, is a diagnostic tool based on ESTATS.

New Packet Filtering Model with Windows Filtering Platform

The Windows Filtering Platform (WFP) is a new architecture in the Next Generation TCP/IP Stack that provides APIs so that third-party ISVs can participate in the filtering decisions that take place at several layers in the TCP/IP protocol stack and throughout the operating system. WFP also integrates and provides support for next-generation firewall features such as authenticated communication and dynamic firewall configuration based on applications’ use of the Windows Sockets API (application-based policy). ISVs can create firewalls, anti-virus software, diagnostic software, and other types of applications and services. Windows Firewall and IPsec in Windows Server 2008 and Windows Vista use the WFP API.

For more information, see Windows Filtering Platform.

IPv6 Enhancements

The Next Generation TCP/IP Stack supports the following enhancements to IPv6:

Dual IP layer stack

The Next Generation TCP/IP stack supports a dual IP layer architecture in which the IPv4 and IPv6 implementations share common transport (that includes TCP and UDP) and framing layers. The Next Generation TCP/IP stack has both IPv4 and IPv6 enabled by default. There is no need to install a separate component to obtain IPv6 support.
Enabled by default

In Windows Server 2008 and Windows Vista, IPv6 is installed and enabled by default. You configure IPv6 settings through the properties of the Internet Protocol version 6 (TCP/IPv6) component in the Network Connections folder and through commands in the netsh interface ipv6 context.

IPv6 in Windows Server 2008 and Windows Vista cannot be uninstalled, but it can disabled. For more information, see Configuring IPv6 with Windows Vista.
GUI-based configuration

Windows Server 2008 and Windows Vista now allows you to manually configure IPv6 settings through a set of dialog boxes in the Network Connections folder, similar to how you can manually configure IPv4 settings.

For more information, see Configuring IPv6 with Windows Vista.
Teredo enhancements

The Teredo client in Windows Vista is enabled but might be active or inactive, depending on the computer’s configuration.

The Teredo client in Windows Server 2008 and Windows Vista uses the 2001::/32 prefix as assigned by IANA and uses unused bits in the Flags field of the Teredo address to help prevent address scans of Teredo addresses. For more information, see Teredo Overview.

Teredo can now be manually enabled for domain member computers and can work if there is one Teredo client behind one or more symmetric network address translators (NATs). A symmetric NAT maps the same internal (private) address and port number to different external (public) addresses and ports, depending on the external destination address (for outbound traffic). This new behavior allows Teredo to work between a larger set of Internet-connected hosts.

For more information about IPv6 and Teredo, see Using IPv6 and Teredo.
Integrated IPsec support

In Windows Server 2008 and Windows Vista, IPsec support for IPv6 traffic is the same as that for IPv4, including support for Internet Key Exchange (IKE) and data encryption. The Windows Firewall with Advanced Security and IP Security Policies snap-ins now support the configuration of IPsec policies for IPv6 traffic in the same way as IPv4 traffic. For example, when you configure an IP filter as part of an IP filter list in the IP Security Policies snap-in, you can now specify IPv6 addresses and address prefixes when specifying a specific source or destination IP address.

For more information, see The New Windows Firewall in Windows Vista and Windows Server 2008.
MLDv2

Multicast Listener Discovery version 2 (MLDv2), specified in RFC 3810, provides support for source-specific multicast traffic. MLDv2 is equivalent to Internet Group Management Protocol version 3 (IGMPv3) for IPv4.
LLMNR

Link-Local Multicast Name Resolution (LLMNR) allows IPv6 and IPv4 hosts on a single subnet without a DNS server to resolve each other’s names. This capability is useful for single-subnet home networks and ad hoc wireless networks. For more information, see Link-Local Multicast Name Resolution.
Support for ipv6-literal.net Names

Windows Vista and Windows Server 2008 support the use of IPv6Address.ipv6-literal.net names. An ipv6-literal.net name can be used in services or applications that do not recognize the syntax of normal IPv6 addresses.

To specify an IPv6 address within the ipv6-literal.net name, convert the colons (:) in the address to dashes (-). For example, for the IPv6 address 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. To specify a zone ID (also known as a scope ID), replace the “%” used to separate the IPv6 address from the zone ID with an “s”. For example to specify the destination fe80::218:8bff:fe17:a226%4, the name is fe80--218-8bff-fe17-a226s4.ipv6-literal.net.

You can use an ipv6-literal.net name in the computer name part of a Universal Naming Convention (UNC) path. For example, to specify the Docs share of the computer with the IPv6 address of 2001:db8:28:3:f98a:5b31:67b7:67ef, use the UNC path \\2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net\docs.
IPv6 over PPP

The built-in remote access client and the Routing and Remote Access service now support the IPv6 Control Protocol (IPV6CP), as defined in RFC 2472, to configure IPv6 nodes on a Point-to-Point Protocol (PPP) link. Native IPv6 traffic can now be sent over PPP-based connections. For example, IPV6CP support allows you to connect with an IPv6-based Internet service provider (ISP) through dial-up or PPP over Ethernet (PPPoE)-based connections that might be used for broadband Internet access.

For more information about IPv6 over PPP, see IPv6 over Point-to-Point Protocol Links.
Random Interface IDs for IPv6 Addresses

To prevent address scans of IPv6 addresses based on the known company IDs of network adapter manufacturers, Windows Server 2008 and Windows Vista by default generate random interface IDs for non-temporary autoconfigured IPv6 addresses, including public and link-local addresses. Windows XP and Windows Server 2003 use Extended Unique Identifier (EUI)-64-based interface IDs for autoconfigured IPv6 addresses.
DHCPv6 support

Windows Server 2008 and Windows Vista include a DHCPv6-capable DHCP client that will perform stateful address autoconfiguration with a DHCPv6 server. Windows Server 2008 includes a DHCPv6-capable DHCP server.

For more information about DHCPv6, see The DHCPv6 Protocol.

For more information about IPv6 changes in Windows Server 2008 and Windows Vista, see Changes to IPv6 in Windows Vista and Windows Server 2008.

For more information about IPv6 in Windows Server 2008 and Windows Vista, see the Understanding IPv6, Second Edition book from Microsoft Press.

TCP Chimney Offload

Managing TCP connections can involve a significant amount of processing, which includes:

Parsing the fields of the TCP header (validating the TCP checksum and processing sequence and acknowledgement numbers, TCP flags, and source and destination ports).
Creating and sending acknowledgements for data received.
Segmentation for data sent.
Copying of data between memory locations for the receive window, the send window, and applications.
Managing timers for TCP retransmission behavior.

By offloading this processing to dedicated hardware, a server computer's CPU can be used for other tasks. TCP Chimney Offload in Windows Server 2008 and Windows Vista provides automated, stateful offload of all TCP traffic processing to specialized network adapters that implement a TCP Offload Engine (TOE).

Rather than offloading individual tasks, the TOE-capable network adapter maintains state for the significant attributes of a connection, such as IP address, the TCP ports, and segment sequence numbers. This allows the network adapter to perform all of the processing of the TCP traffic without impacting the server's CPU. The benefit of offloading all TCP processing is most pronounced when TCP Chimney Offload is used for long-lived connections with large packet payloads, such as TCP connections for file backup and multimedia streaming.

By moving these TCP processing tasks to a TOE-enabled network adapter, the server's CPU is freed for other application tasks, such as supporting more user sessions or processing incoming requests faster.

For more information, see Windows Scalable Networking Initiative.

Domain Name System

Windows Server 2008 includes the following changes and enhancements to the Domain Name System (DNS) Server service:

Background zone loading DNS servers that host large DNS zones that are stored in Active Directory Domain Services are able to respond to client queries more quickly when they restart because zone data is now loaded in the background.
IPv6 support The DNS Server service now fully supports forward and reverse lookups for IPv6 and DNS traffic over IPv6.
Support for read-only domain controllers (RODCs) The DNS Server role in Windows Server 2008 provides primary read-only zones on RODCs.
Global single names The DNS Server service in Windows Server 2008 provides a new zone type, the GlobalNames zone, which you can use to store single-label names that can be unique across an entire forest. The GlobalNames zone provides single-label name resolution for large enterprise networks that do not deploy WINS and where using DNS name suffixes to provide single-label name resolution is not practical. For more information, see DNS Server GlobalNames Zone Deployment.

For more information about DNS support in Windows Server 2008, see DNS Server in the Windows Server 2008 Technical Library and DNS Enhancements in Windows Server 2008. For more information about DNS support in Windows, see the Microsoft DNS Web page.

Quality of Service

In Windows Server 2003 and Windows XP, quality of service (QoS) functionality is made available to applications through the QoS APIs. Applications that used the QoS APIs could access prioritized delivery functions. In Windows Server 2008 and Windows Vista, there are new facilities to manage network traffic for both enterprise and home networks.

Policy-based QoS for Enterprise Networks

QoS policies in Windows Server 2008 and Windows Vista allow IT staff to either prioritize or manage the sending rate for outgoing network traffic and can be confined to applications (by executable name or by application folder path), source and destination IPv4 or IPv6 addresses, source and destination TCP or UDP ports, and a range of ports. QoS policy settings are part of User Configuration or Computer Configuration Group Policy and are configured with the Group Policy Object Editor and linked to Active Directory containers (domains, sites, and organizational units) with the Group Policy Management Console. QoS policies can be applied to users or computers that are members of a domain, a site, an organizational unit, or filtered within an Active Directory container for a security group.

To manage the use of bandwidth, you can configure a QoS policy with a throttle rate for outbound traffic. Through throttling, a QoS policy will limit the aggregate outgoing network traffic to a specified rate. To specify prioritized delivery, traffic is marked with a configured Differentiated Services Code Point (DSCP) value. The routers in the network infrastructure can place DSCP-marked packets in different queues for differentiated delivery. For Wi-Fi Multimedia (WMM)-enabled wireless networks, DSCP values are mapped to WMM Access Categories. Both DSCP marking and throttling can be used together to manage traffic effectively. Because the throttling and priority marking is taking place at the Network layer, applications do not need to be modified.

Advanced policy-based QoS settings allow you to indirectly control incoming TCP data by specifying the maximum size of the TCP receive window (default size of 16 MB) and to specify whether applications can set DSCP values (allowed by default). Advanced QoS settings are only available for Computer Configuration Group Policy.

For more information about QoS support in Windows Vista and other versions of Windows, see the Quality of Service Web page.

qWave and QoS2 APIs for Home Networks

Because home networks are increasingly being shared by both data and audio/video (A/V) applications, a QoS solution is needed so that time-dependent A/V traffic can be given preferential treatment over data traffic. Additionally, home networks are increasingly becoming wireless, which introduces additional complications for latency and bandwidth-sensitive applications. Windows Vista supports Quality Windows Audio/Video Experience (qWave), a collection of QoS-related software components that address the network challenges introduced by A/V applications and wireless networks. qWave is integrated into the networking stack as part of the QoS subsystem and works with multiple network and data link layer packet priority technologies to support multiple A/V streams (real-time flows requiring QoS) and data streams (best-effort flows, such as e-mail or file transfers) simultaneously over a home network, while providing a high-quality user experience.

The collection of qWave technologies detect and monitor LAN bandwidth, discover the QoS capability of the home network, and provide distributed admission control for fair and consistent usage of network bandwidth. These technologies enable advanced A/V streaming techniques so that applications can dynamically adapt to variable network conditions.

Server Message Block 2.0

Server Message Block (SMB), also known as the Common Internet File System (CIFS), is the file sharing protocol used by default on Windows-based computers. Windows includes an SMB client (the Client for Microsoft Windows component installed through the properties of a network connection) and an SMB server (the File and Printer Sharing for Microsoft Windows component installed through the properties of a network connection). SMB in versions of Windows prior to Windows Server 2008 and Windows Vista, known as SMB 1.0, was originally designed 15 years ago for early Windows-based network operating systems such as Microsoft LAN Manager and Windows for Workgroups and carries with it the limitations of its initial design.

SMB in Windows Server 2008 and Windows Vista also supports SMB 2.0; a new version of SMB that has been redesigned for today’s networking environments and the needs of the next generation of file servers. SMB 2.0 has the following enhancements:

Supports sending multiple SMB commands within the same packet. This reduces the number of packets sent between an SMB client and server, a common complaint against SMB 1.0.
Supports much larger buffer sizes compared to SMB 1.0.
Increases the restrictive constants within the protocol design to allow for scalability. Examples include an increase in the number of concurrent open file handles on the server and the number of file shares that a server can have.
Supports durable handles that can withstand short interruptions in network availability.
Supports symbolic links.

Computers running Windows Server 2008 or Windows Vista support both SMB 1.0 and SMB 2.0. The version of SMB that is used for file sharing operations is determined during the SMB session negotiation. The following table shows which version of SMB that is used for various combinations of client and server computers.

Client	Server	Version of SMB used
Windows Server 2008 or Windows Vista	Windows Server 2008 or Windows Vista	SMB 2.0
Windows Server 2008 or Windows Vista	Windows XP, Windows Server 2003, or Windows 2000	SMB 1.0
Windows XP, Windows Server 2003, or Windows 2000	Windows Server 2008 or Windows Vista	SMB 1.0
Windows XP, Windows Server 2003, or Windows 2000	Windows XP, Windows Server 2003, or Windows 2000	SMB 1.0

Computer Browser Service

Windows Server 2008 sets the startup state of the Computer Browser service to disabled by default for a new installation of Windows Server and when upgrading an existing server to Windows Server 2008. The Computer Browser service helps maintain an updated list of domains, workgroups, and server computers on the network and supplies this list to client computers upon request. For detailed information about Computer Browser service operation, see Appendix C - Computer Browser Service.

The default startup state of the Computer Browser service on computers running Windows Server 2008 can cause problems for a domain controller in the primary domain controller flexible single master operations (PDC FSMO) role. For computer browsing, a computer in the PDC FSMO role centrally collects and distributes information about domains, workgroups, and computers for multi-subnet networks. If the computer in the PDC FSMO role is not running the Computer Browser service, computer browse lists across the network will contain only domains, workgroups, and computers on the local subnet. To prevent this problem, configure the startup type for the Computer Browser service for Automatic on the computer in the PDC FSMO role and then start Computer Browser service. You can do this from the Services snap-in or at an elevated command prompt with the following commands:

sc config browser start= auto

sc start browser

Because the Computer Browser service relies on file and printer sharing, you will also need to turn on File and Printer Sharing in the Network and Sharing Center. Alternatively, move the PDC FSMO role to another domain controller that has the Computer Browser service started and configured for automatic startup and File and Printer Sharing turned on in the Network and Sharing Center.

Additionally, if the only server computer on a subnet is running Windows Server 2008, client computers will become the local browse server on the subnets. As client computers are started and are shut down, the role of the local browse server will pass from one client computer to another, possibly resulting in an inconsistent display of domains, workgroups, and computers. To prevent this problem, on the computer running Windows Server 2008, turn on file and printer sharing, configure the startup type for the Computer Browser service for Automatic, and then start the Computer Browser service.

Http.sys Enhancements

Http.sys, the kernel mode driver that services Hypertext Transfer Protocol (HTTP) traffic, has been enhanced in Windows Server 2008 and Windows Vista with the following:

HTTP Server API 2.0
Server-side authentication
Logging
ETW tracing for HTTP events
Netsh commands
Performance counters

HTTP Server API 2.0

HTTP Server API is a kernel-mode HTTP protocol driver with user-mode APIs available through Httpapi.dll. The HTTP Server APIs enables a server application to register HTTP URLs, receive requests, and service responses. HTTP Server APIs include:

Simple-to-use HTTP listener functionality on Windows for native Windows applications.
Applications can use the HTTP Server API to co-exist and share TCP ports with HTTP Server API applications, such as Internet Information Services (IIS) 7.0. This allows popular Web traffic TCP ports such as 80 and 443 to be used by multiple server applications simultaneously as long as they are serving different parts of the URL namespace.
A native HTTP stack for computers running on a Windows operating system that is HTTP/1.1 compliant.
New APIs for configuring the HTTP server: Authentication, Bandwidth Throttling, Logging, Connection Limits, Server State, 503 Responses, Request Queues, Response Caching, and SSL Certificate Binding. For more information, see Using the HTTP Server Version 2.0 API.

Server-side Authentication

Http.sys now provides server-side authentication through the HTTP Server 2.0 APIs for the following schemes: Negotiate (Kerberos | NTLM), NTLM, Basic, and Digest. Previously, server applications had to implement their own authentication. Advantages to Http.sys providing the server-side authentication include the following:

Server applications can run under lower privileged accounts.
Server applications that support Kerberos authentication can now run under a different account than the default account associated with the Service Principle Name (SPN) of the local machine. A service using Http.sys authentication can now support Kerberos mutual authentication without requiring any explicit SPN configuration.
Seamless NTLM authentication handshakes do not cause a restart of the handshake process.

Logging

Http.sys now provides logging through the HTTP Server 2.0 APIs, supporting the following formats: W3C, centralized W3C, NCSA, IIS, and centralized binary log format. Within the centralized log file, site ID fields identify the site to which the log entries belong.

IDNA Support

Http.sys now supports Internationalized Domain Names (IDN) for hostnames. Clients can request sites with IDN hostnames. Http.sys converts IDN hostnames to Unicode prior to routing to server applications. For all encoding formats used by clients in hostnames, Http.sys performs checks and normalization of hostnames according to the IDN in Applications (IDNA) standard (RFC 3490).

ETW Tracing for HTTP Events

Event Tracing for Windows (ETW) is a capability of Windows to obtain information about components and events, typically written to log files. ETW log files make it much easier to troubleshoot problems. Tracing can also diagnose end-to-end issues, in which an Activity ID indicates the flow across operations. Http.sys supports tracing for the following categories:

HTTP requests and responses
SSL and authentication transactions
Logging events
Connections and connection timers
Cache
Service or application setup; setting or deleting properties
Activity ID based, including across other ETW-enabled components

For each tracing category, Http.sys supports four levels of information: Error, Warning, Informational, and Verbose. Http.sys tracing can be used as an advanced troubleshooting tool to obtain information about Http.sys processes and behavior.

To start an ETW trace session for Http.sys, do the following:

Create a folder to store the trace files. From this folder, create a file named Httptrace.txt with the following contents:
```
"Microsoft-Windows-HttpService" 0xFFFF
```

Use the following command to start tracing:

logman start "http trace" -pf httptrace.txt -o httptrace.etl -ets

Perform the steps or tests that need to be traced.

To stop the ETW trace session for Http.sys, use the following command:

logman stop "http trace" -ets

An Httptrace.etl trace file should now appear in the folder. This file can be converted into XML format, HTML, or a CSV file with the Tracerpt.exe tool. For example, to convert the contents of the Httptrace.etl file into a CSV file, use the following command:

tracerpt httptrace.etl -y -o httptrace.csv

The CSV files can then be viewed in a text editor or spreadsheet application.

Netsh commands for Http.sys

You can now manage configuration settings and control diagnostics for Http.sys through a set of commands in the netsh http context. Netsh is a command-line tool that is used by many other Windows networking services, such as IPsec and Routing and Remote Access. The commands in the netsh http context replace the sample tool Httpconfig.exe. With this new support, you can do the following at a Windows command prompt:

Configure SSL certificate bindings, URL reservations, IP listen lists, or global timeouts
Delete or flush the HTTP cache or logging buffers
Display the Http.sys service or cache state

Performance Counters for Http.sys

Http.sys now has the following performance metric counters to help you with monitoring, diagnosing, and capacity planning for Web servers:

HTTP Service Counters
- Number of URIs in the cache, added since startup, deleted since startup, and number of cache flushes
- Cache hits/second and Cache misses/second
HTTP Service URL Groups
- Data send rate, data receive rate, bytes transferred (sent and received)
- Maximum number of connections, connection attempts rate, rate for GET and HEAD requests, and total number of requests
HTTP Service Request Queues
- Number of requests in queue, age of oldest requests in queue
- Rate of request arrivals into the queue, rate of rejection, total number of rejected requests, rate of cache hits

With these new performance counters, metrics can be viewed in through the Diagnostic Console snap-in or obtained through the Performance Counters API.

WinINet Enhancements

Enhancements to the WinINet API in Windows Server 2008 and Windows Vista include the following:

Support for IPv6 literals and scope IDs
Support for HTTP decompression
Support for Internationalized Domain Names
Support for ETW tracing
IPv6 support in Web Proxy Auto-Discovery scripts

Support for IPv6 Literals and Scope IDs

WinINet now supports RFC 3986 and the use of IPv6 literal addresses in URLs. For example, to connect to the Web server at the IPv6 address 2001:db8:100:2a5f::1, a user with a WinINet-based Web browser (such as Internet Explorer) can type http://[2001:db8:100:2a5f::1] as the address. Although typical users might not use IPv6 literal addresses, the ability to specify the IPv6 address in the URL is valuable to application developers, software testers, and network troubleshooters. WinINet also supports the encoding of the IPv6 scope ID (also known as a zone ID) as part of the address to allow users to specify the scope for the IPv6 destination. For more information, see IP Version 6 Support.

Support for HTTP Decompression

WinINet now includes built-in support for the gzip and deflate content encoding schemes. Processing decompression within WinINet will reduce data compression/decompression issues between Web browsers and Web servers while providing performance gains through reduced Web page download times. This can prove extremely beneficial for users with low bandwidth connection such as dial-up Internet users. For more information, see Content Encoding.

Support for Internationalized Domain Names

WinINet now conforms to the Internationalized Domain Names (IDN) standard (RFC 3490) for hostnames when you use the Unicode versions of the WinINet API. This new support ensures that applications work correctly with domain names containing non-ASCII characters without requiring IDN support within the Web application, installation of a third-party plug-in, or intermediate nodes in a network communication path. For more information, see IDN Support in WinINet.

Support for ETW Tracing

WinINet now supports ETW tracing that allows IT helpdesk and support specialists to obtain detailed information about WinINet processes and events to help determine the source of protocol or application problems. By including identifiers for all of the WinINet events, you can construct a chain of ETW traces that span the entire networking stack, using the identifiers to associate traces from adjacent networking layers. For more information about ETW Tracing, see Event Tracing.

IPv6 support in Web Proxy Auto-Discovery scripts

Web Proxy Auto-Discovery (WPAD) script helper functions exposed by WinINet have been updated to include support for IPv6 addresses and subnet prefixes. WPAD scripts that use the dnsResolve, myIpAddress, isInNet, and isResolvable Proxy Helper APIs can now obtain IPv6 information from WinINet. For more information about WPAD, see WinHTTP AutoProxy Support.

WinHTTP Enhancements

Updates to the WinHTTP 5.1 API in Windows Server 2008 and Windows Vista include the following:

Support for data uploads larger than 4 gigabytes
Support for chunked transfer encoding
Support for issuer list retrieval for Secure Sockets Layer (SSL)-based client authentication
Support for optional client certificate requests
Support for 4-tuple connection information indication
New error codes for SSL client authentication
IPv6 support in WPAD scripts

Support for Data Uploads Larger than 4 Gigabytes

WinHTTP now allows applications to add a “Content-Length” header to specify a data length up to 264 bytes.

Support for Chunked Transfer Encoding

WinHTTP now allows applications to perform “chunked” transfer encoding for their data and send them using the WinHttpWriteData API. WinHTTP will detect the presence of a “Transfer-Encoding” header and make internal adjustments to ensure that the transfer is compliant to the HTTP 1.1 specification.

Support for Issuer List Retrieval for Secure Sockets Layer-based Client Authentication

WinHTTP now allows the application to retrieve the issuer list that is associated with a client authentication challenge. An issuer list specifies a list of certification authorities (CAs) that are authorized by the server to issue client certificates. With this new support, a WinHTTP application can determine the correct client certificate to use for client authentication.

Support for Optional Client Certificate Requests

Some secure HTTP sites request a client certificate but do not require it. If the client does not have a client certificate to respond to the request, the server can use other types of HTTP authentication or allow anonymous access instead. To support interoperation with such server configurations, WinHTTP now allows an application to supply a NULL client certificate to indicate to the server that it does not have a client certificate for Secure Sockets Layer (SSL) authentication.

Support for 4-tuple Connection Information Indication

Upon completion of a WinHttpReceiveResponse API, WinHTTP now allows an application to query the source IP/port and destination IP/port associated with the HTTP request that results in the response.

New Error Codes for SSL Client Authentication

WinHTTP now includes error codes for the following common errors in SSL client authentication:

The client certificate does not have an associated private key, which is typically caused by importing a client certificate without the private key.
The application thread that calls WinHttpSendRequest or WinHttpReceiveResponse does not have the privilege to access the private key associated with the supplied client certificate. Verify that the access control list (ACL) for the private key allows the application to access it.

IPv6 Support in WPAD Scripts

WPAD script helper functions exposed by WinHTTP have been updated to include support for IPv6 addresses and subnet prefixes. WPAD scripts that use the dnsResolve, myIpAddress, isInNet, and isResolvable Proxy Helper APIs can now obtain IPv6 information from WinHTTP. For more information about WPAD, see WinHTTP AutoProxy Support.

For information about enhancements to WinHTTP in Windows Server 2008 and Windows Vista, see What's New in Windows Server 2008 and Windows Vista and SSL in WinHTTP.

Windows Sockets Enhancements

Windows Sockets (Winsock) support has been updated with the following:

New Winsock APIs
ETW Tracing for Winsock events
Layered Service Provider enhancements
Winsock Network Diagnostics Framework module
New kernel mode Sockets API

New Winsock APIs

Windows Server 2008 and Windows Vista include the following new Winsock APIs:

WSAConnectByName Creates a connection to the specified destination, given the destination host’s name. WSAConnectByName takes all the destination addresses returned by name resolution, all the local addresses, and attempts connections by using address pairs with the highest chance of success. An optimal pairing algorithm provided by the transport determines the order of the address pairs. WSAConnectByName ensures a connection will be established (if possible), in the minimal amount of time.
WSAConnectByList Creates a connection to the specified destination, given a list of destination IP addresses. WSAConnectByList takes a list of M addresses and the local computer’s N addresses, and tries connecting using up to M x N address combinations before failing to connect.
WSASendMsg Sends data and optional control information from connected and unconnected sockets. The WSASendMsg function can be used in place of the WSASend and WSASendTo functions.
WSAPoll Determines status of one or more sockets.

For more information on these new APIs, search MSDN for the API name.

ETW Tracing for Winsock Events

The following are some of the Winsock events that can be traced with ETW tracing:

Socket creation
Bind
Connect
Accept
Send
Recv
Abort indications

You can enable ETW tracing for Winsock events using the following:

Event Viewer snap-in
Logman.exe and Tracerpt.exe tools

To enable ETW Tracing for Winsock events using the Event Viewer snap-in, do the following:

Run the Event Viewer tool in the Administrative Tools folder.
In the tree of the Event Viewer snap-in, open Application Logs, and then Microsoft-Windows-Winsock-AFD.
Click the Winsock/AFD item.
In the Action pane, click Log Properties.
In the Log Properties dialog box, click Enable Logging, and then click OK.

To view the events, in the Action pane, click Refresh. To disable logging, clear the Enable Logging check box on the Log Properties dialog box for the Winsock/AFD item.

You might have to increase the log size depending on how many events you want to view.

To enable ETW Tracing for Winsock events using the Logman.exe tool, use the following commands:

logman create trace afdlog –o LogFileLocation
logman update afdlog –p “Microsoft-Windows-Winsock-AFD”
logman start afdlog

A binary log file will be written to LogFileLocation. To convert the binary file written by the Logman.exe tool into readable text, use the Tracerpt.exe tool. For example, use the following command:

tracerpt.exe c:\afdlog.etl –o afdlog.txt

To stop logging, use the following command:

logman stop afdlog

Layered Service Provider Enhancements

Winsock Layered Service Provider (LSP) support in Windows Server 2008 and Windows Vista has been enhanced with the following:

The installation and removal of LSPs are logged in the system event log to help determine which applications are installing LSPs and to troubleshoot failed LSP installations. To view the events logged in a console window, use the netsh winsock audit trail command.
There is a new installation API (WSCInstallProviderAndChains) that software vendors can use to install an LSP into the Winsock catalog. Manually installing an LSP can be done using a series of Winsock functions, but if done improperly can leave the Winsock LSP catalog in an inconsistent state. Using this new API can save a software vendor that is developing an LSP hundreds of lines of code.
There are new facilities to categorize LSPs and to remove most LSPs from the processing path for system critical services. These new facilities provide more stability to Windows, protecting system critical services from improperly designed LSPs.
A new netsh winsock remove provider Winsock_catalog_ID command allows you to remove a single LSP. Use this command instead of the netsh winsock reset command, which resets the Winsock catalog to a clean state.
There is a Winsock-specific diagnostics module for the Network Diagnostics Framework that will allow users to selectively repair the Winsock catalog by removing only those LSPs that are causing problems.

For more information about the Network Diagnostics Framework, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.

New Kernel Mode Sockets API

The networking architecture of Windows Server 2008 and Windows Vista include a new interface called Winsock Kernel (WSK) . WSK is a new transport-independent kernel mode Network Programming Interface (NPI) for TDI clients. Using WSK, kernel-mode software modules can perform network communication using socket-like programming semantics similar to those supported in the user-mode Windows Sockets 2 API. While TDI is supported in Windows Vista for backward compatibility, TDI clients should be updated to use WSK to achieve the best performance.

For background information, see Intro to WinSock Kernel (WSK) and Network Programming with Winsock Kernel (WSK). For WSK API information, see Winsock Kernel.

NDIS 6.0

Windows Server 2008 and Windows Vista with no service packs installed include Network Driver Interface Specification (NDIS) 6.0. NDIS specifies a standard interface between kernel-mode network drivers and the operating system. NDIS also specifies a standard interface between layered network drivers, abstracting lower-level drivers that manage hardware from upper-level drivers, such as network transports. For more information about NDIS, see Networking.

NDIS 6.0 includes the following features:

New offload support
Support for lightweight filter drivers
Receive-side scaling

New Offload Support

NDIS 6.0 includes the following new support for offloading network traffic processing functions to network adapters:

Offload of IPv6 traffic NDIS 5.1 in Windows Server 2003 and Windows XP already supports the offload of IPv4 traffic processing. NDIS 6.0 now supports the offload of IPv6 traffic processing.
Checksum offload supports IPv6 Offloading of checksum calculations for IPv6 traffic is now supported.
Large Send Offload version 2 NDIS 5.1 already supports Large Segment Offload (LSO), which offloads the segmentation of TCP data for data blocks up to 64 Kilobytes (KB) in size. Large Send Offload version 2 (LSOv2) in NDIS 6.0 can offload the segmentation of TCP data for data blocks larger than 64 Kilobytes (KB) in size.

Support for Lightweight Filter Drivers

In NDIS 6.0, intermediate filter drivers have been replaced with Lightweight Filter (LWF) drivers that are a combination of an NDIS intermediate driver and a miniport driver. LWF drivers but have the following advantages:

There is no longer a need to write a separate protocol and miniport. All of these functions are contained within a single driver.
Improved performance.
A bypass mode allows the LWF driver to examine only selected control and data paths.

An example of an intermediate filter driver that has been converted to a LWF driver is Pacer.sys, formerly known Psched.sys. It has the same functionality, but takes advantage of performance improvements available with NDIS 6.0.

Receive-Side Scaling

In the architecture for multiprocessor computers running Windows Server 2003 or Windows XP, a network adapter is associated with a single processor. The single processor must handle all the traffic received by the network adapter, regardless of whether there are other processors available. The result of this architecture for high-volume servers such as Internet-facing Web servers or enterprise file servers is that the amount of incoming traffic and number of connections that can be serviced by the processor associated with the network adapter is limited. If the processor associated with the network adapter cannot handle the incoming traffic fast enough, the network adapter discards the traffic, resulting in retransmissions and reduced performance.

In Windows Server 2008 and Windows Vista, a network adapter is not associated with a single processor. Instead, the processing for incoming traffic is distributed among the processors on the computer. This new feature, known as Receive-side Scaling, allows for much more traffic to be received by a network adapter on a high-volume server. A multiprocessor computer can now handle more incoming traffic without having to add servers, resulting in lower costs. To take advantage of this new feature, you must install Receive-side Scaling compatible network adapters that can take advantage of the new architecture in Windows Server 2008 and Windows Vista. Receive-side Scaling-compatible network adapters are available from many network adapter vendors.

For more information, see Scalable Networking with RSS.

NDIS 6.1

Windows Server 2008 and Windows Vista with SP1 support NDIS 6.1, which includes the following features:

Header-data split services
Direct OID Request Interface
IPsec Task Offload Version 2
NETDMA Updates

Header-data Split Services

Header-data split services improve network performance by splitting the header and data in received Ethernet frames into separate buffers. By separating the headers and the data, these services enable the headers to be collected together into smaller regions of memory. More headers fit into a single memory page and more headers fit into the system caches. Therefore, the overhead for memory accesses in the driver stack is reduced. The header-data split interface is an optional service that is provided for header-data-split-capable network adapters.

Direct OID Request Interface

NDIS 6.1 provides a direct OID request interface for NDIS 6.1 and later drivers. The direct OID request path supports OID requests that are queried or set frequently. The direct OID request interface is optional for NDIS drivers. To support the direct OID path, drivers provide entry points and NDIS provides NdisXxx functions for protocol, filter, and miniport drivers.

For NDIS 6.1, the only interface that uses the direct OID request interface is IPsec offload version 2 (IPsecOV2).

IPsec Task Offload Version 2

IPsec task offload provides offloading services for IPsec network data processing to IPsec offload-capable network adapters. NDIS 6.1 supports IPsecOV2. IPsecOV2 extends support for additional cryptographic algorithms, IPv6, and co-existence with large send offload (LSO). IPsecOV2 uses the NDIS 6.1 direct OID request interface.

NETDMA Updates

NETDMA provides services for offloading the memory copy operation performed by the networking subsystem, when receiving network packets, to a dedicated DMA engine. Windows Server 2008 and Windows Vista with SP1 support NETDMA versions 1.1 and 2.0. NETDMA version 2.0 introduces support for a more efficient DMA setup and Plug and Play. In addition, on Windows Server 2008 and Windows Vista SP1, NETDMA versions 1.1 and 2.0 will be used in more scenarios and configurations.

Network Awareness

Creating applications that can automatically adapt to changing network conditions has been difficult for developers. The Network Awareness APIs in Windows Vista allow applications to do the following:

Register with Windows Vista to be informed when there are changes to the network to which the computer is connected.

For example, a user places a laptop into standby mode at work and then opens it at a wireless hotspot. After being alerted of network changes by Windows Vista, applications can automatically configure themselves or behave differently to provide a more seamless user experience.
Query Windows Vista for characteristics of the currently connected network to determine the application settings and behavior. Characteristics include the following:
- Connectivity A network may be disconnected, it may provide access to only the local network, or it may provide access to the local network and the Internet.
- Connections The computer may be connected to a network by one or more connections (such as network adapters). Network Awareness APIs enable applications to determine the connections that Windows Vista is currently using to connect to a network.
- Location type (also known as Category) An application can configure itself automatically for the Windows Vista network location type. For more information, see Network Location Types in Windows Vista.

Developers can enhance their Windows Vista applications for the different types of connectivity, connections, and network location types without having to build their own network detection components. The Network Awareness APIs allow developers to focus on features that make network connectivity transparent to the user, rather than the details of lower-level network determination.

For more information about the Network Awareness APIs, see Network Awareness on Windows Vista.

Windows Peer-to-Peer Networking Enhancements

Windows Peer-to-Peer Networking, originally introduced with the Advanced Networking Pack for Windows XP, is an operating system platform component and API in Windows Vista that allows the development of peer-to-peer (P2P) applications. Windows Vista includes the following enhancements to Windows Peer-to-Peer Networking:

New, easy to use API APIs to access Windows Peer-to-Peer Networking capabilities such as name resolution, group creation, and security have been highly simplified in Windows Vista, making it easier to create P2P applications for Windows.
New version of PNRP Windows Vista includes version 2 of the Peer Name Resolution Protocol (PNRP) that is more scalable and uses less network bandwidth. For PNRP v2 in Windows Vista, Windows Peer-to-Peer Networking applications can access PNRP name publication and resolution functions through a simplified PNRP API. For highly simplified PNRP name resolution in Windows Vista, PNRP names are now integrated into the Getaddrinfo Windows Sockets function. To use PNRP to resolve a name to an IPv6 address, applications can use the Getaddrinfo function to resolve the Fully Qualified Domain Name (FQDN) name.prnp.net, in which name is peer name being resolved. The pnrp.net domain is a reserved domain in Windows Vista for PNRP name resolution. The PNRP v2 protocol is incompatible with PNRP version 1 that was provided with the Advanced Networking Pack for Windows XP. Microsoft has released a PNRP v2 upgrade for Windows XP, which is available through Windows Update or from the Microsoft Download Center. For more information about PNRP, see Peer Name Resolution Protocol.
People Near Me A new capability of Windows Peer-to-Peer Networking for Windows Vista that allows users to dynamically discover other users on the local subnet. For more information, see People Near Me.
Contact management and serverless presence Peer-to-Peer Networking integrates with the Windows Address Book to provide functions for long term contact management. Users can add trusted contacts to the Windows Address Book by exchanging “Me” contact files with each other. The “Me” contact file is automatically created when a user starts the collaboration infrastructure for the first time. It contains information that identifies a user, and can be used by others to protect against spoofing and to track a user’s presence through the Internet.
Application invite This new capability allows applications to invite other users into collaborative activities. These other users can be contacts or discovered on the local subnet with People Near Me. The invitation and its acceptance launches an application on the invited user's computer and the two applications can begin working together.
Windows Meeting Space Windows Vista includes Windows Meeting Space, a new P2P-based application that allows users to easily set up meetings, share files, pass notes, and project applications to the group. Windows Meeting Space uses Windows Peer-to-Peer Networking functionality.
Netsh configuration support You can now configure Windows Peer-to-Peer Networking settings from commands in the netsh p2p context.
Group Policy configuration support You can now configure Windows Peer-to-Peer Networking settings with Group Policy from the Computer Configuration\Administrative Templates\Network\Microsoft Peer-to-Peer Networking Services node.

Windows Firewall

The new Windows Firewall in Windows Server 2008 and Windows Vista has the following enhancements over the current Windows Firewall in Windows XP with Service Pack 2 and later and Windows Server 2003 with Service Pack 1 and later:

Supports filtering of both incoming and outgoing traffic

A network administrator can configure the new Windows Firewall with a set of rules (known as exceptions for Windows Firewall in Windows XP with Service Pack 2 and later and Windows Server 2003 with Service Pack 1 and later) to block all traffic sent to specific ports, such as the well-known ports used by virus software, or to specific addresses containing either sensitive or undesirable content.
New Windows Firewall with Advanced Security Microsoft Management Console (MMC) snap-in for graphical user interface (GUI) configuration

The new Windows Firewall with Advanced Security snap-in, available from the Administrative Tools folder, provides wizards for configuring firewall rules for inbound and outbound traffic and connection security rules. For command-line configuration of advanced settings of the new Windows Firewall, you can use commands in the netsh advfirewall context.
Firewall filtering and Internet Protocol security (IPsec) protection settings are integrated

When using the Windows Firewall with Advanced Security snap-in, you can configure both firewall filtering and traffic protection rules.
Advanced configuration for rules (exceptions)

Configuration options for firewall filtering rules include three different profiles (domain, public, and private), source and destination IP addresses, IP protocol number, source and destination Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports, all or multiple TCP or UDP ports, specific types of interfaces, ICMP and ICMP for IPv6 (ICMPv6) traffic by Type and Code, services, the protection state (protected with IPsec), edge traversal, and specified users and computers based on Active Directory accounts.

Unlike the Windows Firewall in Windows Server 2003 with Service Pack 1 and Windows Server 2003 with Service Pack 2, the new Windows Firewall in Windows Server 2008 is enabled by default.

For more information about these improvements, see The New Windows Firewall in Windows Vista and Windows Server 2008. For additional information, see Introduction to Windows Firewall with Advanced Security.

IPsec Improvements

Windows Server 2008 and Windows Vista include the following improvements to Internet Protocol security (IPsec):

Integrated firewall and IPsec configuration
Simplified IPsec policy configuration
Client-to-DC IPsec protection
Improved load balancing and clustering server support
Improved IPsec authentication
New cryptographic support
Integration with Network Access Protection
Additional configuration options for protected communication
Integrated IPv4 and IPv6 support
Extended events and performance monitor counters
Network Diagnostics Framework support

Integrated Firewall and IPsec Configuration

In Windows Server 2003 and Windows XP, Windows Firewall and IPsec were components and services that had to be configured separately. Although the purpose of Windows Firewall was to block or allow incoming traffic, IPsec could also be configured to block or allow incoming traffic. Because block and allow traffic behavior for incoming traffic could be configured through two different and separate services, it was possible to have duplicated or contradictory settings. Additionally, Windows Firewall and IPsec supported different configuration options for specifying allowed incoming traffic. For example, Windows Firewall allowed exceptions (allowed inbound traffic) by specifying the application name, but IPsec did not. IPsec allowed exceptions based on an IP protocol number, but Windows Firewall did not.

In Windows Server 2008 and Windows Vista, Windows Firewall and IPsec configuration have been combined into a single tool with the new Windows Firewall with Advanced Security snap-in, which now controls both traditional firewall responsibilities (blocking and allowing both inbound and outbound traffic) and protecting traffic with IPsec. Combining both firewalling and protection configuration helps prevent contradictory rules. Additionally, commands within the netsh advfirewall context can be used for command line configuration of both firewall and IPsec behavior. The integration of Windows Firewall with IPsec provides computers running Windows Server 2008 or Windows Vista with an authenticating firewall.

Simplified IPsec Policy Configuration

In Windows Server 2003 and Windows XP, IPsec policy configuration in many scenarios such as Server and Domain Isolation consists of a set of rules to protect most of the traffic on the network and another set of rules for protected traffic exemptions. Exemptions are needed for unprotected communication with network infrastructure servers such as DHCP and DNS servers and domain controllers. When a computer is starting, it must be able to obtain an IP address, use DNS to find a domain controller, and then log in to its domain before it can begin to use Kerberos authentication to authenticate itself as an IPsec peer. Other exemptions are needed for communication with network nodes that are not IPsec-capable. In some cases, there are dozens or hundreds of exceptions, which makes it more difficult to deploy IPsec protection on an enterprise network and to maintain it over time.

IPsec in Windows Server 2008 and Windows Vista provides an optional behavior when negotiating IPsec protection. If enabled, when initiating communication with another network node, an IPsec node running Windows Server 2008 or Windows Vista will attempt to communicate in the clear and negotiate protected communication in parallel. If the initiating IPsec peer does not receive a response to the initial negotiation attempt, the communication continues in the clear. If the initiating IPsec peer receives a response to the initial negotiation attempt, the communication in the clear continues until the negotiation can complete, at which point subsequent communications are protected.

With this optional behavior and the recommended configuration to require protection for incoming initiated communications and request protection for outgoing initiated communications, the initiating node discovers whether the node it is communicating with is capable of IPsec and behaves accordingly. This new behavior greatly simplifies IPsec policy configuration. For example, the initiating node does not need a set of predefined IPsec filters for exemptions for the set of hosts that either should not or cannot protect network traffic with IPsec. The initiating node tries both protected and unprotected traffic in parallel and if protected communication is not possible, the initiating node uses unprotected communication.

This new negotiation behavior also improves the performance of unprotected connections to hosts. An IPsec node running Windows Server 2003 or Windows XP that is configured to request protected communications but allow unprotected communications—a behavior known as fallback to clear—sends the negotiation messages and then waits for a response. The initiating node waits up to 3 seconds before falling back to clear and attempting unprotected communications. With Windows Server 2008 and Windows Vista, there is no longer a 3-second delay when falling back to clear because communications in the clear is already in progress while the initiating node is waiting for a response.

Note

The IPsec Simple Policy Update for Windows Server 2003 and Windows XP includes new negotiation behavior to simplify IPsec policy. Windows Server 2003 Service Pack 2 and Windows XP Service Pack 3 include the Simple Policy Update. For more information, see Simplifying IPsec Policy with the Simple Policy Update.

Client-to-DC IPsec Protection

For Windows Server 2003 and Windows XP, Microsoft does not support IPsec to protect traffic between domain controllers and member computers (however, Microsoft does support protecting traffic between domain controllers). This is because the IPsec policy configuration can become very complex due to the different types of traffic sent between domain members and domain controllers. Additionally, there is a domain join issue. If the domain controller requires IPsec-protected traffic from computers that must provide domain-based credentials for authentication, a computer that is not a member of the domain cannot contact a domain controller to join the domain. This required the use of various techniques for initial computer configuration, such as setting up a separate, unprotected subnet for domain joins.

Windows Server 2008 and Windows Vista supports securing traffic between domain members and domain controllers in the following deployment modes:

You can configure IPsec policy in the domain to request protected traffic but not require it.

Domain controllers will protect most traffic with domain members but allow clear text for domain joins and other types of traffic.
You can configure IPsec policy to require protected traffic for domain controllers.

Domain controllers are configured with IPsec settings that allow the use of Windows NT/LAN Manager version 2 (NTLM v2) user credentials for authentication. When a computer running Windows Server 2008 or Windows Vista attempts to join the domain, the user is prompted for the user name and password of a domain user account. IPsec protection with the domain controller is negotiated with Windows NT/LAN Manager version 2 (NTLM v2) user credentials for a protected domain join. This new behavior is only available for domain member computers running either Windows Vista or Windows Server 2008 and for domain controllers running Windows Server 2008.

Because of the new negotiation behavior, you no longer have to configure exemptions for domain controllers, simplifying IPsec policy and deployment of IPsec protection in a domain.

Improved Load Balancing and Clustering Server Support

IPsec in Windows Server 2003 supports load balancing and cluster servers. However, failover times to re-establish IPsec connectivity to a cluster virtual IP address are the following:

Typically 3-6 seconds for administrative moves of clustered resources.
Up to two minutes when a cluster node suddenly becomes unavailable or another sudden loss of connectivity occurs. The timeout of two minutes includes one minute for the IPsec idle time to expire and one minute to renegotiate security associations (SAs). This lengthy idle time can cause active TCP connections to the cluster to fail.

In Windows Server 2008 and Windows Vista, the timeout for a cluster node failure is substantially reduced. IPsec in Windows Server 2008 and Windows Vista is more tightly integrated into the Next Generation TCP/IP stack. Rather than relying on IPsec idle timeouts to detect a cluster node failure, IPsec in Windows Server 2008 and Windows Vista monitors TCP connections for established SAs. If the TCP connection for an established SA begins retransmitting segments, IPsec will renegotiate the SAs. The result is that the failover to a new cluster node happens quickly, typically in time to keep the application from failing.

Improved IPsec Authentication

IPsec in Windows Server 2003 and Windows XP supports the Internet Key Exchange (IKE) and three authentication methods during main mode negotiations: Kerberos (for Active Directory domain members), digital certificates, and preshared key. For all of these authentication methods, the authentication process is validating the identity and trustworthiness of a computer, rather than the user of the computer. IKE only attempts a single authentication using a single authentication method.

Windows Server 2008 and Windows Vista supports the following improvements in IPsec authentication:

Ability to require that IPsec peers authenticate with a health certificate

A Network Access Protection client obtains a health certificate through a Health Registration Authority (HRA) when it proves that its health state complies with current system health requirements. For more information about the Network Access Protection platform, see "Network Access Protection" in this article.
Ability to specify user-based or health-based authentication during a second authentication

With support for Authenticated IP (AuthIP), IPsec in Windows Server 2008 and Windows Vista allows a second authentication for IPsec-protected communication. With a second authentication, IPsec in Windows Server 2008 and Windows Vista can perform an additional level of authentication, which can be based on the following:
- Kerberos credentials of the logged in user account
- NTLM v2 credentials of the computer account
- NTLM v2 credentials of the logged in user account
- A user certificate
- A computer health certificate
For example, you can use the first authentication and Kerberos credentials to authenticate the computer and then the second authentication and a health certificate to validate the computer's health state. Second authentication can be configured with or without the first authentication.
Multiple authentication methods are attempted

In Windows Server 2003 and Windows XP, you can select multiple authentication methods in a preference order for main mode IPsec authentication. However, only one authentication method is used for authentication. If the authentication process for the negotiated authentication method fails, main mode fails and IPsec protection cannot be performed. When you select multiple authentication methods for computers running Windows Server 2008 or Windows Vista, IPsec will attempt multiple authentication attempts in an effort to perform mutual authentication. For example, if you specify that you want to authenticate using computer certificates with a specific certification authority (CA) and then Kerberos, the IPsec peer will attempt Kerberos authentication if the certificate authentication fails.

For more information about IPsec authentication improvements, see AuthIP in Windows Vista. For more information about AuthIP, see The Authenticated Internet Protocol.

New Cryptographic Support

In response to governmental security requirements and trends in the security industry to support stronger cryptography, Windows Server 2008 and Windows Vista support additional key derivation and encryption algorithms.

Windows Server 2008 and Windows Vista support the following additional algorithms to negotiate the master key material derived during main mode negotiation:

Diffie-Hellman (DH) Group 19, which is an elliptic curve algorithm using a 256-bit random curve group (NIST identifier P-256)
DH Group 20, which is an elliptic curve algorithm using a 384-bit random curve group (NIST identifier P-384)

These methods are stronger than DH algorithms supported in Windows Server 2003 and Windows XP with Service Pack 2 and later. For more information about these algorithms, see RFC 4753. These new DH algorithms cannot be used for main mode negotiation with a computer running Windows Server 2003, Windows XP, or Windows 2000.

In addition to the Data Encryption Standard (DES) and Triple-DES (3DES), Windows Server 2008 and Windows Vista support the following additional algorithms for encrypting data:

Advanced Encryption Standard (AES) with cipher block chaining (CBC) and a 128-bit key size (AES 128)
AES with CBC and a 192-bit key size (AES 192)
AES with CBC and a 256-bit key size (AES 256)

These new encryption algorithms cannot be used for IPsec SAs with a computer running Windows Server 2003, Windows XP, or Windows 2000.

Windows Server 2008 and Windows Vista SP1 also include support for Suite B, a standard from the National Security Agency (NSA) that defines a common set of cryptographic algorithms for the needs of the US government.

For Suite B support, Windows Server 2008 and Windows Vista SP1 include the following additional integrity algorithms for main mode negotiation:

Secure Hash Algorithm (SHA)-256
SHA-38

Windows Server 2008 and Windows Vista SP1 include the following integrity algorithms for providing data integrity when using either Authentication Header (AH) or Encapsulating Security Payload (ESP):

SHA-256
AES-Galois Message Authentication Code (GMAC)-128
AES-GMAC-192
AES-GMAC-25

Windows Server 2008 and Windows Vista SP1 include the following integrity algorithms for providing data integrity and encryption when using ESP only:

AES-Galois/Counter Mode (GCM)-128
AES-GCM-192
AES-GCM-256

Windows Server 2008 and Windows Vista SP1 also include the following authentication methods:

Computer certificate with Elliptic Curve Digital Signature Algorithm (ECDSA)-P256 signing
Computer certificate with ECDSA-P384 signing

These new integrity algorithms and authentication methods can be configured using commands in the netsh advfirewall context. They cannot be configured with the Windows Firewall with Advanced Security or IPsec Policies snap-ins.

The additional Suite B integrity algorithms and authentication methods cannot be used for IPsec SAs with a computer running Windows Server 2003, Windows XP, or Windows 2000.

For more information about Suite B support in IPsec, see RFC 4869.

Integration with Network Access Protection

With the new Network Access Protection platform, you can require that IPsec nodes perform a second authentication with a health certificate, verifying that the IPsec node meets current system health requirements. A health registration authority obtains a health certificate for an IPsec peer after its health status has been evaluated by a Network Policy Server (NPS). For more information, see “Network Access Protection” in this article.

Additional Configuration Options for Protected Communication

When you configure a connection security rule with the new Windows Firewall with Advanced Security snap-in, you can specify the following additional settings:

By application name This greatly simplifies protected traffic configuration because the ports used by the application do not need to be manually configured.
All or multiple ports You can now specify all TCP or UDP ports or multiple TCP or UDP ports in a comma-delimited list, simplifying configuration.
For all addresses in a numeric range You can now specify a range of IP addresses using a numeric range, such as 10.1.17.23 to 10.1.17.219.
For all addresses on the local subnet A set of predefined addresses that are dynamically mapped to the set of addresses defined by your IPv4 address and subnet mask or by your IPv6 local subnet prefix.
For all wireless adapters You can protect traffic based on the interface type, which now includes wireless in addition to LAN and remote access.
By Active Directory user or computer account You can specify the list of computer or user accounts or groups that are authorized to initiate protected communication. For example, this allows you to specify that traffic to specific servers with sensitive data must be protected and can only originate from user accounts that are members of specific Active Directory security groups.
By ICMP or ICMPv6 Type or Code value You can specify ICMP or ICMPv6 messages with values of the ICMP or ICMPv6 message Type and Code fields.
For services You can specify that the exception applies to any process, only for services, for a specific service by its service name, or you can type the short name for the service.

Integrated IPv4 and IPv6 Support

IPsec support for IPv6 traffic in Windows XP and Windows Server 2003 is limited. For example, there is no support for Internet Key Exchange (IKE) or data encryption. IPsec security policies, security associations, and keys must be configured through text files and activated using the Ipsec6.exe command line tool.

In Windows Server 2008 and Windows Vista, IPsec support for IPv6 traffic is the same as that for IPv4, including support for IKE and data encryption. IPsec policy settings for both IPv4 and IPv6 traffic are configured in the same way using either the Windows Firewall with Advanced Security or IP Security Policies snap-ins.

Extended Events and Performance Monitor Counters

Windows Server 2008 and Windows Vista include new IPsec audit-specific events and the text of existing events has been updated with more useful information. These improvements will help you troubleshoot failed IPsec negotiations without having to enable the advanced Oakley logging capability.

Windows Server 2008 and Windows Vista also include IPsec performance counters to help identify performance and networking issues with IPsec-protected traffic.

Network Diagnostics Framework Support

The Network Diagnostics Framework is an extensible architecture that helps users recover from and troubleshoot problems with network connections. For a failed IPsec negotiation, the Network Diagnostics Framework will prompt a user with an option to identify and correct the problem. IPsec support for the Network Diagnostics Framework then attempts to discover the source of the failed connection and either automatically correct the problem, or, depending on security considerations, prompt the user to make the appropriate configuration change.

For more information about the Network Diagnostics Framework, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.

Wireless and 802.1X-based Wired Connections

Windows Server 2008 and Windows Vista include many enhancements to support IEEE 802.11 wireless networks and networks that use IEEE 802.1X authenticating switches.

IEEE 802.11 Wireless Changes and Enhancements

Windows Server 2008 and Windows Vista include the following changes and enhancements to IEEE 802.11 wireless support:

Native Wi-Fi architecture
User interface improvements for wireless connections
Wireless Group Policy enhancements
Changes in Wireless Auto Configuration
WPA2 support
FIPS 140-2 certified mode
Integration with Network Access Protection when using 802.1X authentication
EAPHost infrastructure
802.11 wireless diagnostics
Command-line support for configuring wireless settings
Network Location Awareness and network profiles
Next Generation TCP/IP stack enhancements for wireless environments
Single Sign On

For additional information, see Wireless Networking in Windows Vista.

Native Wi-Fi Architecture

In Windows Server 2003 and Windows XP, the software infrastructure that supports wireless connections was built to emulate an Ethernet connection and can only be extended by supporting additional EAP types for IEEE 802.1X authentication. In Windows Server 2008 and Windows Vista, the software infrastructure for 802.11 wireless connections, called the Native Wi-Fi Architecture, has been redesigned for the following:

IEEE 802.11 is now represented inside of Windows as a media type separate from IEEE 802.3. This allows independent hardware vendors (IHVs) more flexibility in supporting advanced features of IEEE 802.11 networks, such as a larger frame size than Ethernet.
New components in the Native Wi-Fi Architecture perform authentication, authorization, and management of 802.11 connections, reducing the burden on IHVs to incorporate these functions into their wireless network adapter drivers. This makes the development of wireless network adapter drivers much easier. In Windows Server 2008 and Windows Vista, IHVs must develop a smaller NDIS 6.0 miniport driver that exposes a native 802.11 interface on its top edge.
The Native Wi-Fi Architecture supports APIs to allow ISVs and IHVs the ability to extend the built-in wireless client for additional wireless services and custom capabilities. Extensible components written by ISVs and IHVs can also provide customized configuration dialog boxes and wizards.

User Interface Improvements for Wireless Connections

The wireless configuration user interface (UI) has been improved with the following:

Wireless configuration integrated into new Network and Sharing Center Connectivity to wireless networks has been integrated into the new Network and Sharing Center in Windows Vista, rather than from the properties of a wireless network adapter. From the Network and Sharing Center, you can connect to wireless networks, set up a wireless network that uses a wireless access point (AP) or an ad hoc wireless network, and manage your wireless networks.
Wireless networks can be configured for all users or per-user In the Manage Wireless Networks folder (available from the Network and Sharing Center), you can now specify the wireless network profile type. This allows you to specify that new wireless networks (known as profiles) apply to all users of the computer or can be configured to apply to specific users. Per-user wireless profiles are only connected when the user to which the profile applies logs in to the computer. Per-user profiles are disconnected when the user logs off or switches to another user.
Extensible wireless UI As described in the “Native Wi-Fi Architecture” section of this article, custom wireless configuration dialog boxes or wizards can be written and added to the built-in Windows wireless client, allowing the configuration of custom ISV or IHV wireless features and capabilities.
Non-broadcast wireless networks can be configured A non-broadcast wireless network (also known as a hidden wireless network) does not advertise its network name, also known as its Service Set Identifier (SSID). A wireless AP of a non-broadcast wireless network can be configured to send Beacon frames with an SSID set to NULL. This practice is known as using non-broadcast SSIDs. In Windows Server 2003 and Windows XP, you could not configure a preferred wireless network as non-broadcast, which sometimes produced confusing behavior when automatically connecting to preferred wireless networks, some of which are non-broadcast and some of which are not. For computers running Windows XP with SP3, Windows XP with SP2 and the Wireless Client Update for Windows XP with Service Pack 2, or Windows Server 2003 with Service Pack 2, you can now configure a preferred wireless network as a non-broadcast network. In Windows Server 2008 and Windows Vista, you can also configure a preferred wireless network as a non-broadcast network.
Non-broadcast wireless networks displayed as "Unnamed Network" In the list of available wireless networks in the Connect to a network wizard in Windows Vista and Windows Server 2008, non-broadcast networks appear with the name "Unnamed Network". When you connect to the non-broadcast wireless network, you will be prompted to type the non-broadcast wireless network name.
Prompts user when connecting to unsecured wireless network Due to the risks associated with communicating on unsecured wireless networks, Windows Server 2008 and Windows Vista will now prompt the user when connecting to an unsecured wireless network and allow them to confirm the connection attempt.
Network connection wizard lists the security methods supported by the wireless network adapter The Connect to a network wizard in Windows Server 2008 and Windows Vista retrieves the security capabilities of the wireless network adapter and allows the user to select the strongest security method. For example, if a wireless network adapter supports both Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA), the Connect to a network wizard will allow the user to select WPA or WEP as the security method.

For more information about the new wireless configuration UI, see Connecting to Wireless Networks with Windows Vista.

Wireless Group Policy Enhancements

In Windows Server 2008 and Windows Vista, wireless Group Policy settings—located in the Computer Configuration/Windows Settings/Security Settings node in the Group Policy snap-in—include the following enhancements:

WPA2 authentication options Wireless Group Policy settings in Windows Server 2008 and Windows Vista allow you to configure WPA2 authentication options; WPA2 (for WPA2 Enterprise) and WPA2-PSK (for WPA2 Personal). To configure WPA2 authentication options for computers running Windows XP, you must install Windows XP Service Pack 3 or Windows XP Service Pack 2 and the Wireless Client Update for Windows XP with Service Pack 2. Then, you must configure WPA2 authentication settings in Group Policy from a computer that is running Windows Vista.
Lists of allowed and denied wireless network names The wireless client in Windows Server 2003 and Windows XP prompts the user to connect to detected wireless networks if none of the preferred wireless networks were found or if none of the connections to detected preferred wireless networks were successful. Wireless client computers running Windows Server 2003 or Windows XP could not be configured to prompt the user to only connect to specific wireless networks or never prompt the user to connect to specific wireless networks. The wireless Group Policy settings in Windows Server 2008 and Windows Vista allow you to configure lists of allowed and denied wireless network names. For example:
- With an allow list, you can specify the set of wireless networks by name (SSID) to which the Windows Server 2008 or Windows Vista wireless client is allowed to connect. This is useful for network administrators that want an organization's laptop computer to connect to a specific set of wireless networks, which might include the organization’s wireless network and wireless Internet service providers.
- With a deny list, you can specify the set of wireless networks by name to which the wireless client is not allowed to connect. This is useful to prevent managed laptop computers from connecting to other wireless networks that are within range of the organization’s wireless network (such as when an organization occupies a floor of a building and there are other wireless networks of other organization on adjoining floors) or to prevent managed laptop computers from connecting to known unprotected wireless networks.
Additional preferred wireless network settings The wireless Group Policy settings in Windows Server 2008 allow configuration of the following for preferred wireless networks:
- Fast roaming settings Fast roaming is an advanced capability of WPA2 wireless networks that allow wireless clients to more quickly roam from one wireless AP to another by using preauthentication and pairwise master key (PMK) caching. With Windows Server 2008 and Windows Vista, you can configure this behavior through wireless Group Policy settings. With Windows XP SP3 or Windows XP SP2 and the Wireless Client Update for Windows XP with Service Pack 2, you can control this behavior with registry settings that are described in Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update for Windows XP with Service Pack 2.
- Non-broadcast wireless networks As described in the “User interface improvements for wireless connections” section of this article, you can locally configure preferred wireless networks as non-broadcast wireless networks. With Windows Server 2008, you can now configure preferred wireless networks in wireless Group Policy settings as non-broadcast networks.
- Automatic or manual connection With Windows XP Service Pack 3, Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, Windows Server 2008, and Windows Vista, you can configure a preferred wireless network for automatic (the default) or manual connection on the Connection tab of the properties of the preferred wireless network. With wireless Group Policy settings in Windows Server 2008, you can now configure preferred wireless networks for automatic or manual connection.

For more information, see Wireless Group Policy Settings for Windows Vista.

For information about how to extend the schema of a Windows Server 2003 Active Directory environment to support Windows Vista wireless and wired Group Policy enhancements, see Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements.

Changes in Wireless Auto Configuration

Wireless Auto Configuration is a service that dynamically selects the wireless network to which the computer will automatically connect, based either on your preferences or on default settings. This includes automatically selecting and connecting to a more preferred wireless network when it becomes available. Windows Server 2008 and Windows Vista include the following changes to Wireless Auto Configuration:

Change in behavior when there are no preferred wireless networks available

In Windows XP and Windows Server 2003, if a preferred wireless network cannot be connected and the wireless client is configured to prevent automatic connection to wireless networks that are not in the preferred list (the default), Wireless Auto Configuration creates a random wireless network name and places the wireless network adapter in infrastructure mode. However, the random wireless network does not have a security configuration, making it possible for a malicious user to connect to the wireless client using the random wireless network name. Windows XP SP3 and Windows XP SP2 with the Wireless Client Update for Windows XP with Service Pack 2 modifies this behavior by configuring the wireless network adapter with a random name and a security configuration consisting of a 128-bit random encryption key and the strongest encryption method supported by the wireless network adapter. This new behavior helps prevent a malicious user from connecting to the wireless client using the random wireless network name.

For computers running Windows Server 2008 or Windows Vista that use updated wireless drivers designed for Windows Vista, Wireless Auto Configuration removes the vulnerability by parking the wireless network adapter in a passive listening mode. While parked, the wireless network adapter will not send Probe Request frames for a random wireless network name or any other name and malicious users cannot connect to the wireless client. Most wireless network drivers have been updated for Windows Vista. If you are using a wireless network adapter driver that was designed for Windows XP, computers running Windows Vista or Windows Server 2008 will use a random wireless network name with a security configuration.
New support for non-broadcast wireless networks

In Windows XP and Windows Server 2003, Wireless Auto Configuration attempts to match configured preferred wireless networks with wireless networks that are broadcasting their network name. If none of the available networks match a preferred wireless network, Wireless Auto Configuration then sends probe requests to determine if the preferred networks in the ordered list are non-broadcast networks. The result of this behavior is that broadcast networks will be connected to before non-broadcast networks, even if a non-broadcast network is higher in the preferred list than a broadcast network. Another result is that a Windows XP or Windows Server 2003 wireless client advertises its list of preferred wireless networks when sending probe requests. For computers running Windows XP with SP3, Windows XP with SP2 and the Wireless Client Update for Windows XP with Service Pack 2, or Windows Server 2003 with SP2, you can now configure a preferred wireless network as a non-broadcast network.

In Windows Server 2008 and Windows Vista, you can configure wireless networks as broadcast (the wireless network name is included in the Beacon frames sent by the wireless AP) or non-broadcast (the Beacon frame contains a wireless network name set to NULL). Wireless Auto Configuration now attempts to connect the wireless networks in the preferred network list order, regardless of whether they are broadcast or non-broadcast. Because the wireless networks are now explicitly marked as broadcast or non-broadcast, Windows Server 2008 or Windows Vista wireless clients only send probe requests for non-broadcast wireless networks.

WPA2 Support

Windows Server 2008 and Windows Vista include built-in support to configure WPA2 authentication options with both the standard profile (locally configured preferred wireless networks) and the domain profile with Group Policy settings. WPA2 is a product certification available through the Wi-Fi Alliance that certifies wireless equipment as being compatible with the IEEE 802.11i standard. WPA2 in Windows Server 2008 and Windows Vista supports both WPA2-Enterprise (IEEE 802.1X authentication) and WPA2-Personal (preshared key authentication) modes of operation.

Windows Server 2008 and Windows Vista also include support for WPA2 for an ad hoc mode wireless network (a wireless network between wireless clients that does not use a wireless AP).

FIPS 140-2 Certified Mode

Windows Server 2008 and Windows Vista with Service Pack 1 support AES encryption in a Federal Information Processing Standard (FIPS) 140-2 certified mode. FIPS 140-2 is a U.S. government computer security standard that specifies design and implementation requirements for cryptographic modules. Windows Server 2008 and Windows Vista with Service Pack 1 are FIPS 140-2 certified. When you enable FIPS 140-2 certified mode, Windows Server 2008 or Windows Vista with Service Pack 1 will perform the AES encryption in software, rather than relying on the wireless network adapter. You can enable FIPS 140-2 certified mode with the netsh wlan set profileparameter command and through the advanced security settings of a wireless network profile in wireless Group Policy.

Integration with Network Access Protection when using 802.1X Authentication

WPA2-Enterprise, WPA-Enterprise, and dynamic WEP connections that use 802.1X authentication can leverage the Network Access Protection platform to prevent wireless clients that do not comply with system health requirements from gaining unlimited access to an intranet. For more information about the Network Access Protection platform, see "Network Access Protection (NAP)" in this article.

EAPHost Infrastructure

For easier development of Extensible Authentication Protocol (EAP) authentication methods for IEEE 802.1X-authenticated wireless connections, Windows Server 2008 and Windows Vista supports the new EAPHost infrastructure. For more information, see "EAPHost Architecture" in this article.

New Default EAP Authentication Method

In Windows Server 2003 and Windows XP, the default EAP authentication method for 802.1X-authenticated wireless connections is EAP-Transport Layer Security (TLS). Although the most secure form of authentication employing mutual authentication with digital certificates, EAP-TLS requires a public key infrastructure (PKI) to distribute, revoke, and renew user and computer certificates.

In many cases, organizations want to leverage the account name and password-based authentication infrastructure that already exists in Active Directory. Therefore, in Windows Server 2008 and Windows Vista, the default EAP authentication method for 802.1X-authenticated wireless connections has been changed to Protected EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2). PEAP-MS-CHAP v2 is a password-based 802.1X authentication method for wireless connections that only requires computer certificates to be installed on the Remote Authentication Dial-In User Service (RADIUS) servers. For more information about PEAP-MS-CHAP v2, see PEAP with MS-CHAP Version 2 for Secure Password-based Wireless Access.

Diagnostics Support for Wireless Connections

Troubleshooting failed wireless connections, although improved in Windows XP Service Pack 3 and Windows Server 2003 Service Pack 2, can still be difficult. In Windows Server 2008 and Windows Vista, troubleshooting wireless connections is made much easier through the following features:

Wireless connections support the new Network Diagnostics Framework The Network Diagnostics Framework is an extensible architecture that helps users recover from and troubleshoot problems with network connections. For a failed wireless connection, the Network Diagnostics Framework will prompt a user with an option to identify and correct the problem. Wireless support for the Network Diagnostics Framework then attempts to discover the source of the failed connection and either automatically correct the problem, or, depending on security considerations, prompt the user to make the appropriate configuration change.

For more information about the Network Diagnostics Framework, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.
New information stored in the Windows event log For a failed wireless connection attempt, the wireless components of Windows Server 2008 and Windows Vista record detailed information about the connection attempt in the Windows event log. These event records can be used by support professionals within an organization to perform further troubleshooting when the wireless diagnostics either could not resolve the problem or when it could resolve the problem but the problem cannot be fixed by changing wireless client settings. The information in the Windows event log can shorten the time needed to resolve wireless connection support problems. Additionally, these event log entries can be automatically collected by network administrator using Microsoft Operations Manager or other types of central management tools and analyzed for trends and wireless infrastructure design changes.
Wireless diagnostics tracing To perform a detailed analysis, Microsoft or your support specialists need in-depth information about the computer’s state and wireless components in Windows and their interaction when the problem occurred. You can obtain this information from wireless diagnostics tracing in Windows Vista and Windows Server 2008. To use wireless diagnostics tracing, you must start tracing, reproduce the problem, stop tracing, and then collect the tracing report. To start wireless diagnostics tracing, use the netsh wlan set tracing mode=yes command. To stop wireless diagnostics tracing, use the netsh wlan set tracing mode=no command. To view the tracing report, in the console tree of the Reliability and Performance Monitor snap-in, open Reports, System, and then Wireless Diagnostics. For additional information about wireless diagnostics facilities in Windows Vista, see Wireless Networking in Windows Vista.
Information can be sent to Microsoft for analysis and improvements Users that experience wireless connection problems will also be prompted to send the connection information to Microsoft for analysis through the Windows Error Reporting (WER) infrastructure. Additionally, successful diagnostics can be sent to Microsoft through the Software Quality Metrics (SQM) infrastructure, also known as the Customer Experience Improvement Program in Windows XP. In both cases, only wireless network diagnostic information is sent (no personal information about the computer or the user). Microsoft will use this information to identify the top root causes for wireless connection failures, identify new wireless connection problems and their causes, and take appropriate actions to either improve the wireless client software in Windows or work with wireless vendors to help improve wireless hardware products.

Command Line Interface for Configuring Wireless Settings

Windows Server 2003 or Windows XP does not have a command line interface that allows you to configure the wireless settings that are available from the wireless dialog boxes in the Network Connections folder or through the Wireless Network (IEEE 802.11) Policies Group Policy settings. Command line configuration of wireless settings can help deployment of wireless networks in the following situations:

Automated script support for wireless settings without using Group Policy Wireless Network (IEEE 802.11) Policies Group Policy settings only apply in an Active Directory domain. For an environment without Active Directory or a Group Policy infrastructure, a script that automates the configuration of wireless connections can be run either manually or automatically, such as part of the login script.
Bootstrap of a wireless client onto the protected organization's wireless network A wireless client computer that is not a member of the domain cannot connect to the organization's protected wireless network. Additionally, a computer cannot join the domain until it has successfully connected to the organization's secure wireless network. A command line script provides a method to connect to the organization's secure wireless network to join the domain.

For information about joining a Windows Vista wireless client to a domain, see Joining a Windows Vista Wireless Client to a Domain.

In Windows Server 2008 and Windows Vista, you can use Netsh commands in the netsh wlan context to do the following:

Save all wireless client settings in a named profile including general settings (the types of wireless networks to access), 802.11 settings (SSID, type of authentication, type of data encryption), and 802.1X authentication settings (EAP types and their configuration).
Specify Single Sign On settings for a wireless profile.
Enable or disable FIPS 140-2 certified mode.
Specify the list of allowed and denied wireless network names.
Specify the order of preferred wireless networks.
Display a wireless client’s configuration.
Remove the wireless configuration from a wireless client.
Migrate wireless configuration settings between wireless clients.

For more information, see Netsh Commands for Wireless Local Area Network (wlan).

Network Awareness and Network Profiles

Many applications are not network aware, resulting in customer confusion and developer overhead. For example, an application cannot automatically adjust its behavior based on the currently attached network and conditions. Users might to have to reconfigure application settings depending on the network to which they are attached (their employer's private network, the user's home network, the Internet). To remove the configuration burden, application developers can use low-level Windows APIs, data constructs, and perhaps even probing the network themselves to determine the current network and adjust their application's behavior accordingly.

To provide an operating system infrastructure to allow application developers to more easily reconfigure application behavior based on the currently attached network, the Network Awareness APIs in Windows Server 2008 and Windows Vista makes network information available to applications and enables them to easily and effectively adapt to these changing environments. The Network Awareness APIs allow applications to obtain up-to-date network information and location change notification.

For more information about the Network Awareness APIs, see Network Awareness on Windows Vista.

Next Generation TCP/IP Stack Enhancements for Wireless Environments

As described in the "Enhancements for High-loss Environments" section of this article, the Next Generation TCP/IP stack includes support for new TCP algorithms that optimize throughput by recovering from single and multiple packet losses and detecting spurious retransmissions, which improves performance in wireless network environments.

Single Sign On

Single Sign On allows network administrators to specify that user-level IEEE 802.1X authentication occurs before the user logon process. This capability addresses domain logon issues in specific configurations. Single Sign On also simply and seamlessly integrates wireless authentication with the Windows logon experience.

Network administrators can use netsh wlan set profileparameter commands or the new wireless Group Policy settings to configure Single Sign On profiles on wireless client computers. Configuring Single Sign On to perform user-level 802.1X authentication before the user logon process prevents problems with Group Policy updates, execution of login scripts, virtual LAN switching, and wireless client domain joins. For more information, see Wireless Single Sign-On.

For an example of using a Single Sign On profile to join a Windows Vista wireless client to a domain, see Joining a Windows Vista Wireless Client to a Domain.

IEEE 802.1X-based Wired Connectivity Enhancements

In Windows Server 2003 and Windows XP, there is limited support for deployment of 802.1X authentication settings for wired connections to an authenticating switch. Windows Server 2008 and Windows Vista include the following enhancements for easier deployment of 802.1X-authenticated wired connections:

Group Policy support for wired 802.1X settings
Command-line interface for configuring wired 802.1X settings
Integration with Network Access Protection when using 802.1X authentication
EAPHost infrastructure
Single Sign On
Change in 802.1X service state

Group Policy Support for Wired 802.1X Settings

For environments that use Active Directory and Group Policy, Windows Server 2008, Windows Vista, and Windows XP Service Pack 3 include Group Policy support for 802.1X authentication settings for wired connections under Computer Configuration/Windows Settings/Security Settings/Wired Network (IEEE 802.3) Policies.

Command-Line Interface for Configuring Wired 802.1X Settings

For environments that do not use Active Directory or Group Policy or for domain join scenarios, Windows Server 2008 and Windows Vista also support a command line interface for configuring 802.1X authentication settings for wired connections. Using commands in the netsh lan context, you can do the following:

Save all wired client settings in a named profile including 802.1X authentication settings (EAP types and their configuration)
Specify Single Sign On settings for a wired profile.
Display a wired client’s configuration
Remove the wired configuration from a wired client
Import a wired profile to migrate wired configuration settings between wired clients

For more information, see Netsh Commands for Wireless Local Area Network (lan).

For information about using wired profiles to join a Windows Vista wired client to a domain, see Joining a Windows Vista Wired Client to a Domain.

Integration with Network Access Protection when using 802.1X Authentication

IEEE 802.1X-authenticated wired connections can leverage the Network Access Protection platform to prevent wired clients that do not comply with system health requirements from gaining unlimited access to a private network. For more information about the Network Access Protection platform, see "Network Access Protection" in this article.

EAPHost Infrastructure

For easier development of EAP authentication methods for IEEE 802.1X-authenticated wired connections, Windows Server 2008 and Windows Vista supports the new EAPHost infrastructure. For more information, see "EAPHost Architecture" in this article.

Single Sign On

Windows Server 2008 and Windows Vista with Service Pack 1 support Single Sign On for wired connections. Network administrators can use netsh lan set profileparameter commands or the new wireless Group Policy settings to configure Single Sign On profiles on wired client computers. Configuring Single Sign On to perform user-level 802.1X authentication before the user logon process prevents problems with Group Policy updates, execution of login scripts, virtual LAN switching, and wireless client domain joins.

For an example of using a Single Sign On profile to join a Windows Vista wireless client to a domain, see Joining a Windows Vista Wireless Client to a Domain.

Change in 802.1X Service State

In Windows XP and Windows Server 2003, the 802.1X service for wired connections was enabled by default but was placed in a passive listening mode, in which the computer did not attempt to contact the switch. The 802.1X service for wired connections in Windows Vista, known as the Wired AutoConfig service, has the startup type set to Manual by default, but when it is started operates in an active listening mode, in which the computer attempts to contact the switch.

To obtain an Authentication tab for the properties of a LAN connection to configure 802.1X settings, you must first start the Wired AutoConfig service.

For an individual Windows Vista or Windows Server 2008-based wired client, you can use the Services snap-in to start the Wired AutoConfig service and configure it for automatic startup. For a Group Policy object of an Active Directory domain, configure the Computer Configuration/Windows Settings/Security Settings/System Services/Wired AutoConfig setting for automatic startup.

For more information about how to deploy Windows-based wireless and wired clients, see the Windows Server 2008 Networking and Network Access Protection (NAP) book from Microsoft Press.

Network Infrastructure

Windows Server 2008 and Windows Vista include changes to the following components and services of network infrastructure:

Network Access Protection
Network Policy Server
New EAPHost architecture
Remote access and VPN connection enhancements
DHCP enhancements

Network Access Protection

Network Access Protection (NAP) in Windows Server 2008, Windows Vista, and Windows XP with Service Pack 3 is a new platform and solution that controls access to network resources based on a client computer�s identity and compliance with corporate governance policy. NAP allows network administrators to define granular levels of network access based on who a client is, the groups to which the client belongs, and the degree to which that client is compliant with corporate governance policy. If a client is not compliant, NAP provides a mechanism to automatically bring the client back into compliance and then dynamically increase its level of network access.

Administrators can use a combination of policy validation and network access limitation components to control network access or communication. Administrators can also choose to temporarily limit the access of computers that do not meet requirements to a restricted network. Depending on the configuration chosen, the restricted network might contain resources required to update noncompliant computers so that they then meet the health requirements for unlimited network access and normal communication. NAP includes an API set for developers and vendors to create complete solutions for health policy validation, network access limitation, automatic remediation, and ongoing health policy compliance.

NAP Enforcement Methods

Windows Server 2008, Windows Vista, and Windows XP with Service Pack 3 include the following NAP enforcement methods:

IPsec With IPsec enforcement, you can confine the communication on your network to compliant computers. Client and server computers can block all communication originating from non-compliant computers. IPsec enforcement confines communication to compliant computers after they have successfully connected and obtained a valid IP address configuration. IPsec enforcement is the strongest form of limited network access in NAP.
IEEE 802.1X With 802.1X enforcement, a Network Policy Server (NPS) instructs an 802.1X-based access point (an Ethernet switch or a wireless AP) to place a restricted access profile on the 802.1X client until it performs a set of health remediation functions. A restricted access profile can consist of a set of IP packet filters or a virtual LAN identifier to confine the traffic of an 802.1X client. 802.1X enforcement provides strong limited network access for all computers accessing the network through an 802.1X connection. For more information about NPS, see "Network Policy Server" in this article.
VPN With VPN enforcement, VPN servers can enforce health policy requirements any time a computer attempts to make a VPN connection to the network. VPN enforcement provides strong limited network access for all computers accessing the network through a VPN connection. VPN enforcement with NAP is different than Network Access Quarantine Control, a feature in Windows Server 2003.
DHCP With DHCP enforcement, DHCP servers can enforce health policy requirements any time a computer attempts to lease or renew an IP address configuration on the network. DHCP enforcement relies on a limited access IPv4 address configuration and IPv4 routing table entries for NAP enforcement.
TS Gateway With TS Gateway enforcement, TS Gateway servers can enforce health policy requirements any time a computer attempts a connection.

Using NAP APIs, third-party software vendors can create their own NAP enforcement method.

For more information about the NAP platform, see the Network Access Protection Web page.

For more information about how to deploy NAP, see the Windows Server 2008 Networking and Network Access Protection (NAP) book from Microsoft Press.

Network Policy Server

Network Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy in Windows Server 2008. NPS replaces the Internet Authentication Service (IAS) in Windows Server 2003. NPS performs all of the functions of IAS in Windows Server 2003 for VPN and 802.1X-based wireless and wired connections and performs health evaluation and the granting of either unlimited or limited access for NAP clients.

NPS also supports sending RADIUS traffic over IPv6, as specified in RFC 3162.

For more information, see Network Policy Server.

New EAPHost Architecture

Windows Server 2008 and Windows Vista include EAPHost, a new architecture for Extensible Authentication Protocol (EAP) authentication methods and EAP-based supplicants. EAPHost provides the following features that are not supported by the EAP implementation in Windows Server 2003 and Windows XP:

Support for additional EAP methods EAPHost supports other popular EAP methods.
Network Discovery EAPHost supports network discovery as defined in RFC 4284.
RFC 3748 compliance EAPHost conforms to the EAP State Machine and addresses a number of security vulnerabilities that have been specified in RFC 3748. Additionally, EAPHost will support additional capabilities such as Expanded EAP Types (including vendor-specific EAP Methods).
EAP method coexistence EAPHost allows multiple implementations of the same EAP method to coexist simultaneously. For example, the Microsoft version of PEAP and the Cisco Systems, Inc. version of PEAP can be installed and selected.
Modular supplicant architecture In addition to supporting modular EAP methods, EAPHost also supports a modular supplicant architecture in which new supplicants can be easily added without having to replace the entire EAP infrastructure in Windows.

For EAP method vendors, EAPHost provides support for EAP methods already developed for Windows Server 2003 and Windows XP and an easier method of developing new EAP methods for and Windows Server 2008 and Windows Vista. Certified EAP methods can be distributed with Windows Update. EAPHost also allows better classification of EAP types so that the built-in 802.1X and PPP-based Windows supplicants can use them.

For supplicant method vendors, EAPHost provides support for modular and pluggable supplicants for new link layers. Because EAPHost is integrated with NAP, new supplicants do not have to be NAP-aware. In order to participate in NAP, new supplicants just need to register a connection identifier and a callback function that informs the supplicant to reauthenticate.

For network administrators, EAPHost provides availability of new EAP methods and a more robust and flexible infrastructure for 802.1X-authenticated connections.

For more information about EAPHost, see EAPHost in Windows.

Remote Access and VPN Connection Enhancements

Remote access and VPN connections in Windows Server 2008 include the following enhancements:

Secure Socket Tunneling Protocol (SSTP) SSTP is a new VPN protocol that uses an HTTP over SSL session between a remote access VPN client and VPN server to exchange encapsulated IPv4 or IPv6 packets. SSTP-based remote access VPN connections use TCP port 443 and can work seamlessly across most firewalls, NATs, and proxy servers. On the VPN client, SSTP can be configured manually and with Connection Manager. On the VPN server, you must install a computer certificate with the Server Authentication or All-Purpose Enhanced Key Usage (EKU) property. VPN clients running Windows Vista with Service Pack 1 or Windows Server 2008 support SSTP. For more information, see The Secure Socket Tunneling Protocol and the Routing and Remote Access blog.
VPN enforcement for remote access VPN connections The built-in VPN client and Routing and Remote Access add components to support VPN enforcement in the NAP platform. For more information, see "Network Access Protection" in this article.
IPv6 support The built-in remote access client and Routing and Remote Access now support IPv6 over the Point-to-Point Protocol (PPP), as defined in RFC 2472. Native IPv6 traffic can now be sent over PPP-based connections. For example, this allows you to connect with an IPv6-based Internet service provider (ISP) through dial-up or PPP over Ethernet (PPPoE)-based connections (used for broadband Internet access). The built-in remote access client and Routing and Remote Access also support IPv6-based Layer Two Tunneling Protocol with IPsec (L2TP/IPsec) VPN connections. Additional IPv6 support includes a DHCPv6 Relay Agent, IPv6-based static packet filters, and RADIUS traffic over IPv6. For more information, see IPv6 Traffic over VPN Connections.
A revised connection creation wizard This new wizard provides a simplified way to configure dial-up, broadband Internet, and VPN connections.
Updated Winlogin support Allows a third-party access provider to plug in their connections to automatically create a remote access connection during the user login.
Multiple-locale support for the Connection Manager Administration Kit Allows Connection Manager profiles to be created on a server of any locale for installation on a client of any other locale running Windows Vista or Windows XP, which simplifies Connection Manager Administration Kit (CMAK)-based client management.
Connection Manager clients support DNS dynamic update Connection Manager clients now support the registering of DNS names and IP addresses using DNS dynamic update.
New cryptographic support L2TP/IPsec-based VPN connections now support the Advanced Encryption Standard (AES) with 128 and 256-bit keys. Support for weaker cryptographic algorithms—40 and 56-bit Microsoft Point-to-Point Encryption (MPPE) for PPTP and DES with Message Digest 5 (MD5) for L2TP/IPSec—has been disabled by default. To enable 40 and 56-bit MPPE for PPTP-based connections, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\AllowPPTPWeakCrypto registry value (DWORD) to 1, and then restart the computer. To enable DES with MD5 for L2TP/IPSec connections, set the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\AllowL2TPWeakCrypto registry value (DWORD) to 1, and then restart the computer.
Changes to authentication protocols PPP-based connections no longer support the SPAP, EAP-MD5-CHAP, and MS-CHAP authentication protocols. Remote access PPP-based connections now support the use of Protected EAP (PEAP) with PEAP-MS-CHAP v2 and PEAP-TLS.
Additional certificate checking for L2TP/IPsec-based VPN connections The VPN client computer by default performs additional analysis of the fields of the VPN server’s computer certificate to help detect man-in-the-middle attacks. The analysis includes verifying that the Subject Alternative Name or the Subject fields of the VPN server’s computer certificate are the same as the name or IP address of the VPN server as specified on the General tab for the properties of the VPN connection in the Network Connections folder and verifying that the certificate contains the Server Authentication Enhanced Key Usage (EKU). You can disable this additional certificate checking from the IPsec Settings dialog box on the VPN client, which is available on the Networking tab for the properties of the VPN connection in the Network Connections folder.
Support for Network Diagnostics Framework Client-based connections support basic diagnostics capabilities with the Network Diagnostics Framework.

For more information about the Network Diagnostics Framework, see Network Diagnostics Framework in Windows Vista and Network Diagnostics Technologies in Windows Vista.

DHCP Enhancements

The DHCP Server and DHCP Client services include the following enhancements:

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) support DHCPv6, defined in RFC 3315, provides stateful address configuration for IPv6 hosts on a native IPv6 network. The DHCP Client service in Windows Vista and Windows Server 2008 supports DHCPv6. A computer running Windows Vista or Windows Server 2008 can perform both DHCPv6 stateful and stateless configuration on a native IPv6 network. The DHCP Server service in Windows Server 2008 supports DHCPv6 stateful (both addresses and configuration settings) and stateless (configuration settings only) operation.

For more information about DHCPv6, see The DHCPv6 Protocol.
Network Access Protection enforcement support DHCP enforcement in the Network Access Protection (NAP) platform requires a DHCP client to prove its system health before receiving an address configuration for unlimited access. For more information, see "Network Access Protection" in this article.

For more information, see the Microsoft Windows DHCP Team Blog.

Removal of Technologies

Support for the following technologies has been removed from Windows Server 2008 and Windows Vista:

Resource Reservation Protocol (RSVP)
Bandwidth Allocation Protocol (BAP)
X.25
Serial Line Interface Protocol (SLIP)

SLIP-based connections will automatically be updated to PPP-based connections.
Asynchronous Transfer Mode (ATM)
IP over IEEE 1394
NWLink IPX/SPX/NetBIOS Compatible Transport Protocol
Services for Macintosh (SFM)
Open Shortest Path First (OSPF) routing protocol component in Routing and Remote Access
Basic Firewall in Routing and Remote Access (replaced with Windows Firewall)
Static IP filter APIs for Routing and Remote Access (replaced with Windows Filtering Platform APIs)
The SPAP, EAP-MD5-CHAP, and MS-CHAP (also known as MS-CHAP v1) authentication protocols for PPP-based connections

Summary

Windows Server 2008 and Windows Vista include many enhancements to improve connectivity, performance, and ease of configuration for protocols and core networking components; improve security, ease of use, and deployment for wireless and 802.1X-authenticated wired connections; and improve protection for private networks by requiring connecting computers to be compliant with system health policies.

See the following resources for additional information:

Share via

New Networking Features in Windows Server 2008 and Windows Vista

On This Page

Abstract

Introduction

Protocols and Core Networking Components

Next Generation TCP/IP Stack

Receive Window Auto Tuning

Compound TCP

ECN Support

Enhancements for High-loss Environments

Neighbor Unreachability Detection for IPv4

Fail-back Support for Default Gateway Changes

Changes in PMTU Black Hole Router Detection

Network Diagnostics Framework Support

ESTATS Support

New Packet Filtering Model with Windows Filtering Platform

IPv6 Enhancements

TCP Chimney Offload

Domain Name System

Quality of Service

Policy-based QoS for Enterprise Networks

qWave and QoS2 APIs for Home Networks

Server Message Block 2.0

Computer Browser Service

Http.sys Enhancements

HTTP Server API 2.0

Server-side Authentication

Logging

IDNA Support

ETW Tracing for HTTP Events

Netsh commands for Http.sys

Performance Counters for Http.sys

WinINet Enhancements

Support for IPv6 Literals and Scope IDs

Support for HTTP Decompression

Support for Internationalized Domain Names

Support for ETW Tracing

IPv6 support in Web Proxy Auto-Discovery scripts

WinHTTP Enhancements

Support for Data Uploads Larger than 4 Gigabytes

Support for Chunked Transfer Encoding

Support for Issuer List Retrieval for Secure Sockets Layer-based Client Authentication

Support for Optional Client Certificate Requests

Support for 4-tuple Connection Information Indication

New Error Codes for SSL Client Authentication

IPv6 Support in WPAD Scripts

Windows Sockets Enhancements

New Winsock APIs

ETW Tracing for Winsock Events

Layered Service Provider Enhancements

New Kernel Mode Sockets API

NDIS 6.0

New Offload Support

Support for Lightweight Filter Drivers

Receive-Side Scaling

NDIS 6.1

Header-data Split Services

Direct OID Request Interface

IPsec Task Offload Version 2

NETDMA Updates

Network Awareness

Windows Peer-to-Peer Networking Enhancements

Windows Firewall

IPsec Improvements

Integrated Firewall and IPsec Configuration

Simplified IPsec Policy Configuration

Client-to-DC IPsec Protection

Improved Load Balancing and Clustering Server Support

Improved IPsec Authentication

New Cryptographic Support

Integration with Network Access Protection

Additional Configuration Options for Protected Communication

Integrated IPv4 and IPv6 Support

Extended Events and Performance Monitor Counters

Network Diagnostics Framework Support

Wireless and 802.1X-based Wired Connections

IEEE 802.11 Wireless Changes and Enhancements

Native Wi-Fi Architecture

User Interface Improvements for Wireless Connections