Category Archives: Document Imaging

Notes on installation/configuration/management of the XtenderSolutions suite of document imaging products in use at UVM

ApplicationXtender – 5.30 to 5.40SP1 upgrade planning

Previously I documented a rough outline of the AX 5.30 Infrastructure installation process:

With support for 5.30 expiring today, I think it high time we got our infrastructure up to date up to the most current version that is supported for use with SunGard Banner.

  1. Uninstall all previously existing AX components.  Purge any residual files from the IIS  publishing directories, “Program Files”, “Application Data”, and the registry.
  2. Set security for the global impersonation account according to the table on page 210 of the “concepts and planning guide”.
    1. Note that the account does not have to be a local administrator!
    2. However, the security accounts will have to have privileges to the resources accessed by the services (i.e. NTFS filesystems rights, shared folder access).
    3. Rendering Service –
      1. When granting rights to the DX data store, plan ahead.  Permissions could take a long time to apply.
      2. Requires Local Security Policy “Replace a Process Level Token” and “Adjust memory quotas for a process” rights.  Also, the “Allow service to interact with the desktop” box must be deselected in the “Log On” tab of the Rendering service properties.
    4. WebAccess.NET Services –
      1. Global Account needs only “Log on as a service” Local Security Policy assignment.  You can clear out all “legacy” security permissions as they are not needed for WebAccess!
  3. Install AX Desktop, installing all administration tools:
    1. msiexec /i “ApplicationXtender Desktop.msi” /qb ADDLOCAL=DocumentManager,AppGen,ConfigurationTools,ManagementTools
  4. Install the new License Server and install license file:
    1. Install the “ApplicationXtender License Server.msi” (FlexNet License Manager)
      1. Drop the .LIC license file into C:Program FilesXtenderSolutionsContent ManagementLicense Server
      2. Configure the Login identity of the “ApplicationXtender License Client Components” COM+ application to use the global impersonation account.  This component must be shut down to be reconfigured.  Details in EMC PowerLink solution esg92864.
      3. Restart the “ApplicationXtender License Service” Service.
    2. Install the “EMC License Server” (Proprietary License Server, to support DiskXtender)
      1. Install all current patches to the service
      2. Run the “License Server Administrator” GUI.
      3. Go to “Tools”, then “New License Wizard” to install the DiskXtender License.
  5. Install DiskXtender
    1. Install DiskXtender patches, in sequence
      1. When prompted for the DX service account, you must provide an account that has local “administrator” rights, and the ability to “log on as a service”.
    2. Verify and/or re-establish RPC partition maps – See the “Core Components” guide for instructions.
    3. Consider switching to DCOM security model, which will require modifying the “AE_PATHS” table in each data source db.   See page 160 of the “Desktop Install Guide” for details.
      1. This is not actually practical to do since it will break AX Desktop on any system that is not joined to the CAMPUS domain (and why would they not be joined, I wonder?)
  6. Launch AX Admin
    1. See “ApplicationXtender Desktop Installation Guide” for details
    2. Log in as SYSOP and perform the database upgrade, if prompted.
    3. Verify global settings:
      1. Add license server configuration: see “Core Components” guide for details.
      2. Web Access .NET must use Global credentials since we are using and Oracle database with Oracle security.
    4. Save the configuration and exit
  7. Launch AppGen, and verify functionality.
    1. Connect to each defined data source, one at a time.
    2. Perform database upgrades if prompted (this should be safe, but can take several minutes to complete).
  8. Set IIS web site root to use ASP.NET 2.0.
  9. Install AX Web Services, making sure to install the required “Utility Services” component.  “AX Web Services” and “Workflow” components are optional.
    1. See “AppXtender Core Components Admin Guide” for installation and config details.
    2. Choose IIS installation option, and install into “Default Web Site” (which should be the only site present)
    3. Ensure that “Default.aspx” is listed as an accepted default page for the “AppXtender” IIS web application.
  10. Install AX Web Access .NET
  11. Install AX Rending Server
  12. Run the Component Setup Wizard for all installed components
  13. Outside of my control:
    1. BannerXtender updates need to be applied to production Banner systems.
    2. DocSend and ECopy stations need to be upgraded to 5.40 AX Desktop releases
    3. DocAccel server needs 5.40 AX Desktop upgrade
    4. All AX desktop clients need updates, too.
    5. Anyone using WX WebAccess.NET ActiveX controls will need to upgrade these components.
  14. Test Test Test!

ApplicationXtenter Infrastructure Deployment Notes

It seems that I did not take good notes on how to install and configure ApplicationXtender server components. Bah… this made for some fun when rebuilding the test environment. Here goes…

  1. Install Windows Server 2003, Standard Edition, with IIS. 
  2. Bring up to current patch level
  3. Install Oracle Client software…
  4. we used with all patches present on the Prod servers. 
    1. This requires several passes though the Oracle Universal Installer.  First a “runtime” install, then run through again to install “Windows Support Components”, which includes the ODBC drivers that are needed for AppXtender.
    2. Then we need to do two more passes though OUI to install patches, then drop in a few patched DLLs, and finally copy the TNSNames.ORA file from the oracle home on Prod servers to the NETWORKAdmin folder in the Oracle Home on this server.
    3. Update for 2009 – We are now using the database client, but installation is still pretty much the same… you still need the annoying Oracle Universal Installer, you still have to run OUI two to three times.  Additionally, our DBA team has switched from use of the “TNSNames.ORA” file, to “SQLNet.ORA” and “LDAP.ORA”.  Data Source names are now retrieved from an LDAP lookup.  So, ditch the TNSNames file, drop in the new ones.  Also, you must now request a firewall exemption to the database server to make this connection.  Plan a day ahead of time to get access.
  5. Create XS_Global service account, or use existing one. 
    1. Add this account to the local administrators group
    2. Add the additional rights “Act as part of the operating system”, “log on as a service”, and “replace a process level token” rights using the Local Security Policy MMC tool.
  6. Install Legato Licensing Server (if needed… we did not need a new one this time around
  7. Install DiskXtender 2000.  Use existing licensing server if available.  You will need to create service accounts for DX.
    1. Start DX Administrator… you must be a Domain Admin or the local Administrator account.  Members of local Admins have no rights to the DX console!
    2. Extend the local drive that will house your images by going to service->new extended drive.  There are no additional settings that need to be configured here
    3. Under “Service” select “properties”, then “Settings”, and “Partition Map”.
    4. Click “New”, then defined mappings for “DXTEST” (or whatever name you want to give to your DX Instance).  There will ony be one option to choose from under the “Extended Drive” drop-down.
    5. Add another mapping to “OBJECTS”, which will be the subdirectory created by AX in the DX repository.
    6. On the Prod server, we also did the following: Run RegEdit, navigate to:
      Then Modify “TcpIpEndpoint” from 1050 to 6252. This will force DX to use a port that can be accessed from the campus LAN.
  8. Install all AX Binaries… Includes AX Administration tools, ApplicationXtender Administrative installation, WebXtender, Rendering Server, ApplicatonXtender Web Services (IIS Mode).
  9. Open the “System” control panel item.  Go to “advanced”, and under “performance”, click “settings”.  Go to the “Data Execution Prevention” tab, and add an exception for %ProgramFiles%XtenderSolutionsContent ManagementRender ServerWxRender.exe.  This prevents the renderer from crashing in a Server 2003 SP1 environment.
  10. Create shares for “rendering” and “wxsession”.  Both shared need to be accessed Read/Write by the XS Service account.  These allow the rendering service and webXtender service, respectively, to cache files that may need to be accessible to other servers in the AX infrastructure.
  11. Use the “data source selector” tool in the ApplicationXtender Program Group.  Define sources for IMGX and IMGY (test and pre-prod data sources).  You will need to specify the “server name” as “”, and “”, as this is how they are defined in the TNSNames file.  Note that you MUST use the Microsoft OLE DB Provider for Oracle, not the raw Oracle ODBC driver! 
  12. Start XtenderSolutions Administrator (XSAdmin forthwith). 
    1. Login as SYSOP user.
    2. On a new install, you would need to define “Windows Security” as the Security Model in the initial “Environment->Data Sources” window.
    3. Under “Storage->DiskXtender”, we need to have defined:
      Server Name=DXTEST, Connection Type=RPC, DX Network Address=DOCIMGTEST, Network Transport=TCP/IP. Also, on the Prod server, we have defined the “end point” port as 6252.
    4. Under “Storage->Paths”, make sure that any defined paths are valid. It is here that we define the connection to the “rendering” and “wxsession” shares that were created earlier.
    5. Under “WebXtender->Setup”, you must define the service account, and under “Email” you need to specify “” as the email server, then define a “from” address for the service.
    6. Under “Services->Rendering Server”, you again need to define a service account, then provide the “rendering” share created above as the Cache “location”.
    7. Under “Services->XS Web Services”, define a service account.
  13. Run “User Profile Administrator” in the XtenderSolutions Program Group. We set our users to NOT use the Interactive Client by default. However, using AppGen we have given all users the ability to change this setting.
  14. Run the “Component Setup Wizard” in the XtenderSolutions Program Group. Run through the wizard for each component in the infrastructure (XS Web, WebXtender, Rendering Server).
  15. Updated for 2009 – IIS Tuning:
    1. In IIS Admin, get properties on the default web site, access the “Directory Security” tab, and install a server certificate.
    2. Click “Edit” to require SSL for the site
    3. Go to the “Custom Errors” tab, and add our standard JavaScript redirect html file in place of the 403.4 error page… this will force users over to the SSL version of the site using a javascript redirect, instead of displaying an ugly error page.
    4. On the “Home Directory” tab, add a permanent redirect from the base web site URL to the “/AppXender” subdirectory
    5. Get properties on the /AppXtender subdirectory.  In the “Documents” tab, add “Default.aspx” as a default content page.  Failure to do so will result in an “403.14” error page.

Hunting down and exterminating uncompressed TIFFs

It seems that some of our constituients have not been paying overly much attention to the settings on their scanners. We have over 40Gb of black-and-white, text-only documents scanned at 24 BPP, uncompressed, consuming 10 Mb each!

This happened once before. My colleague Warren licensed a product called “2TIFF” to shrink the files in question. This works well, except in his case ALL of the images in an Application folder needed to be compressed. I only need to shrink SOME of them.

After much fooling around and wasting of time, I was able to use a win32 port of the UNIX “find” command to hunt down all of the large files, dump the list to a file, and then use this file as a source for 2TIFF. The big mess of images now occupies only about 30 Mb of space.

Here are the sommand syntax details:
> find.exe “I:OBJECTSPURCHASE_ORDERS” -size +3M -fprint bigfiles.txt
(searches the PURCHASE_ORDERS document tree for all files larger then 3 Mb, dumps results to the text file “bigfiles.txt)

> FOR /f %F in (bigfiles.txt) DO ( “C:Program Files2TIFF2tiff” s=%F d=%~dFshrink%~pF -namegen=”[name].[srcext]” -quantize8 -ct4 -cd4 -keepexif)
(Perform a loop operation. For each loop, set the next line in bigfiles.txt to the variable %F. Run the 2Tiff program using %F as the source file. Use shrink as the output directory (example: when %F=”c:objectsprocurement1163.bin, the output directory will be “c:shrinkProcurement1″).)

Here is what the 2Tiff arguments mean:
-namegen=”[name].[srcext]” -> The name of the destination file is the same as that of the source ([name] is a built in variable equal to the source file name. [srcext] equals the source file’s extention)
-quantize=8 -> sets the “quantization” level of the TIFF. This value effects the “sampling rate” and affects image quality. Eight is the maximum value, for best quality.
-ct4 -> Compression type “LZW” is used. This is the default type for color scans. We are using LZW rather than the standard “type 3” for B/W documents because tests showed that reducing these images to monochrome yielded very low quality in some cases. We are keeping some color information to allow anti-aliasing and thus better letter quality.
-cd4 -> Sets the color depth down to 4 BPP from the source 24 BPP. CD1 would be better, but as mentioned above, this results in poor readability of the destination TIFF.
-keepexif -> preserves EXIF tags in the destination file from the source. Probably there is no EXIF info in these files, but I thought we would keep it in case I am wrong.

Warren had used the “dither” switch, but IMNSHO this makes the target document look worse and also results in larger files.

Changing WX Client Modes

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).

Oracle Instant Client, continued

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.

Packaging ApplicationXtender

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:

  1. At the command line, go to the AX 5.20 installation directory.
  2. Run
    msiexec /a AxSetup.msi TARGETDIR=[working directory]
  3. Assuming the MSP file is in the same directory, run
    "msiexec /p /a [working directory]AxSetup.msi"
  4. Now just zip the working directory into a single file.

We do have some other options that may help with deployment:

  1. 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
  2. The install directory can be added to a self-extracting zip, which calls the SETUP.EXE.
  3. 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.

Legato License Service: RPC Port

I wonder if port of the problem I have been having connecting to the AX applications on IMGX owing to some sort of Firewall problem.

The only service that has been installed on any of the imaging servers that appears to be of any potential relevance is the “Legato Licensing Server” on DOCIMG1. Netstat -ano reveals that this service is listening at port 9152… this port is not available through the internal firewall.

I will switch this server to port 6252 (currently port of the 100-port range for RPC’s made available through our internal firewall). This setting is made in the registry at:
HKLM:SOFTWARELegatoLicense ServerRPC
REG_SZ Value: TcpIpEndPoint
After restarting the service and running another Netstat -ano, I now see that the license service is listening at port 6252. Yeah!

Update: Last week our WX instance broke… EMC support blames this on the port change. I have reverted to port 9152, and will need to get this exempted on the firewall.