JSS 9.3 installation error on Windows Server

[flammable]

Hey all -

We're running our JSS on Windows Server 2008 r2. I went to upgrade our installation from the previous version, and I got this error multiple times:

external image link

Any ideas? It looks like this might be a problem with the MSI installer, but I'm not 100% sure.

[ericjboyd]

We have issues with tomcat not actually stoping when using the installer. Sometimes manually stopping tomcat (and waiting for it to really stop) then launching the installer.

[MarcosMunoz]

The following process worked for me:

1. Stop the Tomcat service
2. Delete the following environmental variables: a. JAVA_HOME b. JRE_HOME c. JSS_HOME
3. Rename the JSS folder in "C:Program Files"
4. Launch a command window as admin and install the new version using the following: msiexec.exe /i "location of MSI installer fileJSS Installer.msi"
5. Follow the prompts and start the Tomcat service in the end

Good luck

[Lewandowski]

I haven't been able to get this installation to complete. I've had a few problems previously, but manually stopping Tomcat and ensuring it is stopped resolved it. After the installation fails, if you try to manually restart the Tomcat service, it advises that it cannot find the service to restart it.

Any other ideas other than the workflow above?

[were_wulff]

@Lewandowski

These are the usual steps I go through, both on my test machines and in live environments, when the Windows installer gets a little squirrely.

1) Take a backup, and save it somewhere other than the default location; usually the desktop is fine.

2) Make sure we are logged in as a local administrator. Download the Windows installer from JAMF Nation, and extract the JSS Installer.msi file to either the Desktop or to the root of the C drive. AD Administrator/Domain Administrator accounts should work, but I've had the best luck, in cases when the installer is grumbling about something, to go with a local admin account.

3) Temporarily disable ALL antivirus/antimalware/firewall/web filter software, both from the tray and from within services.
Having any of the above running is one big reason Windows installers fail to complete; they take issue with the ROOT.war file we use and flag it as malware, which kills the installer.

4) Stop the Tomcat service manually. Not stopping Tomcat prior to running the installer is the #2 reason the installer fails. While the installer is supposed to take care of that on its own, if Windows takes longer than is specified in the installer to actually stop the Tomcat service, Windows tries to move/replace files that are still in use, and the installer fails. It will show up as Apache Tomcat in Services.

5) From Program FilesJSSTomcat, copy the TomcatSSLKeystore to a different location. We usually just place a copy on the desktop.

6) If we're using a third party certificate, there may be a .p12 file in the Tomcat folder. Copy that to the desktop as well.

7) From Program FilesJSSTomcatconf copy the server.xml file out to the desktop.

8) Open up a command prompt by right clicking on it and choosing "Run as administrator".

9) In the command prompt window, type in the following: msiexec /i "C:JSS Installer.msi" and press enter. If the JSS installer.msi isn't at C: we can just drag the MSI itself into the command prompt window and it will populate the correct path.

10) Click next when prompted and hopefully all will go well.

Occasionally, we see the installer have trouble restarting Tomcat properly in Windows, so we usually recommend, after the installer finishes, going back into Services and manually restarting Tomcat.

After that, try to bring up the JSS in any web browser except Internet Explorer; we find Internet Explorer tends to 'hang' on the Startup procedure after an upgrade.

If all went well, we should see that we're on whatever version we were upgrading to after logging in to the JSS, and we'll be good to go.

Steps 5-7 are just 'for safety' steps, if something happens and the installer fails, when it rolls back it wipes out those files, which can be a pain. We copy them out to the desktop prior to avoid that headache if the installer doesn't complete. Once the install is complete and we verify we're on the version we’re trying to install, the files we moved to the desktop can be deleted (or just keep them as a nice backup to have).

If the installer has already failed and Tomcat is broken/half there/not there anymore at all:
- Give the server a quick reboot; this will clear out half-there Tomcats that are stuck in a state of neither started or stopped. Tomcat won't start up again, as it's not fully installed any longer due to the 'rollback'.
- Move (not copy) the entire JSS folder out to the desktop.
- Make sure #3 and #4 from the list above are done.
- Run the installer again.
- From the JSS folder on the desktop, copy JSS omcatconfserver.xml back to Program Files omcatconf
- From the JSS folder on the desktop, copy the JSSBackups folder back to Program FilesBackups
- Remember to regenerate the Tomcat cert through the webapp (it will be self signed) if the TomcatSSLKeystore file is not in the JSSTomcat folder on the desktop.
- If using a third party certificate, it will need to be re-uploaded to the JSS if the TomcatSSLKeystore and .p12 file are missing.

Double check the JSS Database Utility and:

1) Make sure Tomcat memory is set correctly.
2) MySQL Max Packet size is at least 512 and Binary Logging is off.
3) Automatic Backups are still enabled.

If you've had to move the JSS folder out to the desktop, the JSSDBUtilityConfig.xml file gets regenerated as new and everything goes back to default, which isn’t suitable for most environments. Either move the JSSDBUtilityConfig.xml file back from the desktop Program FilesJSSin or open up the JSSDatabaseUtil and set the settings again.

If we’ve moved the entire JSS folder to the desktop, and typically keep backups in JSSBackupsDatabase, we’ll probably want to put that folder back into the new Program FilesJSSBackups as well.

If none of that does the trick, I’d recommend getting in touch with your Technical Account Manager, as there may be something else going on.

@flammable I wasn't able to replicate the error you're seeing in the screenshot; it may be worth it to try re-downloading the installer and making sure it's been extracted locally on the machine we're trying to update.

Thanks!
Amanda Wulff
JAMF Software Support

[flammable]

@amanda.wulff Thanks for the tips - will save your post for future reference.

I redownloaded again, and checked the MD5 - it looks like it's downloading correctly. If I click OK, here's what I get:

external image link

Note that it's referencing the 9.25 installer, which I've since deleted. If I cancel and click Browse and choose the 9.3 installer, I get this:

external image link

I have no choice but to click Cancel (it prompts me twice), then it tries to do some Tomcat stuff and fails with this message:

external image link

I tried loading our Casper installation with Safari on my Mac, and it timed out - even after I rebooted the server. I stopped the Tomcat service, but that didn't seem to change anything. I didn't try any of the other "backup" steps, since I've already had the installation fail and roll back several times.

Is there anything else I can try?

[flammable]

Thanks, @mmunoz2 - I don't quite understand your instructions, though. How do I delete environmental values?

[MarcosMunoz]

You go to the server's "System properties" (Open an explorer window, right click on "Computer", select "Properties", select "Advanced System Settings". The "Environment Variables..." are found at the bottom of the "Advanced" tab.

[were_wulff]

@flammable

That’s an odd one.
I do know that the ‘rollback’ tends to leave Tomcat in a broken state and that’s why you’re not able to access the JSS after that happens, but I've not seen it give the error about the msi not being a valid installer before. There are a few logs we can get/generate that should give us a better idea as to what's going wrong though.

I would highly recommend opening up a case with your Technical Account Manager to go forward, so we have it documented in our ticket system, since this isn't behavior we'd expect to see.

We can create a case by either emailing support@jamfsoftware.com directly, or through My Support on JAMF Nation.

When you do create the case, please attach the screenshots or just a link to this discussion (since the screenshots are already posted here), as well as the results from doing the following:

Move the remnants of your Program FilesJSS folder to the desktop.

Open up a Command Prompt as Administrator.

Type in: msiexec /i drag heinstallerinto the command prompt window.msi /lv C:JSSlogging.log

This will run the installer in debug mode and dump a bunch of info into C:JSSLogging.log (which it will create).

If it fails again, do not click OK when it gives the error of “A script required for this install to complete could not be run.”

Instead, open up an Explorer window and go into your WindowsTemp folder. There should be a file in there named something along the lines of JSS installation log.txt.
It’s locked, so you can’t move it, but you can open it and do a save as to the desktop.

After that, go to Program FilesJSSTomcatlogs and see if there is a recent catalina.log.
If there is, grab that as well.

Attach those three log files to the new case, and we can get a better idea of what’s actually failing, since that error message can be a little vague.
Having the debug log from the installer as well as the temp log file Windows generates should give us a better idea of what’s actually failing here.

Thanks!

Amanda Wulff
JAMF Software Support

[flammable]

@mmunoz2 - sorry, did some searching and came up with this:

http://msdn.microsoft.com/en-us/library/ms924886.aspx

I cleared those variables, stopped Tomcat, and renamed the JSS folder, but still got the same dialog boxes during installation.

[flammable]

Thanks, @amanda.wulff! I just emailed support with those logs.

[jolo]

I had this issue and contact support. Was told to move the tomcat folder and then run the installation again. This worked for me

[mkremic]

Just had the same issue upgrading from 9.8 to 9.81.

Renaming the Tomcat folder to Tomcat-old sorted it for me. Had to update the Tomcat certificate afterwards as well.