Deployment requirements

Requirements and procedures

Desktops for technical consultant

  • 1 Desktop/Laptop
  • Standard browser
  • Access to the appliance and Windows proxy
  • Software installed or permission to install:
    • PuTTy (or other tool to SSH to the BMC Atrium Discovery appliance)
    • WinSCP (or other tool to secure transfer data to the BMC Atrium Discovery appliance)

Hosting for virtual appliance

  • Packaged in a compressed tarball image that contains a single VMware virtual image compatible with either of the following products from the VMware suite:
    • VMware Virtual Infrastructure (ESX Server version 3.0.2 or later)
    • VMware Server (version 2.0 build 122956 or later)
  • With the following configuration:
    • CPU: 1
    • RAM: 2048MB
    • Hard Disk: 1 x SCSI 54 GB (set to grow as necessary in 2 GB file increments)
    • CD/DVD Drive: 1 (auto detect)
    • Network Interface Cards: 1 (eth0) bridged, configured to use DHCP to obtain an IP address.

    The Network Interface Card (eth0) is configured to use DHCP. However, this can be changed to use a static IP.
    During the install process, the following network configuration is required:

    • DHCP or static IP for eth0 interface
      If Static IP then provide the following:
      • Appliance IP Address
      • Gateway
      • Subnet Mask
      • DNS for address lookup


    For initial testing at a small scale, the default configuration is sufficient. For production use, or use at scale you must increase the RAM, CPU and disk configuration in accordance with the sizing guidelines. One size Virtual Appliance is supplied, because a single size simplifies delivery and does not require you to download various sized VMs for various applications such as scanning and consolidation appliances.

    2GB RAM is insufficient to activate a TKU in an acceptable time. To use a TKU in testing, you must increase the amount of RAM in the system to 4GB or more.

Windows proxy

The following table provides information on compatibility between Windows proxy types and versions, and the operating systems that the Windows proxy runs on for BMC Atrium Discovery version 8.3.

Windows Proxy Type

Earliest Windows Proxy Version Supported

Windows Proxy Available for Supported Operating System

Credential Windows proxy

See getServices note below this table.

Windows 2003 SP2 (x86 and x86_64)
Windows 2008 - Service Pack 2 (x86 and x86_64)
Windows 2008 R2

Active Directory Windows proxy

See getServices note below this table.

Windows 2003 SP2 (x86 and x86_64)
Windows 2008 - Service Pack 2 (x86 and x86_64)
Windows 2008 R2


The getServices discovery method was introduced with BMC Atrium Discovery version 8.1. Windows proxies before version 8.1 do not support this method although are supported in all other respects.


The getFileSystems discovery method was introduced with BMC Atrium Discovery version 8.2. Windows proxies before version 8.2 do not support this method although are supported in all other respects.

Workgroup Windows proxy deprecated

The Workgroup Windows proxy has not been supplied since before BMC Atrium Discovery version 8.2. All of its functionality has been moved into the Active Directory Windows proxy.

Windows Proxy type

Earliest Windows Proxy Version Supported

Windows Proxy Available for Supported Operating System

Workgroup Windows proxy
Not available with version

See getServices note above this table.

Windows Server 2008 (x86 - 32bit)
Windows XP - Service Pack 2 (x86 - 32bit)
Windows 2003 - Service Pack 2 (x86 - 32bit)
Refers to 8.1 version.

Minimum host specification

The following are the minimum recommended specifications for the Windows proxy host:



Operating System

As stated in tables above


2GHz Intel Pentium® 4 CPU 512k Cache (or equivalent from other manufacturer)



Hard disk


To avoid any impact during resource-intensive periods of discovery, it is strongly recommended not to install the Windows proxy on any host supporting other business services. This is true even if the minimum Windows proxy specification is exceeded, since the Windows proxy will attempt to use what resources are available, in order to optimize scan throughput.

Windows discovery communications

You should also consider the ports that will need to be opened in any firewall between the appliance and the proxy or proxies, and the proxies and target hosts.

Windows discovery metadata

Discovery metadata covers Windows as well as UNIX. This provides information about why sessions failed to be established and why scripts failed to run, including information about what credential or Windows proxy was used.

IP/Subnet details for the target Data Center

  • IPs or Subnet(s) or combinations
  • IPs to be excluded

Access and permission to scan

  • Network access to all hosts
  • Change Approvals to scan

Credentials to login to each target host

  • Windows:
    • Local admin account with WMI rights
    • Admin share available
    • Netstat (if not available)
  • UNIX:
    • sshd
      (if not available)
      • ssh key or standard user account
    • sudo
      (if not available)
      • sudoers file for privileged commands
    • lsof version 4.78 or later
  • SQL Discovery
    • Database account with read access to databases in scope
    • Rights to run specified SQL queries on databases to be discovered

Credentials to discover virtual containers

  • ESX
    • All Linux requirements
    • Privilege to run esxcfg-info
  • Xenserver
    • all Linux requirements
    • Privilege to run /opt/xensource/bin/xe host-* commands
  • VMware server
  • Solaris Zone container

Commands required to discover host communications

  • Netstat
  • lsof
  • Tcpvcon for Windows 2000 and older

Hosting platform for ongoing data consumption of baseline data after solution decommissioning

  • Snapshot of Baseline on a view only BMC Atrium Discovery version
  • Virtual Appliance for Community Edition of BMC Atrium Discovery
  • Alternatively a desktop or Laptop

Additonal information

Firewall access

This diagram illustrates a deployment with firewall access.

UNIX discovery

Discovery uses:

  • Credentials
  • Access Methods
  • Discovery Commands

This diagram illustrates a Unix deployment.

UNIX credentials

Login via: SSH (keys) OR user name/password

The preferred method is SSH Key authentication. This is based on public-key cryptography where "encryption and decryption are done using separate keys, and it is not possible to derive the encryption key from the encryption key. The server knows the public key, and only the user knows the private key".

The BMC Atrium Discovery appliance counts as the 'user' (or 'client'), because it is trying to log in to the target host(s) (the 'server').

  • For this deployment you would access the private key that matches the public key already deployed in each target host's authorized_keys file.
  • The private key is usually contained in a file named id_dsa or id_rsa and should be put in the /usr/tideway/.ssh/ directory with 600 (rw-------) permissions.

UNIX commands

  • Standard user with non-root privileges
  • Can only run commands that any standard user could run on the target host
  • sudo is used for privilege escalation
  • When setting up the sudo rules on the target Host, BMC Software specifies the command and arguments so that only that command with the designated argument can be run.
  • This prevents the risk of spawning any arbitrary commands

Windows discovery

This diagram illustrates a Windows discovery deployment.

Windows credentials

  • Uses the Active Directory (AD) Windows proxy.
  • The AD Windows proxy does not use any credentials entered using the BMC Atrium Discovery user interface.
  • Each functional area has its own user account and dedicated Windows proxy.
  • The BMC Atrium Windows proxy is deployed on a customer-supplied standard Windows host managed by the local AD operator in each functional area.
  • Multiple windows AD Windows proxies can be connected to one BMC Atrium Discovery appliance.
  • By using this approach BMC Software reduces the exposure in each functional area to the same access level that an AD operator in that functional area would have. The BMC Atrium Discovery appliance or operator would never know the Windows AD password.

AD Windows proxy security

  • Standard Customer Windows Server Build (Windows 2003)
    • Standard Patching and Service Packs
  • Two distinct accounts
    • Windows proxy Discovery Service
    • Log in to Windows Server running the service
  • The user managing the AD Windows proxy will never have access to the account which performs discovery
  • Cannot use the Windows proxy service account to log in to Windows servers interactively

Appliance specification

Physical (provided by BMC Software with BMC Atrium Discovery bundled with RedHat Linux OS). The appliance specification is sufficient for daily full discovery of at least 5000 OSI, with keeping a discovery history of 100 days (a typical configuration).

  • Physical Appliance Spec
  • Specification
  • Physical Specification
  • Power Specifications
  • Environmental Specifications

HBA card discovery on Windows

If WMI cannot be used, some tools are required to be installed on Windows to find the HBA cards. For more information, review the section getHbaInfo in the Windows Operating system page.


  • lsof(1) is a UNIX specific diagnostic tool. The name lsof stands for "LiSt Open Files" and is developed by Victor A. Abell, retired Associate Director of the Purdue University Computing Centre.
  • lsof(1) is a command used in many UNIX systems that is used to report a list of all open files and the processes that opened them. It works in and supports several UNIX types.
  • Open files in the system include disk files, pipes, network sockets and devices opened by all processes. One use for this command is when a disk cannot be unmounted because (unspecified) files are in use. The listing of open files can be consulted (suitably filtered if necessary) to identify the process that is using the files.
  • If the lsof(1) command is not used. BMC Atrium Discovery will not be able to extract communications open (systemwide) by each process.
  • More information is available on lsof is available at

Microsoft Windows 2000 and older versions

For Microsoft Windows 2000 and Microsoft Windows NT, the program-to-program communication dependency is not available through native Windows tools. In order to get the full dependency model, BMC Atrium Discovery requires an additional tool to be available on the Windows hosts. The following tools are currently supported by BMC Atrium Discovery:

  • PSINFO utility is supplied by Sysinternals ™. More details are available on the official website:
  • Tcpvcon – Full details of Tcpvcon are available from the official website:

    Tcpvcon EULA

    Recent versions of this tool require a GUI-based license agreement to be confirmed the first time it is run. This will cause problems if ADDM tries to run it on a server that has not had this. After confirmation, a registry key HKEY_USERS/<UID>/Software/Sysinternals/TCPView/EulaAccepted=1 is created.

  • OpenPorts – this utility was supplied by DiamondCS but is no longer available.

If Windows NT or 2000 is to be discovered as the platforms for the business applications, one of these tools will need to have been deployed before scanning the target host.

Was this page helpful? Yes No Submitting... Thank you


  1. Blaine Simpson

    The instructions above in section "UNIX credentials" under the bullet "The private key..." are wrong. Keys for discovery should definitely not be put into that directory. They should be uploaded using the Host Credentials page of the UI. Read the file ~/.ssh/README.ssh on the appliance if you want to know why.

    Feb 20, 2012 04:13
  2. Blaine Simpson

    I understand that AD Proxy is preferred, but the Credential Proxy is there for a purpose and is often needed in DMZs, labs, etc. This page, especially the "Windows credentials" section, is written as if Credential Proxies do not exist.

    Feb 20, 2012 04:24