Fix WinRM Event ID 10154: Failed to Create WSMAN SPNs

Applies to: Windows Server 2025 / 2022 / 2019 / 2016 / 2012 R2 / 2012 / 2008 R2 / 2008

WinRM can log Event ID 10154 when it cannot register the WSMAN Service Principal Names (SPNs) required for Kerberos authentication.

A typical event contains entries similar to:

The WinRM service failed to create the following SPNs: WSMAN/server.contoso.com; WSMAN/server.

In This Article

• 1. What Event ID 10154 Means
• 2. Check the Current SPNs
• 3. Check for Duplicate SPNs
• 4. Register Missing WSMAN SPNs
• 5. If the Error Is Access Denied
• 6. Why NETWORK SERVICE Is Not the AD Account
• 7. Verify WinRM
• 8. Key Takeaways

1. What Event ID 10154 Means

WinRM uses SPNs for Kerberos authentication. In a normal domain configuration, the WSMAN SPNs are associated with the server’s Active Directory computer account.

Event ID 10154 means WinRM attempted to register one or more WSMAN SPNs but the registration failed. The Additional Data field is important because the underlying error can be different. For example, an access-denied error should be investigated differently from a domain-connectivity or duplicate-SPN problem.

2. Check the Current SPNs

List the SPNs currently registered on the server’s computer account:

setspn -L SERVER01

Look for entries similar to:

WSMAN/SERVER01
WSMAN/SERVER01.contoso.com

3. Check for Duplicate SPNs

Before adding an SPN, confirm that it is not already registered on another account:

setspn -Q WSMAN/SERVER01
setspn -Q WSMAN/SERVER01.contoso.com

You can also scan the domain or forest for duplicate SPNs:

setspn -X

Do not create another copy of an SPN that already belongs to a different account. Duplicate SPNs can break Kerberos authentication.

4. Register Missing WSMAN SPNs

If the WSMAN SPNs are missing and are not registered elsewhere, add them to the server’s computer account with setspn -S:

setspn -S WSMAN/SERVER01 SERVER01
setspn -S WSMAN/SERVER01.contoso.com SERVER01

Use -S instead of -A because -S checks for duplicate SPNs before creating the new entry.

5. If the Error Is Access Denied

If the event reports an access-rights error, inspect the Active Directory computer object’s permissions instead of repeatedly adding the SPN manually.

1. Open Active Directory Users and Computers.
2. Enable View > Advanced Features.
3. Open the affected computer object.
4. Open Security > Advanced.
5. Check whether the computer account can update its own servicePrincipalName attribute, including the Validated write to service principal name permission.

If permissions were customized or inheritance was removed, compare the object with a healthy computer or domain controller in the same environment before changing the ACL. Restore the required computer-object permissions rather than granting broad SPN write permissions.

6. Why NETWORK SERVICE Is Not the AD Account

WinRM runs under NT AUTHORITY\NETWORK SERVICE. However, Microsoft documents that a service running as Network Service presents the computer’s credentials when it accesses remote resources.

For that reason, I no longer recommend the older workaround from the original version of this article that added NETWORK SERVICE directly to the Active Directory computer object’s ACL. The object that normally owns the WSMAN SPNs is the server’s computer account.

7. Verify WinRM

After correcting the SPN or Active Directory permissions, restart WinRM or reboot the server during an appropriate maintenance window:

Restart-Service WinRM

Verify the service locally:

winrm enumerate winrm/config/listener
Test-WSMan localhost

Then confirm that Event ID 10154 is no longer generated and that the expected WSMAN SPNs are present:

setspn -L SERVER01

8. Key Takeaways

• Event ID 10154 means WinRM could not register one or more WSMAN SPNs.
• Check the event’s underlying error before assuming it is an ACL problem.
• Use setspn -Q and setspn -X before creating SPNs.
• Use setspn -S to safely register missing WSMAN SPNs on the computer account.
• If automatic registration fails with access denied, verify the computer object’s SPN write permissions rather than granting NETWORK SERVICE broad access.

References

• Microsoft Learn – Setspn
• Microsoft Learn – NetworkService Account