The Problem
The configuration of the system when this error was encountered is as follows:A. Windows Server 2008 R2 Redundant Domain Controllers - we will call these DC1.joshwieder.com and DC2.joshwieder.com
B. Windows Server 2003 Web Server with Windows Remote Management enabled / part of the Active directory deployment - we will call this WEB.joshwieder.com
C. For the sake of our example, let's say I have configured an OU named "Web Servers" on those domain controllers
Whenever the Windows 2003 Web server reboots, or WinRM.exe service on the Windows 2003 Web server restarts, the following error was logged into the Event Viewer:
Event ID: 10154
Source: Microsoft-Windows-WinRM
Version: 6.1
Symbolic Name: LOG_WSMAN_SPN_CREATION
Message: The WinRM service failed to create the following SPN: %1.
Additional Data
The error received was 8344: Insufficient access rights to perform the operation.
User Action
The SPN can be created by an administrator using setspn.exe utility.
***NOTE: This issue has also been well documented as occurring while using Windows Small Business Server (SBS) 2003
The Explanation
First its important to understand what all of this means and why we should care. This error and its fix are documented in a number of websites elsewhere, however those documents lack any form of explanation to help us better understand what is occurring here.
SPN stands for Service Provider Name. SPNs exist on the domain controller to indicate which service applications are assigned to which computers within the Active Directory forest. WSMAN means Web Services Management (notated commonly as WS-Management), which is a Microsoft protocol used to acquire information related to services and applications hosted on a remote server, and to manage those applications and services. WSMAN differs significantly from SNMP by allowing administrators to perform a more comprensive array of tasks. Whereas SNMP would simply get information, WSMAN gets information and allows an admin to remotely install and modify applications based on that information (SNMP has SetRequest, which is limited to a narrow set of predefined variables).
The WinRM service (Windows Remote Management) is what is installed and runs on servers to listen for WSMAN commands. WinRS (Remote Shell) is the client side application of the protocol, and sends the WSMAN commands to the remote host.
Now that we understand the context of the conflict, we can return to our specific error with a greater understanding of the situation. Its important to note that I was able to verify that the WSMAN SPN does in fact exist on both of my domain controllers, so using setspn.exe to create the SPN wasn't going to help me much. I verified this was true by logging into the domain controllers and running the following command:
setspn -L WEB
(remember we are assuming that my webserver is named web.joshwieder.com)
The output contained a number of items, including the two I was looking for:
WSMAN/WEB and WSMAN/WEB.JOSHWIEDER.COM
This lets me know that the SPExNs do in fact exist. Knowing that winRM.exe will try to rewrite the SPN every time it starts, and together with the Additional Data field of the error message, we now had a confirmed diagnosis and prognosis - the web server has insufficient permissions to write to the SPN, forced rewriting of the SPN at service start generates the error and while there may be no immediate server-side issues because the SPN already exists, that could change at anytime.
The Solution
First, it is necessary to confirm that the WinRM service is properly patched and updated. For Windows 2003 servers, the subject of our discussion here, this means updating to version 2.0 provided via KB968930. 2003 does not include WinRM by default, and older 2003 servers that you have inherited may still be running the antediluvian version 1.1. Windows 2008 servers now include version 3.
Supposing the service is fully updated, there are two ways to go about doing this. Both should accomplish the same thing, but if you have issues with one method try the other.
The first is the easiest to perform for those more comfortable with a GUI. From your domain controller, launch ADSIEDIT.MSC. Connect to the relevant Active Directory instance (typically just the default local connection is fine), then navigate through the domain to the server we are experiencing this issue with. The order of navigation is:
DC=Domain
OU=Variable Organizational Unit
CN=Machine Name
Using our example, I would navigate to:
DC=joshwieder
OU=Web Servers
CN=WEB
Right click on CN=WEB and select Properties. Select the Security tab, click Add, "NETWORK SERVICE". (This assumes that you run the WinRM service using the default identity settings - select the account that is relevant for your configuration). Click Advanced and Effective Permissions tab, and select "Validated write to service principal name". Then Click OK to save your changes. Reboot the domain controller and restart the WinRM service.
Once completed, use setspn -L and the Event Viewer to confirm whether the change was successful. If not, you can use the command line option as an alternative:
dsacls "CN=Web Servers,CN=WEB,DC=ai-host,DC=com" /G "S-1-5-20:WS;Validated write to service principal name"
Same end result here as with the GUI - reboot the DC and restart the WinRM service and check the logs or setspn -L. You're accomplishing the same end result with either task - however there are a host of reasons why a GUI can be problematic. I have yet to encounter a set of circumstances where neither trick does not resolve the issue. If this does not resolve your trouble, please email or comment for me.
Same end result here as with the GUI - reboot the DC and restart the WinRM service and check the logs or setspn -L. You're accomplishing the same end result with either task - however there are a host of reasons why a GUI can be problematic. I have yet to encounter a set of circumstances where neither trick does not resolve the issue. If this does not resolve your trouble, please email or comment for me.
Extra Credit
Planning on using the WinRM IIS Extension? Launch Server Manager and select Add Features to provision the needed packages. Reboot your server and launch a command prompt, then use winrm qc to complete the configuration.