The World According to Mitch

Anyone who has taken a basic networking course will understand that UNC (Universal Naming Convention) paths are one of the common ways we in IT access file shares across our local networks.  They will usually look like this: \\oak-mgt-01\Sharename.  Of course, you can see all of the shares on a particular server by just entering the servername (\\oak-mgt-01).  Once upon a time Windows Explorer would show you that path in the address bar, but in this era of simplification of everything (i.e.: Dumbing it down) it makes it prettier by showing > Network > oak-mgt-01 > Sharename.  This changes nothing, it is the same under the hood.

Users are not the only ones who use these UNC paths.  In fact, it is our servers and applications that use them far more frequently than we do, because under the hood that is what they use to connect to any network resource.

But what happens when UNC paths stop working?

A client called me recently to tell me that none of their UNC paths were working, and because of it their production applications were down.  I checked, and sure enough a particular server could access the Internet just fine, and it could ping every internal resource it wanted, but when you tried to navigate to any UNC path, the result was a very unfriendly and generic one:

Not only was it not working, it was not even giving me a descriptive error code.  I started down a troubleshooting rabbit hole that would haunt me for hours before I found the solution.

The first thing that we confirmed is that while we were pretty sure that this was a networking issue, it was contained within the specific server.  How did we determine this?  We discovered that we got the same result when we tried to navigate to \\localhost.  Localhost is that trusty loopback adapter that exists in every network device, and is the equivalent of \\127.0.0.1… which of course we tried as well.  Because we know that Localhost lives within the server, we knew that it was not an external issue.

Before we went out to the Internet for other ideas, we tried all of the obvious things.  We changed the NIC, we verified DNS, WINS, and even NetBIOS over TCP/IP.  We reset the network connection (netsh ip reset c:\resetlog.txt).  Nothing doing.

We went out to the Internet and followed the advice of several people who had been in our spot before.  We uninstalled and then reinstalled several networking components.  We deleted phantom devices, we ran network reset tools.  No joy.

When I came across Rick Strahl’s Web Log I thought I was close…he had experienced exactly the same symptoms, and in his article UNC Drive Mapping Failures: Network name cannot be found I was hopeful that when I re-ordered the Network Provider Order in the registry (HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order) I would be home free.  Unfortunately I was wrong… but I was in the right place.

When Rick’s solution didn’t work, I was disheartened.  I was about to close it out and look at the next ‘solution’ on-line.  My instinct however told me to look again… to look closer.

There was a typo… but you have to really know what you are looking at to see it.  In fact, even if you really know what you are looking at, it is easy enough to miss.  Take a look… do you see it?  Look closer… The entry LanmanWorkstation is right there, clear as day, right?

Nobody would blame you for not noticing that there is an S at the end of the string… because S is so common at the end of words – it just makes them plural, right?  Well computers – and especially the Windows Registry – does not know English grammar, it knows binary… and the difference between LanmanWorkstation and LanmanWorkstations is the difference between working… and not working.

When I made the change it was instant – no reboot was required, the server application started working immediately.  A big sigh of relief permeated the office.

The server in question is one that several people were working on when it stopped working, and nobody is entirely sure how it happened… was it human error, or did a rogue process cause it?  We will look in our logs and figure that out later.  For the moment though, our UNC paths are back, and my client is back at work.