Network drive not accessible within installer class

[Phil]

A file used by my application may be stored on a shared network drive, so
that it can be accessed by different people using the same application. I
have written some code that uses an OpenFileDialog to allow the user to
specify the location of the file (I then store the filename in the
registry). This all works fine from when the application is run normally,
but I would like to force the user to do this when the software is first
installed. To do this I created an Installer Class in my application which
calls the same code. The OpenFileDialog is displayed, but none of the mapped
network drives are available. If I browse to my network places, I get an
access denied error.
Any suggestions appreciated.
TIA
Phil.

[=?Utf-8?B?ZG90TmV0RGF2ZQ==?=]

You might be running into Code Access Security issues. Where is the install
running from?

David
--
=============== =============== ========
David McCarter [Microsoft MVP]
www.dotNetTips.com
David McCarter''''s .NET Coding Standards available at:
http://www.cafepress.com/geekmusicart.1654787045
"Phil" wrote:

A file used by my application may be stored on a shared network drive, so
that it can be accessed by different people using the same application. I
have written some code that uses an OpenFileDialog to allow the user to
specify the location of the file (I then store the filename in the
registry). This all works fine from when the application is run normally,
but I would like to force the user to do this when the software is first
installed. To do this I created an Installer Class in my application which
calls the same code. The OpenFileDialog is displayed, but none of the mapped
network drives are available. If I browse to my network places, I get an
access denied error.
Any suggestions appreciated.
TIA
Phil.

[Jeffrey Tan[MSFT]]

Hi Phil,

I am not an installer expert, but I suspect this problem is caused by the
Windows security architecture. The network drive mapping is a per logon
session information, which means that if a process runs under a different
account as the interactive user, this process can not see the network drive
mapping that is setup by the interactive user. For example, Asp.net process
runs under a service account, so Asp.net can not see any network drive
mapping of interactive user. So, my suspicion is that the OpenFileDialog is
launched by the Windows installer under a different user account.

To prove my concept, I created a sample Winform project with Installer
class; in the OnBeforeInstall () method, I show a messagebox for testing
purpose. , then I created a setup project with it. During the installation
process, I see my messagebox pops up. Then I use Process Explorer's "Find a
Window's Process" feature to find the process of this messagebox(whic h
should be the same process that runs your OpenFileDialog) . The testing
shows that it is the "MsiExec.ex e" process that runs the MessageBox code.
Also it runs under the "NT AUTHORITY\SYSTE M" account instead of my
interactive domain account. This is why your OpenFileDialog can not see the
network drive mapping.

Let's analyze why the "NT AUTHORITY\SYSTE M" account will result in "Access
Deny" while accessing the network path. The SYSTEM account is a super
priviledge account in the local machine, but it can not be recognized
across machines because every machine has its own SYSTEM account. So, when
the SYSTEM account is accessing the network, it is identified as the
machine account. So it is quite possible that the network path on the
remote machine does not grant access for your machine's machine acount. So
the SYSTEM account accessing fails with "Access Deny".

To resolve this problem, we can explicitly establish the network drive
mapping programmaticall y in the Installer code, so that SYSTEM account can
see it. I provided detailed C# code in the link below:
http://groups.google.com/group/micro...curity/msg/063
d7b08b29e5642?h l=zh-CN&

You may use the C# to VB.net converter below to translate the sample code:
http://authors.aspalliance.com/aldot...translate.aspx

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Phil]

"dotNetDave " <do********@dis cussions.micros oft.comwrote in message
news:08******** *************** ***********@mic rosoft.com...

You might be running into Code Access Security issues. Where is the
install
running from?

Thanks for your reply. At the moment I'm just running the msi from the
output folder after I build my setup project. When we ship to customers it
will likely run from CD, or we may allow them to download the msi file from
a website.

[Phil]

Thanks for the detailed response. I think you're right, the installer code
must be running under the SYSTEM account rather than the logged in user who
started it. I have taken a quick look at the link you provided, but in that
example they knew at design time which username and password to log on to
the network as. What I really need is to have the code running under the
user account of whoever it is who started the setup program, so that the
OpenFileDialog will behave just like it does when running a normal
application.
I think it might be easier for me to take this code out of the installer,
and instead run it when the main application is started. I am setting a
value in the registry, so I can check if this value exists, and will then
know if this is the first time it is run or not and only present the
OpenFileDialog on first time use. The reason I preferred to do it in the
installer though is that I have several different executables which may be
installed from the same setup project, so I will need to do this in all of
them (I'll perhaps create a DLL that they can each use to do this).
I would still be interested for future reference though to know if there is
a way to have the installer code run under the normal user account instead
of SYSTEM.

Thanks,
Phil.

[Jeffrey Tan[MSFT]]

Hi Phil,

Thank you for the feedback.

Yes, since the SYSTEM account does not have the network credential to
access the remote machine we have to explicit provide username/password
pair to establish a new security context. This is the key shortage.

I am not a setup project expert. But I have talked with my setup
specialized colleague, he told me that .Net setup project does not offer
the capability to specify the MSI Windows service running account. So I do
not think we can run the installer code under the interactive user account
using .Net setup project. However, I am not sure if Win32 MSI has this
limitation.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== ===========
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.

This posting is provided "AS IS" with no warranties, and confers no rights.