I have a lot of technology in the studio. I am always looking for ways to use technology effectively to solve audio engineering problems. One problem that I used to face was how to remote control Pro Tools. In the past I used to set up in the control room and try to manage guitar, console, transport control, monitors, keyboards and mice with varying degrees of success and frustration. All that changed when I discovered remote desktop.

I use a notebook computer on the wireless LAN that connects to the Pro Tools workstation through remote desktop. The notebook then becomes the Pro Tools workstation. The monitor and keyboard on the notebook controls Pro Tools remotely. This allows me to set up in one of the talent rooms and control my studio remotely via the notebook. Very cool. Except something happened. I tried to connect to my network and I received a “network not accessible” error. Thus began a prolonged and strange battle with technology.

My first step was to search Google to see if anyone else had this experience. Turns out that most of the world has run into it if they network more than one computer. I found a Microsoft article on the issue here. This knowledge base article precisely described the symptoms I was experiencing: I could not browse other computers in the workgroup, I could not access shared folders or files, I received the dreaded error message: “Workgroup Name is not accessible. You may not have permission to use this network resource”.

The cause was due to NetBIOS over TCP/IP not being turned on and the computer browser service not being started. The resolution is to turn on NetBIOS and to ensure the computer browser service is started. So I tried the resolution.

Didn’t work. Nada. Zip. Still got the same error message.

I crawled on the web for several hours last night and avoided some much needed sleep in the process. Dozens of suggested actions to resolve the problem were discovered and all of them failed. I don’t know why the notebook would no longer see my network. It worked fine for almost a year.

And then I found the answer.

Most networks provision an address for each machine on a network. This address, known as an IP address, is often provisioned through a DHCP service. Some networks operate as broadcast networks and some operate as point-to-point. If you happen to connect a notebook computer to a different network, one that uses point-to-point, then the DHCP service might make a small change in your computer’s registery file.

If a parameter is *optionally* set by *some* DHCP server then that parameter will persist in the registry regardless of any other actions you might try. The parameter is “DhcpNodeType”. Not all DHCP servers set this parameter. I obviously had the misfortune of connecting to another network, which I often do when I travel, where the DHCP service changed this parameter. My network’s DHCP server does not change the parameter and that is why the notebook failed to join the workgroup and gave the error message. This is because my network is set up using the default “broadcast” node type and the persisting DhcpNodeType parameter continued to tell the malfunctioning machine to be a “point-to-point” node. The two types do not talk to each other.

The Solution: check the registry for the DhcpNodeType parameter. If the value is 2 then change it to 1 and reboot. Optionally one may choose the value 4 or 8 to have a computer work in both environments.

Registry Location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters
Key: DhcpNodeType
Value Type: REG_DWORD – Number
Valid Range: 1,2,4,8 (B -node, P-node, M-node, H-node)
Default: 1 or 8 based on the WINS server configuration
Description: This optional parameter specifies the NBT node type. It is written by the DHCP client service, if enabled. This parameter determines what methods NetBT uses to register and resolve names. A B-node system uses broadcasts. A P -node system uses only point- to-point name queries to a name server (WINS). An M -node system broadcasts first, and then queries the name server. An H -node system queries the name server first, and then broadcasts. Resolution through LMHOSTS and/or DNS, if enabled, follows these methods. If this key is not present, the system defaults to B -node if there are no WINS servers configured for the network. The system defaults to H -node if there is at least one WINS server configured.

By the way, there is another optional parameter at the same registry location that one may add which will override any DHCP server value placed in the DhcpNodeType.

NodeType
Key: Netbt\Parameters
Value Type: REG_DWORD – Number
Valid Range: 1 – 8
Default: 1
Description: This parameter specifies the NBT node type. It is an optional parameter that, if present, will override the DhcpNodeType parameter.

I weep for Microsoft. What a sad journey to make to ensure that your computer connects easily to a peer-to-peer network. “Hey”, tech support asks, “Didja happen to check whether you are B-node or P-node?”