I have installed an AX 2012 R3 (Database, AOS and Client). Restarting the server it triggers two error events in the event log:
Object Server 01: RPC error: Failed to unregister service principal name (SPN): 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/AOS.domain.local:2712'
Object Server 01: RPC error: Failed to register service principal name (SPN): 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/AOS.domain.local:2712'
I have had an AX 2012 R2 running, which I first uninstalled. I reused the domain account for the aos service.
I have completed the checklist and AX i working, but I like to have a clean eventlog.
I have also observed this and I think Microsoft has a flaw in the installer always treating the Service Account as a Managed Service Account. I also see this in AX 2009 SP1 solutions with some of the newest kernel builds...
SPNs should only be required when utilizing a Managed Service Account. Maybe it's more to this than I can understand at the time beeing, but I can not find any documentation explaining why it should be like this when utilizing a standard Service Account. If Kerberos authentication is a requirement, then it is easy to grant Write and Read Service Prinsipale name to the Service Account to allow automatic SPN registration and un registration in AD.
Personally I think Microsoft should come clear on this by either explaining why this is a requirement even when utilizing a standard Service Account or fix the installer to add the needed flags to the Service Configuration in Service Control Manager.
Please see my blog for further details.
Interesting I have the same issue when installing a fresh copy of AX 2012 R3 against a new databases
any idea on how to get rid of this error message?
Is there a statement from MS why this is done even though we are not using a Managed Service Account for the AOS?
I have had a suggestion from Microsoft on how to resolve this issue but it made no difference for me.
The SPN is needed for Kerberos authentication; if the SPN registration fails, authentication will revert to NTLM (assuming the SPN was not manually registered). The most likely reason for the failure is that the account that the AOS is running under does not have enough rights to register/unregsiter the SPN.
There is a registry key you can set on the AOS box to have it stop attempting to register/unregister the SPN:
Add authn_regspn as a string value and set it to 0 under HKLM\System\CurrentControlSet\Services\Dynamics Server\6.0\01\Original (install configuration) ... substitute the aos instance and active configuration in the registry path if needed.
The issue here is not permissions to automatically register the SPN in AD, but the fact that MS always treats the service account as a Managed Service Account. Remeber the options you have when installing an AOS instance...
I fixed this by modifying the security settings of the AOS-servers computer object in Active Directory.
Added the user account under which the AOS server is running, and assigned the special authority of "Validated write to service principal name".
As far as I know - another solution would be to add your user account to the Domain Admins group - but this will most likely cause trouble with the Security People :-)
Since this was added I do not see errors when starting or stopping the AOS servers.
Both Stuart and Brian is spot on with their suggested solutions to get rid of the Error beeing logged at AOS start and stop (either register/de-register SPN or do not register/de-register SPN automatically at AOS Service startup/stop or assign permissions to allow writing/reading SPN in AD to the AOS Service Account).
My point is that I find it strange that Microsoft does not explain this as a requirement related to the obvious changes done to the AOS Service in AX 2012 R3 and most important when this is required (when the environment require Kerberos authentication as opposed to NTLM). As I have stated earlier, I consider this as a bug mostly based on the format of the SPN (read up on Managed Service Accounts). It could be a requirement with regards to delegated authentication (AIF/WCF) - if true it makes the lack of formal information from Microsoft even worse... Based on my experience this does not affect the solution and I regard this as uneccesary noice.
Finally some information available from Microsoft - please check the AX Support Blog.
If I have been unclear in previous posts, this is all about RPC Communication (Kerberos | NTLM) and has nothing to do with WCF Services. And it's not related to Managed Service Accounts (also previously stated by me).
My conclusion is that if the environment does not require Kerberos (NTLM is sufficent), implement the authn_regspn = 0 option descibed by others and now also Microsoft.
Adding 'authn_regspn' with value '0' to the registry didn't help me fix the issue. But that may be because I tested this on a Windows 10 machine. Does it only work on Windows Server?
The change did fix the issue after a new restart.
I brought the AOS offline, changed the registry, started the AOS --> Error still popped-up in the eventviewer.
Restarted the AOS once more --> Error doesn't appear in the Event Viewer anymore.
Should it help others, I knocked up a script to fetch these values from a list of servers.
It can also compare and/or update the values against defined preferences.https://gist.githubusercontent.com/JohnLBevan/8058b2da9bbe1f3e1b1dafa7dad1e204/
Business Applications communities