Pop Quiz: When Is An Error Message Not An Error Message?

Answer: when it is a complete and utter pack of lies.

Yes, this is about Microsoft. How did you guess?

Back in 2012, after an Apple Time Capsule I’d previously purchased decided to die on me, I got serious about my data and purchased a QNAP TS459 Pro II NAS box. This turned out to be such a wise investment that I subsequently purchased a larger TS-670 and now use that as my “main” network storage device, with the original serving as a “daily backup” server for critical files, with a 7-generation set of backup scripts running at 02:00 every morning…

Peachy.

Except. Any time I try and open any Microsoft Office file that has macros in it, where that file is stored on a NAS, I get a little “warning strip” with a scary-looking message about the dangers of macro viruses. Never used to. This is another one of those Microsoft “improvements”.

Because I can just click the “OK” button and make the problem go away, I’ve ignored it for a while. This might have something to do with my reporting the issue to Microsoft [when I upgraded to Office 2016 for the princely sum of £389] and being told that although they couldn’t offer me the solution for free, I could buy the fix off of them.

Wait, what? No. Just: no.

Being a stubborn so-and-so, I’ve been returning to this problem from time to time, trying to figure out what needs to be done to fix it. This evening I was trawling the web, looking for suggestions, when I found this thread. Buried in there was a post from “philbo2112” [obviously a keen Rush fan] who suggested that the problem could be fixed by right-clicking on Access and selecting “Run as Administrator”.

Well, not quite. However, after doing this and then attempting once more to navigate my way through the Office “Trust Center” and “Trusted Locations”, I discovered that, as “Administrator”, I was no longer able to “see” my network-mapped drives that connect my desktop to my NAS boxes…

Meh. I’ll just use Network Browse and go in that way… And – there was the solution to the problem. Going in “the long way”, revealed that CIFS required the full [canonical?] path name of

\\NAS1\Public\Data\Office Files\

when, of course, Windows Explorer would show the exact same thing as

\\NAS1\Data\Office Files\

The “name of the share” [i.e. “Public”] is “lost” by Windows Explorer once the mapping is made. So… it turns out that all I had to do was hand-hack the path name back to the fill value and that looks to have solved the problem.

Clearly, the programmer[s] who wrote “Windows Explorer” felt they were being helpful by hiding/masking the name of the network share to which my network drive was being mapped. The programmer[s] who wrote the code for Office Trust Center were somewhat more pedantic and wanted the full network path to be explicitly recorded.

If these two products had been written by different vendors, you could sort-of understand how this might have happened. [i.e. because the OS vendor had failed to give clear guidelines on the mapping of network file systems.] But when the programmers for Office and Windows both work for Microsoft, this is inexcusable.

Idiots.