@Jens.Mansson The "real" error is this:
There was an unexpected error running 'robocopy.exe "C:Program FilesJSS" "C:Program FilesJSSBackupsJSS-20160517-134554JSS" /b /copyall /R:2 /W:5 /e /XD temp backups logs work /LOG:"C:Program FilesJSSBackupsJSS-20160517-134554JSS-Backup.log"'! ---> System.TimeoutException: Running 'robocopy.exe' timed out after '60' seconds.
I think the issue is other data in the C:Program FilesJSS directory that makes the backup too large. Check to make sure there are not other backups there or that someone did not put files there or do something to inflate the directory.
If there are other backups there, they should be moved to another location outside the C:Program FilesJSS location.
I used to have this issue until I did two things. One, clean up that directory. I had put a backup there myself causing it to be too large, and second, making sure that I run the installer msi from an elevated command prompt. I just right click command prompt and choose 'run as administrator'. Then copy paste the path to where the installer msi is sitting. cd "<path>". Next type msiexec /I "JSS Installer.msi" /log C:some_pathinstall.log and hit Enter.
This works for me now. And if it does not, I can check the log file and see what happened. I do think it is true that if the JSS folder has too much data in it, the robocopy times out and the install will fail. In addition, if the msi is not run elevated, it will fail.
I have a log of a successful install. I don't want to post it but if someone would like assistance, let me know and I can compare your log to my log maybe help figure out what is happening.
I know that occasionally I will run into someone that does not realize you can paste into a cmd window. Just to make sure... it can be accomplished by either clicking the tiny cmd window icon in the upper left of the cmd window, going to Edit>Paste or just right click on the cmd window and it should paste in.
Some comments:
- I have removed the entire backup folder. The JSS folder in my test environment is less than 300 MB and it is timing out.
- I have found this whole business of Jamf saying to run from an elevated command prompt odd. No other installer requires this. I once had a support technician who even advised against executing the installer from PowerShell. Sometimes I wish they would just not support Windows and force my hand than support it in a non-100% way.
Some of this is frustration of course on my part. I am disappointed that after 3 revisions the same error is occurring. I know I can do a manual install but that involves more overhead overall and down the line. I don't think it is unreasonable to expect the Windows JSS installer to work.
@powellbc
Wow, that is interesting. It is still timing out. I've got the installer msi open in Orca right now trying to see what I can find.
Running elevated is required. It is a part of Windows Server. Essentially all I mean by this is you have to say I am an administrator running this. Being advised to not run an installer from PowerShell is odd. You may be referring to JAMF's recommendations, I did not say PowerShell, I just said a command prompt. And the reason I suggested that is it is easier than going through explaining other ways to add logging the install process. You can right click the MSI, create shortcut, open the shortcut, look at the command line and add log <somepath><somefile>.log or .txt to the command line and then double click your shortcut. Or open a text file and write the command line out and save it as a .bat. The command prompt is not required, I just thought it would be easiest. PowerShell is essential, in this case of running msiexec, just the command prompt. And there is not a thing wrong with it. In the end, it is all the same, msiexec is getting called to install a msi.
Would you mind logging your install and emailing it to me? aamjohns at iu dot edu?
By the way, a verbose log would be best for troubleshooting. Here is the command line option for verbose:
msiexec /i <msipath>setup.msi /l*v c: empmsi.log
/l*v <path><filename.log> is going to produce a verbose log.
Thanks,
AJ.
TBH this is a really poor effort that this hasn't been resolved yet. I'm happy to do some contract work if you want me to change a "60" to a "300"...
There seems to be some confusion here about the robocopy script. The script excludes a number of folders within the JSS folder. The temp, backups, logs, and work folders are not backed up. The backup size does not increase each time you run it. Perhaps you are getting lucky deleting backups and then successfully running the upgrade.
I still think it's due to the number of files, not size, that is causing the issue. See my earlier post for more info.
Jamf, please fix this rookie mistake!
Ben,
I am curious. If you manually stop the TomCat service before running the install, does it make any difference?
I just looked in Orca too to see if I could modify the timeout but did not see that value. :(
@aamjohns I know you were not saying anything about PowerShell, just brought it up as an example of some of the skittishness I sense around Windows from Jamf support. I did not mean to make it sound like I directed it at you—my apologies.
As I was typing this response I was attempting to generate the verbose log file and on what must be my 20th attempt to install one of the 9.9x releases, it now finally worked on my test server. I did nothing differently other than use the verbose logging command line (and manually calling the msi using msiexec /i instead of just launching it from the command line). I'm happy I have this installed in test but this unreliability in the installer gives me pause before doing it in production.
AJ, unfortunately, not one bit.
I spent hours on this issue when I first encountered it but I haven't looked at it since. I'll attempt the latest update tomorrow at work (it's 11pm atm) and try a few more workarounds.
Well, we do not use a timeout value in our "ditto" or "asr" scripts on the Mac – so why would robocopy need one?
Basically, you say "copy this from here to there and come back if you are ready OR give me an error", and that's it. If you insist on having a timeout, use something like 1 hour upwards, because you really want to be sure before aborting a slow, but perfectly fine installation routine.
Trying to upgrade using this installer is like throwing a dice; you can't even properly test it, because the timeout might hit you only in PROD and not in DEV.
So if you haven't already, contact your TAM and upvote that issue.
Hi,
I'm happy to hear after that many attempts you finally got it installed. I appreciate the clarification. I found nothing looking at the install through Orca. AJ.
I have contacted my TAM, I hope everyone else who has this issue has as well.
Also, thanks everyone, especially @aamjohns, for the feedback.
Same problems here. I cracked the MSI open in Installshield but cannot find any properties to control Robocopy.
Actually, if you shutdown Tomcat and back up this folder C:Program FilesJSSTomcatwebapps, then go into webapps and delete the entire contents, the install will work and it will just reinstall the contents of that folder. So far I don't see any problems.
Wow. I'm holding off upgrading until I see good things mentioned about the installer. Were still on 9.82 and I have no plans to upgrade yet.
I upgraded from 9.82 to 9.92 in test environment and then in production.
My first attempt in 9.82 failed, my TAM said it was the known robocopy issue, but I simply retried the installer and it worked fine. He said if the retry didn't work to do the manual install.
Upgrading in production went smoothly without the robocopy issue using the regular installer.
The other strange thing I ran into was on production box, the installer forced me to login as local admin, whereas in test env it worked fine with domain admin credentials.
I did what @kentmj suggested (delete the contents of the webapps folder), and it worked.
I also had to make sure to move my 'inhouse' folder to the desktop:
https://jamfnation.jamfsoftware.com/article.html?id=205
I'm thinking that's probably what caused robocopy to exceed the 60 second time limit the first time. Oh well. We're successfully running 9.92 now.
Just run into this issue on my test box from 9.82 to 9.93
Will be testing the manual install tonight.. surly this is an easy fix?
The solution I mentioned in the last post still works. I determined that our 'inhouse' directory for eBooks was causing the robocopy script to timeout, so for the last update, I just moved that to the desktop for the upgrade process (and moved it back afterwards). If you're storing anything in the C:Program FilesJSSTomcat directory, just remove that temporarily and you should be fine.
This appears to be resolved in 9.96.
Better late than never I guess!
not resolved for me...
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: There was an unexpected error running 'robocopy.exe "C:Program FilesJSS" "C:Program FilesJSSBackupsJSS-20161027-102625JSS" /b /copyall /R:2 /W:5 /e /XD temp backups logs work /LOG:"C:Program FilesJSSBackupsJSS-20161027-102625JSS-Backup.log"'! ---> System.TimeoutException: Running 'robocopy.exe' timed out after '300' seconds.
at JAMF.JSS.InstallUtilities.Utilities.LaunchExe.Run()
--- End of inner exception stack trace ---
at JAMF.JSS.InstallUtilities.Utilities.LaunchExe.Run()
at JAMF.JSS.InstallUtilities.Utilities.FileOperations.RoboCopy(String sourcePath, String targetPath, String args, String timeout)
at JAMF.JSS.InstallUtilities.Backup.JssDirectory(String timeout)
at JAMF.JSS.InstallUtilities.CustomActions.BackupJss(Session session)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object parameters, Object arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture)
at Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction(Int32 sessionHandle, String entryPoint, IntPtr remotingDelegatePtr)
CustomAction JSS_InstallUtilities_CA_BackupJss returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 10:31:25: JSS_InstallUtilities_CA_BackupJss. Return value 3.
Action ended 10:31:25: INSTALL. Return value 3.
MSI (s) (50:24) [10:31:25:816]: MainEngineThread is returning 1603
MSI (s) (50:DC) [10:31:25:816]: RESTART MANAGER: Session closed.
MSI (s) (50:DC) [10:31:25:816]: No System Restore sequence number for this installation.
MSI (s) (50:DC) [10:31:25:816]: User policy value 'DisableRollback' is 0
MSI (s) (50:DC) [10:31:25:816]: Machine policy value 'DisableRollback' is 0
MSI (s) (50:DC) [10:31:25:816]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (50:DC) [10:31:25:816]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerRollbackScripts 3: 2
MSI (s) (50:DC) [10:31:25:816]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerRollbackScripts 3: 2
MSI (s) (50:DC) [10:31:25:816]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerInProgress 3: 2
MSI (s) (50:DC) [10:31:25:816]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerInProgress 3: 2
MSI (s) (50:DC) [10:31:25:816]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (50:DC) [10:31:25:816]: Restoring environment variables
MSI (s) (50:DC) [10:31:25:816]: Destroying RemoteAPI object.
MSI (s) (50:68) [10:31:25:816]: Custom Action Manager thread ending.
MSI (c) (64:EC) [10:31:25:831]: Back from server. Return value: 1603
MSI (c) (64:EC) [10:31:25:831]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (64:EC) [10:31:25:831]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'.
Action ended 10:31:25: ExecuteAction. Return value 3.
MSI (c) (64:EC) [10:31:25:831]: Doing action: FatalError
Action start 10:31:25: FatalError.
@JustDeWon, looks like robocopy is timing out after 300 seconds. Try this:
- Figure out what's taking up so much space, that robocopy can't copy it within the allotted time. If you're unsure, windirstat is excellent for that.
- Move that data to a temporary location, such as the desktop.
- Run the JSS installer again.
- After a successful installation, move the data back to the original location.
@flammable .. I had already moved the ROOT folder to desktop before posting this..
Was just saying that JSS 9.96 upgrade didn't resolve that particular issue. After moving ROOT folder, it worked as stated above on resolution..
It looks like Jamf's solution to this issue was to increase robocopy's timeout from 60 to 300 seconds. If you have too much data to copy in 300 seconds, you'll still need to move it to a temporary folder when running the installer.
@JustDeWon What's the JSS running on? Slow HDD's perhaps? If you're curious to see how long the backup would take you can run the robocopy command manually.
It'd be nice if they gave us the option to skip the backup.
