InstallationOfWinAppxD < Main

Tags: view all tags
---+ Installation of !WinAppxD

*WinAppxD was replaced by the APPX Login Manager in Release 5.0.0. See <a href="APPXLoginManagerForWindows" target="_self">this page</a> for installing & configuring the Login Manager.*

%TOC%

________________________________________________________________________
---+ 1) Installation of !WinAppxD

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

<br /> For the server, fast disk and plenty of RAM are helpful in getting<br /> the best possible performance out of APPX Presentation Server. We do<br /> not have specific guidelines on the amount of disk or RAM required,<br /> as those are application-dependent. Since APPX maintains a constant<br /> connection between the client and server, like a UNIX "telnet" would,<br /> rather than reconnecting for every transaction, like a Web browser<br /> would, a reliable network connection is strongly advised.<br /><br /> There has been a report from one user site that response times to<br /> APPX session login requests are really long over Token Ring networks.<br /> This is unconfirmed. Any media over which clients can establish a<br /> TCP/IP connection (like the Internet, a RAS dial-in, etc.) should<br /> work, for a connection between client and server. Obviously, the<br /> faster the better, although this is less of a concern with APPX<br /> Presentation Manager than when running APPX against shared disk<br /> files.
---+ 1.2) What software do I need on the server in addition to APPX?

<br /> a. Windows NT Server. Note that APPX Presentation Server cannot<br /> be installed on a machine running Novell Netware instead of NT.<br /> You must have a Windows NT machine on which to install APPX<br /> Presentation Server, even if your network still uses Netware<br /> for file and printer sharing. (For your own personal<br /> development purposes, it is possible to install on Windows NT<br /> Workstation, but this is not recommended for production, multi-<br /> user installations)<br /><br /> b. The Windows NT Server Resource Kit. This contains SRVANY.EXE,<br /> required for installing !WinAppxD (it also contains many other<br /> useful commands that will make an admin's life easier). You<br /> can buy it separately for about $150 or find it on your<br /> network help desk support technician's "Microsoft Technet" CD.<br /><br /> c. The TCP/IP network protocol. APPX Presentation Server<br /> requires TCP/IP to communicate with clients.
---+ 1.3) What software do I need on the clients in addition to APPX?

<br /> a. Windows NT, Windows 95 or Windows for Workgroups 3.11.<br /><br /> b. The TCP/IP network protocol. The APPX client uses TCP/IP<br /> to communicate with APPX Presentation Server.<br /><br /> c. If the client is a Windows 95 machine, and you EVER anticipate<br /> sharing the network drive containing the APPX application data<br /> files and running appx.exe (not appx -c) at the client with<br /> APPXPATH set to that network drive, you MUST install the<br /> Windows 95 network file redirector fix provided by Microsoft at<br /><br /> <a href="http://support.microsoft.com/support/kb/articles/q148/3/67.asp" target="_blank">http://support.microsoft.com/support/kb/articles/q148/3/67.asp</a> <br /><br /> to avoid the potential for APPX data file corruption due to a<br /> bug in Windows 95. If you don't do this now, you may forget<br /> to do it later, corrupt your data files, and spend hours on<br /> problem resolution and recovery. You would not be the first<br /> person it's happened to. You have been warned.<br /><br /> NOTE ABOUT URLs: Microsoft periodically rearranges its web<br /> site, so the above URL may or may not be valid. If you can't<br /> find it, use the "Search" option on the MS web site, instructing<br /> it to look in whatever choice includes the "Knowledge Base".<br /> Specify "Qnnnnnn" as what to look for, where nnnnnn is the number<br /> between the "q" and the ".asp". For example, in the above, it<br /> would be Q148367. That should enable you to locate the article.
---+ 1.4) Where are the instructions for installing !WinAppxD?

<br /> You can find them [[APPXClientServer][here]].
---+ 1.5) Where at Microsoft are the instructions for that NT registry patch we need?

<br /> As documented in the installation instructions, see the following<br /> URL for instructions on the registry modification to avoid<br /> USER32.DLL initialization errors:<br /><br /> <a href="http://support.microsoft.com/support/kb/articles/q142/6/76.asp" target="_blank">http://support.microsoft.com/support/kb/articles/q142/6/76.asp</a> <br /><br /> NOTE ABOUT URL's: Microsoft periodically rearranges its web<br /> site, so the above URL may or may not be valid. If you can't<br /> find it, use the "Search" option on the MS web site, instructing<br /> it to look in whatever choice includes the "Knowledge Base".<br /> Specify "Qnnnnnn" as what to look for, where nnnnnn is the number<br /> between the "q" and the ".asp". For example, in the above, it<br /> 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?

<br /> As documented in the installation instructions, the account used<br /> to run the !WinAppxD process should be in that machine's<br /> Administrators group, and it should have the following rights<br /> assigned to it:<br /><br /> - Act as part of the Operating System<br /> - Replace a process-level token<br /> - Increase quota<br /> - Logon as a service (if it's not already set)<br /><br /> If you do not see these rights in the listbox in User Manager,<br /> click "Show Advanced Rights" and they should appear, so that you<br /> 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?

<br /> As documented in the installation instructions, the special User<br /> Rights that must be assigned to the account you will use to run<br /> !WinAppxD must be assigned on the member server itself. One way<br /> to do this is to sit down in front of THAT SERVER's keyboard and <br /> login to the server as the local Administrator, run the "User<br /> Manager for Domains" utility, and when you "Select Domain" to<br /> administer, type in THE NAME OF THE MEMBER SERVER (not a domain<br /> name at all... the _machine_ name... honest!). This connects you<br /> to the account database specific to that server. From there, set<br /> the User Rights as you would normally.<br /><br /> The extra work is required because of NT security mechanisms.<br /> Most NT wizards will not think this is necessary. However,<br /> straight from Tier 3 MS phone support, it really is. Setting the<br /> rights without connecting to the specific machine will only work<br /> 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?

<br /> Verify that !WinAppxD is running. Check the NT Task Manager. If<br /> it is not there, see "WinAppxD service is not running" in the<br /> "Troubleshooting" section of the FAQ.<br /><br /> Verify that you can, directly on the server (without using the<br /> "appx -c" client option), login to APPX. Being able to do this<br /> is a necessary pre-requisite to being able to login from clients<br /> with "appx -c". Go no further in this troubleshooting process<br /> until you can successfully login directly on the server as with<br /> any standard (non-Presentation Server) APPX for Windows<br /> installation. Common things to check if this doesn't work are<br /> the APPX_KEYMAP and APPXPATH variable settings and data file<br /> permissions.<br /><br /> Once you're logged in on the server, check to make sure that<br /> you have a Registration license for the APX/GCS product.<br /> This is required, to run APPX in APPX Server mode.<br /><br /> If when you try to login with a client, you receive an error<br /> like "Incorrect login," see "Client login issues" in the<br /> "Troubleshooting" section of the FAQ.<br /><br /> If, when you try to login with a client, your client session hangs<br /> BEFORE showing any APPX screen, make sure you have the following<br /> environment variables set in the global System section of User<br /> Environment variables on your NT Server:<br /><br /> APPX_SERVER - set to full path of appx.exe<br /> APPX_KEYMAP - set to "Windows"<br /> APPXPATH - set to your APPX data directory<br /><br /> If you change any of these now, reboot the machine to make them<br /> take effect, then re-test the client login.<br /><br /> If, when you try to login with a client, you get the error "host<br /> unreachable" or "host not found", verify that the server's host<br /> IP address (or name) and port number specified in the login<br /> dialog box are correct. Also check again to make sure that<br /> !WinAppxD is running. If you have the dialog options set<br /> correctly, but !WinAppxD exited with an error as soon as it was<br /> started, the client will not be able to contact !WinAppxD and you<br /> will get errors like these. "Host unreachable" is generally<br /> misleading because the host is usually there just fine, it's<br /> just that !WinAppxD isn't listening for connections.<br /><br /> To verify that you are using a valid host address that is<br /> reachable from the client, go to a DOS command prompt on the<br /> client and "ping" the server address you put in the connection<br /> box on the APPX client.<br /><br /> If something else is happening, or if you've followed the<br /> procedures outlined here and !WinAppxD still isn't working, please<br /> call APPX Software Technical Support for assistance.
---+ 1.9) How do I run two versions in parallel?

<br /> The trick is that you'll want different values for certain environment<br /> variables used by both !WinAppxD and APPX itself, for each engine<br /> you want to be able to run on the server.<br /><br /> To do this, set up your services to run batch files that set<br /> the appropriate environment variables, then launch !WinAppxD.exe.<br /> (Instead of running the services running !WinAppxD.exe directly.)<br /> Different services run different batch files, which start<br /> !WinAppxD's with different ports and other environment variables.
---+ 1.10) What environment variables must be set on the server?

<br /> APPX_SERVER - Full path to the appx.exe on the server. Make sure<br /> that you reference a drive that is available from<br /> the server, not a network drive that is only visible<br /> from clients<br /><br /> APPX_KEYMAP - Normally set to "Windows", but you can set it to<br /> a different name if you wish to customize the<br /> keymap<br /><br /> APPXPATH - Full path to your APPX data directory<br /><br /> These variables MUST be set on the server, and their new values<br /> will not be in effect for any APPX sessions until the server<br /> machine is rebooted.
---+ 1.11) What APPX-provided files are needed on client PC's?

<br /> If using the APPX executable client, just appx.exe.
---+ 1.12) When installing APPX clients, what do I need to know about the server?

<br /> a. The server's IP address. This is obtainable from your network<br /> technician or from the "ipconfig" command. You can run<br /><br /> C:&gt; ipconfig /all<br /><br /> from a DOS command prompt on the server. If it lists more<br /> than one network interface and IP address, ask the network<br /> tech.<br /><br /> b. The port the APPX Presentation Server has been set to listen<br /> on. If you installed APPX Presentation Server, you should<br /> know what this is. It is the number you typed after "-s="<br /> when editing the registry entry for !WinAppxD. Unless you<br /> opted for a different port number because you're running<br /> multiple versions of APPX, or because some software at your<br /> site was already using the APPX-recommended value, it is<br /> probably 8060. Check the registry key:<br /><br /> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinAppxD<br /><br /> (or !WinAppxD2, or !WinAppxD3, etc. if you are running multiple<br /> versions of APPX) for the number following "-s=" in the<br /> "Application" entry.
---+ 1.13) APPX doesn't want to run my APPX_PRT_SCRIPT. What am I doing wrong?

<br /> Nothing, most likely. However, current versions of APPX blindly<br /> pre-penned the APPXPATH to the value of APPX_PRT_SCRIPT. In order<br /> for APPX to properly invoke a replacement APPX_PRT_SCRIPT:<br /><br /> - your replacement print script must be in the APPXPATH<br /> directory<br /> - you must set APPX_PRT_SCRIPT to the file name, not including<br /> any directory or drive letter information in front of it (for<br /> example, you might set APPX_PRT_SCRIPT=myprint.exe)<br /> - APPX_PRT_SCRIPT must be set ON THE SERVER (not the client;<br /> remember, when connecting to APPX Presentation Server, the<br /> SERVER controls the printing), along with APPXPATH and the<br /> other standard variables. Generally this is done from<br /> Control Panel / System / User Environment. Remember to<br /> reboot after you change this.<br /><br /> A request to change this, and allow the full path and drive to be<br /> specified for replacement APPX_PRT_SCRIPT's, has been entered in<br /> ECR.
---+ 1.14) What do I have to do to install a HASP key and get APPX to recognize it?

<br /> a. If you are running an early 3.2 release, upgrade to 3.2.a<br /> (or 3.3, once it is out of beta). Early versions of 3.2 had<br /> some trouble with HASP recognition.<br /><br /> b. Read the instructions for using a HASP from [[WindowsHASPInstallation][here]].

<p align="left">(The following are a brief summary of the instructions for<br /> those who've done it before and need quick hints)<br /><br /> c. [[http://www.appx.com/ftp/appx/support/utilities/hasp/hinstall.zip][Download]] the installation files.<br /><br /> d. Unzip hinstall.zip<br /><br /> e. While logged into the APPX server as Administrator, run:<br /><br /> c:\...your path here...\hinstall.exe /I<br /><br /> f. Reboot.<br /><br /> g. Run APPX directly on the server (not going through appx -c).<br /><br /> At this point, the HASP should be recognized. If the APPX<br /> Registration screen shows your serial number as "00-..." after<br /> this, then it is still not seeing the HASP. Follow the procedure<br /> under "HASP not seen by APPX" in the "Troubleshooting" section of<br /> this FAQ.<br /><br /></p>

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

<br /> You can do this UNDER CERTAIN CONDITIONS. Basically, "the"<br /> condition is that your network has to be fast, uncongested,<br /> stable and reliable. If your network has a slow (less than<br /> 1 mbit/sec) communications link somewhere between the server<br /> and any clients, we STRONGLY recommend storing the client<br /> .exe file locally on each client machine on the far side of<br /> the slow link. Similarly, if your routers are not recent,<br /> top of the line equipment built for, well, abuse, they may<br /> drop net frames on the floor silently when they get busy or<br /> when a link (like an Internet or X.25 link) slows down.<br /> Basically, remember you are probably working over Ethernet,<br /> and Ethernet likes to have no more than half its bandwidth in<br /> use at any time. Additionally, some routers still use 68000's<br /> as their CPU's (think original Apple Mac speed, and you've got<br /> a ballpark estimate of the processing power here.) Still other<br /> pieces of net equipment, like certain T1 interfaces, are just<br /> buggy. Lots of traffic taxes everything on the network, and<br /> network equipment can fail in many strange, unpredictable and<br /> VERY difficult to diagnose ways in such situations.<br /><br /> If you really, really, really are set on the idea of storing<br /> the client on a central server, be warned that the typical<br /> failure symptom you will see when you push your network too<br /> hard, will be APPX clients "just disappearing" seemingly<br /> randomly. If you see things like that, or if processes that<br /> normally work randomly lock up client computers, and you have<br /> ANY clients ANYWHERE on your net loading appx.exe across the<br /> network, please set all clients to use a LOCAL copy of appx.exe<br /> and see if that takes care of the problem, before you call<br /> APPX Technical Support.<br /> <br /> Why is the APPX Client affected by this, and web browsing,<br /> file service, and other functions not? The APPX Client works<br /> like a UNIX telnet, and requires a constant connection<br /> between the client and the server. There will be code in<br /> 3.3 to reconnect dropped sessions, but it's probably best<br /> not to rely on this (performance will be slowed each time<br /> the client has to reconnect) if you can avoid it just by<br /> storing the client locally.<br /><br /> If you are that concerned about the maintenance headache of<br /> updating several dozen clients' copies of appx.exe when a new<br /> version comes out, consider investing in one of the network<br /> software management packages out there, like Microsoft's SMS.<br /> (This isn't an official APPX "go out and buy it" recommendation,<br /> just a word to the wise regarding something you might want to<br /> consider.)
---+ 1.16) Winprint won't print to all or some of my printers. Help?

<br /> APPX sometimes has trouble with printers whose names contain<br /> special characters, or which are located on remote non-NT<br /> machines that are connected to your network.<br /><br /> Since running APPX directly often results in better messages<br /> than when it's run through appx -c, see if you can reproduce<br /> the "won't print" error when running APPX directly on the<br /> server, and if you get an error message dialog box.<br /><br /> If you get an error message that isn't self-explanatory, please<br /> call APPX Software Technical Support for assistance.<br /><br /> If you don't get an error message, follow the "Winprint won't<br /> print to my printer" instructions in the "Troubleshooting section<br /> of the FAQ.
---+ 1.17) What if my network includes more than one Windows NT domain?

<br /> If you're in a large organization, you might be using multiple<br /> NT domains to manage accounts and resource security. You need<br /> to be aware of how !WinAppxD will interact with multi-domain<br /> architectures.<br /><br /> !WinAppxD validates client users using the domain name found<br /> by running !LookupAccountSID() against the NT account used to<br /> start up !WinAppxD. Typically, this means that any client users<br /> running "appx -c" must be defined in the same domain in which<br /> the APPX server participates, because when !WinAppxD is defined<br /> as a service, it starts up in the domain the server is assigned<br /> to.<br /><br /> This means that if your APPX server running !WinAppxD is a<br /> member of your !UsefulApps domain, that users which are<br /> defined ONLY in your !CorpUsers domain will not be able to<br /> login to APPX. If we looked on the client to see which<br /> domain the client user was logged into and sent that info<br /> to the server, it would work, but today (as of 3.3) we do<br /> not do that. You are restricted to validating logins only<br /> in the same domain your APPX server belongs to.<br /><br /> DESPERATE to get around this? If you don't use your server<br /> for much else besides APPX, and it's in a secure room or<br /> you don't mind running a locked screensaver all day, you might<br /> be able to do it. Just walk up to the APPX server machine<br /> and login to your master domain, or useraccounts domain, or<br /> whichever domain your user accounts are found in. Make sure<br /> you are using an account in the Administrator group, and which<br /> has the four magic user rights set (as documented elsewhere in<br /> the FAQ). Now start winappxd from a DOS Command prompt using a<br /> line like:<br /><br /> c:\appx&gt; winappxd -s=8060<br /><br /> This should cause !WinAppxD to use the currently logged in<br /> user's domain for authentication. If you were able to<br /> successfully run winappxd as a service before trying this,<br /> using this technique should not cause it to "break". If you<br /> read this FAQ prior to installation and decided to skip the<br /> whole process of running !WinAppxD as a service, then please<br /> make sure that the APPX environment variables APPXPATH,<br /> APPX_SERVER and APPX_KEYMAP are set for your current command <br /> 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?

<br /> User accounts must have the following user right:<br /> - Logon locally (to the APPX Server)<br /><br /> This right must be set on the APPX Server. If your APPX Server<br /> is not the same machine as your PDC, please see item 1.7 for how<br /> to do this -- this right must be set at the machine level, not<br /> the domain level, for security reasons. Otherwise, just login<br /> as Administrator, and run User Manager for Domains (or just User<br /> Manager if you're using NT in a Workgroups setup).<br /><br /> The best way to do this, since you'll probably have lots of APPX<br /> users, is to assign this right to a group, rather than individual<br /> users. Although the quickest way to do this is to assign this<br /> right to the existing group "Everyone" or "Domain Users", it's<br /> better from a security standpoint if you create a group like "APPX<br /> Users" and assign the right only to that group. This way, you know<br /> that only users you've explicitly added to that group, have that<br /> added right. The downside is that you will have to remember to<br /> 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._
---

<br />%COMMENT%
Topic revision: r3 - 2016-04-06 - JeanNeron