Branch Office Deployment, Part 2: An Imaginary Branch Installation Project
Articles and Tips: article
Senior Systems Consultant
Novell Consulting Services
01 Jan 1997
Concludes this two-part series on deploying a branch office network using a product development approach to streamline the process.
- Introduction
- The Existing Technology
- The Planning Phase
- The Proof of Concept Phase
- The Prototype Phase
- The Pilot Phase
- The Productization Phase
- The Production Phase
- Conclusions
Introduction
Imagine that you have received a contract to reimplement the retail automation network of a major bank. It is an unusual project because it offers you an opportunity to work with Novell Partners, leveraging their skills to the benefit of both companies, and helping to define a new market segment. After carefully examining Novell's appropriate product offerings, you see that Novell incorporates the best technology to support the needs of a centrally-managed branch office network.
This branch office network environment is significantly different from the conventional large LAN implementation. The large LANs you have worked with before have been building-wide, campus, or enterprise multi-campus environments, supported by a staff who can provide personal assistance to their users. The WAN interconnections with which you have become familiar have accomplished much but with high bandwidth links, the cost of which have been justified by the large numbers of users that would take advantage of them, and by the volume of data needing to be moved.
In contrast, this branch network consists of more than 350 small remote sites, each with an average of 12 users. Transaction volumes, and subsequently, bandwidths are typically small. Providing local support personnel is impossible, due to financial and geographic constraints. System reliability and auto-recovery are of paramount importance in this branch, since systems on this site must be able to operate unsupervised.
One of the project goals is to maintain a level of service similar to what the employees and customers are used to, to reduce the size of the support infrastructure, and to reduce training. Also, the bank wants to provide a more widely deployed platform that will enable them to provide additional, more advanced services to their customers, faster and more easily than they have been able to until this time.
The Existing Technology
The existing branch automation is based on proprietary IBM 3600 and 4700 series technology; semi-intelligent controllers that enable customized software to control special-purpose terminals. The terminals are connected in a loop configuration, and share a single IBM LU0 session with a complimentary host application. The corporate side of the bank already has an investment in NetWare, and therefore wants to continue using Novell products to support their IBM LU0Cin essence, a NetWare Branch Server.
The servers will be deployed over the same SNA Network infrastructure as the 4700s. The SNA Network consists of 9600 Bps analog leased circuits and uses IBM intelligent modems, which can be managed from NetView. The bank has future plans to re-implement on more modern technology, but for the time being, the bank's telecom department needs to cost-justify a multi-million dollar telecommunications investment.
You decide to organize the project into six phases; the six "P"s of product development:
Planning
Proof of Concept
Prototype
Pilot
Productization
Production
The Planning Phase
Your first step is to determine the business and technological requirements. Since your client has already started working with IBM OS/2-based technology, you begin to examine that deployment. You would like to re-use as many of the design decisions as was possible, as well as all of the business-line specific custom-developed software. So you ask questions about the reasoning behind the selection of various components.
Assessing Business Needs
In order to be sure your final product satisfies the customer's needs as optimally as possible, you want to understand the business requirements and the impetus behind them. You decide to do some research in this area before moving on to the more technical issues.
Through talks with your client, you determine that the new system must be able to meet their following business needs:
Provide a new infrastructure for future deployment of advanced technology.
Reduce training time.
Minimize system maintenance.
Maximize system availability.
Provide transaction throughput equal to or better than current system's.
Provide access to bank-wide services such as host-based e-mail.
Planning for Future Advances
As part of your infrastructure planning to support future upgrades, you decide to delay implementation of a more advanced front-end until a later date. The existing user population is accustomed to a character-based interface, so you decide to provide a DOS character-based application that will provide host-like sign on screens and menus. The users will not see a DOS prompt.
To keep costs down, you will use NetWare's Menu system with a pre-existing internally-invented sign-on screen program, providing an end product that will be easy to teach and easy to use. To help control user access, the system will use simple DOS batch files to control the flow of the user presentation.
NetWare, through the login script, offers a system implementer a better set of tools to manage the presentation and pass system related data (such as the Bindery or the NetWare Directory Service) than does any other system. The result is a tight integration between the system data and the implementation itself.
Minimize Training
Frequent change and reassignment of personnel is common to the retail banking industry. Therefore, your client bank had previously implemented minimized training in their branches. The bank does not want to provide training to branch employees beyond the absolute minimum. You demonstrate to your client that NetWare can be implemented with the same training strategy they used for their previous IBM OS/2 LAN Server system.
Minimize Maintenance
System maintenance should be minimal for software based systems, but there is always the need to deal with hardware problems. Here Novell shines. The disk mirroring and duplexing in NetWare far surpasses the mirroring capabilities your client has been experiencing with LAN Server. A significant portion of NetWare system maintenance, such as remirroring a replacement drive, is done with the system up and running. The dynamic nature of NetWare's configuration will provide unprecedented ease of maintenance for users who have been accustomed to dealing with the endless rebooting of OS/2-based servers.
In case of drive failure, the only changeover procedure that will be needed is to order another drive and schedule a service call. This is a tremendous change from the complex manual recovery procedure required to restore their current LAN server system.
Access to Legacy Services
NetWare 3270 LAN Workstation software will provide access to legacy host services such as Office Vision, utilizing the existing 9600bps analog leased lines.
Assessing Technical Requirements
When you and your client initially discuss replacing the existing IBM OS/2 system with NetWare, the bank details three technical requirements that you must meet, or, if possible, exceed:
LU0 Support
Remote Management Support
Remote Software Distribution Support
LU0 Support. Although NetWare already features basic support for LU0 (added to NetWare for SAA v1.3), a driver will be necessary for this implementation. The workstation software vendor has already used IBM's LUA API to support previous implementations of LU0. LUA is the model on which Novell has modeled LUx. LUx is a superset of LUA, and provides additional functionality in the area of session establishment with the NetWare for SAA server.
Remote Management Support. Historically, all of the bank's network management was handled through NetView on the host, which was a 3270 terminal-based interface and provided no direct remote access. Because NetWare traditionally incorporates strong remote management capabilities, you now describe how NetWare SNA Links enable the implementation of other technologies, such as the NetWare Management System (NMS) and the NetWare LANalyzer Agent, remote LAN access for file and print service, remote console access through the RCONSOLE utility, as well as any thirdparty products. All of these advantages will be gained, plus you provide additional functionality to the familiar 3270-based NetView management product.
Remote Software Distribution Support. Novell's ManageWise/ Distribute product provides electronic software distribution to the servers as well as to the workstations.
Matching Business Requirements to Technological Solutions
The bank's new branch network must provide branch users with:
File service
Fault tolerance
SNA connectivity for LU0 and LU2 applications
Network management
Software distribution
WAN Routing
The existing SNA Network will remain as the physical infrastructure.
Standardization of Sites
The bank's existing LAN server-based system enabled them to standardize implementation across their various sites. The planned NetWare implementation will not only maintain standardization, but will actually enhance it. Maintaining maximum consistency from branch to branch will enable the help desk to more easily diagnose and resolve problems.
The existing 4700 environment uses a simple, two-digit terminal identifier to identify the terminals within a branch. Therefore, every NetWare branch server will use a similar one-byte code, corresponding directly to the last two digits of the locally administered MAC address. Using this address formula, which includes the branch number and server instance, ensures that addresses will be unique across the entire network.
Once the distinction between workstations is defined by the least significant byte of the MAC address, it becomes possible to define a consistent configuration, wherever the server is to be installed. The node directory contains SNA configuration files which will point to the appropriate sessions, which, in turn, are assigned to the particular node. This architecture means that the only differences between the various installations will be the names of the communication servers.
Other standardization strategies address:
Batch files
Microsoft Windows "PIF" files
NetWare group definitions and trustee assignments
Drive map assignments
Print queues
Remote printer names
User naming
Assessing Needs and Planning Training
Your client bank has communicated that one of their goals in this implementation is to simplify and minimize training. There were several reasons for settling on this strategy:
Previous wholesale training of personnel has proved of limited effectiveness, due to a high rate of turnover or relocation.
Training all employees to the level of CNA is cost-prohibitive.
If all employees are called on to perform network administrative tasks, their efficiency in their normal job function will suffer.
Minimizing the number of people performing redundant job functions will minimize strain on help desk resources.
Teller and platform users will need to know how to:
Log on
Select an item from a menu
Use the banking specific applications
Logout
In addition, one person in each branch will be trained as a Password Administrator. They will not need to know how to create a user, since all users and groups are created in advance and are named by a formula rather than a user's real name. These user IDs are disabled until they are needed. The password administrator needs to know how to:
Enable or Disable an account
Add or remove a full name on an account
Reset a user's password
Reset a user's intruder detection status
This limited training strategy created the need for a highly centralized management infrastructure. A central LAN is planned. This LAN will service the network management and software distributions functions, and will be the responsibility of the data center.
Assigning Responsibilities
Understanding the different roles and responsibilities engendered by your system facilitates design decisions regarding which tasks need to be automated and what facilities are required by support personnel.
You have already defined the role of Password Administrator. You now identify three more groups that will provide internal support: the Systems Group, the Help Desk Group, and the Data Center Group.
The Systems Group. The Systems Group will be responsible to develop and update both system and application software. You find that the bank has some explicit requirements regarding segregation of duties, meaning that a development group is not permitted to deploy any software. Therefore, you will have to create a a well-defined change control procedure to enable them to deliver the updates to the Data center. The Data Center, in turn will test any updates and then, upon acceptance, will deploy them. To provide backup support and techincal advice, your Systems Group will interface regularly with Novell Developer support.
The Help Desk Group. The Help Desk Group will serve as the front line to resolve problems and assist the branch administrators. You make sure the Help Desk phone number is assigned and distributed to all appropriate parties.
|
Note: As a part of the workstation design, you mightconsider making the HelpDesk number a variable.This will allow the same configuration tobe supported by different organizations indifferent regions. |
The Data Center Group. Backup problem resolution will come from the Data Center Operations Group. The Data Center will be responsible for proactive network management and software distribution, in addition to any issues the help desk might escalate to them that the Data Center cannot solve. Any such issues will be escalated to Novell Technical Support.
The Outside Vendor Group. In addition to the internal support groups, you have selected one additional group, an outside company, as an outsourcing vendor for physical delivery of the network infrastructure and equipment. In addition, this group will be responsible for software installation and startup problem resolution. The outside group will interface primarily with the data center and the line of business.
Selecting Products for Your Project
At this point in the project, when you ordinarily would be selecting products, you find that the bank has already done three years of development on OS/2 LAN Server. Their original OS/2-based products are:
IBM OS/2 v1.3
IBM LAN Server Program v1.3
IBM LAN Network Manager (Entry-Level)
IBM Communications Manager
IBM FBSS/2
IBM NetView/DM (host)
After examining the functions provided by each of these components, you select the following products to support this environment and provide superior functionality:
NetWare v4.10
NetWare for SAA v2.0
NetWare Multiprotocol Router v3.1
NetWare SNA Extensions (NetWare Link/SNA)
NetWare Management Agent v2.1
NetWare LANalyzer Agent v1.0
ManageWise/Distribute
To justify your selections to bank management, you explain the benefits of NetWare in this environment:
NetWare provides a faster, more robust file server environment with superior fault tolerance.
NetWare for SAA is a widely deployed commercial product, and is more desirable than a specialized, limited-distribution product; IBM's FBSS, for example. NetWare's management products provide comprehensive, easy to use management tools.
NetWare for SAA supports Link/SNA, providing a wide-area network without the need to invest in a totally new network infrastructure, and still providing a migration path to more advanced WAN technologies.
This "nearly-free" WAN backbone supports other facilities, including RCONSOLE, SNMP network management, remote file services, software distribution, and other third-party network management products.
Providing Support for the Branch Network
In addition to selecting your products for each branch, you need to provide centralized support for all the various branches. You plan a support network that includes several NetWare Link/SNA HUB routers and a ManageWise System console.
Although you originally proposed an integrated hub card internal to the server, the bank prefers to use a discrete network infrastructure, so Madge Smart-CAUs will be used, because they can be managed via IPX over NetWare Link/SNA.
Scaling Issues
As you begin to assess the project needs, you realize that there were many third-party products that can help you deliver a top solution. However, because the bank has 380 branches, you must be extremely cost-conscious. A decision to use an additional product, or simply to add more memory, will multiply the cost by 380.
By justifying two-third party products on a cost-per-benefit ratio, you add them to the project: Madge SmartCAUs (to take advantage of their manageability through IPX) and Intel's LANSelect (used to emulate a pop-up function provided by one of the third party add-ons for the OS/2-based solution).
Capacity Planning
You recognize the need to consider scaling in terms of capacity planning. The existing network infrastructure offers very low bandwidth. Therefore, it is necessary to determine what effects background router traffic might have on the network.
As a model, you select the largest of your client bank's several retail branch networks, which has 180 branches. You decide to study two traffic areas: first, the link from each branch up to the front-end processor, and second, the link from the front-end processor to the "hub" router for NetWare Link/SNA.
Looking at the individual branch lines, you find that each branch generates seven services and four routes. Since this is consistent across most other branches, you create a graph to predict the anticipated background RIP and SAP traffic.
Without any filtering, the background RIP/SAP traffic would overwhelm the 9600Bps links once 150 or so branches were connected. However, only two SAPs are necessary for the central support site to be fully functional; 0x230, and 0x23A, which are used for the NetWare Management Agent and the NetWare LANalyzer Agent, respectively. Filtering everything but these two out, the traffic load will remain below the available bandwidth. However, it will still become significant (over 40%) by the time 180 branches are connected.
Because NetWare Link/SNA is an encapsulation of a switched networking protocol on an exclusively point-to-point link, your analysis takes an alarming turn. If you do not filter all inbound SAPs from being repeated outbound, the traffic loads between the front-end processor and the hub server will increase geometrically (see Figure 1).
Figure 1: The hub router SAP load.
This happens because RIP and SAP traffic are broadcasts, whereas SNA messages are connection-oriented and by their nature do not support any kind of multicast message. Therefore, each broadcast must be turned into n number of unicast messages, where n is the number of connections to each router. Therefore, not only do the SAP and RIP tables get larger as you add more branches, their transmission must also must be repeated more times. The n2 factor in the formula creates the geometric relationship.
Your interim solution will be to filter out all outbound SAPs and RIPs except a specific list, then turn on specific branches for necessary SAP types as required. By changing the traffic load to each branch to a constant level, you remove one factor from the equation of traffic load to the hub, thereby changing the relationship of branches to load from geometric to linear.
The bank plans to make extensive use of the SNMP MIB browser, which will give them valuable information but is not tied to any SAPs.
Filtering the Background Traffic
Within the NetWare Mulitprotocol Router v3.1 and other associated products, there are at least four possible approaches to resolving this issue: implement NLSP, NetWare/IP, Static routes with dynamic links, and SAP/RIP filtering.
Implement NLSP. NetWare Link State Protocol is a replacement protocol for RIP/SAP. Instead of sending out an entire routing and server name table, as does RIP/SAP, NLSP only sends out changes. In addition, it compreses SAP transmissions. Testing of this option indicated it will put a minimal strain on WAN links (less than 7% of a 9600Bps SDLC link) while providing full visibility.
Implement NetWare/IP. Because NetWare SNA Extentions supports the TCP/IP protocol, you can eliminate IPX and its associated RIP/SAP traffic by using NetWare/IP. To a lesser degree, this change would also reduce traffic as would NLSP by eliminating the SAP and RIP protocols. Although NetWare/IP uses the well-understood industry standard TCP/IP protocol, it does impose some additional implementation responsibilities that are normally not required when you use NetWare over IPX.
Implement Static Routes and On-Demand Links. MPR v3.0 includes a new feature for dial-up links that could also be used to minimize traffic. By defining static routes and on-demand connections, the router could automatically connect the branches when a link is requested, then drop the link after it has been inactive for a period of time. Configuring this feature, however, will require a great deal of manpower.
Implementing More Sophisticated RIP/SAP Filtering. The filtering available in MPR v3.0 can be configured to allow all RIPs and SAPs in, but to allow only a specific list in the outbound direction. This enables you to minimize the traffic and keep a constant background load per branch. Ultimately, your customer decides to start with the filtering method, because they are more familiar with that. In the future, the plan is to move toward NLSP.
Understanding the Mission Critical Application
The key application set in your bank is the Platform and Teller software. The systems developers use a set of software tools from Online Financial, a division of MicroBild, in Atlanta, GA. These tools enable the bank's programmers to deal with screens formats and host communications through a wide variety of interfaces, including LU0 and LU2.
The presentation and transaction components of the application, known as "overlays", are built in an interpretive language called CAPS. The CAPS layer interfaces with a driver layer, known as PORTRAIT. PORTRAIT provides generic interfaces to mask the transaction programmer from the specific details of the particular platform, as well as from the complexities of developing to esoteric protocols like LU0.
The developers of these overlays never need to worry about LU0 SNA issues like bracketing or line turnarounds; these are transparently handled by PORTRAIT. The module that is currently providing the LU0 connectivity is called PROFBSS. Your goal is to move to NetWare for SAA transparently, without changing applications at all.
In order to implement this goal, you arrange for Online Financial and Novell to work together to build new driver. Because of the benefits to both companies, you don't anticipate any political problems. Online Financial will be able to expose millions of NetWare users to their technology, and Novell, in addition to delivering a solution for this particular client, can use the history of this development as a future example of one of the ways that financial applications can use Novell technologies.
Solving Unexpected Availability Problems
One of the unexpected challenges of this project is that several of your identified software component releases prove to be unavailable this early in your process. Although you are confident that they will be available when you actually need them for installation, you cannot waste the interim time.
As an interim solution, you decide to use existing releases of the desired software in combination with the existing system. This creates a sort of "hybrid" and enables you to move on with your work. You can become familiar with existing bank products that are being retained, and bank employees can begin to familiarize themselves with the types of products that will be incorporated into their final system.
The Proof of Concept Phase
Your Proof of Concept phase of this project will entail a unit testing and a limited system integration testing. You will test each of the system products for the individual environment, then any modules that rely on other modules will be tested together.
To begin your Proof of Concept phase, you mediate the joint venture of Online Financial and Novell Engineering to create the software driver necessary to replace the IBM FBSS driver currently in use. By facilitating communications between the two groups of engineers, you ensure that the project is progressing as smoothly as possible.
Three weeks later, the prototype driver is ready for testing. Although the driver is not complete, it is advanced enough to enable you to demonstrate that the existing branch application can operate through NetWare for SAA without changing the application at all. You have met one of your initial goals. You arrange any required changes and discuss the final development issues with the two engineering groups, then move on to the NetWare Links/SNA.
Your next goat is to prove that NetWare Link/SNA will work over the bank's existing infrastructure. You call on Novell's engineering group, who work closely with the bank's System Programming group to identify and solve the problem. They discover that the static routes between various front-end processors have not been defined, and that the lines that have been selected for testing are affected. By moving to different lines for testing, you resolve this issue.
Next, you must prove the viability of the ManageWise and other components over NetWare Link/SNA. You are able to confirm that both the NetWare Management Agent and the NetWare LANalyzer agent function over an SNA connection. However, you find an incompatibility between the algorithm that Madge SmartCAUs uses to communicate over a router with the level of LAN Driver required for the NetWare LANalyzer agent. You contact Madge, who quickly creates a new version of the microcode for their CAU. This solves the problem and demonstrates the viability of NMS over SNA Links.
Your next proof of concept challenge lies in the implementation of software distribution. You test delivery of software to the ManageWise/Distribute NLM over the SNA connection successfully. However, you document that the NLM is only capable of distributing to a maximum of 8 concurrent connections, which will affect your planning of the implementation of software distributions.
The Prototype Phase
Now that your individual components have been tested and any problems solved, you can proceed to the first full integration test; the prototype. The prototype is your first attempt to fully integrate the entire suite of products into a single system, simulating the actual configuration that will be installed into a branch. When this step is successfully completed, you will have a model from which you can later take the system to production.
The server-based software products include:
NetWare v4.10
NetWare for SAA v2.0
NetWare Multiprotocol Router v3.1
NetWare SNA Extensions v3.1
NetWare Management Agent v1.5
NetWare LANalyzer Agent v1.0
ManageWise/Distribute
The server hardware configuration is:
IBM PS/2 Model 9595-OMT
Two mirrored SCSI 1Gb disk drives (one internal, one external)
32MB RAM
Microdyne NetWare for SAA Adapter for PS/2 (also known as an "R3SDLC" adapter)
Madge Smart MC3216 Ringnode Bus Mastering Token Ring Adapter
The physical LANs are 16Mb Token Ring, wired with either Type 1 or Type 5 cable, dependent on the age of the site. All sites will include either a Madge SMARTCAU or SMARTCAU+. Most Type 1 sites will retain IBM LAMs, the type 5 wired sites will primarily use Madge SMARTLAMs.
The client applications include:
Teller and Platform Overlays
OLF CAPS and Portrait
NetWare 3270 LAN Workstation for DOS v3.0
Intel LANSelect
Lotus 1-2-3 v2.4
Symantec Q&A Write v4.0
Power Up! Calendar Creator Plus v4.0
Folio v3.01 (Hypertext Policy and Procedure manual)
Ranch Enterprises Calculator
"Bonds" (a custom developed DOS Bond Redemption application)
Client workstation hardware includes IBM PS/2 Model 55 SX, 56 SLC, and 77. Workstation RAM varies from 2MB to 8MB.
Preparing for the Prototype
You prepare for the prototype phase, and fix a delivery date. Your plan for acceptance testing includes a week of client transaction applications regression testing using the NetWare platform rather than the IBM FBSS.
The first step is to create a complete implementation of all of the proposed technologies on one platform. Incompatibilities are identified and fixed through conventional technical support channels.
A problem is identified in a particular application function called "pass through." In this function, the LU2 data streams have proprietary data attached to their front ends, making them effectively LU0. Although Online Financial has created a special version of their LU2 emulator to do this, it is not working with engineering level NetWare for SAA LUx libraries.
In conference calls between yourself, Novell engineering and OLF, the problem is identified as a DOS re-entrancy issue related to the fact that the prototype libraries supplied by Novell Engineering were not intended be run as a TSR, but all of the OLF support modules were implemented as resident code. Terminate and stay-resident modules frequently need to be able to check DOS flags before executing particular functions. OLF needs the real TSR version of our libraries to solve the problem. Once again, you call on Novell Engineering. They deliver an alpha TSR version of the code. By recompiling and relinking, OLF is able to produce a version of the pass through function that works properly in time for the prototype test.
The Prototype Test
Although you are nervous during the testing week, everything goes fairly smoothly. Fortunately, a reference platform from a previous implementation is available help determine the source of problems when they surface. After the last application or platform problems are solved, the platform is declared viable.
The Pilot Phase
You can now turn your efforts to preparation for the pilot. The pilot phase will be your first real branch installation. The selected site is a mid-to-large size branch. You have arranged for a bank employee to serve as on-site coordinator for your installation team, and to provide input that will help you perfect your final product.
Creating the First Pilot Server
One of your goals in creating the first pilot server is to identify some consistent techniques for installing and configuring the server, with an eye toward later productizing the package. You also intend to minimize the number of steps in the configuration process.
To make remote administration and management trhough NetView easier, the data center wants to dedicate host sessions to particular workstations. You want to keep as the bulk of the configuration and software files on the server. As a compromise, you introduce the concept of a node directory; a directory tree rooted at SYS:NODES, containing directories numbered 00 through 99. These two digit numbers correspond to the last two digits of the locally administered MAC address of the workstation. You assign drive V as the search drive and map root it. These directories will hold any information that is specific to the physical computer.
A Distribution Change. This particular product integration consists of utilities that will be used to copy user information from the server bindery and synchronize it with the ManageWise/Distribute user file. This would work if the same user ID always logged in at the same computer. But in your application, this isn't true; user IDs are not even names! The service structure of the bank makes it likely that personnel will move from desk to desk on a daily basis, or even several times a day. Because of this requirement, you know you must make a fundamental change in the way ManageWise/Distribute delivers files.
Instead of using human IDs, you create ManageWise/Distribute users that correspond to the computers. You piggyback on the NODE directory tree, creating users whose IDs are the same two-digit directory names mentioned above. You then place the MWDIST receive directories in subdirectories of that same V drive. To automate this process, you write a batch file to create the users and install the MWDIST directories.
Assigning Printers to Workstations. Part of your project is to enable employees to print to the network printer closest to the workstation they happen to be using at the time. This means that you need to devise a simple way to assign network printers to workstations. The first part of the solution is to number the printers. This enables you to acquaint branch personnel with the locations of the numbered printers, rather than to maintain 360 different sets of names in 360 different locations.
The second part of the solution involves using that same two digit portion of the MAC address to create a table that will associate MAC addresses with default printers.
An example of this type of table, as it might appear in a system login script is shown below:
IF %<ADDR< = "11" THEN DOS SET DQ="01"< IF %<ADDR< = "12" THEN DOS SET DQ="01"< IF %<ADDR< = "13" THEN DOS SET DQ="01"< IF %<ADDR< = "14" THEN DOS SET DQ="02"< IF %<ADDR< = "17" THEN DOS SET DQ="03"
As part of future enhancement you plan to separate this file from the system file, then use an INCLUDE statement to run it within the system script.
Providing a Sign-on Screen. Your next challenge is to provide a sign-on screen. Remember that your user community has previously used IBM OS/2 LAN Server, and are accustom to having a full-screen login.
You enlist a simple program that the bank had created for another NetWare based system. The program displays a greeting and checks three environment variables, displaying in separate fields any variables it finds. The user can edit the fields, and when he or she exits, the program creates a batch file called SETID.BAT. This batch file contains SET statements for the three variables, and it executes CONT.BAT.
The Menu. Next comes the menu system. Although other menu packages are available, your client does not have the time to evaluate the different offerings at this time. You need an interim solution. You might be able to implement a more sophisticated commercial package, such as SABER, as part of the improvements planned for a later date. For the time being, you decide to use a program created for Novell's internal use, called MENUGEN. The program will concatenate separate menu option files together into a custom menu of NetWare .MNU files, based on bindery group membership. Since you use the groups to define the menu options, we can also use the groups to assign trustee rights for the users to the various applications.
You hard-code MENUGEN to use a directory named SYS:PUBLIC/AUXFILES. This directory serves the additional purpose of being the repository for various add-on utilities, batch files, menu files, Windows PIFs, and so on.
Another benefit of using MENUGEN is that it adheres to a convention that adopt in other parts of the system to minimize the amount of maintenance required. The .MNU files that MENUGEN uses always refer to .BAT files. The .BAT files execute the various applications by changing the current directory of a generic application search drive (Y), then changing it back when done.
To allow for the possibility that the drive letters might change in the future, you make sure that batch files never refer to network drive letters directly. Instead, they will refer to them as variable names that are set inside the system login script. Although this seems convoluted, it results in the maximum normalization of information back to the system login script.
As an example, some of the variables that are set might include:
%NODE% Drive letter with NODE specific information %AUX% Drive letter assigned to the AUXFILES directory %USR% Drive letter for the user's home drive %APPS% Drive letter for the generic application directory
As a final safeguard to shield the command line from user access, you download version 2.34PTF of MENU.EXE, which corrects a known problem that can leave users unexpectedly facing a DOS prompt.
Defining Some New Standards
Although you intend to adopt to the bank's existing system LAN Server-based standards, there are still some standards and conventions that you must define.
User Naming Convention.
Your user naming convention is based on this formula:
xyyynn
where:
x = "P" for platform or "T" for teller
yyy = the branch number
nn = the user's former 4700 ID
Fifty users of each type are created by default, corresponding to the way the system had been set up under the IBM 4700. You automate the creation of users by using a combination of batch files and the MAKEUSER utility. After users are created in this system, they have to be disabled. You use features from Network Navigator to create a script to disable the created users.
Token Ring Addressing Convention. All of the bank's branches use Token Ring LANs and take advantage of their locally administered address feature. The following formula determines the server's token ring address:
40000B yyyz00
where:
yyy = the branch number
z = the server "letter" (A - F)
You also adopt the SNA profile name, and use the LAN Server domain name as the NetWare server name. (Under LAN server, each branch is a domain, therefore there is a one-to-one correspondence.)
IPX Network Numbers. Because your branch network will never be internetworked with outside companies, you choose a simple mnemonic numbering convention for IPX network numbers.
You assign 19 network numbers to each branch; for example:
|
Internal IPX Network Address |
B yyyz386 |
|
Token Ring IPX Network Address |
B yyy8025 |
|
DOSbox Virtual\ Ethernet IPX Address |
B yyyz DB0 |
|
SNA Links Virtual IPX Address Pool |
B yyyz960 thru B yyyz96F |
|
NetWare MPR Virtual IPX Address Pool |
B yyyz560 thru B yyyz56F |
where:
yyy = the branch number
z = the server "letter" (A - F)
Adopting a mnemonic convention also does away with the need for certain SAPs to come through the SNA Links hub routers; it becomes possible to RCONSOLE into a server or use the MIB browser in NMS without having to look up an address.
Standardizing the Workstation Installation
The day has come for you to install the workstations. Because you want to install 35 workstations in a single day, you need a custom installation process that makes everything as simple as possible by automating as much of the process as you can. This installation method is sometimes called the "cookie cutter" approach.
Creating Your Cookie Cutter. Your cookie cutter can take many different forms. It could be a documented procedure, or some configuration set up using a third party add-on to NetWare, such as Preferred Systems Inc, ORIGEN product. However, due to your client's tight budget and deployment schedule, and because of the specialized nature of this configuration, you will have to build your cookie cutter from scratch.
With these constraints in mind, you settle on four main design goals:
Make it as fast as possible.
Make it as smart as possible.
Don't ask any questions twice.
Remove the human being from the process as early as possible.
Analyzing the Configuration. You begin by analyzing which parts of the configuration are standard and which parts are variable. This analysis reveals that fewer than 30 items will vary from server to server. Among the variable items are:
Printer configurations
IPX addresses
Node addresses
SNA parameters
LAN and DISK drivers
Driver slot numbers
You determine that many of these items can be formulated from the branch number and the server "alpha" (A - F; these extensions to the branch number are used in branches that have more than one server).
Optimizing Installation Order. To minimize installation times and maximize results, you analyze dependencies to try to determine the optimum order in which installation procedures should be done. Your finished installation outline looks like this:
Physically prep the target machine (FDISK and FORMAT).
Gather data from the user.
Confirm that data.
Prepare the DOS partition to be a NetWare server by attaching to an install server.
Map sequential drive letters pointing to products that must be installed from the server.
Start NetWare and the INSTALL.NLM.
Provide manual instructions to:
Create partitions and volumes.
Install SYSTEM AND PUBLIC from drive J.
Install each product on drives K through R.
Down the server.
Restart the server and install the DOSBOX NLM.
Start the configurator (C:ONFIGURE.NCF).
Copy the SYSROOT image over the SYS: of the server.
Create the GROUPs (groups must come first; users will need them).
Create the USERs.
Configure the PRINTERS/QUEUES (these must come before HOSTPRINT)
Configure the Host products.
Configure software distribution.
Finish the server (create the system login script, the AUTOEXEC.NCF file, and so on).
Automating Your Cookie Cutter
There are several special tools and techniques that are commonly used to automate the cookie cutter process.
The Scratch Variable. You will often see a scratch variable containing repeated asterisks or other invalid display, generated by DOS when it spawns a child process.
MSDOS normally makes a copy of the DOS environment which is only as long as the amount of the parent environment that is in use. In other words, even if you declare in CONFIG.SYS that you want a 1024 byte environment, and you have 768 bytes of variables, if you spawn a secondary command processor (as MENU systems usually do), DOS will create a new environment that it 768 bytes long. This leaves you no room to work, and is the cause of "Out of Environment Space" messages. By declaring a scratch variable and then removing it, you can reclaim some work space.
When you work with secondary command processors, variable changes you make will not be made to the parent or master environment tables. This means that, if you use a DOS SET command within a menu file the variable will not be set when you exit the menu. Instead, you can write the values out to a batch file that you can call in later.
This technique enables you to take data asked at the beginning of a procedure and use it much later on, even after a reboot. If you obtain all your data early, it frees the operator to be busy elsewhere.
You construct your CONFIGURATOR from a series of batch files, some of which have subroutines. The master batch file will call other batch files that perform high level functions. Your convigurator operates after all the required files have been sent to the server. It sets up the groups, users, printer definitions and print queues, SNA session information, and so on.
To make the large configurator procedure more manageable, you break it down into units; one unit creates the NetWare groups, one unit configures ManageWise/Distribute, and so forth. This approach enables you to easily develop, debug, and unit test before integrating all of the units into a whole. In addition, you can divide up the units among your team members.
Finally, you have an automated procedureyour "cookie cutter" that will build your first release of the Server.
How the "Cookie Cutter" Works Your workstation installation cookie cutter was built using common utilities, such as PKZIP, and the standard NetWare menu system. The utilities and menu system have been placed on a bootable floppy disk. This offers the installer choices when the time comes to FDISK and FORMAT the DOS drive, to install the software, and to select options, such as whether the workstation will host a remote network printer.
The installation will query the user for:
The LAN card type
The branch number
The default server letter (A - F)
The last two digits of the node number
The installation will assemble the gathered data into forms such as preferred servers and node addresses, then will construct the configuration files with all of the correct information.
A characteristic of your bank installation is that there are many different combinations and "flavors" of equipment, necessitating many different drivers. You have decided to implement a batch file to help manage the installation of the many different pieces and combinations of equipment.
Your batch file maintains a data file on the workstation. This data file contains a set statement for a variable. The variable uses a series of three-letter strings, separated by spaces, to describe the options that are to be installed for the workstation. The variable is parsed, and a new CONFIG.SYS is created to address the configuration. This means that you can use your variable to add a new driver to CONFIG.SYS.
The following example segment could be used to add a magnetic stripe reader driver to the configuration and remove a PIN pad from it:
CALL OPTION READ CALL OPTION ADD MSR CALL OPTION DEL PIN CALL OPTION SAVE CALL OPTION MAKE
An example of a complete OPTION.BATfile is shown below:
@echo off rem ********************************************************************** REM *** Series: MLWSINST *** REM *** Procedure: OPTION.BAT *** REM *** *** REM *** Author: RobRawson *** REM *** Version: 1.0 *** REM *** DATE: 02/07/96 *** REM *** *** REM *** Purpose: Used to manage user configuration options and *** REM *** make the appropriate CONFIG.SYS file. *** REM *** *** REM *** Dependencies: Sufficient environment space *** REM *** *** REM *** Options: READ - reads the saved options to memory *** REM *** ADD - adds an additional option to the list *** REM *** DEL - removes an option from the list *** REM *** SAVE - saves options from memory to disk *** REM *** MAKE - makes the CONFIG.SYS file from memory *** REM *** *** REM ********************************************************************** REM *** Revision History *** REM *** *** REM *** V1.0: Rob Rawson Initial version *** REM *** *** REM ********************************************************************** If "%1" == "" GOTO USAGE Goto %1 :USAGE Echo OPTION <option< [parm]< Echo Echo <option< = READ, CLEAR, ADD, DEL, SAVE or MAKE< goto DONE :READ Echo WSBURNIN:OPTION Reading Option Data From Disk IF EXIST C:\OPTÂDATA.BAT CALL C:\OPTÂDATA.BAT goto DONE :CLEAR Echo WSBURNIN:OPTION Clearing Option Data From Disk IF EXIST C:\OPTÂDATA.BAT ERASE C:\OPTÂDATA.BAT goto DONE :ADD Echo WSBURNIN:OPTION Adding Option %2 SET ALREADYTHERE=N For %%I in (%OPTION%) do if "%%I" == "%2" SET ALREADYTHERE=Y IF "%ALREADYTHERE%" == "N" SET OPTION=%OPTION% %2 SET ALREADYTHERE= goto DONE :DEL Echo WSBURNIN:OPTION Removing Option %2 SET NEW= REM NEW&=.BAT contains the following single statement: REM if not A%1" == A%2" SET NEW=%1 %NEW% for %%I in (%OPTION%) do CALL NEW& %%I %2 SET OPTION=%NEW% SET NEW= goto DONE :SAVE Echo WSBURNIN:OPTION Saving Data to Disk Echo SET OPTION=%OPTION% >C:\OPTÂDATA.BAT goto DONE :MAKE Echo WSBURNIN:OPTION Creating CONFIG.SYS file COPY C:\CONFIG.STD C:\CONFIG.SYS>NUL For %%I in (%OPTION%) do Type C:\CONFIG.%%I>>C:\CONFIG.SYS goto DONE :DONE
The Installation
Naturally, there are a few small, unanticipated problems during the first installation. Some are caused by misunderstandings, others by software or equipment incompatibilities. Fortunately, your installation team is experienced with the complex requirements of OS/2 LAN Server and FBSS client installations, and they are able to pinpoint the problems and solve them. In addition, they are able to make several valuable suggestions about improvements to the program features and installation procedures that will help you avoid such problems in the future.
Despite the few small problems, your installation goes more quickly than typical IBM OS/2 LAN Server installations.
After a few weeks of stable operation, your initial pilot is declared a success. You can now plan your second pilot and your productization roll out.
The Productization Phase
To work toward your second pilot, you want to go through a complete process with the whole product configuration; similar to what you would do to take a product to market. You begin by applying an informal version control to the process.
To help manage your progress, you begin to track a total system version number. Although you don't think it is necessary to apply version control to the individual files in the system, you maintain version and revision information in the remark headers. Your version controls apply to the entire configuration, and you treat each branch configuration like an individual product. You are still using the tightly controlled "cookie cutter" approach to automated server installation.
The automated installation routine consists of a series of menu files, batch files, ManageWise/Distribute keyboard script files and a small number of add-on batch file utilities. Together, these guide the user through the process of installing a branch server. The routine answers all the questions that always have the same answer, and calculates most of the parameters from a very small number of questions at the beginning.
Relying on your cookie cutter automated installation program enables you to know immediately what versions of which files have been installed in any particular branch location.
You finish your pilots, make any changes to your automated cookie cutter, and you are ready to begin production.
The Production Phase
Despite all your best efforts, and the long hours of planning and testing, there are still a few things that go wrong during the early stages of production. The first, and most important, thing that you can do is to log the problems carefully. In this way, you can begin to get an idea of whether a certain problem night be random, meaning that it might be related to hardware or transient power problems. If the same problem occurs repeatedly, and if you can reproduce the problem on your test equipment, it probably indicates a correctable problem, and should be addressed.
If you are unable to solve a problem yourself, you consult your Novell technical support staff, or, in the case of a hardware problem, the vendor' tech support personnel. Sometimes you find that you have "rediscovered" a known problem, and a workaround exists. Other times a simple code change can solve the problem.
Depending on the severity of the problems you find, and the specific fix involved, you might have to revise your cookie cutter. Again, depending on the severity of any problems you discover during production, you might need to consider suspending your production run while you implement your fixes and perform additional testing.
If you discover that there are problems in Novell products, you should carefully document the problem, your attempted fixes, and your testing results. Forward this information to Novell so that it can be used for product improvement.
Post-Production Considerations
After any large installation, the system continues to evolve. New versions of software and hardware become available, your client might want to add functionality or upgrade. Problems can develop as users are added and capacity is strained. High turnover might lead to an erosion in the number of trained users, causing additional problems. You might find that real users, working in a real world situation, think of ways to "exercise" your system in ways you never imagined or allowed for.
You will want to be aware of these, and similar issues that might arise, so that you can make the best recommendations possible, should your client request them. Changes should not be implemented just for the sake of change; there must always be some benefit to your client's business. Users and management alike are often intimidated by changes, and wary of any that they don't understand, or don't see a business benefit in. By patient and knowledgeable explanation of new possibilities, and the ways in which they will benefit your client, you can make potentially difficult transition stages easier for them.
Conclusions
When you embark on a project such as this, remember these points:
Understand your customer's goals and fears. Frank discussion will help foster mutual understanding and respect.
Establish your own goals.
Realize that there is a middle ground between rigidity and flexibility; you can make Amid-course corrections" without sacrificing quality.
Make sure you have a win-win situation before you proceed.
Establish and maintain contacts with representatives of all the vendors. Let them know when you have problems; they will be happy to help.
If there is an existing system you are replacing, learn as much about it as you can. Understand what the customer and their users like and dislike. It is especially important to understand what the business justification for the change is to make sure your solution fits the model.
When you propose a product mix and configuration, be prepared to explain to your client the reasons for your suggestions, and the ways in which your plan will support their business goals. Remember that there are frequently tangible business benefits that the technology can offer above and beyond the original intentions. Make these benefits known too.
Understand the people who will be involved with the system, and assess their skill levels and training requirements.
Make sure that there are people assigned (or at least planned for) who can deal with each aspect of the system that must be managed.
If the technology is advanced or newly available, you will need to do a proof of concept. Plan to break various technologies into related groups and test them individually. This will allow you to demonstrate the viability of your proposal most quickly.
Develop a prototype, and use it to test the system. Develop tests that as closely as possible emulate the day to day operation of the system.
Perform stress tests to discover problems before rolling the system out to the field.
Be frank with your customer about the significance and ramifications of any problems you discover.
Formulate a plan to quickly deploy the new system. This might be as simple as a document, might employ a commercial product, or might be a new invention. No matter what the solution, if you are going to deploy many similar custom integrated systems, developing a consistent installation procedure will inevitably save time and trouble by ensuring that design decisions are always enforced.
Plan to use some type of version control on the implementation as a whole. Such a system makes it easier to resolve problems, deploy enhancements, and manage user expectations. Consider displaying a version number when users log in. Knowing the version number makes it easier for you to help them if they get unexpected behavior from the system, and simplifies tracking and resolving problems.
Ask your customers about their future plans. You can expect those plans to change, but it still will help you identify where you should allocate resources in anticipation of future requirements.
Deploy no system without a contingency plan. Never make a change without providing a way to quickly back out of it. If you can, try to operate the new and existing systems in parallel for a while. If this isn't possible, make sure you can quickly return to the old system if it becomes necessary.
The importance of good communications cannot be overstressed. Communicate with the customer, with your customer's customer, with your management, and every involved team member. Remember, in a large- scale project, a small problem can be magnified by the sheer scale of the implementation. Good communications, on the part of everyone involved, helps manage the perception of the severity and the scope of those problems.
Finally, expect change. If you anticipate change at the design phase, it will be easier for you to make the systems you implement sufficiently flexible to accommodate whatever modifications might be required by client management changes.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.