Still getting upgrade errors on my DEV system with 9.73 (tried on clean installed 9.72 version, using an SQL database started aroud 9.5)

This might be the relevant installer log line:

Set WshShell = CreateObject("WScript.Shell")

memoryHeapMin="256"

memoryHeapMax="1024"



REM Set paths to Session Property

installRoot = systemDrive & "Program FilesJSS"

tomcatBIN = systemDrive & "Program FilesJSSTomcatin"

webAppFolder = systemDrive & "Program FilesJSSTomcatwebapps"

webAppBackups = systemDrive & "Program FilesJSSBackupsWebapps"

jssSettingsBackupFile = "com.jamfsoftware.jss.settings.xml"

serverXMLBackupFile = "com.jamfsoftware.jss.server.xml"

databaseXMLBackupFile = "com.jamfsoftware.jss.DataBase.xml"

restrictionsXMLBackupFile = "com.jamfsoftware.jss.restr

Info 2898. For DlgFont8 textstyle, the system created a 'Tahoma' font, in 0 character set.

MSI (s) (30:BC) [09:10:24:198]: Product: JSS -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor.  Custom action initTomcatAsUpgrade.vbs script error -2146828230, Microsoft VBScript runtime error: File already exists Line 217, Column 3,  



Action ended 09:10:24: InstallFinalize. Return value 3.

It looks like a good practice to go into C:Windows emp and delete all temporary files the previous installation might have left behind there before starting an upgrade. Those include at least:

• com.jamfsoftware.jss.DataBase


• com.jamfsoftware.xsltproc


• server.xslt


• serverOutput

Likewise, deleting the strange Mac-like folder "C:LibraryLogs" that gets created on every install seems to help with the error message about not being able to update log paths.

At least that helped me a dozen times when fixing "stuck" upgrades (short of completely removing the JSS folder). Anyway, this should be done automatically by the installer.

Is anyone having issues with 9.73 that aren't related to the installation? I will be updating our test environment soon so I'll post back if I find anything....just wondering what others are seeing.

FWIW I highly recommend the manual JSS installation/upgrade method. It's easy and I believe all of the installation issues in this thread would have been avoided.

I've been running 9.73 since about 48 hours after release. I upgraded just fine, but I did go through the MySQL checks as is recommended in JAMFs KB article (@amanda.wulff) is famous for sharing it ;-)

That said, I did initially have an issue with Java running up the CPU and causing timeouts with computers attempting to connect to the JSS. In the end, it all ended up being caused by a single corrupt record in my MySQL db.

After the upgrade D-008898
still appears to be an issue for for me, I've re-opened a support case for it and I'll let you know if I learn anything new.

Didn't even know about D-008898. Can confirm that I have this issue on 9.73, still.

The upgrade failed for us. The manual and regular installer both had weird issues.

We had to use a combination of the installer and the manual installer to get it to work. Thanks to my TAM, Martin, we were able to get it all working in less than an hour!

No experience with Casper server upgrades until this one. We went from v9.4 to v9.73 last night following the procedures for a regular install with the new .msi. No issues to report. Everything came back normally and so far seems to be ok.

D-008898 would be a problem for me as we use SMB shares for our DPs.

@Josh.Smith , testing 9.73 in our Dev environment has revealed SMB issues similar to D-008898 here, and JAMF Support says D-009351 has been filed for the lingering SMB issues with 9.73. I don't have much interest in adding a script to every policy to unmount the DP's and remove kerberos tickets, so no 9.73 upgrade for us.

I have the option of requesting HTTP to be activated on my DPs. Think I might go that route.

@nigelg

I currently use HTTP downloads and I haven't experienced any issues.

Windows Server 2012 R2, IIS8

I'm currently experiencing high CPU usage from Tomcat on my 3 JSS'. Between 74-90%. All are Windows VM's running Server 2008 R2. I have tried replacing the server.xml file from a pre-upgrade backup, but I'm still experiencing the issue. My database is on a separate server. I added the cipher changes, but this did not help either. I used the automated install instead of the manual process. The CPU usage will be fine for a few hours, but then jump up to 74-90%, making the JSS inaccessible through imaging, a browser, and Self Service. I have an email into support this morning. Just wondered if anyone else had the same problem.

@Mike_Meyers

I have my JSS and MySQL on the same server (2012R2) and I might be seeing that issue. My CPU stays around 10%, then randomly jumps to 30-40%.

am now finding after the upgrade to 9.73 that I am unable to mount SMB distribution points with Casper Admin in order to sync them. We are using a directory service account to mount the shares.

running kdestroy -a does not seem to make a difference.

Could this also be related to the D-008898 defect? Are there any suggestions for getting around this?

@amanda.wulff I am seeing that Casper Admin says that the distribution point could not be mounted, however when I navigate to the mounted share via the command line, it is in fact mounted and I can navigate through the packages on that particular distribution point. Are you getting other reports of this?

@ocla&&09

There are many reasons, ranging from environmental to settings to defects or any combination of those things that could cause the behavior that you're seeing with Casper Admin being unable to mount a distribution point.
Without looking into it further, anything I'd suggest would be a shot in the dark, however.

If you haven't already, it'd be a good idea to reach out to your Technical Account Manager so they can collect additional information or set up a time for a call or a WebEx to look into your specific environment's situation a bit closer than we can do on the forums here.

Additionally, if you suspect you're running into D-009351, which has similar symptoms to D-008898 but a different underlying cause, please get in contact with your Technical Account Manager so they can troubleshoot with you further to either confirm or rule out a defect and, if confirmed, get your case attached to the defect for tracking purposes.

You can get in touch with your Technical Account Manager by either giving Support a call, sending an e-mail to support@jamfsoftware.com (it will go directly to their case queue), or by using the My Support section of JAMF Nation.

Thanks!
Amanda Wulff
JAMF Software Support

I'd be curious for those who are using SMB shares what OS those shares are running on. Each version of Windows Server for a while now has had a changes in SMB. Same with the OS X clients. There would be a lot of mix and matching to test but it might help narrow down if its a protocol issue where the Casper apps are having trouble mounting depending on the version of SMB its trying to use.

The issue isn't effecting me but it's just something to try that may help get down to the cause of the issue.

Those of you using the Windows JSS's, how many processors do you have allocated to your servers? What is your setup? I have 3 webapps, 1 distribution point, and 1 database. My Tomcat service is maxing out after a few hours and making the JSS's inaccessible. I have 2 processors and 8GB of RAM for each server. Just curious. Thanks! MM

We're a external company so have loads of JSSes running on Windows that we maintain. It is a bit variable depending on how many check-ins there are and how heavily they use Self Service (which hits tomcat a bit harder than everything else).

If its for under 1000 users we normally go for 2 CPUs and 8GB RAM.

Don't forget that Tomcat might not be configured to use all the RAM in the box by default.

We have around 100 Clients, 15 Minutes Check-IN RAM/CPU works well (10GB + 1 CPU) ... but sometimes the Tomcat doesn't kill the CLOSE_WAITs (just today ... )