| Previous | Next |
| STATUS_MEMBER_IN_ALIAS | STATUS_LOGON_NOT_GRANTED |
STATUS_ALIAS_EXISTS
Existing state must be compared by identity before treating the collision as success
STATUS_ALIAS_EXISTS is returned at alias creation time. Windows exposes local-group creation through NetLocalGroupAdd, while the SAM Remote Protocol models aliases as account-database objects. The collision is about the namespace of the selected SAM/domain context; it does not say that the existing alias has the membership, SID, comment, or purpose expected by the caller.
Idempotent deployment code should query the existing object and compare it with the desired state. Record the server or domain where the object was found, its SID, and direct membership before deciding that creation can be skipped. This is especially important after machine rebuilds or domain migrations, where the same group name can refer to a different SID.
Deleting the existing alias merely to make the create call succeed is dangerous because access-control entries can reference its SID. If the existing object is the intended one, reconcile its properties and membership. If it is not, choose a different design or explicitly migrate ACL references rather than replacing the object by name.
What to inspect
- The account database and server to which the create operation was sent.
- The existing alias SID and direct membership, compared with the intended provisioning state.
- ACLs, services, tasks, or application configuration that reference the existing group SID before any delete-and-recreate action.
References
- Microsoft Open Specifications: Security Account Manager Remote Protocol
- Microsoft: NetLocalGroupAdd
- Microsoft: NetLocalGroupGetInfo
- Microsoft: Security identifiers
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.