The advice in this post is relevant for the 6.x range of Foundation. Additional techniques are available on the 7.x range.

You may decide to rescan a host with the information available in record data. This can be useful when you are consolidating multiple tideway appliances discovered (record) data into one appliance for reporting purpose.

The first thing you will do is change the discovery mode to playback in the UI

Method #1 - Using the Appliance Pool Data

1.  Scan the Windows machines (eg. 172.17.4.46) with a Slave connected to an Appliance.
2.  If you haven’t just scanned the host(s) and are loading data from another source you will only need the pool data sourced from the Appliance.
3.  Create a .no-expiry file in that host’s pool data on the Appliance. To do this for all hosts do: find /usr/tideway/var/pool/ -type d -links 2 -exec touch {}/.no-expiry \;
4.  At this time you should also confirm that the full set of pool data files are there (getInfo getInterfaceList getNames getNetworkConnectionList getPackageList getProcessList getProcessToConnectionMapping nmap-small), if not delete the pool data and rescan the host again. Make sure the pool-expiry isn’t set to -1 or something ridiculously low in ~/bin/tw_svc_discovery.
5.  Go into the Tideway UI and delete the host nodes for the Windows machines.
6.  Stop the Slave service on the Windows machine and stop the tideway service on the Appliance.
7.  For post-6.2 Appliances change the Discovery Mode in Setup->Appliance->System Settings.
8.  Scan the Windows IPs (eg. 172.17.4.46) in playback mode, there is no need to setup credentials.
9.  Once finished playing back data run find /usr/tideway/var/pool/ -type f -name .no-expiry -exec rm -f {} \; to remove the .no-expiry files and restore normal pool data functionality.
Note: When you use the PDA (Playback Data Archive) way of gathering the pool data, it creates the .no-expiry files for you as well. There’s also a script called tw_pool2playback which is a command line tool that creates a PDA called PFI_Data (Primary Foundation Instance, it came out of the BAM Lite work) from all the current pool data.

Method #2 - Using Record Data on the Appliance and Slave

1.  Scan the Windows machines (eg. 172.17.4.46) with a Slave connected to an Appliance.
2.  Delete the host nodes for the Windows machines.
3.  If you haven’t just scanned the host(s) and are loading data from another source you will need the record data sourced from the Appliance as well as the record data sourced from the Slave.
4.  Stop the the Slave service on the Windows slave host and set it to playback mode by altering the CommandLine value in the HKEY_LOCAL_MACHINE\SOFTWARE\Tideway\DISCOVERY\<Slave Type> Registry key.
5.  Appliance. For post-6.2 Appliances change the Discovery Mode in Setup->Appliance->System Settings.
6.  Create a file called os_type with the contents Windows in each record data directory for a Windows host. This script automates this process.
7.  Restart both services, make sure that the Appliance is connected to the Slave.
8.  If you are using a Credential Slave make sure there are some credentials for the IP ranges you want to playback. These credentials can be anything - and username and password as long as the password isn’t blank. This is not required for AD/Workgroup Slaves.
9.  Start Discovery and scan the host(s).

Method #3- Using existing appliance record data only

The below instructions are for Windows hosts. For Unix hosts you just need the record data on the Appliance and then you can set the Appliance to playback mode and do a scan.
1.  Create record directories on the slave and appliance for the host IP you want to scan. (eg. var/record/172/17/4/46/)
2.  Copy the record data to the slave.
3.  Check if your record data has a file called ‘nmap’ if not copy from another set of record data and edit the ip address in the file. Or create a file called os_type as above.
4.  Copy the nmap and nmap-small files to the record directory on your appliance.
5.  With your Slave and Appliance set to playback mode scan the ip address of your record data. (eg. 172.17.4.46)

This is very helpful - we’ve been struggling for a while to synchronise two appliances we use - one for live discovery, the other for reporting.  We rsync the pool data from the discovery appliance to the reporting appliance, and then extract IP addresses from the pool directory structure, followed by a tw_injectip using those addresses with the reporting appliance set to playback mode.

However, we encountered a number of issues with playback discovery on Windows/Unix boxes.  Currently the workaround we use is a shell script executed via cron that creates the .no-expiry files on ALL pool data and runs them all through discovery (which imports the Windows boxes), then 2 hours later (as I’m not aware of an easy way to make a script wait until a discovery run has completed) remove the .no-expiry files and run again, which imports the Unix boxes.

Does anyone have a more elegant solution to this??

Hi Ben, welcome to the forums.

You don’t mention which version of Foundation you are using, there are ways of using the 7.x data model to make this more elegant and the advice above is mostly intended for the 6.x editions.

Our services organisation has a number of best practise template solutions so making contact with them will also be helpful. The up coming 7.2 release will also employ more UI based tools to do consolidation.

We’re currently running 7.1.5 on all our appliances.  I’d be interested in an outline of the way you accomplish this using the 7.x data model.  I’ll also get in touch with services, though it’s not an urgent issue now that replication is working successfully.  Will be keen to see the new release in that case though.

The 7.2 release is looking at consolidating discovery, direct replication is coming a little later, similar tasks but slightly different.

In the 7.x releases you are correct on focusing on the pool data as this captures both Unix and Windows discovery. What you can do is exploit the data model to tell when discovery is finished. When you enter a Discovery Run you will get a DiscoveryRun node in the datastore, which will not have it’s endttime attribute set until it is complete.

So what you can do is poll the datastore to see which Discovery Runs are finished with a query like this, which will display the label and node id of all finished runs:

SEARCH DiscoveryRun
WHERE endtime IS DEFINED
SHOW label, id(#)

You can the query what the IP’s in each Discovery Run were by looking at the DiscoveryAccess nodes underneath. If you iterate over the node id you can use LOOKUP to do this:

LOOKUP ‘8324f2622d09757586665a486e446973636f7665727952756e’
TRAVERSE List:List:Member:DiscoveryAccess
SHOW endpoint

Note you will need to substitue the ‘<value>’ with the node id from your query.

You can then use this IP list both to transfer the pool data via scp and to use via tw_injectip to cause them to be scanned in.

You will need to look at using tw_query to run search queries from the CLI; probably with the—csv flag so you can more easily awk the results. Remember you can use ’ and ” interchangeably in the query, you might want to use ” in the query so you can strong quote it on the CLI:

tw_query -u system—csv ‘SEARCH DiscoveryRun WHERE endtime IS DEFINED SHOW label, id(#)’

I’d also advise using a specific user for this task and not the system account!

Some things you need to think about:
1) The first query will also pick up lot of historical queries. You can restrict this by looking for ones that have finished in the last day/week.
2) There is only ever one instance of pool data and it gets flushed on the next access to that endpoint. So you need to try and ensure that you don’t rescan an endpoint until it is finished initial scan and the consolidation.

A common solution to helping cope with this is to inject a known collection if IPs into the discovery appliance with a unique label (maybe datetime) and poll for this specific run to finish. This can then be repeated on the second appliance to play it back.

Hi

Are the methods described by Mehdi valid for ADDM v8.2?

No, these methods were replaced by consolidation some time ago now:
http://discovery.bmc.com/confluence/display/83/Consolidation

Please see http://discovery.bmc.com/community/forum/viewthread/2733/

I have managed to scan with our prod VM in playback mode, created a clone and put it into test. I then set it to playback mode. It can scan non windows ok, but trouble is with windows. Of course it wants to connect to the windows slaves, which are now unavailable due to the move of the appliance. Is there a way to do this for windows so that I can scan them in playback mode, without a connection to the slaves which are in prod, but my appliance is now in test?

Ah! new information :-) I’ll go back to your original thread then if you don’t mind…