Notes:
1 - When it is necessary to run tw_model_wipe, save as many items as possible first:
-
- If the UI is available, most items can be saved
- If the UI is not available, then some items may possibly be saved, depending on which services it is possible to start:
-
-
- Discovery >= tw_model_wipe 12.0 backups the configuration data by default but requires the model and security services to be started
- Discovery <= tw_model_wipe 11.3 doesn't offer the option to backup the configuration first
2 - The following detailed steps were written mostly for a version 11.3 appliance. These steps are similar for earlier and later versions, but may vary.
3 - Expanded list of the items that ARE removed when running tw_model_wipe or tw_model_init:
LEGEND:
*** items are common to most scanners and consolidators
** items are typically found only on a consolidator
* items are typically found only on a scanner
a) *** All discovered data will be removed, all historical data, anything stored in the datastore is removed
b) *** DDD Removal Blackout Windows
c) *** Configuration as a scanner or consolidator
d) *** User Queries
e) *** The TKU will be reverted back to the older TKU originally shipped with your release
f) ** Root node keys used for integrating with the CMDB are removed
g) ** CMDB Sync configuration (connections, filters, and CMDB Sync blackout windows)
h) ** CAM (saved queries, groups and subgroups, named values, functional component definitions, and generated patterns)
i) ** SAAM Model definitions
j) ** StaticApp models (i.e. manual groups where the name begins with "StaticApp:")
k) * Scheduled scan ranges
l) * Exclude ranges
m) * Registered Windows proxies
n) *** Any custom patterns
o) ** model rules
p) ** Custom Categories such as: Location, Organizational Units, etc.
q) *** LDAP integration
4 - Items that ARE removed when running tw_model_wipe:
The Discovery Credentials (in Manage > Credentials) are not wiped from the appliance, as these are stored in the appliance credential vault.
5 - Known problems with below procedure:
-
- The patterns generated from the procedure "Creating SIs from discovered processes or services" and their inferred SIs are usually displayed in two web pages:
- Model > Software
- Manage > Knowledge (generated modules). At the end of this procedure, this information will only appear in page #2. Page #1 will stay blank. This has no impact on the scan result. This only displays some information (generated pattern and inferred SIs) in one page instead of both.
- Each imported SAAM models will have to be manually opened/edited and published one by one. This typically takes 20-30 seconds per imported SAAM model. An RFE was filed on communities to request for to enabling the publication of multiple SAAM models at once.
- For Discovery <=21.05: The page Explore > Reports > "Imported root node key information which has not been used" would continue to report the keys of some nodes even after having rescanned/recreated them with the same key. This had been reported as defect DRUD1-25165 and was fixed in 21.0. The workaround is to manually select and delete the unexpected nodes.
- For Discovery <= 20.08: DRUD1-25418. The BMC_Application CIs matching the SAAM models will be marked as deleted and replaced by a new CI with the same attributes and a different ADDMIntegrationId. Running the Reconciliation Engine twice will unmark these CIs as deleted. However, this won't unmark as deleted the relationships that were manually added to these CIs in BMC.ASSET. A workaround is documented in Discovery: After a tw_model_wipe, the imported SAAM model creates BAIs with new keys, causing the deletion of some of the BAI relationships.
Steps to take before a tw_model_wipe or tw_model_init:
Note that none of these "before" steps can be performed if the model service is not running, and most can not be performed without an access to the UI.
- For any appliance/cluster that performs CMDB Sync:
1) (item f) Use the procedure in Discovery: How to perform import and export of root node keys to export the root node keys (Run the commands on any cluster member or on the standalone appliance):
The basic command is: tw_root_node_key_export /usr/tideway/root_node_keys.xml (But, please see Discovery: How to perform import and export of root node keys for full instructions).
Note: It is not possible to run this utility if the model service is not running.
2) (item g) Take screenshots of the CMDB Sync Connection Details page
Administration->CMDB Sync-><your connection> -> Details-> take screenshots showing all information for each connection
3) (item g) Export the filters for CMDB Sync:
Administration->CMDB Sync-><your connection> -> Filtering -> Actions -> Export filtering definition
4) (item g)Take a screenshot of any CMDB Sync blackout windows
Administration->CMDB Sync-><your connection> -> Blackout Windows -> take screenshot
- For any appliances with application models. These are usually only found on an appliance that performs CMDB Sync:
5) (item h) Export CAM mapping definitions
Model->Applications->CAM Models-> Select All -> Actions->Export Application Mapping Definitions
6) (item h) Save the CAM-generated TPL:
Manage->Knowledge-> Generated -> Apply->Select All -> Actions->Download Selected Modules
Rename the downloaded file to "tideway_generated_cam_patterns.zip"
7) (item i) Export SAAM model definitions
Explore->Data->Model Definitions-> Select All ->Actions->Export Application Model Definitions
If nothing is returned, try also:
Model->Applications->Other BAIs->Select All->Actions->Export Application Model Definitions
8) (item j) StaticApp: models - Take screenshots or get csv exports (if possible) to save a list of all the objects in these models
- For any appliance:
9) (item b) Take a screenshot of any DDD Removal blackout windows:
Administration->Model Maintenance->DDD Removal Blackout Windows -> take screenshot
10) (item c) Take a screenshot of the Discovery Consolidation page.
Administration->Discovery Consolidation->take screenshot
11) (item d) Save the User Queries. See Discovery: How to export / import saved user queries from Discovery?.
12) (item e) Take a screenshot of the Manage>Knowledge page, that contains details of the TKUs that are loaded.
13) (item n) Save all custom patterns:
Manage->Knowledge->Custom -> Apply->Select All -> Actions->Download Selected Modules
Rename the downloaded file to "tideway_custom_patterns.zip"
14) (item o) Save all model rules
Manage->Model Rules, Select All -> Actions->Export Model rules
15) (item p) Export any Custom Categories that are specified:
Visit Explore->Data->Context&Metadata. Choose the type of data that needs to be saved, such as Location or Organizational Units
Click Customize. Add all attributes to the query.
Export all results to CSV file.
16) (item q) Take the backup (or screenshot) of the LDAP connection details i.e. go to Administration -> LDAP.
- For Scanners:
16) (item m) Save Windows Proxy information with screenshots
Manage->Credentials->Windows Proxies
17) (item l) Save Exclude Ranges.
Run this generic search query"
search in '_System' ExcludeRange show name as 'Label', scope as 'Scope', range_strings as 'Range', recurrenceDescription(schedule) as 'Date Rules', description as 'Description', fullFoundationName(created_by) as 'User'
18) (item k) Save Scheduled Scan Ranges:
Run this generic search query:
(Discovery 11.2 and below) search IPRange where not scan_type = 'Snapshot'
show label, range_string, scan_level, recurrenceDescription(repeat) as 'Date Rules', scheduling_user, created_time as 'Created', enabled
(Discovery 11.3+) search ScanRange where not scan_type = 'Snapshot'
show label as 'Label', scan_level as 'Scan Level', created_time as 'Created', enabled as 'Enabled', range_strings as 'Range', schedule as 'Schedule'
Select All
Actions->Export as CSV
Then, perform the tw_model_wipe according to the Documentation:
1) run tw_model_wipe --force
-- this will run quickly.
For a cluster, this can be run from any member. Model wipe is cluster aware.
NOTE: In 12.0 and later versions of Discovery, if you want to preserve configurations the tw_model_wipe will fail unless the model and security services are running.
If the model service does not start, then use the new option (added in 12.0 and later) like this:
$ tw_model_wipe --force --do-not-preserve-configuration
2) Start the services
-- this will take more time, possibly 45 minutes or longer
Steps to take after tw_model_wipe or tw_model_init:
- For any appliance/cluster that performs CMDB Sync:
1) (item f) Use the procedure in Discovery: How to perform import and export of root node keys - INCLUDES VIDEO to import the root node keys (Run the commands on any cluster member or on the standalone appliance):
The command is: tw_root_node_key_import /usr/tideway/root_node_keys.xml (but please see Discovery: How to perform import and export of root node keys - INCLUDES VIDEO for full instructions)
- For any appliance:
2) (item e) Upgrade the TKU to the version that was active before the model wipe, or a more recent version
For any appliances with application models. These are usually only found on an appliance that performs CMDB Sync.
- For any appliances with application models. These are usually only found on an appliance that performs CMDB Sync:
3) (item h) Import the CAM model definitions:
Model->Applications->Create/Import->Import
4) (item h) Load the CAM-generated patterns
Manage->Knowledge->Upload <"tideway_generated_cam_patterns.zip">
- For any appliance:
5) (item n) Load the desired custom patterns
Manage->Knowledge->Upload <"tideway_custom_patterns.zip">
6) (item b) add DDD Removal blackout windows
Administration->Model Maintenance->DDD Removal Blackout Windows
7) (item d) to re-import the user queries, see Discovery: How to export / import saved user queries from Discovery?
8) (item p) to re-import Custom Categories:
Admnistration->Import CSV. Choose csv file. Update Mode = "Create Only". Node Kind = Location, OrganizationalUnit, etc.
Click Apply. After import, verify the count of locations, etc, are correct.
- For Scanners:
9) (item k) It's not possible to re-import the Scheduled scan ranges, but the exported list can be used as a guide to recreate them..
10) (item l) It's not possible to re-import the exclude scan ranges, but the exported list can be used as a guide to recreate them..
11) (item m) Recreate Windows Proxy definitions
- For any appliance:
12) (item c) Reconfigure as a scanner or consolidator
- For any appliance/cluster that performs CMDB Sync:
13) (item g) Reconfigure CMDB Sync, import Filters, recreate CMDB Sync Blackout Windows
After setting up the CMDB Sync connection, a Resync is required. However, do not Resync yet until after going through the remaining steps. See step#16.
- For Scanners:
14) (item a) Run Discoveries on scanner.
- For any appliances with application models. These are usually only found on an appliance that performs CMDB Sync:
15) (item i) Import the SAAM models (after the necessary data has been discovered on the appliance) and publish them.
16) (item o) Import the model rules (Manage -> Model Rules, Action -> import Model Rules)
17) (item j) Re-build the StaticApp: models (after the necessary data has been discovered on the appliance)
- For any appliance/cluster that performs CMDB Sync:
18) (item g) To get the data back into the CMDB, Scan the entire estate, and then run a Resync.
Make sure to scan the entire estate before the Resync. Otherwise, all data in the BMC.ADDM dataset will be deleted.
NOTE: After a tw_model_wipe, even if the root node key info nodes are imported, any imported SaaM models will create BAIs with new keys after publishing.
After resync, the BMC_Application CIs matching the SaaM models are marked as deleted and replaced by a new CI with the same attributes and a different ADDMIntegrationId. Running the Reconciliation Engine twice will unmark these CIs as deleted. However, this won't unmark as deleted the relationships that were manually added to this CIs in BMC.ASSET.
The workaround, to avoid the deletion of the relationships that were manually added to these CIs in BMC.ASSET, is to manually hard delete all the BMC_Application CIs in BMC.ADDM that have MarkedAsDeleted=YES after a resync and before running the Reconciliation Engine. This allows RE to directly identify the new BMC_Application CI of BMC.ADDM with the one in BMC.ASSET and it does not change the MAD attribute. Therefore there are no marked as deleted relationships in BMC.ASSET.