Printing

Answers in this category:
How do I determine the CPU serial number on Linux platforms?
How do I determine the CPU serial number on Unix platforms?
How do I determine the CPU serial number on Windows platforms?
What operating system versions are required to run APPX?
Which TCP/IP ports are used by APPX?
How do I upgrade APPX 3.5 or 4.0 to version 4.1?
Where does APPX create temporary disk files?
How to set up License Servers under Novell thick client.
Appx Client/Server security considerations
How do I setup an APPX/NET client?
How to connect Appx to Oracle

"bad portable file - non-blank character found between portable fields"
How to install HASP on a windows system
How to install HASP on a Unix/Linux system
What is “xtra-gui”?
Can I install APPX to a mapped drive?
I am trying to connect to the APPX Demo server but get the message "Connection refused by host".
What software do I need on the client PC in addition to APPX running the WinAppxD Daemon?
How to install WinAppxD?
Where at Microsoft are the instructions for that NT registry patch we need for installing WinAppxD?
What special rights must be assigned to the account used to run the WinAppxD process?
What do we need to do differently if installing WinAppxD on an NT 'member server' instead of on a PDC or BDC?
I installed WinAppxD for the first time, and it isn't working, what now?
How do I run two versions of WinAppxD in parallel?
What environment variables must be set on the server?
When installing APPX clients using WinAppxD, what do I need to know about the server?
Can I keep the APPX client .exe file on a server and launch it from across the network on my clients?
Winprint won't print to all or some of my printers. Help?
What if my network includes more than one Windows NT domain?
What special rights must be assigned to the user accounts which will access APPX via the GUI client, Java client or AppxODBC?
What APPX-provided files are needed on client PC's?
If the base 'Data' directory is immediately under the appx engine (as it almost always is), does anyone know of any reason one would want to use APPXPATH?
After an upgrade of the system from 4.1.a to 4.2.3 there is no 0LC application. What's missing?
I am preparing to upgrade to 4.2. The installation instructions suggest that I copy the License Key file so it can be imported in the version.
What are required Windows rights for Appx ?
What are required UNIX permissions for Appx 4.2.4?
Setting HP-UX Kernel parameters
Recommended system configuration for running APPX.
Exporting and importing design files on different platforms.
Emergency Registration for Supported Customers
Is there a work around or environment variable that suppresses the "keep key" behavior?
How to install Appx on a Cluster
How to convert an HFS or Vxfs filesystem from a nolargefiles system to a largefiles system
What is the environment variable for identifying the Ethernet adapter for the APPX serial number?
I am trying to import a file to Oracle, but getting an error "File doesn't exist".
How do I upgrade APPX 3.5 or 4.0 to version 4.2?
What does Error message "Can't load Oracle dll (oci.dll)" mean?
How to manually install Appx on Linux?
I have Appx/Net going, but unable to scratch a file from the client side. Should i be able to?
What does error message "Missing or invalid process definition record, 0LA subroutine SESSION (BEGIN)" mean?
New Item
How to set APPX_PIVOT_YEAR?
When i try to login to Appx from my HP Notebook, i get an error "Negotitating GUI Interface" and it hangs

Answers in this category:
Print files truncated
Is the 'mpage' program required to print text files from the 4.2.4 client?
I just installed Appx 4.2.4 On SunOS 5.8 and have a problem with printing
What is the maximum size of a report?

This is probably a problem with the printer driver default truncating at 8". To get around this, put into 'Printer Options' for the printer in question:

    -form_id="U.S. standard fanfold"

(The above parameter was obtained from loading the DOS prompt in the data directory containing Winprint.exe, then typing "winprint". This gives you all possible Winprint parameters/switches.)

    Why are my labels in an output PDF report being truncated?

Look for the following section in appx_print.  Remove or comment it out.
If you are doing client-side printing, appx_print will be in the client
install directory.  Otherwise, look for it in the $APPXPATH directory on
the server.

This is only for non-windows operating systems. Windows client and server
systems do not use mpage or appx_print.

#
# default format if one wasn't specified
#
if [ "$FORMAT" = "" ]
then
 FORMAT="MPAGE"
fi

You need to modify your appx_print script and replace born shell (/bin/sh) with korn shell (/bin/ksh).
In addition, you might need to modify your filters found in $APPXPATH/filters/ASI: MPAGE, PCL and PDF.

Module: RT.C.4903
Process: 0LA/Input - PRINT ON SCREEN
Bad Prt Write - Error - Already on File

When using a Form defined with a length of zero, the maximum size of a text report displayed on the screen is 65,535 lines. If the Form Length is not zero or the Form Type is PDF there is no limit.

# /sbin/ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:50:56:A6:4F:CB
...
...
The ifconfig command will return several lines of information for each network adapter that is installed on your Linux system. APPX uses the MAC Address (HWaddr) of the ethernet adapter that is installed at eth0 as the serial number for the license key. In the example above, the serial number you should specify when requesting a license key is:
00:50:56:A6:4F:CB

IBM RS/6000 AIX and HP 9000 HP-UX
To determine the serial number, type the command "uname -a" (without the quotation marks, of course). This will display a line of information about the machine, including the serial number. APPX expects a 10-digit serial number. Note that the RS/6000 often displays 12 digits, with extra leading zeroes. In that case, it is the rightmost 10 digits that should be relied upon. Example: 0012345C00.

SUN Solaris
The serial number reported by most Sun machines is not the correct one for APPX licensing. To obtain the correct serial number, you must install and run the "hostinfo" utility, available here: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-su.tar.Z

NCR and SCO
Machine serial numbers are not available on these platforms, so APPX must be installed with a hasp. The hasp will be labeled with its serial number. It should be eight hex digits, and any letters will be capitalized. Example: 1ABC234D

Linux
Linux licenses are tied to the MAC address. Instructions for obtaining that information can be found at http://board.appx.com/cgi-bin/fom.cgi?file=52.

Alternate Method
The "hostinfo" utility, mentioned above for SUN Solaris, is also available for other Unix platforms. Download the version for your platform:

HP9000 HP-UX: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-hp.tar.Z
IBM RS/6000 AIX: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-ib.tar.Z
Linux: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-li.tar.Z
NCR: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-nc.tar.Z
SCO: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-sc.tar.Z
SUN Solaris: http://www.appx.com/ftp/appx/support/utilities/hostinfo/info-su.tar.Z

Note: A foolproof way of determining that you have the correct serial number on any platform is to start APPX. Without a valid license, the system will display the serial number it finds on the machine. If APPX is running, serial number and license information is found in System Administration.

To determine the serial number, exit to a DOS (command) prompt, and type the command "dir c:\ /p" (without the quotation marks, of course). This will display the first page of a directory listing for the root directory of the C-drive. The second line displayed will contain the serial number, like this:

Volume Serial Number is 1A2B-C3D4

That is the number that APPX requires, but it will be reformatted when entered on your license and when displayed by APPX. APPX makes three alterations to the serial number:

Add a leading zero and hyphen

Change all upper-case letters to lower-case

Remove the hyphen between the two groups of characters

So, the serial number 1A2B-C3D4 will be entered and displayed in APPX as 0-1a2bc3d4.

Note: A foolproof way of determining that you have the correct serial number on any platform is to start APPX. Without a valid license, the system will display the serial number it finds on the machine.

Risc Processors:
IBM RS/6000 - AIX 4.3.3 & higher (the last version of Appx that will run on 4.3.3 is 4.2.7)
HP - HPUX 11.0 & higher
SUN (Sparc) - Solaris 8; SunOS 5.8 & higher

Intel & Intel Compatible Processors:
Linux - Redhat 7.2 & higher
Linux - Redhat Enterprise Server 2.1 & higher
Windows - 98/98se/me/NT4/2000/2003
NCR SRV4 MP-RAS Version/Release 03.02.00.39
SCO OpenServer Enterprise System (ver 5.0.4p)
DG/UX R4.20
NOTE: 4.2.a java client will not run or install on Windows 98

Risc Processors:
IBM RS/6000 - AIX 4.3.3 & higher
HP - HPUX 11.0 & higher
SUN (Sparc) - Solaris 8; SunOS 5.8 & higher

Intel & Intel Compatible Processors:
Linux - Redhat 6.2 Kernel 2.2.14-5.0
Linux - Redhat 7.1 & higher
Linux - Redhat Enterprise Server 2.1 & higher
Windows - 98/98se/me/NT4/2000/2003
NCR SRV4 MP-RAS Version/Release 03.02.00.39
SCO OpenServer Enterprise System (ver 5.0.4p)
DG/UX R4.20

The APPX Connection Manager "listens" for connection requests on a configurable, TCP/IP port. The APPX Connection Manager can be configured by a system Administrator to use the port of your choice. The default port is 8060.

On Unix and Linux, the APPX Connection Manager (appxd) runs as a daemon and is typically started by running $APPXPATH/../tools/start-appxd.sh. The desired TCP/IP port can be configured by editing this script.

On Windows, The APPX Connection Manager (appxdsvc.exe) runs as a service. The desired TCP/IP port can be configured via a command line argument when the service is started.

2) Download Appx 4.1 from our www.appx.com > Downloads > APPX Server Releases.

3) Run setup.exe (Windows) or install.sh (Unix), overlaying 4.1 on top of 4.0.
You must be logged in as Administrator in Windows, and as root under Unix.

4) Delete all EM and Dbg directories ($APPXPATH/*/*/EM and $APPXPATH/*/*/Dbg) for all of your Design Files and the Appx 0-App files.

5) Scratch all '$APPXPATH/*/Tmpdata' directories.

6) Create system files new to 4.1: Run System Administration > System Setup > System Administration File Management > Create Files.

7) Go to System Administration > Database/Applications > Applications.
Go down the list of your Applications.
For each, perform 'Design File Management' > "Convert From Pre 4.1 to 4.1".
Do *not* do this for the four "0-apps".

8) Optionally run "Create Executable Modules" while on the Design File Management screen.

9) For users using the GUI Appx/Client, download and install the current 4.1 Appx Java Client onto their PCs.
For users using the Win32(Windows) Client, download and install the current appx.exe client onto their PCs.

10) Once 4.1 is operational, update its Structure files to prevent future export/import problems:

10a) Delete each Application's APPXPATH\vv\aaa\Struct directories and their contents, where aaa\vv is your ApplicationID/Version#.
Do not delete your four 0-app APPXPATH\00\0*\Struct directories.

10b) Run System Administration > Database/Applications > Applications > Design File Management > Create Files, for each Application/Version pair, to recreate its Structure files.

$APPXPATH/aaa/Tmpdata

where:
$APPXPATH is the standard APPXPATH directory
aaa is the Application ID of the application that is creating a temp file

For Novell installations without a hasp, you can pick a single user's PC to act as the license server. Get the hard drive serial number for the license. Set up to run appx -l=c:/licenselog.txt in the Windows startup. You have to make sure this PC is always the first one to start Appx so the license server finds the right serial number.

On each client, do a full Appx install, then set the Appx environment variables you will need. You MUST have APPX_0SA_PATH=<location of appx on network drive>. That is what lets you maintain one set of system admin files for users and such. Appx runs locally, but access 0SA on the shared drive. Set up an FMS group for your application according to the links:

    FMS Path:               R:\APPX\data
       (where R is the shared drive and path to the network Appx installation) 

    FMS Group Attributes:   EM=C:\APPX\local_data

This accesses data on the network drive and creates the EMs on the client PC. This makes the app run faster since the EM does not then need to be copied across the network.

To use the GUI client, just run it using the local tab to point to the client's local copy of Appx.

www.appx.com/assets/asp/dynamic_generator.asp?pageid=608 www.appx.com/assets/asp/dynamic_generator.asp?pageid=626 www.appx.com/assets/asp/dynamic_generator.asp?pageid=695 www.appx.com/assets/asp/dynamic_generator.asp?pageid=707

As long as the hasp is attached, I would not rely on the serial number reported within APPX. The only sure way is to check the c-drive serial number of the server.

- The owner of the WinAppxD process has to be a member of the Administrators group.

- The owner of the WinAppxD has a local policy of "Act as part of OS".

- APPX users have to have an account on the server.

- SRVANY.EXE is used to run WinAppxD as a service.

We don't perform the authentication ourselves, we let Windows do that for us (the client must provide a user id and password and we give those to Windows for authentication). If the user proves his identity to Windows, we use the security token returned to create the child Appx process.

I don't think that the WinAppxD must be owned by a member of the Administrators group, but that is usually most convenient. We need the SeTcbPrivilege ("Act as part of the OS") in order to ask Windows to authenticate the user.

When we start the Appx server process, it inherits the security context of the user logging in. (That's why each user needs an OS account.)

That's all pretty secure. We require a password and user id that is authenticated by Windows. We don't give the Appx server process any privileges other than those held by the user. If we did anything else, we'd be bypassing the Windows security mechanisms. For example, if we supported HTPASSWD authentication, we would have to bypass the normal authentication performed by Windows.

 ---

 ---

The Windows OS user account must exist, but can be disabled (i.e. no password, not just a secret password). One might best be served by reworking his application to use combination of htpasswd and Appx based users, where you could have user tables inside of Appx.

 ---

The only file that needs to be installed on the desktop computer is the APPX/Windows executable (appx.exe). This is the same executable file that is needed when configuring a Windows desktop computer to use the APPX/Win32 Client.

The following three environment variables must be set.

APPXPATH=<dir>
APPX_DATA_SERVER=<hostname>:<port>
APPX_UID=<user>:<password>

where:
<dir> is the desktop directory where the APPX/Net client will create Em's and other temporary files that may be needed.
<hostname> is the hostname or IP address of the server where APPX is installed and where an APPX Connection Manager (appxdsvc/appxd) is running.
<port> is the TCP/IP port number that the APPX Connection Manager is listening on for login requests.
<user> is the user ID that is to be validated by the Connection Manager and which will be used for the APPX session.
<password> is the password that will be validated by the Connection Manager

Windows PC's can run an APPX/Net Client by setting the appropriate environment variables and then running appx.exe (without the -c command line switch). This can be done in a batch (.bat) file or from a Command Prompt. An APPX/Net client is a "thick client" that actually runs the APPX session on the desktop computer but performs all file I/O through an APPX/Net connection to an APPX FMS Server session runing on the server where APPX is installed.

Example where:

<dir>=c:\appxnet
<hostname>=myappxserver
<port>=8060
<userid>=joe
<password>=please


set APPXPATH=c:\appxnet
set APPX_DATA_SERVER=myappxserver:8060
set APPX_UID=joe:please
c:\appxnet\appx.exe

You must install a package called "Oracle Client Software" on appxhost. As of Appx 4.1.a, you must install Oracle Client version 8, the version we built our 4.1.a engine against. (ecr #6417, 7008)

Appx connects to Oracle using the Oracle Client software (called the OCI). The OCI must be able to find a few configuration (and localization) files using the $ORACLE_HOME environment variable. (If you don't have $ORACLE_HOME properly defined, Appx displays the error message: "*Oracle initialization failed".) The typical way to define $ORACLE_HOME is to use the oraenv shell script. Just run: ". oraenv"

When Appx connects to Oracle, there are three different ways that the OCI can locate the Oracle server:

1) Enter a server name in the Appx/Oracle FMS group (either an Oracle SID, or the name of a remote server as described below).

2) If you leave the server name blank, the OCI uses the environment variable $TWO_TASK to locate a remote server.

3) If you leave the server name blank and $TWO_TASK is not defined, the OCI uses the $ORACLE_SID environment variable to locate a local server.

You use $ORACLE_SID when appxhost and oraclehost are the same machine. You use $TWO_TASK when appxhost and oraclehost are different machines. The $ORACLE_SID environment variable refers to an entry in the /etc/oratab file (created by Oracle).

Here's a sample /etc/oratab file:

  # This file is used by ORACLE utilities.  It is created by root.sh
  # and updated by the Database Configuration Assistant when creating
  # a database.
  #
  # A colon, ':', is used as the field terminator.  A new line terminates
  # the entry.  Lines beginning with a pound sign, '#', are comments.
  #
  # Entries are of the form:
  #   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
  #
  # The first and second fields are the system identifier and home
  # directory of the database respectively.  The third filed indicates
  # to the dbstart utility that the database should , "Y", or should not,
  # "N", be brought up at system boot time. 
  #
  # Multiple entries with the same $ORACLE_SID are not allowed.
  
  *:/opt/oracle/product/9.2.0:N

  oracle:/opt/oracle/product/9.2.0:N

The $ORACLE_SID here is 'oracle' and the $ORACLE_HOME is '/opt/oracle/product/9.2.0'.

The oraenv script examines the /etc/oratab file._ oraenv uses a command named dbhome to find the $ORACLE_HOME location given an $ORACLE_SID

The $TWO_TASK environment variable refers to an entry in the tnsnames.ora file (located somewhere in the $ORACLE_HOME directory tree)._ Here's a sample tnsnames.ora file:

  ORACLE.INTERNAL.APPX.COM =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = badger.appx.com)(PORT = 1521))
      )
      (CONNECT_DATA =
        (SERVER = DEDICATED)
        (SERVICE_NAME = oracle)
      )
    )

The OCI supports many different protocols. TCP is probably the most common. On Windows machines, you'll find named-pipe servers. The fastest transport mechanism (which can only be used for local servers) is the bequeath adapter which uses shared memory to communicate between the client (appx) and the server (oracle).

Here's our recommendation for finding all of the magic values you need:

1) If you know your Oracle server is installed on the same machine as your Appx server,

   a) Examine the /etc/oratab file to find your Oracle SID

   b) Examine the /etc/oratab file to find your $ORACLE_HOME

   c) Make sure $ORACLE_HOME is defined in your start-appxd.sh script

   d) Create an Oracle FMS group (type 5) and enter the Oracle SID
      in the server name field 

   a) Examine the /etc/oratab file to find your $ORACLE_HOME.   (In this
      case, $ORACLE_HOME will tell the OCI where to find config files.)

   b) Examine the 'tnsnames.ora' file to find your remote server name.

   c) Make sure $ORACLE_HOME is defined in your start-appxd.sh script.

   d) Create an Oracle FMS group (type 5) and enter the remote server
      name in the server name field.

  http://www.appx.com/assets/asp/dynamic_generator.asp?pageid=605

How to Debug an APPX/Oracle Connection:

  http://www.appx.com/assets/asp/dynamic_generator.asp?pageid=682

The easiest diagnosis in this case is to enter a couple of records into the AppxIO data for the file with the problem, then export it and run it through 'appx -e={filename}' to get it into an ascii readable format. Then, run the problematic Portdata/{filename}.dat through 'appx -e={filename}' (renaming as needed). Then, compare them against each other, comparing the ascii data format Appx was expecting to receive (the data just entered) against the ascii data you were attempting to import.
`

How do I upgrade APPX 3.5 or 4.0 to version 4.1?

To fix this problem, scratch all the Design file "./data/*/*/Struct/" directories on the machine you're trying to import from *EXCEPT* the 0-app /Struct directories. Then run 'File Create' on all those Application Designs, to recreate those Struct libraries. Then re-export your "import from" machine's Design files, transport them to the "import to" machine's Portdata directory, and try the import again.

http://www.appx.com/assets/asp/dynamic_generator.asp?pageid=626

http://www.appx.com/assets/asp/dynamic_generator.asp?pageid=633

The reference to "xtra-gui" can be ignored. There is no package by this name to install when installing APPX on a server. The reference will be removed from the installer text.

The TCP/IP network protocol. The APPX client uses TCP/IP to communicate with APPX Presentation Server.

If the client is a Windows 95 machine, and you EVER anticipate sharing the network drive containing the APPX application data files and running appx.exe (not appx -c) at the client with APPXPATH set to that network drive, you MUST install the Windows 95 network file redirector fix provided by Microsoft at

        http://support.microsoft.com/support/kb/articles/q148/3/67.asp 

to avoid the potential for APPX data file corruption due to a bug in Windows 95. If you don't do this now, you may forget to do it later, corrupt your data files, and spend hours on problem resolution and recovery. You would not be the first person it's happened to. You have been warned.

        NOTE ABOUT URLs:  Microsoft periodically rearranges its web
        site, so the above URL may or may not be valid.  If you can't
        find it, use the "Search" option on the MS web site, instructing
        it to look in whatever choice includes the "Knowledge Base".
        Specify "Qnnnnnn" as what to look for, where nnnnnn is the number
        between the "q" and the ".asp".  For example, in the above, it
        would be Q148367.  That should enable you to locate the article.

http://www.appx.com/assets/asp/dynamic_generator.asp?pageid=586

     http://support.microsoft.com/support/kb/articles/q142/6/76.asp 

        NOTE ABOUT URL's:  Microsoft periodically rearranges its web
        site, so the above URL may or may not be valid.  If you can't
        find it, use the "Search" option on the MS web site, instructing
        it to look in whatever choice includes the "Knowledge Base".
        Specify "Qnnnnnn" as what to look for, where nnnnnn is the number
        between the "q" and the ".asp".  For example, in the above, it
        would be Q148367.  That should enable you to locate the article.

       - Act as part of the Operating System
       - Replace a process-level token
       - Increase quota
       - Logon as a service (if it's not already set)

If you do not see these rights in the list box in User Manager, click "Show Advanced Rights" and they should appear, so that you can assign them.

The extra work is required because of NT security mechanisms. Most NT wizards will not think this is necessary. However, straight from Tier 3 MS phone support, it really is. Setting the rights without connecting to the specific machine will only work if you are running WinAppxD on a PDC or BDC.

Verify that you can, directly on the server (without using the "appx -c" client option), login to APPX. Being able to do this is a necessary pre-requisite to being able to login from clients with "appx -c". Go no further in this troubleshooting process until you can successfully login directly on the server as with any standard (non-Presentation Server) APPX for Windows installation. Common things to check if this doesn't work are the APPX_KEYMAP and APPXPATH variable settings and data file permissions.

Once you're logged in on the server, check to make sure that you have a Registration license for the APX/GCS product. This is required, to run APPX in APPX Server mode.

If when you try to login with a client, you receive an error like "Incorrect login," see the FAQ "Troubleshooting WinAppxD".

If, when you try to login with a client, your client session hangs BEFORE showing any APPX screen, make sure you have the following environment variables set in the global System section of User Environment variables on your NT Server:

          APPX_SERVER    - set to full path of appx.exe
          APPX_KEYMAP    - set to "Windows"
          APPXPATH       - set to your APPX data directory

If you change any of these now, reboot the machine to make them take effect, then re-test the client login.

If, when you try to login with a client, you get the error "host unreachable" or "host not found", verify that the server's host IP address (or name) and port number specified in the login dialog box are correct. Also check again to make sure that WinAppxD is running. If you have the dialog options set correctly, but WinAppxD exited with an error as soon as it was started, the client will not be able to contact WinAppxD and you will get errors like these. "Host unreachable" is generally misleading because the host is usually there just fine, it's just that WinAppxD isn't listening for connections.

To verify that you are using a valid host address that is reachable from the client, go to a DOS command prompt on the client and "ping" the server address you put in the connection box on the APPX client.

If something else is happening, or if you've followed the procedures outlined here and WinAppxD still isn't working, please call APPX Software Technical Support for assistance.

To do this, set up your services to run batch files that set the appropriate environment variables, then launch WinAppxD.exe. (Instead of running the services running WinAppxD.exe directly.) Different services run different batch files, which start WinAppxD's with different ports and other environment variables.

     APPX_SERVER - Full path to the appx.exe on the server.  Make sure
                   that you reference a drive that is available from
                   the server, not a network drive that is only visible
                   from clients

     APPX_KEYMAP - Normally set to "Windows", but you can set it to
                   a different name if you wish to customize the
                   keymap

     APPXPATH    - Full path to your APPX data directory

These variables MUST be set on the server. New values will not be in effect for any APPX sessions until the server machine is rebooted.

              C:> ipconfig /all

from a DOS command prompt on the server. If it lists more than one network interface and IP address, ask the network tech.

The port the APPX Presentation Server (WinAppxD) has been set to listen on. If you installed APPX Presentation Server, you should know what this is. It is the number you typed after "-s=" when editing the registry entry for WinAppxD. Unless you opted for a different port number because you're running multiple versions of APPX, or because some software at your site was already using the APPX- recommended value, it is probably 8060. Check the registry key:

         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinAppxD

(or WinAppxD2, or WinAppxD3, etc. if you are running multiple versions of APPX) for the number following "-s=" in the "Application" entry.

If you really, really, really are set on the idea of storing the client on a central server, be warned that the typical failure symptom you will see when you push your network too hard, will be APPX clients "just disappearing" seemingly randomly. If you see things like that, or if processes that normally work randomly lock up client computers, and you have ANY clients ANYWHERE on your net loading appx.exe across the network, please set all clients to use a LOCAL copy of appx.exe and see if that takes care of the problem, before you call APPX Technical Support.

If you are that concerned about the maintenance headache of updating several dozen clients' copies of appx.exe when a new version comes out, consider investing in one of the network software management packages out there, like Microsoft's SMS. (This isn't an official APPX "go out and buy it" recommendation, just a word to the wise regarding something you might want to consider.)

APPX doesn't want to run my APPX_PRT_SCRIPT. What am I doing wrong?

Nothing, most likely. However, current versions of APPX blindly pre-penned the APPXPATH to the value of APPX_PRT_SCRIPT. In order for APPX to properly invoke a replacement APPX_PRT_SCRIPT:

        - your replacement print script must be in the APPXPATH directory
        - you must set APPX_PRT_SCRIPT to the file name, not including
          any directory or drive letter information in front of it (for
          example, you might set APPX_PRT_SCRIPT=myprint.exe)
        - APPX_PRT_SCRIPT must be set ON THE SERVER (not the client;
          remember, when connecting to APPX Presentation Server, the
          SERVER controls the printing), along with APPXPATH and the
          other standard variables.  Generally this is done from
          Control Panel / System / User Environment.  Remember to
          reboot after you change this.

Since running APPX directly often results in better messages than when it's run through appx -c, see if you can reproduce the "won't print" error when running APPX directly on the server, and if you get an error message dialog box.

If you get an error message that isn't self-explanatory, please call APPX Software Technical Support for assistance.

If you don't get an error message, follow the "Winprint won't print to my printer" instructions in the "Troubleshooting WinAppxD section of the FAQ.

WinAppxD validates client users using the domain name found by running LookupAccountSID() against the NT account used to start up WinAppxD. Typically, this means that any client users running "appx -c" must be defined in the same domain in which the APPX server participates, because when WinAppxD is defined as a service, it starts up in the domain the server is assigned to.

This means that if your APPX server running WinAppxD is a member of your UsefulApps domain, that users which are defined ONLY in your CorpUsers domain will not be able to login to APPX. If we looked on the client to see which domain the client user was logged into and sent that info to the server, it would work, but today (as of 3.3) we do not do that. You are restricted to validating logins only in the same domain your APPX server belongs to.

DESPERATE to get around this? If you don't use your server for much else besides APPX, and it's in a secure room or you don't mind running a locked screensaver all day, you might be able to do it. Just walk up to the APPX server machine and login to your master domain, or useraccounts domain, or whichever domain your user accounts are found in. Make sure you are using an account in the Administrator group, and which has the four magic user rights set (as documented elsewhere in the FAQ). Now start winappxd from a DOS Command prompt using a line like:

        c:\appx> winappxd -s=8060

This should cause WinAppxD to use the currently logged in user's domain for authentication. If you were able to successfully run winappxd as a service before trying this, using this technique should not cause it to "break". If you read this FAQ prior to installation and decided to skip the whole process of running WinAppxD as a service, then please make sure that the APPX environment variables APPXPATH, APPX_SERVER and APPX_KEYMAP are set for your current command shell by doing a "set |more" before running winappxd.

This right must be set on the APPX Server. If your APPX Server is not the same machine as your PDC, please see item 1.7 for how to do this -- this right must be set at the machine level, not the domain level, for security reasons. Otherwise, just login as Administrator, and run User Manager for Domains (or just User Manager if you're using NT in a Workgroups setup).

The best way to do this, since you'll probably have lots of APPX users, is to assign this right to a group, rather than individual users. Although the quickest way to do this is to assign this right to the existing group "Everyone" or "Domain Users", it's better from a security standpoint if you create a group like "APPX Users" and assign the right only to that group. This way, you know that only users you've explicitly added to that group, have that added right. The downside is that you will have to remember to add users who will be accessing APPX to that "APPX Users" group.

The following is true for XP and Windows 2003 Server and newer. (actually this is true for all Windows but NT and 2000 default to these rights)
All APPX OS users require "Modify" rights to the APPX Directory and all contents (recursive - this is important).
All APPX OS users require "Modify" rights to the APPXODBC directory and all contents (recursive - this is important).
This must be done. It must be done by hand (ie you can't just will it to happen -- if you can, please come see me). It may be done by username or by group membership.

chown -R appx:appxgrp /usr/local/appx/
chmod -R 775 /usr/local/appx
chown root /usr/local/appx/tools/appxd
chmod u+s /usr/local/appx/appx
chmod u+s /usr/local/appx/tools/appxd

                  4-users  16usrs  32users  64users
    nfile            1000    4000     8000    16000
    nflocks           500    4000     8000    16000
    ninode            750    3000     6000    12000
    maxfiles          512    2048     4096     8192
    maxfiles lim     1024    2048     4096     8192
    semmnu             30      48       96      192

    nfile        - 1 for each file opened by each user on the system
    nflocks      - nfile + 1 for each locked record on the system
    maxfiles     - 1 for each file opened by a given user
    semmnu       - 1 for each APPX session (user or background)

APPX Software does not certify any configuration. There are too many variables that can affect performance that we have no control over. For example, information relating to the type of APPX applications or the perfomance characteristics of the APPX applications that will be run on the system. We also do not know which applications other than APPX might also be installed on the same machine. Response time is also very subjective. A response time of one second may be very acceptable to one user but not to another. We also have no information regarding how much disk space is needed by the APPX applications or any other applications that might be installed on the machine.

What may be happening is that you have used an FMS group to redirect the AppxIO files (in other words, the AppxIO files are not in their usual location when you do the export). That means that the Portdata files are not in their usual location either. When Appx tries to import (using your Oracle FMS group), it can't find the Portdata files (thus the File Does Not Exist error).

If that is the case, this is easy to fix. Find the FMS group that holds your AppxIO files (let's call that the APPXIO FMS group) it has an FMS type of 1. Make a note of the FMS Path for that FMS group. Now find your Oracle FMS group (let's say that one is named ORACLE) and it has an FMS type of 5. Now make a new FMS group (type 1 this time), but give it the same name as your ORACLE FMS group. In this new ORACLE (type 1) FMS group, enter the FMS path that you wrote down from the APPXIO FMS group.

That should take care of the problem.

The root of the problem is that Portdata files are always AppxIO files - when you try to import from Portdata into Oracle, Appx is using the ORACLE FMS group to find the Portdata files. Since you don't have a type 1 FMS group named ORACLE, Appx is looking in the default location for the Portdata files - and they're not there. Creating a new type 1 FMS group with the same names as your type 5 ORACLE group will give Appx a way to find the Portdata files.

        (a)     Run ‘Create Files’

        (b)     Run ‘Convert From Pre 4.1 to 4.1

        (c)     Run ‘Sync Widget Elements’

        (d)     Run "Create Executable Modules"

11) In Application Design for each application, run Utilities => Toolbox => Conversion Utilities => Synchronize Design Elements.
12) For users using the GUI Appx/Client, download and install the current 4.2 Appx Java Client onto their PCs.
For users using the Win32(Windows) Client, download and install the current appx.exe client onto their PCs.
This procedure is used to upgrade from Appx releases 3.5 to release 4.2.

#
# Make the APPX directory and get inside it:
#
mkdir /usr/local/appx.427
cd /usr/local/appx.427/

#
# Fetch the APPX tar balls via wget
#
wget http://www.appx.com/ftp/appx/products/appx/server/4.2.7/comm_unx.tgz
wget http://www.appx.com/ftp/appx/products/appx/server/4.2.7/data_int.tgz
wget http://www.appx.com/ftp/appx/products/appx/server/4.2.7/exec_lin.tgz
wget http://www.appx.com/ftp/appx/products/appx/server/4.2.7/link_lin.tgz
(link_lin.tgz is optional)

#
# Un tar the tar files
#
tar xzf comm_unx.tgz
tar xzf data_int.tgz
tar xzf exec_lin.tgz
tar xzf link_lin.tgz

#
# set permissions and ownership of the APPX files and directories:
# Be very careful for typos. These are dangerous commands
# Make sure you understand them and verify they are correct for
# your system before you execute them

chown -R appx:appxgrp /usr/local/appx.427/
chmod -R 775 /usr/local/appx.427/
chmod u+s /usr/local/appx.427/appx
chown root /usr/local/appx.427/tools/appxd
chmod u+s /usr/local/appx.427/tools/appxd
mkdir /usr/local/appx.427/data/PRINT
chmod 777 /usr/local/appx.427/data/PRINT

#
# edit and modify the appx client daemon startup script
# edit /usr/local/appx.427/tools/start-appxd.sh and set
APPXPATH="/usr/local/appx.427/data", and APPX_PORT=8060. APPX_SERVER and APPX_KEYMAP should already be set.
Then start the appxd daemon and you should be able to connect to the server (appxd) on port 8060.
/usr/local/appx.427/tools/start-appxd.sh

You can now connect from a client. If you want a client installed on your linux desktop, then continue below:

#
# Start your X session. Open a command window.
# The install tool you are about to run requires a # running GUI desktop, so run the following commands # from the GUI command window:
#
# Fetch the Java based APPX Desktop Client with the wget tool:
#
cd /tmp
wget http://www.appx.com/ftp/appx/products/appx/client/4.2.7/java_lin.bin
sh /tmp/java_lin.bin

Follow the prompts to install APPX Desktop Client 4.2.7. Pay attention to where you install the program. I often will install it at /usr/local/AppxDesktopClient/ When it is installed, execute /usr/local/AppxDesktopClient/AppxDesktopClient

You can now connect in via the APPX DesktopClient's REMOTE tab to connect via TCP/IP, or via the LOCAL tab to connect via the local file system.