exploring, configuring and optimizing the dell openmanage ... · • support for enhanced...

Exploring, Configuring and Optimizing the Dell

OpenManage™ IT Assistant Version 7.0

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

Dell OpenManage™ Systems Management

March 2005

Dell White Paper

By Ross Burns [email protected]

and Terry Schroeder

[email protected]

mailto:[email protected]


Contents 1.0 Introduction ........................................................................................................................3 2.0 An Overview of IT Assistant’s Components................................................................4 3.0 What is New in Version 7.0 .............................................................................................6 4.0 Configuring Discovery, Inventory, and Status Polling In General .........................7 5.0 Configuring Discovery for a Specific Network .........................................................14 6.0 The Protocols Discovery Uses .......................................................................................27 7.0 The Discovery Process In-Depth ..................................................................................34 8.0 The Status Poll Process In-Depth .................................................................................39 9.0 The Inventory Poll Process In-Depth ..........................................................................41 10.0 Discovery Options ..........................................................................................................44 11.0 Importing Devices for Discovery.................................................................................49 12.0 Discovery FAQs and Other Trouble-shooting Tips .................................................52 13.0 Conclusion........................................................................................................................60

March 2005 Dell Enterprise Systems Group


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 IT Assistant (ITA) version 6.5 and continuing with ITA version 7.0, the improved Network Monitoring Service is targeted at fulfilling all of these goals and more. This white paper 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 v7.0 from the Dell OpenManage Apps CD or downloaded from Dell online. IT Assistant version 7.0, released in Q1 2005 calendar year, provides many new discovery and other enhancements, some of which will be mentioned throughout this white paper. 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.


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 devices on the LAN/WAN at scheduled intervals determined by the administrator and populates the database with basic managed device information.

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

Inventory – Inventories the managed device’s hardware and software components, including processor, memory, installed PCI devices, storage, drivers, and firmware information.

Event Management System (EMS) - Processes incoming events including SNMP Traps / 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 / actions are defined, the console view is only updated to reflect event information received from monitored devices.

• IT Assistant Connection Service

Connectivity (communication) to managed devices and the ITA database for retrieving status / summary / asset data and for performing tasks on the managed device.

A conduit between the UI and the Network Monitoring Service to send / 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 device information obtained through discovery and inventory

- IT Assistant Discovery, Inventory, and Status polling configuration

- Event definitions and event filters / action configuration

2.2 IT Assistant Client User Interface

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

Configuration of the IT Assistant Services tier

Reporting and/or performing tasks on individual or groups of managed devices

Dataflow between IT Assistant Client UI and 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 reporting. The Connection Service also supports the task management functionality. See figure 1 for an overview of IT Assistants tiers and representation of dataflow between the tiers.

Figure 1 – Overall Component View



3.0 What is New in Version 7.0 The IT Assistant Network Monitoring Service has been enhanced (from version 6.5) to support the following:

• Increased discovery and status speed through optimized thread-synchronization techniques and newer, faster supporting libraries.

• Increased scalability, providing support for discovery and management of devices numbering in the 1000’s.

• Support for a new inventory cycle. • Support for enhanced configuration and optimization of the discovery / status / inventory

process. • Greatly enhanced data storage capabilities, resulting in a large repository of data from which to

report on. • Other discovery-related features, to be discussed later in this white paper.

In addition, the Network Monitoring Service is able to scale better and take advantage of more of the system resources of the computer it is running on – running on a multi-processor system gives better discovery performance in most cases.

Other changes / enhancements to version 7.0:

• The ITA User Interface is now exclusively web-served and is a Java Applet based on the Sun Java Virtual Machine. The UI can run in Internet Explorer on Windows systems and Mozilla on Linux systems. The usability has been greatly enhanced, allowing right-click functions on most objects. The services tier remains Windows-only at this time.

• A greatly enhanced Event Management System (EMS), allowing for greater customization of event filter and action policies.

• A greatly enhanced reporting system and a larger data repository on which to report on. • The addition of a Task Management System (TMS), allowing tasks to be run on any number of

devices / groups of devices. Tasks include device control, remote SW update, and a remote Server Administrator command line.

• A new Troubleshooting Tool to help troubleshoot discovery / device communication problems. • An overhaul of the device grouping infrastructure, allowing multi-level grouping and dynamic

grouping capabilities. • Enhanced authentication (based on NT domain) and encryption (using HTTPS). • Enhanced application detection and launch of remote device applications. • Removed support for the DMI protocol. • Removed support for Hardware Instrumentation Package (HIP) and OpenManage Client

Instrumentation (OMCI) v6.x. • Removed support for reporting on status of individual probes – this is now accomplished via the

Server Administrator product. • For other new features, see the IT Assistant 7.0 Reference Guide.

4.0 Configuring Discovery, Inventory, and Status Polling In General

4.1 Discovery Cycle: If, When, and How Fast Discovery Occurs In the IT Assistant UI, under Discovery and Monitoring->Discovery Configuration in the top menu is the dialog shown in figure 2 below. Note that this dialog has been redesigned from previous versions. Although anyone can view this dialog, to save a configuration change in this dialog requires the logged-in user to have Administrator privileges. All data in this dialog is stored in the GlobalConfiguration and Task tables in the IT Assistant database.

Figure 2 – Discovery Configuration Settings dialog

In figure 2, the Discovery Configuration Settings dialog, there are several controls:



1. Enable Device Discovery checkbox - this control (checked by default) controls whether or not a regular discovery cycle occurs. Note that this control has no effect on user-initiated (previously known as “forced”) discoveries of an individual device or a discovery range. Un-checking this box while discovery is occurring will cancel all discoveries in progress, except user-initiated 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 logs (located under the Discovery and Monitoring -> Logs menu) and all discovery threads will exit at the first opportune time.

2. Discovery Interval / Time of day / 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 week. The time of day/day of week option allows 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. For this version of ITA, the last discovery run time is always stored, so if the interval option is selected, discovery will not necessarily run immediately if services are stopped and re-started – it will only run at the next scheduled interval. Also note that, even if the enable device discovery checkbox is unchecked, the interval is still maintained behind the scenes; if device discovery is re-enabled, discovery will occur at the next scheduled interval or time of day / day of week.

Note that even if the user schedules a discovery cycle for every hour, if the previous discovery cycle is not complete (all discovery ranges showing 100% complete in the discovery feedback view), another discovery cycle will not be allowed to go through, but will instead be aborted; instead, 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. 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 device 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 user-initiated discoveries to assure IT Assistant has the latest inventory data for the devices 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 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 white paper.

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 devices 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 v7.0, the discovery throttle is set at 30% by default; upon an upgrade from a previous ITA, the throttle control remains at its previously set value.

IT Assistant 7.0 improves upon the optimized parallel threading implementation in the Network Monitoring Service introduced in version 6.5. Because the discovery process can be very I/O 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 devices at once. To an extent, the more threads that run in parallel, each communicating to a different device, the faster discovery will be, barring overall 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 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 discovery service is optimized for parallel threading operations, more system resources may be consumed even at the same throttle setting as the older (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 or increase the throttle dependent upon the system it is running on and the resources available. Note that the discovery service may take up to several minutes to adjust to a new throttle setting.

TIP: For minimal discovery times on medium to large size networks (several hundred to several thousand devices), it is recommended that you install ITA services on a multi-processor system with a version of the Windows operating system that takes advantage of all processors.

4. Discover all devices or only Dell instrumented devices – If All Devices 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 unknown category in the UI. If the setting of Only Dell Instrumented Devices is selected, only those devices that have


Dell instrumentation loaded and running will be discovered. Under this setting, no devices should appear in the unknown category (or group) – all discovered devices should be classified. Should this option be selected after ITA has discovered devices under the All Devices selection, any unclassified devices stored in the database will be deleted immediately. Note that, once ITA classifies a device, it will keep that classification, even if it cannot communicate with instrumentation on subsequent rounds of discovery.

TIP: If you are having trouble in discovering a device and Discover only Dell Instrumented is selected, change this to All Devices and initiate a discovery of the discovery range the device is on. If the device 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 device you are trying to discover or in ITA itself, (2) The protocol ITA needs to use to communicate to the device is blocked by a network router or port blocking software, or (3) Dell instrumentation is not loaded or running on the device to be discovered.

5. Use DNS Name Resolution or Instrumentation Name Resolution – This controls which name is shown for the device in the User Interface. When ITA discovers a device, it will always use the IP address(es) of the device to communicate with it – as part of discovery, the discovery service will always try to resolve this IP Address to a name because users are typically used to dealing with devices by name and not by IP. By default, the discovery service asks for both the DNS Name, in which a network API is called to convert the address to a name (this name is provided by the designated name server, which typically provides the fully qualified domain name (FQDN) of the device), and the Instrumentation Name (which is typically the NetBIOS name or the name stored in firmware of the device), which is provided by the remote device’s agent. Both of these attributes are stored in the database, but only one name is shown for the device in the User Interface. The name shown is determined on the preference chosen and the success of obtaining the name – if the DNS name was preferred, but only the Instrumentation Name is available, then the Instrumentation Name is shown. No matter what the order, if both methods fail to return a name, the name of the device 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 are managing clusters, Instrumentation Name Resolution is the best choice so that each device that is part of the cluster is seen by its real name, not the cluster name. Because changing this setting can sometimes disrupt your ITA environment, it is recommended to change this setting only when necessary.

4.2 Status Cycle: If, When, and How Fast a Status Cycle Occurs In the IT Assistant UI, under Discovery and Monitoring->Status Polling Configuration in the top menu is the dialog in shown in figure 3 below. Note that this dialog has been redesigned from previous versions. Although anyone can view this dialog, to save a configuration change in this dialog requires the logged-in user to have Administrator privileges. All data in this dialog is stored in the GlobalConfiguration and Task tables in the IT Assistant database.

Figure 3 – Status Polling Configuration Settings dialog

In figure 3, the Status Polling Configuration Dialog, there are several controls:

1. Enable Status Polling checkbox – This control (checked by default) allows the user to

enable/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 devices it has discovered.

2. Status Polling Interval – 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 section The Status Cycle Process In-Depth later in this white paper. Just as discovery has a self-regulating feature, so too does status polling cycles; the next status cycle will not start until the last one has finished. The Discovery Logs 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 device. 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 device has lost connectivity with the network or has gone down.

3. Status Polling Speed slider control – 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 to keep the throttle control at 100% (the default).


Note that each tick on the throttle control equals 10% and the range is from 10% to 100%. Upon a new install of ITA v7.0, the status polling throttle is set at 30% by default; upon an upgrade from a previous ITA, the throttle control remains at its previously set value, if that version of ITA had a status throttle control.

4.3 Inventory Cycle: If, When, and How Fast an Inventory Cycle Occurs In the IT Assistant UI, under Discovery and Monitoring->Inventory Configuration in the top menu is the dialog in shown in figure 4 below. Note that this dialog is new to this version of ITA. Although anyone can view this dialog, to save a configuration change in this dialog requires the logged-in user to have Administrator privileges. All data in this dialog is stored in the GlobalConfiguration and Task tables in the IT Assistant database.

Figure 4 – Inventory Poll Settings dialog

In figure 4, the Inventory Poll Settings Dialog, there are several controls:

1. Enable Inventory checkbox – This control (checked by default) allows the user to enable/disable

inventory poll cycles. If using reporting and Software Update task features of ITA, inventory polls should be enabled, as this allows ITA to obtain detailed information about the hardware and software/firmware drivers installed on the remote device.

2. Inventory Interval / Time of day / day of week – When inventory polls are enabled, these controls

configure how often an inventory cycle occurs. The interval option allows the user to schedule discovery as often as every hour or as seldom as every week. The time of day/day of week option



allows the user to control exactly when inventory 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. Note that the last inventory run time is always stored, so if the interval option is selected, inventory will not necessarily run immediately if services are stopped and re-started – it will only run at the next scheduled interval. Also note that, even if the enable inventory checkbox is unchecked, the interval is still maintained behind the scenes; if device inventory is re-enabled, discovery will occur at the next scheduled interval or time of day / day of week.

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

TIP: The data obtained through the inventory cycle is less likely to change than the data from discovery, so an inventory poll can be performed less often, if desired. For more information about what occurs during an inventory cycle and what data is inventoried, see the section The Inventory Cycle Process In-Depth later.

3. Inventory Speed slider control – This control acts much like the discovery throttle, controlling how many threads are used during an inventory cycle. By default, there are a maximum number of 32 threads dedicated to performing the inventory process – the throttle controls how many threads are actually used.

Note that each tick on the throttle control equals 10% and the range is from 10% to 100%. Upon a new install of ITA v7.0, the inventory polling throttle is set at 30% by default.

5.0 Configuring Discovery for a Specific Network

In this version of ITA, the way discovery ranges are configured has been dramatically changed. The concept of wizards is now used to assist in configuring more complex options. To configure a discovery range, a multi-step wizard is involved, where the user configures the subnet, subnet mask, ICMP properties, and then protocol properties. For protocol setup, note that there is no longer the option to configure protocols on a global level, then have them inherited by new discovery ranges, as this option was deemed somewhat confusing and did not benefit the user if already-configured ranges needed to have their protocol settings updated.

In the IT Assistant UI, under Discovery and Monitoring-> Ranges in the top menu bar, is the screen as shown in figure 5 below. In this screen, a list of include and exclude ranges are presented in a tree-like structure. Selecting a range on the left gives a summary of its configuration on the right, minus any properties that are security-sensitive. All data in this screen is stored in the DiscoveryConfiguration table for include ranges and the SubnetExclusion table for exclude ranges in the IT Assistant database.

Figure 5 – Discovery Range View Screen


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 (the IPX protocol is not supported). Configuring include ranges now consists of a multi-step wizard. Each step will be explained below.

5.1.1 – Inclusion Range Wizard Step 1 Figure 6 below depicts the wizard page for configuring the inclusion range for discovery.

Figure 6 – Inclusion Range Wizard Step 1

In figure 6, the Inclusion Range Wizard Step 1 wizard page, there are several items to configure:

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 roughly 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*256 = 65536 IP Addresses.

TIP: 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, and as a result discovery will generate 65536 addresses to ping (minus broadcast and network addresses) during each discovery round, leading to excessive consumption of network and system resources to discover a comparatively (much) smaller number of actual managed devices. 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, ITA will try discovery on every IP returned, provided it is not filtered by the subnet mask.

TIP: Using hostnames for discovery is sometimes ideal if devices 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 section Importing Devices for Discovery later in this document.

3. Subnet Mask – New to this version of ITA, a subnet mask is now supported. The discovery process uses subnet masks to determine which IP addresses are broadcast or network addresses so that they are not pinged. This is especially useful when entering IP ranges which can cross subnet boundaries. The default value populated is for a traditional class C network.

5.1.2 – Inclusion Range Wizard Step 2 Figure 7 below depicts the wizard page for configuring the ICMP settings for the inclusion range. New to this version of ITA, the ICMP (or ping) settings can be customized to a particular discovery range; before, they were only changeable through a configuration file and applied globally to all ranges.




In figure 7, the Inclusion Range Wizard Step 2 wizard page, there are a couple of items to configure:

1. ICMP Timeout – the user can specify, in milliseconds, the timeout of the ping packet. It is suggested to set this value to the slowest device on the range to be discovered. Using the ping command from the command line of the ITA services system can help determine the round trip time of ping packets on the network. To allow for network fluctuations, some padding in the time is recommended. For example, for a round trip time of 200 ms, 400 ms is likely an acceptable setting.

2. ICMP Retries – the user can specify the number of retries attempted. Typically, the default setting of one retry is acceptable.

TIP: When using the ping command to determine ICMP timeouts, if the round trip time varies widely (by at least several hundred milliseconds) from try to try, or packets are being dropped frequently, this is indication that ITA may not operate reliably in discovering and/or statusing the range being configured. It is recommended to root cause and fix problems like these before using ITA with the devices on the discovery range being configured.

5.1.3 – Inclusion Range Wizard Step 3 Figure 8 below depicts the wizard page for configuring the SNMP settings for the inclusion range.


In figure 8, the Inclusion Range Wizard Step 3 wizard page, there are a couple of items to configure:

1. Enable SNMP Discovery checkbox – checked by default, this controls whether or not the SNMP protocol is used for this discovery range. To determine which protocols are used by Dell agents, see the section The Protocols Discovery Uses later in this white paper.

2. Get Community – The user should enter the get (or read) community name here. Multiple names can be entered into this field, separated by commas, and ITA will auto-detect the right one by trying each one in the list until a community name that works is found. Note that community names are case sensitive. Because trying multiple community names can slow down discovery, it is recommended to keep the list to at most a few names. A best practice is to minimize the number of community names setup for each discovery range created.

3. Set Community – The user should enter the set (or write) community name here. Multiple names can be entered into this field, separated by commas, and ITA will auto-detect the right one by trying each one in the list until a community name that works is found. You should follow the same guidelines and best practices as stated in the Get Community section when creating the Set Community name.


4. Timeout – Specifies the maximum amount of time ITA will wait for a response after issuing an SNMP request to a managed device. 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.

5. Retries – Specifies the number of retries ITA will attempt to a managed device during an SNMP request if it receives no response. It is recommended to keep this setting to a low value, as communication to the managed device (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.

5.1.4 – Inclusion Range Wizard Step 4 Figure 9 below depicts the wizard page for configuring the CIM settings for the inclusion range.


In figure 9, the Inclusion Range Wizard Step 4 wizard page, there are a few items to configure:


1. Enable CIM Discovery checkbox – un-checked by default, this controls whether or not the CIM protocol is used for this discovery range. To determine which protocols are used by Dell agents, see the section The Protocols Discovery Uses later in this white paper.

2. Username – CIM uses domain-based authentication. If using the CIM protocol to manage devices, this field is to contain the username of the domain-based account used to authenticate to the remote device(s). In this version of ITA, the discovery process no longer runs in the context of a particular user; due to this, it is important to qualify the user with the correct NT domain or “localhost” if there is none (example: “localhost\adminuser”).

3. Password – If using the CIM protocol to manage devices, this field is to contain the password of

the domain-based account used to authenticate to the remote device(s). This value is encrypted when it is stored in the database.

5.1.5 – Inclusion Range Wizard Step 5 Figure 10 below depicts the wizard page for selecting the discovery action for the range. In previous ITA versions, a discovery was automatically done for a new range, unless discovery was disabled. Now, there is the option to perform this initial discovery. Note that this option setting is not saved with the discovery range.




In figure 10, the Inclusion Range Wizard Step 5 wizard page, the user can select from one of the following:

1. Do not perform Discovery or Inventory – Do nothing with this new range until the next scheduled discovery (if enabled), or a user-initiated discovery is performed. Note that the range must be discovered first before it can be inventoried.

2. Perform only Discovery – Perform only a discovery when the range is saved. Threads allocated for discovery are used for this discovery.

3. Perform both Discovery and Inventory – Perform both an inventory and discovery on the new range. Note that these are performed at the same time – the same thread that discovers the device will then immediately inventory it. Threads allocated for discovery are used for this discovery and inventory.

5.2 Exclusion Ranges Exclusion ranges tell IT Assistant what not to discover or what to ignore. An exclusion 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 devices or small groups of devices among a wider inclusion range or to temporarily exclude devices from being discovered. Should an exclusion range be entered for a device already discovered, that device will be deleted from the IT Assistant database of discovered devices (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 device 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 device as “systemA.domain”. When trying to use an IP address to exclude a device, it is important to include all IP addresses that the device may be discovered under; only IP addresses that are part of an inclusion range need to be entered. For example, if a managed device 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).

5.3 Additional Discovery, Inventory, and Status Cycle Considerations Discovery, inventory, and status cycles operate independently of each other; all can be executing at the same time, which can result in 100+ threads running at any one time in the discovery process (depending on throttle settings). 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 devices are in place, should discovery and status operations occur on the same device at the same time. The same also applies for inventory and the two above mentioned cycles. An inventory cycle does not update the power/connectivity and health check properties and is not meant to take the place of a discovery or status poll of the device.

5.3.1 User-Initiated Actions from a Discovery Range Figure 11 below shows the actions available for a discovery range. Note that some actions may be restricted or not shown depending on the privileges of the user logged into the UI session.

Figure 11 – Discovery Range Right-Click Actions

For users of previous ITA versions, note that the term “force discovery” is no longer used. Instead, there are user initiated actions for both discovery ranges and devices. Note that the same actions are available



from either a right-click off of the range or in the menu bar item Actions when a range is selected. From a discovery range, the following can be performed:

1) Edit … - Allows the user to edit the range’s configuration by traversing the discovery range wizard again. The include range itself is the only non-configurable item.

2) Disable/Enable – Allows the range to be included/excluded from the next scheduled discovery round. Disabling the range does not affect user-initiated actions.

3) Delete Include Range – Deletes the range from the database and any devices exclusively tied to (or discovered on) that range. If a device happens to also be discovered on another range, it will remain.

4) Perform Discovery Now – Perform a discovery of the range.

5) Perform Discovery and Inventory Now – Perform a simultaneous discovery and inventory of the range.

6) Perform Status Polling Now – Perform a status poll of the devices already discovered on the range.

7) Perform Inventory Now – Perform an inventory of the devices already discovered on the range.

5.3.2 User-Initiated Actions from a Device The following actions can be performed on a device (right-click on the device in the device tree):

1) Refresh Inventory – Perform a limited discovery of the device and then an inventory of the device. What is meant by a limited discovery is that IP Address information may not be refreshed completely based on the following scenario:

a. If DNS Name Resolution is the preferred name resolution in ITA, then only those IP Addresses that are returned for the device name by the name server are used / refreshed. If the name server does not return any IP addresses, then only those addresses in the database marked as pingable (a column in the NIC table) for the device will be used. An IP address entry is marked pingable if it is both explicitly part of a discovery range entered into ITA for discovery and the device responds on that address. Other addresses may be returned by the operating system or device agent and are shown, but will not be marked as pingable. This pingable entry assures ITA only uses those addresses to communicate to the device that the user intended it to.

b. If Instrumentation Name Resolution is the preferred name resolution in ITA, then only those addresses in the database marked as pingable for the device will be used.

2) Refresh Status – Perform a status of the device.

Should a user-initiated discovery / status poll / inventory task be started on a discovery range or device already undergoing a scheduled or user-initiated one, the already running task will be stopped and the


new task request will start execution at the beginning, with the exception of a global status poll or inventory cycle. A user-initiated request has a higher priority than a regularly scheduled one so that it will typically finish faster than any other scheduled tasks that happen to be occurring at the same time. However, subsequent user-initiated requests on a discovery range (or device) already undergoing a task of the same type (discovery, status poll, or inventory) does not raise the priority of the task – it will only start that particular task over again. Should a regularly scheduled discovery, inventory, or status poll round start while a user-initiated task of the same type is occurring, no interruption of the user-initiated task will occur.

5.3.3 Discovery Feedback The discovery feedback view has been overhauled from the last ITA version – this view is available from the top menu bar under Discovery and Monitoring->Logs. The highlights of this view are as follows:

I. Overall Discovery / Status feedback and control (top portion of view) – Contains feedback for status poll cycles and discovery on a global level. The Enable Continuous Updates checkbox controls whether or not this view is automatically updated on a periodic cycle. The frequency of the update depends on how many discovery range feedback entries (or rows in the DiscoveryTaskExecutionHistoryView table in the database) there are to refresh. On the right side of the view are the Discovery Status and Status Poll feedback indicators. The Discovery Status feedback indicator reports whether or not discovery is currently running from one or more ranges and the Status Poll feedback indicator reports when the last (global, or all devices) scheduled status poll was run.

II. Table of all discovery related tasks – Displays the progress for each device or discovery range that

has undergone or is undergoing discovery, a status poll, or an inventory, whether it be scheduled or user-initiated. For each entry, a task name, start time, state (pending, running, stopped, completed), percent complete, and end time is provided. For those tasks that are interrupted by the user, either by requesting the task to stop or by stopping the discovery service, the state column will show “stopped” to indicate that the task was interrupted – the percent completed column will show how far the task process had completed before it was interrupted. For tasks in the table, the following right-click actions are supported (some of which are context-sensitive):

a. Export Discovery Data – writes a file with the name ITA_discovery_details.txt to the IT

Assistant root installation directory. This file is typically meant for Dell support personnel to better help them diagnose the discovery process, should the user have problems with discovery completing. Every time this option is selected, the file will be appended to. The file can be started-over by deleting it. The columns in this file are as follows:

1. Node – The managed device. 2. Range – The discovery range. 3. TaskID – The discovery-assigned unique ID of the running task. 4. ThreadID – The operating system-assigned thread ID for the task. 5. Time – Total execution time of the task (in seconds). 6. CheckPoint – Where the task is at in its processing.


b. Request Discovery Details – Brings-up the Discovery Task Details dialog. This dialog describes the discovery, inventory, and/or status poll tasks that are currently running. For more information on what tasks can run, see the in-depth sections on status, inventory, and discovery later in this white paper. 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 (Device Discovery Task), Inventory (Device Inventory Task), and Status Poll (Status Task).

2. Managed Device – the IP addresses or name of the device 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 other tasks queued-up to run at a later time – only a certain number of tasks (or threads) 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 – the table is not dynamic; to refresh it, close the dialog and bring it up again.

c. Delete Selected Entries / Delete All Entries – Deletes the selected feedback entries or all entries, depending on the option chosen. Deleting a feedback entry does not affect the task that is running. If the task is still running, the entry will eventually appear again. Tasks which are stopped or completed will not re-appear after deletion until run again.

d. Stop Selected Entries – New to this ITA version is the ability to stop discovery service-

related tasks. When a stop is requested for a task, all queued sub tasks related to that task are deleted and any sub tasks already running will be asked to stop as soon as possible. Threads (or tasks/sub tasks) are never terminated arbitrarily, as this can de-stabilize the discovery process. This has two implications: (a) For a sub task that us running, but is not permanently hung waiting on a response form the remote device, it will exit at the same time or shortly after the time the task state is shown as stopped in the UI, and (b) For those tasks that appear hung (no increasing progress after several minutes / hours, depending on how large the discovery range is), stopping the task will not result in all sub tasks exiting cleanly. If scheduled (or non user-initiated) tasks have sub tasks (or threads) that are permanently hung, it may take a restart of the discovery service to assure the next scheduled task of the same type (whether the type be status, discovery, or inventory) happens.


6.0 The Protocols Discovery Uses When IT Assistant communicates with a managed device, it uses one or both of two industry standard protocols – SNMP and / or CIM to communicate with the agent technology installed. During each discovery cycle, a process is used to detect which protocols the managed device under discovery is configured to use. It does this by querying a standard piece of information from the device 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 device’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 device), along with the possible configuration of routers in-between to allow the communication to occur. See table 2 for what protocols server/client Dell agents support. For this version of IT Assistant, the DMI protocol has been removed, as well as support for some specific agent versions when it comes to other protocols – this is denoted in the table below by term NLS (no longer supported).

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

Dell OpenManage Server Agent (OMSA) v4.0 – 4.3 Yes2 - NLS 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 - NLS No No

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

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

Dell OpenManage Storage Manager (OMSM) Agent v1.0+ No Yes No

Table 2 – Dell Client and Server Agent Protocol Support 1Via Intel DMI-to-SNMP Mapper, only available on Microsoft Windows NT. 2Microsoft Windows only 3Optional at agent install time (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. NLS - No longer supported in this version of IT Assistant


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 devices. 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.

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.

Protocol information is spread throughout 3 separate tables in the ITA database (see figure 12 below for a diagram of the relationship between the following tables / views):

DiscoveryConfiguration table – Contains the discovery range and protocol settings as configured by a user when the Discovery Range wizard is used. This table contains the CIM protocol credentials; these credentials are not copied to the Device table as in previous versions (known as the Node table) of ITA to facilitate the changing of credentials without the need for a re-discovery.

SubnetDeviceAssociation table – Associates a discovery range with a device. This table contains columns for the detected SNMP read and write community names because devices can sometimes support multiple community names. If a device is discovered on multiple discovery ranges, then this table will contain more than one row for that device.

Device table – Contains basic information about the device, including what protocols it actually supports.

There are also two database table views on the above tables:

SubnetDiscoveredOnView table view – Joins together certain columns from the DiscoveryConfiguration, SubnetDeviceAssociation, and Device tables. There is one row per device per discovery range discovered on. Sometimes used by the discovery process when performing a status poll or inventory.

SubnetLastDiscoveredOnView table view - Joins together certain columns from the DiscoveryConfiguration, SubnetDeviceAssociation, and Device tables. There is one row per device – this row is the last discovery range the device was discovered on. Used by the discovery process when performing a status poll or inventory.

Figure 12 – ITA tables which relate protocol information

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 discover range 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 device discovered on that range. Much of the basic device information is stored in the Device table, including what protocols that device supports – this information is stored as a number in the Device Protocols column. To know what protocols a device supports, just use the ITA reporting system – run a report on one or more devices, including the table Device and column Devic eProtocols. The values return can be interpreted as:

Device supports no protocols: Device Protocols = 0 or blank

Device supports SNMP: Device Protocols = 1

Device supports CIM: Device Protocols = 4

Managed devices may support a combination of protocols, for example: 5 = 1(SNMP) + 4(CIM).

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 device goes down during a discovery round, or the community name changed for that device to where ITA no longer uses the correct community name for that device, discovery would change the protocols fields for that device 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, various storage agents, etc., SNMP is typically 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 is 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. An overview of the SNMP protocol and its configuration is shown in table 3 below.

SNMP Protocol Overview Transport UDP/IP Connection Type Connection-less Typical Ports Used 161 (data), 162 (traps) Variations SNMPv1, SNMPv2c, SNMPv2u, SNMPv3. SNMPv1 and SNMPv2c (also

known as just SNMPv2) are the most prominent. Security SNMPv1, SNMPv2c = community names; SNMPv3 = strong authentication

(username/password). For Dell server agents, such as Dell OMSA, instrumentation username/password 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 device 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 device. For some SNMP master agents, need to assure packets are accepted from the system on which ITA services reside. (2) For events (traps), need to configure community name and destination in managed device’s SNMP agent.

Table 3 – SNMP Overview and Configuration


Community Names and Other SNMP Parameters For data to flow back and forth between ITA and the managed device, 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 an optional write community name. Although read and write 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 cases since community names are case sensitive, but never, ever use the community name of “public” as this name is extremely well known and is equivalent to not having any security methodology in effect. Fortunately, most modern operating services’ SNMP services do not assume any community name – it 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 devices, don’t count on changing them often.

ITA has 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 device 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 – 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 device to find out the response time of a device over the network can help, 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 devices that do not support SNMP since a timeout will occur with these devices. Also, keep in mind that a response may not be received from a remote device’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. There are two transport methods that are most prevalent: Windows Management Instrumentation (WMI) and CIM Operations over HTTP. As WMI suggests, the former transport model mentioned is only available on the Windows operating system, 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 more mature transport model of the two. An overview of the CIM protocol and its configuration are shown in table 4 below.

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.

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.

Configuration Considerations

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

Table 4 – CIM Overview and Configuration

Using CIM and CIM Parameters Using CIM in the Windows context (or WMI) involves domain authentication for security. Previous versions of ITA involved configuring CIM either during install or through an external utility known as configservices.exe – this sometimes reduced or eliminated the need to qualify the CIM username with a domain as the discovery service ran in the context of a user. In the current version, CIM is no longer enabled externally to the application – it is enabled/disabled only on a per discovery range basis. This results in the discovery service no longer running in the context of a user, therefore requiring each CIM


user to be qualified with a domain, or localhost if no trusted domain is configured. It is very important to provide this qualification when configuring CIM through a discovery range (example: domain\username, or localhost\username) or the CIM protocol will not be authenticated and used. TIP: 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. This version of IT Assistant makes account lockouts less frequent when there is the need for a name/password change on a discovery range due to the way discovery configuration is stored and referenced. 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 can make this effort much easier in ITA by defining a template with the changed credentials and re-importing all discovery ranges. For more information, see the section Importing Devices for Discovery later in this document.

7.0 The Discovery Process In-Depth The Network Monitoring Service in IT Assistant v7.0 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) Device discovery tasks, which represent the discovery of individual devices. When a user-initiated 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 devices that respond, a separate task is queued to run in a separate thread – a device discovery task. The device discovery task performs a more intimate discovery of the device, including protocol detection and inventory of the device. See figures 13, 14, and 15 for a more in-depth look at the discovery process.

Figure 13 – Overview of Ping Discovery Task



For figure 13 above – reference the Roman numeral above with a more detailed explanation 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 device 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. IP Broadcast Address – If the IP is calculated to be a broadcast or network address, based on the netmask for the discovery range, then it will be skipped.

IV. Show device as down status if no other IP responds. Generate device down event: Cross-reference the IP address back to the Device table in the database – if a device entry is found, pull its IP addresses that are marked as “pingable” and ping each one until one responds. If no IP responds, put the device status as down. Generate device down event if its power status has changed from what is stored in the database. Send device down trap, if device up/down traps are configured in the dconfig.ini file. A note about pingable addresses - 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 device (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.

V. Queue device discovery task to run - If a device responds to the ping, create a device discovery task object for that device and queue it to run. Both ping discovery tasks and device 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 14 – Overview of Device Discovery Task – Part 1


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


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

III. Attempt connection to instrumentation – If the device supports any protocols, discovery will attempt to connect to the various agents on that device which support those protocols in preparation to pull discovery data.

IV. Attempt to retrieve instrumentation name – Discovery will store both the instrumentation and DNS names for a device, if either or both are available. The instrumentation name 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 device.

V. Discovery only Dell? – In the discovery configuration settings, the user can select whether or not only Dell devices are discovered. If this is selected and discovery cannot connect to the primary Dell agent on the device, the device will not be discovered.

Figure 15 – Overview of Device Discovery Task – Part 2




VI. Find device in database – If the device was previously discovered, discovery will always try to correlate the latest device discovery data back to the original database entry for the device – this is important as devices have unique ids that associate/connect their information throughout many database tables. If instrumentation is available (a), the correlation will occur by MAC Address and possibly device service tag if needed; otherwise, name or IP Address (b) is used to correlate the device.

VII. Select name for device based on user preferences and availability – Discovery tries to retrieve both the DNS and instrumentation name for the device (stored in different columns in the Device table). The ultimate name shown for the device in the GUI depends on what the user prefers (chosen in the discovery configuration dialog box) and what is available. For example, if DNS is preferred, but only the instrumentation name is available, then the instrumentation name is shown.

VIII. Classify device – determine the classification of the device based on the instrumentation present.

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

X. Calculate device membership information – if the device is part of a modular chassis and/or HA cluster, then groups are automatically created, if not already created and the device is added as a member of them.

XI. Retrieve inventory data from device – If the task involves both a discovery and inventory, then perform an inventory of the device at this point.

XII. Update Device info in Database – Store discovery / inventory information to the database – see the table listing which data is pulled in the section The Inventory Process In-Depth.

XIII. Generate device up event - Generate device up event if its power status has changed from what is stored in the database. Send device up trap, if device up/down traps are configured in the dconfig.ini file

8.0 The Status Poll Process In-Depth As mentioned in the previous section, the discovery service in IT Assistant v7.0 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 and health check for an individual discovered device; 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 device. See figure 16 for a more in-depth look at the status process.

Figure 16 – Overview of Device Status Task


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



Assistant may have retrieved several IP addresses for the device 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 device 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 device. Stop at the first IP that responds. For a device to be up in ITA, only one address need respond to ITA.

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

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

V. Generate device down event if change in power status – If the power/connectivity status has changed from the last recorded status (both discovery and status will record this status for the device), generate an internal device down event if the status transition is from up to down. Also, send a device down trap if traps are configured in the dconfig.ini file. Device up/down events are only sent on a transition in status, not during each poll.

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

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

VIII. Generate device up event if change in power status – If the power/connectivity status has changed from the last recorded status (both discovery and status will record this status for the device), generate an internal device up event if the status transition is from up to down. Also, send a device down trap if traps are configured in the dconfig.ini file. Device up/down events are only sent on a transition in status, not during each poll.

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

9.0 The Inventory Poll Process In-Depth New to this version of ITA, a separate inventory polling cycle has been introduced. For inventory polling where a discovery of the device is not involved, there is one basic type of task that runs: the device inventory task, which performs an inventory of various hardware / software components of the device; each of these tasks is run in an operating system thread, making the inventory process a multi-threaded process. See figure 17 for a more in-depth look at the status process.

Figure 17 – Overview of Device Inventory Task




I. Get power status of device from database – retrieve the power status (updated by discovery or status poll) of the device. If the device is down, abort an inventory of it.

II. Find a pingable IP device responds on – Retrieve all pingable IP Addresses for the device and find one that the device responds to – use it to connect to the device to pull inventory.

III. Attempt to connect to instrumentation – Attempt to connect to the Dell agents on the device in order to pull inventory.

IV. Pull hardware / software inventory – Connect to all detected agents and pull inventory information from them.

V. Store hardware / software inventory in database – store the information retrieve from the agent(s) in various database tables. See the table below for what information is stored.

Tables Available for Reporting

Tables Populated by Discovery

Tables Populated by Inventory

Enclosure Management Module

X

Enclosure X

Volume X

Controller X

Array Disk X

Virtual Disk X

Firmware X

Agent X

Device Card X

Power Supply X

Memory Device X

Processor X

Contact Information X

Operating System X

Device X

Software Inventory X

NIC X

Modular Chassis Association X

Cluster X

RAC Device X

Switch Device X


Cost Of Ownership X

SMBIOS X Table 5 – Database table updated by Discovery / Inventory tasks.


10.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 it is discovering, to debug apparent discovery problems (such as discovering a particular device) 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 may not be saved, so it is recommended to backup 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 likeliness that other sections on the configuration file were changed. Some options mentioned below are already in the configuration file with defaults specified – some options may not yet be in the file – for these options, 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 - 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 Name resolution retries.

Section [INET_PARAM]

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 ITA Connection Service.

Short Description Turn off event management system.

Section [EVENT_MANAGEMENT]

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 devices only, not for receiving or processing events, the EMS can be turned-off via this setting. Note that, if this 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 – 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) where 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 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


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 Maximum inventory threads.


Key NUM_INVENTORY_THREADS

Default Value 32


Long Description The maximum number of threads that can simultaneously execute for inventory when the inventory 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 Invalid instrumentation name list.



Key SYSTEM_NAME_EXCLUDE_LIST

Default Value Localhost, etc.

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

Long Description When discovery retrieves the instrumentation name, this name may not be unique for some devices, or may be set to a default value. Use this list to input names that are deemed not valid and they will not be accepted as valid instrumentation names.

Short Description Eliminate duplicate names.


Key ELIMINATE_DUPLICATE_NAMES

Default Value 1

Suggested Values 0 (off) or 1 (on)

Long Description IT Assistant v7.0 has the option of eliminating duplicate names (or duplicate device entries in the UI) by using the MAC address(es) of the computer to uniquely identify it. Duplicate entries occur when DNS returns a different name for the device 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 device – the setting of DUPLICATE_NAME_EXCLUDE_LIST contains this list of exclusions. Should it be suspected that some devices are not showing up as being discovered because they are mistaken as being the same device (the last discovered device 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 devices being discovered and excluded. Once the affected devices are discovered, check IT Assistant’s inventory view to see the MAC addresses for those devices and enter it into the exclusion list.

Short Description Eliminate duplicate names MAC/IP exclusion list.


Key DUPLICATE_NAME_EXCLUDE_LIST

Default Value

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


Long Description ITA v7.0 has the option of eliminating duplicate names (or duplicate device entries in the UI) by using the MAC address(es) of the computer to uniquely identify it. Duplicate entries occur when DNS returns a different name for the device 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 device – this setting contains this list of exclusions. Should it be suspected that some devices are not showing up as being discovered because they are mistaken as being the same device (the last discovered device 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 devices being discovered and excluded. Once the affected devices are discovered, check IT Assistant’s inventory view to see the MAC addresses for those devices and enter it into the exclusion list.

Short Description Keep history for all discovery rounds.


Key KEEP_DISCOVERY_HISTORY

Default Value 0 (off)

Suggested Values 0 (off) or 1 (on)

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 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 device, it is not recommended to enable this. Note that, the more records stored, the slower the response in the discovery feedback view.


11.0 Importing Devices for Discovery In the ITA v7.0 bin directory is a utility that will allow the user to import a list of nodes (or devices) for discovery. The user may wish to do this for several reasons:

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

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

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

Making each device its own discovery range – 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 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. An example of a simple import file is:

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. Optionally, a template, to be discussed next, 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) – a template is used to provide this information. A template is no more than a discovery range itself 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. Template names can be one of:

• 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 it as a template is used. 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 – this entry that does not have 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 (to be provided below) to delete these templates after a successful import of the file (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 devices he wishes to import into IT Assistant for discovery. Since all devices share the same protocol settings, Tom does not need to specify template names after any of the devices. Toms 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 devices and then run the utility to import the devices. Tom follows the following steps:

1) Tom selects Discovery and Monitoring-> Ranges menu in the ITA UI, and then selects Include Ranges, right-clicks, then selects New Include Range…

2) Tom selects Hostname in the first wizard step, and then enters the name of default_template.

3) Tom steps through the rest of the New Discovery wizard, adjusting the protocol settings to his network, and then saves the range.

4) Tom executes the following command: importnodelist tomsnodelist.txt to import the list of devices.

5) Tom optionally adjusts his discovery interval for the devices just entered by selecting Discovery and Monitoring->Discovery Configuration… menu.


12.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 in this white paper for diagnosing the issue.

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

When examining this problem, bring-up the Discovery Details dialog from the Discovery Logs view (from a right-click action) 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 devices that are not on the network.

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

i. Is the device 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 white paper 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 device, 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 white paper for information on how to do this), then look at the Checkpoint field (the fields are delimited by a “|” character – this file can be imported into Microsoft Excel) – if the field ends at “(CIM check begin)”, this is an indication that the CIM protocol is hanging the discovery thread. The discovery of this device should be moved to a discovery range that does not use the CIM protocol (SNMP may need to be setup 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 device. Server devices running a Server Agent older than version OpenManage Server Agent (OMSA) v4.5 or Server Administrator v1.0 are strongly advised to upgrade the agent for best results.

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 if 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 – if the Checkpoint field for the task has not progressed in 30 minutes – 1 hour, it is likely the task is hung.

2. My device 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 device came back up. Check the device summary for that device to see when the last status poll has run. A status poll of the device can be done through a right-click action from the device.

ii. The ping being performed on the command line is a different device than where IT Assistant services reside. Make sure you are performing the ping from the system where the IT Assistant services are installed. Or, the new Troubleshooting Tool can be used to perform a ping test – this tool can be launched from a right-click action from the device.

iii. The ping timeout in IT Assistant needs to be increased. The Troubleshooting Tool can be used to perform a ping test while varying the timeout. If a timeout needs increasing, make sure to adjust the discovery range parameters after an acceptable value is found.

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 device (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 The Troubleshooting Tool can be used to perform a ping test - this test will show the IP Address used. If there is an IP address that the device can be reached by, but this IP address is not shown in the test, then the IP address need to explicitly be included in a discovery range.

v. Perhaps the IP addresses used by IT Assistant to ping the remote device are stale. Again, the Troubleshooting Tool can be used to determine what IP address(es) are being used. The device’s summary page can be checked for the last time the device was discovered. If the device was discovered by hostname and DNS is present in the environment (and it is preferred in ITA), it is possible to refresh the device’s IPs by right-clicking the device and performing a refresh inventory. Otherwise, the discovery range the device was discovered on will need to have a user-requested discovery performed on it. This is possible through a right-click action on the discovery range itself.

vi. Another device received the IP address of the one that is in a down state. When discovery runs, it updates all IP addresses for a device – during this time, it looks for any other device that also has any of these addresses – for those other devices, their IP addresses which are the same are marked as not pingable (note that the Troubleshooting Tool will only attempt to ping the pingable IP addresses during a ping test for a device, so this test will indicate what pingable IP addresses the device currently has – this tool may also indicate if the device has no pingable addresses, which likely indicates another device has the IP address as pingable). The assumption is no two devices can share the same IP address and discovery will have an accurate


picture of the network (all IP addresses for all discovered devices updated) when it completes. In a DHCP environment, it is possible for devices to exchange IP addresses, especially if they have been disconnected from the network or powered off for a while. If a device 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. The reporting system can be used to show if two devices share the same IP (select the IP Address column from the NIC table and sort on the IP address column). If one of the devices remains up after a status poll is performed on it, then it is likely the device that has the IP address marked as pingable – the other device should transition to a down state after a status poll. This situation indicates one or more duplicate entries are present (the same device was discovered under different name(s) and the entries could not be correlated to one device due to insufficient information) – it is recommend to delete the entry not wanted and perform another discovery – if this entry shows up again, then name resolution (or protocol detection) is not working as desired. Note that if it is necessary to see which device has the IP address as Pingable=1, the database utility dcdbmng,exe can be used to view this information in the DeviceNICView table.

vii. The device that has gone down in IT Assistant is actually a duplicate entry. Although the discovery service attempts to eliminate duplicate entries (you have a duplicate entry if you have the same device known by two different names – these names are usually similar, but one can be an IP address) by using the MAC addresses of the device (a MAC address, assigned to the network interface of the device, uniquely identifies a device), it must use one of the supported protocols (SNMP/CIM) to retrieve the MAC addresses. If, during a discovery round, there is a problem to where 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 devices can have the same IP address, one of the devices in the IT Assistant database will likely not have any pingable addresses (the one that is down) because another entry has the same address. If the down device is a duplicate entry of another device, this device can be removed by deleting it – it is likely discovery is no longer updating this entry during discovery - this can be verified by performing a refresh inventory on the device, then checking the last discovery time on the device’s summary page.

viii. Discovery may not be updating the device information in the database due to the device 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 device is within a discovery range.

3. My device 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 device’s summary page to see when the last status poll and/or discovery ran. Perform a refresh inventory or status poll of the device to see if the state 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 device where ITA services are running.

iii. The IP addresses being used by status polling have changed since the last discovery cycle. It is important that discovery be run at regular intervals because it is discovery that updates the IP addresses for a device. To check the last time the device was discovered, view its summary page.

4. How do I know when a device was last discovered?

The device’s summary page will show the last time the device was discovered, inventoried, or statused.

5. How often should I run discovery?

Since networks can be very diverse, this is a difficult question to answer. However, if devices to be discovered get their IP addresses through DHCP, then the discovery should run at least twice as often (or half the time of) 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 poll) cycle was aborted, an entry will be placed in the NT Event Log by IT Assistant Services, or in the ITA Application Logs dialog (under the Tools menu). The event log entry also names the devices still undergoing a discovery when the abort occurred, so if a few devices are holding up another full discovery cycle, there may ways to optimize communication to these devices to speed-up discovery (or exclude these devices from ITA if not needed).

6. 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. It is suggested to get an idea of how long a status poll takes by observing the status poll progress in the Discovery Logs view, after all devices have been discovered. If there is the desire to know the status of a device (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 device/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, or in the ITA Application Logs dialog (under the Tools menu). The log entry also names the devices still undergoing a status poll when the abort occurred, so if a few devices are holding up another status poll cycle, there may ways to optimize communication to these devices to speed-up status polls (or exclude these devices from ITA if not needed). Non-scheduled status polls occur for a device when an event is received from that device; therefore, it is important that remote


device events (such as traps) are sent to ITA so that it may keep the status of the device as up-to-date as possible.

7. How often should I run a inventory poll?

The inventory poll schedule can be set to run less often than a discovery round, as the data collected during an inventory poll is less likely to change in a short period of time.

8. My device has not been discovered by ITA.

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

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

ii. The ping timeout in IT Assistant needs to be increased for the discovery range. Compare the round-trip response time from a command line ping of the device to IT Assistant’s timeout setting and adjust accordingly.

iii. The device name or IP address is part of an exclusion range. They are convenient to have, but can easily be forgotten after being configured.

The device responds, but shows up as unknown. If the option Discover only Instrumented Devices is selected in the Discovery Configuration Settings dialog, then unknown devices would not show up. If this option is selected, it is suggested to temporarily select All Devices to be discovered, and then perform a user-requested discovery to discover the device in question – if the device shows up as unknown again, go to the FAQ #9 below for more troubleshooting information. If the device still does not show up in the unknown group, restart IT Assistants services and perform a user-requested discovery again.

9. My device shows up as unknown in ITA.

Typically, if a device should be classified in IT Assistant (only devices running Dell agents are classified at this time), but if 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 reporting feature in ITA, the DeviceProtocols column can be shown. Refer to the section The Protocols Discovery Uses earlier in this white paper 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, or the read community name used is wrong, or the device is configured to reject SNMP packets from the ITA services system. If the


protocol being used is CIM, perhaps the password was mistyped. The Troubleshooting Tool can be used to perform several tests, including what protocols are detected on the device and what Dell agents are detected through those protocols (the success of these tests can depend on how the discovery range for the device was setup).

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.

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

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

This typically 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. FAQ #9 should be used to troubleshoot this problem, as it is very similar.

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

Although the discovery process attempts to eliminate duplicate entries by using the MAC addresses of the device (a MAC address, assigned to the network interface of the device, uniquely identifies a device) and sometimes the service tag of the device, it must use one of the supported protocols (SNMP/CIM) to retrieve the MAC addresses for both device entries. If, during a discovery round, there is a problem to where the MAC addresses cannot be retrieved, and the device name cannot be correlated to a previously stored entry, this can result in a duplicate entry. Typically, if the MAC addresses show up for a device under NIC Information section in the detailed summary page for that device, then ITA can retrieve the MAC addresses during discovery. If there are duplicate device entries, typically one entry will eventually show as a down status – this entry can be deleted because discovery is no longer updating it.

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

Since networks can be very diverse, this can be a tough question to answer. Some recommendations:

i. Configure discovery ranges that discover a maximum of around 250 devices for smaller networks and up to 500 devices per range for larger (several thousand devices) 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 devices), making each device a discovery range is not recommended. However, it is popular with some and is done, but discovery feedback is tougher to discern for this many discovery ranges and it makes protocol management difficult – see FAQs #13 and #14.

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

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

Importing (or configuring) host names for discovery means each hostname itself will become a discovery range. The Discovery Logs 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, it is recommended to reduce the number of discovery ranges that are configured, perhaps by using IP ranges rather than hostnames.

14. 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 section Importing Devices for Discovery earlier in this white paper 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.

15. I upgraded to ITA 7.0 from a previous version – what data is migrated?

Due to ITA v7.0 having a very different schema than any version in the past, there is little data that can be migrated. At this time, the only discovery data that is migrated is:

1) Global Configuration settings

2) Discovery Ranges

When ITA v7.0 is started for the first time, there will be no devices nor will any previously configured custom groups reside in the database – a discovery will need to be done and custom groups reconfigured. In addition, for the Event Management System, only configured actions are preserved – event filters will need to be re-configured. This was a hard decision, but was a result of the inability to map the old schema to the new one consistently for every scenario.

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


During a discovery or status poll, when IT Assistant detects that a device’s power status / network connectivity has changed, IT Assistant will generate an internal power status change event for that device. In addition, if traps are configured (enabled) in the dconfig.ini file, discovery will also initiate a trap for this event to the configured destination(s). If the device transitions to an up state, a device up trap is sent; if the device transitions to a down state, a device 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 device did lose power, one of the device’s NICs failed, one of the device’s NICs was disabled, the operating device is locked-up, some sort of hardware failure occurred on the device itself or on a piece of network hardware between IT Assistant and the remote device, port blocking software was installed on the device, or one of several other problems. In IT Assistant v7.0, device up/down traps are configured as off by default, since events such as these are now generated internally to the service – as always, the IT Assistant Event Management System (EMS) can be used to take actions on these events (these events are currently defined under the System Events category). These traps may look like they are actually being sent by the device itself, but IT Assistant is actually impersonating the device for which it sends the up/down trap; it inserts that deviceʹs IP address into the trap so that it appears that the trap came from that device. This implementation enables specific devices to be monitored for device up/device down events. Note that a device down trap may be the only event sent for a device that goes down, so it can be a useful feature for alerting IT Personnel remotely (via paging or email) that a device went down.

17. How can I mine the discovery/inventory data that is stored for reporting?

These tables 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. Or, an ODBC datasource can be configured for applications like Excel.

13.0 Conclusion IT Assistant version 7.0 has many new enhancements that warrant an upgrade from previous versions. Among these features is an enhanced discovery service. Not only is discovery faster than before, but is more reliable, configurable, and includes many new features requested by users. This white paper is meant to give users an insight into how this enhanced discovery service works and how to configure it for any network. For additional questions or suggestions, please email Roger Foreman, Dell Enterprise Marketing, at [email protected].

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, and PowerVault 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 2005 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 ... · • support for enhanced...

Documents