Please tell me you're upgrading your dev environment first. The JSS is notoriously buggy in a Windows server environment. I could be wrong, but my we had nothing but issues at my previous gig with Windows. I'm running Ubuntu and Redhat and we do not have these issues.
Nope. Production server upgrade. It's a VM so we're only a snapshot away from a quick restore.
We actually had more issues with our JSS on Ubuntu than Windows. Probably more to do with our environment though (mainly proxy issues)
I'm receiving the same error when trying to upgrade from 9.82 to 9.9 on a 2012 R2 machine. And like @bprc, our JSS host is a VM so upgrading right away isn't an issue, snapshotting all the way!
I had this yesterday when upgrading on our Windows VM. I just restarted the server and ran the update again. It worked so not sure what the issue was.
From the log:
Running 'robocopy.exe' timed out after '60' seconds.
The installer does not wait long enough for the copy job to finish. 60 seconds is a bit on the low side.
I had this issue also. Try opening command prompt with right click>run as administrator. cd to the location of your installer msi. At the command prompt enter: msiexec /I "JSS Installer.msi" and hit enter. This is not the only way to run msiexec elevated, just giving you how I do it.
I suspect this has to do with running the installer elevated.
I would be curious if this solves the issue. The error robocopy timed out after sixty seconds is not that they are not giving it enough time, I think that it is hanging on the inability to perform elevated permission actions on files.
Just ran this in our dev environment and saw the same error. Using @aamjohns instructions above were the answer. Elevating the installer seemed to do the trick.
I haven't tried to upgrade our windows VM to 9.9 yet, but in the past I've found it worked better when you stop the apache service before updating. Hopefully that will make it into the documentation someday.
Since this update doesn't have too much OSX based upgrade, we'll probably wait a bit before we upgrade.
I usually stop Tomcat service before the upgrade also. Seems to be quicker than the installer stopping it.
Thanks for the suggestions but still no success. :(
Here's a list of things I've tried.
- Restarted server
- Ran as Admin (you have to do this anyway... the installer bombs if you don't).
- Doubled CPU and RAM on VM.
- Manually stopped the Tomcat service.
Unfortunately, the only suggestion support has offered so far is to re-run the installer and select the "Repair" option. The repair option doesn't exist as it never reaches the install code initially.
The Robocopy script still runs after the installer times out. It seems to take about 90 seconds to complete the backup. Pretty slow for 175MB.
So unless I can skip the backup step it looks like I'm stuck until JAMF update the installer to wait for longer until it times out.
So I did a little snooping to see what I could remove from the install directory to speed up the backup.
The TomcatwebappsROOT directory contains about 5,000 tiny files. We don't have customisations so I removed it.
Install went through fine and recreated the ROOT directory.
I'd suggest holding off for a proper fix but if you're desperate this may be an option.
Do it at your own risk.
@bprc I had the same issue crop up during my v9.9 upgrade this morning in my Test JSS running Windows Server 2012 R2 as well. The same steps that you highlighted (modified below in my own words) did the trick for me as well.
Issue: "Invalid Message - The message could not be parsed."
System: Windows Server 2012 R2
1. In your JSS, launch Services.msc and stop the Tomcat service (called Apache Tomcat 7.0 Tomcat7).
2. Navigate to C:Program FilesJSSTomcatwebapps and copy the ROOT folder to your Desktop.
3. Once copied, delete the ROOT folder from C:Program FilesJSSTomcatwebapps.
4. In a browser, navigate to https://my.jamfsoftware.com/products.html and expand the Show JSS installer downloads section.
5. Click on the download button next to JSS Manual Installation.
6. Navigate to the downloaded zip folder and extract all contents.
7. In the extracted folder, navigate to the JSSInstallation>JSS Components directory and copy the ROOT.war file to C:Program FilesJSSTomcatwebapps.
8. Restart the Tomcat service (called Apache Tomcat 7.0 Tomcat7) that was stopped in Step 1.
9. Verify that the ROOT has repopulated.
10. Launch a browser and navigate to your JSS URL and verify that this is starting back up.
11. Once confirmed, please run the "sudo jamf recon" command again from a machine enrolled in this JSS.
Long story short, if you're not in a hurry, wait for the issue to be permanently fixed by JAMF. @Tad is there an ETA on this being permanently fixed for Windows Server 2012 R2 users?
Any news on a permanent fix? I now get an error that the Installer couldn't create the folder "JSS" inside the backup folder when the Installer wants to backup data. I already tried the suggested solutions.
My suggestion would be to at least give the user the choice to backup data or not. I assume that most users are running the JSS as a VM anyway and a restore is just a snapshot away.
My job was closed off today as my situation has been resolved (using the ROOT folder workaround).
I don't think my helpdesk guy understood the importance of having this fixed. He said he'd "pass this up the line to help improve it further down the track"
The lack of JAMF staff feedback on here is a little concerning.
I'd suggest logging a ticket if you haven't already so they can gauge the severity/impact.
@bprc, this is a user forum, and while JAMF folk occasionally chime in,
if you need or expect official communication with JAMF, your TAM is the route.
Glad you were able to resolve your issue!
I was preparing to do this upgrade myself when I saw this thread. I reached out to my support buddy who said that an engineer is looking into the issue, but we also schedule a WebEx to run through the upgrade with him on the line in case something bombs. JAMF support is great!
I ran into this yesterday and opened a support case. I sent the tech a link to this thread today.
I logged a ticket and got a confirmation that it was a defect.
This issue is still not fixed with the 9.91 installer.
Holy Crow! How frustrating! I was attempting to upgrade our environment from 9.81 to 9.91 and the installer failed. Log file error: "There was an unexpected error running 'robocopy.exe "C:Program FilesJSS System.TimeoutException: Running 'robocopy.exe' timed out after '60' seconds."
I opened a ticket with JAMF . . . and my reply was to try the installer again. SMH*
Before opening the ticket, I had tried the installer multiple times. Truth of the matter is that the recommendation (to try installing again) only makes the situation worse.
What seems to be happening is if the JSS folder is too large, robocopy times out before the folder can complete copying the pre-install backup.
To compound the issue when the installer attempts the robocopy backup it creates the backup within the JSS folder that it is trying to backup: JSS_BACKUP_DIR=C:Program FilesJSSBackupsJSS-20160511-083832
After five attempted installations, my JSS folder had ballooned an additional 2.5GB in size, because of the numerous backups created each time that I ran the installer. Since there is no mechanism in the installer to delete the failed robocopy backup, the JSS folder continued to grow in size each time the installer runs.
With a JSS folder now 7GB in size I began to work on some clean up. By making a back up of the JSS folder to another volume and then manually deleting log files, back ups and the failed installer backups, I was able to reduce the JSS folder to under 1GB.
With the JSS folder now a manageable size, the installer worked fine and I was able to complete my installs.
I'm glad that I was able to figure this out on my own, and I hope very much that the next release will take this issue into consideration, as this seems to be a rather serious flaw.
My JSS folder was down to less than 300MB and I am still getting the failures with Robocopy timing out. Very frustrating...
Seems like migrating to another server platform is the way to avoid these bugs. Cheers for keeping the post updated.
For future troubleshooting.1603 is a "general error" speaking in msi-errors. Check logfiles in %temp% or %windir%/temp on your windows server for more accurate logs when facing this.
