SystemAdministratorQuestions < Main

---+ System Administrator Questions

*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%

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

<br /> This was due to a bug in versions of APPX at or below 3.2.x. If<br /> you are running 3.2.x or earlier, you must upgrade to a newer<br /> version of APPX or change your APPX User ID's to 3-character ID's.<br /> This restriction affects only the APPX user ID's, not the "System<br /> ID" that is used to link the APPX user ID with the Windows network<br /> user ID.
---++ 2.2) What do I put in the "System ID" field when adding a new APPX user to the APPX user list?

<br /> In that field, you should enter the Windows network login ID which<br /> is used by that user, to authenticate him/her to NT. When you<br /> enter this login ID, be sure that it matches exactly the case in<br /> which it listed in the NT User Manager. Yes, we know that when NT<br /> itself validates logins, it does case-insensitive comparisons so<br /> that a user whose NT network login ID is 'SWilliams' can login<br /> successfully as 'swilliams'. However, because other OS's do<br /> case-sensitive login validations, APPX has always required an<br /> exact match, including case, of system login ID when users sign on<br /> to the APPX environment. We want the NT version to work the same<br /> way that the other versions of APPX do.<br /><br /> Note: If you have installed NT 4.0 Service Pack 4, your NT Server<br /> may be performing case-sensitive comparisons on login ID and<br /> password, so if you enforce case-sensitivity on your network logins,<br /> this might not cause as much "what combination of upper and lower<br /> case did I use originally?" confusion as in prior release levels<br /> of NT 4.
---++ 2.3) What is the "Password" field for?

<br /> This field is not applicable for users of !WinAppxD. If you are<br /> running a standalone version of APPX on a PC or notebook computer<br /> which does not have Microsoft Networking installed, login password<br /> validation cannot be performed by the operating system. This<br /> field exists so that access to applications on such systems can<br /> still be password-protected.
---++ 2.4) How do I define a new keymap?

<br /> We generally recommend that customers use the existing Windows<br /> keymap that ships with APPX for Windows.<br /><br /> The best way to define a new keymap on APPX for Windows is to<br /> login locally to APPX on your server (that is, by running 'appx'<br /> directly, not by running 'appx -c') and define it there. There<br /> are reports of problems defining new keymaps through 'appx -c'.<br /> We strongly suggest leaving the default Windows keymap intact<br /> and only editing NEW local keymaps.<br /><br /> For example, to define a new generic keymap called 'Wincorp',<br /> you would invoke APPX at a command prompt on the server with:<br /><br /> C:&gt; appx.exe -k -m=:Wincorp<br /><br /> After doing this, you would set APPX_KEYMAP=Wincorp on the<br /> server machine and clients.
---++ 2.5) How can I find out who has a specific record in a specific file locked?

<br /> As of version 3.3 and earlier, this capability is not available.
---++ 2.6) We get USER32.DLL errors. Help?

<br /> There are two common reasons that customers experience "USER32.DLL<br /> Initialization failed" errors. The first is a Windows NT default<br /> resource limit which can be raised by editing the NT server's<br /> registry according to instructions at URL:<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 /> The second is that the customer is using an old (pre-January 15,<br /> 1998) version of !WinAppxD.exe. <br /><br /> The first thing you should do to resolve these errors is edit the<br /> registry as described above. If you have modified the registry<br /> and still receive USER32.DLL errors, please contact APPX Software<br /> Technical Support to verify that you have the most up-to-date<br /> copies of !WinAppxD.exe and appx.exe.<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.
---++ 2.7) Where are the instructions for interfacing with !UniQue?

<br /> Instructions for interfacing APPX Presentation Manager with the<br /> !UniQue print spooler from LBM Systems can be found [[UniQueClientServer][here]].
<p align="left">Instructions for interfacing the 'network disk' version of APPX<br /> for Windows with the !UniQue print spooler can be found [[UniQueDirectConnect][here]].</p>

---++ 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)?

<br /> Yes. By default, APPX sends its print files to winprint.exe.<br /> However, by setting the environment variable APPX_PRT_SCRIPT to<br /> the name of an alternate print file processing program (or .bat<br /> file), it is possible to customize print file handling. This<br /> variable MUST be set on the server, and its new value will not<br /> be in effect for any APPX sessions until the server machine is<br /> rebooted.<br /><br /> For example, if you set APPX_PRT_SCRIPT=mycustom.exe, and are<br /> printing a file named 'prntfile', APPX will invoke your custom<br /> print file processor with the command line:<br /><br /> mycustom.exe -config=prntfile.cfg prntfile <br /><br /> Inside mycustom.exe, you can inspect the file name, the contents<br /> of the file itself, and/or the contents of the config file, to<br /> programmatically add printer-specific font switching or other<br /> control codes. You can then copy the modified file back to its<br /> original name and from inside mycustom.exe, invoke the command:<br /><br /> winprint.exe -config=prntfile.cfg prntfile <br /><br /> on it to cause APPX to print the file, or do something else if<br /> you prefer.
---++ 2.9) I get Dr. Watson errors when running APPX. Help?

<br /> When APPX gets certain kinds of errors, it crashes. There is<br /> code in the APPX engine to write out a stack trace whenever a<br /> "trappable" crash occurs. However, if Dr. Watson is enabled<br /> on your system (as it is on most), the crash will cause Dr.<br /> Watson to be invoked, rather than write out the stack trace.<br /><br /> APPX Software often needs the stack trace to diagnose software<br /> failures. Therefore, if you are working with ASI to debug an<br /> error that causes an APPX crash, please turn off Dr. Watson at<br /> least temporarily, in order to permit APPX to write out the<br /> stack trace.
---++ 2.10) How can I tell what versions of !UniQue and !OpenNT/Interix I am running?

<br /> The version of !OpenNT can be gotten from the registry key:<br /><br /> \HKEY_LOCAL_MACHINE\SOFTWARE\Softway Systems\Interix<br /><br /> (As of 3/14/1999, the newest version is 2.2.400).<br /><br /> The following<br /> Command will show the !UniQue Version number:<br /><br /> \OpenNT\usr\spool\uprint\ulp -h<br /><br /> (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?

<br /> Name resolution failures generally take a bit more than 2.5 minutes<br /> (means you have a problem with name resolution on either the client<br /> or server) or a bit more than 5 minutes (means both sides have a<br /> name resolution problem), give or take a minute. [ 2.5 minutes is<br /> approximately the time it takes for a DNS query to time out. ]<br /><br /> To diagnose if you have a name resolution issue, you DO NOT need<br /> fancy network monitors and experts and the like. All you need is<br /> "ping", the hostname and IP address of your APPX Server and (if<br /> running the APPX Server on NT) the hostname and IP address of your<br /> Primary Domain Controller (and any Backup Domain Controllers that<br /> exist). You can get a machine's IP address by running "ipconfig"<br /> at the command prompt and picking the internal network interface<br /> (that is, not the one that starts 224, or 127, or the one labeled<br /> dialup adapter!). Do the following tests:
---+++ 1. Check that the client can resolve the APPX Server's host name.

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

<br /> Sit down at the APPX server that is running !WinAppxD or appxd.<br /> Ping the server by its IP address. Ping the server by its name.<br /> If the ping by IP address comes back in a second or two, but<br /> the ping by name takes longer, the server has a name resolution<br /> problem. See the typical reasons for this above. If after<br /> fixing this (or not finding a problem here), it's still slow,<br /> 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.

<br /> If you've eliminated problems 1 and 2, either by fixing them<br /> and verifying that pings by name and IP address now take about<br /> the same amount of time, or by doing the above tests and not<br /> seeing a dramatic difference between ping times, the problem<br /> is slightly different. In this case, you are probably running<br /> APPX on an NT server (rather than a UNIX box) and the Primary<br /> Domain Controller is _probably_ a different machine than your<br /> APPX Server. And what's happening is that the APPX server<br /> is having name resolution problems finding the PDC, when it<br /> tries to log the user into NT behind-the-scenes. Sometimes<br /> this indicates a DNS problem, other times it indicates a WINS<br /> problem (yes, NT uses two different name resolution services,<br /> depending on how it's set up). To see if it's a DNS issue,<br /> sit at the APPX server and ping the PDC by name and IP address.<br /> If the ping by name is much slower than the ping by IP address,<br /> by now, you probably have know what the trouble is -- DNS doesn't<br /> know about your PDC. If you're not using DNS, make sure the PDC<br /> is in the HOSTS file on your APPX server. If you are using DNS,<br /> make sure your DNS tables include a record for the PDC's name<br /> and IP address, and the names and addresses of all BDCs defined<br /> on your network. If that didn't solve the performance problem,<br /> you're all out of DNS problems, and have to look at WINS, which<br /> is a Microsoft-specific name resolution service. You might run<br /> into WINS performance issues if your network is set up to use<br /> WINS (don't immediately discount this -- some are!) and the Windows<br /> name of the PDC machine isn't the same as its TCP/IP hostname.<br /> Typically, the problem would be that the APPX server doesn't<br /> have a WINS server specified (or has the wrong WINS server name<br /> specified). One way to see if you have a WINS issue might<br /> be to sit at the APPX server, login as Administrator, open up a<br /> Command box, and do the command "net view \\PDCNAME" (where PDCNAME<br /> is the name of your domain's Primary Domain Controller box). If<br /> it takes a while for it to come back (longer than a few seconds),<br /> check your WINS configuration.<br /><br /> I don't want to use DNS. How do I put static IP address information<br /> into my machines' "HOSTS" files?<br /><br /> All APPX clients and the APPX Server should have a hosts file, if you<br /> have decided to go this route. At a minimum, this file needs to look<br /> like:<br /><br /> 142.42.42.1 appxserverhostname<br /> 142.42.42.2 pdchostname<br /><br /> That is, two lines. The first is the IP address of the machine running<br /> winappxd, followed by at least one space, then the name of that machine.<br /> The second is the IP address of your network's Primary Domain Controller<br /> for the domain that validates logins, followed by at least one space,<br /> then the name of the PDC. If you have BDC's, you would want to include<br /> a line for each of them as well.<br /> <br /> The HOSTS file lives in different places, depending on whether you<br /> are running Win9x or Windows NT.<br /><br /> In Win9x: \windows\hosts<br /> In NT: \winnt\system32\hosts<br /><br /> (Of course, if you've installed Windows into a different directory,<br /> you'll want to change the first part of those paths above.)<br /><br /> This SHOULD improve your response time dramatically, and is useful<br /> for small networks as well as a temporary fix to get a site up and<br /> running without having to wait several days for an appointment with<br /> a network techie to set up DNS on your LAN if the site's network<br /> administration is done by an outside party.
---++ 2.12) Automatically update Presentation Clients to the most recent version!

<br /> Here's a nice low-budget way to "distribute" APPX from a central <br /> server to client workstations, making sure that clients always run <br /> the most up-to-date version.<br /><br /> The following batch file can be loaded on your APPX NT server, and <br /> run by each client wanting to initiate a thin client session. <br /><br /> Under this scheme, clients always execute a local copy of appx.exe -c <br /> as recommended, but when the appx.exe client is upgraded, it is not <br /> necessary to distribute the new executables out to all the clients!<br /><br /> echo off<br /> xcopy \\rocky_bdc\appx\appx.exe %temp% /d<br /> start %temp%\appx.exe -c<br /><br /> The /d switch on the xcopy command only executes the copy if no <br /> destination file exists or if the date/time on the source is later <br /> than on the destination. <br /><br /> The start command then executes the local copy of the executable. <br /> This works Win 95/98 and NT Workstation clients.<br /><br /> Thanks to Steve Glore of Consolidated Meat Group in Australia <br /> &lt;glores@meat.aust.com&gt;!
---++ Comments:

_Read what other users have said about this page or add your own comments._
---

<br />%COMMENT%
This topic: Main > WebHome > SpecialTopics > ConfiguringAPPXForWindows > APPXPresentationServerWinAppxD > SystemAdministratorQuestions
Topic revision: r3 - 2016-04-06 - JeanNeron