Playbook: Repair duplicate Jira Service Management assets from a Lansweeper sync

This playbook shows you how to use Assets Data Manager to refresh stale Lansweeper asset keys in an Assets schema, so a Lansweeper data sync stops creating duplicate objects in Jira Service Management.

Why asset keys go stale

When you import assets into Assets in Jira Service Management, through the Lansweeper Marketplace app or Assets Data Manager, Lansweeper stamps each object with an asset key. When Lansweeper reconciles, renames, or re-scans an asset for the first time, it can assign the asset a new key. The import method then fails to match the asset on the next run and creates a duplicate object for each new key.

Assets Data Manager lets you update these keys in bulk without rebuilding the schema.

Before you start

Check your scanning health

Stale keys are a common cause of duplicates. But the real problem can be a scanning issue that Lansweeper's reconciliation engine hasn't yet resolved. Before you run the cleanup, check that your scanning configuration is healthy. See Understand the reconciliation engine.

What you need

• An active Lansweeper data source configured in Assets Data Manager.
• A target schema that the Lansweeper import method is populating.
• A saved search in Assets Data Manager that returns the objects you want to repair.
• A LansweeperKey attribute (or equivalent) already mapped on the target schema.
• The Lansweeper import method sync paused until the cleanup is complete. This stops the import method creating new duplicates while you repair the schema.

Refresh the stale asset keys

Step 1: Import Lansweeper data into Assets Data Manager

If you don't already have a Lansweeper import configured in Assets Data Manager, set one up now using the Lansweeper data source. Use the "cloud-to-cloud" option.

When you configure the data source field mapping, set the primary key to the same attribute you use for deduplication in the target schema. For example, use the serial number, MAC address, or fully qualified domain name (FQDN). This lets Assets Data Manager match records by a different identifier and refresh the asset key attribute. Verify that you have mapped the Lansweeper Asset Key field to a Data Manager attribute, for example LansweeperKey.

Fetch, transform, map, cleanse, and merge the data in Assets Data Manager. Assets Data Manager now holds a current copy of your Lansweeper inventory, including up-to-date asset keys.

Step 2: Create a saved search

In Assets Data Manager, create a saved search that covers the object class of the objects you want to clean up and repair, for example, recently updated Windows computers. This search becomes the data source for the repair import in step 3.

Step 3: Create a temporary cleanup import configuration on the target schema

Go to the target schema in Assets in Jira Service Management, the schema with stale or duplicate objects. Create a new import configuration of type Assets Data Manager.

For each object type import mapping, map only these 3 fields:

Step 4: Set the identifier

Select the identifier checkbox on the deduplication attribute: MAC address, serial number, or FQDN. This tells the import engine to match incoming records to existing objects on that attribute instead of creating new objects.

Step 5: Run the import

Run the import. The engine matches each incoming record to an existing object using the identifier attribute. It then writes the updated LansweeperKey value over the stale one.

Step 6: Verify

Check a sample of objects in the schema. The LansweeperKey values now match what Lansweeper reports for those assets.

From this point, the import method finds the correct keys on its next run and updates the existing objects instead of creating duplicates.

If duplicates reappear

If duplicates return after the import method runs, repeat the process. Reimport from Lansweeper into Assets Data Manager, then run the cleanup schema import again to refresh the keys. If duplicates keep recurring, this can point to an ongoing scanning or reconciliation issue. Go back to Check your scanning health and review your scanning configuration again.

If the duplicates are in Assets Data Manager itself

If duplicate objects are showing up in Assets Data Manager rather than in the target schema, the fix is different.

Assets Data Manager doesn't ship a built-in option to clear an object class and start again. Atlassian has an open feature request for this: JSDCLOUD-15900. Objects persist by design until they no longer appear in any configured source data.

To clear an object class, clean out the Lansweeper data source and reimport:

1. Go to Assets Data Manager > Settings > Data Sources.
2. Delete the Lansweeper data source, or sources, that feed the object class you want to clear.
3. Rerun the import. Without a source feeding records into the class, the existing objects drop out.
4. Confirm in the Analysis view that the object class is now empty.

Recommended settings for cleaning up old duplicates

Object type mapping in the assets schema import includes settings that help you clean up objects that no longer appear in your import source due to Lansweeper and Data Manager reconciliation. See Create objects from data using object type mapping.

Missing objects

This setting controls what happens to objects that were created or updated by the import structure but no longer appear in the current import. Choose one of:

• Remove: Deletes objects that aren't found in the current import structure but were previously created using it. Use this to cleanse your data by removing objects that weren't found in the last import.
• Update: Updates an attribute on objects that aren't found in the import structure but were previously created or updated using it. Use this to mark which objects were missing from the last import, for example setting a status to "reconciled".
• Ignore: Makes no changes. Use this if you don't want missing objects handled automatically, and manually remove stale records and duplicates.

Threshold number

The threshold number is how many times an object can go missing from the import source before the Missing objects rule is applied. This is a safety feature that stops objects being removed or updated immediately after a single missed import.

Set the threshold in line with how often the import produces stale records, a higher threshold for more frequent imports, so a single import doesn't trigger the rule prematurely:

Adjust within this range based on how reliable your import schedule is and how tolerant you want to be of stale records before the Missing objects rule applies.