You can always get the latest version of Network Drive Control here:

https://www.michaelburns.net/Software/NDC/


Permission Issues

Network Drive Control (NDC) stores its configuration under each user separately, so that different users on a machine can configure how they want any network drives mapped independent of each other. This also means that Network Drive Control (NDC) does not run & map drives until a user logs in, and then it only maps drives that specific user has configured it to map. 


Generally, the difference between permissions for network drives mapped by Network Drive Control (NDC) and permissions programs need to operate on those drives won't be a problem, because programs run by a user have the same permission level as NDC.


As mentioned above, depending of factors such as the User Account Control settings on a PC, when the drives are mapped by NDC, the security settings of the mapped drives should be the same as the user running NDC. However, this can sometimes create issues with other programs even that are running at higher permission levels, where the program cannot access or see the mapped drive. An example of this is backup software running as a System Service with Administrator privileges, may not see a drive mapped by NDC with the users level of privileges even if the user's account has Administrator privileges. This is a Windows issue having to do with the service running as a different user than the logged on user, and would also occur if the drive were mapped by the user using the Windows Explorer "Map network drive" menu. The present suggested work around is to configure the backup software to run as a regular program under each user's account, rather than as a System Service. The long term solution for NDC is for me to setup NDC to allow a user with Administrator privileges to be able to designate "all users" drives to be mounted at boot time rather than just user specific mappings the get mapped at user logon times. If this is a big issue for you, let me know and I'll raise it's priority.


Mapping Conflict Issues

NDC makes an effort when you Add, Edit or Clone a mapped drive to prevent adding conflicts to the list of mapped network drives. Examples of conflicts are situations where mappings on a given network request multiple servers to be mapped to the same drive letter or a network drive to be mapped to a drive letter already occupied by an existing hard drive or optical drive. An example where the latter can occur despite all the checks NDC could possibly do is if you plug in a USB drive before you log onto Windows and by the time you logged in, Windows had already assigned that USB drive a drive letter you had told NDC to use for mapping to a server on that network. Is such cases, the mapping will simply fail when NDC asks Windows to make it. The user won't see any error message, although if logging is turned on, the failed mapping & the reason why may appear in the log files.


Mapping & Network Environment Changes

NDC has the ability to monitor the network environment and respond to network changes in that if the system tray icon is active, then every 60 seconds NDC will see if the network the PC is connected to has changed, and if so, it will un-map any of the drives it mapped to the old network, and map any drives which are supposed to be mapped to the new network. In addition, at the same 60 second interval, NDC will in the case where the network has not changed, check and see if any drives that should be mapped to the present network did not map successfully, and it will try to remap them. This behavior is only functional if the Display Icon in System Tray menu item is checked. The default is for this not to be checked as it does consume a very small amount of system resources, which not using the system tray icon allows NDC to exit the program thus using zero resources.


SMB1 Connection Issues

SMB1 was disabled by default starting with Windows build 1709 released October 17, 2017. SMB1 was superseded by SMB2 and later protocols starting in 2007, about ten years earlier. If you need to connect to a server using SMB1 (because it's, for example, ancient) you will have to enable SMB1 in your Windows installation, and because it's not really supported, it may have issues working. This is a Windows issue, not an NCD issue as NDC communicates with Windows using the Windows Networking (WNet) API (Application Program Interface) which means that NDC hands the WNet API the path to the server, the drive letter it wants the server mapped to, and the credentials the server wants to authenticate the connection, in a manner programatically similar to the user manually entering that information into Windows Explorer's "Map network drive" menu selection.


Network Connection Encryption Issues

NDC communicates with Windows using the Windows Networking (WNet) API which means that NDC hands the WNet API the path to the server, the drive letter it wants the server mapped to, and the credentials the server wants to authenticate the connection, in a manner programatically similar to the user manually entering that information into Windows Explorer's "Map network drive" menu selection. Windows looks at the format of the path to the server and determines which of the protocols it supports is compatible with the server path format and attempts to map the drive using that protocol. Windows will interpret server paths that begin with http or https as requiring the WebDAV protocol, and server paths that begin with \\ as being Server Message Block (SMB), Common Internet File System (CIFS), or possibly Netbios protocols. If the path begins with https and the connection is successful, then the traffic between your PC and the server is encrypted. This is the only connection method you, as a client, can be sure the connection is encrypted. The details of the encryption are determined by Windows & the server, just as they would be web browsing to a https web site such as when you access your bank accounts online. Paths that begin with \\ will only be encrypted if the connection is made using SMB 3.0 or higher, and the server using SMB 3.0 requires encryption. Versions of SMB less than 3.0 do not support encryption. As a general rule, you won't know what protocol or version is used with a path that starts with \\, so you should assume all such connections are unencrypted. The most important thing to understand is that any encrypted connection that may be involved in the mapping of the drive has nothing to do with NDC and is determined by Windows & the server, exactly the same as it is when entering your drive mapping request using Windows Explorer's "Map network drive" menu.


Having said the above about encryption, if you have Administrator privileges on your computer and are running Window 8 or higher, you can start Powershell with Administrator privileges and use the Powershell Get-SmbConnection cmdlet to query whether an SMB connection is encrypted.


As an additional note, last time I tested my QNAP servers throughput, I saw a pretty substantial throughput hit, on the order of 25%, when I require encryption despite the servers CPU's supporting the Advanced Encryption Standard (AES) and New Instructions (AES-NI) in hardware.



FTP mapping to drive letters

NDC does not support mapping a server to a drive letter via FTP (or SFTP) because the WNet API does not. However there are commercial products that do such as  WebDrive, NetDrive & MountainDuck.


Drive letters in the NDC list used for other drive types

If a drive letter that appears in the NDC list of mapped network drives is attached to a non-network drive such as a USB drive, NDC may still identify it as being connected. That can also happen if the drive is a mapped network drive mapped using 3rd party software. If NDC does identify (or misidentify) such a drive and the description is nonsensical, if you email me a screen shot, a description of what the drive is, and log file, I may be able to fix it. Send feedback to NDC@michaelburns.net


Blank (Null) Passwords

This is a real rabbit hole I would generally suggest people avoid. The Windows Networking (WNet) API does support blank passwords, so NDC does as well. Whether Windows will even attempt to map a drive without a password depends on the protocol used as well as System Policy settings and System Registry settings governing guest access. Over time, various Windows 10 updates have changed the defaults to these to not allow blank or null passwords for network shares, and if you already have mappings that don't use passwords they may stop working and figuring out why can be very difficult. NDC will accept a blank password into it's settings even if the Windows machine's System Policy or System Registry settings won't allow the PC to actually attempt the connection. If you leave the password box blank when adding or editing a connection, when you save the mapping NDC will ask for confirmation just to make sure you are not making a mistake. But again, NDC won't be checking if the machine has System Policy or System Registry settings don't allow blank passwords.


Even if your Windows machine allows blank passwords for drive mappings, how the server will react when Windows attempts to map the drive without a password will also depend on a number of factors at the server side, again external to NDC. I will also say that this is a feature people asked for but I don't use. That means that despite my testing, the likelihood of a bug is higher with this feature. Please let me know if you have any issues.  


Blank (Null) UserIDs

 A lot of the same security issues exist with blank UserIDs as with blank passwords (see above). The difference with blank UserIDs is that the Windows Networking (WNet) API does not support using a blank UserID, so NDC does not either.


Net use

Some users have the mistaken impression that if they can do something with a Net Use command line, that NDC should behave the same way. That is a bad assumption. I don't know how Net Use interfaces into the Windows networking system, but Net Use seems to allow a few things that the Windows Networking (WNet) API does not, such as blank UserIDs. If you really want to use a blank UserID, you probably should use the Net Use command in a login script.


Network Identification Issues

There are situations where Windows does not associate a network name with being connected to a network, in which case NDC will not be able to identify the network to which the PC is connected.  This can occur with some types of Virtual Private Networks (VPN). I have not observed any issues with Windows correctly identifying the remote network that it VPN's into when connected using Windows built in VPN capabilities (PPTP, IPSec, etc.). However, the other two VPN protocols that I use, and so have tested against are two versions of Cisco Systems IPSec utilities, QuickVPN & AnyConnect. Cisco QuickVPN, used by some Cisco small business routers, does not allow the use of network names, and so Network Drive Control won't be able to identify the remote network. This is due to the way Cisco QuickVPN interacts with Windows, not Network Drive Control. Cisco's AnyConnect used with Cisco's enterprise class routers does not have this issue and so NDC can see the remote network's name.


If you are using a VPN solution that does not pass the network name to Windows, one work around is to simply use the wildcard (*) option for the Network Name when you create or edit the drive mapping. NDC will then attempt to make that network mapping with any network the machine finds itself on. If, for example, you have your PC automatically VPN into a network but the VPN utility does not identify the network to WIndows (and hence NDC does not receive a Network Name from Windows), if you wild card the network name and also set a sufficiently long NDC delay in the Mapping Start Delay (sec) box, then after the VPN is established NDC should still be able to map the drive.


There are situations where Windows associates the wrong network name with the network, in which case NDC will misidentify the network to which the PC is connected as it gets the network name from Windows. We have observed this to occur in cases where routers allow multiple ways to connect, such as wirelessly and wired, each with a different network name, and the router passes the wrong network name to Windows, which of course, means NDC receives the wrong network name from Windows. I've only observed this in Enterprise environments where the router and network access is messed up. This error requires the network administrator to fix their router configuration (maybe just a reboot of the router). A possible work around is to clone the mapped drive, but assign the clone to the alternate network. 


 

QuickVPN® & AnyConnect® are either registered trademarks or trademarks of Cisco Corporation in the United States and/or other countries.


Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.