I'm creating a custom action that executes a script on a database. The problem is that the connectios uses intergrated security, so when I try to open the connection i get the error: Login Failed for user 'Domain\ComputerName$'.
When i check the identity on the custom action (using System.Security.Principal.WindowsIdentity.GetCurrent()) I always get "NT AUTHORITY\SYSTEM"
but I'm running the installer under my account which has enough privileges on the Database.
How can I run the custom action under the real user runnig the msi file or solve this problem in any other way?
Well, there's a simple solutions for this but maybe it's not suitable for all cases.
If you set the project property of InstallAllUsers
To true, the installer runs with "NT AUTHORITY\SYSTEM" Account, but if you set it to false it runs with the identity of the user who launches the installer.
Setting it to false worked for me, even that I was installing a Windows Service that runs for all users.
The short answer is that you're going to need to
Enable 'impersonation' for the custom action.
(On Windows Vista and Windows 7 systems) run the entire installation in an 'elevated' context (i.e. 'Run as Administrator').
How you accomplish #1 depends on what you are using to create the installation package. In order to easily deal with #2, I use a bootstrapper (created with Bootstrapper Manifest Generator) that is configured to run 'elevated'.
Related
I'm having a hard time trying to figure out what is causing this odd issue.
So I've created a very basic .msi by following the WiX v3 Setup Project documentation, pretty much just the provided template, but no matter what i try, whenever i go to uninstall it via the Windows 10 Apps & Features interface, i keep getting this:
However, when i uninstall via Control Panel\Programs\Programs and Features or by right-clicking and hitting Uninstall in the .msi's Context Menu, it uninstalls fine.
What am i missing here, should i be implementing something within the installer project to support the Apps & Features uninstall?
Thanks in advance.
AVG Anti Virus: In this case it was AVG anti virus. Uninstalling this product made the uninstall run correctly when
invoked from the new settings GUI in Windows 10.
Blocking: Errors like these often mean something is blocking the uninstall. Please disable or uninstall any anti-virus and / or security software and try again.
General Check List: Please check this answer for a "deployment check list" or "mnemonic" to debug similar problems: Deployment Mnemonic (mid-page). Also see comments above. Sweep for malware with Windows Defender Offline.
Microsoft Tips: Windows cannot access the specified device, path, or file...
Make Log File: To debug, always make an MSI log file:
FireGiant: MSI log "how-to"
Installsite: MSI log "how-to"
Exact Error Message: "Error: Windows cannot access the specified device, path, or file. You may not have the appropriate permission to access the item"
I have a project in c# which requires auto update functionality, since it has quite a lot of dependencies and runs a Windows service, ClickOnce installer is not suitable for this work. So I created a setup project for this application. Now I want to include an auto update feature.
My auto-update strategy is:
From the main application, check for updates every morning.
If an update is found, get the msi link
Application passes control to the msiexec and quits
Ex.
msiexec /i http://www.example.com/share/package.msi /L*V "C:\log\example.log"
Since my application is running on administrator account UAC prompt will not occur.
Are there any pitfalls that I haven't seen? Or there any superior way to do auto update gracefully?
Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions.
A couple of comments/answers:
"Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions."
But only if you increment the Version property of the setup project, accept the change in ProductCode, keep the UpgradeCode the same, ensure that the value of EveryOne or Just me is the same in the older product and the upgrade, and increase the file versions of files you need to update.
It's also not obvious to me that you won't get a UAC prompt because "running on an administrator account" does not mean the same as "running with administrator privilege". If the running process is not running elevated a prompt will occur, because UAC means that even administrators are running limited unless explicitly elevated. Even if you are elevated, calling msiexec as an external shell call will not result in msiexec being elevated. A shell execute does not transfer privilege to the offspring process. The other thing to consider is whether it's the current interactive user that is effectively doing this update, because there may be an issue trying to show UI if another user owns the desktop.
Anyway in general it's ok to do that, it's quite common, and signing the MSI would be more secure. Also, Windows Installer will sometimes prompt a repair, so that install URL needs to remain valid. A better approach would be for you to download the MSI to a location on the client system that you own and prompt the user to run it, or you run it - it's more friendly to offer that than pull the rug out and just do it.
I have an MSI installer, which have my custom installer project output and I added an exe file to run while installation.
So my MSI setup file will copy or remove files from source location and my custom GUI will install my window server call some server api's and updated its logon credentials etc stuff.
Copying and removing is of files is controlled by MSI on its action as its added as output for MSI project. If I am installing its will copy files or if I uninstall it will remove files.
Now I have below problems -
1) Now if I will go to control panel and try to uninstall my application and later from GUI if I abort it, my GUI will abort but MSI will clear all files.
2) If I will select uninstall and further from GUI, select repair. It will still remove files.
So my installer is not real custom installer, its just namesake one.
Now how can I quick fix above two options?
And is there any better approach to do this task - > my original question create single click msi file of custom installer of an application ?
Thanks in advance
It sounds like you are trying to do things at the wrong time. In any installation system you should gather all user input up front and then once the installation itself starts there should be no further requirement for user input until everything is done.
The easiest way to ensure integrity is to only let the user cancel during the UI gathering phase, not the installing phase. If you do want to let the user cancel during the install phase, you have to pass that on to the underlying engine so that it knows to cancel and rollback any changes made thus far.
It seems to me that you need to set proper conditions for your actions like one that initiates your exe-file execution. Try setting something like "Not installed" so that it would occur only during initial installation but not during remove/repair or upgrade.
I have a C# application, and a Visual Studio (2010) Setup Project with it. In my Setup Project, I am using InstallAllUsers = True. Additionally, my application needs to launch at Startup, so a shortcut is being added to the User's Startup Folder.
So I install my application as user Bob (from a share), and then I log off and log on as user Alice. Alice gets a dialogue that says:
The feature you are trying to use is on a network resource that is unavailable.
It provides the network path from which the MSI was installed. So, basically, it's looking for the MSI on a share that Alice doesn't have access to. This is repeatedly reproducible if Alice tries to manually launch the Startup link. However, Alice can directly launch the exe from the installation location, which works fine.
I don't fully understand why it is looking for an MSI, but I guess it makes sense that an application can not be completely installed by one user for another user, so the MSI is needed to complete the installation.
But if that is the case, then I don't understand why the MSI only seems to be required when launching from the Startup link, and not from the exe directly.
My question has several parts:
Is what I am experiencing expected behaviour for the InstallAllUsers option?
If so, how can I ensure that my application is fully installed for all users?
Is it necessary to copy the msi locally, and ensure that it does not get deleted before each user has had a chance to log on?
This is happening because the shortcuts are "advertised shortcuts" hence the greyed out target box.
More info here...
http://www.advancedinstaller.com/user-guide/advertised-shortcuts.html
When an advertised shortcut is launched it validates the checks
associated with the key resources. If any is missing it will fix it by
running the installation package and installing again all information
from the .msi file.
This is why its trying to run the msi.
You can turn off advertised shortcuts by reading this article...
DISABLEADVTSHORTCUTS=1 disables all shortcuts
If its an all users install, then the shortcut will probably want to reside in the all users start menu. Win 7: C:\ProgramData\Microsoft\Windows\Start Menu.
Eric, I would recommend taking a look at the shortcut file contents. You can do this by using Powershell, and there is a SO link to help you on your way:
Editing shortcut (.lnk) properties with Powershell
I need to get the username of the user running the installer for my custom install action. Because the installer gets special priviledges, Environment.UserName just gives "SYSTEM".
Environment.SpecialFolders.ApplicationData returns the current users appdata folder, but I can't reliably dig the username out of it.
More case specifics:
Using a Visual Studio 2008 Setup Project
The custom action is an installer class run after install and is the only one in the project.
You can get some information from Environment variables. I am using
Environment.GetEnvironmentVariable("USERNAME");
to get current user name.
Basically, you can't.
UAC in MSI Notes: Credential Prompt and Permissions explains some of this is more detail, but effectively once you've elevated your credentials the currently logged in user is SYSTEM from the installers point of view (you can have multiple people logged in and running applications on a machine, so you have to think from the context of the process itself rather than who is sitting in front of the physical machine).
Use WindowsIdentity.GetCurrent().Name from the System.Security.Principal namespace. This will include the domain portion as well so if you don't need that add a split to the end of it. WindowsIdentity.GetCurrent().Name.Split('')[1].
using System.Security.Principal;
this.nametext = WindowsIdentity.GetCurrent().Name.Split('')[1];
First, make sure you have the Impersonate bit set to OFF. Here is how.
Unfortunately, there is not a way to
directly set this flag for a custom
action in the UI for the setup project
in the Visual Studio IDE. In Visual
Studio 2005, you can use a post-build
step that modifies the MSI to set this
bit using a strategy previously
described in this blog post.
Second, I assume you are running Vista because people seem to have this problem with Vista and someone asked this question on MSDN and his solution was to follow the blog post linked here.
Robert Flaming's Blog post on UAC in MSI Notes: The NoImpersonate Bit Mistake also gives some insight into these issues.
I've never touched VS setup projects (played with WiX though and can recommend it). Looking at your problem it seems that your CA runs deferred (and with elevated privileges).
Searching the net for VS setup projects I came across a lengthy article 1 that contained this paragraph (search for "deferred"):
In other words, the Visual Studio design restricts you to custom actions that are called when your files are on the system (deferred custom actions), which means that you must use the CustomActionData property. Other tools that generate MSI files are often more flexible, so if you anticipate complex setups, investigate those tools.
1: http://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup---projects-and-custom-actions/