After upgrading the OS on my workstation from Windows XP to Windows 7 I discovered that, suddenly, some files could not be opened from a network shares that was mapped on my computer when the program was running in elevated mode and the file that I wanted to open was activated by double clicking the item.
Also I discovered that when I used the "Open File" dialog from within the program all the network shares that was connected when using Explorer was now marked with a red X indicating that the connection was not established. Selecting the mapped drive would then connect the share and every thing would work as it used to for that share until the next time the computer was rebooted.
This behavior was the effect of being restrained by the UAC introduced in Windows Vista and as an administrator on the computer you actually have two sessions when you are looged on to the system, one elevated an one restricted. These two sessions does not share context, and this also includes what network shares that are mapped and connected. So when you double click a file in Explorer to open it in the associated program, and that program is set to be elevated, then you have a scenario where a program in one context is asking to have a file opened in another context, but the program in the other context does not yet known that the mapped drive exists. Only when the mapped drive has been connected in the other context, i.e. by using the "Open File" dialog and making the drives connect will the context know that the drive is accessible, and this information will last until next time the user needs to perform a new log-on and thus creating new sessions.
After searching the Internet for solutions to this problem, including understating what the underlying problem was, I ended up with two possible solution candidates
The first possible solution was a change in registry as described in this article: Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or in Windows 7. The problem, in my view, with this solution is that it essentially just removed the security boundary, and then I could just as well turn UAC completely off, plus a change to the registry was needed that was not guaranteed to work going forward. So this method was not really what I wanted, and the search for solutions continued.
As my search continued I got more and more frustrated that there was no apparent solution to this problem and I decided that it should be possible to create some kind of solution that would perform the task of entering the other security context, perform the equivalent of selecting an unconnected network share to get it reconnect.
My reasoning was that explorer is able to show me the shares that are mapped and whether they are connected or not. So I should be able to extract that information as well.
After a lot of digging around I ended up with a solution that uses some parts of Windows Management Instrumentation and some parts of Windows Shell Objects to accomplish the task.
the WMI part is used for querying what shares are mapped, but not necessarily connected and what drive letters is actually used for mounted drives. By comparing the two list I can then determine what shares that are not connected by seeing if the drive letter that is listed in the ManagementObject is also listed in the mounted drives list.
And if the drive is not mounted, and is one of the shared that I want to have mounted I can then use the WSO to mount the share to the requested drive letter.
A question may arise here of why I don't use WMI to map/mount the share as a drive. and the answer is that this was the fasted solution i could find at the time, and possibly not the best.
This fine little application now just needs to be executed once in the other context (the elevated one in this case) and then the world view would be the same for the selected drives on both sides of the security context wall.
Putting the program in the startup folder won't help you here, as Windows will block programs that require elevated privileges to avoid the elevation prompt at startup.
To solve this little dilemma I found out that I could make a scheduled task that would run whenever I logged in that can then elevate the process to the correct context and thus problem solved.
Just To make this solution deployable across the entire department where I work, I created an MSI installer that automatically created the task upon installation and removed on removal of tool, this is accomplished by using custom actions that uses the command line version of schtasks.exe
This behavior was the effect of being restrained by the UAC introduced in Windows Vista and as an administrator on the computer you actually have two sessions when you are looged on to the system, one elevated an one restricted. These two sessions does not share context, and this also includes what network shares that are mapped and connected. So when you double click a file in Explorer to open it in the associated program, and that program is set to be elevated, then you have a scenario where a program in one context is asking to have a file opened in another context, but the program in the other context does not yet known that the mapped drive exists. Only when the mapped drive has been connected in the other context, i.e. by using the "Open File" dialog and making the drives connect will the context know that the drive is accessible, and this information will last until next time the user needs to perform a new log-on and thus creating new sessions.
After searching the Internet for solutions to this problem, including understating what the underlying problem was, I ended up with two possible solution candidates
The first possible solution was a change in registry as described in this article: Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or in Windows 7. The problem, in my view, with this solution is that it essentially just removed the security boundary, and then I could just as well turn UAC completely off, plus a change to the registry was needed that was not guaranteed to work going forward. So this method was not really what I wanted, and the search for solutions continued.
As my search continued I got more and more frustrated that there was no apparent solution to this problem and I decided that it should be possible to create some kind of solution that would perform the task of entering the other security context, perform the equivalent of selecting an unconnected network share to get it reconnect.
My reasoning was that explorer is able to show me the shares that are mapped and whether they are connected or not. So I should be able to extract that information as well.
After a lot of digging around I ended up with a solution that uses some parts of Windows Management Instrumentation and some parts of Windows Shell Objects to accomplish the task.
the WMI part is used for querying what shares are mapped, but not necessarily connected and what drive letters is actually used for mounted drives. By comparing the two list I can then determine what shares that are not connected by seeing if the drive letter that is listed in the ManagementObject is also listed in the mounted drives list.
And if the drive is not mounted, and is one of the shared that I want to have mounted I can then use the WSO to mount the share to the requested drive letter.
A question may arise here of why I don't use WMI to map/mount the share as a drive. and the answer is that this was the fasted solution i could find at the time, and possibly not the best.
This fine little application now just needs to be executed once in the other context (the elevated one in this case) and then the world view would be the same for the selected drives on both sides of the security context wall.
Putting the program in the startup folder won't help you here, as Windows will block programs that require elevated privileges to avoid the elevation prompt at startup.
To solve this little dilemma I found out that I could make a scheduled task that would run whenever I logged in that can then elevate the process to the correct context and thus problem solved.
Just To make this solution deployable across the entire department where I work, I created an MSI installer that automatically created the task upon installation and removed on removal of tool, this is accomplished by using custom actions that uses the command line version of schtasks.exe
Comments
Post a Comment