Recently in 70-216 Category

Incremental Migration
Incremental migration is more suitable for companies that need to completely redesign their systems and domain structure. However, this method also requires additional hardware for the migration. A high-level description of an incremental migration includes:

• Create the new forest or root domain by performing a clean Windows 2000 install.
• Establish down-level trusts between established Windows 2000 domains and the original Windows NT Server 4.0 domains so that moved users can access the resources.
• Clone groups and users by using the ClonePrincipal utility (provided in Windows 2000); this will create a duplicate user in the new domain.
• Move computers using the NetDom utility (provided in Windows 2000) to join the computers to the new domain.
• Once all users, groups, and resources have been moved or copied, retire the Windows NT Server 4.0 domains by taking any remaining Windows NT Server 4.0 controllers off-line and remove trusts.
• Decommission the Windows NT Server 4.0 domains.

Deployment Methods to Consider

The right deployment method will depend on your local IT policies and supporting infrastructure. Microsoft has improved existing deployment methods and has included new ones.

Unattended Installs. Microsoft has substantially improved the unattended install by creating a wizard-based setup manager that guides you through the process of creating the unattend.txt file for hands-free installation. The setup manager runs across the network and is the most flexible method of deployment automation. Use an answer file to specify settings that are common to multiple computers and use a uniqueness database file (UDF) during an unattended installation to identify unique settings to a computer.

Duplication. When deploying a large number of computers on identical hardware, you can use the duplication method through the Sysprep tool (sysprep.exe), which prepares the disk for duplications. Storage controllers, hardware abstraction layers (HALs), and advanced configuration and power interface (ACPI) functionality must all be identical. Sysprep allows you to set up and configure the computer and duplicate the hard drive for deployment. It strips the Security ID (SID) from the computer, but when the computer is rebooted, it regenerates the SID.

Remote Installation Services. New to Windows 2000, Remote Installation Services (RIS) allows the installation of Windows 2000 on client computers. RIS uses dynamic host configuration protocol (DHCP), DNS, the Active Directory, and the Preboot Execution Environment (PXE)-enabled client for policy-based installation. The PXE client, using DHCP, makes the request for the install service. Combining RIS with IntelliMirror� can provide a completely unattended installation and user settings.

Managing Domains
Every Active Directory namespace design includes at least one domain. One domain is sufficient for most organizations, and it is easier to administer and maintain than multiple domains.

Several reasons can justify additional domains:

• The domain will contain more than 10 million objects.
• You can control replication if a reliable network connection is unavailable.
• Two or more groups in the organization have unique domain policy and security requirements. The domain boundary constitutes the security boundary.
• The organization responds to political requests for autonomous administration of departments or divisions.

Collapse Resource Domains to a Hierarchy of OUs
In Windows NT Server 4.0, resource domains provide the means for delegating administration. Windows 2000 can reduce these administrative and hardware costs by collapsing the resource domains into a hierarchy of OUs. You can use the upgrade to the Active Directory to reduce the number of domains in the environment, thus simplifying the network administration and network structure.

Additional OUs may be necessary to delegate administration, scope the application of policy, scope visibility of objects, or to replace Windows NT Server 4.0 resource domains.

Preparing for Migration

The migration or deployment should be approached with the following goals:

• Minimize disruption to the production environment.
• Maintain or improve system performance.
• User access to data, resources, and applications must be maintained during and after the migration.
• The users' familiar environment must be maintained during and after the migration.
• There must be minimal impact on security policy.
• The enterprise must obtain earliest access to key features of the new platform.
• There must be minimal setup of new permissions for resources.
• Administrators should only have to visit the client computer a minimum number of times.
• If possible, users must be able to retain their passwords.
• There must be seamless migration of user accounts.

Domain Migration Methods

Two basic types of migration scenarios when migrating from a Windows NT Server 4.0 environment to Windows 2000 include domain migration and incremental upgrade or migration.

Domain Migration
Domain migration provides the most rapid path to migrating to Windows 2000 and the Active Directory. This is an in-place upgrade of your domain. Some high-level steps involved in a domain migration include:

• Take a synchronized backup domain controller (BDC) of the master account domain off-line; this provides a back-out plan.
• Upgrade the primary domain controller (PDC) of the master account domain and at least one BDC.
• Leave at least one BDC as Windows NT Server 4.0 to maintain a mixed-mode environment. Do not switch to native mode (all Windows 2000 domain controllers) until you need some of the replication and scalability that comes with native mode.
• Next, proceed with upgrading all resource domains using the same steps as above.
• Move objects from new Windows 2000 domains to the upgraded account domain and organize as needed. After all objects have been moved out of the Windows 2000 resource domains, retire the resource domains.

Next: Designing Your Windows 2000 Active Directory - Part 5

There are many considerations in planning your Active Directory. Do not expect to get it right the first time. For large environments, you may consider separating the planning into two or more phases.

Figure 2. Forest, Tree,and Domain Structure.

First, design what you consider to be the ideal structure, even if it does not reflect your current domain or directory infrastructure. Although what is considered the ideal structure may not seem attainable in the current situation, it may be at a later date or under different circumstances.

Next, review your existing Windows NT Server 4.0 domain model and compare it to the business, support, and administration models and goals identified above. Then begin the design of your corporate forest, tree, domain, and organizational unit structure. Figure 2 shows the structure of a forest, with trees and domains.

Steps For Designing the Active Directory Architecture

• Design forest, tree, and domain structure: When designing your forest, start with one domain; ensure that additional domains are justified. Keep the domain structure as broad and flat as possible to facilitate faster searches for object within directory.
• Design the DNS structure and namespace.
• Justify any additional forests
• Justify additional Windows 2000 domains.
• Justify an explicit trust between domains.
• Select domain migration model.
• Design domain schema: The schema should be consistent throughout the enterprise for ease of administration. Object definitions within a tree must be consistent; however, definitions can differ between the trees in a forest.
• Design site boundaries, intrasite replication, intersite replication, and site scope. Determine the size of a site and the factors affecting site scope. Services performed within a site include the following: client authentication, group policy execution, global catalog sourcing, domain controller sourcing, replication, DFS access, and file replication services (FRS) that replicate system policies and logon scripts stored in System Volume (SYSVOL) and replicate data for distributed file system.
• Design global catalog structure and usage. Design the global catalogs very carefully, specifying attributes that will be indexed for rapid searching.
• Design OU structure and determine what justifies the creation of UOs.
• Delegate administration.
• Design Group Policy object (GPOs); that is, site, domains, and organizational units.
• Design site GPOs.
• Design domain GPOs.
• Design OU GPOs.
• Determine GPO overlap for even more granular permissions.

Figure 3 shows an organizational unit tree structure. OUs exist for the delegation of administration and for the application of group policy and not to simply mirror a business organization. The default OUs are not represented in this figure: built-in, accounts, users, computers, domain controllers, and groups. Only a sample second tier is represented.

Figure 3. The Organizational Unit Tree Structure.

Designing Security
Design the security model and policies for each level. With Windows 2000 and the Active Directory, you can become very granular with security. Allow yourself additional time for developing the security model, for there is much to learn.

Next: Designing Your Windows 2000 Active Directory - Part 4

Designing Your Active Directory

Several key elements are important to consider when designing the Active Directory:

• Business model. Consider your organization's key business objectives while designing the Active Directory namespace.
• Administrative model. Consider the importance of administrative responsibility at all levels of the domain hierarchy in your enterprise network.
• Future growth and reorganization. Design the Active Directory namespace to accommodate organizational changes.
• Security. Set policies and enable trusts that provide users with secure, authorized access to network data and resources.
• The existing environment. Determine a strategy for upgrading or migrating from the existing environment to the Windows 2000 environment. This includes planning for integrating distributed applications with Active Directory.

Once you have evaluated these business issues, you should consider some characteristics that are important to the Active Directory design:

• Flexibility. As the company changes, the proposed architecture must be flexible enough to be able to accommodate those changes without any visible change to the overall service provision.
• Scalability. As the company grows or changes its business model, the proposed architecture must be able to scale at a global level and have a design that can handle rapid growth by servicing hundreds of millions of objects.
• Decentralization. The proposed architecture should be designed so that no one entity can wield absolute control over the entire namespace.
• Maintainability. The proposed architecture should be user-friendly and modular so that various parts can be replaced or changed independently of others.
• Globalization. Directory design must accommodate the size of a growing organization, keeping in mind global expansion, or dispersion. Consider the global network topology and global administration and support needs. Identify whether there is a common set of services and/or management across regions and business units.

Preparing the Windows NT Server 4.0 Environment

It is not necessary to wait. You can begin preparing your current Windows NT Server 4.0 environment for migration. The following tasks can be performed now to get your Windows NT Server 4.0 environment ready for migration:

• Perform a network discovery and document all computers; their purposes; operating system versions, including Service Packs; and application loads.
• Upgrade to Windows NT Server 4.0 any servers that are running previous versions, since Windows NT Server 4.0 provides the easiest upgrade path to Windows 2000.
• Consolidate all resources into as few domains as possible.
• Implement an enterprise-wide DNS structure. Choose one of the naming conventions supported by the Active Directory that best fits the needs of the organization.
• Simplify the Windows Internet Naming Service (WINS) architecture as much as possible. As you migrate to Windows 2000, you will still need to rely on WINS for NetBIOS resolution until you have eliminated NetBIOS altogether. In your plans for eliminating NetBIOS, be sure to check all applications for dependencies on NetBIOS.
• Become familiar with Windows Scripting Host to develop system administration tools and Microsoft Management Console (MMC) as a repository for those tools.
• Become familiar with Microsoft DFS, which provides the capability to create distributed file systems that spread across several servers. With DFS, the user does not need to know the names of the servers on which the information is stored.soft Management Console (MMC) as a repository for those tools.

Start testing now by establishing a proof-of-concept lab for product evaluation. Establishing this lab environment prior to deployment will help prevent engineers and users from "playing" with the new operating system on your production network. This will also provide an environment for application testing during your migration project.

Read the Microsoft Windows 2000 white papers and walk-throughs available on Microsoft's Web site. Microsoft has done its best job yet in providing technical white papers and migration strategies prior to the product release. Take the time to read about subjects such as site boundaries, directory replication, global catalog servers, and indexing. Implementing new features like these without completely understanding their purpose and without fine-tuning can cause less than optimal network performance.

Next: Designing Your Windows 2000 Active Directory - Part 3

The design and deployment of Windows 2000 Active Directory has several considerations. The Active Directory design phase should include the forest, tree, domain, trusts, organizational units, Domain Name System, site boundary definitions, global catalog, and schema architecture. This article provides critical information that should be considered prior to the design of the Active Directory and deployment of Windows 2000.

---

The directory service integrated into the Microsoft Windows 2000 Server and Windows 2000 Advanced Server operating systems offers many advantages over Windows NT Server 4.0. Directory Services provides access to information about people and resources on the network within one view and enables the user to search through the global catalog. Types of information found in a directory can include the following: names, locations, e-mail addresses, logins, passwords, computers, databases, printers, routers, servers, Distributed File System (DFS) volumes, and Group Policy Objects (GPOs).

The Active Directory

Everything is simply an object in the Active Directory. Information about these objects is stored in the directory information base (DIB). Entries in the DIB describe and provide links to users and physical objects. The Active Directory uses the Domain Name System (DNS) as its locator service, organizes objects within domains into a hierarchy of organizational units (OUs), and allows multiple domains to be connected into a tree structure. The namespace can contain millions of objects, a significant improvement over the Windows NT Server 4.0 size and replication limitations.

The Active Directory provides a single point for administering all published resources in the network; it even provides access to application programs. Figure 1 shows the Active Directory structure.

Figure 1. Active Directory Structure

Active Directory Service Interface (ADSI) abstracts the capabilities of directory services from different network providers to present a single set of directory service interfaces for managing network resources. ADSI is a set of extensible, easy programming interfaces that can be used to write applications to access and manage the Active Directory and any Lightweight Directory Access Protocol (LDAP)-based directory, including NetWare� Directory Services (NDS).

The object set and its available attributes are called the schema. The schema, which is stored in the Active Directory, makes object classes different from each other. The Active Directory provides the ability to extend the directory schema and to create new properties, objects, and custom data structures in the directory for applications, using the directory as a data store. One type of object is a container, which can be used to organize other objects and can be nested within other containers.

Domains represent a logical partition within the Active Directory for both security and directory replication. Domains relate directly to the DNS namespace and are, in fact, addressable through DNS. All network objects exist within a domain, and each domain contains a full set of its objects within the Domain Naming Context.

In the Active Directory architecture, trees are hierarchical structures of linked domains that form a contiguous namespace and share a common schema, configuration, and global catalog.

Next: Designing Your Windows 2000 Active Directory - Part 2

Learn what to look for on the client and the server side when fixing WINS problems.

Update: See also Steps to take to recover a crashed WINS server

Much has been made of the idea that you no longer need WINS in a pure Windows 2000 environment because DNS handles all name resolution in Windows 2000. However, many older applications still require WINS. For example, the Map Network Drive function, the My Network Places, and the net command with supported options such as net view all require WINS name resolution. So if you're running older applications like these on your network, WINS is still pretty important. In this article, we'll show you how to troubleshoot a problematic WINS installation in a Windows 2000 network.

WINS locates resources on a network by name

WINS stands for Windows Internet Naming Service. It's a name resolution service that uses the NetBIOS method to locate computer resources on a network by name. It's the follow-on from the LMHOSTS file, and it's an automatic system insofar as you don't need to manually update name records. WINS is slightly misnamed because, contrary to what its name implies, it can't be used to resolve names over the Internet. That requires DNS.

In Windows 2000, WINS is classed as a legacy name resolution method because Windows 2000 relies on DNS for all its name resolution needs, and DNS uses the Winsock API rather than the NetBIOS API. However, WINS remains the de facto name resolver in Windows NT 4.0 and earlier operating systems, and Windows 2000 Server ships with a WINS server because Microsoft recognizes the need for backwards compatibility.

Common errors

The most common errors you'll encounter on a network running WINS usually fall into two categories: PC client and/or WINS server. It's likely that the first indication of a WINS problem will come from a client PC, so it makes sense to start troubleshooting there. The vast majority of WINS-type errors can be cured at the client.

WINS client problems

The most prevalent errors with WINS clients are ones such as "Network Path Not Found" or "Name Not Found". The first things you need to do, in roughly this order, are:

• Check the network cable's physical connection to the network card and to the LAN socket.
• PING the localhost to determine whether the machine's TCP/IP stack responds properly. If it doesn't, you may need to reinstall it.
• On a Windows 2000 machine, verify that Enable NetBIOS Over TCP/IP is selected in the client's Advanced TCP/IP properties. If it's disabled, WINS resolution won't work.
• On a Windows 2000 client, verify that the TCP/IP NetBIOS Helper Service is started.
• Run the ipconfig /all command to get a detailed summary of how the client's TCP/IP stack is configured. In particular, check the Primary and Secondary WINS server IP addresses.
• Assuming that the WINS servers' entries are correct, try pinging the WINS server. If it responds, you know this client's connectivity is not suspect.
• If the error message was received while trying to connect to a different computer, open the WINS server console to check that both the client's and the required resource's WINS records exist in the WINS database.
• At a command prompt, run the command nbtstat -RR on both the client and the required resource. This forces both machines to release and refresh their WINS records.

If WINS servers aren't specified on a client, that client will, by default, try to resolve NetBIOS names by sending a broadcast to the network. If the required resource is on a different subnet, then these broadcasts can't be routed because broadcasts aren't routed in Microsoft TCP/IP. This leads to errors. That's why you need to configure WINS Proxy agents to catch, bundle, and forward these broadcasts between subnets.

If you're getting this type of error, make sure that any WINS proxies in use are installed and correctly configured. If you have more than one subnet without WINS servers, make sure that you actually set up WINS proxies in the first place so that clients can register with the WINS servers.

If you receive a Duplicate Name error, you need to find the corresponding WINS database entry on that client's Primary WINS server and delete it if it's a static record. You can manually add the correct record, or you can try to do it automatically by running the nbtstat -RR command at a command line.

WINS server problems

If your clients are working fine, you need to turn your attention to the WINS servers. Just as with the clients, you need to check the server's physical network connections first. Then you should verify that the WINS service is actually flagged as Started in the Services node of the Computer Management console. If it's stopped, attempt to restart it. If it won't start, perform a reboot to see if that clears the air.

If rebooting doesn't work, refer to the WINS database. If specific clients seem to be having problems, you need to check the accuracy of their records on the WINS server. They may have changed IP address and failed to update this information in WINS. If you have any static entries, you may want to migrate them to dynamic entries by using the Enable Migrate box in Replication Partners Properties. Dynamic mappings are better and often more accurate than their static counterparts.

It may be that WINS replication has failed. This often leads to mismatched record information, which can cause WINS-type problems. You may want to review your WINS replication strategy. If you're using a large number of WINS servers (i.e., more than 15), you definitely need to address this.

You also need to check the version ID on the WINS records. If there's a discrepancy between WINS servers, this could be part of the problem. WINS version IDs are incremented for actions like a change of IP address.

If WINS is running on a domain controller, you should consider moving the service, because WINS registration and logon authentication traffic is often most intense at the same time of day. This can prevent the server from registering itself in WINS because it's too busy answering authentication calls. Similarly, make sure the actual WINS server registers itself in the local database. Don't configure a secondary WINS server - it can be problematic if records of ownership are split across different WINS servers.

Finally, avoid installing WINS on multihomed servers. WINS registrations can become corrupted on servers that have more than one network interface if the WINS server can't work out which subnet the requests came from.

WINS is a vital component of Windows NT servers in large network environments. Although Microsoft went a long way toward eliminating WINS in Windows 2000, it's still there. When your WINS server goes bad, you need a way to restore the WINS database. Here's how.

Update: See also Troubleshoot WINS on Windows 2000

Identifying errors

Various errors are associated with WINS that may be flagged in Event Viewer. The Event IDs you're most likely to see include:

• 4318
• 4224
• 7022
• 7023
• 37

These errors deal with the inability to start the WINS service, find the WINS.mdb file/directory, or read the database header. In addition, you may see Event IDs in the low-300s range, which indicate that the WINS database is trying to repair itself and/or has successfully done so.

Some things to try first

Before proceeding with a repair operation, you need to check that the root of your problem doesn't lie with insufficient disk space. If the WINS database lives on a volume with low disk space, this fact alone may cause WINS to stop working properly, and it may cause corruption.

If restore attempts don't succeed, you should attempt a database compaction. A fragmented database is more likely to become corrupted. Much as with DHCP, the WINS database should be compacted periodically, especially if it exceeds 25 to 30 MB. Remember that it's quite possible for a WINS database to be large because of the numerous types of records WINS holds for each machine. Dynamic compaction is performed in WINS, but you still need to make periodic file size checks. Use the Jetpack.exe utility on the Windows 2000 CD for the compaction. You'll need to drop to the command line and type in the following commands, pressing [Enter] after each line:

CD %SYSTEMROOT%\SYSTEM32\WINS
NET STOP WINS
JETPACK WINS.MDB TMP.MDB
NET START WINS

Notice that you need to stop the WINS service first. If you don't, you'll likely corrupt the database further or compaction will fail. Jetpack.exe compacts the database file WINS.MDB, renaming it TMP.MDB. Jetpack.exe also deletes the old WINS.MDB and then renames the compacted file TMP.MDB to its new name, WINS.MDB. You can use any filename other than TMP.MDB, but make sure that you don't choose a name already used by another file in the same directory. If you do, it'll get overwritten and your day really will be shot. Only after the compacted file is saved as WINS.MDB can you restart the WINS service.

If all else fails

If your WINS database appears corrupted beyond repair, you can try to fix it using a utility called Winscl.exe, found in the Windows 2000 Server Resource Kit. It's a powerful utility that lets you manually inspect and correct errors in a WINS database. For instance, Winscl.exe can completely remove entries that are corrupt and, in doing so, may allow you to bring your WINS installation back online. (A full discussion of Winscl.exe is beyond the scope of this article, but you can refer to the Resource Kit and/or to Microsoft's Knowledge Base for more information.) It's important to keep in mind that Winscl.exe is a resource hog and it can affect the availability of bandwidth. You should plan an adequate amount of time to run it.

The final approach is to stop the WINS service and simply delete all the files in the WINS directory - but not the directory structure. When you restart the WINS service, all new files will be generated. Then, you'll need to check that all machines have reregistered themselves. You'll also need to delete the WINS files on push-pull partners so that all data is new when replication starts. Some administrators prefer this approach, especially in a smaller environment, because debugging WINS can take a long time. In large environments, this approach can be problematic and can eat up bandwidth, due to the greater number of client reregistrations and server replication actions that are required.

Best practices may help you avoid problems

Here's a list of some of the best practices you can follow to avoid many of these WINS problems from the outset:

• Assess how many WINS servers you need to service the number of clients in your environment. One WINS server can service 5,000 machines, but this may not be the best setup for your situation.
• Fault tolerance is crucial, as with any network service. Make sure you can replicate the WINS database to enough servers in case of failure. The aim is seamless service provision.
• Place WINS services on computers other than domain controllers. Registration and authentication traffic is heaviest at the same times of the working day, so a domain controller may become overworked.
• Avoid using static entries in WINS, because they need management. WINS is an automated service to save you time, so take advantage of that.
• Perform regular backups from the WINS console. This will speed up recovery. Make sure you also have offsite backups.
• Estimate the loads WINS places on network bandwidth, especially if you have a slow WAN link. Refer to the Resource Kit for more information on WINS' bandwidth needs.
• Use the WINS console to perform regular consistency checks. This is resource- and bandwidth-intensive, so schedule the activity outside of office hours if possible.
• Ensure that your replication setup is sensible and makes the best use of available network resources.
• Test your WINS deployment plan and modify it, if needed.

Whether your systems are powered by Windows or Linux, network configuration problems inevitably arise. Often the problem can be traced to an improperly configured TCP/IP setting, but finding the culprit can be difficult. You can use the following checklist to help you identify and eliminate network TCP/IP errors.

---

1. What stopped working? The client or the server? Ask around before attacking coworkers� PCs; learn if the outage is affecting others or just a single desktop.

2. If the server stopped working, you should notice many office mates banging their heads against their desks simultaneously. If this is the case, focus on fixing the server.

3. If a single client PC has stopped responding to the network, ask the user whether new software was just loaded or any recent changes have been made to the system, including the installation of service packs, new Internet software, Elf Bowling games, and so on.

4. Check the physical network. The physical topology of your network is most prone to failure. In fact, most network problems are often due to Physical Layer failures.

5. Is it plugged in? Check all network cable connections. Start at the NIC; is there a green light? Check the wiring closet to see if someone "borrowed" the patch cable. Check the hub to see if the system is getting a link across the cable.

6. If you don�t have a cable tester, get one. Cabling is very susceptible to electricians, cleaning people, HVAC personnel, and so on.

7. Start PINGing. Both Windows and Linux have the ping command. In a typical network you have this order (client->gateway->server) or (client->gateway->internet). First, attempt to PING yourself from the Windows command prompt or use the Linux shell. Your local "loopback" address for such testing is 127.0.0.1. Windows users should see the response shown in Listing A, while Linux operators should see the results shown in Listing B.

Listing A: Windows

C:\WINDOWS>ping 127.0.0.1 pinging 127.0.0.1 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time=1ms TTL=32 ping statistics for 127.0.0.1:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 0ms, Maximum = 1ms, Average = 0ms

Listing B: Linux

[root@gateway /root]# ping -c 4 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=1.2 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.9 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.9 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.9 ms --- 127.0.0.1 PING statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.9/0.9/1.2 ms

Note that in Linux you must add -c 4 to the command, which requests four PINGs. Otherwise, you must stop the test using [CTRL]C.

8. If you do not receive a successful PING from yourself, in Windows, try re-installing the TCP/IP protocol from the Network Control Panel. In Linux, see if your Ethernet card is loading properly by using ipconfig. It should provide the information shown in Listing C.

Listing C

[root@gateway /root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:00:11:22:33:44 inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:219876 errors:0 dropped:0 overruns:0 frame:0 TX packets:153838 errors:0 dropped:0 overruns:0 carrier:0 collisions:77 txqueuelen:100 Interrupt:10 Base address:0x230   lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0

By issuing the interface configuration (ifconfig) program, you will receive a list of your interfaces. If the loopback (lo) is not listed, you may have an incorrectly configured kernel or possible problems with the loopback module. Try recompiling/reinstalling to see if that resolves the problem.

9. If PINGing your loopback worked fine, then try PINGing someone who is on the same subnet as you. In the ifconfig example above, the IP address is set to 192.168.1.100. Thus, in this scenario you should attempt to ping 192.168.1.1. Be sure the target IP address being PINGed is a valid IP address assigned to a system; otherwise, you�ll receive errors.

Use the Start | Run | ipconfig command to learn your NT machine's IP configuration (use WINIPCFG with Windows 98). ipconfig  provides valuable information about what network you are on, as well as your gateway address. In Linux, use ifconfig to learn your network settings.

10. If you can PING someone on your local subnet, move on to the next step. If you can't, you're probably experiencing a Physical Layer failure. The usual suspects are bad cables or a NIC gone bad (they do that sometimes). With loopback, you were just testing the inner workings of the TCP/IP protocol stack; with PINGing on your local subnet you tested for failure on the failing machine. Try replacing the network card and using a new patch cable.

11. The next problem area is in the gateway. Find the IP address of your gateway. You can find this in the ipconfig screen with NT systems (WINIPCFG for Windows 98) or in Linux by running the netstat -rn command, providing these results:

[root@gateway /root]# netstat -rn Kernel IP routing table Destination  Gateway Genmask  Flags MSS Window irtt Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.254  0.0.0.0 UG 0 0 0 eth0

The -rn prints the routing table and puts everything in numeric format. In this example, the default gateway (0.0.0.0) is 192.168.1.254. If you don't have a gateway configured, then one will not show up in WINIPCFG or when using netstat. This is a problem.

In Windows, locate Start | Settings | ControlPanel | Network | TCP/IP | Gateway and add your gateway. This is your local interface on your router. In Linux, use linuxconf or set up a temporary route using the route add command.

PING this address; this will prove a solid connection from your PC to the gateway. If you have made it this far, the PC is working, the cabling is working, and the router (gateway) interface is working. You can skip to the next section.

However, if you receive no response from the gateway, and you have one configured, it's time to call in the big guns. Your router is improperly configured. It must have a local interface (IP address) on your subnet to listen to the traffic on your network. If there is no interface, have the router administrator add one. If it has one but has stopped working, it could mean you�re experiencing a router failure, and others will be affected as well. Conversely, the router administrator may have loaded an old config; check with the administrator to make sure this isn't the case.

12. The final step is through the gateway. PING something that is on the other side of the gateway. In an intranet, PING a printer on a remote subnet. On the Internet, PING www.jrksoftware.com (for example). If you do so successfully, you should not have a problem. If you can't get to a particular system in your network or on the Internet, that resource may not be available. You may want to tell the administrators of those systems about this checklist! Certainly, you can expect they�re working through the same difficulties as you.

Remember, always look for the most obvious problems first, and if in doubt, reboot your system.