Thanks for getting back to me so promptly - excellent help!
Indeed, once I deleted the directory "C:\ProgramData\MySQL" the version 4.2 installation program was willing to continue ...
Unfortunately, after a short time it seems to fail again. This time the error message is:
Installation Wizard Completed. The wizard was interrupted before OnCommand Workflow Automation could be completely installed.
In the InstallShield GUI window, below that message, an empty box is displayed, which looks as if it is meant to contain some more information (see attached screenshot).
I tried this several times, with the same result each time.
I then tried installing 4.1 again. Strangely, the 4.1 install doesn't experience the above problem and seems to have completed. It takes a long time, stopping a couple of times, saying that it has timed out trying to verify things, but after it completes I am able to log in to and use the WFA Web UI.
I then tried the version 4.2 installation again, thinking it might work once 4.1 was already installed. The installer recognises that WFA is already present and says it will perform an upgrade, but then fails just as before with the same "The wizard was interrupted" error.
So it seems as if we have at least got 4.1 working again. However we really need 4.2 for the improved AD/LDAP user authentication support.
Any suggestions on fixing this one? Seen it before? You did great last time!
Thanks again for taking an interest in our problem.
The system identifies itself as being: Windows Server 2008 R2 Standard Service Pack 1
We are trying to install (actually upgrade to) WFA version 4.2. It should be installed in "D:\NetApp\WFA", where version 4.1 is already installed and functioning.
I believe that the WFA application on this system has been upgraded several times. I think the first version to be installed may have been 2.1 or 2.2.
I attached the screenshot of the InstallShield error already. The following event is logged by Windows when the failure occurs:
Windows Installer reconfigured the product. Product Name: OnCommand Workflow Automation. Product Version: 4.2.3223. Product Language: 1033. Manufacturer: NetApp, INC. Reconfiguration success or error status: 1603.
Windows Server 2008 R2 Standard Service Pack 1
I imagine there is a good clue in the fact that I was able to (re-)install version 4.1 apparently successfully (apart from some timeouts) but that the version 4.2 installation fails. That would seem to suggest that something has changed in the InstallShield code ...
This issue is happening because of MySQL 5.7 which needs a 2013 VC Runtimes and during the install of VC Runtimes on Windows Server 2008R2 machine, a certificate chain need to be established. This certificate chain can be established only when machine is connected to internet.
OK, that would be my mistake. Didn't think to check the InteropMatrix - sorry! Though you could consider adding a check of the Windows version to the install program ...
So we will probably deploy a new VM guest with a newer version of Windows and (re-)install WFA there.
Do you have any suggestions regarding migrating the workflow we have developed? What's the best way to do that? Via backup and restore, or via an export? It seems as if I can only export "everything", or individual items?
FYI, I still don't know what a WFA key is, however I was able to fix this most recent error (the bizarre "'_x0017_', hexadecimal value 0x17, is an invalid character" when running workflow) by resetting the Filer/Cluster access credentials (Web UI: Execution -> Credentials).
The Web UI has a useful test button there which was returning a failure when used with the existing (restored) credentials. Switching to another user+password worked.
the same workflow now runs successfully (well, until I reach the next issue!).
On the WFA server that the backup was taken from, open a CMD window. Change to the WFA\bin directory - wherever you installed WFA, then "bin" under that. Run this command and capture the output:
It will emit what appears to be a base64 dump of a key (probably is), a 20-some character string that usually (always?) ends in "==". Keep a copy of this string for future reference, it will apply to any WFA restore from this or any WFA server that is sharing these backup/restores and this key.
For example's sake, let's say that the key string is "1234567890123456790==". On a WFA host that hasn't aleady had this key installed, such as a fresh WFA install, where you want to restore one of these backups, either before or after the restore - shouldn't matter which - run this:
Obviously replace the part after the "-key=" with your key string. This key is used to encrypt the auth credentials to your NAS and, I think, your UM server, and - again, i think - your AD/LDAP connection if you have one. Replacing the randomly-generated key on a new install with the key from your reference install will allow you to restore the reference's backups and have them actually work.
I hope this helps. I've set up many a temp install of WFA to munge workflows in so I don't hose my Prod server, and I've had to do this a on each of them. Works like a charm.
I forgot to mention that I am having essentially the same failed WFA 4.2 install issues on my server that you are, expect that mine is already 2012 R2. It's getting pretty frustrating. I'm just very glad that this isn't my Prod server.
I installed WFA 4.1 recently, and did some workflow work. Once I got that completed and moved the updates to Prod, I wanted to test 4.2 before upgrading my Prod server. WOW was I glad that I did. At first I mindlessly upgraded by just running the installer. Not only did that fail, but it crashed the server. After it rebooted it was a real mess to clean up the cruft it left behind. I've now tried 4 times to install 4.2, and I keep getting these weird "Could not verify schema validation success or failure even after 900 seconds. Please verify your install after installation is over." messages. After the install neither WFA nor its database will start, so I guess the verification failed. I've uninstalled the various pieces, searched for stray files and dirs and cleaned them up, rebooted, and attempted the installs again, nevery successfully. At least once I got 2 similar messages sayone something couldn't be validated, ths second one stated that it happened "even affter 1200 seconds". I don't have a capture of that one.
I'm beginning to think that WFA 4.2 isn't "ready for prime time". I'm also bummed that, according to the install manual (now that I've read it), you're not supposed to "upgrade" from 4.1 to 4.2, you're supposed to uninstall 4.1 and install 4.2. The disappointing thing is that the installer doesn't check for this, and instead proceeds to do the wrong thing. It shouldn't even attempt the upgrade under these circumstances, it should fail with a useful error message.
As a "truer test" of the WFA 4.2 upgrade, I took a fresh install of WIndows 2012 R2 and installed WFA 4.1, then restored my Prod database. I then uninstalled WFA 4.1, rebooted, and initiated the installation of WFA 4.2. Here's where it got to be "fun".
Several seconds into the installation of MySQL the server suddenly and without warning crashed and rebooted. When it came back up I attempted the installation of WFA 4.2 again, expecting it to fail rather rapidly. Instead it completed the installation of MySQL and ActivePerl, and proceeded to install WFA. The progress bar made it about 3/4 of the way across, then sat there for several minutes.
After 15 minutes or so I got a requestor stating "Could not verify schema validation Success or Failure even after 900 seconds. Please verify your install after the installation is over.".
After selecting "OK" I was then presented with the fabulous news in another requestor stating "Deployment of E:\WFA\jboss\standalone\deployments\wfa-0.5.ear failed. Installation will be aborted. You will have to manually delete WFA Services from your system.". Fabulous!
I captured the Install Log in case it would be helpful. If it would be helpful I'm sure that I could "sanitize" it and upload it, or whatever section of it would be useful.
As I said in a previous post, it appears that WFA 4.2 isn't "ready for prime time".
I am opening a case against this issue and will upload the install log files from my tests along with some screen captures. This will keep any potentially private information that might be contained in the log files isolated to a more private location. The case number is 2007383540.