System Administrator Questions

WinAppxD was replaced by the APPX Login Manager in Release 5.0.0. See this page for installing & configuring the Login Manager.

2.1) APPX user ID's that are only 2 characters rather than 3 can't print. Help?

This was due to a bug in versions of APPX at or below 3.2.x. If
you are running 3.2.x or earlier, you must upgrade to a newer
version of APPX or change your APPX User ID's to 3-character ID's.
This restriction affects only the APPX user ID's, not the "System
ID" that is used to link the APPX user ID with the Windows network
user ID.

2.2) What do I put in the "System ID" field when adding a new APPX user to the APPX user list?

In that field, you should enter the Windows network login ID which
is used by that user, to authenticate him/her to NT. When you
enter this login ID, be sure that it matches exactly the case in
which it listed in the NT User Manager. Yes, we know that when NT
itself validates logins, it does case-insensitive comparisons so
that a user whose NT network login ID is 'SWilliams' can login
successfully as 'swilliams'. However, because other OS's do
case-sensitive login validations, APPX has always required an
exact match, including case, of system login ID when users sign on
to the APPX environment. We want the NT version to work the same
way that the other versions of APPX do.

Note: If you have installed NT 4.0 Service Pack 4, your NT Server
may be performing case-sensitive comparisons on login ID and
password, so if you enforce case-sensitivity on your network logins,
this might not cause as much "what combination of upper and lower
case did I use originally?" confusion as in prior release levels
of NT 4.

2.3) What is the "Password" field for?

This field is not applicable for users of WinAppxD. If you are
running a standalone version of APPX on a PC or notebook computer
which does not have Microsoft Networking installed, login password
validation cannot be performed by the operating system. This
field exists so that access to applications on such systems can
still be password-protected.

2.4) How do I define a new keymap?

We generally recommend that customers use the existing Windows
keymap that ships with APPX for Windows.

The best way to define a new keymap on APPX for Windows is to
login locally to APPX on your server (that is, by running 'appx'
directly, not by running 'appx -c') and define it there. There
are reports of problems defining new keymaps through 'appx -c'.
We strongly suggest leaving the default Windows keymap intact
and only editing NEW local keymaps.

For example, to define a new generic keymap called 'Wincorp',
you would invoke APPX at a command prompt on the server with:

C:> appx.exe -k -m=:Wincorp

After doing this, you would set APPX_KEYMAP=Wincorp on the
server machine and clients.

2.5) How can I find out who has a specific record in a specific file locked?

As of version 3.3 and earlier, this capability is not available.

2.6) We get USER32.DLL errors. Help?

There are two common reasons that customers experience "USER32.DLL
Initialization failed" errors. The first is a Windows NT default
resource limit which can be raised by editing the NT server's
registry according to instructions at URL:

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

The second is that the customer is using an old (pre-January 15,
1998) version of WinAppxD.exe.

The first thing you should do to resolve these errors is edit the
registry as described above. If you have modified the registry
and still receive USER32.DLL errors, please contact APPX Software
Technical Support to verify that you have the most up-to-date
copies of WinAppxD.exe and appx.exe.

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.

2.7) Where are the instructions for interfacing with UniQue?

Instructions for interfacing APPX Presentation Manager with the
UniQue print spooler from LBM Systems can be found here.

Instructions for interfacing the 'network disk' version of APPX
for Windows with the UniQue print spooler can be found here.

2.8) Can I intercept a print file before it is sent to the printer, and do something to it (like add font setup codes)?

Yes. By default, APPX sends its print files to winprint.exe.
However, by setting the environment variable APPX_PRT_SCRIPT to
the name of an alternate print file processing program (or .bat
file), it is possible to customize print file handling. This
variable MUST be set on the server, and its new value will not
be in effect for any APPX sessions until the server machine is
rebooted.

For example, if you set APPX_PRT_SCRIPT=mycustom.exe, and are
printing a file named 'prntfile', APPX will invoke your custom
print file processor with the command line:

mycustom.exe -config=prntfile.cfg prntfile

Inside mycustom.exe, you can inspect the file name, the contents
of the file itself, and/or the contents of the config file, to
programmatically add printer-specific font switching or other
control codes. You can then copy the modified file back to its
original name and from inside mycustom.exe, invoke the command:

winprint.exe -config=prntfile.cfg prntfile

on it to cause APPX to print the file, or do something else if
you prefer.

2.9) I get Dr. Watson errors when running APPX. Help?

When APPX gets certain kinds of errors, it crashes. There is
code in the APPX engine to write out a stack trace whenever a
"trappable" crash occurs. However, if Dr. Watson is enabled
on your system (as it is on most), the crash will cause Dr.
Watson to be invoked, rather than write out the stack trace.

APPX Software often needs the stack trace to diagnose software
failures. Therefore, if you are working with ASI to debug an
error that causes an APPX crash, please turn off Dr. Watson at
least temporarily, in order to permit APPX to write out the
stack trace.

2.10) How can I tell what versions of UniQue and OpenNT/Interix I am running?

The version of OpenNT can be gotten from the registry key:

\HKEY_LOCAL_MACHINE\SOFTWARE\Softway Systems\Interix

(As of 3/14/1999, the newest version is 2.2.400).

The following
Command will show the UniQue Version number:

\OpenNT\usr\spool\uprint\ulp -h

(As of 3/14/1999, the newest version is 3.31_25).

2.11) It takes a long time to start APPX from a client PC using the Win32 or Java client, but after it finally lets us login, performance is OK. Help?

Name resolution failures generally take a bit more than 2.5 minutes
(means you have a problem with name resolution on either the client
or server) or a bit more than 5 minutes (means both sides have a
name resolution problem), give or take a minute. [ 2.5 minutes is
approximately the time it takes for a DNS query to time out. ]

To diagnose if you have a name resolution issue, you DO NOT need
fancy network monitors and experts and the like. All you need is
"ping", the hostname and IP address of your APPX Server and (if
running the APPX Server on NT) the hostname and IP address of your
Primary Domain Controller (and any Backup Domain Controllers that
exist). You can get a machine's IP address by running "ipconfig"
at the command prompt and picking the internal network interface
(that is, not the one that starts 224, or 127, or the one labeled
dialup adapter!). Do the following tests:

1. Check that the client can resolve the APPX Server's host name.

Sit down at a client that is taking a long time to connect to
APPX. ping your APPX server (the one specified in the login
box when you start up APPX) by NAME and by IP address. If the
ping by IP address comes back in a second or two, and the
ping by name takes a while, the client has a name resolution
problem. This typically means that the DNS servers specified
on the client machine do not know about the server (often the
case in situations like the above where only Internet DNS is
used, and one is on an internal network; also can be the case
if there is a local DNS server but the APPX server machine is
new and its name hasn't been added to it yet; also can be the
case if the list of DNS servers on the client is incomplete.)
If after fixing the problem on the client side, it's still
slow, but has gotten a bit faster, proceed to step 2.

2. Check that the APPX Server can resolve its own host name.

Sit down at the APPX server that is running WinAppxD or appxd.
Ping the server by its IP address. Ping the server by its name.
If the ping by IP address comes back in a second or two, but
the ping by name takes longer, the server has a name resolution
problem. See the typical reasons for this above. If after
fixing this (or not finding a problem here), it's still slow,
proceed to step 3.

3. Check that the APPX Server can resolve the PDC's host name (and BDC host names), if you are running APPX Server on a Windows NT box.

If you've eliminated problems 1 and 2, either by fixing them
and verifying that pings by name and IP address now take about
the same amount of time, or by doing the above tests and not
seeing a dramatic difference between ping times, the problem
is slightly different. In this case, you are probably running
APPX on an NT server (rather than a UNIX box) and the Primary
Domain Controller is probably a different machine than your
APPX Server. And what's happening is that the APPX server
is having name resolution problems finding the PDC, when it
tries to log the user into NT behind-the-scenes. Sometimes
this indicates a DNS problem, other times it indicates a WINS
problem (yes, NT uses two different name resolution services,
depending on how it's set up). To see if it's a DNS issue,
sit at the APPX server and ping the PDC by name and IP address.
If the ping by name is much slower than the ping by IP address,
by now, you probably have know what the trouble is -- DNS doesn't
know about your PDC. If you're not using DNS, make sure the PDC
is in the HOSTS file on your APPX server. If you are using DNS,
make sure your DNS tables include a record for the PDC's name
and IP address, and the names and addresses of all BDCs defined
on your network. If that didn't solve the performance problem,
you're all out of DNS problems, and have to look at WINS, which
is a Microsoft-specific name resolution service. You might run
into WINS performance issues if your network is set up to use
WINS (don't immediately discount this -- some are!) and the Windows
name of the PDC machine isn't the same as its TCP/IP hostname.
Typically, the problem would be that the APPX server doesn't
have a WINS server specified (or has the wrong WINS server name
specified). One way to see if you have a WINS issue might
be to sit at the APPX server, login as Administrator, open up a
Command box, and do the command "net view \\PDCNAME" (where PDCNAME
is the name of your domain's Primary Domain Controller box). If
it takes a while for it to come back (longer than a few seconds),
check your WINS configuration.

I don't want to use DNS. How do I put static IP address information
into my machines' "HOSTS" files?

All APPX clients and the APPX Server should have a hosts file, if you
have decided to go this route. At a minimum, this file needs to look
like:

142.42.42.1 appxserverhostname
142.42.42.2 pdchostname

That is, two lines. The first is the IP address of the machine running
winappxd, followed by at least one space, then the name of that machine.
The second is the IP address of your network's Primary Domain Controller
for the domain that validates logins, followed by at least one space,
then the name of the PDC. If you have BDC's, you would want to include
a line for each of them as well.

The HOSTS file lives in different places, depending on whether you
are running Win9x or Windows NT.

In Win9x: \windows\hosts
In NT: \winnt\system32\hosts

(Of course, if you've installed Windows into a different directory,
you'll want to change the first part of those paths above.)

This SHOULD improve your response time dramatically, and is useful
for small networks as well as a temporary fix to get a site up and
running without having to wait several days for an appointment with
a network techie to set up DNS on your LAN if the site's network
administration is done by an outside party.

2.12) Automatically update Presentation Clients to the most recent version!

Here's a nice low-budget way to "distribute" APPX from a central
server to client workstations, making sure that clients always run
the most up-to-date version.

The following batch file can be loaded on your APPX NT server, and
run by each client wanting to initiate a thin client session.

Under this scheme, clients always execute a local copy of appx.exe -c
as recommended, but when the appx.exe client is upgraded, it is not
necessary to distribute the new executables out to all the clients!

echo off
xcopy \\rocky_bdc\appx\appx.exe %temp% /d
start %temp%\appx.exe -c

The /d switch on the xcopy command only executes the copy if no
destination file exists or if the date/time on the source is later
than on the destination.

The start command then executes the local copy of the executable.
This works Win 95/98 and NT Workstation clients.

Thanks to Steve Glore of Consolidated Meat Group in Australia
<glores@meat.aust.com>!

Comments:

Read what other users have said about this page or add your own comments.

---

Commenting is disabled while not logged in