Implementing PC SystemView (NetFinity) in Real-World Environments

By Christopher Gaskins and Patricia Davis

''For those of you familiar with NetFinity, PC SystemView is its new name. Announced in 1993, NetFinity has always been a member of the SystemView family, but to make this positioning more intuitive, its name was changed to PC SystemView 4.0. Like previous versions of NetFinity, PC SystemView is compatible with earlier releases.''

''This article discusses factors to consider when implementing PC SystemView in large-and small-scale environments. It also briefly discusses SystemView's architecture, features, and new functions, plus lists additional resources for PC SystemView and other SystemView products.''

NetFinity was designed to provide efficient hardware management in a simple, easy-to-use product. With its immense success, NetFinity provided some additional systems management features, and it evolved into a focal point of the IBM systems management strategy.

NetFinity encompasses extensive hardware management, as well as some enterprise-level systems management, and provides easy, instant systems management capability in IBM PCs, whether server, desktop, or laptop systems. (NetFinity is shipped at no charge with all IBM PC Servers and with some desktop and laptop models.)

PC SystemView
PC SystemView 4.0 is the core of the Intel-based SystemView product set, which provides a manager plus clients on Windows, Windows 95, OS/2, OS/2 Warp, NetWare, and now Windows NT. PC SystemView's breadth of platform coverage is a key advantage in mixed environments.

Advanced management features are available in SystemView for OS/2 and SystemView for AIX if you require additional function. This scalability lets you easily grow in systems management sophistication as your business grows. For instance, SystemView for OS/2 provides software distribution and full remote console takeover, in addition to the NetFinity 3.0 base product. And SystemView for OS/2 will continue to grow in advanced function to provide additional management features from the OS/2 managing station. SystemView for OS/2 comes with OS/2 Warp Server, but can also be bought separately. (See the accompanying article, "SystemView for OS/2," in this issue of Personal Systems.)

PC SystemView 4.0 encompasses the best of some essential systems management capabilities, including process management, file transfer, remote session, screen view, RAID management, remote systems management, comprehensive hardware and software inventory of all systems, Desktop Management Interface (DMI) browser, system monitors, alert management, and much more.

Product Overview
A key advantage of the PC SystemView product is its modular design, which enables easy customization for varied environments, while simultaneously affording easy installation in less than five minutes.

Figure 1 illustrates PC SystemView's three major components: the base function, which resides on each system and executes the actual commands; the transport layer, which relays the information between the base and the graphical user interface (GUI) through several protocols such as IPX, NetBIOS, TCP/IP, and phone line (serial) connection; and the GUI, which presents the information on the screen.



'''Figure 1. PC SystemView Local Architecture'''

Figure 2 illustrates how PC SystemView works remotely when a manager makes a client station call. The transport layer permits communication through multiple protocols, so that a PC SystemView manager can control multiple network nodes running different protocols. This control is accomplished either by installing (on the managing station) the multiple protocols used in the network or by using PC SystemView's peer-to-peer, pass-through management feature. Thus, a manager at station A can control station B simply by selecting it, just as though he or she resides at station B and uses the protocol at that station.



'''Figure 2. PC SystemView Remote Architecture'''

It is important to understand that PC SystemView is not server-centric and does not require any server hardware to run PC SystemView manager or services in a LAN environment. The PC SystemView services are what most people might generically call a client; however, we call them services because they provide actual end-user value, not just to a manager but to any PC user.

Figure 3 illustrates PC SystemView's pass-through management function and peer-to-peer access. A PC SystemView manager installed on a traveling ThinkPad can dial into a LAN through PC SystemView serial support and gain full control of another manager.



'''Figure 3. PC SystemView Pass-Through Management'''

PC SystemView Architecture
In general, each PC SystemView service or function has a base and a separate GUI file. This design lets you customize your installation so that a service can be disabled by removing or renaming its base file. Its GUI can also be removed.

This design also enables you to install client stations without a GUI front-end. This option, termed passive services, is intended for a manager who wants full control of the client stations with no intervention from the end user. It also requires less disk space - now 10 MB. And, like NetFinity, PC SystemView still requires only about 340 KB of memory, all above the 1 MB extended memory boundary, to run in idle mode.

Conversely, installing the GUI services on the client lets you take advantage of all the PC SystemView services features, such as workstation monitoring, hardware and software inventory, security, and alert actions, whether or not that station is connected to a LAN.

To aid in our discussion of how the manager and client communicate, we now briefly describe how PC SystemView discovers all PC SystemView managers and services in a network across the IPX, NetBIOS, and TCP/IP protocols. During the discovery, PC SystemView also discovers any SystemView for OS/2 managers and clients and, of course, any NetFinity stations using that particular protocol.

In the IPX protocol, the PC SystemView manager issues a GetAllNetworks request. All addresses and internal network IDs are returned. The manager sends a broadcast to each specific IPC socket on each server and network segment. For example, with 10 servers and five segments, 15 broadcasts are sent.

The NETFBASE, or base code, running on each client examines the discovery keyword conditions. If a match occurs, the system responds with its system name, type, and network address. Further exchanges between the manager and client at this point are performed directly.

Note: For communication between client and manager to take place, NETFBASE code must be running on the station to be managed by PC SystemView. This is the first area to check when troubleshooting. If discovery or communication between client and manager is not occurring, verify whether NETFBASE is running in the task list. (After PC SystemView is installed, NETFBASE should start automatically every time the system is started.)

PC SystemView uses two unique NetBIOS names during discovery: the network address name and the PC SystemView group name (which is non-textual). The PC SystemView manager broadcasts the datagram to the unique NetBIOS name. (NetBIOS cannot resolve the MAC layer, so it effectively issues a single-route broadcast.) The NETFBASE on the client examines the discovery keyword conditions, and if there is a match, the client responds with its system name, network address, and system type. After this, information exchange between client and manager is performed directly.

When using TCP/IP, the PC SystemView manager uses a local IP broadcast address, which must be enabled, to issue a broadcast to a TCP/IP socket. The IP broadcast is derived from the IP address and the subnet mask. For example, if the IP address is 9.80.128.1 and the subnet mask is 255.255.0.0, the local broadcast address becomes 9.80.255.255.

To discover other subnets in TCP/IP, simply create a text file named TCPADDR.DSC in the \NETFIN directory and enter the IP address and subnet mask. The NETFBASE on the client examines the discovery keyword conditions and responds (if there is a match) with the system name, type, and IP address. Further communication between manager and client is performed directly via the address routing protocol (ARP).

PC SystemView On the World-Wide Web
PC SystemView 4.0 has a new Web-ability feature in the PC SystemView manager. This feature is offered as an option during installation; if selected, an additional hypertext markup language (HTML) front-end is installed on the managing station. This front-end lets you access a PC SystemView manager through Web browsers (such as NetScape 1.12 or 2.0 and OS/2 WebExplorer) that support HTML version 2 and tables.

For instance, an AIX, Macintosh, or other system installed with a supported Web browser can fully access PC SystemView's systems management features from a TCP/IP network. This access assumes that you have proper security access and are within your company's firewall. Additionally, the services accessible to that manager are the "public" services, set by the security manager at that station, which require no password entry into that system. You need a password to access services not open to "public" access.

In a typical scenario, you might suddenly be contacted about a critical situation at a remote location--perhaps the PC SystemView alert manager beeped your pager with a severity 1 alert. You need a PC, Macintosh, or AIX system with a Web browser to access that machine - probably by first dialing into your company's intranet, then typing the URL for the PC SystemView manager installed with the Web-ability code. Pass-through management allows you to remotely access the systems as needed to fix the situation. Remote systems management doesn't get much easier!

Note: Remote-session service is not available in the current version of OS/2 WebExplorer 1.03, but is enabled on any browser with Java support, such as NetScape. Security on the Web is an important issue. PC SystemView 4.0 uses NetFinity's security to encrypt passwords and user IDs. In future releases, PC SystemView will use secure socket layer to provide full encryption on the network.

Planning for PC SystemView Installation
PC SystemView comprises two separate pieces: manager and services. Usually, there are more services (clients) than managers.

Installing either services or managers on a small number of systems is easy and straightforward, especially when done from a CD-ROM drive (either a local CD-ROM drive or a shared CD-ROM drive on the LAN). A directory of the PC SystemView CD (see Figure 4) shows a subdirectory for each operating environment that PC SystemView supports (\OS2, \NETWARE, and \WINDOWS). On the \OS2 and \WINDOWS subdirectories are further subdirectories indicating services or manager code. '''Figure 4. PC SystemView CD Root Directory'''

To install PC SystemView Manager for OS/2, simply execute the installation program in the \OS2\MANAGER subdirectory. Similarly, you can install the other components by executing the installation programs in their respective subdirectories.

If you install PC SystemView on a small number of systems (less than 25), then little planning is required. Install the product and customize each system's monitoring, thresholds, alerting, and security features. If you perform normal installations, then you must individually customize each machine; however, in a small environment, this is usually not a problem.

At the other end of the spectrum is implementing PC SystemView for a large environment, which could mean installing and administering PC SystemView for hundreds, thousands, or even tens of thousands of systems. Modifying each system is overwhelming and certainly not feasible. Consequently, to use PC SystemView in the enterprise environment, a considerable amount of planning must occur to make the installation simple as possible.

PC SystemView is designed to help with: Among the first installation planning considerations is to determine the proper ratio of PC SystemView managers to PC SystemView services. The ratio depends upon how you will use PC SystemView. Following are rough guidelines to determine this ratio. (Remember that each installation is unique, and many factors apply in determining the correct ratio.)
 * Help desk support
 * System resource monitoring and alerting
 * Hardware and software asset management

When using PC SystemView as a help desk support tool, determining the ratio of managers to services is simple--it boils down to how many help desk personnel will need to use the manager console. For example, if three employees in the help desk organization serve 500 end-user workstations, then the ratio of managers to services will probably be very low.

The process grows more complicated when PC SystemView is implemented for monitoring and alerting. In fact, it is probably the most difficult implementation to size properly. Why? Because PC SystemView's alert manager is so flexible that an infinite number of situations can be created where alerts are being generated. Let's look at two scenarios.

Scenario 1: You are using PC SystemView to monitor the resources of 50 OS/2 application and file servers. On these servers, the following resources will have thresholds configured to generate severity 1 alerts: How many PC SystemView managers should be installed in this situation? You should install at least two, primarily so that two system administrators can be notified of the problem. Each server being monitored should be configured so that all severity 1 alerts are forwarded to the two PC SystemView managers. In this case, with a relatively low number of systems being monitored, one or two PC SystemView managers will suffice.
 * When CPU utilization is 100 percent for five minutes
 * When memory utilization is 50 MB for five minutes
 * When free disk space drops below 10 MB
 * When any RAID drive drops into a critical state
 * When the UPS incoming voltage drops below 110 vac

However, what happens in an environment where PC SystemView is going to be installed on 10,000 workstations?

Scenario 2: You are using PC SystemView to monitor 10,000 workstations, with the following thresholds configured to generate alerts: There is no way that one or two PC SystemView managers can effectively handle alerts generated from 10,000 workstations. Here, an implementation of hierarchical PC SystemView managers is beneficial. Local PC SystemView managers that "catch" alerts from about 200 to 250 systems each can, in turn, forward the most critical alerts to another PC SystemView manager or convert the alert to a simple network management protocol (SNMP) trap that can be sent to an enterprise management console such as SystemView for AIX. Creating this hierarchy of PC SystemView managers ensures that no alerts escape because the system is too busy to "catch" them. The number of systems that a regional or mid-level manager is responsible for can vary; it depends upon the amount of alert traffic generated by each client and your particular policies.
 * When free disk space drops below 10 MB
 * When the CONFIG.SYS and AUTOEXEC.BAT files are changed
 * When CPU utilization is 100 percent for 10 minutes

Before you use PC SystemView to provide hardware and software asset management for all PCs on the LAN, you must answer a few questions: Once again, the answers to these questions greatly change the manager-to-client ratio. Let's look at two more scenarios.
 * How often will the hardware/software inventory be collected?
 * During which hours of the day or night is the inventory collected?
 * How many systems will be inventoried?

Scenario 3: You are asked to inventory 150 clients once a week, between 11:30 a.m. and 1:00 p.m. on Thursdays, then export the data to a Lotus Notes database.

Since PC SystemView collects data from each system consecutively, you must know the amount of time it takes to perform a full software and hardware inventory. To determine this, allow about two minutes per system to collect hardware and software data. This conservative number may be tuned for specific environments, but is a good starting point for planning purposes.

With 150 clients to inventory, multiplied by two minutes per client, you need 300 minutes. However, the timeframe for collecting this data is tight--only a 90-minute window from 11:30 a.m. until 1:00 p.m. on Thursdays. So, to determine the required number of managers, divide the total minutes required (300) by the actual number of minutes available (90), which yields 3.3. Round up this number to find the answer, which is four managers.

We know now that four managers will be required for 150 clients; therefore, each manager will be responsible for about 38 clients. When the hardware and software inventory is collected, each manager will gather data from its 38 clients during the 90-minute window. (This scenario will work, because at two minutes per system, the inventory requires 76 minutes.) Each manager can insert the data directly into a Lotus Notes database on a centralized server.

Scenario 3 was straightforward, with few variables. Now, let's look at a more complex scenario for a much larger environment.

Scenario 4: Here you inventory 15,000 clients at least once a month, anytime between 10:00 a.m. and 4:00 p.m., Monday through Friday, and export the data to a DB2 database. The inventory does not have to be gathered from all clients on the same day.

While this example is more flexible, it adds more variables to the equation. There are 15,000 systems to be inventoried, so it will take 30,000 total minutes to collect the data (15,000 clients multiplied by two minutes per client).

Now you must calculate your window for collecting the inventories. The time period for collecting them is one month. The collections can be done during 360 minutes per day; there are (conservatively) 20 days per month. Therefore, 360 minutes per day multiplied by 20 days per month yields 7,200 available minutes per month for inventory collection.

Finally, to determine the required total number of managers, divide the total number of minutes (30,000) by the available minutes (7,200); this yields 4.1 managers, which you round up to five.

When implemented, five managers will query and collect data from 150 clients each day. Therefore, the total number of systems inventoried per day is 750. Earlier, we used 20 working days in a month, so 750 clients per day multiplied by 20 days per month equals 15,000 clients inventoried per month.

When configuring the five managers to collect the inventory, each manager will have 20 groups of 150 clients (that is, 150 different clients on each of 20 days). Each manager will collect data from a different group each day and insert it into a centralized DB2 database.

If the organization grows and more clients are added, simply add another manager to handle another 20 groups containing 150 clients each.

Installing PC SystemView on Large Numbers of Systems
As mentioned earlier, PC SystemView is a true peer-to-peer-based product. This structure offers many advantages, such as flexibility, network operating system independence, and the ability to work in small, medium, and large environments.

In large environments, however, you can roll out and customize PC SystemView more easily by cloning a single system's customization. Why is this preferable? Since PC SystemView services monitor themselves and only communicate with a PC SystemView manager when being managed or when forwarding alerts, each client must be properly configured for such things as thresholds on system resource monitors, critical file monitoring, security access, and alert actions.

If the normal PC SystemView installation is completed on 500 clients, and then customizations are made, the same actions would have to be taken manually for each of the 500 clients. It is much easier to install PC SystemView on one system most typical of your environment, customize it, then roll out these changes to all systems while installing PC SystemView.

Before rolling out PC SystemView, you may want to consider customizing these items: Once you have decided about these items, install PC SystemView on a client that is typical of the majority of all of the target clients. After the installation is complete, make customizations to the above items, which might include: All of the changes made are held in PC SystemView's .INI files. Figure 5 lists the PC SystemView .INI files and their descriptions. '''Figure 5. PC SystemView .INI Files'''
 * Security access
 * Thresholds for the system monitors (memory, CPU, disk)
 * Critical files to be monitored
 * Alert actions for alert notification
 * System keywords for logical groupings
 * Creating IDs and passwords for security
 * Selecting which critical files will be monitored for changes
 * Creating thresholds on all applicable system monitors
 * Creating alert actions in the alert manager for forwarding alerts to PC SystemView manager systems
 * Configuring the transport protocol to be used, as well as which keywords are installed for logical groupings

After you complete the customizations, you must complete a few more steps. First, copy the contents of the appropriate PC SystemView Installation CD subdirectory onto a shared directory on a file server running LAN Server, NetWare, or Windows NT. If you are going to roll out multiple different agents, place each agent into a separate shared directory on the file server. Next, copy all of the .INI files from the customized client into the directories where you copied the PC SystemView files. The .INI files are common across all platforms that PC SystemView supports. Therefore, the .INI files customized on an OS/2 system will work on a Windows, Windows 95, Windows NT, or NetWare system.

As part of the basic installation, the SECIN.INI, SECOUT.INI, and ALACTION.INI files will be copied automatically to the target system during installation. For all other .INI files that are to be copied during installation, changes must be made to the INSTALL.INI file in the appropriate sections and their corresponding .INI files: Each relevant section in the INSTALL.INI file has the structure shown in Figure 6.
 * System Monitor Base section, for MONTHR.INI
 * NetFinity Client Base section, for NETDRVR.INI
 * Process Manager Base section, for PROCMAN.INI
 * Critical File Monitor GUI section, for MONCRITF.INI



'''Figure 6. A Section of the INSTALL.INI File'''

An example of the default System Monitor Base section in the INSTALL.INI file is shown in Figure 7 below.



'''Figure 7. Default System Monitor Base Section'''

To ensure that the MONTHR.INI file is copied to the target system, Figure 8 below lists the changes you should make to the section in the INSTALL.INI file shown in Figure 6.



'''Figure 8. Changes to INSTALL.INI for MONTHR.INI'''

You must similarly edit the other affected sections. Once you have edited one or two sections, the process becomes easy to understand. (Refer to either the PC SystemView User's Guide or NetFinity User's Guide for more details.)

Now the rollout can begin. On each workstation that is going to install the client, issue a NET USE command (when accessing a LAN Server machine) or MAP a drive letter (when accessing a NetWare machine) to the file server, and install from the shared directory.

If you require an automated approach, PC SystemView is CID-compliant, so you can invoke CID response files to make the installation much easier. Again, please refer to either the PC SystemView User's Guide or the NetFinity User's Guide for CID installation assistance.

How can managing so many workstations be integrated with AIX, UNIX, or MVS enterprise management consoles? As mentioned earlier, by using a Web browser, you can now fully manage any PC SystemView- or NetFinity-enabled client from any platform that supports a Web browser. Furthermore, PC SystemView/NetFinity can create SNMP traps that can be forwarded to the enterprise management console.

PC SystemView Partners in Management
The PC SystemView Partners in Management program (formerly the NetFinity Partners in Management program) allows key non-IBM hardware and software vendors to integrate and extend the PC SystemView product via the PC SystemView Software Developers Toolkit. Using this toolkit, partners write extensions or snap-in modules that extend or add function to PC SystemView.

This program is available only to companies that meet the requirements and have the synergy to significantly increase the value of PC SystemView.

Current members of the Partners in Management program are:
 * American Power Conversion (APC)--. APC has developed snap-in extensions to PC SystemView that let you actively monitor an APC uninterruptible power supply (UPS). When installed, six new system monitors appear, providing detailed information about the attached APC UPS. These extensions are shipped with every IBM PC Server on the ServerGuide CD-ROM set.
 * APCON--. APCON resells PC SystemView/NetFinity with their external small computer system interface (SCSI) switch box, called PowerSwitch. PowerSwitch allows two PC Servers to be cabled to one external direct access storage device (DASD) tower. PC SystemView/NetFinity performs the automatic switch in case of a server failure.
 * BMC Software (formerly HawkNet, Inc.)--[]. BMC has integrated their NetTune Pro product, which snaps in 40 NetWare server monitors. These new monitor extensions provide detailed data about the NetWare server attributes such as dirty cache buffers and LAN adapter traffic.
 * Diagsoft, Inc.--. Diagsoft is one of the world's largest suppliers of PC-based diagnostics. Diagsoft plans to develop a snap-in diagnostic module that integrates with PC SystemView to allow system and LAN administrators to run diagnostics from within PC SystemView.
 * Lexmark International--. Lexmark has created a new snap-in service that allows PC SystemView to collect alerts that are generated from Lexmark LAN-attached printers. These alerts can range from paper jams to out-of-toner. These extensions will soon be shipped with Lexmark's MarkVision for OS/2.
 * Motorola--. Motorola is currently integrating PC SystemView with their client/server-based paging software, AirApparent. This integration will allow PC SystemView to use AirApparent as a numeric and alphanumeric paging device in more sophisticated environments.
 * Vinca Corp.--. Vinca is currently reselling PC SystemView/NetFinity with every Standby Server 32 for OS/2. Standby Server 32 is an OS/2 mirrored server product that takes advantage of PC SystemView's monitoring and alerting capabilities.

The partners listed above are the current members of the PC SystemView Partners in Management program. Other partners are currently being pursued to add functionality to PC SystemView. For more information about the PC SystemView Partners in Management program, contact Chris Gaskins at [cgaskins@vnet.ibm.com] or Denise Collins at [dcollins@vnet.ibm.com].

More information about IBM SystemView and NetFinity can be found on the following World-Wide Web sites:
 * http://www.pcco.ibm.com
 * http://www.software.ibm.com