Skip to main content

Test 000-565: IBM Tivoli Network Manager IP Edition V3.9 Implementation

Tab navigation

Section 1: Planning

  1. Given access to the customer technical staff and network information, determine the Network Manager requirements so that Network Manager requirements are documented and allow configuration to be carried out.
    With emphasis on performing the following tasks:
    1. Evaluate current Netcool components installed.
    2. Perform a gap analysis against default functionality of the product.
    3. Determine installation user (root, non-root).
    4. Determine FIPS compliance.
    5. Gather SNMP community strings, including versions and applicable subnets, Telnet passwords and DNS server details. Determine if there are any access control lists or restricted SNMP views.
    6. Gather the Enterprise Management Server (EMS) information for non-SNMP devices or network.
    7. Gather network address space(s) for static NAT gateways.
    8. Determine the overall size of the network (ports, agents, etc).
    9. Gather network equipment list. (Indicate layer 2, 3 devices with name, management IP address, OID).
    10. Determine any non-contiguous or unmanaged networks.
    11. Determine network technology (e.g., multicast routing protocols, etc.).
    12. Gather detailed requirements for polling.
    13. Gather detailed requirements for data collection.
    14. Determine advanced discovery options.
    15. Determine logical groupings for service affecting events.
    16. Determine how to seed the discovery with customer.
    17. Determine full and partial discovery behavior.
    18. Determine network devices for which detection must be restricted.
    19. Determine any devices that must be removed from a completed discovery.
    20. Determine the mgmt IP addresses of the IBM Tivoli Network Manager IP Edition V3.9 (ITNM) server switch and default router.
    21. Determine discovery scheduling.
    22. Set customer expectations regarding a timeline for completion.
  2. Given the identified ITNM requirements, determine the ITNM architecture so that a detailed deployment plan is created.
    With emphasis on performing the following tasks:
    1. Identify any restrictions imposed by firewall policies which prevent communication between ITNM and network devices.
    2. Determine if multiple ITNM installations are required due to overlapping non-NATs address spaces.
    3. Determine if a simple or distributed installation is required.
    4. Determine the NCIM database type and location.
    5. Determine the growth of network in percentage.
    6. Identify the type of network (Multiprotocol Label Switching, WAN, MAN, or LAN).
    7. Determine if the network is divided into geographical locations.
    8. Get the disaster recovery location from the customer for failover.
    9. Document the plan.
  3. Given the network size (ports/interfaces) and architecture, determine the hardware and server specifications so that hardware and server are designed for a successful ITNM deployment.
    With emphasis on performing the following tasks:
    1. Review the detailed architecture plan.
    2. Determine operating system version.
    3. Estimate minimum hardware requirements.
    4. Calculate disk usage and verify that server(s) meets memory and CPU requirements.
    5. Ensure other prerequisites are met.
  4. Given a requirement for NCIM failover, determine the configuration options required so that primary and backup ITNM servers use independent databases..
    With emphasis on performing the following tasks:
    1. Determine database version and license.
    2. Review the High/Low Level Architecture diagram.
    3. Determine the geographical dependencies for allocating servers, if any.
  5. Given installed ITNM, enable the Collector Framework so that all devices which are imported by the Collector Framework are available in the topology after finishing the successful discovery.
    With emphasis on performing the following tasks:
    1. Configure the Collector.
    2. Start the Collector.
    3. Seed the Collector Finder.
    4. Enable the Collector agents.
  6. Given access to ITNM and requirements from the customer, determine data collection strategy and data polling definitions so that ITNM configuration details are determined.
    With emphasis on performing the following tasks:
    1. Identify gap between the out-of-the box polls and the customer requirements.
    2. Identify which poll definitions are required to be created including details of the threshold and clear values, event description, and associated variables.
    3. For each poll definition, determine the associated poll policy, including frequency, scope, filtering, and any required interface filtering.
    4. Determine adaptive polling requirements.
    5. Determine if the policy will be for fault only, historical data collection or for both.
    6. Using information gathered about the network devices and logical topology, determine if additional pollers will be required.
    7. If additional pollers are required, add these to the architecture or design.
    8. Determine the database location for historical data collection.
    9. Determine the average daily record numbers for historical data collection, and plan to configure the poll schema and database accordingly.

Section 2: Installation

  1. Given an installation environment, server, and user access method, determines if the IBM Tivoli Network Manager IP Edition V3.9 (ITNM) installation prerequisites will affect the installation method so that a method for installation has been determined.
    With emphasis on performing the following tasks:
    1. Determine the type of installation that can be used (Launchpad, interactive console installation or silent installation method).
    2. Ensure that the installation user PATH contains the required OS tools.
    3. Ensure that any installation restrictions are understood and factored into the installation choice; for example, the Windows Administrator user may not allow GUI access forcing a silent installation, etc.
    4. If installing into a Solaris Zone, understand if it is a full or sparse zone and the implications has for the installation method used.
    5. For Windows installation, ensure that a supported version of the Windows Installer is installed and useable by the installation user. If this is not, or it cannot be installed, the installation method will be required via one of the console/silent options.
    6. Understand the installation directory requirements on both UNIX and Windows platforms and understand this directory choice for future Tivoli product support; e.g., IBM Tivoli Business Service Manager (TBSM) support.
    7. Understand that the installation options are different if using a database that is not provided in the default installation package.
  2. Given a set of customer requirements and a suitable ITNM architecture, establish which installation option to choose during the installation process so that an installation method has been determined.
    With emphasis on performing the following tasks:
    1. For both installations, determine the installation directory ensuring compliance for any other Tivoli integration (e.g., for TBSM the path cannot contain a space " ").
    2. Determine the type of installation to use (Basic or Custom).
    3. Enter a domain name.
    4. Follow the installation options for either the custom or basic installation, and single or multi-server.
    5. Verify that a discovery will run based on the inputs during the installation process at the end of a basic or custom installation.
  3. Given the server operating system, topology database type, and hardware specifications, verify the component prerequisites so that component prerequisites are met.
    With emphasis on performing the following tasks:
    1. Verify the OS version is supported.
    2. Verify that additional OS configuration steps are made.
    3. Verify that topology database is installed if using Oracle, MySQL, DB2, or IDS.
    4. Verify that user has sufficient rights to install.
    5. Verify the minimum bandwidth for the discovery.
  4. Given the architecture design documentation, determine the user access required for installation with directory permissions so that the required user permissions are met for installation.
    With emphasis on performing the following tasks:
    1. Determine with customer whether to install as root or non-root user.
    2. Determine the reason for installing as root. non-root user is always recommended.
    3. Obtain root access on temporary basis to perform certain installation tasks.
  5. Given a server for installation with UNIX or Windows operating system and an account with sufficient rights, create the input files for silent installation so that the product is installed on required operating system.
    With emphasis on performing the following tasks:
    1. Uncompress the installation media into a suitable location by using the appropriate tool for the installation OS.
    2. Ensure the impact of any preinstallation tasks is understood. (e.g., turning off SELinux, enabling ssh etc.).
    3. Ensure the other installable components are in the appropriate location.
    4. Perform the operating system specific preinstallations tasks.
    5. Perform any required database preinstallation tasks.
    6. Create the silent installation file, or modify the supplied default
    7. Run the installation script with the -i silent and -f option by using the created silent installation response file
    8. Perform any required post-installation tasks.
  6. Given access to the command line on the installation system(s) and installation media, start the installation process so that a command line installation is performed.
    With emphasis on performing the following tasks:
    1. Uncompress the installation media into a suitable location by using the appropriate tool for the installation OS.
    2. Ensure the impact of any preinstallation tasks is understood. (e.g., turning off SELinux, enabling ssh etc.).
    3. Ensure the other installable components are in the appropriate location.
    4. Perform the operating system specific preinstallations tasks.
    5. Perform any required database preinstallation tasks.
    6. Run the installation script with the -i console option.
    7. Perform any required post-installation tasks.
  7. Given access to a graphical interface on the installation system(s) and installation media, start the installation process so that a GUI installation is performed.
    With emphasis on performing the following tasks:
    1. Uncompress the installation media into a suitable location by using the appropriate tool for the installation OS.
    2. Ensure the impact of any preinstallation tasks is understood.
    3. Ensure the other installable components are in the appropriate location.
    4. Perform the operating system specific preinstallations tasks.
    5. Perform any required database preinstallation tasks.
    6. Run the launchpad.exe, launchpad.sh or install.sh script.
    7. Perform any required post-installation tasks.
  8. Given a new installation of ITNM, perform the required post-installation tasks so that the system is ready for configuration.
    With emphasis on performing the following tasks:
    1. Configure root or non-root access depending on the installation user.
    2. Configure FIPS for IBM Tivoli Integrated Portal and OMNIbus as required.
    3. Configure inter-server communications.
    4. Configure the WebGUI data source information.
    5. Perform integration with common Tivoli components (TADDM, ITM, TBSM, TDW).
    6. Perform any operating system dependent tasks.

Section 3: Configuration

  1. Given location and version of OMNIbus server, use the SQL file from remote IBM Tivoli Network Manager IP Edition V3.9 (ITNM) server to configure the ALERTS.STATUS table by using nco_sql command so that the OMNIbus database is updated to work with ITNM.
    With emphasis on performing the following tasks:
    1. Determine the version of the object server.
    2. Identify missing fields for ITNM, if any.
    3. Update any missing fields.
    4. Obtain the user credentials of user with sufficient privilege for OMNIbus.
    5. Configure encrypted access.
    6. Review the connectivity from ITNM server to OMNIbus by using telnet.
    7. Run the SQL script by using nco_sql command.
  2. Given an ITNM installation, a virtual ObjectServer pair, appropriate server information, and access to the appropriate configuration files, configure ITNM to communicate with a virtual ObjectServer failover pair so that ITNM is able to correctly connect to an ObjectServer failoverpair.
    With emphasis on performing the following tasks:
    1. Determine the failover pair server and port information.
    2. Create the OMNIbus interfaces file in a supported way to reflect this information.
    3. Modify the WebGUI data source information if required to reflect the failover pair.
    4. Modify the ITNM process configuration files to ensure that the appropriate processes connect to the failover pair as required.
    5. Ensure that the configuration is reflected on both the primary and failover ITNM servers if failover is enabled.
  3. Given an installation of ITNM, domain information, access to the appropriate command line, and configuration GUIs, create a new ITNM domain with the default poll policies in place so that a new domain is created on Windows and UNIX with the default polling policies.
    With emphasis on performing the following tasks:
    1. Determine domain information.
    2. Determine database login information.
    3. Copy the appropriate default configuration files to domain specific versions as required.
    4. Modify the configuration files to reflect domain and database information.
    5. Create the Windows services.
    6. Use the domain_create.pl script to register the domain within NCIM and populate the domain with the default polls.
    7. Modify automated startup scripts to automatically start the domain if required.
    8. Configure the discovery information for the domain as required.
  4. Given the Architecture documentation, configure the remote DB so that it is accessible from various ITNM components.
    With emphasis on performing the following tasks:
    1. Verify which database will be used.
    2. Verify database server is up and running.
    3. Verify Privileged Access to Database to create the NCIM DB.
    4. Create table schema with the script provided with the ITNM.
    5. Verify required port should be accessible from the other Netcool component.
    6. Perform any database library actions necessary.
  5. Given that ITNM is installed, configure IBM Tivoli Integrated Portal (TIP) so that a user is created and defined with sufficient privileges.
    With emphasis on performing the following tasks:
    1. Access TIP and enter the ITNM admin credentials.
    2. From the navigation pane, click Manage Users.
    3. Create a new user defining appropriate parameters.
    4. Assign the user to a group.
    5. Click Group Membership and assigned required group.
    6. Define the role for sufficient privileges.
  6. Given that a user is logged in with the appropriate ITNM administration rights to the TIP, select the Network Discovery Configuration and enter the appropriate information so that a discovery is scoped.
    With emphasis on performing the following tasks:
    1. Log in to TIP.
    2. Click Discovery -> Network Discovery Configuration.
    3. Select Scope tab.
    4. Select Scoped Discovery option.
    5. Specify one or more subnets to use for scoping by clicking New and typing an IP address and a netmask or wild carded IP address.
    6. Determine to include or exclude the subnet.
    7. Determine whether to include the subnet in the ping seed list for IPV4 or IPV6.
    8. Click OK.
    9. Click the Save icon.
  7. Given access to TIP and a user with sufficient privilege, access the ITNM Discovery Configuration panel and enter the appropriate information to seed the discovery with the file finder, ping finder or both so that ITNM has been configured to use the file or ping finder or both.
    With emphasis on performing the following tasks:
    1. Log in to the TIP.
    2. Click Discovery -> Network Discovery Configuration. From the Domain list, select the required domain.
    3. To switch off the Ping finder or File finder, clear the use ping finder in Discovery or use file finder in Discovery check boxes.
    4. Add or edit a ping seed.
    5. Complete the fields and click OK.
    6. Add or edit a file seed.
    7. Complete the fields and click OK.
    8. Click the Save button to save the configuration.
  8. Given a seed file and a discovery configured to use the seed file, configure the discovery process to only discover devices that are available in the seed file so that File finder is configured to the validate entries in the seed file before they are included in the discovery.
    With emphasis on performing the following tasks:
    1. Go to the Advanced tab in the Discovery configuration.
    2. Enable the File finder verification.
    3. Alternatively edit the Disco.DOMAIN.cfg file to enable the appropriate flag in the disco.config section.
    4. Ensure that the Ping finder is configured to run.
    5. Determine what actions, if any, should be taken after the discovery has been changed.
  9. Given access to devices, configure SNMP community string and telnet user name and password so that the devices can be queried.
    With emphasis on performing the following tasks:
    1. Configure for encrypted or unencrypted credentials.
    2. Click Discovery -> Network Discovery Configuration. From the Domain list, select the required domain.
    3. Click Passwords.
    4. To add a new SNMP community string, click New and complete the appropriate fields on the SNMP Password Properties page.
    5. Click Move Up and Move Down to arrange the SNMP community strings into the order of most frequently-expected use, with the most frequently-used strings at the top of the list.
    6. Click Save.
    7. To add Telnet/ssh access information, click New and complete the appropriate fields on the Telnet Password Properties page.
    8. Configure Telnet-privileged access mode properties.
    9. Click OK, Click Save.
  10. Given that ITNM is installed and running, select required discovery agents so that system is configured to run the appropriate agents during discovery.
    With emphasis on performing the following tasks:
    1. Launch and log in to TIP.
    2. Navigate to Discovery -> Network Discovery Configuration
    3. Select the required domain from the list.
    4. Click on either "Full Discovery Agents" tab or "Partial Rediscover Agents" tab.
    5. Select the check box next to the required agent.
    6. Select any other appropriate options.
    7. Click the Save button.
  11. Given the Architecture document and an understanding of the NAT environment, configure discovery so that the NAT environment is discovered correctly.
    With emphasis on performing the following tasks:
    1. In the Discovery Configuration GUI, select the NAT tab.
    2. Define appropriate settings in the NAT tab.
    3. Click the Save button to save your settings.
    4. Activate the correct NAT agents for your discovery,
    5. Map the discovery scope zones to NAT address.
    6. Click the Save button to save your settings.
    7. Verify that NAT addresses are set in the translations.NATAddressSpaceIds table.
  12. Given that ITNM is installed, configure filters so that devices, which are passed to the filter criteria, would be interrogated or instantiated in the topology.
    With emphasis on performing the following tasks:
    1. Go to the Filter tab in ITNM admin configuration page.
    2. Click Filter Library then click Add Filter.
    3. Define filter name and filter criteria and save the changes.
    4. Select defined filter into Available Filter option then click Add Filter.
    5. Save the Changes.
  13. Given that a user is logged in with the appropriate ITNM administration rights to the TIP, select the Network Discovery Configuration and enter the appropriate information, so that advanced options are configured.
    With emphasis on performing the following tasks:
    1. Log in to TIP.
    2. Click Discovery -> Network Discovery Configuration
    3. Select Advanced tab.
    4. Configure the advanced settings.
    5. Click the Save icon.
  14. Given the IP address and port on which the collector is running or listening, enable default collectors so that the default collectors are enabled and configured for discovery.
    With emphasis on performing the following tasks:
    1. Edit the collector configuration file appropriately.
    2. Save the collector configuration file.
    3. Obtain the host name and the port on which the collector is running/listening.
    4. Start a collector by going to the relevant collector directory and issuing a command-line interface command.
    5. Edit the DiscoCollectorFinderSeeds.DOMAIN.cfg configuration file by appending an insert into the collectorFinder.collectorRules table.
    6. In the Discovery Configuration GUI, select the Full Discovery Agents tab.
    7. Select the appropriate agents by checking the box next to the agent.
    8. Verify the configuration settings saved in the DiscoAgents.DOMAIN_NAME.cfg.
  15. Given a list of devices not discovered correctly, configure an active object class so that the device is represented correctly.
    With emphasis on performing the following tasks:
    1. Determine the instantiate filter for the class (usually defined by the SNMP ObjectID).
    2. Create the Active Object Class file in the aoc directory.
    3. Define the active_class which is the name the class will use NOT the file name.
    4. Define the super_class for the class.
    5. Define the instantiate rule for the class.
    6. If the instantiate rule for this class is not a subset of the super_class (or hierarchically upwards), add the instantiate rule to all super_class levels.
    7. Define the basic device type for this class (router, switch, node) which will be the base icon used in the GUI.
    8. Run ncp_class -read_aocs_from aoc -domain XXXXX (where XXXXX is the domain name), and if any errors are reported, these should be rectified.
    9. Stop and restart the ncp_class process. .
    10. Stop and restart the ncp_model process.
    11. If required, modify the topoviz.properties file to reflect any icon changes for the new class.
  16. Given the SNMP variable that contains requested data, modify the appropriate agent definition file so that agent is able to retrieve extra data during discovery.
    With emphasis on performing the following tasks:
    1. Determine which entity that records the data should be added.
    2. Find the appropriate agent definition in the agents directory.
    3. Edit the agent definition and change type to DiscoCombinedAgent, if required.
    4. Create Entries for DiscoAgentMediationFilter, DiscoAgentMediationLayer, and DiscoAgentProcessingLayer, if required.
    5. Add DiscoAgentProcLayerAddTags and DiscoAgentProcLayerAddLocalTags.
  17. Given the ITNM environment, configure the polling discovered devices, so that threshold polling, adaptive polling, and historical data collection are configured in appropriate poll policies and targeted correctly.
    With emphasis on performing the following tasks:
    1. Log in to TIP as a user with sufficient privilege to configure polling.
    2. Select Administration-> Network-> Network Polling.
    3. Create a new poll definition by using the "Add New" icon from the "Configure Poll Definitions" pane.
    4. Select the type of poll required from the drop down list (Generic Threshold, Basic Threshold etc.) and click "OK".
    5. In the Poll Definition Editor, under the General tab, complete the General Properties fields including the Event Severity.
    6. Fill in the other tabs as required (Threshold, Ping etc.) including the message Summary.
    7. Specify an Interface filter if required.
    8. Specify the Class targets for this poll definition if required.
    9. Save the poll and verify that it is the list of poll definitions (alphabetically sorted), before the poll has run (as part of a policy) - the status will be "Unknown" (grey diamond).
    10. In the "Configure Poll Policies" pane click the "Add New" icon.
    11. Define a name and enable the poll if required.
    12. In the "Poll Definition" section select the "Add Poll Definition(s) to this policy" icon.
    13. Select the poll definitions required within this poll policy, set the interval and qualify if they are required to store poll data.
    14. Assign the poll policy to the desired poller.
    15. Set a policy throttle (high water target limit) for use with Network View based targeting.
    16. Specify targeting by using a Network View, or a Device filter.
    17. Save the poll policy.
    18. Check that the poll policy is active, and reaches the desired targets.
    19. Check that the poll definition has been run successfully (green check, or red x icon), in the Poll Definition pane.
  18. Given an existing poll definition and access to the appropriate configuration file, configure the ITNM event gateway so that a named poll is passed correctly from the ITNM event gateway for Root Cause Analysis (RCA).
    With emphasis on performing the following tasks:
    1. Determine the EventID of the poll either by using the GUI or by using OQL.
    2. Modify the ITNM event gateway inserts file to include an entry representing this EventID with the appropriate precedence and EventMap values.
    3. Ensure that the event will be processed correctly by the default Precision Monitor RCA event map (based on polled EntityID).
    4. If required, create a new EventMap to handle the RCA event correctly.
    5. If required, register the EventMap with the RCA plug-in.
    6. Ensure that the event gateway process uses the new configuration.
  19. Given the ITNM server or alternative IP address, ensure RCA is configured correctly so that RCA will work after successful discovery.
    With emphasis on performing the following tasks:
    1. Click the Discovery Configuration.
    2. Click the Scope.
    3. Add ITNM server IP address and subnet mask and check the box for PING Seed.OR Edit the EventGatewaySchema.cfg file and set the $NcpServerEntity field with an appropriate IP Address under config.defaults.
    4. Save the Configuration.
    5. Restart the EventGateway.
  20. Given some additional data in the discovery and sufficient user privileges, modify the appropriate ITNM configuration files so that the additional data is correctly displayed in the structure browser.
    With emphasis on performing the following tasks:
    1. Determine the topology attribute that is required to be included in the Structure browser by using OQL and the model service.
    2. Determine the entity type the attribute is held against.
    3. Log in as a user with sufficient privilege to edit the DbEntityDetails.cfg file for the domain.
    4. Modify the contents of the DbEntityDetails file to map the topology attribute to a suitable entity details name.
    5. Ensure that these attributes exist in the model topology and if so, stop and restart the model process, and if required, ensure model contents are transferred to NCIM.
    6. If the attributes do not exist, ensure that these will be picked up during the next discovery process, and run the discovery as usual.
  21. Given a discovered network and additional data that is required to be partitioned on, appropriate command-line privileges to edit ITNM configuration files, and a suitable database login to modify NCIM tables and modify the configuration of ITNM so that non-standard data is available to create Network Views from.
    With emphasis on performing the following tasks:
    1. Determine the data that is required to be partitioned on.
    2. Determine where this data is held in the topology database, for example at a chassis or interface level.
    3. Determine the data type for each new topology attribute, for example text, integer etc.
    4. Extend the NCIM database tables to include a new table that will hold the new additional data.
    5. Modify the DbEntityDetails.DOMAIN.cfg file to include a mapping to allow population of the new NCIM table with the required topology data.
    6. Modify the ncimMetaData.xml file to ensure that the extend NCIM table is available for use in Topoviz.
    7. Stop and start the model process to force a population of the new data into NCIM.
    8. Ensure that Topoviz has picked up the new ncimMetaData by cycling the TIP/Topoviz.
    9. Verify the data is available in the network views.
  22. Given that ITNM and the dependent Netcool components are installed and running and admin access to the command line is available, perform configuration tasks so that a new icon is available for a class of device.
    With emphasis on performing the following tasks:
    1. Create icon as an image file.
    2. Copy icon to appropriate directory.
    3. Add the appropriate line to the topoviz.properties file.
    4. Save the topoviz.properties file.
  23. Given an ITNM installation and a third-party Web-based tool, configure ITNM so that the third-party tool is available as a context sensitive right-click menu tool from the topology views.
    With emphasis on performing the following tasks:
    1. Determine the URL for launching the tool, including any encoded parameters that is required to be passed from the entity.
    2. Determine the ITNM core tool attributes.
    3. Determine the context for launching the tool based on the available attributes.
    4. Determine the security contexts for launching the tool.
    5. Determine the menu the tool will run from.
    6. Edit the tool and menu XML configuration files to incorporate the tool.
    7. Stop and start TIP.
    8. Verify that the new tool is available and launches correctly in the correct object and security context, with the expected parameters being passed.
  24. Given a working installation of ITNM and the user requirements, create and configure the network view so that the required network view would be available for the specific user.
    With emphasis on performing the following tasks:
    1. Navigate to the Network View Wizard.
    2. Select the type of view and select the appropriate parameters.
    3. Populate the filters for this view.
    4. Copy or move the view to specific user(s).
  25. Given a working ITNM system, appropriate SNMP access to discovered devices, a successful, completed discovery and ITNM administrative access to TIP; create a path view so that a path between two devices can be viewed and managed by ITNM.
    With emphasis on performing the following tasks:
    1. Click TIP, go to Network Availability -> Path Views in the navigation panel of TIP.
    2. Add a New Path.
    3. Select the Domain name.
    4. Type the name of the New Path.
    5. Type the start Node or click the browse box and fine the first Node.
    6. Type the end Node or click the browse box and select the final Node.
    7. Click "Save and Trace".
    8. Ensure the Path is managed by the SAE process.
    9. Use the Path View Administration GUI to administer the Path.
  26. Given that a firewall exists between the primary and secondary ITNM domains, configure a fixed TCP/IP port for communication so that ITNM virtual domain components can communicate.
    With emphasis on performing the following tasks:
    1. On primary server, start ncp_virtualdomain.
    2. Edit the ServiceData.cfg file.
    3. Edit the VIRTUALDOMAIN reference and set DYNAMIC: YES to NO and change the PORT property to a valid port.
    4. Copy line and paste the line in backupservers ServiceData.cfg file.
  27. Given a default installation of ITNM, enable the SAE functionality and configure it to use a named topology field within the resulting SAE events so that the SAE process is enabled, the ObjectServer is configured to accept Service data and the SAE events contain the named topology field.
    With emphasis on performing the following tasks:
    1. Ensure that the ObjectServer is configured to accept Service Data from the SAE process.
    2. Modify the SAE configuration file to use the named topology attribute as the CustomerNameField within the SAE events.
  28. Given an existing topology attribute and an existing ObjectServer event field, configure the ITNM gateway to enrich events with the topology attribute in the ObjectServer field so that the event gateway is configured to enrich all events with a named topology attribute into a named ObjectServer field.
    With emphasis on performing the following tasks:
    1. Identify the topology attribute's location within the topology object.
    2. Determine if the attribute type is compatible with the destination ObjectServer field.
    3. Modify the EventGateway stitchers and configuration to enrich the event with the appropriate topology attribute.
    4. Ensure that the EventGateway uses the new configuration.
    5. Validate that ObjectServer events are enriched with the topology attribute once they have passed through the EventGateway.
  29. Given the ITNM environment and a suitable set of ObjectServer alerts.status column names, configure the system so that the ObjectServer alert.status column names can be used in the creation of Network Views and for Adaptive Poll targeting.
    With emphasis on performing the following tasks:
    1. Determine the column type used in the ObjectServer alerts.status table, via nco_sql or the nco_config GUI.
    2. Match this type to a column type in the selected NCMONITOR database (varchar, int etc.).
    3. Log in to the NCMONITOR database as a user with sufficient rights to change the activeEvent table.
    4. Modify the activeEvent table to add the additional columns - the names should match exactly between ncmonitor.activeEvent and alerts.status.
    5. HUP the event gateway to ensure that the new column is activated.
    6. Log in to TIP with a user with rights to create a Network View.
    7. Verify that a Network View can be created by using the new column names in the activeEvent table.
  30. Given a running ITNM environment, perform a graph of a specific MIB variable for a network device so that operators and administrators can see a real time graph for fault analysis and solution of network problems.
    With emphasis on performing the following tasks:
    1. Launch the MIB Graph properties window.
    2. Select Domain.
    3. Select Hostname.
    4. Select MIB data by using a MIB OID or Poll Definition .
    5. Select Polling interval in seconds.
    6. Save.
    7. View MIB Graph.
  31. Given access to Command Line Interface (CLI) of ITNM Core server, configure the OQL Service Provider (ncp_oql) so that ncp_oql is configured to authenticate against the NCIM database or Netcool/Omnibus ObjectServer instead of the default method (no authentication).
    With emphasis on performing the following tasks:
    1. Determine the authentication mode required per user requirement; i.e., NCIM, ObjectServer.
    2. Log in as a user with sufficient privilege to edit ConfigSchema.cfg or domain specific file if applicable (e.g.., ConfigSchema.DOMAIN.cfg).
    3. Modify the value for m_OQLAuthenticationMode under config.settings per requirement.

Section 4: Administration

  1. Given a working installation of IBM Tivoli Network Manager IP Edition V3.9 (ITNM) and sufficient user privileges, use the command line to uninstall ITNM so that the required components will be uninstalled.
    With emphasis on performing the following tasks:
    1. On a Windows installation remove all the installed domains prior to the uninstallation by using the ncp_install_services -domain -remove for each installed domain.
    2. Run the uninstallation script Uninstall_ITNM on the UNIX platform with the correct parameters to uninstall specific parts of the installation, or all of the Netcool suite.
    3. Run Uninstall_ITNM.exe on the Windows platform. Use the correct command line parameter to this script to change from a GUI to command line uninstallation.
      1. If installed in other than GUI mode, to uninstall with the GUI, use -i swing
      2. If installed in GUI modem to uninstall with the command line, use -i console
    4. Follow the on-screen prompts to remove the components you require.
    5. To uninstall in silent mode, edit the appropriate options in ITNM-uninstall-response.txt.
    6. Save the ITNM-uninstall-response.txt file.
    7. Run the uninstallation script.
  2. Given a time the discovery should run, configure the appropriate stitcher so that discovery is started on given time.
    With emphasis on performing the following tasks:
    1. Edit the FullDiscovery.stch file.
    2. Uncomment the appropriate ActOnTimedTrigger line and set values.
    3. Set the time the discovery should run.
    4. Save the file.
  3. Given appropriate access to the GUI, the appropriate tool security privilege, and access to the ITNM configuration files, unmanage a topology entity by using the GUI and permanently unmanage a filtered set of entities via the discovery configuration files so that an entity unmanaged via the GUI/command line and a set of entities are unmanaged automatically via the discovery process.
    With emphasis on performing the following tasks:
    1. Use the hop view, or network view, select a topology entity and unmanage it by using the right click menu tools.
    2. Use the Structure browser, select a topology entity and unmanage it by using the drop down menu tool.
    3. Use the command line, use the UnmanageNode.pl scripts to unmanage a node.
    4. Modify the appropriate discovery stitcher to permanently unmanage a set of entities (interfaces) according to the defined filter condition.
  4. Given the operational setup of the ITNM, start, stop, and verify the status of discovery process so that the discovery process is managed and verified.
    With emphasis on performing the following tasks:
    1. Start discovery process from the command line or the GUI.
    2. Stop discovery process from the command line or the GUI.
    3. Verify the status of disco by using Discovery ncp_oql, itnm_disco.pl script, the Web OQL interface, or the Network Discovery Status GUI.
  5. Given ITNM core components are installed, make changes into CtrlServices.domain.cfg file so that ITNM processes are started automatically.
    With emphasis on performing the following tasks:
    1. Verify and perform the appropriate task on user privileges to configure the automatic startup of the processes.
    2. Back up CtrlServices.cfg file.
    3. Save a copy of the CtrlServices.cfg file with the domain name appended to the file name, for example, CtrlServices.Domain.cfg.
    4. Edit the CtrlServices.Domain.cfg file according to the requirement.
    5. If required, execute the "create_itnm_control_scripts.sh" in UNIX environment OR for Windows, click Start -> Control Panel -> Administrative Tools -> Services.
    6. Select ncp_ctrl for domain DOMAIN from the Services list.
    7. Select Properties from the Action menu. Select the General tab.
    8. Change the startup type to Automatic.
    9. Leave all other ITNM services as manual startups.
  6. Given an installation of ITNM, appropriate access to the ITNM discovery configuration files, and a list of unconnected entities that need connecting, configure the PresetLayer stitcher mechanism so that the unconnected devices are connected and the model database is populated with this information.
    With emphasis on performing the following tasks:
    1. Determine the entity names of the entities to be connected.
    2. Determine if these entity names are liable to change with each discovery.
    3. Modify the PresetLayer stitcher to include the desired connections, add any additional entities, and provide the correct containment.
    4. Enable the PresetLayer stitcher via the correct calling stitcher.
    5. Ensure that the connections defined within PresetLayer assume the correct priority in the final topology.
    6. Verify that the connections appear in the appropriate topology map.
  7. Given that ITNM is installed and access to the ITNM databases is available, demonstrate a working knowledge of ITNM databases, so that entity data can be retrieved.
    With emphasis on performing the following tasks:
    1. Query the ITNM databases.
    2. Retrieve assets and connectivity data about a device.
  8. Given a discovered topology, select the appropriate devices for the rediscovery and set the partial agents so that rediscovery of devices could be performed successfully.
    With emphasis on performing the following tasks:
    1. Verify if the partial discovery agents are configured.
    2. Select the devices to be rediscovered from HOP View or Network View and right-click, and Rediscover Node(s) or use the Discovery Configuration GUI Rediscovery button to enter devices or subnets to be discovered.
    3. Complete the basic and advanced fields if required.
    4. Click Go to launch the rediscovery.
  9. Given a MIB file and access to the IBM Tivoli Integrated Portal server, make the appropriate actions so that MIB information is successfully written to the NCIM database.
    With emphasis on performing the following tasks:
    1. Verify that the MIB file has the correct sufflix.
    2. Edit the MibDBLogin.cfg and verify that correct database credentials are used (m_UserName, m_Password).
    3. Save the file.
    4. Start the ncp_mib process by issuing the ncp_mib command.
    5. Verify that MIB has successfully loded by query the database table ncmib.mib_modulefor the MIB name : SELECT * FROM ncmib.mib_modules WHERE modulename = ‘MODULENAME';

Section 5: Problem Tuning & Problem Determination

  1. Given the Architecture documentation, access to the command line and credentials for the NCIM database, verify connectivity to the NCIM database so that IBM Tivoli Network Manager IP Edition V3.9 (ITNM) components can access the NCIM database.
    With emphasis on performing the following tasks:
    1. Check the type of database.
    2. Verify database server is up and running.
    3. Verify required port should be accessible from the other Netcool component.
    4. Perform any database library actions necessary.
  2. Given the running setup of the ITNM, verify the device can be contacted from ITNM so that the reason the device is not fully discovered.
    With emphasis on performing the following tasks:
    1. Ping and verify the reachability of the device from the ITNM server.
    2. Verify the device was included in the finders.
    3. From ITNM Web-console, use MIB browser to verify the SNMP connectivity from ITNM with the given SNMP credentials to device.
    4. Verify that the device or IP address was passed to the post AssocAddress agents.
    5. Verify the device is not being removed by discovery filters.
    6. Verify that the collector is able to import the required device list from respective EMS/data source and those devices are accessible from ITNM.
    7. Verify any NAT configuration.
  3. Given a running OMNIbus and ITNM environment, interrogate the event sub-system so that events are properly mapped to the corresponding topology entity.
    With emphasis on performing the following tasks:
    1. Enable debug level 4 for nco_p_ncpmonitor, ncp_g_event, and ncp_poller processes.
    2. Verify that nco_p_ncpmonitor and ncp_g_event processes are connected to OMNIbus environment.
    3. Verify that events are being generated by the ncp_poller processes and the nco_p_ncpmonitor probe is receiving the events by viewing their respective log files.
    4. Verify that events are received by the ObjectServer.
    5. Verify that incoming events are matching event map criteria defined into NcoGateInserts.cfg file or EventGatewaySchema.cfg in ncp_g_event.domain.trace
    6. Verify that events are mapping on topology on discovered devices.
  4. Given administrative access to ITNM system, perform configuration tasks so that the log levels of ITNM Core processes are changed.
    With emphasis on performing the following tasks:
    1. Connect with administrative privileges to the ITNM system.
    2. Change at the needed level the debug parameters in the CtrlServices.DOMAIN.cfg file under the etc directory for ITNM specific files or use the kill -USR2 (processid) command on a specific process as many times as the debug level desired.
    3. Restart the ncp_ctrl processes if required.
  5. Given a failing ITNM process or component and access to the ITNM server, locate the appropriate log or trace file so that the problem can be identified.
    With emphasis on performing the following tasks:
    1. Locate the appropriate log or trace file.
      1. Check log file rotation environment variables to ensure the correct file is being examined.
    2. Look for significant error messages.
  6. Given completely installed product, verify the basic criteria, and based on the outcome, make the required changes so that ITNM is connected with OMNIbus.
    With emphasis on performing the following tasks:
    1. Obtain the ObjectServer port and name on which it is running.
    2. Verify the interfaces file.
    3. Verify if the ObjectServer is running by using nco_ping, ps -ef commands.
    4. Verify if the hosts file is correct in the operating system.
    5. If this is a remote installation of OMNIbus; verify whether the two systems are able to communicate by using available UNIX, Windows, and Netcool commands.
    6. Verify that the ITNM to OMNIbus processes have no error in their log files.
    7. Verify connectivity by using nco_sql.
  7. Given that ITNM is installed and the ITNM host is in the MODEL topology, determine why ITNM Root Cause Analysis (RCA) is not working so that the reason for Root Cause problem is identified.
    With emphasis on performing the following tasks:
    1. Confirm that there is a contiguous path in the MODEL topology between the source and destination.
    2. Check that the Gateway ncp_g_event is running and the RCA plug-in is enabled.
    3. If the RCA plug-in or gateway is not running or cannot be started, review the log files in the log directory for ITNM specific files.
    4. Open an OMNIbus Event List and confirm that the events expected to partake in RCA contain the required data to pass across the ITNM Gateway. (LocalNodeAlias and EventId are populated and NmosDomainName is set appropriately).
    5. Examine the EventGatewaySchema and/or NcoGateInserts files to confirm that: a) the EventId is mapped to an existing and appropriate EventMap, b) the EventMap is registered with the plug-in, and c) the Event is associated with an EventGateway stitcher.
    6. Check that the value for LocalNodeAlias in the event exists as an entity in ncimCache.entityData by using ncp_oql. For example, in the case of chassis where LocalNodeAlias is a text string, SELECT * FROM ncimCache.entityData WHERE ENTITYNAME = ‘LocalNodeAlias';
    7. Check that an Alert has been created in mojo.events by using ncp_oql. For example, SELECT * FROM mojo.events WHERE EntityName = ‘LocalNodeAlias';
    8. Check if the Alert in mojo.events has been updated by the RCA plug-in.
    9. Determine if the expected root cause or symptom event(s) have occurred within a similar timeframe.
    10. If the alert is in mojo.events force synchronization by issuing a kill -HUP [PID] ncp_g_event process, monitor the logs and search for the problem event and errors.
    11. If the Alert has not been updated as expected by RCA, check how the event should be processed by the EventGateway stitchers (for the initial topology lookup) and the RCA set of stitchers.
    12. If the Alert has been updated as expected by RCA, check the EventGateway log and or trace file to determine why the update has not been passed back to the OMNIbus Event List.
  8. Given the operational setup of ITNM, configure the MONITOR probe to communicate with the ObjectServer, and populate an event field with new data so that ITNM MONITOR probe is able to communicate with ObjectServer.
    With emphasis on performing the following tasks:
    1. Ensure that the ObjectServer interfaces file contains the IP address or host name of the ObjectServer server and the ObjectServer port number.
    2. Modify the probe rules file to include the new source variable in an appropriate event field.
  9. Given that all ITNM processes are running and discovery configuration parameters are configured, demonstrate knowledge of the various phases of discovery, and the common databases used in troubleshooting discovery issues so that detailed information about the discovery processes is available.
    With emphasis on performing the following tasks:
    1. Review troubleshooting reports for ITNM.
    2. Determine which phase a discovery is using ncp_oql (not the GUI).
    3. Determine if the discovery has cycled and what causes this.
    4. Determine how many IP addresses were found.
    5. Determine how many devices were filtered by the Pre-Discovery filter.
    6. Determine which agents are still running and why.
    7. Determine the neighbor data returned from a specific device by using the agent returns tables.
    8. Find out how many chassis objects will be in the final topology with a Sysname like "lon".
    9. After making changes to the PostScratchProcessing stitcher, rerun the stitcher and send the modified topology to model.
  10. Given a requirement to enable caching of discovery tables, configure the discovery via the GUI or the configuration file so that discovery is configured for the next discovery.
    With emphasis on performing the following tasks:
    1. Navigate to the Advanced tab of the discovery configuration.
    2. Select "Enable Caching of Discovery Tables"
    3. Save the configuration and ensure that the discovery process will use it.
    4. Alternatively modify the domain specific disco configuration file and ensure that m_WriteTablesToCache is enabled.
    5. Ensure the discovery will use this configuration.

Register for a test

Register for an IBM Certification test at Prometric and take a step into your future.

IBM at Prometric