What does HRESULT 0x80270011 (NAP_E_SHV_CONFIG_EXISTED) mean?

 
Previous Next
NAP_E_TOO_MANY_CALLS NAP_E_SHV_CONFIG_NOT_FOUND

NAP_E_SHV_CONFIG_EXISTED

The requested SHV configuration already exists

NAP_E_SHV_CONFIG_EXISTED is HRESULT 0x80270011 (signed decimal -2144927727, unsigned decimal 2150039569). AllStat, using winerror.h, describes it as “SHV configuration already existed.” The value has failure severity, facility 0x27, and code field 0x0011.

This is a legacy Network Access Protection result: Microsoft states that NAP is unavailable starting with Windows 10 and that current Windows Server releases do not include the former NAP, HRA, and HCAP roles; use the code for supported legacy systems, archived telemetry, compatibility components, or migrations rather than assuming a modern machine should expose the old platform.

NewConfig detected configuration-store drift or duplication

Microsoft documents this HRESULT for INapComponentConfig3::NewConfig. Network Policy Server assigns a configuration ID that is unique within an SHV, and NewConfig must allocate a copy of the default data for that ID. The error means the SHV already has the ID even though the caller is asking to create it; Microsoft explicitly notes that the IDs known to NPS and the SHV differ.

How the two stores diverge

  • A previous NewConfig succeeded in the SHV but the NPS-side transaction failed or rolled back.
  • Configuration was restored from backup on one side without restoring the matching NPS metadata.
  • A retry after timeout repeats creation without first checking whether the first call committed.
  • The SHV failed to delete an old configuration ID during policy removal.
  • Multiple management nodes create the same assigned ID concurrently.

Configuration identity evidence

  • Record configID, SHV SystemHealthEntityId, NPS policy identifier, and the operation transaction/correlation ID.
  • Enumerate or query the SHV store and compare the existing blob’s version and hash with the intended default.
  • Review the preceding NewConfig response and any management timeout that may have hidden successful persistence.
  • Capture backup, migration, import, and delete history for both NPS and the SHV configuration store.

Reconciling the ID

  • Use GetConfigFromID to determine whether the existing ID contains the intended configuration or stale data.
  • If the existing object is the same logical policy, continue with the documented get/UI/set sequence rather than creating it again.
  • If it is orphaned, remove it through DeleteConfig only after proving that no active NPS policy references it.
  • Serialize create/delete operations per SHV so two management writers cannot race on one ID.

Difference from nearby NAP results

NAP_E_SHV_CONFIG_NOT_FOUND is returned when GetConfigFromID or SetConfigToID addresses an ID that has not been allocated. NAP_E_CONFLICTING_ID concerns component registration identity, not a per-SHV policy configuration. A duplicate config ID can be an idempotent retry, but it can also reveal store divergence that must be reconciled.

Retry and recovery

Do not overwrite the existing blob blindly. Read and compare it, then either treat creation as already completed or repair the NPS/SHV store mismatch under administrative control. Retrying NewConfig unchanged will continue to return the same result.

Practical scenario

NPS assigns configID 42 and calls NewConfig. The SHV writes the default blob, but the management connection drops before NPS records success. A retry receives NAP_E_SHV_CONFIG_EXISTED. The administrator verifies the blob, adopts the existing configuration, and avoids creating a second policy object.

References

Looking for a different code? Search another status or error code.