[v6 General Discussion] Mapped Network Drives Not Available
2 CommentsSorted by Popular
Hi!
You will need to use the direct unc path and not the network drive.
You will need to use the direct unc path and not the network drive.
Thank you, Terry, for your response. While using network paths would technically get around the problem, it's not really a solution. Fortunately, after a bit of research I've found a solution. The problem really isn't as much EasyWorship's fault as it is Microsoft's. I'd really like to provide some valuable information here for others who may happen upon this issue so I'm going to explain things as thoroughly as I understand them; but for those who aren't interested in details here's the short answer. There are actually two solutions:
[list:184ghump]1. Disable UAC (not recommended)[/list:u:184ghump]
[list:184ghump]2. Create the DWORD "EnableLinkedConnections" with value 1 in the registry in HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System (recommended)[/list:u:184ghump]
The long answer as I understand it (which could be totally wrong):
Although Microsoft Window's UAC system has been an annoying thorn in IT Admins' sides (and developers), it's still a pretty good system, really. The ingenious part of UAC (which is also the problem here) is how it handles users with privileged rights (i.e. administrators). Even though a user may be part of the local administrators group, UAC strips off the privileged rights and the user actually operates as a standard user. These privileged rights are then granted to a separate, "hidden" privileged account of the user that is invoked only when privileges are requested (such as when EasyWorship executes with elevated privileges). Window blurs these two accounts together so that to the user it appears all as one account. So, when EasyWorship is run as administrator, even though it looks like EasyWorship is running under the same user, it is technically running under the "hidden" privileged account of the logged-in user. Furthermore, Windows does not retain any settings or session information for this privileged account of the user (which affects mapped drives).
So here's the kicker. Network drives that are mapped via Group Policy are linked only to the standard user account and not the privileged account of the user. The same goes for manually mapped drives. This is why mapped drives don't show up in EasyWorship. And if you manually map a drive while in the EasyWorship folder dialogue screen (which is run under the privileged account of the user), since Windows does not retain anything for this special privileged account it will not remember the mapped drive the next time you run EasyWorship.
So what's the solution? In their forbearance, Microsoft created an option for allowing the standard user account to share its connection links (i.e. mapped drives) with its corresponding special "hidden" privileged user account. This option is enabled by creating the DWORD "EnableLinkedConnections" in the registry. The reason this isn't default behavior is because, according to the lead UAC designer, should the privileged account be compromised it wouldn't reveal the standard user's connections as potential attack points. From my research, though this feature could technically be categorized as a security vulnerability, most consider it benign at worst. Therefore, I have no qualms about enabling it and allowing my users to see their mapped drives as expected.
*Modifying the registry is a wonderful way to hose up your system, so please do take care when performing this kind of operation. There are plenty of solid guides out there if you need guidance.
[list:184ghump]1. Disable UAC (not recommended)[/list:u:184ghump]
[list:184ghump]2. Create the DWORD "EnableLinkedConnections" with value 1 in the registry in HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System (recommended)[/list:u:184ghump]
The long answer as I understand it (which could be totally wrong):
Although Microsoft Window's UAC system has been an annoying thorn in IT Admins' sides (and developers), it's still a pretty good system, really. The ingenious part of UAC (which is also the problem here) is how it handles users with privileged rights (i.e. administrators). Even though a user may be part of the local administrators group, UAC strips off the privileged rights and the user actually operates as a standard user. These privileged rights are then granted to a separate, "hidden" privileged account of the user that is invoked only when privileges are requested (such as when EasyWorship executes with elevated privileges). Window blurs these two accounts together so that to the user it appears all as one account. So, when EasyWorship is run as administrator, even though it looks like EasyWorship is running under the same user, it is technically running under the "hidden" privileged account of the logged-in user. Furthermore, Windows does not retain any settings or session information for this privileged account of the user (which affects mapped drives).
So here's the kicker. Network drives that are mapped via Group Policy are linked only to the standard user account and not the privileged account of the user. The same goes for manually mapped drives. This is why mapped drives don't show up in EasyWorship. And if you manually map a drive while in the EasyWorship folder dialogue screen (which is run under the privileged account of the user), since Windows does not retain anything for this special privileged account it will not remember the mapped drive the next time you run EasyWorship.
So what's the solution? In their forbearance, Microsoft created an option for allowing the standard user account to share its connection links (i.e. mapped drives) with its corresponding special "hidden" privileged user account. This option is enabled by creating the DWORD "EnableLinkedConnections" in the registry. The reason this isn't default behavior is because, according to the lead UAC designer, should the privileged account be compromised it wouldn't reveal the standard user's connections as potential attack points. From my research, though this feature could technically be categorized as a security vulnerability, most consider it benign at worst. Therefore, I have no qualms about enabling it and allowing my users to see their mapped drives as expected.
*Modifying the registry is a wonderful way to hose up your system, so please do take care when performing this kind of operation. There are plenty of solid guides out there if you need guidance.
Forums Migration
Although remapping the drive consistently fixes the issue temporarily, this is not something I'd expect our average user to pull off on their own and is rather tedious. Anyone have any insight?