How to manage Unknown devices under MECM deployment

In Configuration Manager (MECM), “Unknown” devices and “Client check passed / Inactive” devices are handled differently and should be managed with different actions.

1. Understand what “Unknown” and “Inactive” mean

• Unknown detection state (for software updates or WUfB-integrated devices):
  • Devices can appear with a detection state of Unknown when they are managed by Configuration Manager but use Windows Update for Business client policies. In this case, ConfigMgr can see the device but cannot fully evaluate update compliance, so the state is Unknown.
• Client check passed / Inactive:
  • The client is installed and passes basic health checks, but hasn’t communicated recently (for example, no policy or status messages within the configured time window). These devices are often powered off, off-network, or otherwise not actively reporting.

2. Managing “Unknown” devices (update compliance) When integrating Windows Update client policies with Configuration Manager, devices may show Unknown detection state for updates:

• This is expected behavior when Windows Update for Business policies are applied and ConfigMgr is not the source of update evaluation.
• Such devices are still visible in the console, but update detection state is Unknown.
• Management approach:
  • Use Windows Update for Business reports or Windows Update for Business reports in Azure to track compliance for those devices instead of relying solely on ConfigMgr compliance states.
  • Ensure devices are actively scanning Microsoft Update and are joined to Microsoft Entra (for WUfB reporting) so they appear correctly in WUfB reports.

3. Managing “Client check passed / Inactive” devices Inactive devices typically:

• Haven’t sent policy/status/inventory data within the configured activity window.
• May still be healthy when online, but are not currently active.

Actions:

1. Verify client activity thresholds

• In the Client Status Settings Properties (Monitoring > Overview > Client Status > Client Status Settings), review:
  • How many days since last status message or policy request define a client as active.
  • Adjust if necessary to match operational reality (for example, devices that are rarely powered on).

2. Use the client health dashboard

• The client health dashboard summarizes client health and activity:
  • If the most recent status message is less than seven days old, or there is no status message, the client is considered Success.
  • If the most recent status message is older than seven days and not yet deleted, the client is considered Failure.
• For devices that are inactive but should be active:
  • Confirm they are powered on and can reach the management point and distribution points.
  • Check network/firewall/VPN conditions that might block communication.

3. Generate fresh status messages for “quiet” clients

• If only modern software distribution is used (applications, software updates) and no legacy packages, some clients may not send status messages frequently and can appear as failures or inactive in some views.
• Workaround:
  • Deploy a small legacy package (for example, cmd /c echo) to those clients to generate regular status messages so their last status message timestamp is updated and they no longer appear as failed/inactive in status-based views.

4. Clean up stale or truly obsolete devices

• Use the Client Activity and client status views to identify devices that have been inactive for a long period and are no longer in use.
• Remove or decommission those devices from Configuration Manager to keep compliance and health reporting meaningful.

4. Handling “Unknown Computer” objects If “Unknown devices” refers to Unknown Computer objects used for OS deployment:

• Each primary site should have only one x64 Unknown Computer and one x86 Unknown Computer object.
• If there are multiple Unknown Computer objects per site, or if a client has “stolen” an Unknown Computer GUID during imaging, follow this pattern:
  1. Identify duplicate Unknown Computer objects in the All Unknown Computers collection and note their Resource IDs.
  2. Back up the site database.
  3. Delete all Unknown Computer objects for the affected site from the database (per documented procedure).
  4. Recreate the Unknown Computer objects for that site.
  5. Update membership of All Unknown Computers and re-add the new Unknown Computer objects to the appropriate collections.
  6. Reinstall the Configuration Manager client on any offending client that stole the GUID, after its record has been cleaned.
• This ensures OS deployment behaves correctly and prevents imaging issues related to Unknown Computer GUIDs.

5. Operational recommendations

• Separate views/collections:
  • Create collections for:
    • Active, healthy clients.
    • Client check passed but inactive for X days.
    • Devices with Unknown update state (especially WUfB-integrated).
  • Apply different operational policies: remediation for inactive-but-expected devices, cleanup for long-term inactive, and alternate reporting (WUfB) for Unknown update state.
• Regular maintenance:
  • Use maintenance tasks such as Delete Aged Status Messages to keep the database clean and ensure health calculations remain accurate.

References:

• Integrate Windows Update client policies with management solutions
• Some devices are reported as failed on the client health dashboard
• A client computer can steal the Configuration Manager GUID of an Unknown Computer object during imaging
• Fundamentals of managing devices with Configuration Manager