3

We have a ~30 PC heterogeneous network environment. DOS, Linux, OSX, Windows 98, XP, 7 , and 10 clients, to name a few.

The question: How can I get Windows desktops to treat Mapped network drives as first-class-citizens?

  • rephrased: How can I get Novell Netware mapped paths to act like Windows Server 2008 R2 paths?
  • rephrased: How can I get Windows to "trust" my Netware resources?

We have a few mapped drives:

> C:\Users\{username}>net use
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
             F:        \\xxxxx\xxx               NetWare Services
             H:        \\xxxxx\xxx\MISC\HARDWARE NetWare Services
OK           K:        \\xxxxx-xxxxx\masact      Microsoft Windows Network
             M:        \\xxxxx\xxx\MISC          NetWare Services
             O:        \\xxxxx\xxx\SOFTWARE      NetWare Services
             P:        \\xxxxx\xxx\MISC\PUBLIC   NetWare Services
             S:        \\xxxxx\xxx\SALES         NetWare Services
             T:        \\xxxxx\xxx\MISC\TRANSFER NetWare Services
             U:        \\xxxxx\xxx\USERS\{username}
                                                NetWare Services
             Z:        \\xxxxx\xxx\PUBLIC        NetWare Services
The command completed successfully.

We're using "workgroup" settings in Windows, our desktops don't participate in a Microsoft domain.

We're using Novell Client 2 SP4 for Windows 10 (IR2) and similar, recent, clients.

Only the "Microsoft Windows Network" server's mapped drive [K:] "works" reliably; all other drives provoke security questions and file creation errors in older programs.

I have already added the Netware server's IP and UNC to the Internet Options | Attachment Manager | etc tree so it won't ask security questions when running files off the netware paths.

I have tried disabling the Windows Split Token for members of the Administrator group (which did allow mapped drives to show from elevated processes (cmd run as adminstrator won't show mapped drives, otherwise) but, with Windows 10 in this state, none of the "metro" apps can run (they refuse to run for Administrator-class accounts). And, although this did address the "drive letters hidden from elevated operations" it still doesn't fix the rest of the issues.

Specific issues, plausibly specific to Windows 10:

  • Keil µVision5 won't "save as" a file on any NetWare Services mapped drive.
  • Delphi 5 "can't rename filename.$$$ to filename.xxx" errors during compile or save, which, if you simply cancel the dialog then hit the compile button again, one time for each file in the project that needs recompiling, it will eventually succeed.
  • TextPad 7.5.1 cannot create files on Netware mapped drives. It can save to existing files, no problem.
  • CorelDraw X5 "file not found" errors when saving new files, no problem updating existing ones.

I've toggled the Netware Client "file caching" to no effect. Same with "file commit"

Thoughts?

  • 1
    DOS? Netware? Windows 98? WORKGROUPS?!?!? It was time to upgrade over a decade ago, and time to get rid of that workgroup garbage even before that. So, here's what you do... you take everything that's older than Windows 7, throw it off the roof into a pile in the parking lot, douse the pile in gasoline, and ignite it with a flare gun. Mapped drive problems, solved. – HopelessN00b Feb 04 '16 at 23:24
  • 1
    It took me a while to even find (much to my amazement) that there even was a win10 NetWare redirector. Its likely the client was written at the wrong trust level, but it is time to retire NetWare, its neither pervasive or well supported on any of the client OSes listed. While I'm not sure the bonfire is required, I'd also agree its time to leave the 80s behind on the clients. – Jim B Feb 05 '16 at 01:04

0 Answers0