Requires admin privileges for setup
I found a question about the same problem as installshield 2012 , but my problem with installshield 2015 and Solutions in the answer are not compatible with installshield 2015
I hope you understand the repetition
so
I'm trying to package application. I used install shield 2015 and I have created the setup file. When I try running the setup file it keeps throwing this error code
1925: it needs admin privileges to run the setup.
How do I configure the setup file to be run by any user? Should I make any changes in the registry during the creation of setup file in install shield? Is there anyway to work around this problem?
As suggested, first determine whether your setup or msi should be installed with admin rights. If it doesn't need admin rights:
Set "Require Administrative Privileges" to No for the Summary Information Stream setting under General Information.
Go to your release configuration under Releases. Select the setup.exe tab and select the Required Execution Level to Invoker.
Related
I was trying to uninstall TFS 217 update 3.1 going through the control panel ->uninstall a program . When I click on TFS 2017 update 3.1 I am getting only change option not getting uninstall option. How to uninstall ?
We do not uninstall TFS server from control panel--Programs and Features. Use the unconfigure instead, it's similar to the way we usually uninstall other software.
To "Unconfigure TFS", please go to the Team Foundation Administration Console on the Application Tier machine. Click on the server name and click on "Remove Feature"
By Removing the feature, we will be removing
The Application Tier configuration from the server (but we don't
remove the binaries)
Connection with Data tier (but the databases won’t be deleted)
TFS Website.
TFS Application Pools
TFS Services (The Visual Studio Team Foundation Server Job Agent)
You can do the same from command prompt, execute TfsConfig setup /uninstall:ApplicationTier command to unconfigure TFS Application Tier. (You can also use various switches to remove other features SharePointExtensions, TeamBuild and VersionControlP
roxy) from server machine.
Usually we'd like to refresh the TFS Application Tier setup to defaults in case there's an unintended change in services/IIS settings and we want to set it back to defaults. We give an option to Remove Application Tier/Features without having to uninstall the complete application.
Another usage is when you are using pre-upgrade for test, you could quickly remove Application Tier. Since everything have been migrated, if you don't need the TFS server any more, just simply uninstall the complete application and database.You could back up your database, once you want to use again. Just install a new application and restore your database.
Hope this helps.
I'm trying to get Dotfuscator Pro 4.13 to run between the unit tests and creation of installation package. The buildserver that we use is Jenkins 1.487 on Windows Server 2008 R2.
The command line for dotfuscator is very simple, i use /q and point out an xml configuration file. it works like a charm when i manually run the exact command from the commandline.
But when the same commands are executed by Jenkins the following error is logged:
Use of this software implies acceptance of accompanying license
agreement.
LICENSED TO:
SERIAL #:
You must first accept the end user license agreement before using Dotfuscator.
For some reason Dotfuscator cant read the licensing information when it's ran by Jenkins. I cant find any information about this but something tells me that this is related to the user that Jenkins is executed under. What am i missing?
As i thought it was something user related. this problem comes from that the user the Jenkins job is ran under has never accepted the Dotfuscator user agreement. There are two ways to resolve this:
Either you log into the machine with the user that is running the automated build and launch the Dotfuscator GUI and accept the license agreement
Or you can copy the following files:
C:\Users{user that installed/accepted agreement}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dfusrprf.xml
C:\Users{user that installed/accepted agreement}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.cfg
C:\ProgramData\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.dat
into the installation directory of dotfuscator (default is C:\Program Files (x86)\PreEmptive Solutions\Dotfuscator Professional Edition 4.13.0).
I had a similar problem using Team Foundation Build Service running under Windows Server 2012.
According to Dotfuscator's tech support:
To resolve this you will need to move the following files:
C:\Users{User that installed dotfuscator}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dfusrprf.xml
C:\Users{User that installed dotfuscator}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.cfg
Into the same folder on the user account that is running the automated build.
I was running my build service under NT AUTHORITY\NETWORK SERVICE. After some searching I found their home directories:
%systemroot%\ServiceProfiles\NetworkService
which usually translates as:
c:\Windows\ServiceProfiles\NetworkService
I am using Advanced Installer and would like to know where do I configure when it needs to take the Installation process and when it need to take the Maintenance process. I am not sure if it is configurable. If not I would like to know how Windows decides which process to perform. help is very appreciated.
There is no need to configure that, the packages created by Advanced Installer know exactly when to go to install or maintenance phase, this is controlled by Windows Installer on each machine where you install the package. Try the simple installation tutorial to see how it works.
Basically, each package has guide, the product code, that is registered on the system by Windows Installer when you run it first and install your app. The second time you launch the same MSI Windows Installer will see the product code is registered as installed and automatically enter maintenance, showing the appropriate dialogs.
If you don't want a package to be enter maintenance phase, i.e. run only the install phase (every time you launch it) just go to Product Details page in your project and untick the option "Register product with Windows Installer".
I've an Installer with some custom actions & the designer fancy to install a windows service.
From times to times, when I made a mistake in my custom actions (or in the MSI configuration) the upgrade process may fail. Solution is to uninstall the Application and do a fresh installation.
But sometimes I'm ending in the situation, where I can't uninstall the Application because the "custom actions" for the service claims, that the service is not registered in the system. OK, maybe, no problem. I'm uninstalling the App. The problem: my app don't get uninstalled. It remains. I have to manually add the service to the registry again and restart the uninstall process.
Question: What do I have to configure/develop/program/etc. to tell the service (un)installer not to fail during uninstall when the service is already removed.
BTW: My custom actions do NOTHING during uninstallation. Only during installation/upgrade, I'm asking the user for some configuration and do some custom config stuff - only related to my app. Not related to the service.
EDIT: forgot to mention: VS 2008, default installer project, no fancy stuff, target machine is Windows XP
Yeah, that's one of the many reasons I say not to use VDPROJ and InstallUtil custom actions. You need to put a try catch block in your uninstall custom action and handle that scenario.
Hopefully you are testing on a VM and can just revert but in case this is your dev box use the Windows SC command to recreate the service so you can get the uninstall to work for now.
If you really want to do this right, you want to do something like this:
Augmenting InstallShield using Windows Installer XML - Windows Services
The same concept applies you'll just be adding the WiX merge module to your VDPROJ installer.
I'm using WiX to write a MSI installer to start a service that depends on DLLs installed by the MSI. On Vista, the DLLs become added to the global assembly cache in the MSI's InstallFinalize phase, so I can't use the built-in service starting command in WiX. That one tries to start the service before the DLLs are in the GAC, and fails. The solution seems to be to use a custom action instead [1], and run that after InstallFinalize.
The custom action I used was starting the service with sc. Everything works fine when running the installer as an administrator, but running as a regular user doesn't work. The installer will elevate privileges for the actual install phase, but will drop them after finalizing the installation, and starting the service with sc as a non-privileged user will fail. Setting the custom action to be deferred and no-impersonate to get admin privileges won't work either after InstallFinalize [2].
As a final kludge, I tried to add <Condition>Privileged</Condition> to the WiX file to tell the user that the installer needs to be run as Administrator, but I couldn't get that to work either. The Privileged value gets set to 1 during the installation, maybe when the main install sequence is given higher privileges.
So has anyone else ran into the combination of Vista, non-Administrator user, installer needs to start a service and service needs stuff that goes into GAC during installation to run? Is there any kind of working general approach to this?
[1] http://www.mail-archive.com/wix-users#lists.sourceforge.net/msg09162.html
[2] http://www.mail-archive.com/wix-users#lists.sourceforge.net/msg15381.html
This is one of those times when the easiest solution is just to schedule a reboot.
Here are a few possibilities :
If possible, do not install prerequisite assemblies in the GAC. This will allow your service to be started normally (ie between InstallInitialize and InstallFinalize).
Create a bootstrapper (a small app that launches prerequisite MSIs in a certain order). Place the prerequisite assemblies (those that go in the GAC) into their own MSI, and get the bootstrapper to install them before it installs your service.
Create a launcher (an even smaller app that just launches your MSI). Give it a manifest that will make it run elevated. That way, the entire MSI is elevated, not just the part that's between InstallInitialize and InstallFinalize. You should be able to invoke sc succesfully.
I agree with #sascha. Rebooting is not just the easiest but cleanest in this case. All of the other proposed solutions are going to set you up for a much higher failure rate in the future. IMHO, the Windows Installer design w.r.t. the GAC is busted. The reboot is recognition of that.