exploring, configuring and optimizing the dell openmanage ...€¦ · 6.0 the protocols discovery...

January 2004 Dell Enterprise Systems Group

Exploring, Configuring and Optimizing the Dell

OpenManage IT Assistant Discovery

Service Enterprise Systems Group (ESG) Advanced Systems Group (ASG)

Dell OpenManage Systems Management

Dell White Paper

By Ross Burns [email protected]

And Terry Schroeder

[email protected]


Contents

1.0 Introduction ........................................................................................................................3 2.0 An Overview of IT Assistant’s Components................................................................4 3.0 What is New in Version 6.5 .............................................................................................6 4.0 Configuring Discovery and Status Polling in General ..............................................7 5.0 Configuring Discovery for a Specific Network .........................................................13 6.0 The Protocols Discovery Uses .......................................................................................20 7.0 The Discovery Process In-Depth ..................................................................................26 8.0 The Status Poll Process In-Depth .................................................................................31 9.0 Discovery Options...........................................................................................................33 10.0 Importing Systems for Discovery .............................................................................41 11.0 Discovery FAQs and Other Trouble-shooting Tips ..............................................44 12.0 Conclusion.....................................................................................................................52


1.0 Introduction As Dell expands into the enterprise space, its systems management software must become more scalable, robust, configurable, and faster to adapt to customers’ networks that are ever increasing in size and diversity. Beginning with OpenManage™ IT Assistant (ITA) version 6.5, the improved Network Monitoring Service is targeted at fulfilling all of these goals and more. This article provides an in-depth examination of the Network Monitoring Service and the new features it provides. In addition, the reader will gain insight on configuration options and tips on how to optimize the service for their specific network environment, as well as take advantage of options not previously published.

For this paper, it is recommended that the user have a minimum installation of IT Assistant v6.5 from the Dell OpenManage Apps CD or downloaded from Dell online. IT Assistant version 6.5, released in the fourth quarter of 2003, provides many new discovery and other enhancements, some of which will be mentioned throughout this article. This paper assumes a basic level of familiarity with using IT Assistant in a networked environment. Many concepts discussed in this paper build on the IT Assistant’s User’s Guide and the IT Assistant’s Reference Guide, which can be found on the OpenManage Product Documentation CD that ships with each PowerEdge™ server.


2.0 An Overview of IT Assistant’s Components IT Assistant is a multi-tiered application – it is made up of a services tier and a user interface (UI) tier; following is a breakout of the tiers and their supporting functions.

2.1 IT Assistant Services Tier The IT Assistant services tier is the heart of the product. Included in this tier are the following services and the functions they perform:

• IT Assistant Network Monitoring Service

Discovery – Discovers managed systems on the LAN/WAN at scheduled intervals determined by the administrator and populates the database with managed system information.

Status Polling - Actively polls managed systems for power/network connectivity status and health status at scheduled intervals determined by the administrator.

Event Management System (EMS) - Processes incoming events including SNMP Traps, DMI indications, and CIM indications for alert notification based upon the existence of event filters and actions configured by administrators. Event filters and actions do not need to be defined for alerting to occur, but this allows for automated notification of administrators in the event of a hardware problem. If no event filters or actions are defined, the console view is only updated to reflect event information received from monitored systems.

• IT Assistant Connection Service

Connectivity (communication) to managed systems and the ITA database for retrieving status, summary, and asset data and for performing sets on the managed system.

A conduit between the UI and the Network Monitoring Service to send and receive discovery configuration data.

• IT Assistant Database

The database tier is based upon Microsoft’s MSDE database, or users can also implement the IT Assistant database based on a local or remote Microsoft SQL Server™ installation.

Repository for:

- Managed system information

- IT Assistant Discovery and Status polling configuration

- Event definitions, event filters and event actions configuration

2.2 IT Assistant Client User Interface

Console view of all managed systems including an alerts view, managed system view, etc. The IT Assistant Connection Service can support multiple UI connections to IT Assistant.


Configuration of the IT Assistant Services tier

Configuration of individual managed systems

Dataflow between IT Assistant Client UI and the Services tier flows through the Connection service, which acts as a conduit between the two. Additionally the Connection service can talk directly to the database for functions like inventory. The Connection service also provides the means by which the UI can communicate to a managed system, either to retrieve data dynamically from the managed system or to configure the managed system. See Figure 1 for an overview of IT Assistant’s tiers and representation of dataflow between the tiers.

Figure 1 – Overall Component View


3.0 What is New in Version 6.5 The IT Assistant Network Monitoring Service has undergone a re-architecture and rewrite, designed to provide the following enhancements and features:

• Increased discovery and status speed through an optimized multi-threaded design. • Increased scalability, providing support for discovery and management of systems numbering in

the 1000s. • Support for discovery and status feedback to the user. • Support for enhanced configuration and optimization of the discovery/status process. • Support for offline summary information • Other discovery-related features discussed later in this article.

Other changes and enhancements new to version 6.5:

• Because of the discontinuance of support for the Microsoft JVM, the ITA User Interface now installs and runs as an application under the .Net framework - the framework is automatically installed and configured. Because of this change, the UI no longer runs in an Internet Explorer browser and is not web-servable.

• The system summary page can now be viewed even if the system is offline (down) in IT Assistant.

• Reduced startup time of the User Interface if managing a large number of systems compared with prior releases of IT Assistant

• Automatic grouping of systems that are members of a high availability windows cluster. • Addition of a node (or system) import utility to import nodes for targeted discovery. • Addition of a group configuration utility for configuring IT Assistant groups outside of the UI.


4.0 Configuring Discovery and Status Polling in General

In the IT Assistant UI, under Options->Discovery Cycle in the left navigation bar is the dialog shown in Figure 2 below. Note that this dialog has been redesigned from previous versions. Another change is that this dialog is only viewable when the user has read/write permissions to protect protocol information. All data in this dialog is stored in the GlobalConfiguration table in the IT Assistant database.

Figure 2 – Discovery/Polling Cycle Configuration dialog

In the Discovery/Polling Cycle Configuration dialog, the user can configure the following:

1 Discovery Settings Tab: The time at which discovery occurs, how often discovery occurs, and how fast discovery occurs.

2 Status Settings Tab: How often a status poll cycle occurs and how fast it occurs.


3 Protocol Settings Tab: The default protocol settings for each of the standard protocols that IT Assistant supports. The settings changed here apply to each new discovery range that is to be setup. The user can then further customize these settings for each discovery range. Note that any changes to the protocol settings in this tab do not apply to previously setup discovery ranges; only new ones.

4.1 Discovery Cycle: If, When, and How Fast Discovery Occurs In figure 2, the Discovery Settings Tab, there are several controls:

1. Enable Discovery checkbox - this control (checked by default) controls whether or not a regular discovery cycle occurs. Note that this control has no affect on forced discoveries (discoveries that the user can explicitly initiate). Un-checking this box while discovery is occurring will cancel all discoveries in progress, except forced ones. When a discovery range, sometimes known as a discovery subnet, is cancelled before it can complete, its status will show as “stopped” in the discovery feedback view and all discovery threads will exit at the first opportune time.

2. Discovery Interval, Time of day and Day of week – When regular discovery is enabled, these controls configure how often a discovery cycle occurs. The interval option allows the user to schedule discovery as often as every hour or as seldom as every few days. New to IT Assistant v6.5 is the time of day and day of week option, allowing the user to control exactly when discovery occurs, such as an off-peak hour of the day to reduce network traffic. The user can switch between interval and time of day/day of week options at any time. Should the interval option be selected at the time of services startup, a regular round of discovery will occur immediately, which establishes a beginning reference point for each interval after that point. For time of day/day of week, discovery will not occur at services startup unless services are started at the very moment a discovery is scheduled.

Note that, even if the user schedules a discovery cycle for every hour, if the previous discovery cycle is not complete (meaning all discovery ranges do not show 100% complete in the discovery feedback view), another discovery cycle will not be allowed to go through but will instead be aborted. Then, an NT event log entry will be created under the Application Event Log with the source name of IT Assistant Services saying that a discovery cycle was aborted. Any subsequent discovery cycles will be aborted until the last cycle running has completed. This is a self-regulating feature of the discovery service to assure that discovery cycles never accumulate due to a discovery interval that is too short for the network being discovered. If the user is frequently seeing these abort messages, it is likely that the discovery interval will need to be increased.

TIP: If your network suffers from congestion, or the IT Assistant services are run on a computer that is used for other tasks during the day, you should select the time of day/day of week option for scheduling discovery during an off-peak hour. This allows the discovery service to take full advantage of the system resources available and minimizes the impact on network traffic.

TIP: Because IT Assistant updates its database of IP Addresses for each system during a discovery cycle, it is important that discovery be run often in a DHCP-prevalent environment A good rule of thumb is an interval that is no more than approximately half the time of the lease


period for IP Address assignments on the network. For static IP environments, discovery can be run less often, but it is not recommended to rely solely on forced discoveries to assure IT Assistant has the latest inventory data for the systems it manages.

IT Assistant Configuration Option: By default, another round of discovery will not occur if the last round (or cycle) was not 100% completed for all discovery ranges. To change this behavior to occur on a discovery range level so that when discovery starts again, those discovery ranges that are already 100% complete are started again, see the configuration option ONE_RUNNING_DISCOVERY_ABORTS_ALL in the section Discovery Options later in this article.

3. Discovery Speed slider bar – This control, also known as the discovery throttle, controls how fast discovery occurs and how much network and system resources are consumed for discovery by controlling:

a. How many discovery threads are allowed to run at any one time, and b. How long the delay is between pinging systems during a network ping sweep, on the

order of milliseconds.

Note that each tick on the throttle control equals 10% and the range is from 10% to 100%. Upon a new install of ITA v6.5, the discovery throttle is set at 40% by default; upon an upgrade to ITA v6.5, the throttle control remains at its previously set value.

IT Assistant v6.5 introduces a highly optimized parallel threading implementation in the Network Monitoring Service. Because the discovery process is very resource intensive it can be greatly optimized by making it a parallel operation, where threads running in parallel (known as multi-threading) are sending requests and handling responses to several systems at once. To an extent, the more threads that run in parallel, each communicating to a different system, the faster discovery will be, barring high network congestion or latency. The discovery process, by default, allows a maximum of 32 threads to run in parallel (or concurrently) at any one time for discovery. To control the number of parallel threads executing you can move the discovery throttle control either up or down. When set at the maximum, 32 parallel threads are actually allowed to run. If the throttle is at 50%, only 16 threads are allowed to run at any one time. Because the new discovery service is optimized for parallel threading operations, more system resources will be consumed even at the same throttle setting as the older (pre-v6.5) discovery process. It is recommended that you monitor the system resources so that a satisfactory trade-off is made between discovery speed versus system resources available for IT Assistant. It may be necessary to lower the throttle or increase the throttle dependent upon the server. Note that the discovery service may take up to several minutes to adjust to a new throttle setting.

TIP: For medium to large size networks (several hundred to several thousand systems) that ITA must discover, it is recommended that you install ITA services on a multi-processor system running a multi-processor version of Windows.


4. Discover all systems or only Dell instrumented systems – If All Systems is selected (the default), ITA will store in its database any network device that responds to a ping – it does not need to have any instrumentation loaded, nor does it need to support any of the standard protocols that ITA communicates by. Many of these devices will possibly show up in the unclassified category in the UI. If the setting of Only Dell Instrumented Systems is selected, only those systems that have Dell instrumentation loaded and running will be discovered. Under this setting, no systems should appear in the unclassified category (or group) – all discovered systems should be classified. Should this option be selected after ITA has discovered systems under the All Systems selection, any unclassified systems stored in the database will be deleted immediately. Note that once ITA classifies a system, it will stay with that classification even if it cannot communicate with instrumentation on subsequent rounds of discovery.

TIP: If you are having trouble discovering a system and Discover only Dell Instrumented Systems is selected, change this to All Systems and force a discovery of the discovery range the system is on. If the system shows up in the unclassified group, it is responding to a ping, but one or more of the following is true: (1) the protocol settings are incorrect on the system you are trying to discover or in ITA itself, (2) the protocol ITA needs to use to communicate to the system is blocked by a network router or port blocking software, or (3) Dell instrumentation is not loaded or running on the system to be discovered.

5. Use DNS Name Resolution or Instrumentation Name Resolution – This selection controls which name resolution method ITA uses first – one is always a backup for the other. When ITA discovers a system, it will always use the IP address(es) of the system to communicate with it – as part of discovery, the discovery service will always try to resolve each IP Address to a name because users are typically used to dealing with systems by name and not by IP Address. If DNS Name Resolution (default) is selected, a network API is called to convert the address to a name. If this call fails and instrumentation is loaded on the remote system, ITA will query the instrumentation for the systems name. The name given by DNS is typically the fully qualified domain name (FQDN) while the instrumentation name is typically the NetBIOS name. If Instrumentation Name Resolution is selected, then instrumentation is queried first for the name; if it fails, DNS is used. No matter what the order, if both methods fail, the name of the system will be left as the IP Address.

TIP: If DNS is present in your environment, you should select DNS Name Resolution as your default resolution. If you must later change it, it is recommended that you delete all discovered systems and allow for discovery to rediscover all systems so that there are no duplicate entries in the UI; also, any event filters that were set up with managed systems as criteria may need to be edited to include the new names as criteria. If you are managing clusters, Instrumentation Name Resolution is the best choice so that each system that is part of the cluster is seen by its real name, not the cluster name. Because changing this setting can disrupt your ITA environment, it is recommended that you change this setting only when necessary.

4.2 Status Cycle: If, When, and How Fast a Status Cycle Occurs In figure 2, the Status Settings Tab, there are several controls:


1. Enable System Status checkbox – This control (checked by default) allows the user to enable or disable status poll cycles. Status polls should always be enabled, as this allows ITA to perform a frequent check of the connectivity and hardware health of the managed systems it has discovered.

2. Get System Status Interval Setting – With the status poll enabled, the user can configure the interval at which the status cycle occurs using this control. An interval can be set anywhere from a minute to many hours. For more information about what occurs during a status cycle, see the Status Cycle Process In-Depth section later in this article. Just as discovery has a self-regulating feature, so too do status polling cycles; the next status cycle will not start until the last one has finished. The Discovery Feedback view provides the progress of a status cycle.

TIP: Status cycles occur much quicker than discovery cycles because they query only a few pieces of data from the managed system. Therefore, the interval between status cycles can be set much lower. The more often a status cycle occurs, the quicker ITA can tell if the managed system has lost connectivity with the network or has gone down.

3. Status Speed slider control – This control, also known as the status throttle, is new to version 6.5. This control acts much like the discovery throttle, controlling how many threads are used during a status cycle. By default, there are a maximum number of 32 threads dedicated to performing the status process – the throttle controls how many threads are actually used. Since the status threads do less work than discovery threads, they take up fewer system and network resources. It is recommended that you keep the throttle control at 100% (the default).

4.3 Protocol Defaults In figure 2, Protocol Settings tab, there are several controls related to configuring the various standard protocols that ITA supports. The protocol settings configured here apply to discovery ranges that are set up – these settings fill in the corresponding identical fields when a new discovery range is set up for the first time. After this, the protocol settings for each discovery range can be further customized to the subnet (or group of systems) that is to be discovered within the defined IP range, or can be left alone if no further customization is needed. Note that changes to the settings in the Protocols tab only apply to new discovery ranges – changes are not retroactive. The overview of these controls by protocol is as follows:

1. SNMP settings: a. Get Community – The user should enter the get (or read) community name here. New to

v6.5, multiple names can be entered into this field, separated by commas, and ITA will auto-detect the correct one by trying each one in the list until a community name that matches is found. Note that community names are case sensitive. Because trying multiple community names can slow down discovery, keeping the list to a few names is recommended. A best practice is to minimize the number of community names set up for each discovery range created.

b. Set Community – The user should enter the set (or write) community name here. New to v6.5, multiple names can be entered into this field, separated by commas, and ITA will auto-detect the correct one by trying each one in the list until a community name that


matches is found. You should follow the same guidelines stated in the Get Community section above when creating the Set Community name.

c. Timeout – Specifies the maximum amount of time ITA will wait for a response after issuing an SNMP request to a managed system. Note that the latency includes both: (1) the round trip network time and (2) the time the agent takes to retrieve this data from its own subsystem that it reports on. For most networks and Dell agents, the default setting should suffice. For slower networks and/or WAN infrastructures, this setting may need to be increased.

d. Retries – Specifies the number of times ITA will attempt to communicate to a managed system during an SNMP request if ITA receives no response. Dell recommends that you keep this setting at a low value, as communication to the managed system (including discovery) will be slowed if it is not. However, if ITA is in a network environment where UDP packets (SNMP communicates via UDP over IP) are dropped frequently, this setting may need to be increased.

2. DMI Settings: a. RPC Type – DMI is a Remote Procedure Call (RPC)–based protocol. Different operating

systems use different RPC types. Microsoft Windows® uses the RPC type of Distributed Computing Environment (DCE) while Novell® Netware® and UNIX® use the Open Network Computing (ONC) RPC type. The default setting is DCE and, unless Novell Netware-based systems are being discovered, this will suffice. Previous versions of ITA would try both DCE and ONC protocols – the RPC type GUI control would dictate which one was tried first. New to ITA v6.5, only the RPC type specified in RPC type GUI control will be tried by IT Assistant. Note that some UNIX operating systems have DMI Service Layers that are buggy and can lead to instability in the discovery service. Because of this, the ONC RPC type is not tried by default. If Novell Netware systems are to be managed by ITA, one or more discovery ranges should be set up especially for these systems, with the ONC protocol type as the selected RPC type, but these discovery ranges should not contain the IP Addresses or names of UNIX-based systems.

b. Transport – This further specifies the way ITA should communicate to DMI-based systems. This field should be left at its default setting.

3. CIM Settings: a. Username – CIM uses domain-based authentication. If using the CIM protocol to manage

systems, this field is to contain the username of the domain-based account used to authenticate to the remote system(s).

b. Password - If using the CIM protocol to manage systems, this field is to contain the password of the domain-based account used to authenticate to the remote system(s). Note that ITA stores this field using strong encryption.


5.0 Configuring Discovery for a Specific Network

In the IT Assistant UI, under Options->Set Discovery Range in the left navigation bar is the dialog shown in Figure 3. Note that this dialog has been redesigned from previous versions. Another change is that this dialog is only viewable when the user has read/write permissions in IT Assistant in order to protect protocol information. All data in this dialog is stored in the DiscoveryConfiguration table for inclusion ranges and the SubnetExclusion table for exclusion ranges in the IT Assistant database.

Figure 3 – Discovery Range Setup Dialog

New to IT Assistant v6.5, both include and exclude discovery ranges can be set up.

5.1 Inclusion Ranges Inclusion ranges tell IT Assistant what to discover. An inclusion range can be one of: hostname, IP address, or IP range. Note that discovery using the IPX protocol, prominent on Novell Netware systems, is no longer supported by IT Assistant – it is necessary to equip these systems with an IP stack for IT Assistant to continue to discover and manage them. Figure 4 depicts the dialog for configuring inclusion ranges for discovery.


Figure 4 – Discovery Range Setup Dialog

In Figure 4, the Discovery Range Configuration dialog, there are several controls:

1. Discovery range – IP Address or Range – the user can enter a single IP Address or a range of IP Addresses. Given an IP Address or IP range consisting of the format w.x.y.z, the following table specifies what is allowed by IT Assistant:


Placeholder User can enter

W For a single IP or IP range: a single number within the range 0 < w < 255.

X For a single IP or IP range: a single number within the range 0 ≤ x ≤ 255.

For a single IP: a single number within the range 0 ≤ y ≤ 255.

For a range represented by startIP – endIP: the range represented by a – b, where b > a, 0 ≤ a ≤ 255, and 0 ≤ b ≤ 255. Examples: 12 – 14, 200 – 202.

Y

For a full (valid) range generated by ITA: the character “ * ”. ITA generates the range of 0 ≤ y ≤ 255 during discovery.

For a single IP: a single number within the range 0 < z < 255.

For a range represented by startIP – endIP: the range represented by a – b, where b > a, 0 < a < 255, and 0 < b < 255. Examples: 12 – 14, 200 – 202.

Z

For a full (valid) range generated by ITA: the character “ * ”. ITA generates the range of 0 < z < 255 during discovery.

Table 1 – Valid Discovery Ranges

To figure out how many IP Addresses are generated for a particular discovery range, multiply the four IP parts together: w*x*y*z. For example, for a discovery range of 192.168.*.*, the number of addresses generated is 1*1*256*254 = 65,024 IP Addresses.

TIP: Although IT Assistant allows you to enter a discovery range such as “192.168.*.*”, which will likely discover your entire network without the need to enter any additional discovery ranges, discovery will generate 65,024 addresses to ping during each discovery round leading to excessive consumption of network and system resources to discover a comparatively (much) smaller number of actual managed systems. In addition, the discovery cycle can take from several hours to over a day to perform a full discovery, resulting in unnecessary delays in refreshing data in the IT Assistant database. Instead, it is recommended to configure discovery ranges that correspond to the segments of your network. If IP ranges are used, as opposed to hostnames or single IP addresses, the optimal configuration is 10 – 20 discovery ranges that each cover approximately 250 – 500 IP addresses. Examples of this are: 192.168.2.*, 192.168.1-2.*, 192.168.2-3.1-100, etc.

2. Discovery range – Hostname – the user can enter a single hostname for discovery. IT Assistant must be able to resolve this hostname to one or more IP addresses for discovery to be successful. To check resolution from name to IP, run the command on the IT Assistant services machine: ping


–a hostname. Note that if a hostname is resolved to more than one IP, IT Assistant will try discovery on every IP returned.

TIP: Using hostnames for discovery is sometimes ideal if systems to be discovered are scattered throughout a network and/or DHCP is prevalent in your network environment; however, it can introduce a dependency on your domain name server to produce accurate and dependable results when discovery calls upon it to resolve a name to an IP. If hostnames are the preferred method for discovery and you wish to have an easy way of importing a list of hostnames, see the Importing Systems for Discovery section later in this document.

3. Enable Scheduled Discovery of this Item checkbox – checked by default, this enables/disables discovery for this particular discovery range. Uncheck this option if you wish to disable discovery of this item. Note that a status poll is still performed on what has been already discovered by this discovery range. Since discovery updates the IP addresses for each discovered system, a status poll using this information could produce inaccurate results as to the connectivity status of the discovered system if discovery of the item is disabled. If a discovery range is disabled for any extended period of time and changes to the assignments of IP address(es) occur that IT Assistant does not know about, IT Assistant may report these systems as being down, which could be inaccurate, or even worse – IT Assistant could be reporting data on a different system entirely. Dell recommends that you only disable discovery for a temporary period of time, if needed.

4. Enable SNMP, enable DMI, enable CIM checkboxes – checked by default, each of these control whether or not the respective protocol is used for this discovery range. A new feature to ITA v6.5, these controls can streamline discovery by only using those protocols that are used by the agents ITA communicates to on each managed system. To determine which protocols are used by Dell agents, see the Protocols Discovery Uses section later in this article.

5. SNMP, DMI, and CIM settings – these fields are initially filled in with the global defaults and can be customized further to this discovery range. For more information on how to configure each protocol, see section 4.3 above.

5.2 Exclusion Ranges Exclusion ranges tell IT Assistant what not to discover or what to ignore. An inclusion range can be one of: hostname, IP address, or IP range. The formats for exclusion ranges are the same as for inclusion – for valid exclusion ranges, see section 5.1 above. Exclusion ranges are useful for omitting single systems or small groups of systems among a wider inclusion range or to temporarily exclude systems from being discovered. Should an exclusion range be entered for a system already discovered, that system would be deleted from the IT Assistant database of discovered systems (and subsequently, the UI). Any combination of IP addresses or hostnames can be used for exclusion and any exclusion range entered applies to any and all inclusion ranges configured. For example, an inclusion range can be specified as 192.168.2.*, while an exclusion range can be the hostname “systemA”, which might have the IP address of 192.168.2.30. When IT Assistant begins discovering on range 192.168.2.*, it will abort the discovery of this system as soon as it resolves the IP of 192.168.2.30 to “systemA” and finds that it is in an exclusion range.


When using a hostname as an exclusion range, the name must exactly match what is returned to IT Assistant, including any domain extension, if applicable. For example, specifying “systemA” as an exclusion range will not work if IT Assistant discovers a system as “systemA.domain.” When trying to use an IP address to exclude a system, it is important to include all IP addresses that the system may be discovered under; only IP addresses that are part of an inclusion range need to be entered. For example, if a managed system has three network cards with the IP addresses of 192.168.2.3, 192.168.2.4, and 193.168.200.200, and IT Assistant has an inclusion range of 192.168.2.*, both 192.168.2.3 and 192.168.2.4 would need to be entered as exclusion ranges (or 192.168.2.3-4 could be entered for exclusion). Note that, although IT Assistant does not directly support the entry of netmasks, a netmask can be emulated through an exclusion range.

5.3 Additional Discovery and Status Cycle Considerations Discovery and status cycles operate independently of each other; both can be executing at the same time. Although discovery performs all of the functions as a status cycle (power/connectivity, health check), a status cycle is much faster to execute due to the limited number of functions it performs, so a status cycle is not halted or prevented from starting should a discovery cycle already be running and vice-versa. Synchronization techniques in updating the database of systems are in place within IT Assistant should discovery and status operations occur on the same system at the same time.

5.3.1 Force Discovery In ITA v6.5, a force discovery can be initiated through one of two left navigation bar options: Views->Discovery Feedback or Management->Force Discovery. Force discovery allows the user to initiate a discovery outside of the regularly scheduled discovery. Should a force discovery be started on a discovery range already undergoing a regular or forced discovery, that discovery cycle will be stopped and the new force discovery request will start execution at the beginning. A force discovery request has a higher priority than a regular discovery, so a force discovery request that is executed while a regular discovery is occurring will get priority and finish faster. However, subsequent force discovery requests on a discovery range (or system) already undergoing a force discovery will not raise the priority of discovery of that item – it will only start the force discovery of that item over again. Should a regular discovery round start while a force discovery is occurring, no interruption of the force discovery will occur. Under force discovery, the following options are allowed:

1. All Systems – initiates a force discovery of all configured discovery ranges. 2. Discovery Range – select one or more discovery ranges for a force discovery. 3. Select Systems – select one or more individual systems for a force discovery.

5.3.2 Initial Discovery When entering a discovery range into ITA for the first time, ITA will automatically start a discovery cycle to attempt to discover that range, provided that the range is enabled when configured.

5.3.3 Discovery Feedback New to ITA v6.5 is a discovery feedback view, accessible from the left navigation bar under Views->Discovery Feedback. This view has two tabbed panels, Global Status and Discovery Cycle Log:


1. Global Status Tab – Contains feedback for status poll cycles and discovery on a global level. If a status poll is occurring, in the Status Feedback section the progress bar will show the overall progress; otherwise the “Current Status” will show the time that the last status poll occurred. Status polling can be disabled through this view, provided the user has read/write privileges for IT Assistant. The enable/disable button in this view is the same as the status poll enable/disable checkbox under Options->Discovery Cycle. For discovery, the “Current Status” Label in the Discovery Feedback section shows whether discovery is running or not running; details of discovery can be viewed under the Discovery Cycle Log tab. A global progress bar for discovery is not provided at this time. Discovery can be disabled through this view, provided the user has read/write privileges for ITA. The enable/disable button in this view is the same as the discovery enable/disable checkbox under Options->Discovery Cycle.

2. Discovery Cycle Log – Displays the progress for each discovery range that has undergone or is

undergoing discovery. All entries are cleared out if IT Assistant’s services are restarted. A start time, percent complete, and completed time are provided for each entry. For those ranges that are interrupted during discovery, the completed time column will show “stopped” to indicate that the range was interrupted, and the percent completed column will show how far the discovery process had completed before it was interrupted. Interruptions that can occur include disabling discovery, performing a force discovery on a range already under discovery, and removing a discovery range while it is being discovered.

a. Discovery Details – Under the Discovery Cycle Log tab is the button that brings up the

Discovery Details dialog. This dialog and the additional actions the user can perform from here help the user to troubleshoot a discovery or status cycle that appears to take a long time or never complete. Under the Discovery Details dialog are two options:

i. Request Details – Shows a dialog that describes the discovery or status poll tasks that are currently running. For more information on what tasks can run, see the in-depth sections on status and discovery later in this article. The columns presented in this view are as follows:

1. Discovery Type – shows the type of task; the value is one of: IP Address

Discovery (also known as a Ping Discovery Task), System Discovery (System Discovery Task), and Status Poll (Status Task).

2. Managed System – the IP addresses or name of the system the task is executing on. This is not applicable to IP Address Discovery tasks.

3. Discovery Range – the discovery range that is responsible for initiating the task.

4. Execution Time – Time (in seconds) the task has been executing. Note that only executing tasks are shown in this view. There may be tasks in queue to run at a later time, as only a certain number of tasks are allowed to run at any one time. When a task is finished, a queued task will be scheduled to run, so this table of results will constantly change. Because the table is not dynamic, to refresh it, you must close the dialog and bring it up again by clicking on Request Details.


ii. Export Details File – writes a file to the IT Assistant root installation directory. This file is typically meant for Dell support personnel to better help them diagnose the discovery progress, should the user have problems with discovery completing. Every time the Export Details File button is clicked, the file will be added to. The file can be started over by deleting it. While most of the information in this file is the same as with Request Details above, some additional information is provided. The columns are as follows:

1. Node – the same as Managed System above. 2. Range – the same as Discovery Range above. 3. TaskID – The discovery-assigned unique ID of the running task. 4. ThreadID – The operating system-assigned thread ID for the task. 5. Time – the same as Execution Time above. 6. CheckPoint – Where the task is at in its processing.


6.0 The Protocols Discovery Uses When IT Assistant communicates with a managed system, it uses one or more of three industry standard protocols – SNMP, DMI, or CIM - to communicate with the agent technology installed. During each discovery cycle, a process is used to detect which protocols the managed system under discovery is configured to use. It does this by querying a standard piece of information from the system for each protocol enabled in the discovery range. If a response to the query is received for a particular protocol, that information is stored and used for subsequent communications. After protocol detection is done, discovery will use this protocol information when initiating communication with the system’s agents to pull inventory, asset, and other management data. Various Dell agents communicate with ITA and other management applications through various protocols. For communication to be successful, several conditions need to be right, including correct setup of the protocol at both ends (ITA and the managed system), along with the possible configuration of routers in between to allow the communication to occur. See Table 2 for the protocols Dell agents support. Each protocol that ITA uses will be discussed in more depth below.

Dell Instrumentation Supports DMI Supports SNMP Supports CIM Dell Hardware Instrumentation Package (HIP) v3.x Yes* Yes1 No

Dell OpenManage Server Agent (OMSA) v4.0 – 4.3 Yes2 Yes3,* Yes2,3,5

Dell OpenManage Server Agent (OMSA) v4.4 and later No Yes* Yes3,5

Dell OpenManage Server Administrator v1.x No Yes* Yes5

Dell OpenManage Client Instrumentation (OMCI) v5.x, v6.0

Yes No No

Dell OpenManage Client Instrumentation (OMCI) v6.1+ Yes* No Yes4

Dell OpenManage Client Instrumentation (OMCI) v7.x No No Yes

All Dell Remote Access devices (DRAC v2.x/v3.x, ERA) No Yes No

Dell OpenManage Array Manager (OMAM) Agent v2.x/v3.x

No Yes No

Table 2 – Dell Agent Protocol Support 1Via Intel DMI-to-SNMP Mapper, available only on Microsoft Windows NT. ITA v6.5 only supports HIP versions 3.5.x and above 2Microsoft Windows only 3Protocol support is optional at agent install time (for some versions) 4,5Events only supported through the 4DMI protocol or 5SNMP protocol. *Dell recommends using this protocol with this version of agent, given the agent supports more than one.

TIP: When configuring each discovery range, knowing what type of devices will be discovered on that range as well as the protocols that will be used to communicate with them allows you to optimize discovery by only enabling those protocols supported by the agents installed on the managed systems.


For each protocol disabled, discovery time for that range will be reduced. The time taken for a request-response cycle to complete is generally the longest for the CIM protocol, followed by DMI, with SNMP being the fastest.

TIP: Not all agents are created (or programmed) equally when it comes to exposing features or data to ITA. In Table 2, for those agents that support multiple protocols, the recommended protocol is marked with a “*”. Once that protocol is enabled and configured correctly, ITA will automatically use it as the preferred protocol, even if more than one protocol is enabled and detected.

When a discovery cycle occurs, all protocol configuration data is read from the DiscoveryConfiguration table in the database – this is where the data is stored from protocol setup in the ITA UI. For each discovery range, discovery looks for what protocols to try and what parameters go along with these protocols; this information is used for each and every system discovered on that range. All system information is stored in the Node table, including what protocols that system supports – this information is stored as a number in the Protocols column. To know what protocols a system supports, just use the ITA database utility, dcdbmng.exe, to look the Protocols column up in the Node table and reference the following:

System supports SNMP: Protocols = 1

System supports DMI: Protocols = 2

System supports CIM: Protocols = 4

Managed Systems may support a combination of protocols: add the above numbers until a combination is found that equals the number in the Protocols column. Examples: 5 = 1(SNMP) + 4(CIM) or 3 = 1(SNMP) + 2(DMI).

Note that no previous detection is considered each time discovery occurs. So, for example, if for some reason the SNMP master agent on a remote system goes down during a discovery round, or the community name changed for that system to where ITA no longer was using the correct community name for that system, discovery would change the protocols fields for that system to reflect the absence of SNMP support.

6.1 SNMP Protocol The Simple Network Management (SNMP) protocol is by far the most prevalent protocol used by agents that reside on Dell devices. For those agents that are not mentioned in Table 2 above, such as PowerConnect™ switches, digital KVM devices, and various storage agents, SNMP is the predominate protocol used. Over the years, there have been several versions of SNMP released, such as SNMPv1, SNMPv2c, SNMPv2u, and SNMPv3, although SNMPv1/v2c are used on the majority of devices managed by Dell. Some devices can support multiple versions of SNMP. SNMP uses the protocol UDP/IP, where UDP datagrams are sent over the wire in the form of a request-response cycle or via alerts in the way of traps. SNMP is designed as a connectionless protocol, where no formal “handshaking” is done to establish a connection up front before data is exchanged. IT Assistant supports SNMPv1 and SNMPv2c for retrieving data and SNMPv1 for receiving traps. For SNMP to work correctly, the necessary configuration is shown in Table 3.

SNMP Protocol Overview Transport UDP/IP


Connection Type Connection-less Typical Ports Used 161 (data), 162 (traps) Variations SNMPv1, SNMPv2c, SNMPv2u, and SNMPv3. The most prominent are

SNMPv1 and SNMPv2c (also known as just SNMPv2). Security SNMPv1, SNMPv2c = community names; SNMPv3 = strong authentication

(username/password). For Dell server agents, such as Dell OMSA, instrumentation username/password is required on top of community name for SNMP sets to occur; data for sets is encrypted.

Metadata format MIB (Management of Information Base) Data Organization Relational-based (Tables/Rows) How Data is Provided Typically, the master SNMP agent on the managed system is listening on

port 161. Sub-agents (such as Dell OMSA) hook into the master agent. The master agent passes requests from the management console (such as ITA) to the appropriate sub agent depending on the request (which SNMP OID) made; the sub-agent then processes the request and sends data back.

How Events are Sent ITA hooks into the Trap Listening Service, which typically listens on port 162. Sub-agents (such as Dell OMSA) send out traps via the master agent, which is configured with the trap destination(s) (such as where ITA services reside), and then the master agent sends the trap to port 162 on all registered destinations.

Configuration Considerations

(1) For SNMP data (request/response), community name must be configured as the same (community name is case sensitive) both in ITA and the SNMP agent on the managed system. For some SNMP master agents, it is necessary to assure packets are accepted from the system on which ITA services reside. (2) For events (traps), it is necessary to configure community name and destination in managed system’s SNMP agent.

Community Names and Other SNMP Parameters For data to flow back and forth between ITA and the managed system, a common public “key” needs to be known between both. This key is known as a community name. Some may equate a community name with a password, but this is too strong of an analogy, due to community names being more “public” than passwords and due to the rare practice of equating them to a particular user account or machine. Typically, a few or one set of community names is used throughout a network – a set of community names consists of a read community name and a write community name. Although read and write names can be the same, this reduces what little security community names provide – if they are the same and someone needs the ability to read data, they also then have the ability to write data, opening up a hole for attack. It is always good practice to make the read community name different from the write community name and even use a mixture of upper and lower case since community names are case sensitive. Never, ever use the community name of “public” as this name is extremely well known and is akin to not having any community name. Fortunately, most modern operating services’ SNMP services do not assume any community name – they must be set up by the user. The number or sets of community names will greatly depend on how many network segments there are and how many different groups or people manage these segments; for a small network, one set will typically suffice. Since community names can be tedious to configure for a large group of systems, don’t count on changing them often. New to ITA v6.5 is the ability to auto-detect the correct community name from a comma-delimited list entered during setup.


First, discovery detects the read community name by going through the list of read community names, using (and storing) the first one found that works. This is enough for discovery to mark the system as supporting SNMP. Next, discovery goes through the list of write community names, using (and storing) the first one found that works. The standard SNMP variables used for reading/writing are mib2|system|sysObjectID and/or mib2|system|sysContact. Since failed SNMP read/write cycles slow discovery down, the list of community names to process should be kept to three or less for any IT Assistant discovery range. There is also the notion of community names for traps, but IT Assistant itself does not filter out any traps based on community name. SNMP has the notion of timeout and retry parameters, and the defaults provided in IT Assistant should suffice for most networks. For very slow networks, the values may need to be adjusted up. Even though doing a ping request to a remote system to find out the response time of a system over the network can help determine the network latency, the SNMP timeout parameter does not exactly equate to the ping timeout, nor does one setting affect the other in ITA. The SNMP timeout setting must also take into account the time it takes the agent to respond – some agents are faster than others. An SNMP test tool is more appropriate for testing request/response time when experiencing timeout problems with SNMP. Large timeout plus large retry values will have an impact on discovery should the network under discovery have a considerable number of systems that do not support SNMP since a timeout will occur with these systems. Also, keep in mind that a response may not be received from a remote system’s SNMP master agent should the community name not be recognized.

6.2 CIM Protocol The Common Information Model (CIM) protocol is prominent on Microsoft Windows systems. Using the term “CIM protocol” is actually somewhat of a misnomer, as CIM describes the way the data is organized, not necessarily the transport model used to transport the data. The two most prevalent transport methods are Windows Management Instrumentation (WMI) and CIM Operations over HTTP. As the name suggests, WMI is only available on Windows operating systems, while the latter transport model is prevalent on non-Microsoft operating systems. Currently, IT Assistant only supports data exchange through the WMI model, which is the older transport model of the two.

CIM Protocol Overview Transport TCP/IP (WMI uses DCOM, which uses RPC-based communication, which is

typically TCP/IP-based). Connection Type Connection-oriented Ports Used Varies for WMI, but range can typically be restricted through operating

system configuration. These ports are related to RPC. For more information on configuring ports for use with WMI, see the Microsoft COM Whitepaper Using Distributed COM with Firewalls, available from www.microsoft.com.

Variations Typically two data transport methodologies: (1) WMI (Windows Management Instrumentation) on Windows, which uses DCOM for data exchange over the network and (2) CIM Operations over HTTP, which uses the HTTP(S) protocol for data exchange over the network.

Security Username/password. WMI typically uses domain-based authentication. Encryption is provided by Microsoft.

Metadata format MOF (Managed Object Format) Data Organization Object-based (Classes/Objects)


How Data is Provided For WMI, the supported method of CIM data transport in ITA, typically the WMI service on the managed system waits for a connection on a port. The WMI service is also known as a CIM Object Manager (or CIMOM) in CIM terminology. Providers (such as Dell OMSA) hook into the CIMOM; requests from a management application (such as ITA) over the network are forwarded from the CIMOM to the appropriate provider depending on the request (which CIM namespace) made; the provider then processes the request and sends data back.

How Events are Sent For those agents (or providers) that support CIM indications, ITA automatically registers as a temporary event consumer to receive those indications.


(1) For CIM data and events between ITA and the managed system, the proper authentication credentials (username/password) need to be passed.

Using CIM and CIM Parameters Using CIM in the Windows context (or WMI) involves domain authentication for security. If IT Assistant is installed using the express install option, then CIM is not activated by default. It can be activated in one of two ways. The first option is to activate by using the custom install option and specifying the username and password (and optionally the domain) that IT Assistant services are to run as. The second option is, after installing ITA, run the ITA utility configservices.exe to enable CIM and enter the username and password (and optionally the domain) that ITA services will run as. The username/password is typically a domain administrator’s account if the systems are part of a domain; if not part of a domain, it can be the credentials for an administrator account on the remote system. In the latter case qualifying the username with the localhost specifier is advised (as in “localhost\username”). TIP: ITA stores CIM credentials in its database using Microsoft encryption. The encryption algorithm used is not the same between Windows NT/2000 and Windows XP/2003. If upgrading the operating system from one group to the other (for example: Windows 2000 -> Windows 2003), it is recommended to uninstall and re-install IT Assistant and reconfigure its discovery ranges, otherwise discovery of the CIM protocol will not work. In addition, exporting the configuration data from an ITA installation in one OS group to another ITA installation in a different OS group will not work when using CIM. TIP: If you have more than a few discovery ranges and must change domain credentials fairly often, using the importnodelist utility in ITA can make this effort much easier by defining a template with the changed credentials and re-importing all discovery ranges. For more information, see the Importing Systems for Discovery section later in this document. For those networks where excessive logins can cause an account to be disabled, it is important to make sure IT Assistant has the correct credentials for the account being used. Also, for those networks that have different credentials for different subnets, it is important that these discovery ranges are set up independently and do not overlap so that authentication works properly.

6.3 DMI Protocol The Distributed Management Interface (DMI) protocol is prevalent among older Dell agents, but is being phased out as a supported protocol. ITA v6.5 will be the last release to support the DMI protocol. There are two main RPC types for DMI: (1) Distributed Computing Environment (DCE) for Windows–based


systems and (2) Open Network Computing (ONC) for Novell Netware–based systems. When setting up discovery ranges in ITA v6.5, it is important to specify which RPC type to use.

DMI Protocol Overview Transport TCP/IP Connection Type Connection-oriented Ports Used Varies, but range can typically be restricted through operating system

configuration. These ports are related to RPC. Variations Two Remote Procedure Call (RPC) types – Distributed Computing

Environment (DCE) on Microsoft Windows-based systems and Open Network Computing (ONC) on Novell Netware and UNIX-based systems.

Security No authentication required. For Dell server agents, such as Dell OMSA, instrumentation username/password required for DMI sets to occur; data for sets is encrypted. For Dell client agents (OMCI), BIOS password required for DMI sets to occur.

Metadata format MIF (Management Information Format) Data Organization Relational-based (Groups/Rows) How Data is Provided The DMI service layer is listening on a port on the managed system.

Providers, also known as components (such as Dell OMSA) hook into the service layer. The service layer passes requests from the management console (such as ITA) to the appropriate provider depending on the request (which DMI component) made, and then the provider processes the request and sends data back.

How Events are Sent ITA registers (subscribes) with the remote service layer to receive DMI indications. The managed system’s service layer sends alerts back to ITA via RPC calls to the ITA management station.


Select the DCE RPC type for Windows–based systems and the ONC RPC type for Netware–based systems.


7.0 The Discovery Process In-Depth The Network Monitoring Service in IT Assistant v6.5 has a very task-oriented architecture. For discovery, there are two basic types of tasks that run: (1) ping discovery tasks, which represent discovery ranges, and (2) system discovery tasks, which represent the discovery of individual systems. When a scheduled (or force) discovery is initiated, a ping discovery task is spawned for each discovery range configured (or selected); each of these tasks is run in an operating system thread, making the discovery process a multi-threaded process. In each ping discovery task, every IP that is part of that range is pinged; for those systems that respond, a separate task is queued to run in a separate thread – a system discovery task. The system discovery task performs a more intimate discovery of the system, including protocol detection and inventory of the system. See figures 5, 6, and 7 for a more in-depth look at the discovery process.

Figure 5 – Overview of Ping Discovery Task


For Figure 5 above, the Roman numerals correspond with the more detailed explanations below:

I. Expand discovery range – For a single IP address, the range consists of one IP; for a discovery range that can be expanded (the range contains one or more “*” and/or “-“ characters), expand to all possible valid IP addresses in the range, and for a system name, resolve the name to one or more IP addresses using DNS.

II. Start loop – for each IP in discovery range – Loop through all IP addresses that were a result of the expansion in I. If the IP is in the list of exclusion ranges, ignore it and continue, otherwise try to ping it and wait for a response.

III. Show system as down status if no other IP responds - Send system down trap and cross-reference the IP address back to the Node table in the database. If a system entry is found, pull its IP addresses that are marked as “pingable” and ping each one until one responds. If no IP responds, show the system status as down. Send out a system down trap for the system if its power status has changed from what is stored in the database. An IP address is marked as pingable if it is part of an IP range that discovery has explicitly been configured to discover – other IP addresses that are returned for the system (from one of the supported protocols) that are not explicitly part of an ITA discovery range are marked as not pingable. Discovery does not try to ping or use these addresses (only report them), although they may be reachable.

IV. Queue system discovery task to run - If a system responds to the ping, create a system discovery task object for that system and queue it to run. Both ping discovery tasks and system discovery tasks can (and usually do) run at the same time. There are a limited number of thread slots for tasks to run – when one task ends, another one is started to fill that thread slot.


Figure 6 – Overview of System Discovery Task – Part 1


I. Get IP address to discover – Retrieve the IP address that the ping discovery task allocated to this system discovery task. The system discovery task performs a more intimate discovery of the system.

II. Check for supported protocols – Check for the standard protocols that ITA supports – SNMP, CIM, or DMI. For those protocols that are valid, store protocol configuration information for later use.

III. Attempt connection to Dell instrumentation – If the system supports any protocols, ITA will attempt to connect to the various Dell instrumentation that supports those protocols in preparation to pull inventory and other discovery data.

IV. Attempt to resolve name via instrumentation – If the user selected instrumentation as the preferred method of name resolution, use Dell instrumentation to get the name, which is typically not qualified with a domain (in contrast with the name returned by DNS, which is


typically domain qualified). Every time discovery determines a name, it must check the exclusion list to assure it should continue to discover the system.

Figure 7 – Overview of System Discovery Task – Part 2


V. Retrieve system inventory and capabilities – retrieve the basic inventory for the system, which gets stored in the Node table. Capabilities include what management capabilities the system supports, such as shutdown, flash BIOS, etc.

VI. Retrieve system’s other IP addresses – Using the protocol supported by the remote instrumentation/agent, retrieve the other IP addresses that are configured for the system. Mark these addresses as not pingable, which means that discovery will not try to ping these


addresses to determine system up/down status. In the case where the system is discovered on multiple discovery ranges, discovery will detect this and mark all appropriate IP addresses as pingable.

VII. Classify system – determine the classification of the system based on the instrumentation/agents that respond to ITA.

VIII. Calculate global status of system – Query the main Dell agents for their global statuses and take the worst-case status as the system’s status in ITA. For example, for servers, DRAC, Array Manager, and OMSA all figure into the global status of the system. If the agent is not detected or does not respond, its global status is not considered.

IX. Calculate if system is part of a modular system – If the agent returns modular chassis–related data, it is considered part of a modular system. A grouping attribute, the chassis service tag in most cases is used to create a chassis group in ITA and place all discovered components under this group. Components include blades, switches, and ERAs.

X. Calculate if system is part of a cluster – If cluster information is exposed by the agent, a cluster group is created in ITA and all systems that are members of that cluster are grouped under it.

XI. Attempt to resolve name via DNS – If the user selected DNS as the preferred method of name resolution, use a DNS server to get the name, which is typically qualified with a domain (in contrast with the name returned by instrumentation, which is typically not domain qualified). Every time discovery determines a name, it must check the exclusion list to assure it should continue to discover the system.

XII. Delete duplicate systems from database – new to ITA v6.5, discovery will detect, based on MAC addresses, if the system being discovered is known by a different name in the database and delete that other system from the database so that the current system’s information can be inserted into the database.

XIII. Insert/update NIC, Node table data – Put the system’s inventory, capabilities, IP addresses, MAC addresses, and other discovery data into the database. Also, store system’s global health status, as well as connectivity/power status. Send out a system up trap if the system’s power status has changed from what is in the database (assuming the system was previously discovered).

XIV. Store offline summary information – Retrieve data from the agent(s) and store it in the OfflineSummary table.

XV. Update group membership if cluster or modular system – If the system is part of a modular chassis or cluster (as determined in steps IX. and X.), update database with this information.


8.0 The Status Poll Process In-Depth As mentioned in the previous section, the discovery service in IT Assistant v6.5 has a very task-oriented architecture. For status polling, there is one basic type of task that runs: the status task, which performs a power/connectivity/health check for an individual discovered system; each of these tasks is run in an operating system thread, making the status process a multi-threaded process. Another way a status poll task may be kicked-off is when IT Assistant receives an event from a managed system. See Figure 8 for a more in-depth look at the discovery process.

Figure 8 – Overview of System Status Task


I. Get pingable IP addresses for system – to determine if the system is up/down or connectivity is good/bad, pinging of a system will only be done on its pingable IP addresses. Although IT


Assistant may have retrieved several IP addresses for the system during discovery, it only uses those that were actually part of a discovery range in ITA; these addresses are called “pingable.” IP addresses for a system are not updated during a status poll.

II. Go through list of IP addresses – For all pingable IP addresses, try to ping each one, waiting for a response from the system. Stop at the first IP that responds. For a system to be up in ITA, only one address need respond to ITA.

III. System is down, status unchanged – Record the system as down in ITA, keeping the system’s health status as the last known status (the status recorded when the system was last up).

IV. Attempt connection to instrumentation – Using the protocols known to be supported by the remote system, attempt a connection to instrumentation through one or more of those protocols in preparation to pull the global status.

V. Send system down trap if change in up/down status – If the power/connectivity status has changed from the last recorded status (both discovery and status will record this status for the system), send a down trap if the status transition is from up to down. System up/down traps are only sent on a transition in status, not during each poll.

VI. System is up with unknown status – If a failure to connect to Dell instrumentation happens, the global health status for that system is unknown.

VII. System is up with known status - Query the main Dell instrumentation/agents for their global statuses and take the worst-case status as the system’s status in ITA. For example, for servers, DRAC, Array Manager, and OMSA all figure into the global status of the system. If the agent is not detected or does not respond, its global status is not considered. A system can have a status, but be unclassified because the OMSA/OMCI agent is required for classification of the system, while other agents provide just a status to ITA.

VIII. Send system up trap if change in up/down status – If the power/connectivity status has changed from the last recorded status (both discovery and status will record this status for the system), send an up trap if the status transition is from down to up. System up/down traps are only sent on a transition in status, not during each poll.

IX. Write system status to database – If the power/connectivity and/or global health status of the system have changed from what was previously recorded, update the database with the new statuses.


9.0 Discovery Options The most common discovery options are exposed through the User Interface. However, there is sometimes the need to customize discovery further than this due to the uniqueness of the network ITA is discovering, to debug apparent discovery problems (such as discovering a particular system) that are exposed because of the network environment, or to take advantage of a unique configuration that IT Assistant allows.

Note that all configuration options mentioned below are in the dconfig.ini file located in IT Assistant’s configuration directory; it is recommended to have some familiarity with the format of ini files. During an upgrade or re-install, any special changes made to the configuration file are not saved, so it is recommended to back up those ini sections that were changed to a separate file and restore them upon an upgrade or re-install. It is not recommended to replace the whole file on an upgrade due to the likelihood that other sections on the configuration file were changed. Some options mentioned below are already in the configuration file with defaults specified and some options may not yet be in the file. For the latter, be careful to add the key specified to the right ini section for it to work. All ini sections mentioned below are already in the dconfig.ini file. Use these sections and do not create new sections with the same name. In addition, make sure the key does not already exist before adding it (perform a search on the key).

Any configuration file change requires ITA services to be restarted. The format of each option will be presented as follows:

Short Description A short description of what the configuration key provides.

Section What section in the dconfig.ini file the key resides in.

Key The name of the key for the setting.

Default Value The default value, either already specified in the configuration file or in the code, if not in the configuration file.

Suggested Values The suggested values for the setting.

Long Description A more in-depth explanation of the setting.

In the dconfig.ini file, an example for this would be:

[Section]

Key=Default Value


Services options:

Short Description Ping timeout.

Section [INET_PARAM]

Key PING_TIMEOUT

Default Value 400ms

Suggested Values A number, in milliseconds, greater than 300ms but less than 5000ms.

Long Description The amount of time, in milliseconds, that ITA will wait for a response to a ping request. Used by status polling, discovery, and by the Connection service.

Short Description Ping retries.


Key PING_RETRIES

Default Value 1

Suggested Values A number greater than 0 but less than 5.

Long Description The number of times ITA will retry a ping request when a ping timeout occurs (no response). Used by status polling, discovery, and by the Connection service.

Short Description Name resolution retries.


Key RESOLVE_RETRIES

Default Value 1

Suggested Values A number greater than 0 but less than 5.

Long Description The number of times ITA will re-attempt an IP->Name or Name->IP resolution by asking the DNS server. Used by discovery and by the Connection service.

Short Description Turn off event management system.

Section [EVENT_MANAGEMENT_CONFIG]

Key DISABLE_EVENT_MANAGEMENT

Default Value 0 (EMS on)

Suggested Values 0 (EMS on) or 1 (EMS off)


Long Description If using ITA for discovery and statusing of systems only, and not for receiving or processing events, the EMS can be turned off via this setting. Note that if the EMS is turned off, no events will be received by IT Assistant and subsequently, no event actions will be performed.

Short Description Don’t abort next discovery round if one or more discovery ranges is not finished.

Section [DISCOVERY_PARAM]

Key ONE_RUNNING_DISCOVERY_ABORTS_ALL

Default Value 1 (on – next discovery is aborted)

Suggested Values 1 (on) or 0 (next discovery is not aborted)

Long Description Normally, if the next discovery round that is scheduled is to be executed, but one or more discovery ranges are not finished by this time, the discovery round that is scheduled will be aborted, and this will keep occurring until all ranges are finished. This is meant to be a self-regulation feature to avoid discovery running all the time should the interval be set too small for the network under discovery. This feature can be adjusted (set to 0) so that the next discovery round is not aborted if a discovery range is not finished; however, only those discovery ranges that are complete at the time are allowed to undergo discovery again – any range still under discovery will not be restarted.

Short Description Specify if discovery or status tasks can be terminated after a given time.


Key TASKS_ARE_KILLABLE

Default Value 0 (off)

Suggested Values 0 (off) or 1(on)

Long Description Should the RPC-based protocols such as DMI and CIM that ITA uses not respond in an expected amount of time, the data request call discovery makes to the lower APIs it uses may never return due to there not being a timeout parameter available. Previous versions of IT Assistant would kill the communication thread after a given period of time, usually several minutes, so that discovery/status threads were not left around and the cycle could complete. However, this type of thread termination can make the discovery service unstable and prone to crashing. For this reason, thread termination is turned off by default. Typically, upgrading to the latest version of agents will resolve any potential lockups, but


this setting can be enabled to assure that a discovery round/status poll round always completes. Be aware that should this setting be enabled, those systems causing discovery to not complete may not have accurate representation or status in IT Assistant.

Short Description Ping discovery task execution time.


Key PING_DISCOVERY_TASK_DURATION

Default Value 600 seconds (10 minutes)

Suggested Values A value greater than 600 seconds, should network conditions require it. Values should be specified in seconds.

Long Description This setting is only applicable if the setting, TASKS_ARE_KILLABLE = 1, is enabled. This setting, in seconds, is the maximum amount of time a ping discovery task (or thread) is allowed to live. The ping discovery task is the task that runs for each discovery range, executing in a loop, pinging each IP in the range. The default value should not need to be adjusted up because the task automatically increments its own allotted time each round through the loop.

Short Description System discovery task execution time.


Key SYSTEM_DISCOVERY_TASK_DURATION



Long Description This setting is only applicable if the setting, TASKS_ARE_KILLABLE = 1, is enabled. This setting, in seconds, is the maximum amount of time a system discovery task (or thread) is allowed to live. The system discovery task is a task that runs for a discovered system, pulling inventory and status for that system and other functions. A system discovery task is spawned by the ping discovery task for each IP that returns a response to the ping discovery task; a system discovery task talks to exactly one system during its lifetime. Should discovery be operating in a slow network environment, this value may need to be increased.

Short Description Status task execution time.



Key STATUS_TASK_DURATION



Long Description This setting is only applicable if the setting, TASKS_ARE_KILLABLE = 1, is enabled. This setting, in seconds, is the maximum amount of time a status task (or thread) is allowed to live. The status task is a task that runs for each already discovered system, performing a ping and health check for that system. A status task is spawned for each discovered system (each entry in the Node table in the DB); a status task talks to exactly one system during its lifetime. Should IT Assistant be operating in a slow network environment, this value may need to be increased.

Short Description Maximum status polling threads.


Key NUM_STATUS_THREADS

Default Value 32

Suggested Values A number greater than or equal to 16.

Long Description The maximum number of threads that can simultaneously execute for status polling when the status throttle is set at 100%. Since reducing the throttle can reduce the number of threads that execute, the default value should only be adjusted when increasing the number of threads.

Short Description Maximum discovery threads.


Key NUM_DISCOVERY_THREADS

Default Value 32

Suggested Values A number greater than or equal to 16.

Long Description The maximum number of threads that can simultaneously execute for discovery when the discovery throttle is set at 100%. Since reducing the throttle can reduce the number of threads that execute, the default value should only be adjusted when increasing the number of threads.


Short Description Retrieve offline summary for a system.


Key RETRIEVE_OFFLINE_SUMMARY

Default Value 1 (on)

Suggested Values 1 (on) or 0 (off)

Long Description When this setting is on, IT Assistant pulls all information for the summary page for a system during discovery of that system so that the summary page can be viewed when IT Assistant shows the system as down. For very slow networks, this extra amount of data requested can cause a sizeable delay for a discovery round to finish. Should the user not need to view this data when the system is down, this function can be turned off. Note that the summary page will be blank when the system is down in this case.

Short Description Try multiple DMI RPC types.


Key TRY_MULTIPLE_DMI_RPCS

Default Value 0

Suggested Values 0 (off) or 1 (on)

Long Description Before IT Assistant v6.5, this option was set to 1 by default to accommodate discovery of both Novell Netware-based systems, which use the ONC RPC type, and Microsoft Windows-based systems, which use the DCE RPC type. However, due to older DMI agents on UNIX-based systems, which use the ONC RPC type, and return garbled data that can cause the discovery service to crash, this is now set to 0 by default. This should only set back to 1 if discovering both Netware- and Windows-based systems on the same discovery range.

Short Description Eliminate duplicate names.


Key ELIMINATE_DUPLICATE_NAMES

Default Value 1


Long Description IT Assistant v6.5 has the option of eliminating duplicate names (or duplicate system entries in the UI) by using the MAC address(es) of the computer to uniquely identify the computer in the ITA system tree. Duplicate entries occur when DNS returns a different name for


the system than before or DNS/Instrumentation fails to return a name when it is the primary means for name resolution. Certain MAC addresses or IP addresses that map to certain MAC addresses are prevalent on many devices. These addresses cannot be used to distinguish a system, and the setting of DUPLICATE_NAME_EXCLUDE_LIST contains this list of exclusions. Should it be suspected that some systems are not showing up as being discovered because they are mistaken as being the same system (the last discovered system will replace anything before it), this function can be disabled temporarily via this setting (set to 0) so that it can be determined which MAC address is common among the systems being discovered and excluded. Once the affected systems are discovered, check IT Assistant’s inventory view to see the MAC addresses for those systems and enter them into the exclusion list.

Short Description Eliminate duplicate names MAC/IP exclusion list.


Key DUPLICATE_NAME_EXCLUDE_LIST

Default Value 127.0.0.1,0.0.0.0,005345000000,33506F453030,505054503030

Suggested Values Add to default values as determined by your network.

Long Description ITA v6.5 has the option of eliminating duplicate names (or duplicate system entries in the UI) by using the MAC address(es) of the computer to uniquely identify the computer? in the system tree. Duplicate entries occur when DNS returns a different name for the system than before or DNS/Instrumentation fails to return a name when it is the primary means for name resolution. Certain MAC addresses or IP addresses that map to certain MAC addresses are prevalent on many devices. These addresses cannot be used to distinguish a system, and this setting contains this list of exclusions. Should it be suspected that some systems are not showing up as being discovered because they are mistaken as being the same system (the last discovered system will replace anything before it), this function can be disabled temporarily via the ELIMINATE_DUPLICATE_NAMES setting (set to 0) so that it can be determined which MAC address is common among the systems being discovered and excluded. Once the affected systems are discovered, check IT Assistant’s inventory view to see the MAC addresses for those systems and enter them into the exclusion list.

Short Description Keep history for all discovery rounds.



Key KEEP_DISCOVERY_HISTORY

Default Value 0 (off)


Long Description Normally, upon each discovery round, the feedback data for each discovery range is overwritten over the last round. To keep this from occurring (no overwrite) and to keep every record of when discovery runs, this setting can be set to 1. Note that discovery records are still cleaned out upon services start. Should each discovery range be an individual system, it is not recommended to enable this. Note that the more records stored, the slower the response in the discovery feedback view.


10.0 Importing Systems for Discovery New to ITA v6.5 is a utility that will allow the user to import a list of nodes (or systems) for discovery. The user may wish to do this for several reasons:

• The user has a list of systems exported from another software program that he/she works with and wants to import this list of systems into ITA.

• The user wants a very targeted discovery of many systems, but does not want the effort of entering each and every system into ITA through the UI. In addition, the user wants a way to easily update the ITA settings for every one of these imported systems.

• The user wants to maintain a list of systems to discover separately from ITA and import them when needed.

Making each system its own discovery range, which is what this utility does, can be appealing for some, but note that the discovery feedback view will become more and more sluggish as the number of discovery ranges increase. When working with around 1,000 or more discovery ranges the user can expect higher response times for user commands to or refreshes from the discovery feedback view.

The name of the utility is importnodelist.exe and is located in IT Assistant’s bin directory. Note that this utility only works with IT Assistant v6.5 and above. The utility takes as an argument a file containing one or more lines, each line being an IP address, a nodename, or even a discovery range (discovery ranges can also be imported using the utility). The utility adds these entries to the DiscoveryConfiguration table in the IT Assistant database – just as the UI does if the user configures a range through it. Examples of simple import files are:

Example A:

<begin_file> #This is a comment (a "#" sign at the beginning of the line means to ignore the line). 23.45.65.34 23.45.65.35 hostname1 hostname2 23.34.55.* 12.34.56.20-30 <end_file> The <begin_file> and <end_file> markers are not needed and should not be in the file – they are here for illustration purposes. However, a blank line (as shown) is needed at the end of the file – be sure to include this. Optionally, a template can be entered after the discovery range to be imported as in the next example (note the comma delimiter): Example B: <begin_file> #This is a comment (a "#" sign at the beginning of the line means to ignore the line). 23.45.65.34,template1 23.45.65.35,template1 hostname1


hostname2,template2 23.34.55.*,template2 12.34.56.20-30 <end_file> For each entry in the file, IT Assistant needs to know what discovery settings to apply to it (just as these settings are adjustable for each discovery range entered through the UI and are stored with that range), and a template is used to provide this information. A template is no more than a discovery range used for a special purpose: to provide protocol settings for one or more discovery ranges in the file to be imported. Templates are to be entered through the UI just as a discovery range would be, however the name of the discovery range should be unique to indicate it is to be used as a template. When specifying template names, use the guidelines:

• Use the name default_template for the discovery range name (entered in the hostname field in the dialog) for a file such as example A above – the utility will automatically know that a discovery range with the name of default_template is to be applied to those entries without a template name after them.

• When a template name is specified in the file, as in example B above, any name other than default_template can be used. It is suggested to use a name that is unique enough to identify the entry as a template. For example: template1, template_1, template_a, etc.

Because multiple discovery ranges in a file may have different protocol settings, it is allowed to specify multiple templates in a file. As example B points out, an entry does not need to have a template specified, even if surrounded by other entries that do – the entry without a template will use the template (or discovery range) entered as default_template. When entering these templates via the UI, they too are stored in the DiscoveryConfiguration table with all other discovery ranges. There is an option (provided below) to delete these templates after a successful import of the file, but templates can be left with no adverse effects. After importing the templates, but before running the importnodelist utility, the templates can be backed up by exporting the DiscoveryConfiguration table using IT Assistant’s database management utility, dcdbmng.exe. Sample importnodelist.exe commands and their explanations: importnodelist nodelist.txt #Import the nodes from the file "nodelist.txt" importnodelist nodelist.txt -delete #Import the nodes from the file "nodelist.txt". #Delete the templates used after successful import. importnodelist nodelist.txt -delete -default my_template #Import the nodes from the file "nodelist.txt". #Delete the templates used after successful import. #The default template name to use is "my_template".

Note that parameters for discovery ranges that were imported via this utility can be updated en masse by simply changing the template(s) parameters and running the import utility again – the old settings will be overwritten.


Example scenario: Tom has a list of systems he wishes to import into IT Assistant for discovery. Since all systems share the same protocol settings, Tom does not need to specify template names after any of the systems. Tom’s file, tomsnodelist.txt, looks something like:

<begin_file> # Tom’s list of nodes. Tomserver1 Tomserver2 Tomserver3 : : Tomserver500

<end_file> Next, Tom needs to define a default template in ITA to apply to these systems. Tom follows the following steps:

1) Tom selects Options->Set Discovery Range from the left navigation menu in the ITA UI, and then selects Add…

2) Tom selects Hostname under Discovery Range, and then enters the name of default_template.

3) Tom adjusts the protocol settings to his network, and then presses OK. 4) Tom executes the following command: importnodelist tomsnodelist.txt to import the list of

systems. 5) Tom adjusts his discovery interval for the systems just entered by selecting Options-

>Discovery Cycle from the left navigation menu.


11.0 Discovery FAQs and Other Trouble-shooting Tips

This section is meant to answer (or instruct how to troubleshoot) some common problems users see in IT Assistant, related to discovery. Note that some of the FAQs addressed here are similar to ones found in the IT Assistant Reference Guide; however, more advanced troubleshooting techniques are presented for diagnosing the issue.

1. According to the Discovery Feedback View, I have discovery cycles that never complete or take a long time to complete.

When examining this problem, bring up the dialog Discovery Feedback->Discovery Cycle Log->Discovery Details->Request Details and consider the following:

a) The discovery range includes a large number of IP addresses. For example, the range of 192.168.*.* includes over 65,000 addresses to ping! If you see a discovery type of IP Address Discovery taking two or more hours to complete, this is a sign that your discovery range is too large and either needs to be narrowed or broken up into smaller discovery ranges. While entering large ranges is easy for a complete sweep of the network with minimal setup, it can cause ITA to expend unneeded resources and time trying to discover systems that are not on the network.

b) Due to the DMI/CIM protocols not having timeouts like SNMP, some older Dell agents that use the DMI/CIM protocols for communication may cause discovery of these systems to hang. Should a System Discovery task take one or more hours to complete, consider these possibilities:

i. Is the system on a slow or remote network? If so, it would be best to isolate it to a separate discovery range and set the configuration parameter: ONE_RUNNING_DISCOVERY_ABORTS_ALL=0 (see Discovery Options earlier in this article for more information).

ii. Is the CIM protocol causing the discovery hang to occur? If this is the case, then either the CIM protocol should not be used for that system, or the agent should be upgraded. One telltale sign of a problem with CIM is to export the discovery details file (see section 5.3.3 – Discovery Feedback earlier in this article for information on how to do this), then look at the Checkpoint field (the fields are delimited by a “|” character, which means this file can be imported into software such as Microsoft Excel). If the field ends at “K(CIM check begin),” this is an indication that the CIM protocol is hanging the discovery thread. The discovery of this system should be moved to a discovery range that does not use the CIM protocol (other protocols may need to be set up in this case), or if the agent does not support any other protocol, it is advised to upgrade the agent to the latest version released by Dell for that system. Server systems running a Server Agent older than OpenManage Server Agent (OMSA) v4.5 or Server Administrator v1.0 are strongly advised to upgrade the agent due to problems with WMI and these older agents.


iii. Is the DMI protocol causing the discovery hang to occur? If this is the case, then either the DMI protocol should not be used for that system, or the agent should be upgraded. One telltale sign of a problem with DMI is to export the discovery details file, then look at the Checkpoint field. If the field ends at “G(DMI check begin),” this is an indication that the DMI protocol is hanging the discovery thread. The discovery of this system should be moved to a discovery range that does not use the DMI protocol (other protocols may need to be set up in this case), or if the agent does not support any other protocol, it is advised to upgrade the agent to the latest version released by Dell for that system.

If it is perceived that a hang has occurred, the IT Assistant Services will need to be restarted to clear the hang. If there are any doubts whether a hang is occurring, the discovery details file can be used to monitor a task’s progress. Clicking the Export Details button every 30 minutes or so will provide a snapshot in time of how the task is progressing, and if the Checkpoint field for the task has not progressed in 30 minutes to an hour, it is likely the task is hung.

2. My system shows that it is down in ITA, but I can ping it from the command line – what is wrong with ITA?

Several possible causes need to be considered:

i. Perhaps a status poll cycle has not run since the system came back up. Check the Discovery Feedback view to see when the last status poll was run. A status poll can be manually triggered by disabling, then re-enabling, status polling. This can be done from the Discovery Feedback view.

ii. The ping being performed on the command line is a different system than where IT Assistant Services reside. Make sure you are performing the ping from the system where the IT Assistant Services are installed.

iii. The ping timeout in IT Assistant needs to be increased. Refer to the PING_TIMEOUT parameter mentioned in this article for information on how to adjust this setting.

iv. The IP address being used by the ping command may not be a pingable IP address in IT Assistant. Even though discovery may retrieve a complete set of configured IP addresses from the remote system (it uses one of the supported protocols to do this), during a status poll it will only try to ping those addresses which are part of a configured discovery range in IT Assistant. If using IP ranges for discovery, this is easier to figure out; however, when using host names as the discovery ranges, it becomes tougher to determine. The best way to determine which IP addresses are considered pingable by IT Assistant is to use IT Assistant’s database management utility, dcdbmng.exe, to look at the IP addresses for a discovered system. Select the NIC table, then sort by the Nodename column, and compare the IP addresses marked as pingable (check the Pingable column) with the IP address returned by the ping command. If they are different, either (1) the problem with connectivity to the managed system via the IP address used by ITA needs to be resolved, or (2) a discovery range that includes the IP address that is responding needs to be created.

v. Perhaps the IP addresses used by IT Assistant to ping the remote system are stale. These addresses are only updated during discovery. Use the IT Assistant database


management utility, dcdbmng.exe, to see which addresses are being used to ping the system (look at the NIC table, sort by Nodename, then check the Pingable column). If the addresses are not the same as the address that the ping command uses, and discovery has not run for awhile, force a discovery of the discovery range (or ranges) that the system was discovered on. (Do not force a discovery of the system itself, for this may or may not update the IP addresses for the system.) If you are unsure which discovery ranges the system was discovered on, use the database management utility, go to the Node table, search for the system in question (on the Name column), then look at the NetDiscoveredOn column. In this column are the list of discovery ranges, separated by a pipe (‘|’) symbol. Wait for all forced ranges to complete, and then check the system status again.

vi. Another system received the IP address of the one that is in a down state. When discovery runs, it updates all IP addresses for a system. During this time, it looks for any other system that also has any of these addresses; for those other systems, their IP addresses which are the same are marked as not Pingable (check the Pingable column in the NIC table for this attribute). The assumption discovery makes is that no two systems can share the same IP address and discovery will have an accurate picture of the network (all IP addresses for all discovered systems updated) when it completes. In a DHCP environment, it is very possible for systems to exchange IP addresses, especially if they have been disconnected from the network or powered off for a while. If a system has gone down during a status poll and a discovery has recently ran, wait for the next status poll to run (after a completed discovery cycle) to see if this corrects the problem.

vii. The system that has gone down in IT Assistant is actually a duplicate entry. Although the new discovery service attempts to eliminate duplicate entries (you have a duplicate entry if you have the same system known by two different names – these names are usually similar) by using the MAC addresses of the system (a MAC address, assigned to the network interface of the system, uniquely identifies a system), it must use one of the supported protocols (SNMP/CIM/DMI) to retrieve the MAC addresses. If, during a discovery round, there is a problem so that the MAC addresses cannot be retrieved, this may result in a duplicate entry. Since there is the assumption (stated in vi. above) that no two systems can have the same IP address, one of the systems in the IT Assistant database (the one that is down) will likely not have any pingable addresses because another entry has the same address. If the down system is a duplicate entry of another system, this down system can be removed by deleting it, as it is likely discovery is no longer updating this entry. This can be verified by using the database management utility, selecting the Node table, then looking at the LastDiscoveredTime column for a system.

viii. Discovery may not be updating the system information in the database due to the system obtaining an IP address that is now out of the range of any configured discovery range in ITA. This is possible in a DHCP environment. Check the IP address return by the ping command against the discovery ranges configured in ITA to assure the system is within a discovery range.


3. My system shows that it is up in ITA, but I don’t get a response by pinging it from the command line – what is wrong with ITA?

Consider the possible causes:

i. A status poll or discovery cycle has not run recently. Check the Discovery Feedback view to see when status and/or discovery were last run. Force a discovery of the system to see if the status changes. If it does, perhaps the status and/or discovery interval needs to be shortened.

ii. Make sure that the ping command is being run on the system where ITA Services are running.

iii. The IP addresses being used by status polling are stale. It is important that discovery be run at regular intervals because it is discovery that updates the IP addresses for a system. To check the last time the system was discovered, use the database management utility, dcdbmng.exe, select the Node table, and then look at the LastDiscoveredTime column for a system. The IP addresses used by status polling for a system can be verified by going to the NIC table, sorting by the Nodename column, and then looking at the addresses that have a Pingable column marked with a “1”.

4. I initiated a force discovery of a system or discovery range, but do not see it in the Discovery Feedback view.

If a force discovery is initiated while the discovery service is already processing other regular/forced discoveries, it may take a small amount of time – up to several minutes, depending on how large your network is and how many systems are being discovered - for the force discovery request to show up in the feedback view. Feedback entries are only shown for discovery tasks that are currently running. If the task is queued to run, you will not see it right away. Issuing another force discovery of the range will not result in the range being processed faster (or showing up any sooner in the feedback view). Although force discoveries have a higher priority than regular discoveries, there still can be other regular/forced discovery requests ahead of them in the queue that are processed first. Note that performing a force discovery on a discovery range that is undergoing a regular discovery will result in the stopping of the regular discovery of that range to avoid using additional resources to discover the same range at the same time.

5. How do I know when a system was last discovered?

Unfortunately, the last discovered time of a system is not exposed through the UI at this time. However, it can be viewed in the database. To see the last discovered time of a system, use the database management utility, dcdbmng.exe, select the Node table, sort by the Name column, and then look at the LastDiscoveredTime column for the system wanted. There is also a LastStatusedTime column, but it is only updated when the system status (power or health) changes – not necessarily every time a status poll runs.

6. How often should I run discovery?

Since networks can be very diverse, this is a difficult question to answer. However, if systems to be discovered get their IP addresses through DHCP, then discovery should run at least as often as the


lease time for IP addresses on the network. Due to self-regulation, discovery cannot be scheduled so often that it becomes “backed-up.” Should discovery be scheduled to run again when the last discovery cycle was not complete (all non-forced discovery ranges at 100%), the next discovery cycle will be aborted and will not be attempted again until the next scheduled cycle after that (example: if discovery is scheduled to run every hour, but actually takes 2.5 hours to complete, then discovery will actually run every three hours). If a discovery (or status) cycle was aborted, an entry will be placed in the NT Event Log by IT Assistant Services. The event log entry also names the systems still undergoing a discovery when the abort occurred, so if a few systems are holding up another full discovery cycle, there may be ways to optimize communication to these systems to speed-up discovery (or exclude these systems from ITA if not needed).

7. How often should I run a status poll?

Since status poll cycles are processed much faster than discovery cycles, the status poll interval can be set at a fraction of the discovery interval. To get an idea of how long a status poll takes, observe the status poll progress in the Discovery Feedback view after all systems have been discovered. To find out the status of a system (if it went up or down, or critical) as soon as possible, then schedule the status interval at the low end of your estimation; otherwise, add some “padding” to the time if system/network resource utilization is a concern. Status polls cannot be scheduled so often that they become “backed up.” Should a status poll cycle be scheduled to run again when the last status poll cycle was not complete, the next status poll cycle will be aborted and will not be attempted again until the next scheduled cycle after that (example: if status is scheduled to run every 10 minutes, but actually takes 25 minutes to complete, then status polls will actually run every 30 minutes). If a status round was aborted, an entry will be placed in the NT Event Log by IT Assistant Services. The event log entry also names the systems still undergoing a status poll when the abort occurred, so if a few systems are holding up another status poll cycle, there may be ways to optimize communication to these systems to speed-up status polls (or exclude these systems from ITA if not needed). Non-scheduled status polls occur for a system when an event is received from that system; therefore, it is important that remote system events (such as traps) are sent to ITA so that it may keep the status of the system as up-to-date as possible.

8. My system has not been discovered by ITA.

Typically, if a system is not seen in its respective group (Servers, Clients, etc.), it is caused by one of several problems:

i. The issue may be that the managed system is not responding to a ping request. If discovering the system by IP address or IP range, make sure the system returns a response when pinged from the server running the IT Assistant Services. If discovering a system by name, make sure that the system’s name can be resolved to an IP address and that it returns a response by running the command ping –a <name> from the server running the IT Assistant Services. See the Configuring Discovery for a Specific Network section earlier in this article for more information.

ii. The ping timeout in IT Assistant needs to be increased. To adjust this setting, refer to the PING_TIMEOUT parameter mentioned in this article. Compare the round-trip response time from a command line ping of the system to IT Assistant’s timeout setting and adjust accordingly.


iii. The system name or IP address is part of an exclusion range. New to IT Assistant v6.5 is the concept of exclusion ranges to block out things ITA should not discover. They are handy to have, but can easily be forgotten after being configured.

iv. The system does not have Dell Instrumentation loaded or running, or ITA has difficulty in communicating with the Dell agent, and Discover only Dell Instrumented Systems is selected in the Discovery/Polling Cycle Configuration dialog. In this circumstance, the system responds, but would appear in the unclassified group. If the option Discover only Dell Instrumented Systems is selected in the Discovery/Polling Cycle Configuration dialog (accessible from Options->Discovery Cycle), then unclassified systems will not appear anywhere in ITA. If this option has been selected, it is suggested to temporarily select All Systems to be discovered, and then perform a force discovery to discover the system in question. If the system appears as unclassified again, go to FAQ #9 below for more troubleshooting information. If the system still does not show up in the unclassified group, restart IT Assistant Services and perform a forced discovery again.

9. My system shows up as unclassified in ITA.

Typically, if a system should be classified in IT Assistant (only systems running Dell agents are classified at this time), but is not, this indicates a failure to communicate to the remote Dell agent. Typically, one of several problems can cause this to happen:

i. The protocols are not being detected correctly. Using the database management utility, dcdbmng.exe, select the Node table, and then sort by Name, locating the system with the problem. Then, look at the protocols field for this system. Refer to the Protocols Discovery Uses section earlier in this article to learn how to interpret the Protocols column, how to configure a particular protocol, and how to find out what Dell agents support what protocols. If the protocol being used is SNMP, perhaps the SNMP timeout and/or retry values will need to be increased.

ii. A router is blocking the protocol needed or a firewall is blocking communication. Additional tools may be needed to determine this. The SNMP protocol is typically the most blocked protocol of the three (SNMP/CIM/DMI).

iii. The agent on the remote system is not installed, is not running, or is not configured correctly. Again, refer to the Protocols Discovery Uses section for more information.

10. My system shows up with a gray question mark in ITA, even though it is discovered and classified.

This usually indicates that at one time ITA was able to successfully communicate with the remote Dell agent, but now cannot, or the agent is in an unknown state. The answer to FAQ #9 should be used to troubleshoot this problem, as it is very similar.

11. I have duplicate system entries (same system – different name) in the ITA UI – why doesn’t ITA prevent this?

Although the new discovery service attempts to eliminate duplicate entries by using the MAC addresses of the system (a MAC address, assigned to the network interface of the system,


uniquely identifies a system), it must use one of the supported protocols (SNMP/CIM/DMI) to retrieve the MAC addresses for both system entries. If, during a discovery round, there is a problem so that the MAC addresses cannot be retrieved, this may result in a duplicate entry. Typically, if the MAC addresses show up for a system under Network Data section in the summary page for that system, then ITA can retrieve the MAC addresses during discovery. If communication to the managed system is only through DMI (see The Protocols Discovery Uses section earlier in this article to learn how to find out what protocols ITA is using for a particular system), the vendor’s NIC instrumentation (for example, Intel NIC Instrumentation for Intel network cards) must be loaded for ITA to retrieve the MAC addresses for that system. If there are duplicate system entries, typically one entry will eventually show as a down status, and this entry can be deleted because discovery is no longer updating it. Using the inventory view, you can determine what MAC addresses are stored for the system.

12. How do I enable the CIM protocol?

The CIM protocol can be enabled either through the custom setup option during installation, or using the ConfigServices.exe utility after installation.

13. What is the recommended way to partition discovery ranges?

Since networks can be very diverse, the answer to this question varies with your network. Some recommendations:

i. Configure discovery ranges that discover a maximum of around 250 systems for smaller networks and up to 500 systems per range for larger (several thousand systems) networks.

ii. Discovery should receive a response from a majority of the IP addresses it pings on a subnet. In other words, don’t configure a discovery range of 192.168.*.* for a relatively small network. If the discovery range would ping 500 addresses, at least 250 should respond. To do this, configure precise (or small) inclusion ranges, or larger inclusion ranges with exclusion ranges to block out ranges of IP addresses that are not used.

iii. For larger networks (several thousand systems), making each system a discovery range is not recommended. Although this is popular with some, it makes discovery feedback tougher to discern for this many discovery ranges and it makes protocol management difficult – see FAQs #14 and #15.

For more information on setting up discovery ranges, see the Configuring Discovery for a Specific Network section earlier in this article.

14. I imported a list of host names to be discovered – why do I experience sluggish performance in the Discovery Feedback view?

Importing (or configuring) host names for discovery means each hostname itself will become a discovery range. The Discovery Feedback view shows progress for each discovery range, so it possible for this view to become sluggish in this case. While the view does have an automatic adjustment of its refresh rate based on the number of entries to process, it still can seem sluggish to some users, especially if the network is congested (the feedback data must transported to the UI). For


resolution of this, either (1) reduce the number of discovery ranges that are configured, perhaps by using IP ranges rather than hostnames, or (2) directly view or export the DB table that contains the feedback entries; the name of this table is Statuser. If viewing using the ITA database management utility, dcdbmng.exe, use the <F5> key to refresh the data. Note that this table is cleared out upon ITA services restart.

15. Is there an easier way to update settings for a lot of configured discovery ranges?

Using the import node utility to create templates for changing settings is one easy way to go about this – see the Importing Systems for Discovery section earlier in this article for more information. If you are very proficient in using SQL (or have an easy-to-use SQL tool), this is another option. Changes to the DiscoveryConfiguration table (the name of the database this table is under is ITAssist) can be made by issuing SQL table update commands; however, updating CIM passwords will be difficult due to being encrypted, unless you have a tool that allows an easy copy- (from the row with the updated, but encrypted CIM password) –and–paste (to other rows that need the updated password). The database that ships with IT Assistant (MSDE) includes a command line utility to execute SQL commands – the utility is osql.exe.

16. What are system up / down traps and how are they configured?

During a discovery or status poll, when IT Assistant detects that a system’s power status/network connectivity has changed, IT Assistant will initiate a trap for this. If the system transitions to an up state, a system up trap is sent; if the system transitions to a down state, a system down trap is sent. Keep in mind that the problem may be connectivity-related. A loss of connectivity could mean one of several problems may have occurred: the system lost power, one of the system’s NICs failed, one of the system’s NICs was disabled, the operating system was locked-up, a hardware failure occurred on the system itself or on a piece of network hardware between IT Assistant and the remote system, port blocking software was installed on the system, or one of several other problems. In IT Assistant v6.5, system up/down traps are configured by default to go to the localhost destination, since this is where IT Assistant services are located. The IT Assistant Event Management System (EMS) can then be used to take actions on these events (these events are currently defined under the Software category). To disable these events, simply comment-out the localhost destination in the trapconfig.cfg file and restart services. Additional destinations can also be configured. These traps may look like they are actually being sent by the system itself, but IT Assistant is actually impersonating the system for which it sends the up/down trap; it inserts that system's IP address into the trap so that it appears that the trap came from that system. This implementation enables specific systems to be monitored for system up/system down events through the IT Assistant EMS. Note that a system down trap may be the only event sent for a system that goes down, so it can be a useful feature for alerting IT personnel remotely (via paging or email) that a system went down.

17. How can I mine the data that is stored for the Offline Summary view?

Every piece of information seen in the Offline Summary view is contained in the OfflineSummary table in the ITA database. This table can be mined using SQL tools, or can be exported using the ITA database management utility, dcdbmng.exe, and exported into another application, such as Excel, to better utilize and report on the data.


12.0 Conclusion IT Assistant version 6.5 has many new enhancements that warrant an upgrade from previous versions, most notably the discovery service. Not only is discovery designed to be faster than before, but also more reliable and configurable, and it includes many new features requested by users. This article is meant to give users an insight into how this new discovery service works and how to configure it for any network.

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY

KIND.

Dell, OpenManage, PowerEdge, PowerVault, and PowerApp are trademarks of Dell Inc.

Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others.

©Copyright 2004 Dell Inc. All rights reserved. Reproduction in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell. Dell cannot be responsible for errors in typography or photography.

Information in this document is subject to change without notice.

exploring, configuring and optimizing the dell openmanage ...€¦ · 6.0 the protocols discovery...

Documents