Doing upgrades for users going from 12 > 12.x version was easy. Just install over top and done.
Going to version 13 is proving a little more difficult. The test install I've done for this is getting hung in the steps I've setup via our management software during the install. I am speculating its stopping on some of the prompts I saw with the manual install where it mentioned the version 12 we had could not be upgraded without a new certificate (Which I have).
I think you're right about the cause, from my own testing today. The Inno Setup /log option shows it's unable to proceed from the initial installer page, which requires a confirmation before the Next button is enabled. Using /SAVEINF and /LOADINF to record the choice also doesn't seem to work, unfortunately.
As far as I can tell, silent installs currently require Opus 12 be removed first, which isn't ideal. (Not just the extra logic required, but because it will wipe the user's config.)
We're discussing internally how we can improve this.
I also noticed that our instructions didn't include a link to Inno Setup's uninstaller command line details (only those for the installer). I've corrected that. For convenience, I'll link to both here:
The uninstaller is usually C:\Program Files\GPSoftware\Directory Opus\unins000.exe.
Note that uninstalling usually requests a reboot, since our DLLs end up loaded into a lot of processes. But upgrading Opus 12 to 13 also requires a reboot, which won't be needed if 12 was uninstalled first, so it ends up even in that respect.
So the main issue at the moment is losing the config folder(s), unless manually backed up and restored:
Awesome! Do I need to adjust anything in my current steps to make this happen? Trying to prepare ahead of time. Are any command switches different? Also, the environment lab we work in is a closed network. I know version 13 can pull down the license when online but will this be an issue with a separated network environment?
You shouldn't need to make any changes, if your existing scripts work with Opus 12.20 and above (i.e. the Inno Setup builds), other than be weary that the upgrade from 12 to 13 may prompt for a reboot at the end (or will do a reboot without prompting, if told to via the command line).
Offline environment shouldn't cause any issues. You can install the new certificate file via the command line after the update itself is installed, to keep everything automated. I verified that still works today when testing the new installer. (Remember that the command line for doing that may need updating, as it includes both the path to the certificate file and the registration code.)
Another thing to be aware of: The first time the user runs Opus 13 after the upgrade, it'll show the upgrade dialog to help convert their config. That won't happen during the installation itself, though (as long as you include /norun when running dopus.exe to install the certificate).
Hello Leo! I got around to testing this out in our environment after 13.10 came out. The install worked fine of course for a user going from 13.6 to 13.10. But it appears to be hanging on a system I tested it on still on version 12.24. This is how the steps process through;
I kill any potentially open process using;
Kill -Name *dopus* -Force
I then run the install with the follow command line;
There's usually no need to kill any processes, and doing so can corrupt config files or other data. The installer will restart Opus automatically in most cases (although see below), or you can tell it to exit in your script:
If Opus 12 was installed and Opus 13 then installed over the top, a reboot is required to update some of the DLLs to the new version. It may be that which is preventing dopus.exe from running after the 12 to 13 update.
That would be fine if it wouldn't run after installing and needed a reboot but its not finishing the silent install. The test run ran for 1 hour before exceeding the time limit on the deployment program and had to stop.
I've updated our steps for closing the program cleanly. Thanks!
Ah, so the DOpusInstall.exe stage isn't completing? (I wasn't sure if that was step 1 or 2 above.)
Does the log file it outputs (/LOG="DOInstall.log" in your command line) say what the last things it did were? They might tell us what it's waiting on.
Unfortunately due to the sensitive nature of the disconnected network we are using this on pulling those files off to submit isn't really feasible.
But something I want to note here;
Running the command to close directory opus vs killing the process has opened, what I assume, is the initial launch screen selections where you select default behaviors. Its being opened on an account that doesn't login locally and is just use for deployment of software. This has opened the process in the background where it remains stuck. I tested this on a new login of an account. Doing the Close Program command still did this default selection behavior instead of directly closing any open Opus processes.
Is that happening while DOpusInstall.exe is running? (Testing with the command-line you have above, and the DOpusInstall-13.10.2.Beta.exe installer, I haven't seen it re-launch Opus after updating it.)
Or is that happening when "C:\...\dopus.exe" /cert ... is run? (The /norun on the end should prevent that, unless we've broken something...)
If it's the latter, one thing to check is that the /C:\***locationofcertfile*** argument is quoted if the path contains any spaces.
Checking dopus.exe in Task Manager's Details tab, with the Command Line column turned on, may also reveal something about how/why it's being launched.
No. This happened when I was trying to determine why the install was stalling out. I logged in with an account I don't normally use and tried to close active opus processes with the Close command. Because this account isn't normally used and had not launched opus before the close command opened the initial window for selecting different behaviors for Directory Opus. Like the first time startup options.
Also, does the close command close all processes system wide or only for the user who uses it?
Ah, OK. You'd only want to run the Close command if Opus was already running. Otherwise, Opus will be started so that the command can be sent to it, which doesn't make sense if the aim is just to close Opus.
The ExitOpusAndWait script in How to Exit Directory Opus - #2 by Leo has an example showing one way to check if Opus is already running before telling it to exit if it is.
The Close command only affects the user/desktop it's run from.
Reading through the information I have to ask one question. Can Directory Opus close all active opus processes? Including ones that are not under that user. I need a way to close them system wide to run the update process.
No, there's no way for Opus running under one user to communicate with itself running under another. The different users' processes and desktops are isolated from each other by the operating system.
That must be something that comes up with other software as well, though? It's not unique to Opus and would be something an automated install system for a (simultaneous) multi-user system must need to handle (e.g. by providing a way to run a command for all active users, maybe).
Well yes and no. A process running from an elevated prompt can view/close processes in another user session as long as its knows to check for them. If I run a 'ps -IncludeUserName' from an elevated powershell prompt in Windows I can view the process ID and who is running the program and even close it from there. So for other software its generally not an issue. When I script out an installation package I will insert a step to check and see if something is running OR kill processes that match a name. Its required in a corporate environment with many users and machines to manage. Far too many users don't listen to their IT and leave machines on or programs running when we need to get them updated.
Killing a process is not ideal and kind of a last resort when we have people who are trying to set uptime records.