|
|
You're in the
visual studio .net setup
group:Setup without admin privileges
visual studio .net setup:
application has to be able to read and write to MS Access databases. Therefore I added the MDAC merge module (MDAC.MSM, version 2.7, see http://support.microsoft.com/default.aspx?scid=kb;en-us;320788) to the setup project. My customer complains that installing the application on Windows 2000 machines that are part of a Windows domain is a cheek: First you have to log on with administrator privileges to install the .Net framework 1.1 (dotnetfx.exe does not start without administrator privileges). After that the customer tried to install the application while being logged on as a normal user (not power user). The problem here: The setup program fails while installing the MDAC files. Obviously the MDAC merge module extracts its own nested setup.exe which does not have enough access rights to succeed. The customer's second attempt also had problems: Being logged on as normal user he started setup.exe (the bootstrapper setup.exe that launches the .msi file) and the operating system offered to run the setup using the administrator account. The customer chose to do so and could finish the setup successfully. However, using the icon which was added to the start menu brought up the Windows installer which finally failed. The third attempt was to log on as administrator start setup and then choose 'Install for all users'. The result was similar to the second attempt: The setup initially succeeded but starting the application as normal user failed. Conclusion: It is not possible to install and run the application without admin privileges. Creating setup programs was and is a pain. Guido
Hi Guido,
Thanks for posting. First of all, it is obvious that we must have admin permission to install this application. MDAC is a system level component and only admins are allowed to install it. Secondly, as you mentioned ,after an admin installs the product successfully, when a normal user tried to open the application, MSI is triggered to repair something. Based on my past experience, this may happen if you have installed some files into user specific folders, like "My Documents", "Application Data" or installed something under the "HKCU" registry key. If this is the case, it is natural that the deployment may fail, since user specific data is not accessible to another user. You may need to revise your deployment logic. I hope the information is useful to you. Regards, Felix Wang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "as is" with no warranties and confers no rights.
My setup is very straightforward: I have an .EXE which is installed
into the application folder, a link to this .EXE which is installed into "User's Program Menu", the MDAC merge module, and the Crystal Report merge modules which are included with VS.NET 2003. There are no other files or registry settings. If you are logged on as normal user the installation fails during the MDAC part of the setup. You can successfully install the application with admin privileges. After that the user can click the application icon in the start menu but then sees the Windows installer which fails. How should I change the setup to get it working with normal users? Should I leave out the MDAC merge module? If so, can I be sure that the application will run under any version of Windows NT, 2000, XP? As I understand the Windows Installer technology was meant to be able to install files even if you don't have admin access rights. And what is the MDAC merge module good for if it does not install? The only solution I can see is to give the user local administrator privileges. However, for my customer, this is not acceptable. Guido "Felix Wang" <v-felwa@online.microsoft.com> schrieb im Newsbeitrag news:Ywjh96NKEHA.3088@cpmsftngxa10.phx.gbl... [quoted text, click to view] > Hi Guido, > > Thanks for posting. > > First of all, it is obvious that we must have admin permission to install > this application. MDAC is a system level component and only admins are > allowed to install it. > > Secondly, as you mentioned ,after an admin installs the product > successfully, when a normal user tried to open the application, MSI is > triggered to repair something. Based on my past experience, this may happen > if you have installed some files into user specific folders, like "My > Documents", "Application Data" or installed something under the "HKCU" > registry key. > > If this is the case, it is natural that the deployment may fail, since user > specific data is not accessible to another user. You may need to revise > your deployment logic. > > I hope the information is useful to you. > > Regards, > > Felix Wang > Microsoft Online Partner Support > Get Secure! - www.microsoft.com/security > This posting is provided "as is" with no warranties and confers no rights. >
Some preaching here, please excuse me.....
Xcopy deployment of .NET apps has nothing to do with deploying system components that might be requirements for those apps. If your app required a Windows Service pack, you wouldn't expect a non-Admin user to be able to install the SP, and the support for .NET apps is in the same category. (The installation design issue is that people expect the MSI setup to do everything. ) You can avoid manually installing things with a helper program (like a CD autoplay) that checks for prerequisites like MDAC and the framework, and that can be on the CD in a form that an Administrator can install them and the user then install the app. There are external bootstrap programs that you can use as a base - http://www.codeproject.com/dotnet/dotNetInstaller.asp?target=dotnetinstaller The Crystal Reports message seems to be a consequence of their design, not ..NET. Their application installs or uses files in that common files folder, and on my system ordinary users do not have Full Control, Write or Modify privileges to that folder. It's a fairly common issue that people design apps that need access to secured folders instead of the "correct" folders (such as the application data folder for the installing user), and consequently you need Admin privilege. If an MSI file could be run by a non-Admin user and update secured parts of the system, that would be an enormous security breach. Non-Admin users can have apps deployed with GPO, Active Directory, or something like the Application Deployment Editor. The MSI files need blessing by an Administrator first befre a non-Admin can install them. -- Phil Wilson [MVP Windows Installer] ---- [quoted text, click to view] "Guido Kraus" <guido@somewhere.com> wrote in message news:OdAjkpWKEHA.556@TK2MSFTNGP10.phx.gbl... > I did some further tests: > I removed the MDAC merge module and tried to install the application as a > normal user (not even Power User). The installation started but then failed > during installation of the Crystal Reports components ("No access rights for > C:\Program Files\Common Files"). > > If I run the setup with Administrator permissions it now works as expected: > After logging on as normal user, you can start the application using the > icon in the start menu. And this time no Windows installer pops up. > > However, I'm a little disappointed: > - you have to manually install dotnetfx.exe > - then you have to manually install mdac_typ.exe > - after that you need an MSI based setup (because of the Crystal Reports > engine) > - and for all that you need Administrator permissions. > > I thought I heard something about xcopy deployment of .NET apps... > > Guido > > > "Guido Kraus" <guido@somewhere.com> schrieb im Newsbeitrag > news:uXTkIaTKEHA.2456@TK2MSFTNGP12.phx.gbl... > > My setup is very straightforward: I have an .EXE which is installed > > into the application folder, a link to this .EXE which is installed into > > "User's Program Menu", the MDAC merge module, and the Crystal Report merge > > modules which are > > included with VS.NET 2003. There are no other files or registry settings. > > > > If you are logged on as normal user the installation fails during the MDAC > > part of the setup. You can successfully install the application with admin > > privileges. After that the user can click the application icon in the > start > > menu but then sees the Windows installer which fails. > > > > How should I change the setup to get it working with normal users? Should > I > > leave out the MDAC merge module? If so, can I be sure that the application > > will run under any version of Windows NT, 2000, XP? As I understand the > > Windows Installer technology was meant to be able to install files even if > > you don't have admin access rights. And what is the MDAC merge module good > > for if it does not install? > > > > The only solution I can see is to give the user local administrator > > privileges. However, for my customer, this is not acceptable. > > > > Guido > > > > > > "Felix Wang" <v-felwa@online.microsoft.com> schrieb im Newsbeitrag > > news:Ywjh96NKEHA.3088@cpmsftngxa10.phx.gbl... > > > Hi Guido, > > > > > > Thanks for posting. > > > > > > First of all, it is obvious that we must have admin permission to > install > > > this application. MDAC is a system level component and only admins are > > > allowed to install it. > > > > > > Secondly, as you mentioned ,after an admin installs the product > > > successfully, when a normal user tried to open the application, MSI is > > > triggered to repair something. Based on my past experience, this may > > happen > > > if you have installed some files into user specific folders, like "My > > > Documents", "Application Data" or installed something under the "HKCU" > > > registry key. > > > > > > If this is the case, it is natural that the deployment may fail, since > > user > > > specific data is not accessible to another user. You may need to revise > > > your deployment logic. > > > > > > I hope the information is useful to you. > > > > > > Regards, > > > > > > Felix Wang > > > Microsoft Online Partner Support > > > Get Secure! - www.microsoft.com/security > > > This posting is provided "as is" with no warranties and confers no > rights. > > > > > > > > > > >
I did some further tests:
I removed the MDAC merge module and tried to install the application as a normal user (not even Power User). The installation started but then failed during installation of the Crystal Reports components ("No access rights for C:\Program Files\Common Files"). If I run the setup with Administrator permissions it now works as expected: After logging on as normal user, you can start the application using the icon in the start menu. And this time no Windows installer pops up. However, I'm a little disappointed: - you have to manually install dotnetfx.exe - then you have to manually install mdac_typ.exe - after that you need an MSI based setup (because of the Crystal Reports engine) - and for all that you need Administrator permissions. I thought I heard something about xcopy deployment of .NET apps... Guido "Guido Kraus" <guido@somewhere.com> schrieb im Newsbeitrag news:uXTkIaTKEHA.2456@TK2MSFTNGP12.phx.gbl... [quoted text, click to view] > My setup is very straightforward: I have an .EXE which is installed > into the application folder, a link to this .EXE which is installed into > "User's Program Menu", the MDAC merge module, and the Crystal Report merge > modules which are > included with VS.NET 2003. There are no other files or registry settings. > > If you are logged on as normal user the installation fails during the MDAC > part of the setup. You can successfully install the application with admin > privileges. After that the user can click the application icon in the start > menu but then sees the Windows installer which fails. > > How should I change the setup to get it working with normal users? Should I > leave out the MDAC merge module? If so, can I be sure that the application > will run under any version of Windows NT, 2000, XP? As I understand the > Windows Installer technology was meant to be able to install files even if > you don't have admin access rights. And what is the MDAC merge module good > for if it does not install? > > The only solution I can see is to give the user local administrator > privileges. However, for my customer, this is not acceptable. > > Guido > > > "Felix Wang" <v-felwa@online.microsoft.com> schrieb im Newsbeitrag > news:Ywjh96NKEHA.3088@cpmsftngxa10.phx.gbl... > > Hi Guido, > > > > Thanks for posting. > > > > First of all, it is obvious that we must have admin permission to install > > this application. MDAC is a system level component and only admins are > > allowed to install it. > > > > Secondly, as you mentioned ,after an admin installs the product > > successfully, when a normal user tried to open the application, MSI is > > triggered to repair something. Based on my past experience, this may > happen > > if you have installed some files into user specific folders, like "My > > Documents", "Application Data" or installed something under the "HKCU" > > registry key. > > > > If this is the case, it is natural that the deployment may fail, since > user > > specific data is not accessible to another user. You may need to revise > > your deployment logic. > > > > I hope the information is useful to you. > > > > Regards, > > > > Felix Wang > > Microsoft Online Partner Support > > Get Secure! - www.microsoft.com/security > > This posting is provided "as is" with no warranties and confers no rights. > > > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |