Installation of WinAppxD

1) Installation of WinAppxD

1.1) What kind of machines and network do I need for server and clients?

For the server, fast disk and plenty of RAM are helpful in getting
the best possible performance out of APPX Presentation Server. We do
not have specific guidelines on the amount of disk or RAM required,
as those are application-dependent. Since APPX maintains a constant
connection between the client and server, like a UNIX "telnet" would,
rather than reconnecting for every transaction, like a Web browser
would, a reliable network connection is strongly advised.

There has been a report from one user site that response times to
APPX session login requests are really long over Token Ring networks.
This is unconfirmed. Any media over which clients can establish a
TCP/IP connection (like the Internet, a RAS dial-in, etc.) should
work, for a connection between client and server. Obviously, the
faster the better, although this is less of a concern with APPX
Presentation Manager than when running APPX against shared disk
files.

1.2) What software do I need on the server in addition to APPX?

a. Windows NT Server. Note that APPX Presentation Server cannot
be installed on a machine running Novell Netware instead of NT.
You must have a Windows NT machine on which to install APPX
Presentation Server, even if your network still uses Netware
for file and printer sharing. (For your own personal
development purposes, it is possible to install on Windows NT
Workstation, but this is not recommended for production, multi-
user installations)

b. The Windows NT Server Resource Kit. This contains SRVANY.EXE,
required for installing WinAppxD (it also contains many other
useful commands that will make an admin's life easier). You
can buy it separately for about $150 or find it on your
network help desk support technician's "Microsoft Technet" CD.

c. The TCP/IP network protocol. APPX Presentation Server
requires TCP/IP to communicate with clients.

1.3) What software do I need on the clients in addition to APPX?

a. Windows NT, Windows 95 or Windows for Workgroups 3.11.

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

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

1.4) Where are the instructions for installing WinAppxD?

You can find them here.

1.5) Where at Microsoft are the instructions for that NT registry patch we need?

As documented in the installation instructions, see the following
URL for instructions on the registry modification to avoid
USER32.DLL initialization errors:

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.

1.6) What special rights must be assigned to the account used to run the WinAppxD process?

As documented in the installation instructions, the account used
to run the WinAppxD process should be in that machine's
Administrators group, and it should have the following rights
assigned to it:

- 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 listbox in User Manager,
click "Show Advanced Rights" and they should appear, so that you
can assign them.

1.7) What do we need to do differently if installing WinAppxD on an NT 'member server' instead of on a PDC or BDC?

As documented in the installation instructions, the special User
Rights that must be assigned to the account you will use to run
WinAppxD must be assigned on the member server itself. One way
to do this is to sit down in front of THAT SERVER's keyboard and
login to the server as the local Administrator, run the "User
Manager for Domains" utility, and when you "Select Domain" to
administer, type in THE NAME OF THE MEMBER SERVER (not a domain
name at all... the machine name... honest!). This connects you
to the account database specific to that server. From there, set
the User Rights as you would normally.

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.

1.8) I installed WinAppxD for the first time, and it isn't working, what now?

Verify that WinAppxD is running. Check the NT Task Manager. If
it is not there, see "WinAppxD service is not running" in the
"Troubleshooting" section of the FAQ.

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 "Client login issues" in the
"Troubleshooting" section of the FAQ.

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.

1.9) How do I run two versions in parallel?

The trick is that you'll want different values for certain environment
variables used by both WinAppxD and APPX itself, for each engine
you want to be able to run on the server.

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.

1.10) What environment variables must be set on the server?

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, and their new values
will not be in effect for any APPX sessions until the server
machine is rebooted.

1.11) What APPX-provided files are needed on client PC's?

If using the APPX executable client, just appx.exe.

1.12) When installing APPX clients, what do I need to know about the server?

a. The server's IP address. This is obtainable from your network
technician or from the "ipconfig" command. You can run

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.

b. The port the APPX Presentation Server 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.

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

A request to change this, and allow the full path and drive to be
specified for replacement APPX_PRT_SCRIPT's, has been entered in
ECR.

1.14) What do I have to do to install a HASP key and get APPX to recognize it?

a. If you are running an early 3.2 release, upgrade to 3.2.a
(or 3.3, once it is out of beta). Early versions of 3.2 had
some trouble with HASP recognition.

b. Read the instructions for using a HASP from here.

(The following are a brief summary of the instructions for
those who've done it before and need quick hints)

c. Download the installation files.

d. Unzip hinstall.zip

e. While logged into the APPX server as Administrator, run:

c:\...your path here...\hinstall.exe /I

f. Reboot.

g. Run APPX directly on the server (not going through appx -c).

At this point, the HASP should be recognized. If the APPX
Registration screen shows your serial number as "00-..." after
this, then it is still not seeing the HASP. Follow the procedure
under "HASP not seen by APPX" in the "Troubleshooting" section of
this FAQ.

1.15) Can I keep the APPX client .exe file on a server and launch it from across the network on my clients?

You can do this UNDER CERTAIN CONDITIONS. Basically, "the"
condition is that your network has to be fast, uncongested,
stable and reliable. If your network has a slow (less than
1 mbit/sec) communications link somewhere between the server
and any clients, we STRONGLY recommend storing the client
.exe file locally on each client machine on the far side of
the slow link. Similarly, if your routers are not recent,
top of the line equipment built for, well, abuse, they may
drop net frames on the floor silently when they get busy or
when a link (like an Internet or X.25 link) slows down.
Basically, remember you are probably working over Ethernet,
and Ethernet likes to have no more than half its bandwidth in
use at any time. Additionally, some routers still use 68000's
as their CPU's (think original Apple Mac speed, and you've got
a ballpark estimate of the processing power here.) Still other
pieces of net equipment, like certain T1 interfaces, are just
buggy. Lots of traffic taxes everything on the network, and
network equipment can fail in many strange, unpredictable and
VERY difficult to diagnose ways in such situations.

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.

Why is the APPX Client affected by this, and web browsing,
file service, and other functions not? The APPX Client works
like a UNIX telnet, and requires a constant connection
between the client and the server. There will be code in
3.3 to reconnect dropped sessions, but it's probably best
not to rely on this (performance will be slowed each time
the client has to reconnect) if you can avoid it just by
storing the client locally.

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

1.16) Winprint won't print to all or some of my printers. Help?

APPX sometimes has trouble with printers whose names contain
special characters, or which are located on remote non-NT
machines that are connected to your network.

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 section
of the FAQ.

1.17) What if my network includes more than one Windows NT domain?

If you're in a large organization, you might be using multiple
NT domains to manage accounts and resource security. You need
to be aware of how WinAppxD will interact with multi-domain
architectures.

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.

1.18) What special rights must be assigned to the user accounts which will access APPX via the GUI client, Java client or AppxODBC?

User accounts must have the following user right:
- Logon locally (to the APPX Server)

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.

Comments:

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