Piper's Pit BBS/FTP: ibm 0210

home *** CD-ROM | disk | FTP | other *** search

/ Piper's Pit BBS/FTP: ibm 0210 - 0219 / ibm0210-0219 / ibm0213.tar / ibm0213 / LS4APWAC.ZIP / LS40A.A11 / IBMLSA / IBM400R1 / README.DOC < prev next >

Wrap

Text File | 1994-06-10 | 85.0 KB | 2,413 lines

IBM OS/2 LAN SERVER 3.0 PRODUCT SUPPLEMENTAL INFORMATION (READ THIS FIRST) INTRODUCTION Congratulations! You have just received the highest performing personal computer network operating system on the market today. We take great pride in offering this product to you and hope it exceeds all your expectations. This document provides important supplemental information for IBM* OS/2* LAN Server Version 3.0. It is recommended that you read this document before installing and using the LAN Server (LS) product. LAN Server Team Introduction ii CONTENTS Trademark Notices . . . . . . . . . . . . . . . . . . . . . . 1 New functions for LAN Server 3.0 . . . . . . . . . . . . . . . 2 Distributed Features . . . . . . . . . . . . . . . . . . . . . 4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . 4 Levels of OS/2 Needed for LS 3.0 Enhancements . . . . . . . 4 LAN Server 3.0 Installation Restrictions . . . . . . . . . . 5 386 HPFS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Creating 386 HPFS Boot Diskettes . . . . . . . . . . . . . 6 386 HPFS and the /Autocheck: Drive List . . . . . . . . . 6 Formatting a Drive as HPFS . . . . . . . . . . . . . . . . 7 Servers with More Than 16MB of Memory . . . . . . . . . . 7 NetBIOS for TCP/IP . . . . . . . . . . . . . . . . . . . . . 8 Remoteboot Service . . . . . . . . . . . . . . . . . . . . . . 9 Support for OS/2 2.0 or high 32-Bit Display Device Drivers . 9 Command Syntax for RPLSETD.CMD . . . . . . . . . . . . . . . 9 Upgrading the Remote IPL Service . . . . . . . . . . . . . 10 Preserving the Ability to Remote IPL OS/2 1.3 Clients . . . 12 Server Name/Workstation Name Restriction (DBCS Only) . . . 15 Disk Fault Tolerance . . . . . . . . . . . . . . . . . . . . 15 SCSI Drives . . . . . . . . . . . . . . . . . . . . . . . . 15 Limit of 24 Partitions . . . . . . . . . . . . . . . . . . 16 FDISK and FDISKPM Marking of Free Disk Space . . . . . . . 17 Commands in FTREMOTE Response File . . . . . . . . . . . . 17 Recovering From a Failure of a Mirrored Boot Drive . . . . 17 Format of Boot Drive . . . . . . . . . . . . . . . . . . . 19 Deactivating the Fault Tolerance Service . . . . . . . . . 19 Missing Drive Letters in FTADMIN . . . . . . . . . . . . . 19 Synchronizing Internal Passwords . . . . . . . . . . . . . . 19 DOS LAN Requester . . . . . . . . . . . . . . . . . . . . . . 21 DLR and POPUP Support with Video Modes 3 and 73 . . . . . . 21 STACKS= Statement in CONFIG.SYS . . . . . . . . . . . . . . 21 LOAD= Statement when Running DLR Windows on Windows 3.0 . . 21 DLR and POPUP Support with 3270JPC (DBCS Only) . . . . . . 22 Productivity Aids . . . . . . . . . . . . . . . . . . . . . . 22 Handle APIs . . . . . . . . . . . . . . . . . . . . . . . . . 23 Remote Installation . . . . . . . . . . . . . . . . . . . . . 23 Remote Installation of Local Security . . . . . . . . . . . 23 Upgrading LAN Requester and LAN Server . . . . . . . . . . 23 Contents iii TRADEMARK NOTICES The following terms, denoted by an asterisk (*) in this file, are trademarks of the IBM Corporation in the United States and/or other countries: IBM OS/2 Win-OS/2 The following terms, denoted by a double asterisk (**) in this file, are trademarks of other companies as follows: Microsoft Microsoft Corporation Windows Microsoft Corporation Madge Madge Networks Ltd. Ringnode Madge Networks Ltd. Etherlink 3Com Corporation Page 1 NEW FUNCTIONS FOR LAN SERVER 3.0 LAN Server 3.0 includes all the functions of OS/2 LAN Server 2.0 plus the following new functions: ■ Advanced Server on OS/2 2.0 or high The Advanced server now runs on OS/2 2.0 or high. This allows access to more than 16MB of memory, which results in a performance improvement. The open file handle limits and the search handle limits are also improved in the LAN Server 3.0 Advanced server. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation" and the "Network Administrator Reference Vol. 2: Performance Tuning." ■ Network Transport Services/2 (NTS/2) NTS/2 is a separate IBM product that is also included with LAN Server 3.0. NTS/2 provides network support for the IBM OS/2 2.0 or high operating system by supplying NETBIOS and 802.2 protocols, NETBIOS VDD, and many network adapter drivers. It also includes a configuration utility, enhanced multi-adapter support, and remote installation support. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation," the "Network Administrator Reference Vol. 2: Performance Tuning," the "NTS/2 Redirected Installation and Configuration Guide," the "NTS/2 LAN Adapter and Protocol Support Configuration Guide," and the "NTS/2 Messages and Problem Determination Guide." ■ Redirected installation The LAN Server 3.0 product can be installed on requesters and servers remotely from a code server. The remote installation can be done in either an attended manner or an unattended manner through a response file. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation" and the "NTS/2 Redirected Installation and Configuration Guide." ■ Improved Fault Tolerance Improvements in the Fault Tolerance service include the ability to mirror without format and to mirror the boot partition. For information see the "Network Administrator Reference Vol. 1: Planning and Installation" and the "Network Administrator Reference Vol. 3: Network Administrator Tasks." ■ DOS LAN Requester New functions for DLR include support for DLR installation in a specific DOS session on OS/2 2.0 or high, improved DLR redirector performance, and DBCS-enablement of DOS LAN Requester Windows. For information, see the "Network Administrator Reference Vol. Page 2 1: Planning and Installation," the "DOS LAN Requester and DLR Windows User's Quick Reference," and the "LAN Support Program User's Guide." ■ Improved multi-adapter support In LAN Server 3.0, a single server can support more than 254 sessions on a single LAN or on multiple LANs by using multiple adapters. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation" and the "NTS/2 LAN Adapter and Protocol Support Configuration Guide." ■ Coexistence with TCP/IP LAN Server 3.0 coexists with TCP/IP clients and servers. LAN Requester/Server is supported over NETBIOS for TCP/IP. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation." ■ Optional client full-screen interface Requester workstations can be installed without the full-screen interface code, using instead the full-screen interface code that resides on the server. This saves about 2.5MB of disk space on the requester. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation" and the "Network Administrator Reference Vol. 3: Network Administrator Tasks." ■ Peer service This feature gives a requester some of the capabilities of a server by allowing a requester to share resources with one user at a time. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation," the "Network Administrator Reference Vol. 2: Performance Tuning," the "Network Administrator Reference Vol. 3: Network Administrator Tasks," and the NET SHARE, NET SESSION, NET START, and NET STATISTICS commands in the "OS/2 LAN Command Reference." ■ Virtual DOS LAN API support This feature enables DOS applications running in the Virtual DOS machine environments of OS/2 2.0 or high (including WIN-OS/2*) to call the LAN API functions without loading the DOS LAN Requester code. For information, see the "Network Administrator Reference Vol. 1: Planning and Installation" and the "OS/2 LAN Server Application Programmer's Reference." Page 3 ■ System management enhancements System management enhancements include the SNAPDUMP facility and two new categories of API functions, the Alias and Application categories. The functions in the Alias category manage information about network resources. The Application category functions give new capability to manage information about network applications. New functions in the User category enable the application programmer to control a user's account and make changes in the user's logon assignments and application selector remotely. These APIs allow application developers to manipulate user information on the domain controller. This simplifies the migration of OS/2 LAN Server into the Distributed Computing Environment (DCE) and allows application developers to create system management tools. For information, see "Productivity Aids" and the "OS/2 LAN Server Application Programmer's Reference." DISTRIBUTED FEATURES When you purchase a copy of the LAN Server 3.0 product, you are authorized to install the requester code and the server code on your server machine. When you order a Distributed Feature, you obtain a license to make a single copy of the part of the product identified as the Distributed Feature (the requester function) and the printed documentation. You must obtain a license for each workstation (requester/client) that uses any part of a Distributed Feature. For example, a DOS LAN Requester workstation would require purchase of one Distributed Feature and an OS/2 Requester workstation would require purchase of another Distributed Feature. The preceding information also applies to Distributed Feature upgrades. INSTALLATION Be sure to read the following information before you install LAN Server 3.0. LEVELS OF OS/2 NEEDED FOR LS 3.0 ENHANCEMENTS ■ LAN Server 3.0 requires OS/2 2.0 or high. ■ If you plan to use Fault Tolerance on your server workstation, it is recommended that you install the OS/2 2.0 Service Pak Version 2.00 (XR06050). ■ If you plan to use the Virtual DOS LAN API support, you must install the OS/2 2.0 Service Pak Version 2.00 (XR06050). ■ If your Advanced server has more than 16MB of memory, you must install the OS/2 2.0 Service Pak Version 2.00 (XR06050) to take Page 4 advantage of this additional memory. ■ If you are planning to install DOS LAN Requester in a specific DOS session on OS/2 2.0 or high using DOS 5.0 or high and the instructions in Chapter 6 of the "Network Administrator Reference Vol. 1: Planning and Installation," you must install the OS/2 2.0 Service Pak Version 2.00 (XR06050) in order to provide the correct level of the FSFILTER.SYS device driver needed to complete this procedure. This requirement does not apply if you are using DOS 3.30. If you want to install an OS/2 2.0 Service Pak on a 386 HPFS workstation, see the information in Appendix F of the "Network Administrator Reference Vol. 1: Planning and Installation." LAN SERVER 3.0 INSTALLATION RESTRICTIONS ■ The workstation on which you are installing LS 3.0 must have been restarted (IPLed) at least twice since LS 2.0 was installed. This is because the LS 2.0 installation program locks a message file and two IPLs are required so that the LS 3.0 installation program can use the file. ■ If Local Security is installed and the server name is changed, the name change will not always be effective. To fix this problem, log on locally with administrator authority and run ADDSVRIN.EXE from the command line. The correct syntax for the command can be found in the d:\OS2\INSTALL\IBMLANER.LOG file (where d is the boot drive). The line will be similar to the following: [14:51:43 DOSX C:\IBMLAN\NETPROG\ADDSVRIN.EXE REQSYD3 2 C:\IBMLAN] The command to run in this example is: C:\IBMLAN\NETPROG\ADDSVRIN.EXE REQSYD3 2 C:\IBMLAN ■ After the installation is complete, the LS 3.0 installation history log shows a summary of the status of the LS 3.0 components. The column marked "Configured" in this summary should be ignored. ■ Local Security can be installed only on HPFS drives. Installation of Local Security on non-HPFS drives is not supported. If the boot drive of your system is a FAT file system and you try to install Local Security through a response file, you will not receive any error message but the installation will not work, and you will not have Local Security Page 5 on your system. Non-response-file installations will display an error if you attempt to install Local Security on non-HPFS drives. ■ If you are upgrading an additional server to a domain controller using a response file, the keyword "InstallServer=" must be set to Install in the response file. If the keyword is not set as described above, then the "DOS LAN Requester Online Reference" and Timesource support will not be installed. ■ LAN Server 3.0 will only run on OS/2 2.0 or high. However, you can use an OS/2 1.3xx machine as a code server to install LAN Server 3.0 on other machines. To do this, you must use an OS/2 2.0 or high workstation and some form of redirection to store the LAN Server 3.0 product images in a directory on the OS/2 1.3xx machine. The redirection can be managed through LAN Server or through another product such as SRVIFS (shipped with NTS/2). ■ During LAN Server 3.0 installation, you will be referred to the "Migration Handbook." If you are upgrading from LAN Server 1.3 or 2.0 to LAN Server 3.0, you should instead refer to the "Network Administrator Reference Vol. 1: Planning and Installation." If you are migrating from PC LAN Program to LAN Server 3.0, refer to the "PC LAN Program Migration Guide." 386 HPFS You should read the following information if you are using the 386 high performance file system. Creating 386 HPFS Boot Diskettes After you install LAN Server 3.0 and restart your system, it is recommended that you create 386 HPFS boot diskettes, using the MAKEDISK utility. See Appendix C of the "Network Administrator Reference Vol. 3: Network Administrator Tasks" for information on MAKEDISK. 386 HPFS and the /Autocheck: Drive List The 386 HPFS supports an asterisk (*) in the /Autocheck: drive list on the IFS= line in the CONFIG.SYS file. The * in the /Autocheck: drive list causes the 386 HPFS to autocheck all HPFS drives. When the LAN Services installation program installs the 386 HPFS, it adds "/Autocheck:*" to the IFS= line for the 386 HPFS in the CONFIG.SYS file. The * should be left in place to ensure that Page 6 dirty drive message pop-ups do not occur during system IPL. Encountering dirty drive message pop-ups during system IPL may cause the system to hang. If your system does hang because of dirty drive message pop-ups during system IPL, use the following procedure: 1. Re-IPL your system using the 386 HPFS boot diskette. 2. Edit the CONFIG.SYS file on your system and add either * or the dirty drive's letter to the /Autocheck: drive list. 3. Re-IPL your system using the system's boot disk. Formatting a Drive as HPFS If you are trying to format a drive as HPFS and the 386 HPFS is installed on your machine, you may receive an HFS0102 message indicating that the drive is dirty and that CHKDSK /F must be run. To continue the format, select the "Return error to program" option. Servers with More Than 16MB of Memory For servers with more than 16MB of RAM, you can improve performance by defining a very large file system cache. This support is contingent on the presence of the "USEALLMEM" parameter on the 386 HPFS IFS= statement in the CONFIG.SYS file and the type of adapter(s) that the server is using. Three basic types of adapters are: ■ Shared RAM Adapters ■ 24-bit DMA Adapters ■ 32-bit DMA Adapters Considerations for installation of the 386 HPFS server with these types of adapters are: ■ Shared RAM Adapters - Shared RAM adapters typically can handle a physical address above 16MB and can support very large caches. Examples include the IBM Token-Ring Network 16/4 Adapter/A and the IBM PS/2 Adapter for Ethernet Networks. Page 7 ■ 24-Bit DMA Adapters - Adapters with 24-Bit DMA may not be able to handle a physical address above 16MB. If the adapter will not address above 16MB, then the "USEALLMEM" parameter on the 386 HPFS IFS statement in the CONFIG.SYS file should not be specified. To determine whether a 24-Bit DMA adapter can address above 16MB, you should contact the vendor of the adapter. - The IBM Token-Ring Network 16/4 Busmaster Server Adapter/A cannot address above 16MB, so "USEALLMEM" should not be specified. ■ 32-Bit DMA Adapters - Adapters with 32-Bit DMA should have full 32-Bit addressability and can support very large caches. Examples of such adapters include the 3Com 3C527 Etherlink/MC 32 Adapter** and the Madge Smart 16/4 MC Ringnode Adapter**. For the Madge adapter to be recognized by NTS/2 during installation, the SMARTND.NIF provided by Madge must be modified. Contact Madge technical support for the necessary changes. NETBIOS FOR TCP/IP If you want to use LAN Server over TCP/IP, you must purchase, in addition to the LAN Server product, the IBM TCP/IP for OS/2 product (version 1.2.1) and the IBM NETBIOS for TCP/IP for OS/2 product (version 1.3). The products must be installed in the correct order. You must install LAN Server first and then install TCP/IP. You can reinstall LAN Server after installing TCP/IP as long as a version of LAN Server was installed before TCP/IP. NETBIOS can be installed after TCP/IP is installed. To configure these products to work together, see Appendix D of the "Network Administrator Reference Vol. 1: Planning and Installation." If you install LS 3.0 over LS 2.0 and you are already using the NETBIOS for TCP/IP product, you must change the CONFIG.SYS and IBMLAN.INI files in a way similar to those in Appendix D of the "Network Administrator Reference Vol. 1: Planning and Installation." Page 8 REMOTE IPL SERVICE The following information applies to the Remote IPL service (also called RIPL). RESTRICTIONS: Memory constrained remote IPL workstations should not try to run too many applications concurrently. If too many applications are running concurrently, the performance may become very slow and the workstation may eventually lock up. If the workstation locks up, the only recovery may be to power off. This recovery could result in lost data. VALID OS/2 REMOTE IPL CONFIGURATIONS The following table identifies valid OS/2 Remote IPL configurations: ┌──────────┬────────────────────────────────────────────────────────┐ │ Server │ Operating System to be Remote IPLed │ │ Operating│ 2.0+ OS/2 For │ │ System │ 1.3.2 2.0 Service Pak 1/2 2.00.1 2.1 Windows │ ├──────────┼───────┼─────┼─────────────────┼────────┼─────┼─────────┤ │ 1.3.2 │ Yes │ Yes │ Yes │ Yes │ Yes │ Yes │ │ │ │ │ │ │ │ │ │ 2.x │ No │ Yes │ Yes │ Yes │ Yes │ Yes │ └──────────┴───────┴─────┴─────────────────┴────────┴─────┴─────────┘ Note: OS/2 2.1 and OS/2 For Windows are mutually exclusive. You can install only one of them in the RIPL tree, not both. SPECIAL PROCEDURES FOR OS/2 2.0+SERVICE PAK AND SERVICE PAK 2 Service Pak and Service Pak 2 for OS/2 2.0 do not update the RIPL directory tree correctly. The following rexx procedures have been provided to correct this problem: RPLSPDDI.CMD Installs the Service Pak files in the RIPL directory that were not installed by the Service Pak. A prior version of RPLSPDDI.CMD and RPLSETD.CMD are located on Service Pak diskette 2. Do not use the files on Service Pak diskette 2. RPLSP2DI.CMD Installs the Service Pak 2 files in the RIPL directory that were not installed by the Service Pak 2. After installing Service Pak or Service Pak 2, the appropriate REXX procedure must be run to finish the update of the RIPL directory tree. Page 9 OS/2 2.00.1 (OS/2 PREINSTALL) If you have access to the OS/2 Preinstalled Restore Diskette Pack, it is recommended that you use the RIPLINST utility (located on diskette 7) to install the new version of OS/2 2.0 in the directory d:\IBMLAN\RPL\OS2.20a (where d: is the drive where IBMLAN\RPL is installed). If you have the prior version of OS/2 2.0 installed, this will leave the prior version installed in the d:\IBMLAN\RPL\OS2.20 directory. After completing the migration to the new display drivers, the OS2.20 directory tree can be deleted. The menu interface has been updated to automatically select the FITS\DEFALT2A.FIT entry when a 'NEW' client is created using an OS/2 2.00.1 server record id. However, the master CONFIG.20 files are not automatically updated to OS/2 2.00.1 level so that back level versions of OS/2 can also be supported. RPLSETD must be used to update the client to the OS/2 2.00.1 level (refer to the section SUPPORT FOR OS/2 2.x 32-BIT DISPLAY DEVICE DRIVERS ). There is no support for SVGA on OS/2 2.00.1 RIPL clients. OS/2 2.1 IBM LAN Server 3.0 has been updated to support the remote IPL of OS/2 2.1 RIPL clients. The menu interface has been updated to automatically select the FITS\DEFALT21.FIT entry when a 'NEW' client is created using an OS/2 2.1 server record id. However, the master CONFIG.20 files are not automatically updated to OS/2 2.1 level so that back level versions of OS/2 can also be supported. RPLSETD must be used to update the CONFIG.20 file to the OS/2 2.1 level (refer to the section SUPPORT FOR OS/2 2.x 32-BIT DISPLAY DEVICE DRIVERS ). A new client created using the defaults, will be configured to support the IBMVGA32 display drivers. If the client has an XGA or 8514 display attached, RPLSETD must be run against the client to reconfigure the client for the correct display type. Currently, there is no support for SVGA on OS/2 2.1 RIPL clients. Page 10 OS/2 FOR WINDOWS IBM LAN Server 3.0 has been updated to support the remote IPL of OS/2 For Windows RIPL clients. OS/2 For Windows and OS/2 2.1 both install into the \IBMLAN\RPL\OS2.21 directory in the RIPL tree. For this reason, you can install OS/2 For Windows or OS/2 2.1, but not both. The Windows 3.1 code must be installed in the directory \IBMLAN\RPL\OS2.21\WINDOWS prior to using RIPLINST to install OS/2 For Windows in the RIPL tree. Three possible methods for completing this step are given below (chose one): 1. If the Windows 3.1 code is already installed on the server, copy the installed d:\WINDOWS directory tree into the d:\IBMLAN\RPL\OS2.21\WINDOWS directory tree. XCOPY d:\WINDOWS d:\IBMLAN\RPL\OS2.21\WINDOWS /S /E 2. If the Window 3.1 code is not installed on the server, boot the server with DOS and install Microsoft Windows 3.1 to a FAT partition on the server. Reboot the server and allow it to boot the OS/2 operating system. Copy the Windows files from the FAT partition to the d:\IBMLAN\RPL\OS2.21\WINDOWS directory tree. XCOPY e:\WINDOWS d:\IBMLAN\RPL\OS2.21\WINDOWS /S /E where e: is the partition where Windows is installed d: is the partition where OS/2 RIPL is installed 3. Install the Windows 3.1 code on a DOS machine. Remote IPL OS/2 to that machine. Start the LAN Requester and NET USE the drive where \IBMLAN\RPL is installed. Copy the Windows files from the local hardfile to the server. XCOPY e:\WINDOWS d:\IBMLAN\RPL\OS2.21\WINDOWS /S /E where e: is the partition where Windows is installed d: is the partition where OS/2 RIPL is installed To create OS/2 For Windows RIPL clients, use the OS/2 2.1 options. Page 11 SUPPORT FOR OS/2 2.x 32-BIT DISPLAY DEVICE DRIVERS The LAN Server 3.0 Remoteboot service supports by default the OS/2 2.0 16-bit VGA display device driver. If you have installed one of the following versions of OS/2 that support 32-bit display device drivers the in Remote IPL directory structure, you will need to upgrade existing RIPL clients to use the new display device drivers: - OS/2 2.0 + Service Pak - OS/2 2.0 + Service Pak 2 - OS/2 2.00.1 - OS/2 2.1 If you attempt to remote IPL an existing client workstation prior to upgrading the client, the client will hang while trying to initialize the display. A REXX command procedure, RPLSETD.CMD, has been provided that performs the following functions: - Upgrade existing RIPL clients that use 16 bit display drivers to use the new 32 bit VGA, XGA, and 16 bit 8514 display drivers provided in OS/2 2.00.1, 2.0 + Service Pak. It also supports the 32 bit 8514 display driver in OS/2 2.0 + Service Pak 2 and OS/2 2.1. - Can be used in some cases to change the display type (32 bit VGA,XGA, or 8514) that a RIPL client is using. RPLSETD does not support converting from the new 32 bit drivers back to the old 16 bit display drivers. If a Desktop exists for the RIPL client, changing to a higher resolution display type can cause unpredictible results. If a Desktop exists, the client definition recreate it, use RPLSETD to change to the higher resolution display type, and then boot the client and let it create a new Desktop. - Can be used to update a RIPL client to boot a different version of OS/2 2.x. The OS/2 2.x code must be installed Page 12 in the RIPL directory structure. The following OS/2 2.x versions conversions are supported: old version new version 2.0 2.00.1 2.0+Service Pak 1/2 2.1 OS/2 For Windows 2.00.1 2.0+Service Pak 1/2 2.1 OS/2 For Windows 2.0+Service Pak 1/2 2.1 OS/2 For Windows Note that there is no support for converting any of the newer versions back to the original OS/2 2.0. After a client is converted to OS/2 2.1 or OS/2 For Windows, RPLSETD cannot be used to convert back to 2.0+Service Pak 1/2 or 2.00.1. - Can be used to update a RIPL client to change the bus type, i.e. MCA or ISA/EISA. - Can be used to update a RIPL client to specify whether the SWAPPATH and WIN-OS2 'PagingFile' will be on a local hardfile or on the RIPL server. Client definitions can be updated individually or in a group (grouped by common attributes such as display type, bus type, and operating system). The client name DEFALT20 is a special client name used by the OS/2 Remoteboot support as a default when creating a new client (not modelling an existing client). If you are supporting prior versions of OS/2 (i.e. 2.0, 2.00.1, or 2.0 + Service Pak/Service Pak 2) in the RIPL directory tree, do not update DEFALT20 to support OS/2 2.1. You must leave DEFALT20 at its current level to support the prior versions of OS/2. To support OS/2 2.00.1 or 2.1 RIPL clients do the following (example is for OS/2 2.1): - Create a 'new' OS/2 2.1 RIPL client, for example, MODEL21, using the defaults. - Use RPLSETD to update MODEL21 to support OS/2 2.1. Then use MODEL21 as a model client to create all future 2.1 clients. - You may need to create multiple 2.1 models, one for each LAN type you support. The client names DEFALT2A and DEFALT21 are reserved. Do not create clients with these names. DEFALT2A and DEFALT21 are not a complete client definition like DEFALT20. They are used in conjunction with Page 13 DEFALT20 to support OS/2 2.00.1 and 2.1 clients. Do not attempt to update the DEFALT2A and DEFALT21 clients with RPLSETD.CMD. If the only version of OS/2 that will be installed in the RIPL directory tree is OS/2 2.00.1 or 2.1, you should update the client DEFALT20 to the appropriate level. Then all future default clients will automatically support the correct OS/2 version. COMMAND SYNTAX FOR RPLSETD.CMD The command syntax for RPLSETD.CMD is as follows: RPLSETD [/H] [/C:CLIENT[,CLIENT2,CLIENT3,...]] [/D:DISPLAY_DRIVER] [/O:CURRENT_OS2] [/N:NEW_OS2] [/B:BUSTYPE] [/S:SWAPTARGET] [/L:LOGFILE] [/R:RESPONSE_FILE] where: /H displays the syntax on screen. If specified, it must be the first parameter. /C:CLIENT[,CLIENT2,CLIENT3,...] (CLIENT or CLIENTLIST) is the name of one or more OS/2 Remoteboot client workstations that are to be updated. If multiple client names are specified, each client name must be separated with a comma. Imbedded blanks are not allowed. The response file keywords CLIENT and CLIENTLIST are equivalent to each other. They may be specified as many times as necessary. This is a required parameter if the /R parameter is not specified. When specified, at least one other parameter must also be specified. /D:DISPLAY_DRIVER (DISPLAYDRIVER) is the new display type for the client definition. The following display types are valid: IBMVGA32 32-bit VGA display driver IBMXGA32 32-bit XGA display driver IBM8514 16-bit 8514 display driver (2.0+SP or 2.00.1) 32-bit 8514 display driver (2.0+SP2 or 2.1) 8514_32 Alternate 32-bit 8514 display driver name (2.1) This parameter is normally optional, however, it must be specified when an existing 2.0 or 2.00.1 RIPL client is converted to 2.1 by specifying the /N parameter. Page 14 When upgrading the display type of an existing RIPL client (it has booted at least one time and has a Desktop) from VGA to XGA or 8514, you must delete and recreated the RIPL client and then run RPLSETD.CMD. If you update the existing client to a higher resolution display type, many of the display sizing characterics in OS2.INI do not get updated. As a result you end up with some objects in VGA resolution and some in the higher resolution. If no Desktop exists for the client, it can be updated to change to a higher resolution. When the Desktop is created during the first boot, it will reflect the display characteristics for which it is configured. /O:CURRENT_OS2 (CURRENTOS2DIR) is the root directory under \IBMLAN\RPL for the current version of OS/2 2.0 or 2.00.1 that the client is using. This parameter is case sensitive. The /O parameter should only be specified when you want the client operating system type verified before updating to a new operating system type. If /O is not specified, the current operation system being used by the RIPL client is determined from the client.FIT file. If the /O parameter is specified, then the /N parameter must also be specified. /N:NEW_OS2 (NEWOS2DIR) is the root directory under \IBMLAN\RPL for the version of OS/2 2.x that the client is to be switched to. This parameter is case sensitive. The default is OS2.21. The /O and/or /N parameters should only be specified when you need to switch a client from an older OS version to a newer OS version. When an existing RIPL client is updated to OS/2 2.1, the client WINOS2 *.INI and *.GRP files must be replace with the 2.1 versions of these files. The old files are renamed to *.IBK and *.GBK. When the user is satisfied that these old files are no longer needed for reference, they should be deleted. /B:BUSTYPE (BUSTYPE) is the type of I/O bus used by the RIPL client machine. Valid types are: MCA - Micro-channel ISA - AT compatable EISA - AT compatable /S:SWAPTARGET (SWAPTARGET) is an indicator of where the SWAPPER.DAT file will reside: Valid values are: L - file will reside on local hardfile of RIPL client S - file will reside on RIPL server This parameter also control the location (local/server) of the 'PagingFile' parameter in the OS/2 2.1 WIN-OS2 SYSTEM.INI file. Page 15 /L:LOGFILE (LOGFILE) is the drive, path, and filename of a file to which all messages and errors are to be logged. If this parameter is specified, the only errors displayed on the screen will be for a failure to open the logfile or for missing required parameters in the response file. /R:RESPONSE_FILE is the drive, path, and filename of a file that contains the command inputs in keyword form (keyword=value). The valid keywords are indicated above in parenthesis () following each /X: syntax. Only one keyword can be specified per line in the response file. The CLIENT or CLIENTLIST parameter and at least one other parameter are required when using a response file. If the /R parameter is specified, all other parameters specified on the command line are ignored. Examples: - To update the DEFALT20 client to use the 32 bit VGA display driver and switch the operating system from OS2 2.0 to OS2 2.1, type: RPLSETD /C:DEFALT20 /D:IBMVGA32 /N:OS2.21 This will update the default files to support OS/2 2.1 and the new VGA display driver. These files are used when defining clients using the default configuration. Note: If you plan to also support previous versions of OS/2 (i.e. 2.0, 2.00.1, or 2.0 + Service Pak/Service Pak 2), do not update the DEFALT20 client. - To update the MACH001 client to use the 32 bit XGA display driver and switch the operating system to OS/2 2.1, type: RPLSETD /C:MACH001 /D:IBMXGA32 /N:OS2.21 - To update the MACH001 client to use the 32 bit XGA display driver, verify the current operating system is OS2.20a, and switch the operating system to OS/2 2.1, type: RPLSETD /C:MACH001 /D:IBMXGA32 /O:OS2.20a /N:OS2.21 - To update the MACH001 client to specify a bus type of ISA and set the SWAPPATH/PagingFile to the RIPL server, type: RPLSETD /C:MACH001 /B:ISA /S:S Page 16 - To update the MACH001 client to use the 32 bit VGA display driver, verify the current operating system is OS/2 2.0, switch the operating system to OS/2 2.1, specify a bus type of ISA, and set the SWAPPATH/ PagingFile to the RIPL server, type: RPLSETD /C:MACH001 /D:IBMVGA32 /O:OS2.20 /N:OS2.21 /B:ISA /S:S - To update multiple clients, MACH001 and MACH002, to use the 32 bit VGA display driver and switch the operating system to OS2.21, type: RPLSETD /C:MACH001,MACH002 /D:IBMVGA32 /N:OS2.21 RPLSETD RESPONSE FILE KEYWORDS The valid response file entries/keywords are: ; Comment line [GROUP] (this statement is optional for the first group and required for all subsequent groups) DISPLAYDRIVER= CLIENT= CLIENTLIST= CURRENTOS2DIR= NEWOS2DIR= BUSTYPE= SWAPTARGET= A ';' in column 1 indicates the line is a comment. Leading blanks are allowed on keyword statements. The keywords are defined above in the RPLSETD syntax description. [GROUP] designates the start of a RIPL client or group of clients that share the same configuration characteristics. When the [GROUP] statement is encountered, the client machines in the previous group are updated according to the specified keywords. Multiple [GROUP]s can appear in the response file. This allows a single response file to process a number of different configurations. The [GROUP] statement is optional for the first group in the response file but is required for all subsequent groups. CLIENT and CLIENTLIST are equivalent and multiple entries can be specified on either. Multiple CLIENT and CLIENTLIST keywords can be specified per group. Only one of each of the other keywords is allowed per group. Page 17 Example: To use the response file option, do the following: 1. Create an ASCII file that contains the appropriate keyword values. For example: [GROUP] (optional) ; Update existing clients to support the IBMXGA32 display driver, ; switch from OS2.20 to OS2.21, support the MCA bus, and put the ; swappath on a local hardfile. CLIENT=DEFALT20 CLIENT=MACH001,MACH002 CLIENTLIST=MACH003,MACH004 DISPLAYDRIVER=IBMXGA32 CURRENTOS2DIR=OS2.20 NEWOS2DIR=OS2.21 BUSTYPE=MCA SWAPTARGET=L [GROUP] (required) ; Update client for ISA bus and put the swappath on the RIPL ; server (no local hardfile). no hardfile CLIENT=MACH005 BUSTYPE=ISA SWAPTARGET=S 2. Type the following command: RPLSETD /R:d:\path\response_filename where d:\path\response_filename is the fully qualified file name of the resonse file. GETRPL.EXE UTILITY GETRPL has been updated to be CID enabled. Two new command line options have been added to support this. They are: /L:Logfile A fully qualified path name for a logfile to which all messages and errors are logged. If /L is specified, GETRPL runs in an invisible window (no dialog boxes). /O:OS2_2x_path The fully qualified path of the OS2.2x directory in the RIPL directory tree that is to be processed by GETRPL. For example: /O:C:\IBMLAN\RPL\OS2.21 If /O is not specified, GETRPL will use the last 'target file' saved in OS2SYS.INI by the RIPLINST utility. If RIPLINST has never been run, GETRPL will default the value to C:\IBMLAN\RPL\OS2.20. Page 18 UPDATING MASTER WORKPLACE SHELL OS2.INI FILES Some users have a master customized OS2.INI file that is copied to the client directory each time the client is remote IPLed. This master file must also be update to identify the type of display driver that the client workstation is using. Clients with different display types (i.e. vga, xga, 8514) MUST use different master OS2.INI files. To update a master OS2.INI file, enter the following command: RPLRXUTL /D:DISPLAY_DRIVER /C:INI_FILENAME where: /D:DISPLAY_DRIVER is the same as for RPLSETD. /C:INI_FILENAME is the drive, path, and filename of the master OS2.INI file to be updated. For example: RPLRXUTL /D:IBMVGA32 /C:E:\IBMLAN\RPL\MASTER\VGAOS2.INI The RPLRXUTL utility will not display any error information. It does return with a non-zero return code if there was an error. If you need to verify error information, invoke RPLRXUTL from a CMD procedure (batch file or REXX) so that the return code can be tested. SUPPORTING MULTIPLE LEVELS OF THE OS/2 OPERATING SYSTEM It is possible to install and support multiple levels of the OS/2 2.x operating system on a RIPL server. This section documents the correct procedure to use to support such an environment. The basic procedure is as follows: 1. Run the OS/2 utility RIPLINST to install the OS/2 code in the RIPL directory tree. You must be carefully to use the version of RIPLINST that matches the level of code to be installed. RIPLINST is located on diskette 7 of all OS/2 2.x installation diskettes. RIPLINST is unique for each version of OS/2. Page 19 2. After running RIPLINST, run the LAN Server utility, GETRPL. GETRPL uses information stored in the OS2SYS.INI file by RIPLINST so it is very important that GETRPL be run before using RIPLINST to install another version of OS/2. 3. Repeat steps 1 and 2 for each version of OS/2 that will be RIPLed. 4. Check the \IBMLAN\RPL\RPL.MAP file. Look for the OS/2 server records, they start with yyyyyyyyyyyy or ;yyyyyyyyyyyy and field two will contain a name like OS220*.CNF or OS221*.CNF. A comment in column 1 indicates the record is disabled. Make sure that the appropriate records are enabled or disabled based on what OS/2 version(s) you installed. 5. Determine whether the special RIPL client, DEFALT20, should be updated by RPLSETD. This depends on what OS/2 versions are installed. OS/2 version 2.0 uses 16 bit display drivers. OS/2 versions 2.00.1, 2.0+Service Pak, and 2.1 use 32 bit display drivers for VGA and XGA support. However, there are slight differences in the XGA support between 2.00.1 and 2.0+Service Pak/2.1. If OS/2 2.0 is present, DEFALT20 must not be updated. It must remain as is to allow the creation of future 2.0 clients. If OS/2 2.0 is not present, then DEFALT20 could be updated with RPLSETD to support either 2.00.1 or 2.0+Service Pak/2.1. To update DEFALT20 to support 2.0+Service Pack, enter the command: RPLSETD /D:IBMVGA32 /C:DEFALT20 To update DEFALT20 to support 2.00.1, enter the command: RPLSETD /D:IBMVGA32 /C:DEFALT20 /N:OS2.20a The /N parameter indicates that the new default target operating system will be \IBMLAN\RPL\OS2.20a. The RIPLINST for OS/2 2.00.1 defaulted to a target directory of \IBMLAN\RPL\OS2.20a. To update DEFALT20 to support 2.1, enter the command: RPLSETD /D:IBMVGA32 /C:DEFALT20 /N:OS2.21 The /N parameter indicates that the new default target operating system will be \IBMLAN\RPL\OS2.21. The RIPLINST for OS/2 2.1 defaults to a target directory of \IBMLAN\RPL\OS2.21. Page 20 6. Since the special RIPL client DEFALT20 must be associated with a specific OS/2 version, it is recommended that model clients be created for the other OS/2 versions installed in the RIPL tree. RPLSETD can be used to update the model client definitions to point to the correct operating system. Then these model clients can be used to create future clients for each type operating system. PRESERVING THE ABILITY TO REMOTE IPL OS/2 1.3 CLIENTS If you upgrade an existing OS/2 1.30.1/LAN Server 2.0 server that has OS/2 Remote IPL installed to OS/2 2.0/LAN Server 3.0, the ability to remote IPL OS/2 1.3 client workstations is not preserved. If you need to preserve the ability to remote IPL OS/2 1.3 client workstations, you must use the procedure described below when upgrading the server. Two REXX command procedures, RPLSAV13.CMD and RPLRES13.CMD, have been provided to assist you in saving and then restoring the ability to Remote IPL OS/2 1.3 client workstations. These procedures are located on the LAN Server 3.0 Productivity Aids diskette 1 in the file RPLUTIL.ZIP. The following procedure assumes that you are installing LAN Server 3.0 on top of an existing LAN Server 2.0. Warning: The procedure will preserve 23MB of OS/2 1.3 remote IPL data. Be sure that you have sufficient space on your hardfile for this data and LAN Server 3.0 before starting this procedure. 1. If you have OS/2 1.3 and LAN Server 2.0 Advanced installed and you want to upgrade to OS/2 2.0 and LAN Server 3.0, the 386HPFS access control lists must be removed prior to installing OS/2 2.0. Insert the SERVER 1 diskette of LS 3.0 and run PREPACL to remove the access control lists. To run PREPACL, enter the following command: A:PREPACL /P /B:C:\ACL.LST /D:C: You can type PREPACL to get the parameter list. Basically P says remove access control lists, B says save them in a list with path and filename and D says remove the access control lists on the C drive. Page 21 If you have OS/2 on the C drive and LAN on the D drive, THIN386 can be run on the D drive to remove enough access control lists in order to install LAN Server 3.0 over LAN Server 2.0. PREPACL can be run on the C drive for OS/2. 2. Install the remote IPL REXX procedures located on the Productivity Aids diskette 1. To install these REXX procedures, do the following: a. Change to the d:\IBMLAN\INSTALL directory. b. Enter the following command(all on one line): PKUNZIP2 -D A:\RPLUTIL.ZIP d:\IBMLAN\RPL RPLSAV13.CMD RPLRES13.CMD where d is the drive where LAN Server is installed. 3. Prior to installing OS/2 2.0, execute the REXX procedure RPLSAV13.CMD to save the appropriate OS/2 1.3 Remote IPL directories and files. To run the procedure, enter the command: d:\IBMLAN\RPL\RPLSAV13.CMD RPLSAV13.CMD performs the following functions: - Renames RPL\MUGLIB to RPL\MUGLIB13. - Renames RPL\IBMCOM to RPL\IBMCOM13. - Renames RPL\IBMLAN to RPL\IBMLAN13. - Renames RPL\OS2 to RPL\OS213. - Copies RPL.MAP to RPL\RPL13\. - Copies RPL\OS2BB*.CNF to RPL\RPL13\. Everything is saved under the RPL directory. Any other application subdirectories that are unique to OS/2 1.3 must be manually saved. 4. Install OS/2 2.0. (Be sure to select "REXX" on the OS/2 Setup and Installation panel.) 5. Install NTS/2. 6. Shutdown. 7. Install LAN Server 3.0. 8. Shutdown. Page 22 9. Insert SERVER 1 diskette in drive A and run PREPACL. To run PREPACL, enter the following command: A:PREPACL /R /B:C:\ACL.LST where R restores the ACLs and B specifies the access control list that is to be restored. 10.Run the REXX procedure RPLRES13.CMD to make the changes required to support the OS/2 1.3 code base saved in step 3. To run the procedure, enter the following command: d:\IBMLAN\RPL\RPLRES13.CMD RPLRES13.CMD performs the following functions: ■ Renames RPL\OS213 to RPL\OS2. ■ Copies the saved CONFIG.13 files (in IBMCOM13 directory) to RPL\IBMCOM. ■ If necessary, updates RPL.MAP to contain the OS/2 1.3 server records. ■ Copies the saved OS2BB*.CNF files back to the RPL directory and updates them to be compatible with LAN Support Program V1.35. ■ Updates all the OS/2 1.3 *.FIT files to refer to the renamed MUGLIB13, IBMCOM13, and IBMLAN13 directories. 11.Unpack RIPLINST from diskette 7 of OS/2 2.0 diskettes and run the RIPLINST utility. 12.Start the server and log on, then run GETRPL. When GETRPL prompts for the first OS/2 1.3 Install diskette, select the Cancel option. Selecting the Cancel option will result in a warning message when GETRPL completes, but the message can be ignored. 13.If there were any predefined DOS workstations, a new DOS image needs to be made in order for the workstations to be able to remoteboot. 14.OS/2 1.3 client workstations can now be defined and remote IPLed. Existing OS/2 1.3 client workstations can be remote IPLed. OS/2 2.0 client workstations can now be defined and remote IPLed. Page 23 SERVER NAME/WORKSTATION NAME RESTRICTION (DBCS ONLY) When installing a server that will be used as an OS/2 Remoteboot server, the server name can only contain DBCS characters in the range X'81'-X'9F.' The same restriction also applies to remote IPL workstation names. This restriction does not apply to Remoteboot servers that only boot DOS workstations. DISK FAULT TOLERANCE The following information applies to the Fault Tolerance component. SCSI DRIVES In a workstation with SCSI drives, if it appears that your system is hanging on reads or writes or you have excessive errors on SCSI drives, be sure your SCSI adapters are terminated properly. The following information will help you do so: 1. A SCSI card has one bus, which extends internally and externally. Each end must be terminated exactly once. The different drives terminate differently. 2. If no drives are attached to a card internally, then a card edge terminator is installed on the gold tabs at the top of the card. Page 24 If no drives are attached externally, then on the IBM SCSI adapter with cache, an external pin-in-socket terminator is used. On an IBM SCSI adapter with no cache, either that terminator is used or the on-board terminator near the external connector is inserted. 3. When drives are attached (internally, externally, or both), each cable must be terminated at the end. The black drives (60, 80, 120, 160) have terminators on the underside of the drive and usually have white slips of paper attached to them. The gold drives (more than 300MB) have a terminator that gets inserted between the cable and the connector on the drive. LIMIT OF 24 PARTITIONS Fault Tolerance has a limit of 24 partitions. Since FDISK and FDISKPM do not count secondary (mirror) partitions, these utilities will allow you to create more than 24 partitions. If you accidentally create more than 24 partitions and restart the computer, the mirroring support will not be activated. To recover from this: 1. Remove the DISKFT.SYS and the FTMONIT.EXE statements from CONFIG.SYS. 2. Run FDISK or FDISKPM to remove the extra partitions. 3. If your boot drive is mirrored: a. Delete FTCFG.SYS on drive C:. b. Delete FTCFG.DRV on your boot drive. 4. Restart your server computer. 5. Run FTSETUP to reactivate Fault Tolerance support. Do not make any changes to the drive configuration at this time. (The statements in CONFIG.SYS that you removed in Step 1 will be replaced at this time.) 6. Restart your server computer. 7. Run FTSETUP to check the configuration. Page 25 FDISK AND FDISKPM MARKING OF FREE DISK SPACE Sometimes FDISK or FDISKPM marks free space on a disk as primary space. Primary space cannot be used for secondary partitions of mirrored drives. If the free primary space is contiguous with a logical drive or other free space, it can be changed to "pri/log" space. With FDISK or FDISKPM, select the primary space and then select Delete partition. COMMANDS IN FTREMOTE RESPONSE FILE In an FTREMOTE response file, if a command includes both valid and not valid information, FTREMOTE will execute the valid part of the command and ignore the rest. RECOVERING FROM A FAILURE OF A MIRRORED BOOT DRIVE Perform steps 1 through 3 after Fault Tolerance has been configured but BEFORE the boot drive has failed. The diskettes created from these steps can then be kept until needed. 1. Copy the following files to diskettes: a. From the \OS2\DLL subdirectory copy: ■ DISPLAY.DLL ■ DOSCALL1.DLL ■ MSG.DLL ■ NLS.DLL ■ PMGPI.DLL ■ PMGRE.DLL ■ PMSHAPI.DLL ■ PMSHLTKT.DLL ■ PMSPL.DLL ■ PMWIN.DLL ■ SPL1B.DLL b. From the \MUGLIB\DLL subdirectory copy: ■ NETAPI.DLL ■ NETOEM.DLL ■ NETSPOOL.DLL ■ MAILSLOT.DLL c. From the \IBMLAN\NETPROG subdirectory copy: ■ FTREMOTE.EXE d. From the \IBMLAN\NETLIB subdirectory copy: ■ FT.DLL e. From the \OS2 subdirectory copy: ■ FDISK.COM Page 26 2. Create the 386 HPFS boot diskettes, using the MAKEDISK utility. See Appendix C of the "Network Administrator Reference Vol. 3: Network Administrator Tasks" for information on MAKEDISK. 3. Run FTSETUP or FTREMOTE and note the location of the boot drive's secondary partition. This information will be needed by FTREMOTE during the recovery process. The following steps should be done when the boot disk fails: 4. Replace the failed disk. If necessary, format the disk using the procedure on the reference diskette. 5. IPL the computer using the 386 HPFS boot diskettes created in step 2. 6. Copy all the files that were stored on diskette in step 1 to an existing drive so that the files can be accessed by FTREMOTE during the recovery procedure. 7. Create an FTREMOTE response file with the following format: COMMANDS < recover loc=2:35 secondary > Note: The location of the secondary partition in the above example is for completeness only; the secondary partition of any given boot drive will probably not reside at this location. Also, there must be storage space AT LEAST the size of the partition plus 1 megabyte at the beginning of the hard disk containing the boot drive. 8. Run FTREMOTE using the following syntax: FTREMOTE /r:filename where filename is the name of the response file from step 7. 9. Run FDISK. a. Install the Boot Manager. b. Add the newly created drive to the Boot Manager list. (This drive will be the first drive on the replaced disk.) 10.Exit FDISK and restart the server. Page 27 FORMAT OF BOOT DRIVE When Fault Tolerance has been activated, the boot drive must be formatted as HPFS. If the boot drive is formatted as FAT, DISKFT.SYS may unmirror all mirrored drives. DEACTIVATING THE FAULT TOLERANCE SERVICE When the Fault Tolerance service is activated through FTSETUP, the Fault Tolerance device driver, DISKFT.SYS, is placed at the top of the CONFIG.SYS file. This makes DISKFT.SYS the first device driver to be started when the computer is restarted. If you run FTSETUP to deactivate Fault Tolerance but it does not seem to be deactivated after you restart your computer, edit the CONFIG.SYS file and remove the following lines: DEVICE=<drive>:\IBM386FS\DISKFT.SYS RUN=<drive>:\IBMLAN\NETPROG\FTMONIT.EXE After you restart your computer, Fault Tolerance will be deactivated. MISSING DRIVE LETTERS IN FTADMIN Drive letters will occasionally not be displayed in FTADMIN due to an OS/2 2.0 or high problem. SYNCHRONIZING INTERNAL PASSWORDS Under unusual circumstances, the internal password between an additional server and the domain controller may become unsynchronized. This can also occur if a backup copy of the file NET.ACC is installed on the domain controller or additional server. Symptoms of this occurrence are the following error messages: ■ OS/2 error 5: Access denied when attempting to start the NETLOGON service on an additional server ■ NET3224: Error in changing this machine's password Page 28 displayed in the error log of the additional server followed by multiple occurrences of: NET3226: Error in synchronizing with primary domain controller To recover from this situation, the Administrator should perform the following steps: 1. Ensure that the additional server is listed on the domain controller in the Full Screen Interface as a server. If it is not listed, add it. If it is listed, ensure that the additional server has a user ID and is also a member of the group SERVERS. 2. Reset the password for the additional server user ID on the domain controller using the following command: NET USER <Servername> <New Password> 3. On the additional server (with the NETLOGON service stopped), change the role of the server to standalone using the following commands: NET STOP NETLOGON NET ACCOUNTS /ROLE:STANDALONE 4. On the additional server, ensure that the additional server has a user ID and that it is a member of the group SERVERS in its local definition: NET USER <Servername> NET GROUP SERVERS If the additional server is not locally defined, add it in the following way: NET USER <Servername> <New Password> /add NET GROUP SERVERS <Servername> /add If it does exist, reset its password as follows: NET USER <Servername> <New Password> Page 29 In either case, the password you set locally and on the domain controller must be the same. 5. Restore the role of the additional server and restart the NETLOGON service in the following way: NET ACCOUNTS /ROLE:MEMBER NET START NETLOGON DOS LAN REQUESTER If you plan to use DOS LAN Requester, read the following information. DLR AND POPUP SUPPORT WITH VIDEO MODES 3 AND 73 Only applications using Video Modes 3 and 73 will receive pop-ups when the /POP parameter is used. Users of applications using any video modes other than 3 and 73 should use NET LOG /ON to log messages since no message pop-ups will appear on the display when these applications are running. STACKS= STATEMENT IN CONFIG.SYS It is recommended that you set STACKS=0,0 in the CONFIG.SYS file if you want to use DOS LAN Requester. Failure to do so may cause problems on your workstation. LOAD= STATEMENT WHEN RUNNING DLR WINDOWS ON WINDOWS 3.0 You will get an unrecoverable application error (UAE) if WINPOPUP.EXE is loaded before RUNLSAPP.EXE when you are using DLR Windows 3.0 on Windows 3.0. This problem does not exist if you are using Windows 3.1. If you want to manually insert RUNLSAPP.EXE in the LOAD= statement of the WIN.INI file, be sure that RUNLSAPP.EXE is loaded before WINPOPUP.EXE. The LOAD= statement is as follows: LOAD= RUNLSAPP WINPOPUP Page 30 DLR AND POPUP SUPPORT WITH 3270JPC (DBCS ONLY) 3270JPC users should use NET LOG /ON for receiving messages when using the /POP option. When /POP is used with NET START, the pop-up will be displayed in the DOS screen when running with 3270JPC. PRODUCTIVITY AIDS The following productivity aids are on the Productivity Aids diskettes that are included in your OS/2 LAN Server Version 3.0 package. These productivity aids are provided on an "as-is" basis without any warranty of any kind, including the warranties of merchantability and fitness for a particular purpose which are expressly disclaimed. CONMAN Displays the current state of all LAN connections while allowing you to connect to, release, and reassign LAN resources. LANACCSS Lets you obtain information about the access to server resources given to a single user ID. LANACNT Lets you change the settings for the Netlogon service. LANMSG Lets you view and process a LAN message file on a requester. Page 31 LANUSER2 Allows a user logged on with administrative privileges to create a user ID from a previously created ID. NEWPW Allows you to manage passwords on multiple domains by changing the password on all the domains you specify. RPLADD Lets you create multiple new remote workstation machine definitions automatically. RPLDEL Lets you delete any number of remote workstation machine definitions automatically. SNAPDUMP/2 Gives you the ability to capture a wide variety of system data into a single, easily transportable file. VENDOR Can be used to control access to remote vendor software. HANDLE APIS The Handle APIs NetHandleGetInfo and NetHandleSetInfo do not work when called from a 32-bit application developed using IBM C Set/2. REMOTE INSTALLATION The following section gives additional information on remote installation. REMOTE INSTALLATION OF LOCAL SECURITY If you are installing Local Security using the LAN Configuration Installation Distribution (CID) Utility, be sure to remove the CASAGENT statement and the CMD statement from the PRIVINIT.CMD file after the remote installation completes. The CASDELET program will not do this automatically. Leaving the CMD statement in PRIVINIT.CMD leaves the STARTUP session open as a privileged session and presents a security exposure. UPGRADING LAN REQUESTER AND LAN SERVER This section contains three upgrading scenarios: ■ Upgrading LAN Requester 2.0 on OS/2 2.0 or high to LAN Requester 3.0 on OS/2 2.0 or high ■ Upgrading LAN Requester 2.0 on OS/2 1.3 to LAN Requester 3.0 on OS/2 2.0 or high Page 32 ■ Upgrading LAN Server 2.0 with the 386 HPFS on OS/2 1.3 to LAN Server 3.0 with 386HPFS on OS/2 2.0 or high. Note: The following scenarios for upgrading OS/2 LAN Requester would also apply to an initial installation of OS/2 LAN Requester, although the method of installation would probably be boot diskettes and the parameters used in some of the response files (for example, formatting your hard drive) would sometimes differ. Before using any of the following scenarios, you should be familiar with the "NTS/2 Redirected Installation and Configuration Guide" and the "Network Administrator Reference Vol. 1: Planning and Installation." The following is an example of the product-specific definitions for LAPS and the LAN Requester component of LAN Server 3.0. These definitions are designed to be used in a situation where you are upgrading a LAN Requester Version 2.0 running on OS/2 2.0 or high to a LAN Requester Version 3.0 running on OS/2 2.0 or high. See also the procedure that follows the product-specific information. The product-specific information that follows is only part of what is used by the procedure. For information on other product-specific information, see the "NTS/2 Redirected Installation and Configuration Guide." Page 33 x.laps_prod = 2 /* structure index */ x.2.name='LAPS' /* product name */ x.2.statevar = 'CAS_' || x.2.name /* state variable name */ x.2.instprog = 'x:\img\laps\laps ', /* fully qualified install program */ '/e:prod ', /* production installation */ '/s:x:\img\laps ', /* source directory */ '/t:' || bootdrive || '\ ', /* target directory */ '/l1:x:\log\laps\' || client || '.log ', /* log file */ '/r:' /* response file flag (auto selection) */ x.2.rspdir = 'x:\rsp\laps' /* response file directory */ x.2.default = 'lapsrsp.rsp' /* default response file name */ x.laninstr = 5 /* structure index */ x.5.name='LS 3.0' /* product name */ x.5.statevar = 'CAS_' || x.5.name /* state variable name */ x.5.instprog = 'x:\img\ls30\laninstr ', /*fully qualified install prog*/ '/req ', /* install a requester */ '/l1:x:\log\ls30\' || client || '.L1 ', /* error log file */ '/l2:x:\log\ls30\' || client || '.L2 ', /*history log file*/ '/r:' /* response file flag (auto selection) */ x.5.rspdir = 'x:\rsp\ls30' /* response file directory */ x.5.default = 'lanreq.rsp' /* default response file name */ x.laps_maint = 12 /* structure index */ x.12.name='LAPS MAINTENANCE' /* product name */ x.12.statevar = 'CAS_' || x.12.name /* state variable name */ x.12.instprog = 'x:\img\laps\laps ', /* fully qualified install prog*/ '/e:maint ', /* maintenance installation */ '/s:x:\img\laps ', /* source directory */ '/t:c:\maint ', /* target directory */ '/tu:' || bootdrive || ' ', /* location of config.sys */ '/l1:x:\log\laps\' || client || '.log ', /* log file */ '/r:x:\rsp\laps\lapsrsp.rsp' /* response file */ x.12.rspdir = '' /* no auto selection */ x.12.default = '' Page 34 The following is an example of the command procedure used to upgrade a LAN Requester Version 2.0 running on OS/2 2.0 or high to a LAN Requester Version 3.0 running on OS/2 2.0 or high. /****************************************************/ /* DO NOT MODIFY THE NEXT LINE */ /****************************************************/ OVERALL_STATE = GetEnvironmentVars() Do Forever Select when OVERALL_STATE = 0 then do /* Check if booted from hard drive -- if it was, then goto state 1 */ if BootDriveIsFixedDisk() == YES then iterate /* Install LAPS maintenance */ if RunInstall(x.laps_maint) == BAD_RC then exit if RunInstall(x.thinifs) == BAD_RC then exit /*Inst SRVIFS request*/ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call RebootAndGoToState(2) /* Reboot and skip next state */ end when OVERALL_STATE = 1 then do /* Install LAPS production */ if RunInstall(x.laps_prod) == BAD_RC then exit Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 2 then do if RunInstall(x.laninstr) == BAD_RC then exit /* Install requester*/ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 3 then do if RunInstall(x.ifsdel) == BAD_RC then exit /*Delete SRVIFS request*/ if RunInstall(x.casdelet) == BAD_RC then exit /* Delete LCU */ Call Reboot /* Reboot */ end end end exit /*************************************************************/ Page 35 The following example is of product-specific information used in a LAN CID Utility command file to install OS/2 LAN Requester. This example was used with the procedure following it to upgrade a LAN Requester Version 2.0 running on OS/2 1.3 to a LAN Requester version 3.0 running on OS/2 2.0 or high. The product-specific information that follows is only part of what is used by the procedure. For information on other product-specific information, see the "NTS/2 Redirected Installation and Configuration Guide." x.laninstr = 5 /* structure index */ x.5.name='LS 3.0' /* product name */ x.5.statevar = 'CAS_' || x.5.name /* state variable name */ x.5.instprog = 'x:\img\ls30\laninstr ', /*fully qualified install prog*/ '/req ', /* install a requester */ '/l1:x:\log\ls21\' || client || '.L1 ', /* error log file */ '/l2:x:\log\ls21\' || client || '.L2 ', /* history log file */ '/r:' /* response file flag (auto selection) */ x.5.rspdir = 'x:\rsp\ls30' /* response file directory */ x.5.default = 'lanreq.rsp' /* default response file name */ Page 36 The following example command procedure is for upgrading a LAN Requester Version 2.0 running on OS/2 1.3 to an LAN Requester Version 3.0 running on OS/2 2.0 or high. /****************************************************/ /* DO NOT MODIFY THE NEXT LINE */ /****************************************************/ OVERALL_STATE = GetEnvironmentVars() Do Forever Select when OVERALL_STATE = 0 then do /* Check if booted from diskette -- if it was, then goto state 1 */ if BootDriveIsDiskette() == YES then iterate if RunInstall(x.semaint) == BAD_RC then exit /*Install maintenance*/ if RunInstall(x.laps_prep) == BAD_RC then exit /*Install LAPS prep*/ if RunInstall(x.thinifs) == BAD_RC then exit /*Inst SRVIFS request*/ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 1 then do if RunInstall(x.seinst) == BAD_RC then exit /* Install OS/2 */ if RunInstall(x.laps) == BAD_RC then exit /* Install LAPS */ if RunInstall(x.thinifs) == BAD_RC then exit /*Inst SRVIFS request*/ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 2 then do if RunInstall(x.laninstr) == BAD_RC then exit /*Inst LS requester*/ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 3 then do if RunInstall(x.ifsdel) == BAD_RC then exit /*Delete SRVIFS request*/ if RunInstall(x.casdelet) == BAD_RC then exit /* Delete LCU */ Call Reboot /* Reboot */ end end end exit /*************************************************************/ Page 37 The following are two product-specific definitions for the THIN386 utility. These definitions are used in the procedure that follows them to upgrade a LAN Server 2.0 Advanced Server workstation with the 386 HPFS and OS/2 1.3 to a LAN Server 3.0 Advanced workstation with the 386 HPFS and OS/2 2.0 or high. These product-specific definitions are described in more detail in the "Network Administrator Reference Vol. 1: Planning and Installation." The product-specific information that follows is only a part of what is needed by the procedure. For information on other product-specific information, see the "NTS/2 Redirected Installation and Configuration Guide." x.thin386 = 14 /* structure index */ x.14.name='THIN386' /* product name */ x.14.statevar = '' /* state variable name */ x.14.instprog = 'x:\img\ls30\thin386 ', /* fully qualified install program name */ '/b:' || bootdrive , /* config.sys location */ '/t:' || bootdrive ||'\service\temp386 ', /*path to temp HPFS*/ '/l1:x:\log\386hpfs.log' /* log file */ x.14.rspdir = '' /* no auto selection */ x.14.default = '' x.sec386 = 15 /* structure index */ x.15.name='SEC386' /* product name */ x.15.statevar = '' /* state variable name */ x.15.instprog = 'x:\img\ls30\thin386 ', /* fully qualified install program name */ '/b:' || bootdrive , /* config.sys location */ '/t:' || bootdrive || '\ibm386fs ', /* path for final HPFS */ '/l1:x:\log\386hpfs2.log' /* log file */ x.15.rspdir = '' /* no auto selection */ x.15.default = '' Page 38 The following product-specific information defines the BACKACC utility for use with the LAN CID Utility. It is recommended that you use the BACKACC utility when upgrading a server. x.backacc = 17 x.17.name='BACKACC' /* product name */ x.17.statevar = '' /* state variable name */ x.17.instprog = 'x:\img\ls30\backacc ', /*fully qualified inst program*/ bootdrive || ' ', /* directory to be backed up */ '/f:x:\backups\' || client || '.acl ', /*backup file*/ '/a /s ', /* no overwrite and subdirectory params */ '/l1:x:\log\ls30\' || client || '.bka' /* log file */ x.17.rspdir = '' /* no auto selection */ x.17.default = '' The following section is an example of a command procedure used in the LAN CID Utility REXX command file to upgrade a LAN Server 2.0 Advanced Server workstation with the 386 HPFS and OS/2 1.3 up to a LAN Server 3.0 Advanced workstation with the 386 HPFS and OS/2 2.0 or high. In addition to using THIN386, which is required for upgrading a workstation with the 386 HPFS, this procedure also uses the BACKACC utility. BACKACC creates backup files for NET.ACC, NET.AUD (if it exists), and for access control profiles. It then uses COPY to copy the NETACC.BKP and NETAUD.BKP files to the code server. The backup file for access control profiles is saved directly to the code server as defined above in BACKACC's product-specific information. Page 39 /****************************************************/ /* DO NOT MODIFY THE NEXT LINE */ /****************************************************/ OVERALL_STATE = GetEnvironmentVars() Do Forever Select when OVERALL_STATE = 0 then do /* Check if booted from diskette -- if it was, then goto state 1 */ if BootDriveIsDiskette() == YES then iterate if RunInstall(x.backacc) == BAD_RC then exit 'copy c:\ibmlan\accounts\netacc.bkp x:\backups\' || client || '.acc' 'copy c:\ibmlan\logs\netaud.bkp x:\backups\' || client || '.aud' if RunInstall(x.semaint) == BAD_RC then exit /*Inst maintenance sys*/ if RunInstall(x.thin386) == BAD_RC then exit /*Run THIN386 utility*/ if RunInstall(x.laps_prep) == BAD_RC then exit /*Install LAPS prep*/ if RunInstall(x.thinifs) == BAD_RC then exit /*Inst SRVIFS request*/ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 1 then do if RunInstall(x.seinst) == BAD_RC then exit /* Install OS/2 */ if RunInstall(x.sec386) == BAD_RC then exit /*Run THIN386 utility*/ if RunInstall(x.laps) == BAD_RC then exit /* Install LAPS */ if RunInstall(x.thinifs) == BAD_RC then exit /*Inst SRVIFS request*/ if RunInstall(x.casinstl) == BAD_RC then exit /* Install LCU */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 2 then do if RunInstall(x.laninstr) == BAD_RC then exit /* Install Server */ Call CheckBoot /* Reboot if it was requested */ end when OVERALL_STATE = 3 then do if RunInstall(x.ifsdel) == BAD_RC then exit /*Del SRVIFS request*/ if RunInstall(x.casdelet) == BAD_RC then exit /* Delete LCU */ Call Reboot /* Reboot */ end end end exit /*************************************************************/ Page 40