Men die earlier than women because they want to.
WebXtender has two modes: Interactive (IRC), or “Thin Client”. Interactive requires IE 6 with ActiveX controls, wheras “Thin” does not, but has fewer features.
To set the mode for users, you must enter the “User Profile Administrator” program that installs with XS Admin. You can change the global default, and/or the default for specific users (but not for Groups???!!!). Without further configuration, this option becomes fixed, and the user cannot change it.
However, in App Gen (part of a Full ApplicationXtender install), you can set a global option per-user or per-group called “Configure WS”. Once set, this allows the user to change ALL WebXtender user-configurable options, including the client mode.
Note: Setting this option in AppGen does not enable it for the user automatically! You must restart the WX service in order for the change to take effect! AARGH! (Recommended approach is to run the “Component Setup Wizard” which ships with XS Admin).
To simplify installation of the OC, I wrapped the files into a MSI using “Advanced Installer” v2.6.4 from Caphyon Software.
To accomplish this, I just needed to follow the previously documented manual installation routine, and take note of what changed on the system (specifically, I had a look at the REG text files generated by the ODBC installation script).
Advanced Installer lets to specify source files from ANY location, to be installed to a specified Program Files target. You also can specify Environment variables and Registry settings that you want performed during the install.
I just shipped the Install Directory to “University of VermontOracle 10g Client”, and added an “admin” subdirectory for the TNSNAMES.ORA file. Then I set the PATH, SQLPath, and TNS_Admin environment variables. Finally, I specified the required ODBC registry changes, and built the MSI.
Since doing the build, a new version of OC 10g Instant Client has become available (v10.1.0.4). I have updated the installer to use these files instead. Making this change is fairly simple. All you have to do is open the original Adv Installer package specification file (.AIP), take note of the location of the source files, then drop the updated files into that location. If there are any new files, or files that are no longer present, you need to update the AIP to reflect these changes. Change the package version number, then rebuild… easy.
After some fine head-banging, I have figured out how to package the ApplicationXtender 5.25 .MSP (patch) file into the original 5.20 installer. We just need to follow the standard “administrative installation point” routine:
- At the command line, go to the AX 5.20 installation directory.
msiexec /a AxSetup.msi TARGETDIR=[working directory]
- Assuming the MSP file is in the same directory, run
"msiexec /p /a [working directory]AxSetup.msi"
- Now just zip the working directory into a single file.
We do have some other options that may help with deployment:
- The “XSCM.Config” file from “Documents and SettingsAll Users” into the final archive directory, along with a script that drops this file into place on the target system. This will save installation staff the need to locate the setup file on first run of the application
- The install directory can be added to a self-extracting zip, which calls the SETUP.EXE.
- SETUP.EXE has command-line support, documented in the AX Installation guide. Essentially, we would run
SETUP MsiExec.exe /i "AxSetup.msi" /QB INSTALLLEVEL=[install_level]
where [install_level] is a number from 1 to 3. 1=Retrieval install, 2=Scan, and 3=admin install.
Symantec just extended us the honor of downloading SAV v10.0.1 (Maintenance Release 1 for SAV 10). This build is supposed to fix a bunch of performance complaints. Now that we have it, I suppose we should think in earnest about getting clients to install the new version.
I have been concerned about the apparent need to provide two installers… one for upgrades, and one for new installations. This is an issue that came up with SAV 9, mp2. Fortunately, I was able to find a decent thread on installation techniques at Novell “Cool Solutions”:
I have changed our installed to run the installer using “setup.exe” (an install shield program), instead of “msiexec”. When using setup.exe, the installer appear to deal well with existing installations.
I have also added an additional .bat to the installer script… RemoveStartupScan.bat. This runs “reg.exe” to import a .reg file obtained from Symantec. The reg settings included disable the startup “quick scan” (DoScan.exe) that has been irritating Symantec clients since the release of 10.0. Symantec says that DoScan has been “fixed” with 10.0.1, but I still do not like it.
Finally, I am allowing installation of the Pop3Smtp component, although I suspect that we will just have to rip it out again in the near future. I thought we might give it a chance for now.