SOFTWARE COMPATIBILITY TEST METHODOLOGY INTRODUCTION This document is a guide for investigating an application that is not functioning properly on WINVIEW. It also includes a recommended methodology for verifying the basic WINVIEW system installation and NetWare integration. Refer to Chapter 18, "Application Server Problem Determination," in the WINVIEW System Administrator's Guide. Use the section titles in this document as a checklist when you encounter compatibility problems with WINVIEW. REVIEW PRELIMINARY REQUIREMENTS Listed below are several known limitations with WINVIEW. Make sure your problem is not one of them. DOS Graphics DOS graphics programs will work on the application server console but not from a workstation. Usually you will get a hard error popup message such as "invalid video mode" at a workstation when a graphics video mode is attempted. However, sometimes the mode cannot be detected properly and you may get only a blank screen. There are some applications that are primarily text based, but display a graphics logo only upon initial startup. In that event, you may be able to support the application by disabling the initial logo display or by selecting "Ignore" on the popup you may receive. DOS Block Device Drivers DOS block device drivers are designed to augment the DOS file system. Since WINVIEW "virtualizes" the DOS file system, these device drivers are not supported. Block device drivers are used on a DOS-based PC to access devices such as CD-ROM and tape backup drives via a drive letter. An example of a block device driver is MSCDEX.EXE, the Microsoft CD-ROM extension. Workarounds for these include obtaining the respective OS/2 multitasking device drivers, or installing the device on a NetWare server in a way that supports standard network drive redirection. OS/2 Presentation Manager (PM) Applications that use the OS/2 Presentation Manager are not supported. The symptom for this is usually a message similar to "cannot load PMxxx.DLL." Unfortunately, some OS/2 text-based applications contain Presentation Manager dependencies. An example is where the application uses Presentation Manager to popup error messages. These applications usually will not load or execute on WINVIEW. A small set of applications are text based but have been modified with the addition of a few PM calls to install themselves on the PM desktop. If the install program still runs, or the application can be installed manually, you may still be able to use it with WINVIEW. Windows Program Requiring Enhanced Mode VxDs (*.386 Files) Windows enhanced mode VxDs are not supported. If the application uses VxDs, you will get an error message stating that the system "cannot load xxx.386." Check to see if the application will run in standard mode. If standard mode does not work, check with the application manufacturer. You may have to configure the application slightly differently for it to work in standard mode. ENSURE APPLICATION WORKS ON DOS/WINDOWS WORKSTATION (APPLICATION SET UP FOR NETWORK) Occasionally, an application will not install properly on an application server. If that happens, first install the application on a DOS/Windows workstation and ascertain that the application is running properly. You can use this configuration to identify requirements the application might have for special device drivers, TSRs, DLLs, environment variables, .INI file configurations, etc. Once the application is running on the workstation, install it again on the application server. If you encounter difficulties, try to identify the specific application function(s) that may be causing the difficulties. ENSURE OTHER APPLICATIONS WORK ON WINVIEW (WINVIEW INSTALLED PROPERLY) Before you invest much time trying to debug the application, make sure WINVIEW has been installed properly by setting up an application that is known to work, and verifying that it functions properly. If not, you may have a more basic problem than application compatibility. BEGIN APPLICATION INTEGRATION WALK THROUGH The best way to investigate why an application is not working begins with checking the system to ensure that it is installed properly and to become familiar with the application server configuration. CHECK WINVIEW INSTALLATION Check WINVIEW for proper installation. Error Messages During System Initialization Normally, errors during initialization will be reported on the console screen and the system will pause. The Administrator will be prompted to press ENTER to continue. If an error is not very serious, the console will not be paused and it may be necessary to force a pause after loading a device driver. If you receive an error message during system initialization, it may be because the base system is not installed properly. To read messages that scroll off the screen too quickly, place the following line in CONFIG.SYS: DEVICE=STOPHERE Assuming you have kept the default PAUSEONERROR= YES, this statement will cause the system initialization routine to pause and display the error message(s). Place this statement in CONFIG.SYS immediately following the driver whose message you want to read. If you are getting error messages in programs that are started automatically by the system STARTUP.CMD, you can review the messages in the file \OS2\CTX\OPS\ CTXBOOT.LOG. For example, TCP/IP for WINVIEW uses STARTUP.CMD to initialize TCP/IP support. Check Ability to Login Verify that you can login as userID "citrix" (or a current Administrator userID). NOTE: Remember that the "citrix" login is valid for ten days after installation unless you explicitly delete or extend the expiration date. Make sure you have a valid login. If you can login, most likely the system is installed and functioning. You can use the application server even if the network subsystem is not yet operational. Review Hardware Configuration and CONFIG.SYS Review CONFIG.SYS in the root directory of the boot drive. Check for the following: Are the correct base device drivers listed in the BASEDEV statements? Are the CONFIG.SYS sections for NetWare and TCP/IP included and properly enabled? Is the correct network interface card driver specified? Is the correct multiport adapter board driver specified? Are the parameters correct? Are the correct video drivers for the console loaded (VGA vs SVGA)? CHECK NETWARE NETWORK SUBSYSTEM Follow the steps below to ensure the network subsystem is functioning properly. Start OS/2 Session, Run SLIST SLIST is an OS/2 text-based NetWare utility that is shipped with WINVIEW. It is in the path if the NetWare subsystem has been installed properly. If this utility works on Ethernet networks, you can be reasonably sure the network requester is functioning properly. SLIST works properly on Token Ring networks even if source routing has not been properly enabled. If SLIST does not function properly, you may see only a subset of your file servers, or you may be able to see some but not log into them. Review NET.CFG If SLIST does not work, review NET.CFG in the \NETWARE subdirectory. Compare each entry with the examples in Chapter 5 of the WINVIEW for Networks Command Reference. Check the Link Driver section for incorrect NIC settings or frame types. NOTE: Use the QUERY NETWORK utility to display information about the NetWare requester. Try Using a LANLINK Workstation for Your Investigation If the IPX virtual workstation connections load successfully, you should move from the console to a LANLINK workstation to continue your investigation. At this point, it's time to start testing how the network works with the application server virtual DOS environment. Before you start testing the network in this environment, you need to test the base DOS functionality. CHECK ABILITY TO START A DOS SESSION From the "citrix" user "Start Programs" menu select "DOS Command Prompt." Use this as a way to check the system's ability to create DOS sessions. Video OK If all you get is a blank screen when you start the DOS session, it could mean you have the incorrect console video drivers specified in CONFIG.SYS. Check CONFIG.SYS to make sure the correct drivers are specified. You should use a color VGA monitor on the console or all workstations will have monochrome attributes by default. This may cause DOS sessions started at workstations to display data incorrectly or display no data at all. If you have an SVGA adapter installed in the application server and the screen is blank when starting a DOS session, try replacing the CONFIG.SYS statement: DEVICE=C:\OS2\MDOS\VVGA.SYS with DEVICE=C:\OS2\MDOS\VSVGA.SYS assuming C is the WINVIEW boot drive. DOS Character Device Drivers Load (ANSI.SYS,..) DOS device drivers and DOS character device drivers load when the DOS session is first created. All DOS sessions will load DOS device drivers specified in the base CONFIG.SYS. Only DOS device drivers common across all users and applications (e.g.; ANSI.SYS) should be specified in the system CONFIG.SYS. Device drivers that need to be loaded for specific users or applications should be specified in a unique Program Start File (PSF) and an associated DOS Properties File (DPF) managed by the CONFIG APPLICATION utility. AUTOEXEC.BAT Runs (Check Environment Variables) After the DOS session is created and the device drivers are loaded, AUTOEXEC.BAT executes. NOTE: Type SET at the DOS command prompt to verify that AUTOEXEC.BAT has executed. If it has not, it could be due to one of more of the following conditions: AUTOEXEC.BAT does not exist AUTOEXEC.BAT is not reachable or has an invalid statement and terminates COMMAND.COM was invoked without the /P option If the AUTOEXEC.BAT runs properly, the environment displayed with the SET utility will have at least ten lines, including a complete PATH statement and a fully qualified path within the COMSPEC and HOME environment variables. The system looks for and gives priority to an AUTOEXEC.BAT in the user's home directory; otherwise it will use the one in the \OS2\MDOS directory unless COMMAND.COM has been invoked without the /P option. CHECK DOS SESSION Check the key aspects of the DOS session compared with a typical DOS LAN workstation. Check Environment Variable Space (MEM /DEBUG) Use the MEM utility to verify the memory configuration for this DOS session. MEM, MEM /C and MEM /DEBUG all display relevant information. You should also be able to verify at this point that the virtual IPX (VIPX) driver that connects the DOS driver to the NetWare requester and IPX/SPX protocol stack is properly loaded. If the protocol stack is properly loaded, MEM /DEBUG typed at a command prompt will show the device driver as VIPXXXX$. If the typical DOS workstation seems to require a large amount of environment space, you may want to increase the default value set in the SHELL= statement of CONFIG.SYS. To activate this change, reboot the application server before continuing. Some environment variables may change size when the paths to certain directories become longer. For example, one application could not handle the extended length of the TEMP variable on WINVIEW due to the inclusion of the path to the user's home directory (resulting in a SYS3176 error). Check Conventional, EMS, XMS, and DPMI Memory Available Compare the amount of memory available with what you would require for proper application execution on a standard DOS LAN workstation. For example, if you typically require a 4MB workstation with extended memory (XMS) enabled to run the application properly, make sure you have at least 4MB of XMS in your DOS session. If DOS expanded memory (EMS) allocation is specified but none shows up when you run MEM, you may have a memory conflict with a memory mapped I/O board such as a Token Ring network interface card. You can usually overcome this by specifying to include the memory region for the EMS frame in the DOS properties associated with the DOS session. Example: Other: Include regions . . .[D0000-DFFFF ] This would make D0000-DFFFF available for EMS. DOS protected mode interface (DPMI) memory allows DOS programs to use the protected-mode features of the 80286 and later processors without compromising built-in system protections. It is the memory used by Windows. Check PSF/DPF DOS Properties as Appropriate Use CONFIG APPLICATION to manage memory resources and other aspects of the DOS session. Particularly for DOS applications, you should be aware of any special DOS property settings required to run the application in a DOS session under OS/2. In general, these OS/2 requirements will also be relevant for execution within WINVIEW; e.g., special DOS version simulation settings required by Lotus 123 (refer to the Lotus 123 README for details). Do not modify the default PSFs and DPFs provided with WINVIEW so you can use them for comparison and to help debug problems. Make copies of these files and modify them for your testing. CHECK NETWARE RESOURCES Once the DOS session is set up properly, verify that the rest of the network subsystem supporting DOS/Windows sessions is functioning properly. Begin Without Integrated Security The best approach is to first verify that you can manually start a DOS session, load the network shell, and login to the network. This approach will help you more quickly identify such problems as incompatibilities occurring during network login script processing. Start DOS Session with Known PSF/DPF One easy way to manually login to NetWare from the WINVIEW server is to start a DOS command prompt from the "citrix" userID program selector menu. If you want to use a custom PSF, add an entry to the program selector menu that calls this PSF. Manual Load of NETX-Check Default Connection Before Version 2.3 OF WINVIEW for Networks, the NETX shipped with WINVIEW was the most compatible NetWare shell available. Beginning with WINVIEW for Networks Version 2.3, VSHELL has been greatly enhanced and is now the preferred NetWare shell. However, NETX is still a little easier to load manually and can be used for this test. Load NETX from the \NETWARE subdirectory. If the VIPX driver has been loaded properly and the network subsystem is functioning, NETX should be able to establish a default connection to the login directory of a file server. A preferred server for the entire WINVIEW system can be specified in the \NETWARE\NET.CFG file. The default connection drive letter assignment is based on the LASTDRIVE= parameter as specified in the base system CONFIG.SYS, or as overridden by the DOS properties associated with the PSF file used to start the DOS session. Use the QUERY DRIVES utility to display the drive letter assignments for the session. With the current release of WINVIEW, loading NETX manually should result in changing the current directory to the default NetWare LOGIN directory. MANUAL LOGIN AS NETWARE USER WITH NETWARE LOGIN PROGRAM Run the NetWare DOS Login program from the login directory on the file server just as you would from a DOS workstation after it has booted and loaded NETX. Your DOS system and user login scripts should execute. If the system runs a strange login script, you may be running the NetWare OS/2 Login program found in the WINVIEW \NETWARE subdirectory. This executes the NetWare OS/2 login script, which is different from the DOS login script. Change your current directory to make sure you are running the DOS Login program in the login directory on the file server. ANALYZE MAP After the NetWare Login Script executes and you are successfully logged in to the network, use the NetWare MAP command to survey your mapped drives and search drives. Use your DOS workstation for comparison. Mapped Drives Should be the Same as on the DOS Workstation Look for differences in drive letter assignments or missing drives. These are some of the most common causes of LAN application problems. Often batch files have been written that start the application and assume certain mapped drive letter assignments. If these change when a user logs in from an application server, applications may not function properly. Network Search Drives Should be the Same (With Additional WINVIEW Paths) The default WINVIEW path is usually different from the path on the DOS workstation. This will cause your network search drive assignments to be different. Make sure all the search drives your applications need get assigned, and verify that any differences in the number of assignments or ordering will not affect your applications. Here are some example problems: LASTDRIVE for the WINVIEW session is set too high and there is not enough room for all the search drives. With WINVIEW workstation drive mapping enabled, the WINVIEW boot drive letter is changed and gets mapped over by the login script, removing access to the WINVIEW system files. The login script assumes C:\ should be placed in the path. This will erroneously point to the application server system directory where users don't have access or to drive C of the remote client via workstation drive mapping, causing unexpected files to be used on the application server. LOCATION OF NET.CFG The original NetWare OS/2 requester placed NET.CFG in the root directory of the boot drive. Make sure your application is not trying use a NET.CFG in this directory (the WINVIEW EVENTS utility may help identify this problem). The default for the current NetWare OS/2 and WINVIEW requester is for NET.CFG to be in the \NETWARE subdirectory. On WINVIEW, a user-specific NET.CFG can be contained in the user's home directory, but this is of limited usefulness when using integrated security. Novell LAN Workplace for OS/2 TCP/IP support is an example of an application that has this NET.CFG problem. All TCP/IP support should be migrated to TCP/IP for WINVIEW. ANALYZE DOS ENVIRONMENT VARIABLES Now that the NetWare resources have been mapped properly, check the remainder of the DOS environment. SET Command Use the SET command again to check your environment. Ensure that any environment variables set in your login scripts have been set properly. Check COMSPEC COMSPEC points to the active COMMAND.COM command processor. A COMSPEC error can cause application execution problems. The application may execute for a while and fail during execution or upon exit. Often networks are configured to assume all workstations have COMSPEC set to C:\ or C:\DOS. These settings will not work with WINVIEW. Some networks set COMSPEC to a COMMAND.COM on a file server. This will cause problems. You must use the COMMAND.COM distributed in the WINVIEW \OS2\MDOS directory. The WINVIEW COMMAND.COM is not interchangeable with the DOS version. In WINVIEW for Networks Version 2.3, an integrated security feature has been added that checks COMSPEC after login script processing is completed and changes it back to the WINVIEW default if it was modified. This feature works only when integrated security is enabled, and only when the changes occur during login script processing (it will not fix a batch file problem). Some networks are configured to map a drive letter to DOS using login script variables (%MACHINE, %OS, %OS_VERSION). On the application server, these values are set to %MACHINE=IBM_PC, %OS=CITRIX, and %OS_VERSION=V2.3. In this case you can avoid a system login script change by creating a subdirectory on the file server with a name based on the unique values for the variables returned by WINVIEW. You can then copy the COMMAND.COM from the WINVIEW \OS2\MDOS directory to this path on the file server. NOTE: While this technique can help avoid a system login script change, placing COMMAND.COM on the file server will increase network traffic and should be avoided if possible. Check Environment Variables Used by Application/Batch Files This is a good time to check the environment variables on your DOS workstation and make sure they are all available in the WINVIEW DOS session. TRY INTEGRATED SECURITY Now that you know the basic NetWare login sequence functions, login using the WINVIEW integrated security feature with the default group set so that it starts a DOS PSF and leaves you at a DOS command prompt. Review the DOS environment as before. At this point, if you have a problem, you know it is specific to the integrated security autologin features and you can focus on the differences between this and the manual methods. A good technique for troubleshooting integrated security problems is to run the WINVIEW LOGIN program from an OS/2 command prompt under the "citrix" userID and use the verbose mode switch (/V). For example: [C:\USR\citrix]login bobw /v The verbose mode execution of the WINVIEW login program will display integrated security and autologin parameters such as the default group, first user program, home directory, etc. that can help you diagnose problems. TRY VSHELL AS REQUIRED If all your testing has been with NETX up to this point, you should now test a session started with a PSF where network resources are set to GLOBAL. This will USE VSHELL instead of NETX. Switching from NETX to VSHELL is a common way to clear up problems associated with starting a DOS application from the Windows Program Manager. VSHELL is also smaller than NETX and leaves more conventional memory available for your DOS applications. VSHELL support in WINVIEW for Networks Version 2.3 has been enhanced so that new DOS sessions inherit the drive map, search drive, and environment variables as they exist in the initial parent session immediately after the login script is executed. For Windows users, this "snapshot" of the environment is made again just before Windows is started. If you have run programs or batch files that change these settings after you login, these changes most likely will not be inherited by subsequent DOS sessions and must be reissued. ANALYZE APPLICATION REQUIREMENTS If all previous steps have been accomplished and all anomalies resolved, you can now focus directly on specific application configuration issues. Here are some common ones to look for. Location and Paths Used for Batch Files to Start Applications WINVIEW checks for the existence of the specified "First User Program" before creating the DOS session. If you have specified a program or batch file on a mapped drive on the network as your first user program, the login will fail because the user is not logged in at the time WINVIEW checks for the file's existence. One alternative is to make COMMAND.COM the first user program and have it start the batch file with the /C or /K option. The NetWare auto-login programs LOGIN.EXE and NWLOGIN.EXE can read a configuration file, NWLOGIN.CFG. NWLOGIN.CFG is an ASCII text file that can be created by the System Administrator using a text editor. This file must reside in the \OS2\CTX directory on the boot drive of the application server. The NWLOGIN.CFG file contains configuration information that LOGIN.EXE and NWLOGIN.EXE read when initializing a user login. These configuration parameters can include where the user's home directory resides, as well as other optional information. If you need to do batch file processing after network login and login script processing, create a file called NWAFTER.BAT. As with the AUTOEXEC.BAT, a global file for all users can be placed in the \OS2\MDOS irectory, or a user-specific one can be placed in the user's home directory. The NWAFTER.BAT can be used to "clean up" certain problems created by the system login sequence without having to modify the NetWare system login script. NOTE: Several features have been added to WINVIEW that help the system integrator modify the results of the NetWare login sequence without having to modify the system login script. This helps minimize the risk of affecting the normal operation of other network users. These features often give you several ways to accomplish the same objective, particularly in cases where the system integrator has the LAN configuration knowledge and the supervisor rights to change the system login script. Location of Application Requirements (Mapped Drives, Local Drives) Many network installations use batch files to start applications. Review these batch files and ensure they don't make assumptions about drive mappings or user workstation directory structure that are different when running on an application server. Location of User-Specific Files, Temporary Work Space, Data Within an application, configuration settings often are contained in user profile or .INI files. Review these settings to see if they make assumptions about the locations of files or working directories that may be different when running on an application server. Memory Management Requirements (EMS, XMS, DPMI) These settings should be reviewed as part of making sure the DOS session was created properly. Double check the requirements for the specific application and make sure sufficient memory resources have been allocated. Remember, the sum of all memory resources for all sessions used by a user must not exceed the maximum virtual memory allowed by the user or default group profile. Usually when increasing the memory allocation for a DOS property, you must also increase the virtual memory limit with the CONFIG USER utility. Special Application Resource Needs Environment Variables in AUTOEXEC.BAT Check for other changes to the environment that an application installation procedure made to your typical LAN workstation. Look for things such as special device drivers, file handles, or expanded environment space specified in CONFIG.SYS. Also check the AUTOEXEC.BAT for TSRs that get loaded or environment variables that need to be set. Windows Enhanced Mode vs. Standard Mode Some Windows applications behave differently in the two different modes of Windows. However, many of the motivations for using enhanced mode on a single user workstation do not apply with WINVIEW. These include true DOS multitasking and virtual memory management, both of which are supported by Citrix Windows in standard mode. For these reasons, standard mode is the default Windows execution mode for WINVIEW. If your Windows application fails for an unidentifiable reason, try switching from standard to enhanced mode. Use the WINENH.PSF supplied with WINVIEW instead of WIN.PSF. If you started your testing in enhanced mode and your Windows application returns an error message such as "cannot load xxxxx.386," the application is probably trying to load a Windows VxD (Virtual Windows Device Driver). Since VxDs are not supported on WINVIEW, try switching to standard mode. Windows does not support VxDs in standard mode, so many applications will function properly without VxDs when loaded in standard mode. NetWare NetBIOS Emulation Support NetWare NetBIOS emulation for DOS and Windows programs is not supported on WINVIEW, but NetBIOS can be used in several ways in a WINVIEW system. Some application programs use NetBIOS to synchronize multiple user access to program resources such as file and record locking. For WINVIEW systems not connected to a network, NetBIOS emulation within the WINVIEW system is provided to make the application believe it is running on a NetBIOS network. This support works only in a stand-alone WINVIEW configuration not attached to a network. Some WINVIEW systems are attached to NetBIOS networks such as Microsoft LAN Manager. In a configuration of this type where the LAN Manager OS/2 requester is installed on WINVIEW, properly configured DOS workstations can use NetBIOS with LANLINK to connect to the application server. NOTE: There are limitations to using WINVIEW with LAN Manager because WINVIEW is optimized primarily to run with Novell NetWare. There is an NDIS-based network subsystem from IBM (referred to as NTS/2 and LAPS) that can be configured to support NetBIOS for certain DOS and Windows applications on WINVIEW. This product has a PM-based installation program and is difficult to integrate with WINVIEW because it must first be installed on a single user OS/2 machine and then copied to WINVIEW. The entire subsystem layout and configuration parameters are based on the IBM LAN Server and will not be familiar to the typical NetWare integrator. This configuration works only when communicating with other native NetBIOS servers not NetWare NetBIOS emulation servers. While several WINVIEW installations are using this support, it is not recommended unless you are already running this configuration on other OS/2 systems on your LAN. In summary, several NetBIOS configurations are supported with WINVIEW. Some work well, some are complex to install but may work, and others like the NetWare NetBIOS emulation for DOS and Windows applications are not supported. TCP/IP SUBSYSTEM Prior to WINVIEW for Networks Version 2.3, Citrix supported several TCP/IP subsystems. These subsystems had a variety of limitations. To overcome these limitations, Citrix now markets a TCP/IP subsystem that has been optimized and tested for use with WINVIEW. This is the TCP/IP subsystem that should be used. NOTE: Refer to the TCP/IP for WINVIEW System Administrator's Guide and Command Reference for additional information on TCP/IP for WINVIEW. INTEGRATE WITH WINVIEW REQUIREMENTS If you are still having problems, here are some other potential reasons. Windows Executables in \WINCRED Some applications incorrectly assume a certain path to the Windows system directory. The client/server version of Windows shipped with WINVIEW is in the \WINCRED directory. This version of Windows must be executed when running on an application server. It is safest to remove any single user versions of Windows from the path when running applications on WINVIEW. Some applications install files in the Windows system directory. If this occurs, you need to make sure these files get copied to the \WINCRED directory. Always start Windows on WINVIEW using CWIN instead of WIN. If you need to leave the Windows system directory in the path, always place it in the path after the \WINCRED directory. .INI Files in the Path Many Windows applications store configuration information in .INI files. If you have not set up your application server users to share a common .INI directory already set up on the network, you will need to rerun the application setup program from WINVIEW so that the users' .INI files are added and updated properly. Use your typical workstation to compare the .INI files for LAN vs. application server users to identify differences. CWIN.INI and CSYSTEM.INI One of the techniques used by WINVIEW to provide seamless integration with existing LAN Windows users involves utilizing unique .INI files for the WINVIEW-specific information. There are values in the WIN.INI and SYSTEM.INI files that need to be different when executing on an application server versus executing at a LAN workstation. To accomplish this, WINVIEW does not change any existing .INI files but builds its own extensions that take precedence when executing on the application server. These are called CWIN.INI and CSYSTEM.INI. Check these files to see if they are overriding settings that are needed by your application (e.g.; forcing PROGMAN.EXE instead of the shell you use). Also, check to see if settings for your application are not in .INI files where moving or copying the settings might make a difference. WIN.INI and SYSTEM.INI are used if entries are not found in CWIN.INI and CSYSTEM.INI. Application DLLs are in the Path Many Windows applications are implemented as a collection of Windows DLLs. Make sure that any changes in the path or mapped drives give you complete access to all the DLLs needed to run an application. In addition, make sure that your application does not replace DLLs shipped with WINVIEW (such as NWIPXSPX.DLL). You must run the DLLs shipped with WINVIEW for the application server and your applications to function properly. User Home Directory A very common problem when first testing an application server is that an application may be configured to assume the user's home or working directory is located on drive C. An application server user is set up similar to a diskless LAN workstation, where the home directory is actually a path and not the root directory of drive C. Make sure the application can accommodate this type of configuration. In some instances, you may need to use the NetWare MAP ROOT command to substitute a drive letter for the home directory path. In fact, this is a good way to remove user-specific path information from profile and .INI files so that user profile information can be copied from one user to another. NOTE: Use MAP ROOT to remove all user-specific paths from a user's environment: MAP ROOT U:=SYS:\USR\%USERNAME% In this case U is used in common batch/.INI files for all users to refer to the user's HOME directory. Security Issues By default, WINVIEW integrated security users have only USER level security rights on the application server system. Running the application with a userID that has WINVIEW Administrator rights is one way to determine if an application compatibility problem is security related. If this makes a difference in the way the application is behaving, use the WINVIEW EVENTS utility to identify which resources a USER level user is being denied access to. You can use the CONFIG ACCESS utility to grant specific file/directory/API access rights to users if that is the proper solution. Start From the Beginning If you have been unsuccessful trying to integrate with an existing Windows user already set up on the LAN, start over. Act as though you are adding a new user to the LAN, but use the application server as the user's workstation. Run the WINVIEW Windows setup for this user initially, and then run the application-specific setup program on the application server. This can sometimes help identify differences (that are not readily apparent) in the workstation install/configuration. (Setting up a control/test user in this way is usually a good idea in any case.) This is also true if you are upgrading an application server to a new level. Sometimes changes or enhancements are made to the system that will not take effect unless you recreate the user and run the Windows setup again on the updated system. For example, if you add TCP/IP for WINVIEW to an existing WINVIEW system, the default AUTOEXEC.BAT is modified to load the drivers necessary to access the TCP/IP protocol stack. Existing users already set up to run Windows have individual AUTOEXEC.BAT files that will not inherit the changes to the default files. In this case you can manually edit each user's AUTOEXEC.BAT. Starting DOS Applications from PIF If you are using a Windows PIF to launch a DOS application, DOS properties cannot be specified. Try creating a special PSF file for the application to see if specific DOS properties are needed to run the application. If necessary, you can launch a specific PSF file instead of a PIF file from a Windows icon. If Problems Persist Consult with someone who is very familiar with the application for information about similar failures on DOS/Windows workstations. Check with the application vendor technical support team who might have knowledge of similar failures on DOS/Windows as well as OS/2 workstations. Ask if there are special requirements for this DOS/Windows application when running in an OS/2 session. NOTE: If you are advised that the application is not supported under OS/2, that doesn't mean it won't work on WINVIEW. WINVIEW has been enhanced to run DOS and Windows applications that do not run well under OS/2. If, after following the solutions in this chapter, you still need assistance, please contact your Citrix authorized reseller. Refer to Appendix O for a list of authorized resellers.