We have a windows service installed as a part of our msi WIX installer . During upgrade we are trying to just restart service instead of doing complete reinstall to safe guard the service user creds.
A lot of posts discussed in this regard but nothing is conclusive.
Tried out disabling DeleteServices during upgrade by doing below,
<InstallExecuteSequence>
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
</InstallExecuteSequence>
Note: The above code is in old MSI as well
But still saw service getting actually deleted and reinstalled. Tried disabling installservice during upgrade as below
<InstallServices>NOT WIX_UPGRADE_DETECTED</InstallServices>
But service is in stopped state and installer fails in action, ExecServiceConfig with code 1603 since service is not in running state.
Any pointers on this will be helpful
I wrote an answer for something similar (I think) a while back: Wix: Windows Service sometimes uninstalled when upgrading. Please read that link for several, different suggestions.
Minor Upgrade: In addition to the options in the linked answer, you can use a minor upgrade as well - if that is at all a viable option. In a minor upgrade the product is not uninstalled and then reinstalled, but rather upgraded "in-place". For minor upgrades to work you need to follow the component rules to the letter - which can be hard to do, but you can then definitely upgrade without losing your service creds. See bottom here for how a minor upgrade is applied. And I will just link to an answer with a little bit of info on late REP.
Permanent Component: As the linked answer above states, you can set the component with the service configuration settings to be permanent. In this case it will never be uninstalled during upgrade, but not during a real uninstall either. Accordingly you have to manually clean out the service installation and file installation on "real" uninstall (as opposed to a major upgrade initiated uninstall which sets UPGRADINGPRODUCTCODE). Sort of an easy approach that I don't really like that much.
(Managed) Service Accounts: Not something I have used, but the newer concept of managed service accounts as described in the above, linked answer could be investigated? Step-by-step.
Late REP / Service MSI: Scheduling RemoveExistingProducts correctly late means your service should not be uninstalled during upgrade scenarios (see the linked answer for details). It can be hard to follow all component rules to the letter, but you can ease that by putting your service in its own, minimal service installation MSI, and then installing via a WiX Burn bundle (installing MSI files in sequence).
As stated several times, please do read this similar answer: Wix: Windows Service sometimes uninstalled when upgrading.
Related
I have ES 7.10.2 installed as a service in W10.
Looking at some very cursory notes I seem to have made, I installed this by going
...\bin>elasticsearch-service.bat install
So I just downloaded the .zip for 7.16.3 (please don't ask why I don't yet want to move to 8!).
I stopped the existing 7.10.2 service, which is called "elasticsearch-service-x64"
In the unzipped 7.16.3 directory I went
...\bin> elasticsearch-service.bat install
I get a screen saying "do you want to do this as admin" --> Yes
I get the following failure:
D:\apps\ElasticSearch\elasticsearch-7.16.3\bin>elasticsearch-service.bat install Installing service : "elasticsearch-service-x64" Using ES_JAVA_HOME (64-bit): "D:\apps\ElasticSearch\elasticsearch-7.16.3\jdk" -Des.networkaddress.cache.ttl=60;-Des.networkaddress.cache.negative.ttl=10;-XX:+AlwaysPreTouch;-Xss1m;-Djava.awt.headless=true;-Dfile.encoding=UTF-8;-Djna.nosys=true;-XX:-OmitStackTraceInFastThrow;-XX:+ShowCodeDetailsInExceptionMessages;-Dio.netty.noUnsafe=true;-Dio.netty.noKeySetOptimization=true;-Dio.netty.recycler.maxCapacityPerThread=0;-Dio.netty.allocator.numDirectArenas=0;-Dlog4j.shutdownHookEnabled=false;-Dlog4j2.disable.jmx=true;-Dlog4j2.formatMsgNoLookups=true;-Djava.locale.providers=SPI,COMPAT;--add-opens=java.base/java.io=ALL-UNNAMED;-Xms1g;-Xmx1g;-XX:+UseG1GC;-XX:G1ReservePercent=25;-XX:InitiatingHeapOccupancyPercent=30;-Djava.io.tmpdir=C:\Users\Chris\AppData\Local\Temp\elasticsearch;-XX:+HeapDumpOnOutOfMemoryError;-XX:HeapDumpPath=data;-XX:ErrorFile=logs/hs_err_pid%p.log;-Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m;-XX:MaxDirectMemorySize=536870912;-XX:G1HeapRegionSize=4m
Failed installing 'elasticsearch-service-x64' service
yup, NOTHING ELSE. Spectacularly informative. To be fair, there may be some log output somewhere... But I have obviously have no idea where I might find that.
In a way I am not surprised that this failed to be installed, as there is already an existing service called "elasticsearch-service-x64", and just because it is stopped this wouldn't stop installing a new one with the same name being a problem. Can we install ES with a custom name??? (such as "elasticsearch-service-7.16.3"? Oh how helpful that might be).
But I am EXTREMELY nervous about, for example, uninstalling/deleting the present ES service 7.10.2, which does at least work. I am far from convinced that re-installing it would be trivial.
This time I intend to make many many more notes.
Has anyone had this experience? What do I do?
Anyone else ever wanting to upgrade this:
All the following was done in W10 as Admin:
I wondered if it was possible to change the path to the executable. Found this.
I stopped the ES service. Then I did this:
sc config elasticsearch-service-x64 binPath= "D:\...\elasticsearch-7.16.3\bin\bin\elasticsearch-service-x64.exe"
This said "success". The W10 "Services" dialog showed that the "path to executable" had indeed been changed.
But the service wouldn't start.
Then I tried to switch back to 7.10.2 using the above method. Again it wouldn't start. At least this meant I had no choice but to uninstall and reinstall, which is what I did:
sc delete elasticsearch-service-x64
In the 7.16.3 bin directory:
...>elasticsearch-service.bat install
... success! 7.16.3 installed as service elasticsearch-service-x64. Also starts.
My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
Thank you in advance for considering this question. If a similar question existed, I was unable to find it.
The Issue: Our company packages an application into an MSI. This MSI when installed outside of any GPO properly updates, blocks attempts to downgrade (or move from a higher revision to a lower revision), and never has trouble uninstalling previous versions of the application regardless of how long ago those versions were created/installed. For example, we can install version 1.2.3 and then install version 2.3.4 and the application will properly install without issue. However, we work with a customer who uses GPO to deploy our application to hundreds of PC's. Each time we have provided an updated version of the application the following has been indicated:
On any machine where a previous version of our application was installed via GPO, no matter what the previous version is, the update successfully installs without issue.
On a machine where the application was manually installed (outside of the GPO), and an attempt to update the application via GPO is made - either the application is installed in addition to the old version, OR there remain registry keys to the previous version of the application and the application cannot open/run correctly. In this case the registry keys must be manually removed, and the install is then attempted again from a clean machine.
What we know is that on any machine where the application was originally installed via GPO - updating the application is no problem. On every machine where the application was not installed with the GPO in the first place, updating via GPO fails with one of the problems presented above.
My question is: Is there a technical issue with how the installation is being handled partially through the GPO and partially outside? Does the GPO need to be responsible for the entire life-cycle of the application? OR is it a reasonable expectation that the application be updated both on machines where the original version was manually (outside the GPO ) installed, and when it was installed initially from within the GPO?
One solution we are aware of is simply having all computers manage the application life-cycle (since we know updates work in that environment already), however this would mean that many computers would need to have the manually installed versions removed by hand - and then properly handle the installation through GPO which is an extensive bit of work.
We would greatly welcome any solutions, references to technical documentation that formally shed light on the proper management or expectations here, or links to information. Our research suggests that it is "best" to manage the entire applications life-cycle inside the GPO - but I have as of yet been unable to determine that it is 100% necessary to do so.
Looking forward to any assistance. If any further technical details are required to help the viability of the question, please don't hesitate to request such details.
If you end up with two versions installed in Control Panel, then all other things being correct, the most likely explanation is that you upgraded a per user install with a per machine install (or vice versa). In the GPO world that's related to assigning it to a user or to the computer, something like that. That's easy to verify by getting a verbose log and checking the FindRelatedProducts actions for an indication that another product was found but in a different context.
When you're in GPO mode all the time, I assume each one (whether it's per user or per machine) is consistent, therefore upgrades always work, but they don't work cross-context.
I believe GPO suppresses the UI in most cases, and the UI (or the UI sequence) is sometimes where per user/per machine is set. That might be something else that would cause it, depending on how the GPO publishes to the computer or the user.
We are experiencing a difficult problem which has been puzzling us for some time. We have two MSI setup files containing COM+ components and GUI respectively. The applications in both are written in VB6.
After a lot of testing we have arrived at this:
Application initially installed: Works.
Application uninstalled, new version installed: Does not work.
New application uninstalled, old application installed again (should work): Does not work.
The components are installed on Windows Vista clients, initially by Active Directory deployment, but testing is done by removing that deployment from AD, manually uninstalling and manually installing.
With “Does not work” I mean: Unable to complete a transaction. It seems to be a timeout on anything between 200 and 445 seconds. The GUI application is using the COM+ components to DTC to a server witch a MSSQL database.
Now why am I posting such a specific error? I'm looking for information regarding:
Any Windows Update update of MSDTC / COM+ the past year that could affect new installations.
This may be a common problem that others have a hint to what could be causing it.
Is there a COM+ cleanup utility to remove "old junk"?
Could this be a result of how Windows Vista handles the old "dll-hell" problem, that the new version introduces a new shared file?
Could it be something with versioning on components? (We have hundreds of them, difficult to say)
Ok, weird.
It seems installing SQL Native Client and opening for DTS in the local firewall solved the problem. The problem was actually that the SQLOLEDB provider seemed to break when reinstalling the application. This was not the case 1 year ago with the same executable, so something could have been changed on the network or by windows update.
As most of you probably noticed, when uninstalling an MSI package Windows will ask for the original .msi file. Why is that?
I can only see disadvantages to that:
not resilient to network changes.
not resilient to local disk changes.
unexpected by users.
typically requires users to leave their desk and start a crusade to get the correct CD.
kind of proves installations are not self-contained.
promotes the use of unsafe tools such as msizap.
which in turn promotes the "next time I'll just use a zip file" mentality.
Could someone shed some light on this?
Fix Broken Uninstall: You can try the newest FixIt Uninstall tool from Microsoft if you have problems uninstalling an MSI. And one more link: Uninstalling an MSI file from the command line without using msiexec (a plethora of different ways to uninstall an MSI).
UPDATE:
This new support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall (rather than the outdated, deprecated, unsupported msizap.exe).
Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know. Feedback in that answer indicates that it works (I don't have any stuck setups to test with as of now).
Why are you asked for the original installation media?:
The original MSI is not needed for uninstall unless the MSI itself is badly designed - or the cached MSI is missing (see details below).
All installed MSI files are cached in %SystemRoot%\Installer\*.* using a random hex name.
The cached MSI file is used for any maintenance, repair and uninstall operations - and it is sufficient for uninstall in the vast majority of cases.
In some cases this cached file can be missing, and then uninstall is not possible at all in some cases (some theories as to why this can happen - MSI design errors, anti-virus quarantining, system restore, tinkering, developer system in erroneous state from development work, etc...). See more info below - and links to force uninstall or unregistration of the product.
The original source is only needed if files need to be copied to disk (for a maintenance install), or the MSI does an explicit request to resolve the original source via the standard action ResolveSource or via a custom action (which shouldn't be done in a properly authored package - I think the MS Office package contained this ResolveSource error back in the day, causing everyone to go looking for their installation CDs/DVDs).
In previous editions of Windows this cached MSI was stripped of all cabs, and hence contained the installer structure only, and no files.
Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature which affects the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). Check this article and especially the discussion at the bottom for more intel.
To prevent caching a huge MSI file, you can run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it. Note that this may yield a UAC prompt is some cases since the extracted MSI file is no longer signed - this must be tested with your SOE / desktop configuration.
Read my answer in this thread for the full description of admin installs: What is the purpose of administrative installation initiated using msiexec /a? or this similar but perhaps more accessible answer: admin install and its uses
In some rare cases the cached MSI (with the random name) can be erroneously missing, and uninstall will then ask for the original MSI in order to complete the uninstall. This does not happen often. It used to be the case that one could use MsiZap.exe to clean out such an install, but this tool is outdated, deprecated and unsupported. Don't use it - there are too many incompatibilities with newer Windows versions and you create new problems. Perhaps try this support tool instead (also deprecated). The only option I can suggest now is this answer from saschabeaumont. If you try this tool, please let us know if it works for you. If you want to figure out what could have caused the cached MSI to be missing, try to read section 12 here: Uninstalling an MSI file from the command line without using msiexec (in short potential causes range from interference with system restore, anti virus and cleanup scripts, to erronous manual tweaking, low disk space, power outages, developer box debugging errors, badly designed MSI files with duplicate package codes, failed patches, etc... Many theories, few certainties I am afraid).
As a last resort you can try system restore (unless it has been disabled entirely or partly) to go back to a previous installation state and see if this solves your uninstall problem (you can find video demos of this on youtube or a similar site).
Be aware that system restore might affect Windows Update that must then be re-applied - as well as many other system settings. I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun, it's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems and such issues. The longer you go back the more rework you will create for yourself. A lot of self-evident stuff, but I guess it needs to be mentioned.
Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs. This will do nothing to fix your failing uninstall though (or I would be very surprised).
Related answer:
Uninstall without an MSI file
In addition to this answer, perhaps this article on various ways of uninstalling MSI packages is of interest. It is a rather popular article with a high number of views:
Uninstalling an MSI file from the command line without using msiexec.
There are a few reasons for keeping the original msi:
The uninstaller uses it to know what files and registry keys were installed and make sure they are all cleaned up.
The msi may contain special uninstall actions that need to be performed.
It allows you do to a 'repair' operation from the Add/Remove Programs menu, regardless of whether or not you saved the install file yourself.
The normal way of things is for Windows to keep the file cached for you, so you don't have to think about it. See your %WINDIR%\Installer\ folder. The only reason it would ask your for the original msi is if something is wrong with the saved file. This addresses most of your concerns, though it does raise a new one (disk-space).