A server must be uniquely identified by CAM to ensure that multiple versions of a single device are not created during a scan operation. Consider the case when a device has multiple NICs and is scanned using all available IP addresses. The generation of an unique identifier for a device is normally performed by executing commands that are native to the O/S of the device (on a *nix box,dmidecodewould be such a command; on Windows, WMI/Remote Registry Requests would be used). There may be one or more native commands that can be used in this process.
In some cases, the commands on which the identification of a device depends return invalid or empty responses, or consistently time out. This would typically mean that the device cannot be uniquely identified and would be rejected.
|
The native command failures can normally be resolved by the appropriate configuration of WMI, Remote Registry and SSH commands by modification to user and credential configuration. These modifications should be discussed with the Customer Success staff and your own IT/Security staff. Additional testing can be carried out by using the WBEM test tool (can be run from any windows machine and/or by running tests directly from the appliance command line. For information about the latter see: Running WMI commands from the appliance. Only in the (unusual) scenario where an appropriate modification is not possible should the scan operations be modified to use the additional features described here. Please seek advice from CloudSphere staff prior to their use. |
Using Generate Identifier Flags
The CAM product provides a feature (associated with the scan operation) that allows a secondary method to be used. The method is not based upon the execution of native commands and is, therefore, always successful and will always allow a device to be successfully created. In order to make this a permanent value associated with the device, the value is written to a file on the server and is used as the device identifier from that point on.
Control of this feature is provided through the “Enablings” section of the scan Job Configuration. There are three flags that are associated with the use of a generated ID.
- enableGeneratedID
- removePrevGeneratedID
- forceGeneratedID
enableGeneratedID
This is the flag that identifies that for all servers associated with a scan job if a native command (or set of commands) fail to execute or return no data then use a CloudSphere-generated Identifier. “Use”, in this case, means either
- look for a file that holds a CloudSphere generated Identifier (generated during a previous scan) and use the store value
- if no file exists then generate a value, store it in a file on the device and use it as the identifier.
removePrevGeneratedID
This is the flag that forces the removal of all existing files on the servers that hold generated IDs that are being scanned. This is the means to “reset” any existing CloudSphere-generated IDs.
forceGeneratedID
This is the flag that identifies that for all servers associated with a scan job, ignore all native commands (regardless of whether they execute successfully or return data) and always use a CloudSphere-generated Identifier. “Use”, in this case, means either
- look for a file that holds a CloudSphere-generated Identifier (generated during a previous scan) and use the stored value
- if no file exists then generate a value, store it in a file on the device, and use it as the identifier.
This flag is useful when native commands would generate an identical identifier across more than one distinct device.
Usage
A flag must be set in a Job configuration to enable one or more of these flags. The following section identifies an example where the EnableGenerateId flag is applied to a job. This process can specify one or more of these flags at the same time.
The flag is set in the “Enablings“ section of a Job configuration.
To configure this option go to Discovery → Scan Jobs
Then either select an existing Job or create a new one.
Now select the details tab.
Under the “Enablings” field add the option “EnableGeneratedID“.
Once the servers within this job's scope have been scanned, they will be discovered with a CloudSphere-generated identifier (if the native commands cannot generate a suitable identifier).
Although more than one flag can be specified in conjunction with the others. there are a number of negative interactions that could occur with overlapping flag settings and the scan operation will warn about them. The following combinations will generate a warning in the ScanInfo:
|