Network Settings in Windows NT 4.0 Registry | Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software

When you install new network components, the appropriate information is added to the registry. In Windows NT 4.0, each network component is represented in the following two parts of the registry:

Software registration keys for the component driver and network adapter driver under HKEY_LOCAL_MACHINE\Software
Service registration keys for the component driver and network adapter driver Under HKEY_LOCAL_MACHINE\System

This section describes the general organization and contents of the software registration and service registration keys for network components. Next, we'll discuss bindings and dependency handling.

Types of Network Components in Windows NT 4.0 Registry

The types of network components contained in Windows NT 4.0 registry are listed in Table 8.2.

Table 8.2: Types of Network Components
Component type	Description

Adapter	This is a physical device
Driver	This is a software component directly associated with the physical device
Transport	The software component used by services
Service	The software component that services user applications
Basic	Marker used for representing the name of a fundamental class (for example, a class that has no parents)

Network Component Installation and Windows NT 4.0 Registry

When you install any type of network component, the installation program creates registry subkeys for both the services and network software. Thus, if you install a single networking component, the following keys will be created in the Windows NT 4.0 registry:

The software registration subkey for the driver, located under HKEY_LOCAL_MACHINE\Software\Company\ProductName\Version. For example, the registry path to the Etherlink adapter driver will look like the following: HKEY_LOCAL_MACHINE\Software\Microsoft\Elinkii\CurrentVersion. In Windows 2000/XP registry, there's no Currentversion key.
The software registration subkey of the network adapter card has the following registry path: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\Netcard#.
The service registration key for the driver, located under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.
The service registration subkey for the network adapter, located under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.

Software Registration Data for Network Components

When you install the network adapter, the installation program creates separate registry entries for both the driver and the adapter. Because of this, the Software key must contain several subkeys describing the network component. For each network component, registration keys for the driver and the adapter contain a special subkey named NetRules, which identifies the component as part of a set of networking components.

For example, the standard registration item for the Etherlink II driver is stored under HKEY_LOCAL_MACHINE\Software\Microsoft\Elinkii\CurrentVersion.

The standard settings for this driver may include the following:

    Description = 3Com Etherlink II Adapter Driver    InstallDate = 0x2a4e01x5    ...    RefCount = 0x1    ServiceName = Elnkii    SoftwareType = driver    Title = 3Com Etherlink II Adapter Driver

The NetRules subkey associated with the Etherlink II driver may contain the following settings:

    bindable = elnkiiDriver elnkiiAdapter non exclusive    bindform = "ElnkllSys" yes no container    class = REG_MULTI_SZ "elnkiiDriver basic"    Infname = OEMNADE2.INF    InfOption = ELNKII    type = elnkiiSys ndisDriver elnkiiDriver    use = driver

Detailed descriptions of the registry settings under NetRules keys are provided in the Regentry.hlp file included with the Windows NT 4.0 Workstation Resource Kit. This data is maintained by the system, and users shouldn't modify these settings.

The adapter (Etherlink, in our example) is described by the NetworkCards key under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\Netcard#.

Standard settings for the network adapter may look like the following:

    Description = 3Com Etherlin II Adapter Driver    InstallDate = 0x2a4e01x5    Manufacturer = Microsoft    ProductName = Elnkii    ServiceName = Elnkii02    Title = [01] 3Com Etherlink II Adapter

Service Registration Information for Network Components

The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services registry key represents the registration area for the services (including network services). The service registration information is used when you load the service into the memory. Registry subkeys under this key contain all the data needed to load the service, including the path to the executable file, service type, and startup criteria.

Software registration keys for network components, described in the previous section, contain mandatory ServiceName parameters. Each ServiceName setting has a value that represents the name of the service for the appropriate network component. This name is used as a symbolic link to the settings of the service located under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<ServiceName>.

Some network components represent a set of services rather than a single service. In this case, each of the services has its own subkey under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. Usually, these network components contain a "main" service. All other services included in the set depend on it.

To illustrate this, let's discuss our example (registry settings for the Etherlink adapter). The ServiceName setting for the Etherlink adapter driver has a value set to Elnkii. The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key contains the subkey with this name, and information contained under this subkey will define the path to the driver file, dependent services (dependencies), and other data needed to start the service. The Elnkii subkey may contain other subkeys that define settings and rules for binding this driver.

In our example, the ServiceName setting for the Etherlink adapter has a value set to Elnkii02, which is also the name of the subkey under the Services key. This key defines the binding rules and physical settings of the network adapter (for example, the I/O address and IRQ). Normally, you set these parameters using the Adapters tab of the Network window.

Binding Network Components

For the networking software to function correctly, it's necessary to load all the required software components. It's also necessary to establish appropriate relationships between all the components. These relationships are also known as bindings. To establish an optimum set of bindings, the system searches the following registry information:

The set of configurable network components
Types of network components included into this set
Restricting settings for network components and their bindings
Possible bindings that can be established
The appropriate method of informing network components about their bindings

During the system startup, the kernel scans the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key to find binding information for each service. If it finds such information, it creates the Linkage subkeys to store these data. For example, the Bind setting under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage may contain the following string:

    Bind\Device\Nbf_Elnkii01\Device\Nbf_Elnkii02

The Bind setting describes the binding information used by Windows NT redirector if there are two network adapters installed on the computer. In this case, the network card number is added as an index to the symbolic name of the adapter. This name is added to the name of the transport that provides access to the network card. These names are generated by the system according to restrictions that are put in effect by the network components.

All bindings must meet a usability requirement, which means that the binding must end with an adapter (physical device) or with a logical end point, which may represent a program component that manages all other information interactions. This requirement allows you to avoid loading unnecessary software components. For example, you can work with the network before deciding to remove the network card. Without the usability restriction, bindings continue to bind the components that need to be loaded (for example, without a network adapter, it's no use of loading its driver).

The example shown below illustrates the working principles of the Nbf.sys and Srv.sys software components with two Etherlink II adapters and one IBM Token Ring adapter. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf\Linkage registry key contains the following settings:

    Bind = "Device\ElnkII1"           "Device\ElnkII2"           "Device\ItmtTokll    Export = "\Device\Nbf\ElnkIIl"             "\Device\Nbf\ElnkII2"             "\Device\Nbf\IbmTokl"    Route = "ElnkIISys ElnkII1"            "ElnkIISys ElnkII2"            "IbmtokSys IbmTokl"

Under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Srv\Linkage, the following settings may be present:

    Bind = "Device\Nbf\ElnkII1"           "Device\Nbf\ElnkII2"           "Device\Nbf\IbmTok11    Export = "\Device\Srv\Nbf\ElnkIIl"             " Device\Srv\Nbf\ElnkII2"             " Device\Srv\Nbf\IbmTok1"    Route = "Nbf ElnkIISys ElnkIIl"            "Nbf ElnkIISys ElnkII2"            "Nbf IbmtokSys IbmTokl"

The names in the Bind and Export settings are created based on object names defined under NetRules keys for the respective components. Consequently, these settings may be different from the actual names of the services (in our example, similar names are used in order to simplify the description). The names contained in the Route settings are the names of the subkeys under the Services key, including the whole downward route along the binding hierarchy.

When the system completes the binding procedure for network components, and the results of this procedure have been saved in the registry, you may need to inform certain network components about modifications that have been introduced. For example, TCP/IP may require you to enter the IP address for each newly configured network adapter. If the NetRules key for a network component contains a Review setting that has a nonzero value, then the INF file for this network component will be checked each time the bindings are modified.

Dependency Handling for Network Components

Network services may depend on other services or drivers. These, in turn, may depend on yet other services or drivers. The system will establish the following types of dependencies:

Specific dependencies represented by the names of the services the current service is dependent on
Group dependencies
Static dependencies that are required under any condition and in any situation

Specific Dependencies

Specific dependencies simply represent the name of the required service. By default, the system generates explicit names for all dependent services detected when generating bindings. Specific dependencies are marked by the Use setting, which, in our case, appears under the NetRules key of the respective component.

For example, suppose that the Workstation service depends on NBF, which binds to the two network adapters, and, consequently, depends on their drivers. The system marks NBF as a service dependent on the two network card drivers, and the Workstation service as a service dependent on both the network card drivers and on the NBF.

Group Dependencies

This service needs to be loaded only if one of the members of the dependency set has been loaded successfully. In the previous example, the Workstation service didn't need to be loaded if the drivers for both network adapters couldn't be initialized.

The easiest approach, in this case, is using group dependencies. Each service (driver, transport, or other) can identify itself as a member of a service group. For example, all Windows NT drivers for network adapters are handled as members of the NDIS group.

In the registry, all group dependencies are marked by the Use setting, which appears under the NetRules key for the appropriate component. The groups are the symbolic names listed under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GroupOrderList.

Static Dependencies

A static dependency is a required service that needs to be loaded under any condition.

To configure a service as statically dependent on another service, create the OtherDependencies setting under the Linkage key for appropriate component. The OtherDependencies setting has a REG_MULTI_SZ data type, and it can contain as many service names as necessary.