NetBEUI functionality on Windows 10 with Heidelberg CPC32 as alternative
NetBEUI functionality on Windows 10 with Heidelberg CPC32 as alternative
Has anyone managed to resolve NetBEUI compatibility on a Windows 10 system? This issue often arises with older CNC equipment still using NETBEUI for file sharing, and we have a printing press that faces a similar challenge. It appears the machine is an outdated prepress unit running Windows Server 2000, and the problem lies in its inability to support the NetBEUI protocol—something that seems to have been deprecated after Windows 7. The press’s system relies on this legacy protocol for SMB traffic. Copying netbdf.inf and nbf.sys from the old server into the Windows INF and System32/drivers directories works, but installing them manually through Ethernet Properties triggers a policy block. I could likely turn TCP/IP on the older machine, but that would pose even greater security risks than enabling NetBEUI on a modern Windows 10 device, especially since the press runs Windows NT 4.0. It seems best to install NetBEUI support on the new replacement unit for reliable operation.
Generally not feasible... Usually I'd recommend using Linux as a bridge, but checking if Linux supports NETBEUI led me to an old 1998 discussion stating MS has stopped maintaining it, making implementation on Linux impractical. Instead, consider running a Win2k/XP VM to share a directory via NETBEUI, and then access the same folder through modern methods for broader compatibility.
Microsoft restricts my ability to install older Windows versions needed by my organization from VLSC. I considered running Linux inside a VM with a PCIe NIC connected. It seems unlikely any Windows software would support this due to driver limitations on the Windows NIC side. Likely, that’s where I should focus next. The issue intensifies when I tried netBIOS over TCP/IP directly on a wired Windows NT machine—it didn’t work, regardless of cable or TCP/IP settings. I also couldn’t locate the required technician-level credential to adjust TCP/IP configurations. It’s possible additional steps are needed, as netBIOS over TCP/IP functions smoothly on Windows Server 2000.
Occasionally you need to ignore the licensing rules... since the real fix would be to upgrade or replace the equipment.
I'm planning to try Linux next. The Pro B660M-C D4-CSM motherboard works with my i5-12400 for this build because I needed LPT headers and other features like VGA and PS/2. Since it's a P-core model, I wasn't sure how older 2000 software would work. I'll provide an update if Linux proves useful. The Windows NT 4.0 setup only required SMB over netBIOS over netBEUI. In the worst case, the system might run on an old SD card that I could use to manually move files. This seems like the best overall option rather than keeping a Windows NT 4.0 and Server 2000 machine on the LAN. I might need to look for a reader, but I could adapt an old IDE version for internal USB.
NetBEUI presents challenges but offers a workaround. By setting up TCP/IP in the Heidelberg SM102's CP2000, which runs Windows NT 4.0, it becomes functional. If you manually input a random IP within the software, it activates the protocol. Otherwise, it remains disabled. In this setup, static IP addresses are necessary for color printing. I've managed to bypass the netBEUI restrictions, which is impressive. Regarding netBEUI, it isn't routable by default. However, on my network, a Windows Server 2000 connected to a gateway switch (x.x.10.1) uses an SFP port to link with a switch (10.13), where the NT 4.0 machine resides. If netBEUI can't be routed, how does it manage to communicate over the network? This is interesting given my limited prior knowledge of the protocol.
In the late '90s, netBEUI felt like a mysterious tool you encountered while setting up TCP/IP but had no prior experience with. Unless you were part of the field dealing with older hardware, it seemed like something out of a reference list.
To wrap up this conversation, for those encountering the same situation and preferring not to rely on air gapping as a safeguard, this discussion is customized for the Heidelberg SM102 and its individual machines. It might also apply to CNC systems facing comparable challenges. Swapping out the Prepressinterface software is feasible using a Windows 10 system, provided you have the original installation disc. There are some details to sort out by testing on the legacy machine to verify settings—such as accessing the Registry Editor to retrieve the equipment ID. I strongly advise either upgrading this unit or making sure your configurations are securely stored in other programs. Attempting this without the original hardware would probably not work. You’ll likely need to adjust how data transmissions function. If your setup currently connects via SMB to the CP2000 machine, consider revising that configuration. Until you assign a fixed IP address to the CP2000 device, TCP/IP won’t be active and only netBEUI will remain enabled. In this case, assigning it a random IP with a 255.255.255.0 network would allow you to wire it directly to your CPC32 replacement on the same subnet. The new CPC32 unit can then operate freely within the network without compromising security. Because the machine is physically connected to the CP2000, I placed it in the same rack as the operator panels. Even though the adjacent cabinet now uses 120mm intake and exhaust fans, I positioned CPC32(10) on the opposite side, which is airtight. The i5 12400 in CPC32(10) has Turboboost turned off, which hasn’t caused performance problems—this unit also serves as a login point for press operators. It’s limited to 2.5GHz due to its sealed design. This was done intentionally to lower heat output. As a result, the CPU runs at around 30°C (with Thermalright PA 120), which is quite efficient. If anyone else has a similar problem with an older CNC system, I recommend following a comparable path. Look for ways to activate TCP/IP and replace the outdated operating system with a newer machine acting as a bridge between it and the network for SMB. The core unit driving the equipment is usually essential, so using a modern computer as a proxy is ideal. Any device supporting netBIOS over netBEUI should also support TCP/IP. In this instance, enabling it through the machine’s specialized software by assigning a static IP would be key. This unit had the feature in Windows on its network card, but it wasn’t activated until given a fixed IP address. If you can get TCP/IP working on the original machine, swapping its SMB role becomes feasible.
It’s not being routed properly. What bothers me is that modern switches still accept it. Those were the good times when NetBEUI was the main protocol on NT4. I believe Microsoft addressed this in SP4 after complaints. If you configure an NT4 server without disabling the NetBEUI option in network settings, all devices will default to it over TCPIP. That’s clever. This seems to match your situation since NetBEUI was often left on by mistake, but with NT4’s widespread use many companies wanted a simpler solution. I’ve resolved numerous network problems back then—usually by turning off NetBEUI, restarting the server, and seeing performance improve. The switch’s behavior helped because packet floods were limited. Token Ring performed better in some cases due to its design and layout, but it couldn’t handle the issue. Newer Windows systems often have NTLM or SMB problems with older hardware, so well done fixing this! NT4 was a solid platform.