Whether you operate Win98 boxes in 2018 as a hobbyist or as an IT provider (oh, how I pity you in that case), you have undoubtedly discovered at some point in Win98’s impressive tenure that sharing files across a network is by far the fastest and easiest way to get new drivers and software onto such a machine, and files such as work product, screenshots and more back off such a machine. If you happen to do any of that interfacing from a Windows 10 computer, you have likely found that your ability to talk to your Win98 box mysteriously disappeared. I did, and here’s what I did to fix it.
The scenario for me: a new Windows 98SE installation on a Toshiba Libretto 60 subnotebook is in need of some drivers and software that would be extremely inconvenient to transfer via floppy disk, and the machine has very limited I/O options that can be matched by my ThinkPad W520. My go-to solution for this type of situation is to create a share on the Windows 98 computer, connect to it from the modern computer, dump all the files I need onto the 98 box all in one go, and get to work. Sometimes I’ve done the reverse with a share on the newer machine, and generally have shares setup in both directions to provide as many options as possible. In my scenario, there is no domain in the picture, just a workgroup.
In this case, I installed the PCMCIA Ethernet card driver from the C: drive, having copied it to there from a floppy disk in “command prompt only” mode (F8 menu) – the Libretto PCMCIA floppy drive requires special drivers inside of Windows, but not in true DOS. Win98 has successfully leased an IP address, can ping the router, and can be pinged by the router. Win98 can ping Win10, and Win10 can ping Win98. Sounds great, right?
Not so! Attempting to navigate to \\Win98hostname\share from Win10 gives a strange “Windows can’t access…” message with an exception 0x80004005. Attempting to navigate to \\Win10hostname\share from Win98 gives a message that the computer does not exist on the network. Yeah, that’s cool, but you can ping each other, remember?
I couldn’t help but feel this seemed familiar, as if I’d ran into it before, but had previously fixed it (and so it should remain fixed). Since Win98 certainly hasn’t changed at all in over a decade, surely Win10, which loves to just change itself into whatever it wants to be on a day-to-day basis, is at fault.
After much hair-pulling, the truth surfaced: Windows 10, following (but not directly as part of) the Fall Creators Update (1709) de-installed support for SMBv1. MS states:
- SMBv1 now has both client and server sub-features that can be uninstalled separately.
- Windows 10 Enterprise and Windows 10 Education no longer contain the SMBv1 client or server by default after a clean installation.
- Windows Server 2016 no longer contains the SMBv1 client or server by default after a clean installation.
- Windows 10 Home and Windows 10 Professional no longer contain the SMBv1 server by default after a clean installation.
- Windows 10 Home and Windows 10 Professional still contain the SMBv1 client by default after a clean installation. If the SMBv1 client is not used for 15 days in total (excluding the computer being turned off), it automatically uninstalls itself.
- In-place upgrades and Insider flights of Windows 10 Home and Windows 10 Professional do not automatically remove SMB1 initially. If the SMBv1 client or server is not used for 15 days in total (excluding the time during which the computer is off), they each automatically uninstall themselves.
- In-place upgrades and Insider flights of Windows 10 Enterprise and Windows 10 Education do not automatically remove SMB1. An administrator must decide to uninstall SMB1 in these managed environments.
- Automatic removal of SMB1 after 15 days is a one-time operation. If an administrator re-installs SMB1, no further attempts will be made to uninstall it.
- The SMB version 2.02, 2.1, 3.0, 3.02, and 3.1.1 features are still fully supported and included by default as part of the SMBv2 binaries.
- Because the Computer Browser service relies on SMBv1, the service is uninstalled if the SMBv1 client or server is uninstalled. This means that Explorer Network can no longer display Windows computers through the legacy NetBIOS datagram browsing method.
- SMBv1 can still be reinstalled in all editions of Windows 10 and Windows Server 2016.
As we see above, my ThinkPad running Windows 10 Pro, which was updated in place to 1709, apparently automatically uninstalled SMBv1 support after 15 days of not using it. Since I do not regularly work with my Win98 hardware, this is completely plausible. According to the MS wording above, we are assured that if we re-add SMBv1 support, it will ‘stick’ and not automatically undo itself again.
To re-add SMBv1 support, navigate to Control Panel (as much as MS wants you to not see it anymore), go to Programs and Features, then Turn Windows Features On or Off. You will find SMBv1 as “SMB 1.0/CIFS File Sharing Support” which has 3 sub-items: Automatic Removal (ha! don’t install this!), Client, and Server (both of which may be beneficial depending on exactly what you’re doing).
Check the boxes for the items you want (my approach is client and server), reboot when prompted, and presto – your Win10 1709 computer can now talk to your Win98 computer again.
Quick note for completeness:
If you are looking to initially set up sharing between Win98 and Win10, there’s more to it than just the above. You will also need to change the Local Security Policy setting, Network Security: LAN Manager Authentication Level to “Send LM & NTLM responses”, and of course enable file sharing on the Win98 machine and log on using Client for Microsoft Networks.