Export (0) Print
Expand All
11 out of 20 rated this helpful - Rate this topic

Connecting Clients to Windows Networks

Published: November 03, 2005

Microsoft Windows XP Professional can be a member of a variety of network configurations, from a small home network consisting of two computers to a large enterprise network that includes thousands of computers worldwide. This chapter describes the network environments in which Windows XP Professional can be used.

For information on how to obtain the Windows XP Professional Resource Kit in its entirety, please see http://www.microsoft.com/mspress/books/6795.asp.

Bb457117.3squares(en-us,TechNet.10).gif
On This Page

Related Information
Microsoft Networking Overview
Microsoft Network Environments
Account Authentication
TCP/IP and Other Network Protocols
Locating Resources by Publishing Objects
Group Policy and System Policy Settings
Joining the Network Environment
Confirming Domain and Workgroup Membership
Troubleshooting Microsoft Networking
Additional Resources

Related Information

  • For more information about account authentication in Microsoft Windows 2000 or Microsoft Windows Server™ 2003 domains, see Chapter 17, “Managing Authorization and Access Control.”

  • For more information about deploying Windows Server 2003 client network services, see the Deploying Network Services book of the Microsoft Windows Server™ 2003 Deployment Kit.

Microsoft Networking Overview

The networking capabilities of Windows XP Professional include refinements of features introduced in Windows 2000. These refinements allow you to maintain a scalable networking presence in a variety of environments.

New in Microsoft Networking

The networking innovations, first appearing in Windows 2000 Professional and further refined in Windows XP Professional can be categorized into three areas: directory services, account authentication, and policy handling.

Directory Service

Windows XP Professional, Windows 2000, and Windows Server 2003 use the Active Directory directory service as its domain-based directory service. A directory service provides information about objects in a network environment, including user and computer accounts, and shared resources such as printers and other directories. It provides a consistent way to name, describe, locate, access, manage, and secure information about each of these resources. Active Directory, the directory service used in Windows 2000 and Windows Server 2003 domains, organizes information in a hierarchical, object-based fashion.

Account Authentication

In Windows 2000 and Windows Server 2003 domains, Account Authentication is performed using a protocol called Negotiate. Negotiate, in turn, uses the Kerberos V5 authentication protocol to authenticate any Windows XP–based computers, Windows 2000–based computers, and Windows Server 2003–based computers. The Kerberos V5 authentication protocol, as defined in RFC 1510, is an industry-supported distributed security protocol based on Internet standard security.

Negotiate uses the NTLM protocol where local authentication is needed and to authenticate any computer based on versions of Windows prior to Windows 2000. NTLM is also used as the account authentication method in Microsoft Windows NT domains and for authentication to Microsoft Windows NT version 4.0–based domain controllers.

For more information about the Kerberos V5 protocol and Windows XP Professional, see “Account Authentication” later in this chapter.

Policy Handling

Windows XP Professional supports the use of both System Policy and Group Policy to specify user and computer configurations. System Policy, introduced in Windows NT 4.0, is more limited than Group Policy, introduced in Windows 2000. In a Windows NT domain, domain administrators use System Policy to manage the user’s work environment and to enforce system configuration settings. In a Windows 2000 or Windows Server 2003 domain, Group Policy settings are your primary method for enabling centralized change and configuration management. A domain administrator can create Group Policy settings at a Windows 2000–based or Windows Server 2003–based domain controller to create a specific system configuration for a particular group of users, computers, or both. You can use Group Policy to do the following:

  • Automatically install applications assigned to users or computers or both, and provide location independence for roaming users.

  • Permit desktop customization and lockdown.

  • Configure security policies.

For more information about Group Policy, see “Group Policy and System Policy Settings” later in this chapter.

Fundamental Configuration Tasks

To allow your Windows XP Professional–based computer to take its place in a Microsoft network, you must first perform these fundamental tasks: assess the current network environment, install and configure your transport protocol, connect your computer to the appropriate network environment, verify that that you are logged on, and then troubleshoot any problem that might have occurred in the process.

Determining the Current Networking Environment

Before adding a Windows XP Professional–based computer to a network, you must determine whether you want to add the computer to a Windows 2000 or Windows Server 2003 domain, to a Windows NT domain, to a workgroup of computers running Microsoft Windows 95 and Microsoft Windows 98, or to a non-Windows–based environment such as Novell Netware. Typically, the network environment determines the authentication method you choose to access the network, the means you choose to enforce desktop and security rules (Group Policy or System Policy), and the method you use to handle logon scripts.

Installing and Configuring TCP/IP or Another Network Protocol

Before you can add a Windows XP Professional–based computer to an existing network, you must establish client connectivity with the network. Transmission Control Protocol/Internet Protocol (TCP/IP) has become the universal network protocol suite because of its scalability and its role as an Internet standard.

For all recommended tasks, it is assumed that the Windows XP Professional–based computer on the Microsoft network runs IP protocol as the default network protocol. Windows XP Professional supports NetBIOS over TCP/IP (NetBT), Windows Sockets (WinSock), and the Internetwork Packet Exchange/Sequenced Packet Exchange protocol (IPX/SPX). NetBT and WinSock are installed by default. IPX/SPX can be added if needed for connectivity to legacy Novell networks.

For more information about the Windows XP Professional implementation of TCP/IP and IP configuration, see “Configuring TCP/IP” on the companion CD.

For more information about network protocol installation and configuration, see “TCP/IP and Other Network Protocols” later in this chapter.

Connecting to the Right Network Environment

A user who has appropriate permissions can do the following:

  • Join a domain or workgroup. No rights are required for joining a workgroup.

  • Create the computer account in a domain during Windows XP Professional installation. For workgroups, no permissions are required.

  • Use the Network Identification Wizard to make the Windows XP Professional–based computer a member of a specified domain or workgroup.

  • Manually add a computer to a network by specifying the appropriate domain or workgroup on the Computer Name tab of the System Properties dialog box.

For more information about joining a domain or workgroup, see “Microsoft Network Environments” later in this chapter.

Verifying a Successful Client Logon Attempt

To verify that a Windows XP Professional–based client is added to the network, attempt to log on to the domain where you added the computer; or if you added the computer to a workgroup, log on locally. If you are in a domain environment, make sure that logon scripts function as expected and that no conflicts occur between the following:

  • Local Group Policy and Windows NT System Policy

    – or –

  • Local Group Policy and Windows 2000 or Windows Server 2003 domain Group Policy settings

    Note Domain Group Policy always overrides Local Group Policy.

For more information about confirming a Windows XP Professional–based computer’s membership in a workgroup or domain, see “Confirming Domain and Workgroup Membership” later in this chapter.

Troubleshooting a Failed Logon Attempt

If a user cannot log on to a workgroup by using a local account or to a domain by using an account on a domain controller, troubleshoot the logon failure to determine its cause and solution.

For examples of logon-related problems and how to solve them, see “Troubleshooting Logon Problems” later in this chapter.

Microsoft Network Environments

There are two distinct kinds of Microsoft network environments—the peer-to-peer or workgroup (non-server-based) and the domain (server-based). Peer-to-peer networking is geared to small groups of users sharing resources on a one-to-one basis. Networks with Novell 3.x servers or stand-alone Windows NT-based, Windows 2000–based, or Windows Server 2003–based servers fall into the peer-to-peer group The domain model is enterprise networks built around a central directory database.

Peer-to-Peer Network Environment

A peer-to-peer network or workgroup is a single-subnet network that is used as a convenient way to connect a small number of users to share resources. Peer-to-peer clients have the identical level of authority on a network, which eliminates the need for domain controllers. User authentication is decentralized by the use of the local account database located on each client. A user must have a user account on each computer to gain access. Figure 23-1 shows an example of a peer-to-peer network.

Figure 23-1 Peer-to-peer network

Figure 23-1 Peer-to-peer network

Peer-to-peer networks are ideal for small office/home office (SOHO) configurations that have from two to 10 computers. They can also be helpful for users who work with more than one computer and share resources (such as files, applications, or printers) with other users. For more information about SOHO local connections, see Chapter 25, “Connecting Remote Offices.”

Windows XP Professional is compatible with all Microsoft products that use the Server Message Block (SMB) protocol. SMB functionality includes support for peer-to-peer networking with all other Microsoft networking products.

A Windows XP Professional–based computer in a peer-to-peer environment performs account authentication locally. Because the Kerberos V5 protocol is used only for domain authentication, Windows XP Professional uses NTLM to authenticate users in the local account database. For more information about account authentication, see “Account Authentication” later in this chapter.

Windows-based computers communicate with each other on peer-to-peer networks by using a common protocol. As a result of the dominance of the Internet, TCP/IP has become the protocol of choice for peer-to-peer networks. For more information about configuring protocols for peer-to-peer networking, see “TCP/IP and Other Network Protocols” later in this chapter.

Windows Domain Environment

A domain is a logical grouping of networked computers that share a central directory database that contains user account and security information for resources within the domain.

In a domain, the directory database is stored on computers that are configured as domain controllers. A domain controller manages all security-related aspects of interactions between users and domains. Security and administration are centralized. Figure 23-2 illustrates a domain configuration.

In a domain that has more than one domain controller, the domain accounts database is replicated between domain controllers within the domain for increased scalability and fault tolerance. If a domain controller becomes unavailable, directory information is still available from the other domain controllers. For more information about Windows 2000 Server domain controller placement in a Windows 2000 domain, see “Designing the Active Directory Structure” in the Deployment Planning Guide of the Microsoft Windows 2000 Server Resource Kit. For more information about Windows Server 2003 domain controller placement, see the Microsoft Windows Server 2003 Deployment Kit.

Windows 2000 and Windows Server 2003 domains improve on Windows NT domains. In Windows 2000 and Windows Server 2003 domains, all domain controllers can receive updates to the directory database. In Windows NT domains, the single-master model allows only one domain controller to be updated, which then replicates the changes to the other domain controllers. In Windows 2000 and Windows Server 2003 domains, the directory is distributed and it uses a hierarchical namespace based on the Domain Name System (DNS). In Windows NT domains, the directory is centralized and a flat namespace is used.

Windows XP Professional is fully compatible with Windows NT, Windows 2000, and Windows Server 2003 domains. For more information about whether to migrate an existing Windows NT domain to Windows 2000, see “Determining Domain Migration Strategies” in the Deployment Planning Guide.

Figure 23-2 Domain-based network

Figure 23-2 Domain-based network
Active Directory

Active Directory is the directory service included with Windows 2000 Server and Windows Server 2003. The service provides a place to store information about network-based entities (such as applications, files, printers, and users) and the means to locate and manage resources. Active Directory provides a consistent way to name, describe, locate, access, manage, and secure information about network resources.

Active Directory is available only in domains with Windows 2000–based or Windows Server 2003–based domain controllers. Active Directory presents domain information in a hierarchical, object-based format and protects network data from unauthorized access. It replicates directory data across a network so that data remains available if one domain controller fails.

Active Directory clients

Active Directory supports clients running Windows XP Professional, Windows 2000, Windows NT, and Windows 9x. These computers can have access to shared resources within a domain to the extent allowed by the security on the resources. However, a computer that runs Windows 98, Windows 95, or Windows NT 4.0, or must have the Active Directory client software installed to search for information in Active Directory about the shared resources.

Active Directory objects

In Active Directory, network resources such as users, groups, and computers are represented as objects. An object is a unique namespace within the directory with object-specific attributes that represents something concrete, such as a user, a printer, or an application. An Active Directory object is defined by a set of rules, or schema. When you create an Active Directory object, Active Directory generates values for some of the object’s attributes, and you provide other values. For example, when creating a new user account, Active Directory automatically assigns a globally unique identifier (GUID) but requires the administrator to provide values, at least for the minimally required attributes such as the user name and the logon identifier.

Organizational units

An Active Directory domain can contain an organizational unit hierarchy. Organizational units are containers to which you can delegate administrative authority over sets of objects. Organizational units can also be used to apply policies to users and computers. An organizational unit can contain Active Directory objects—such as users, groups, computers, printers, and shared folders—as well as other organizational units. Each domain can have its own hierarchy of organizational units that implements domain-specific administration.

An Active Directory organizational unit can represent a group of users, such as the marketing department, or a collection of related objects, such as printers. You can create a tree structure by nesting organizational units, objects, and containers in the same way that a Windows file system uses folders and files. Storing objects in an organizational unit allows an administrator to use Group Policy to apply restrictions to all users or all computers within that unit. Objects can still be stored in containers other than organizational units when such container-level policies are not required.

Global catalog

Windows 2000 Server introduced the global catalog, which provides forest-wide Active Directory searches. Ordinarily, a domain controller stores objects for only one domain. A global catalog server is a special domain controller that stores complete objects for one domain and partial objects (every object but only a limited set of each object’s attributes) for every other domain in the forest. The global catalog is also required for user logon. There can be multiple global catalog servers in a forest.

The global catalog makes directory structures within an enterprise transparent to end users seeking information. In an enterprise that contains many domains, the global catalog allows clients to easily perform searches across all domains without having to search each domain separately.

Administration tools

Administrators who have the required permissions can use the Windows Server 2003 Administration Tools Pack to remotely create Active Directory objects and perform other administration tasks from a Windows XP Professional client that meets the following criteria:

  • The Windows Server 2003 Administration Tools Pack has been installed locally.

  • The Windows XP Professional Client has been updated to at least Service Pack 1 or has the software update described in Knowledge Base article 329357 applied.

  • The Windows XP Professional client is a 32-bit client. The tools support 32-bit and 64bit server operating systems. However, the Windows Server 2003 Administration Tools Pack does not install on 64-bit systems.

    Warning You must have administrative permissions on the local computer to install or run Windows Server 2003 Administration Tools Pack. For security reasons, Windows Server 2003 Administration Tools Pack should be uninstalled if the Windows XP Professional computer is to be used by a non-administrator. In addition, you should be aware of specific security requirements for each tool. Note also that the default configuration for Windows Firewall on computers running Windows XP Service Pack 2 prevents certain Windows 2000 and Windows Server 2003 administrative tools from remotely managing these computers. (See article 840634, “You receive an ‘Access denied’ or ‘The network path was not found’ error message when you try to remotely manage a computer that is running Windows XP Service Pack 2,” in the Microsoft Knowledge Base at http://support.microsoft.com for more information.

The Administration Tools Pack is available as adminpak.msi on the Windows Server 2003 family operating system CDs or from the Microsoft Download Center at http://www.microsoft.com/downloads (by searching for “administration tools”). For more information about installing the Administration Tools Pack, see the Windows Server 2003 Help and Support Center.

Active Directory security

A security identifier (SID) is a unique number created by the security subsystem of the Windows XP Professional, Windows 2000, Windows Server 2003, or Windows NT operating system, and it’s assigned to security principal objects such as user, group, and computer accounts. Every account on a network is issued a unique SID when that account is first created. For example, when you join a computer to a Windows 2000 or Windows Server 2003 domain, a SID is created for that computer account. Internal processes in the Windows XP Professional, Windows 2000, Windows Server 2003, and Windows NT operating systems refer to an account by its SID instead of its user name or group name.

Each object is protected by an access control list (ACL) that contains access control entries (ACEs) that specify the users or groups who are permitted access to that object and what these access rights are. An ACE is created for an object by assigning permissions. Each ACE contains the SID of a user or group who is allowed (or explicitly denied) access to that object. An ACE also defines the level of access allowed. For example, a user might have read-only access to some objects, read-and-write access to other objects, and no access to the remaining objects.

If you create an account, delete it, and then create a new account that has the same user name, the new account does not have the rights or permissions previously granted to the old account because the accounts have different SIDs. For more information about planning and implementing access permissions, see Chapter 17, “Managing Authorization and Access Control.”

DNS and Active Directory domains

Domain Name System (DNS) is required for support of Active Directory for the following reasons:

  • Active Directory domains are named with DNS names.

  • Active Directory uses DNS as its location service, to enable clients to locate domain controllers.

Active Directory can also benefit DNS. DNS zone information can be copied to Active Directory domain controllers to enhance zone replication and provide security.

To implement Active Directory, one or more DNS servers must be available to the Windows 2000 or Windows Server 2003 domain, and the DNS client service must be configured at each member computer. This can be done automatically through DHCP.

Active Directory domains are named with DNS names. The DNS hierarchical naming structure is an inverted tree structure, or a single-root domain, under which can be parent and child domains. For example, a Windows 2000 domain name such as seattle.noam.reskit.com identifies a specific computer in a domain named noam, which is a child domain of the domain reskit. The com domain is a top-level domain on the Internet by which reskit.com and any of its child domains might be located.

Each computer in a DNS domain is identified by a unique, fully qualified domain name (FQDN). The FQDN of a computer located in the domain noam.reskit.com is computername.noam.reskit.com. Figure 23-3 illustrates a Windows 2000 domain that uses the DNS hierarchical naming structure.

Figure 23-3 Windows 2000 domain hierarchy

Figure 23-3 Windows 2000 domain hierarchy

Every Windows 2000 (or Windows Server 2003) domain and every Windows XP Professional–based computer has a DNS name. Thus, domains and computers are represented both as Active Directory objects and as DNS nodes. (A node in the DNS hierarchy represents a domain or a computer.) When you add a computer to a Windows 2000 or Windows Server 2003 domain, you need to specify the FQDN, consisting of the computer name and domain name. This information is provided when you add the computer account to the domain during or after initial Windows XP Professional Setup. For more information about adding Windows XP Professional–based clients to a Windows 2000 or Windows Server 2003 domain, see “Joining the Network Environment” later in this chapter.

Although the two namespaces can share an identical domain structure, it is important to understand that they are not the same namespace. Each stores different data and therefore manages different objects. DNS stores zones and resource records, and Active Directory stores domains and domain objects.

Note Not every client needs to be visible to the Internet and not every company that wants to implement Active Directory needs to be on the Internet.

For more information about configuring the DNS client, see Chapter 24,“Configuring IP Addressing and Name Resolution.” For more conceptual information about DNS and the Windows 2000 DNS service, see “Introduction to DNS” and “Windows 2000 DNS” in the Microsoft Windows 2000 Server TCP/IP Core Networking Guide.

Windows NT 4.0 Compatibility

In addition to being able to use Active Directory domain controllers, Windows XP Professional–based computers can access domain controllers used in Windows NT 4.0 domains. Like Active Directory, the Windows NT 4.0 account database includes the following two types of accounts in its domain environment:

  • Computer accounts.

    Windows NT 4.0–based, Windows 2000–based, and Windows XP Professional–based computers that can access the domain.

  • User accounts.

    Users who can access the domain.

Shared resources defined within the domain are associated with accounts by using ACEs, which determine the permissions to domain resources such as shared files and printers. A Windows XP Professional–based computer can access objects stored in a Windows NT account database without modification.

Typically, a Windows XP Professional–based computer uses Kerberos V5 authentication to find a Windows 2000–based or Windows Server 2003–based domain controller. A Windows XP Professional–based computer that is authenticating against a Windows NT 4.0 domain controller uses NTLM as its security protocol. For information about Kerberos V5 authentication, see “Account Authentication” later in this chapter.

Account Authentication

Typically, a computer and its stored information must be protected from unauthorized access. Windows XP Professional secures the computer by using account authentication, which can prevent a user from accessing a computer or domain. Account authentication is the process of confirming the identity of a user by verifying a user’s login name and password or smartcard information against data stored in an account database either locally or on a domain controller. After authentication identifies the user, the user is granted access to a specific set of network resources based on permissions. Authorization takes place by means of the mechanism of access control, using access control lists (ACLs), which define permissions on file systems, network file and print shares, and entries in the account database. For more information about account authentication, see Chapter 16, “Understanding Logon and Authentication.”

Authentication Methods

Account authentication is performed by one of the following two methods:

  • Authentication by the local account database, for computers in workgroups and stand-alone computers.

  • Authentication by a domain account database located on a domain controller, for computers in a domain.

Windows XP Professional uses the Kerberos V5 authentication protocol as the default authentication method for domain access and NTLM for local access.

When you log on to an Active Directory domain, Windows XP Professional attempts to use Kerberos V5 security procedures as the primary source of user authentication, searching for the Kerberos Key Distribution Center (KDC) service on the domain controller. KDC is the account authentication service that runs on all Windows 2000–based and Windows Server 2003–based domain controllers.

In a Windows NT 4.0 environment, Windows 2000 and Windows XP Professional use NTLM to authenticate to the domain’s Windows NT Security Accounts Manager (SAM) database on a Windows NT–based domain controller.

When users log on locally to a workstation or to a stand-alone or member server, authentication to the local database occurs by way of NTLM rather than by way of the Kerberos V5 protocol. The local accounts database on Windows XP Professional–based and Windows 2000–based computers is a SAM database, similar to the database used in Windows NT 4.0 and earlier.

Logon Names

A user must have a unique logon name to access a domain and its resources. In a domain environment, a user is a type of security principal. Every account, domain or local, has a user name, which is also called the SAM account name.

The logon name for a user on the local computer is the same as the user name for the account stored on the local computer.

The logon name for a user in the domain can be one of two types (and every Windows 2000 or Windows Server 2003 domain user has both by default), both of which contain the user name of the domain account.

User principal name

The user principal name (UPN) consists of the SAM account name, the at sign (@), and a user principal name suffix. The default UPN suffix for a user account is the DNS domain name of the domain where the user account resides, but you can change the UPN suffix if desired. For example, the user John Doe, who has a user account in the redmond.reskit.com domain, would have the user principal name JDoe@redmond.reskit.com by default, but this could be changed to Jdoe@reskit.com to simplify logon as long as no other user has this UPN. This form of the logon name can then be used to log on to Windows 2000 or Windows Server 2003 networks.

User logon name (pre-Windows 2000)

The SAM account name is combined with the NetBIOS domain name, separated by a backslash (for example, reskit\JDoe). This form of the logon name is used to log on to Windows NT networks or to log on to a Windows 2000 or Windows Server 2003 network from a client that is running an earlier version of Windows or accessing a server that is running an earlier version of Windows.

The user principal name of the user object is independent of the distinguished name, which is the name that identifies the object and its location within Active Directory. Theoretically, two accounts that log on to the same domain can have the same SAM account name. In such a situation, it is the distinguished name that differentiates the object, not the SAM or user principal name. While this sharing of one principal name by two user objects is possible, it is never recommended, as it can cause confusion. Also, you can move or rename a user object without affecting the user principal name, and you can have multiple user principal names.

Note For a more detailed explanation of user principal names and UPN suffixes, see article 243280, “Users Can Log On Using User Name or User Principal Name,” in the Microsoft Knowledge Base at http://support.microsoft.com.

TCP/IP and Other Network Protocols

Because TCP/IP is the standard network protocol suite, IP is the protocol installed by default on Windows XP Professional. For backward compatibility, Windows XP Professional also supports NetBIOS over TCP/IP (NetBT) and Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).

Benefits of TCP/IP

Windows XP Professional includes a complete implementation of the standard, routable TCP/IP protocol suite. TCP/IP support in Windows XP provides the following benefits:

  • Support for Internet connectivity

  • Ability to route packets, which allows you to divide networks into subnets to optimize networking performance or to facilitate network management

  • Connectivity across interconnected networks that use different operating systems and hardware platforms, including communication with many non-Microsoft systems, such as Internet hosts, Apple Macintosh systems, IBM mainframes, UNIX systems, and Open Virtual Memory System (VMS) systems

  • Support for automatic TCP/IP configuration by using Dynamic Host Configuration Protocol (DHCP)

  • Support for Automatic Private IP Addressing (APIPA), allowing computers in small networks without a DHCP server to automatically assign themselves IP addresses

  • Support for automatic mapping of IP addresses to NetBIOS names by using Windows Internet Name Service (WINS) servers

  • Support for NetBIOS over TCP/IP (NetBT)

  • Performance enhancements, including a larger default TCP receive window size and selective acknowledgments

  • Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and other communications protocols used for Internet access

  • Alternate IP Configuration, a new feature that allows users to have a DHCP-assigned IP address as well as a static IP address mapped to the same network adapter and thus allows the user to roam between different networks seamlessly

When you install Windows XP Professional, TCP/IP and NetBIOS over TCP/IP (NetBT) are installed by default. Either can be configured during or after installation. IPX/SPX is also included with Windows XP Professional and can be installed if needed. For a list of legacy network protocols that are deprecated in Windows XP, see article 310310, “Network Clients and Protocols Not Included in Windows XP,” in the Microsoft Knowledge Base at http://support.microsoft.com.

For more information about features of TCP/IP in Windows XP Professional, see “Configuring TCP/IP” on the companion CD.

Configuring the Protocol Binding Order

If multiple network protocols are installed on your Windows XP Professional–based computer, you can determine the binding order of each protocol for each service that uses the protocol. The binding order determines which protocol a service uses to connect to another client or service. To reduce the time needed to find required clients and services, place the most –frequently used protocol first.

Multiple services can bind with each protocol, but the service that controls access to the network is the Client for Microsoft Networks, shown in Figure 23-4. The binding order appears on the Adapters and Bindings tab of the Advanced Settings property sheet of a selected network adapter.

Figure 23-4 Configure protocol binding order

Figure 23-4 Configure protocol binding order
To change the binding order of network protocols
  1. In Control Panel, click Network and Internet Connections.

  2. Click Network Connections.

  3. Select the connection you want to modify, and then on the Advanced menu, click Advanced Settings.

  4. On the Adapters and Bindings tab, in Connections select Local Area Connection or the specific Remote Access connection for which to change the binding order. Then, in Bindings for the selected connection, select the protocol to move up or down in the list, and then click the Up or Down button.

Locating Resources by Publishing Objects

Typically, users want to locate shared resources when they log on to the network. Windows XP Professional provides shared resources by publishing objects in domains and by using the browse function in SMB-based networks, such as Windows NT.

Publishing

Publishing is the act of  creating objects in Active Directory that either contain the information you want to make available or that provide a reference to that information. For example, a user object contains useful information about the user, such as a telephone number and an e-mail address. Similarly, a shared folder object might contain a reference to a shared file system directory or volume. Published objects are available to Windows XP Professional–based and Windows 2000–based clients, and to Windows NT 4.0–based, Windows 95–based, and Windows 98–based clients that have Active Directory client software installed. Publishing can be implemented only in an Active Directory domain where TCP/IP is the transport protocol.

Share publishing and printer publishing are two examples of file and print objects published in Active Directory.

Share publishing

Network administrators and authorized users can publish a shared folder as a shared folder object in Active Directory by using the Active Directory Users and Computers snap-in of the Microsoft Management Console (MMC). Users can then query Active Directory for a shared folder.

Printer publishing

In a Windows 2000 or Windows Server 2003 domain, Active Directory simplifies managing, locating, and connecting to printers. When you add a printer by using the Add Printer Wizard and then share the printer, the printer is automatically published as an object in Active Directory. Publishing printers in Active Directory lets users locate the most convenient printer. Users can now query Active Directory for any of these printers by specifying printer attributes such as type (PostScript or legal-sized paper, for example) and location. When you remove a printer from the server, it is unpublished by the server.

Computer Browser and Browsing Roles

The Computer Browser service provides a method of locating shared resources within a domain or workgroup environment. The service transparently designates certain workstations or servers as browse servers, which maintain master browse lists, or directories of all shared resources on the network. The Computer Browser service designates other workstations and servers as browsers, which contact the nearest browse server to obtain the master browse list.

Browsing is required by network applications that use SMB, such as My Network Places, the net view command, and Windows Explorer.

Typically, domains that allow browsing are controlled by computers that run earlier versions of Windows operating systems, such as Windows 98 or Windows NT. For compatibility, Windows 2000 and Windows Server 2003 domains support browsing for clients that use these operating systems. However, you can enhance the functionality of browsing by publishing shared resources to Active Directory and to global catalogs.

Table 23-1 describes the browser roles and functions that computers using this service can perform.

Table 23-1 Browser Roles and Functions

Browser Role

Function

Domain master browser

A browse server that collects and maintains the master browse list of available network servers for its domain, as well as any names for other domains and workgroups used in the network. The domain master browser distributes and synchronizes the master browse list for master browsers on other subnets that have computers belonging to the same domain. It is used only in domain environments. By default, the domain master browser role is held by the primary domain controller for a Windows NT domain, or the domain controller having the PDC Emulator FSMO role in a Windows 2000 or Windows Server 2003 domain. A Windows XP Professional–based computer cannot become a domain master browser, but it can function as a browse server.

Master browser

A browse server that collects and maintains the list of available network servers in its subnet. The master browser replicates its listed information by relying on the domain master browser to obtain a complete browse list for the network. This browser then distributes its completed list to backup browsers located on the same subnet.

Backup browser

Receives a copy of the browse list from the master browser for its subnet. Distributes the browse list to other computers on request.

Potential browser

Under normal conditions, operates similarly to a nonbrowser. It is capable of becoming a backup browser if instructed to by the master browser for the subnet. This is the default configuration for a Windows XP Professional–based computer.

Nonbrowser

Can operate as a browse client, requesting browse lists from other computers that have browser roles on the same subnet. However, it does not maintain a browse list. It is configured so that it cannot become a browser.

Under certain conditions, such as failure or shutdown of a computer that is designated for a specified browser role, browsers or potential browsers might change to a different role by using a process known as browser election.

When a Windows XP Professional–based computer starts, it checks the registry entry MaintainServerList to determine whether it can become a browser. This entry is found in:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\ Parameters

Table 23-2 describes the values that you can assign to the MaintainServerList entry to specify how a computer participates in browser services.

Table 23-2 Allowable Values for the MaintainServerList Registry Entry

Value

Description

No

Prevents the computer from participating as a browser.

Yes

Makes the computer a browser. At startup, the computer attempts to contact the master browser to get a current browse list. If the master browser cannot be found, the computer forces a browser election. The computer becomes either an elected master browser or a backup browser.

Auto

Makes the computer a potential browser. It might become a browser, depending on the number of currently active browsers. If necessary, the master browser instructs the computer if it must become a backup browser.

The Auto value is the default for computers running Windows XP Professional, Windows 2000 Professional, and Windows NT Workstation 4.0.

Tip Set the MaintainServerList entry to No on computers that are frequently turned off or removed from the network, such as portable computers. This ensures that a browse server remains available, helps to reduce browser elections, and reduces network overhead caused by a browser. Disabling browsing on client computers also reduces the network overhead that results from browser announcements.

Another entry in this registry location, IsDomainMaster, determines whether a Windows XP Professional–based computer can become a preferred master browser. A preferred master browser has priority over other computers in master browser elections. Whenever a preferred master browser starts, it forces an election. The default setting for a Windows XP Professional–based computer is False.

Caution Do not edit the registry unless you have no alternative. The Registry Editor bypasses standard safeguards, allowing settings that can damage your system or even require you to reinstall Windows. If you must edit the registry, back it up first.

Browser Elections

After the browsing role for a Windows XP Professional–based computer is determined, the computer checks to see whether a master browser is present on the domain. If a master browse server does not exist, a browser election determines which computer becomes a master browse server for the workgroup. A browser election occurs when the following circumstances exist:

  • A computer cannot locate a master browser.

  • A preferred master browser comes online.

  • A domain controller starts.

    Note In a Computer Browser service context, a server is any computer that can provide resources to the rest of the network. For example, a computer that can share files or print resources with other computers on the network is considered a server in the context of the browser system even if the computer is not actively sharing resources.

If a master browse server already exists, Windows XP Professional checks the number of computers in the workgroup and the available browse servers. If the number of computers in the workgroup exceeds the defined ratio of browse servers to computers (which is typically one browse server for every 32 computers) and the MaintainServerList registry entry is set to Auto, the master browser can select a Windows XP Professional–based computer to act as a backup browser.

Building the Browse List for Microsoft Networks

In Windows XP Professional, the Computer Browser service maintains an up-to-date list of domains, workgroups, and computers and provides this list to applications at the user’s request. The user sees the list in the following circumstances:

  • If a user requests a list of computers in a workgroup, the Computer Browser service on the local computer randomly chooses a browse server and sends the request.

  • If a user selects a workgroup to which the user’s computer does not belong:

    • Windows XP Professional requests a list of the computers that belong to the selected workgroup. A browse server in the selected workgroup provides the list.

    • The selected browse server sends a list of the workgroups that are on the network and a list of computers in the user’s workgroup.

The browse list is displayed anywhere that Windows XP Professional presents lists of browsable resources. You can also use the net view command to view the browse list. The list can contain the names of domains, workgroups, and computers that run the file and printer sharing service, including the following:

  • Computers running Windows 98, Windows 95, Microsoft Windows for Workgroups, and Windows NT Workstation

  • Windows NT domains and servers

  • Workgroups defined in Windows 98, Windows 95, Windows for Workgroups, Windows NT Server, and Windows NT Workstation

  • Workgroup Add-on for Microsoft MS-DOS peer servers

  • LAN Manager 2.x domains and servers

Adding to and Removing from the Browse List

When a user starts or properly shuts down a computer running Windows XP Professional on the network, it announces that event to the master browse server for its workgroup. The master browse server either adds or removes that computer from the list of available computers in the workgroup. Next, the master browse server notifies backup browse servers that a change to the browse list is available. The backup browse servers then request the new information to update their local browse lists. New computers on the network do not show up in a user’s request for a browse list until the backup browse server receives an updated browse list, which can take up to 15 minutes.

If a user turns off the computer without properly shutting it down, the computer does not notify the master browse server. In such cases, the computer name continues to appear in the browse list until the name entry times out, which can take up to an hour.

Note For additional information on how the Computer Browser service works, see article 188001, “Description of the Microsoft Computer Browser Service,” in the Microsoft Knowledge Base at http://support.microsoft.com.

Logon Scripts

A logon script is a batch file (.bat or .cmd), executable file, or procedure (including VBScript, JavaScript, or Windows Script Host) that you can use to configure the user environment after the System Policy or Group Policy is enabled. An administrator can use logon scripts to set up network directory and printer shares or start maintenance applications, such as an antivirus application.

The functionality of logon scripts that are designed for a Windows NT domain is the same for Windows XP Professional–based clients. However, after migrating to a Windows 2000 or Windows Server 2003 domain, test logon scripts to verify that your applications and procedures are compatible with Windows XP Professional.

Group Policy and System Policy Settings

System Policy is based on registry settings made by using Poledit.exe, the System Policy Editor tool. Windows NT 4.0 introduced Poledit.exe, which specifies user and computer configurations stored in the Windows NT registry. By using Poledit.exe, administrators can create a System Policy to control the user work environment and to enforce system configuration settings for all computers that run either Windows NT 4.0 Workstation or Windows NT 4.0 Server.

Windows NT 4.0 includes 72 policy settings that:

  • Assign the values only for registry entries based on .adm files

  • Apply only to users on Windows NT–based computers, or Windows 95–based and Windows 98–based computers within a domain

  • Apply only to controls exercised by user name and membership in security groups

  • Remain in user profiles only until the specified policy is reversed or until the user edits the registry

  • Function primarily for customizing desktop environments (They do not perform as well in other circumstances.)

  • Lack security

Beginning with Windows 2000, the Group Policy snap-in replaced the System Policy Editor tool used in Windows NT 4.0. The Group Policy snap-in gives you increased control over configuration settings for groups of computers and users. In Windows XP Professional, as in Windows 2000 and Windows Server 2003, Group Policy settings are your primary means for enabling centralized change and configuration management. A domain administrator can use Group Policy at a Windows 2000–based or Windows Server 2003–based domain controller to create a specific desktop configuration for a particular group of users and computers. You can also create local Group Policy settings for individual workstations to customize environments that differ from the domain environment.

A Windows 2000 domain Group Policy has more than 100 security-related settings and more than 450 registry-based settings that provide a broad range of options for managing the user environment. Windows Server 2003 offers additional options and settings, and with Service Pack 2 for Windows XP the number of registry-based settings available in Group Policy is almost 1400. Group Policy settings are:

  • Defined either locally or in the Windows 2000 or Windows Server 2003 domain

  • Extended by using MMC or .adm files

  • Not left in user profiles

  • Applied to users or computers in a specified Active Directory container (sites, domains, and organizational units)

  • Controlled further by user or computer membership in security groups

  • Used to configure many types of security settings

  • Applied to logon, logoff, startup, and shutdown scripts

  • Used to install and maintain software (Windows 2000 and Windows Server 2003 domain policies only)

  • Used to redirect folders (such as My Documents and Application Data)

  • Used to perform maintenance on Microsoft Internet Explorer (Windows 2000 and Windows Server 2003 domain policies only)

  • Used to ensure security, including configuring Windows Firewall in Windows XP Service Pack 2

You can use the Group Policy snap-in to edit local Group Policy objects to make the following changes at the local computer:

  • Define security settings for a local computer only, not for a domain or network.

  • Use administrative templates to set almost 1400 operating system behaviors.

  • Use scripts to automate computer startup, shutdown, and user logon and logoff processes.

On a stand-alone computer running Windows XP Professional, the local Group Policy object (LGPO) is located at systemroot\System32\GroupPolicy.

For more information about implementing Group Policy within a Windows 2000 domain, see “Group Policy” in the Distributed Systems Guide of the Microsoft Windows 2000 Server Resource Kit. For more information about implementing Group Policy in a Windows Server 2003 domain, see the Designing a Managed Environment book of the Microsoft Windows Server 2003 Deployment Kit and the Microsoft Windows Server 2003 Resource Kit Group Policy Guide.

System Policy and Group Policy Coexistence

You might have instances in which Windows NT System Policy must coexist with Windows 2000 and Windows Server 2003 Group Policy. Two possible scenarios follow:

  • A Windows XP Professional–based computer uses local Group Policy together with Windows NT 4.0 System Policy to enable Windows 2000 security settings.

  • A Windows XP Professional–based computer is in a Windows NT 4.0 domain that you are in the process of migrating to a Windows 2000 or Windows Server 2003 domain, and user and computer accounts are split between the two domains.

In an environment where Windows NT System Policy coexists with Windows 2000 or Windows Server 2003 Group Policy, the resulting computer and user configuration is determined by the following factors:

  • The location of the user account (Windows NT–based, Windows 2000–based, or Windows Server 2003–based domain controller)

  • The location of the computer account (Windows NT–based, Windows 2000–based, or Windows Server 2003–based domain controller)

  • The activity taking place, such as a computer starting up, a user logging on, or the refreshing of a user or system account.

Table 23-3 summarizes the expected behavior of computer and user accounts in an environment where Windows NT System Policy coexists with Windows 2000 or Windows Server 2003 domain Group Policy.

Table 23-3 Expected Behaviors of System Policies and Group Policy Settings

Environment

Account Object Location

Result at Windows XP Professional–Based Client

Windows NT 4.0 domain

Computer: Windows NT 4.0

At computer startup: Computer local Group Policy (only if changed).

Every time the user logs on: Computer System Policy.

Windows NT 4.0 domain

Computer refresh

Before Control+Alt+Delete: Computer local Group Policy only.

After the user logs on: Computer local Group Policy and computer System Policy.

Windows NT 4.0 domain

User: Windows NT 4.0

When the user logs on: User System Policy.

If local Group Policy changes: User local Group Policy and user System Policy.

Windows NT 4.0 domain

User refresh

User local Group Policy and user System Policy.

Mixed domain (migration)

Computer: Windows NT 4.0

At computer startup: Computer local Group Policy (only if changed).

Every time the user logs on: Computer System Policy.

Mixed domain (migration)

Computer refresh

Before Control+Alt+Delete: Computer local Group Policy only.

After the user logs on: Computer local Group Policy and computer System Policy.

Mixed domain (migration)

User: Windows XP Professional

Group Policy is processed by the local computer.

Windows NT 4 does not recognize Group Policy. Thus, a user logging on to a Windows NT 4 computer does not get any portion of Group Policy.

Mixed domain (migration)

User refresh

User Group Policy.

Mixed domain (migration)

Computer: Windows 2000 Server, Windows Server 2003, or Windows XP Professional

During system startup: Group Policy.

Mixed domain (migration)

Computer refresh

Computer Group Policy.

Mixed domain (migration)

User: Windows NT 4.0

When the user logs on: User System Policy.

If local Group Policy changes: User local Group Policy and user System Policy.

Mixed domain (migration)

User refresh

User local Group Policy and user System Policy.

Windows 2000 or Windows Server 2003 domain

Computer: Windows XP Professional

Computer Configuration part of Group Policy is processed when the computer starts and at designated intervals thereafter. (Period is configurable.)

Windows 2000 or Windows Server 2003 domain

User: Windows XP Professional

User Configuration part of Group Policy is processed when the user logs on.

Workgroup

Local

Local Group Policy only.

In a system environment where local Group Policy on a Windows XP Professional–based computer coexists with a Windows NT 4.0 domain System Policy, make sure that the policy settings do not conflict or override each other. For example, in a Windows NT 4.0 domain that has system policies enabled, a Windows XP Professional–based computer with local Group Policy enabled enforces both policy settings whenever the computer is restarted immediately after the user logs on.

For more information about implementing Windows 2000 Group Policy on a Windows XP Professional client, see “Defining Client Administration and Configuration Standards” in the Deployment Planning Guide of the Microsoft Windows 2000 Server Resource Kit. For more information about implementing Windows Server 2003 Group Policy on a Windows XP Professional client, see the Designing a Managed Environment book of the Microsoft Windows Server 2003 Deployment Kit.

Checking Local and Domain Policy Compatibility

Check to see whether existing local Group Policy and Windows NT System Policy are compatible. Does configuring Group Policy with Windows NT System Policy or with Windows 2000 or Windows Server 2003 domain Group Policy produce unexpected results? For example, if you configure local Group Policy to remove entries from the Start menu, does the domain Group Policy override the entries when the user logs on to the domain? For more information about the coexistence of local Group Policy with domain Group Policy or Windows NT System Policy, see “Troubleshooting Group Policy and System Policy” later in this chapter.

Group Policy Settings for Network Connections

You can use Group Policy settings or a combination of Group Policy and System Policy settings to control access to the Network Connections folder and the way the folder is used. For example, a Group Policy setting can be applied to make the Advanced Settings menu unavailable in the Network Connections folder. For more information about using Group Policy with Windows 2000 Server, see Windows 2000 Server Help. For more information about using Group Policy with Windows Server 2003, see the Windows Server 2003 Help and Support Center.

The location in the Group Policy snap-in for these settings is shown in Figure 23-5.

Figure 23-5 User Configuration in Group Policy

Figure 23-5 User Configuration in Group Policy

Descriptions of local Group Policy settings that are found under User Configuration\Administrative Templates\Network\Network Connections and that apply to Service Pack 2 for Windows XP Professional follow.

Ability to delete all user remote access connections

This setting determines whether users can delete all user remote access network connections. By default, only administrators can delete connections available to all users. If you disable this setting, users cannot delete shared remote access connections (although they can still delete their own private remote access connections). For information about using Group Policy to manage user desktops, see Chapter 5, “Managing Desktops.”

Prohibit deletion of remote access connections

This setting determines whether users can delete remote access network connections. If you enable this setting, users cannot delete any remote access connections and the Delete option is disabled on the context menu for a dial-up connection and on the File menu in Network Connections. If you disable this setting, users can delete their own private remote access connections but they cannot delete shared remote access connections unless the Ability to delete all user remote access connections setting is also enabled.

Note By default, the Prohibit deletion of remote access connections setting takes precedence over the Ability to delete all user remote access connections setting.

Ability to change properties of an all user remote access connection

The Ability to change properties of an all user remote access connection setting determines whether a user can view and change the properties of dial-up connections that are available to all users of the computer. This setting also determines whether the Dial-up Connection Properties dialog box is available to users.

If you enable this setting, users can delete shared dial-up connections. If you do not configure this setting, only administrators can delete shared dial-up connections. If you disable this setting, no one can delete shared dial-up connections. By default, users can still delete their private connections, but you can change the default by using this setting.

Also, if you disable this setting, administrators are restricted from changing properties of all user remote access connections the same as any other user.

The Ability to change properties of an all user remote access connection setting overrides settings that remove or disable parts of the Dial-up Connection Properties dialog box, such as those that hide tabs, remove the check boxes for enabling or disabling components, or disable the Properties button for components that a connection uses. If you disable this setting, it overrides these subsidiary settings.

Prohibit access to properties of components of a remote access connection

This setting determines whether users can connect and disconnect dial-up connections.

If you enable this setting, the Connect and Disconnect options on the File menu for dial-up connections are not available to users in the group.

Prohibit connecting and disconnecting a remote access connection

This setting determines whether users can connect and disconnect remote access connections. If you enable this setting, the Connect and Disconnect menu items are disabled for all users.

Ability to enable/disable a LAN connection

This setting determines whether users can enable and disable local area network connections.

If you enable this setting, users in the group can enable and disable LAN connections. If you disable this setting, even administrators are blocked from enabling and disabling LAN connections.

Prohibit access to properties of a LAN connection

This setting determines whether users can view and change the properties of a LAN connection. It also determines whether the Local Area Connection Properties dialog box is available to users.

If you enable this setting, users cannot open the Local Area Connection Properties dialog box. If you disable or do not configure this setting, the Local Area Connection Properties dialog box is displayed when users right-click the icon representing a local area connection and then click Properties. The Properties option is also available on the File menu when users select the connection.

Prohibit changing properties of a private remote access connection

This setting determines whether users can view and change the properties of their private dial-up connections.

Private connections are available to one user only. Typically, a user can create a private connection on the Connection Availability page in the Network Connection Wizard by clicking Only for myself. You can use the Prohibit changing properties of a private remote access connection setting to make the Dial-up Connection Properties dialog box unavailable to users.

If you enable this setting, users cannot open the Local Area Connection Properties dialog box. If you disable or do not configure this setting, the Local Area Connection Properties dialog box is displayed when users right-click the icon representing a local area connection, and then click Properties. The Properties option is also available on the File menu when users select the connection.

Ability to rename all user remote access connections

This setting determines whether users can rename the dial-up and local area connections available to all users.

If you enable this setting, the Rename option is enabled. Users can rename connections by clicking the icon representing a connection or by using the File menu. If you disable this setting, the Rename option is disabled. This setting has no effect on administrators.

Prohibit renaming of private remote access connections

This setting determines whether users can rename their private dial-up connections.

Private connections are available only to one user. To create a private connection, on the Connection Availability page in the Network Connection Wizard, click Only for myself.

Prohibit adding and removing components for a LAN or remote access connection

This setting determines whether administrators can add and remove network components.

If you enable this setting, the Install and Uninstall buttons for components of connections in Network Connections are disabled. Also, when this setting is enabled, administrators cannot gain access to network components in the Windows Components Wizard. If you disable or do not configure this setting, the Install and Uninstall buttons for components of connections are enabled, and administrators can gain access to network components in the Windows Components Wizard.

When this setting is disabled, the Install button opens the dialog boxes used to add network components. Clicking the Uninstall button removes the selected component in the components list (preceding the button). The Install and Uninstall buttons display when administrators right-click a connection and then click Properties. These buttons are on the General tab for local area connections and on the Networking tab for dial-up connections.

Tip When this setting is disabled, the Windows Components Wizard permits administrators to add and remove components. To use the wizard, double-click Add or Remove Programs in Control Panel. To go directly to the network components in the Windows Components Wizard, click the Advanced menu in Network Connections and then click Optional Networking Components.

Prohibit Enabling/Disabling components of a LAN connection

This setting determines whether administrators can enable and disable the components used by local area connections.

If you disable or do not configure this setting, the Properties dialog box for a connection includes a check box for each component that the connection uses. Selecting the check box enables the component, and clearing the check box disables the component. Enabling this setting dims the check boxes for enabling and disabling components. As a result, administrators cannot enable or disable the components that a connection uses.

Prohibit access to properties of components of a LAN connection

This setting determines whether administrators can change the properties of components used by a local area connection.

This setting determines whether the Properties button for components of a local area connection is enabled. If you enable this setting, the Properties button is disabled. If you disable this setting or do not configure it, the Properties button is enabled.

To find the Properties button, right-click the connection, and then click Properties. You then see a list of the network components that the connection uses. To view or change the properties of a component, click the name of the component and then click Properties.

Not all network components have configurable properties. For components that are not configurable, the Properties button is always disabled.

Ability to rename LAN connections

This setting determines whether ordinary users can rename LAN connections. If you enable this setting, the Rename option is available when users right-click the icon for a network connection.

Ability to rename LAN connections or remote access connections available to all users

This setting determines whether ordinary users can rename LAN connections or all user remote access connections. If you enable this setting, the Rename option is available when ordinary users right-click the icon for a network connection or all user remote access connection.

Note By default, the Ability to rename LAN connections setting takes precedence over both the Ability to rename LAN connections or remote access connections available to all users and Ability to delete all user remote access connections settings.

Prohibit access to the Network Connection wizard

This setting determines whether users can use the Network Connection Wizard, which creates new network connections.

If you disable or do not configure this setting, Make New Connection appears in the Network Connections folder. Clicking Make New Connection starts the Network Connection Wizard. If you enable this setting, Make New Connection does not appear. As a result, users cannot start the Network Connection Wizard.

Prohibit viewing of status for an active connection

This setting determines whether users can view the Status page for an active connection.

Status displays information about the connection and its activity. It also provides buttons to disconnect and to configure the properties of the connection.

If you disable or do not configure this setting, Status appears when users double-click an active connection. Also, an option to display Status appears on a menu when users right-click the icon for an active connection, and the option appears on the File menu when users select an active connection. If you enable this setting, Status is disabled and Status does not appear.

Prohibit access to the Remote Access Preferences item on the Advanced menu

This setting determines whether Dial-up Preferences on the Advanced menu in Network Connections is enabled.

If you enable this setting, Dial-up Preferences is disabled. If you disable or do not configure this setting, it is enabled. By default, Dial-up Preferences is enabled.

Dial-up Preferences allows users to configure Autodial and callback features.

Prohibit access to the Advanced Settings item on the Advanced menu

This setting determines whether Advanced Settings on the Advanced menu in Network Connections is enabled.

If you enable this setting, Advanced Settings is disabled. If you disable or do not configure this setting, it is enabled. By default, Advanced Settings is enabled.

By enabling Advanced Settings, an administrator can view and change bindings and the order in which the computer accesses connections, network providers, and print providers.

Turn off notifications when a connection has only limited or no connectivity

This setting determines whether notifications are presented to users when a DHCP client cannot obtain an IP address from a DHCP server. By default, such notifications are displayed, but by enabling this setting you can disable them.

Prohibit TCP/IP advanced configuration

This setting determines whether users can use Network Connections to configure TCP/IP, DNS, and WINS settings.

If you enable this setting, the Advanced button on Internet Protocol (TCP/IP) Properties is disabled. As a result, users cannot open Advanced TCP/IP Settings. If you disable this setting, the Advanced button is enabled and the users can open Advanced TCP/IP Settings and modify IP settings, such as DNS and WINS server information.

Warning If the Prohibit access to properties of a LAN connection setting or the Prohibit access to properties of components of a LAN connection setting are enabled, users cannot gain access to the Advanced button. As a result, this setting is ignored.

Joining the Network Environment

Adding a Windows XP Professional–based computer to a logical grouping of computers is called joining the domain or workgroup. To add a computer to the domain, you must be logged on to the computer with an account that is a member of the local Administrators group. If the account does not have administrative rights at the domain controller, another administrative account that does must be used. You can add a computer to a domain by using the Network Identification Wizard.

Note In a Windows 2000 or Windows Server 2003 domain, permissions to add computers to a domain can be delegated to nonadministrative user accounts. A domain administrator determines the delegation strategy used in an enterprise. For more information about delegation, see Chapter 17, “Managing Authorization and Access Control.”

Network Identification Wizard

The Network Identification Wizard provides a simple interface for joining a Windows XP Professional–based computer to a Windows NT domain, Windows 2000 or Windows Server 2003 domain, or a Windows XP Professional workgroup.

To start the Network Identification Wizard
  1. Right-click My Computer, and then click Properties.

  2. On the Computer Name tab, click Network ID, and then click Next.

  3. Select This computer is part of a business network, and I use it to connect to other computers at work, and then click Next.

Follow the subsequent instructions in the wizard to complete the process.

Changing Windows Workgroup Membership

In the default Setup configuration, a Windows XP Professional–based computer is a member of a workgroup called WORKGROUP. You can change workgroup membership by logging on to an account that has administrative permissions. You can also enable your Windows XP Professional–based computer to manually join a Windows workgroup.

Warning If your computer was a member of a domain before you joined the workgroup, it is disjoined from the domain and your computer account is disabled.

To join a Windows workgroup
  1. In Control Panel, click Performance and Maintenance.

  2. Click System.

  3. In the System Properties dialog box, click the Computer Name tab.

  4. Click Change.

  5. Under Member of, click Workgroup.

  6. Type the name of the workgroup that you want to join, and then click OK.

  7. Click OK twice to return to the System Properties dialog box.

  8. Click OK, and then click Yes to restart the computer.

Manually Joining a Windows Domain

As mentioned earlier, in the default Setup configuration, a Windows XP Professional–based computer is a member of a workgroup called WORKGROUP. You can move from a workgroup to a domain by logging on to an account that has administrative permissions. You can also manually configure a Windows XP Professional–based computer to join a Windows domain.

To join a Windows domain
  1. In Control Panel, click Performance and Maintenance.

  2. Click System.

  3. In the System Properties dialog box, select the Computer Name tab.

  4. Click Change.

  5. If the computer account has been created at the domain controller, enter the user name, password, and domain, and then click Next.

    – or –

    If the computer account has not been created at the domain controller do the following:

    1. Enter the user name, password, and domain name, and then click Next.

    2. At the prompt, enter the user name and password of an Administrator account and then click OK.

  6. Click OK twice to return to the System Properties dialog box.

  7. Click OK, and then click Yes to restart the computer.

Confirming Domain and Workgroup Membership

After you add the Windows XP Professional–based computer to the domain or workgroup, you should verify that the move is successful. To do so, restart the computer. After you press Ctrl+Alt+Del, the Log On to Windows dialog box appears. Use the arrow to the right of the Log on to text box to review the Log on to list. If you have joined a domain, the list will include the logon domain and any of its trusted domains. Reviewing the list is the first step toward confirming that you have successfully added the computer account to the logon domain.

Testing a Workgroup User Account

To test workgroup membership, log on to the local computer by using a valid user name and password. Typically, you can access all local computer resources and view other workgroup computers in My Network Places. A failure to access other workgroup computers might indicate problems with addressing or name resolution or a failure to connect to an intervening computer.

Testing a Domain User Account

You can test the validity of a user account by logging on to the trusted or logon domain. If you can log on by using the logon credentials at the domain controller, you’ve been granted access to a user account at the selected domain. If a message indicates that you’ve connected by using credentials stored in the cache, the domain controller could not be contacted during the account authentication process. It is important to verify that the physical connection (network adapter and cables) and logical connection (transport protocol configuration) permit access to the domain controller.

You can use Nltest.exe, a command-line tool included with Windows Support Tools on the Windows XP Professional operating system CD, to test the logical connection between a Windows XP Professional–based computer and a domain controller. By using Nltest.exe, you can determine whether a domain controller can authenticate a user account. Nltest.exe also establishes which domain controller performs the authentication and provides a list of trusted domains. For more information about Nltest.exe, click Tools in Windows XP Professional Help and Support Center and then click Windows Support Tools.

Establishing a Secure Channel

The logical connection between the Windows XP Professional–based computer and the domain controller is known as a secure channel. A secure channel acts to authenticate computer accounts on computers running Windows XP Professional, Windows Server 2003, Windows 2000, and Windows NT. A secure channel also authenticates user accounts when a remote user connects to a network resource. The user account exists in a trusted domain. This process is called pass-through authentication. A secure channel must exist for account authentication to be performed. Nltest.exe can test secure channels and reset them at the discretion of the user.

The following examples show a Windows XP Professional computer, Client1, that is a member of the Windows NT 4.0 domain Main_dom. The account User1, in this instance, has been created within the domain.

To identify the domain controllers in the Main_dom domain, at the command prompt, type:

nltest /dclist:Main_dom

Your output shows this information:

List of DCs in Domain Main_dom 
  \\NET1 (PDC) 
The command completed successfully

To determine whether the domain controller Net1 can authenticate the user account User1, at the command prompt, type:

nltest /whowill:Main_dom User1

Your output shows this information:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

[20:58:55]Mail message 0 sent successfully 
(\MAILSLOT\NET\GETDC939) 
[20:58:55]Response 0: S:\\NET1
 D:Main_dom A:User1 (Act found) 
The command completed successfully

In this example, S: indicates the domain controller that authenticates the account, D: indicates the domain of which the account is a member, and A: indicates the account name.

To determine whether the workstation Client1 has a secure connection with a domain controller within the Main_Dom domain, enter:

nltest /server:Client1 /sc_query:Main_Dom

Your output shows this information:

Flags: 0 
Connection Status = 0 0x0 NERR_Success 
Trusted DC Name \\NET1 
Trusted DC Connection Status Status = 0 0x0 NERR_Success 
The command completed successfully

When computer and user account authentication is completed, make sure all logon scripts perform as expected. Make sure that network shares, batch files, and tools are configured as indicated by the logon script.

Troubleshooting Microsoft Networking

Tools and techniques are available that can help you identify and resolve problems that you might encounter in a networking environment.

When troubleshooting a network connection in Windows XP Professional, first establish that the following conditions exist:

  • The cable connection between the network adapter and the port is secure. If it is, restart the computer in case you have temporarily lost connection.

  • The network adapter is correctly installed. Use Device Manager to verify that it is functioning correctly.

  • Event Viewer is correctly logging system and application events so that the problem can be fully analyzed. For more information about using Event Viewer and the event logs, see “Tools for Troubleshooting” later in this chapter.

  • At least one domain controllers is available and functioning.

For more information about troubleshooting techniques and tools, see Appendix C, “Tools for Troubleshooting;” Chapter 27, “Understanding Troubleshooting;” and Windows XP Professional Help and Support Center.

Tools for Troubleshooting

Windows XP Professional includes tools to help you diagnose and resolve networking problems. For information about the use and syntax of the troubleshooting tools, see Appendix C, “Tools for Troubleshooting.”

Event Viewer

Event Viewer allows you to monitor events in your system. It maintains logs about program, security, and system events on your computer. You can use Event Viewer to view and manage the event logs, gather information about hardware and software problems, and monitor Windows XP Professional security events. The Event Log service starts by default when you start Windows XP Professional. All users can view application and system logs.

An event log consists of a header, a description of the event (based on the event type), and additional data (optional). A typical log entry consists of the header and a description as shown in Figure 23-6.

Figure 23-6 Typical event log entry

Figure 23-6 Typical event log entry
To use Event Viewer to access a security log
  1. Right-click My Computer, and then click Manage.

  2. Click System Tools, click Event Viewer, and then click Security.

  3. In the list of specific security events, double-click the most recent one.

  4. In the Event Properties dialog box of the specific security event, read the information about the event and relevant data.

  5. Event Viewer categorizes events by log type (for example, security or system) and displays a separate log for every event, which includes date, time, source, category, ID, user account, and computer name.

The log types that directly relate to a user logging on are the security and system logs. Table 234 provides a description of these log types and how they can be used in troubleshooting.

Table 23-4 Log Types

Log Type

Description

Security

The Security Log records security events—such as valid and invalid logon attempts—and events related to resource use—such as creating, opening, or deleting files or other objects—providing auditing has been configured for the computer or domain. For example, the Security log records a user’s inability to log on to a domain account as a result of an incorrect or invalid user ID/password combination.

System

The System Log records events logged by the Windows XP Professional system components. For example, if a driver or other system component fails to load during startup, it is recorded in the System Log. Also, the System Log records a duplicate computer name on the domain as an error message sent by NetBT.

For more information about Event Viewer, see Windows XP Professional Help and Support Center.

Network Connectivity Tester (Netdiag.exe)

This command-line diagnostic tool helps isolate networking and connectivity problems by performing a series of tests to determine the state of your network client and its functionality. Netdiag.exe performs LAN connectivity and domain membership tests, including network adapter status, IP configuration, domain membership, and Kerberos V5 security tests. The tests can be performed as a group or individually.

For more information about the function and syntax of Netdiag.exe, see Appendix C, “Tools for Troubleshooting.”

Status menu command

If your computer is set up to accept incoming connections, an icon with an assigned user name appears in the Network Connections folder as each user connects. You can view the progress of incoming connections by right-clicking a named connection and then clicking Status.

By using the Status menu command, you can view the following data:

  • The duration of a connection.

  • The speed at which you initially connected. For a single-link connection and for individual links in a multilink connection, this speed is negotiated (and fixed) at the time the connection or link is established. For multilink connections, this speed is equal to the sum of the speeds of the individual links. For multilink connections, this speed varies as links are added or deleted.

  • For local area connections, the number of bytes transmitted and received during a connection. For other types of connections, the number of bytes transmitted and received during a connection, and the associated compression and error statistics.

  • The diagnostic tools that you can use for a connection, if any (for example, the Windows Network Troubleshooter, TCP/IP Autoping, and TCP/IP Windows IP Configuration).

The Support tab in the Local Area Connection Status dialog box

The Support tab in the Local Area Connection Status dialog box allows you to do the following:

  • View the address type, IP address, subnet mask, and default address of a connection.

  • Use the Details button to view a detailed summary of the network connection, which includes its physical address; the IP address of its DHCP, DNS and WINS servers; the date the DHCP lease of the address was obtained; and the date the DHCP lease is due to expire. This is in addition to the IP address, subnet mask, and default address of the connection.

  • Open the Network Diagnostics page of Windows XP Professional Help and Support Center.

  • Repair your settings by pressing the Repair button. This does the following:

    • Releases current TCP/IP settings.

    • Renews your TCP/IP settings.

    • Registers the DNS resource records for all adapters on your Windows XP Professional–based computer. All errors are reported in the Event Viewer within 15 minutes of the time registration is initiated. On the command line, you can achieve similar results by using “ipconfig/registerdns”.

    • Flushes the ARP cache.

    • Does a DHCP broadcast renew for the IP lease.

    • Purges and reloads the remote cache name table of NetBT. On the command line, you can achieve similar results by using “Nbtstat -R”.

    • Sends Name Release packets to WINS and then starts refresh. On the command line, you can achieve similar results by using “Nbtstat -RR”.

    • Purges the dns resolver cache and re-registers the DNS recodes. On the command line, you can achieve similar results by using “ipconfig/flushdns”.

Troubleshooting Joining Networks

You can use the following techniques and procedures to troubleshoot problems that might occur when you join a Windows XP Professional–based computer to a Windows NT domain, Windows 2000 domain, Windows Server 2003 domain, or a workgroup consisting of other Microsoft networking clients.

Unable to join a domain

When you attempt to add a computer running Windows XP Professional to a domain, the following message appears:

Note: The following code snippet has been displayed in multiple lines only for better readability. These should be entered in a single line.

"Unable to connect to the domain controller 
for this domain. 
Either the user name or 
password entered is incorrect."

To join a Windows XP Professional–based computer to a domain, you must provide an account name that is a member of the Domain Admins group (Windows NT, Windows 2000, or Windows Server 2003 domains) or that is a member of a group that has permissions to add computers to a domain.

Unable to find a domain controller

When you attempt to add a computer running Windows XP Professional to a domain or workgroup or a Windows XP Professional workgroup by using the Network Identification Wizard or by manually adding the computer, the following message appears:

Note: The following code snippet has been displayed in multiple lines only for better readability. These should be entered in a single line.

The specified domain does not exist 
or could not be contacted.

When you receive the preceding message, verify that the correct domain or workgroup names are entered in the Workgroup and Domain fields on the Computer Name tab of the System Properties dialog box.

If TCP/IP is the transport protocol used, the problem might be caused by the configuration of TCP/IP options on the client. Log on to a local administrative account, and perform the following tasks to resolve the problem:

  1. Attempt to ping the domain controller by using its NetBIOS name (for example, DomainController1) or a fully qualified DNSdomain name (for example, DomainController1.domain1.reskit.com). If the attempt is unsuccessful, attempt to ping the domain controller by using the IP address.

  2. If the attempt to ping the domain controller by name is unsuccessful and DNS or WINS is used for name resolution, verify the IP addresses of the name servers. Then try again to ping the domain controller by name.

  3. If the attempt to ping the domain controller by name is unsuccessful and the Windows XP Professional–based client is in the same subnet as the domain controller, verify the client’s IP address.

  4. If the Windows XP Professional–based client is in a different subnet from the domain controller, verify that you have specified the correct default gateways.

  5. If Internet Control Message Protocol (ICMP)–enabled routers are used within your network, you can use a method called ICMP Router Discovery to automate the discovery and configuration of default gateways. For more information about ICMP Router Discovery, see “Configuring TCP/IP” on the companion CD.

  6. If Routing Information Protocol (RIP)–enabled routers are used in the network, install RIP support.

  7. If a domain controller has an Internet Protocol security (IPSec) policy set at Secure Server, it denies transfer of IP packets to clients that do not have IPSec enabled by local or domain-based security policies. Contact the domain administrator to revise the IPSec policy on the domain controller. For more information about IPSec, see “Configuring TCP/IP” on the companion CD.

Unable to rename a computer

When you attempt to name or rename a computer with a name that is similar to the domain or workgroup name, the following message appears:

Note: The following code snippet has been displayed in multiple lines only for better readability. These should be entered in a single line.

The new computer name may not be the 
same as the Workgroup (Domain) name.

In a Windows NT workgroup or domain or a Windows 2000 or Windows Server 2003 domain where NetBIOS is not disabled on all clients and servers, the first 15 characters of the name of the Windows XP Professional–based computer must not duplicate the name of an existing client, workgroup, or domain. For example, if the domain name is Reskit1domainSEA, you must select a different name for a computer in that domain.

Troubleshooting Logon Problems

After joining a Windows XP Professional–based computer to a workgroup or domain, the computer running Windows XP Professional typically communicates with other clients in the network environment. You can use the following techniques and procedures to identify and resolve problems that occur when you attempt to log on to a domain or to a workgroup consisting of other Microsoft networking clients.

Unable to log on at a local workstation

After creating a computer account at the domain, you attempt to log on locally by using a non-administrative account. The following message appears:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

The system could not log you on. 
Make sure your user name and Domain are correct,  
then type your password again.
Unable to log on to a domain

After your computer joins a Windows 2000 or Windows Server 2003 domain and you attempt to log on to the domain, the following message appears:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

The system cannot log you on due to the following error: 
There is a time difference 
between the Client and Server. 
Please try again or consult your system administrator.

The Kerberos V5 authentication protocol inspects the timestamp of the authentication request sent by the logged-on client. The timestamp is compared to the current time of the domain controller. If a significant difference exists between the times (default is five minutes), authentication fails. Log on locally to an administrative account and make sure that the Windows XP Professional–based client time is the same as that of the domain controller. It is also important that the time zone be entered correctly because the Kerberos protocol converts all times to Greenwich Mean Time and then compares them that way.

Each user account object in Active Directory contains a User must log on using a smart card option. If the account is configured for using a smart card, the user selects this option, and the user then tries to log on without using a smart card, the following message appears:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

Your account has been disabled. 
Please see your system administrator.

The preceding message appears even though the account is not disabled. The user must contact the domain administrator to disable the User must log on using a smart card option.

Look for these common causes of logon failure:

  1. Password or user name incorrectly typed

  2. Password typed with CAPS LOCK on

  3. No common protocol between a Windows XP Professional–based client and a domain controller

For the first two causes of logon failure, you should receive an error that begins with “Make sure your User name and domain are correct....” For the third cause of failure, you should get an error stating that the domain controller could not be contacted.

Assuming that TCP/IP is the protocol that you used in the network, the client configuration might have changed since initial installation. Look for these causes:

  • Incorrect static addresses or subnet masks

  • DHCP enabled in an environment where no DHCP server is available

  • Improperly configured default gateways

  • Incorrect addresses for DNS or WINS servers

  • Incorrectly configured Hosts or Lmhosts files

Unable to log on to a domain after renaming the computer

Often your logon domain does not recognize the new name of your client computer. To troubleshoot this problem, you must rename the Windows XP Professional–based computer that belongs to a Windows NT domain.

To rename a Windows XP Professional–based computer that is a member of a Windows NT domain
  1. Create a new computer account (or have one created for you) that uses the new computer name.

  2. Leave the domain by temporarily joining a workgroup.

  3. When prompted, restart the computer.

  4. Join the domain by using the new computer name.

  5. When prompted, restart the computer.

Troubleshooting Group Policy and System Policy

Configuration conflicts can occur between local Group Policy settings and Windows NT System Policy, which can impede user access to system features and functions. For example, if a Windows XP Professional–based computer that was originally a stand-alone computer or a member of a workgroup is added to a Windows NT domain that uses System Policy, both the local Group Policy and Windows NT System Policy might be processed at various points in the logon process. To anticipate the behavior of a Windows XP Professional–based computer by following local Group Policy in a Windows NT domain that uses system policies, see “System Policy and Group Policy Coexistence” earlier in this chapter.

Troubleshooting My Network Places

A common problem is that you cannot use My Network Places to access all local computer resources or to see other workgroup computers. A typical problem, a likely cause, and possible solutions follow.

After successfully logging on to a workgroup or domain, you attempt to view shared resources either by typing net view at the command prompt or by opening My Network Places. The resulting window does not show any computers or members of the workgroup or domain.

Likely cause

A browser election has taken place, and the browse list is being updated on the domain master browser, on master browsers in the domain or workgroup, and on backup browsers.

Possible solution one

Attempt to force an update of the browse list by refreshing the My Network Places window. Otherwise, it might take up to 15 minutes for all browsers to receive an updated browse list.

Possible solution two

If your computer is a member of a workgroup, make sure that you have changed the default name, WORKGROUP, to the specified workgroup name.

Additional Resources

These resources contain additional information and tools related to this chapter.

Related Information

  • “Configuring TCP/IP” on the companion CD, for more information about configuring TCP/IP

  • Chapter 17, “Managing Authorization and Access Control,” for more information about account authentication

  • The Deploying Network Services book of the Microsoft Windows Server 2003 Deployment Kit, for more information about Windows networks

  • “Defining Client Administration and Configuration Standards” in the Deployment Planning Guide of the Microsoft Windows 2000 Server Resource Kit, for more information about implementing Group Policy

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.