Another “Network Path was not found” gotcha

When testing Overseer 5.0, I got stuck on a “Network Path is not found” issue. I was testing with workgroup-based computers instead of domain-based computers, and I was quite certain it was due to this setup that the problem was happening– as my domain based computers continued to work fine, even connecting to workgroup-based computers…

Eventually, I tracked this down to using usernames such as “.\administrator”… Sometimes Windows uses these, so you’d think it’d be OK– but when connecting FROM a workgroup-based computer to another workgroup-based computer(and maybe domain computer; I didn’t test that), you’ll get a “Network Path was not found” error– totally useless for an obvious **username** issue… While there are many causes of the network path was not found error, this is one that I didn’t know about until today.

Oddly enough, I did a network tap when trying to figure this out, and I saw Windows attempting to connect **on port 80** to the computer, versus using SMB ports(139, 445, etc.)… This was crazy, yet I could find no information online about this– obviously, it’s using the WebClient service instead when it sees a username like this…I’m still not sure why.

So, bottom line– if you’re receiving a “network path was not found” error, and you’ve gone through the checklist, make sure you’re not using .\username when logging in.

If you’re using Overseer network monitoring software, Overseer will automatically change a username without a domain qualifier into the appropriate MACHINE\username– so simply enter the username, and you’ll be OK.