05-07-2012 04:55 PM
Hey everyone this is Dan with the helpdesk. Lately we've been running across a fair amount of installation issues. Sometimes you'll see issues when installing on 64bit systems. Much of this centers around the installer looking for a certain key being false, or a particular app pool not set correctly. Now keep in mind, that this won't always be true for every system, which is why knowing how to troubleshoot the issue is much more important than knowing a list of particular issues. So, how do I find out if this is the case for your installer? Logs!
Many applications put logs in the temp directory. The BPM product does the same. You can navigate to the temp directory by doing the following
Start > run > cmd > %temp%
On a Windows 7/Vista/2008 environment this should open up:
All of the Metastorm install logs follow a similar format:
So, if I just attempted to install the 9.1 SR3 installer, I would want to take a look at the MetastormBPM220.127.116.11Log.txt log. Now, these logs contain a large amount of data, which makes them no fun to parse if you don't know what you're looking for. If your installer is failing and/or rolling back there is one item to search for:
So, in the following install log. I have an installer rolling back. When searching for Value 3, I see the following occuring before the value is thrown:
InstallShield 16:50:54: SetVRootProperties for virtual directory 'ECL.WS', app 'ECL.WS'
InstallShield 16:50:54: IIS7 check for ASP.NET version bitness on application pool 'MetastormECLWSAppPool', install is requesting 'x64'
InstallShield 16:50:54: GetAdminSection for section 'system.applicationHost/applicationPools' and path 'MACHINE/WEBROOT/APPHOST' and commitpath 'MACHINE/WEBROOT/APPHOST'.
InstallShield 16:50:54: Found element with property 'name' value of: MetastormECLWSAppPool
InstallShield 16:50:54: Application pool Enable32bitAppOnWin64 value is 'true'
InstallShield 16:50:54: SetAspversion: machine is 64-bit and IIS running in a bit mode other than the currently selected mode
InstallShield 16:50:54: Error with IISRT: -2172
CustomAction ISIISInstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 16:50:54: InstallFinalize. Return value 3.
In IIS 7 there is a section called Application Pool Defaults. You need to make sure that 'Enable 32-Bit Applications' is set to False. Otherwise the installer will fail.
Start > run > inetmgr
IIS 6 works differently and doesn't allow you to run 32bit and 64bit application pools. To turn off 32bit application pools you will want to open a command prompt and run the following (Source: http://support.microsoft.com/kb/894435):
start > run > cmd
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
This will set all of the application pools back to 64bit. After setting this rerun your installer.
I've zipped up and attached my MetastormBPM18.104.22.168Log.txt so you can take a look for yourself.
05-07-2012 05:12 PM - edited 05-07-2012 05:24 PM
9.1.3 Specific Installer issues:
9.1.3 introduced some changes. Most of the application pools were changed to the .NET 4.0 framework, with the exception being the MetastormWebAppPool
Since some changes are being introduced we have some more redistributables for you to install (\Metastorm BPM Core 9.1.3 SR3\redist):
So be sure to install those before attempting to install the SR3 patch. As always read the Release Notes as well.
One issue that several people have run into, is that when their MetastormECLWSAppPool was set to 32bit=true the installer was rolling back. After setting that specific application pool to 32bit=false the installer would continue.
08-13-2012 02:49 PM
"One issue that several people have run into, is that when their MetastormECLWSAppPool was set to 32bit=true the installer was rolling back. After setting that specific application pool to 32bit=false the installer would continue."
This is still true for the 9.2 installer as well.
10-29-2013 03:35 PM
I have an update to make for 9.2.1 / 9.3 etc.
Sometimes you will start an upgrade and all appears to be going well until the installer attempts to start the services, at which point it fails and starts to roll back the upgrade. This will happen when you have your services set to automatically start in the registry. You can workaround this by setting the startup to manual
start > run > regedit
EDEPSERVSTARTUPTYPE = manual
ESTARTUPTYPE = manual
After making the change, rerun the installer. After the upgrade completes you can just set the Engine Service back to Automatic (Delayed) and the Deployment Service to Automatic or Automatic (Delayed). (You must use Delayed for the engine service or it can interfere with core windows services starting up.)