I have MQ V8.0.0.2 installed in my system and I am applying the fix pack to upgrade it to 8.0.0.5 using the silent install method. It runs successfully and finishes but dspmqver still says the version as 8.0.0.2.
It is on a Windows 7 machine 64 bit. The exe file I am using to apply the fix pack is WS-MQ-8.0.0-FP0005.exe.
I am not getting any errors in the command prompt. I followed the installation instructions IBM suggested while downloading the fix pack. I stopped the MQ manager and then ran the command WS-MQ-8.0.0-FP0005.exe -f silent_install.resp
I gave the response file name along with its path. But its still not working.
Update
On a multi-installation setup the update was being applied properly but to a different installation. To fix the problem, run amqicsdn.exe as described in Applying maintenance level updates on IBM MQ servers in the Windows maintenance Tasks section of the Knowledge Center.
amqicsdn MQPINSTALLATIONNAME=name MQPSILENT=1
This invocation sets a pointer to the installation that is to be updated.
The response file tells the installer what to do and what to install. Depending on what is set there, what you are seeing is what would be expected.
Specifically, the MQPREBOOT and MQPINUSEOK parms tell the installer whether or not to continue if a file it needs to update is in use. There are two likely outcomes here.
1) The maintenance was applied correctly but because files were in use it will not show up until after a reboot.
2) The MQPINUSEOK parm told the installer to bail out if the files were in use.
On Windows, even though the QMgr is stopped, the service continues running. Depending on the MQPINUSEOK setting that would either cause the install to fail or to complete pending a reboot.
It is worth noting that installing anything on Windows requires a couple of reboots. The very first thing before running the install or upgrade is to reboot. That ensures that the registry is saved at the current values. It also ensures that if someone else's app has gone rogue with a memory leak or other issue, it gets cleared before your MQ install proceeds.
After the install, reboot again to ensure the registry with the new MQ settings is saved. That's because if the server crashes, you want the last known good registry entry to be the one with your install or upgrade reflected in it. That also ensures the services still start as expected.
Finally, I'm unsure what "the installation instructions IBM suggested while downloading the fix pack" are but the official instructions are in the Knowledge Center section Windows: Applying maintenance level upgrades on IBM MQ servers. Among the other information you will find there is that the location for the installation log is either specified in the response file or defaults to amqicsdn.txt in your TEMP directory (%TEMP%).
Try to stop the Message Queue Manager and then run the installation command again (after modifying the silent response file). If you still face this issue, check if you have a "C:\Program Files\IBM\source\WebSphere MQ 8.0.0.5" folder created and then run the "amqicsdn.exe" file. That should resolve your issue!
Related
We use Erlang OTP because it is bundled with a business application my company uses (as part of a RabbitMQ installation). On our development and test servers, the entire installation went smoothly without any issues. On the production system, however, Erlang OTP installs but fails to launch afterwards. When I doubleclick erl.exe I get an error popup:
The entry point “llround” was not found in the DLL “C:\Program Files (x86)\…\Erlang-21.3\erts-10.3\bin\beam.smp.dll”. (Translated from German, path clipped)
I am completely new to Erlang, so I do not even know whether there are any logs that I should provide. In the Erlang directory, I cannot find anything that looks like a log. The Windows event log shows basically the abovementioned error message plus a message saying that the Erlang VM crashed instantly (wrong distribution name?) – but that seems to be just a follow-up to the root cause of the problem with the DLL.
As I said, erl.exe opens without problems and displays a command prompt when launched on the test or development system. The setup there is almost identical to our production server. We tried removing Erlang and reinstalling it but to no avail. We even restored the VM to an earlier point an did a fresh install of the entire application. Short of setting up another pristine VM, is there any way of getting Erlang to work on the existing system?
I have a c# code that installs rabbitmq on windows machines.
After running rabbitmq-service install and rabbitmq-service start I am running rabbitmq-plugins enable rabbitmq_management.
At the end I get:
set 3 plugins.
Offline change; changes will take effect at broker restart.
I would like to know if I can avoid this restart. It's taking a lot of time and slowing the installation process. I'm pretty sure that at least one time during my tests I wasn't required to do that but I can't reproduce...
You might be running into the issue we are addressing in this pull request:
https://github.com/rabbitmq/rabbitmq-server-release/pull/82
You don't say which version of RabbitMQ or Windows you are using, nor do you say how you are installing RabbitMQ - are you using the .exe install package or the .zip package? This is all very important information to share when you ask questions about RabbitMQ (or any software, really).
When you install RabbitMQ and start it for the first time, Erlang will create cookie files. You can read this document to see where these files are created - it depends on your version of Windows and Erlang (which is why I need to know both!).
When you run commands like rabbitmqctl.bat or rabbitmq-plugins.bat, the cookie is read to establish a connection to RabbitMQ. If the cookie file in your user's home directory does not match the cookie being used by the server, you will see an "offline change" being made.
What you should do if you are using either the .exe installer or the .zip installer is, after RabbitMQ starts, be sure to copy the .erlang.cookie file from where RabbitMQ is reading it (most likely C:\WINDOWS\system32\config\systemprofile\.erlang.cookie) to your user's home directory (C:\Users\my-account\.erlang.cookie).
Then, run rabbitmq-plugins.bat enable rabbitmq_management and the plugin will be enabled at run-time.
An alternative is to pre-create the enabled_plugins file and save it to %AppData%\RabbitMQ\enabled_plugins before starting RabbitMQ the first time. %AppData% is the application directory of the admin user account you're using to install and start / stop RabbitMQ.
To enable the management plugin, that file should contain the following text:
[rabbitmq_management].
Let me know how it goes, thanks.
The RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
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.
I had a program that starts up a Windows Service when installed and deleted that Windows Service when uninstalled. However it refused to uninstall after I modified the installer by accident (my fault!). I couldn't even remove it from Programs and Features as it kept throwing an error 2715. I found this article that had a FixIt program: https://support.microsoft.com/en-us/mats/program_install_and_uninstall
Using that, I managed to finally remove the program itself. Now however, when I try installing and uninstalling it again (to test my changes), the Windows Service that's attached doesn't get removed. In fact, it continues running. I checked the registry and indeed the key for the service is still there after the uninstall. I would need to manually stop it and do a sc delete to get rid of it. Any idea on how I can solve this?
Edit: I am able to replicate the issue on another computer. What I do is, I install the program there, and use the Fix It tool to remove it. Once this is done, I can easily replicate the issue as the service is never deleted after uninstalling. It works fine prior to this.
Some guesswork here because there's not enough info....
Eroor 2715 is a Windows Installer error, and I suspect it's related to you running a program (as you describe it) to start and stop services. I'm guessing that you run it as a cuatom action, and on uninstall you attempt to run it but it's missing because it's been uininstalled.
So:
That fixit cure is not for a broken MSI (which yours is) - it's for fixing corrupt registry data that prevents uninstall, not fixing a broken MSI uninstall.
You don't need to run code to start and stop and delete services. Most MSI-building tools have support to the the Windows Installer functionalty that does this for you, so stop doing it!
A more specific answer is difficult without knowing what you are using to build your MSI with, and how you're running your program, but the signs point to you running the program after it's been removed, and even if you get the program running properly there's no way to tell whether it is correct without seeing the code. But 2 is what you should be doing anyway.
I have an application (Installed as a service) that has 5 different versions. For testing I need to have all 5 installed. Currently I have to uninstall the application and reinstall the required version.
The application has a single exe (in Program Files\App) along some an xml file containing it's settings. This is installed via an MSI file. Each version has the same file\service name and checks for previous versions before installing.
Any ideas on a way to run all five versions at the same time?
First of all, I assume you're a developer, not the QA person. The QA need to use either virtual machines, or just 5 separate PCs. What I'm describing is a dirty hack that might save you some time.
Install version #1 to C:\program files\YourApp_1
Launch services.msc, stop the service, change the startup type to manual.
Launch regedit.exe.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services key, find the key for your service, rename the service: change both the key name, the "DisplayName" value, and to simplify your life write something meaningful to the "Description" value, e.g. "MyApp 1.0 - this is the reference version".
If the installer checks some other keys before installing (it might be e.g. in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\YourApp), remove them. If you don't know those keys - use SysInternals ProcessMonitor to get them (set filter to instmsiw.exe or something, then launch the installer, wait for the "the prevoius version was found" message, alt-tab to the ProcessMonitor, stop logging, and read the log bottom-to-top)
Now install version #2 to C:\program files\YourApp_2, repeat the process.
At the end, to switch versions you'll only need to launch services.msc, stop the version that's currently running, start another one. Or use net start / net stop command line commands. Or whatever.
P.S. Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Though this is more of a Sever Fault type of question:
http://www.microsoft.com/windows/virtual-pc/
There's yer answer :-)
Use virtual machines for each of your 5 different versions.
VMWare player is free: http://www.vmware.com/products/player/
Use VirtualBox.
Create one test system, configure it, then clone it 5 times (you'll have to use vboxmanage), and install one version on each of them.
If it wasn't a service, I had suggested Sandboxie, but I doubt that Sandboxie can handle services.