Duplicate device IDs in registry block new device enrollments and cause provisioning failures

IoT PTC ThingWorx
, , , , , , , ,
1

We’re unable to enroll new devices because the registry throws duplicate device ID errors, even though the devices are genuinely new. We used bulk import to provision 500 devices last month, and now when we try to add new ones, we get:


Error: Device ID already exists in registry
Device: DEV-2024-0501
Status: PROVISIONING_BLOCKED

The strange part is that DEV-2024-0501 doesn’t appear in our device list when we query the registry through Composer. Bulk import validation must have created phantom entries that aren’t visible but still block enrollment.

We need to enroll 200 new devices this week. Is there a way to check for duplicate device IDs via REST API before attempting enrollment? Our current process doesn’t have any pre-check validation, and we’re manually discovering duplicates only when enrollment fails. Device ID uniqueness enforcement seems stricter than our import process anticipated.

2

I ran CleanupFailedDevices for the date range of our last bulk import, and it removed 47 orphaned entries. However, I’m still seeing duplicate errors for some device IDs. Is it possible that the cleanup service doesn’t catch all failure states? Should I run it multiple times or with different parameters?

3

The phantom entries are likely in the registry’s audit trail but marked as soft-deleted or in a failed state. Query the DeviceRegistry with includeDeleted=true to see them. You can use the REST API to pre-validate device IDs before enrollment. Call GET /Thingworx/Things/DeviceRegistry/Services/CheckDeviceExists with the device ID as a parameter.

4

Here’s a comprehensive solution addressing all three focus areas:

Bulk Import Validation: The root cause is that bulk import doesn’t validate device ID uniqueness across all registry states before creating entries. When imports fail partway through, some devices end up in limbo states that block future enrollments but don’t appear in normal queries.

To clean up existing phantom entries:

// Query all non-active device states
let states = ["PENDING", "INITIALIZING", "FAILED", "DELETED"];
states.forEach(status => {
  let devices = Things.DeviceRegistry.GetDevicesByStatus({status: status});
  // Review and delete orphaned entries
});

Run this cleanup script to find all problematic entries. Review each device’s creation timestamp - anything from your bulk import period that never reached ACTIVE status should be deleted.

Device ID Uniqueness Enforcement: ThingWorx 9.5 enforces device ID uniqueness across ALL registry states, including soft-deleted and failed entries. This is stricter than previous versions. The registry maintains historical records for audit purposes, which is why your deleted devices still block new enrollments.

To properly remove a device and free its ID for reuse:

Things.DeviceRegistry.DeleteDevice({deviceId: "DEV-2024-0501", permanent: true});

The permanent: true flag completely removes the device from the registry, including audit history. Without it, the device is soft-deleted and the ID remains blocked.

REST API Pre-Check: Implement a validation step before enrollment using the REST API:

// Pre-enrollment validation function
function validateDeviceId(deviceId) {
  let exists = Things.DeviceRegistry.CheckDeviceExists({deviceId: deviceId, includeDeleted: true});
  return !exists;
}

Integrate this into your enrollment workflow. Before calling the enrollment service, verify the device ID is truly available. This prevents enrollment failures and provides immediate feedback.

For bulk imports, create a pre-validation service that processes your import file:

  1. Read all device IDs from the import file
  2. Query registry for each ID with includeDeleted=true
  3. Generate a report of conflicts before starting the import
  4. Only proceed with import if all IDs are available

This approach catches duplicates before they cause failed enrollments. You can also extend it to check for ID format compliance, valid device types, and other business rules.

Immediate Fix for Your 200 New Devices: Run the cleanup script above to purge all orphaned entries from your previous bulk import. Then implement the REST API pre-check validation before enrolling your new devices. This two-step approach will resolve your current blockage and prevent future occurrences.

For long-term stability, consider implementing a device ID generation service that guarantees uniqueness by querying the registry before assigning IDs, rather than relying on external ID schemes that might conflict with existing entries.