I am experimenting with silent installs of Oracle 10g XE on a fresh XP VM. I have an iss file, copied from the standard one from oracle, called "foo.iss" Here is my command:
>OracleXEUniv.exe /s /f1”C:\xe\foo.iss” /f2”C:\xe\foo.log”
I just followed what I found on the Oracle support site. This command causes a temp folder to be created, which contains an installer file: "Oracle Database 10g Express Edition.msi"
So it looks good. But the process then just silently fails. No log is created in the install folder (C:\x) except for setup.log which only has:
In C:\windows is the larger log file, OracleDatabaseXEServerInstall.log
Is has alot in it, and ends with:
1: Standard project type, let scripting engine clean up setup files...skipping action Action ended 17:43:27: ISSetupFilesCleanup. Return value 1. MSI (c) (34:BC) [17:43:27:420]: PROPERTY CHANGE: Adding ISSETUP_UISEQUENCE_PROCESSED property. Its value is '1'. MSI (c) (34:BC) [17:43:27:420]: Note: 1: 2262 2: Upgrade 3: -2147287038 1: Not using skins for this installation. Could not find skin file . MSI (c) (34:BC) [17:43:27:650]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (34:BC) [17:43:27:700]: Note: 1: 2262 2: ISRequiredFeature 3: -2147287038 MSI (c) (34:BC) [17:43:27:920]: Note: 1: 2205 2: C:\DOCUME~1\dlwiii\LOCALS~1\Temp\_is33\Oracle Database 10g Express Edition.msi 3: ISAlias MSI (c) (34:BC) [17:43:27:920]: Note: 1: 2228 2: C:\DOCUME~1\dlwiii\LOCALS~1\Temp\_is33\Oracle Database 10g Express Edition.msi 3: ISAlias 4: SELECT * FROM ISAlias 1: Ready to launch program block. 1: User aborts the installation, ready to launch __OnAbort. MSI (c) (34:BC) [17:43:30:434]: Destroying RemoteAPI object. MSI (c) (34:B8) [17:43:30:454]: Custom Action Manager thread ending. === Verbose logging stopped: 8/27/2011 17:43:30 ===
Any idea what I am doing wrong? The command line looks suspect, as when I run the install program with just /? I get the following, which shows no /f1 nor /f2 options at all:
I am simply playing with this, but would really like to solve this, as unattended installs look like a great option to ensure consistent database deployments.