MS SQL Server can't register SPN when started with a service account

When you change the service account used by the MS SQL server services, they often are not abel to register the corresponding SPN in active directory.

You should see these messages in the SQL server log when it's working correctly

The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/SQL.testdomain.in:24629 ] for the SQL Server service.

In the case you get errors like this, the SPN registration (and therefore later on the lookup via AD) is not working

The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x54b. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies. 

 For a service account to be able to register the SPN you need to set these rights on the AD user account:

Now you just have to restart the MS SQL service, and it should be able to register the SPN in AD.

If you still receive the error message, then it's because the corresponding SPN's are still/already registered on another object (mostly the computer account of the MS SQL server) and the service account has no rights to modify them (Since we did only allow it to modify it's own rights)

So the simplest way to do this is to use the setspn command to remove the stale entries.

You can look what SPN entries are registered for a specific AD object with this command:

setspn -l domain\sql-server

You will then probably see something like this:

• MSSQLSvc/ sql-server.domain.local
• MSSQLSvc/ sql-server.domain.local:1433 

So you can also remove them from the object with:

setspn -d  MSSQLSvc/sql-server.domain.local domain\sql-server

setspn -d  MSSQLSvc/sql-server.domain.local:1433 domain\sql-server

Now you restart the MS SQL service and it should be able to register.

If it still throws errors, then the SPN is probably assigned to another account. In that case just try to add the spn manually, and it will tell you where the duplicate SPN can be found.

setspn -a  MSSQLSvc/sql-server.domain.local domain\service-account

This can also happen when you switch from one service account to another.

Adding a Windows 2012 R2 Essential Server to a existing domain

Adding a new Windows 2012 R2 Essentials server to a existing domain is a supported scenario by microsoft.

The new server will then be the primary server for all the ADS roles.

Unfortunally this does not mean it will just work out of the box.

The basic steps for this are:

- Make the basic installtion of the windows server

- Don't follow the wizard after installation, just cancel it
- Important: Set the server name you wish to use now, you won't be able to change it later on
- Install the Active Directory Services on the new server
- Add the new server as a additional ADS server in the existing domain
- Let the wizard finish the essentials configuration

The details can be found on the microsoft product site.

Unfortunally the wizard won't finish, but rather say: Error occured and nothing is logged.

The post-config wizard won't let you configure the Essentials Experience role because it's unable to start the 'Windows Server Essentials Management Service' system service. This service is configured to run under the <domain>\ServerAdmin$ account. This account must have 'Log on as a service' rights.

• Go to Group Policy Management
• Edit your policy, such as the 'Default Domain Controllers Policy'
• Go to Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ User Rights Assignment
• Edit 'Log on as a service' and add 2 accounts: <domain>\ServerAdmin$ and <domain>\MediaAdmin$

The ServerAdmin$ is enough to let the wizard finish the configuration. The MediaAdmin$ is needed for the 'Windows Server Essentials Media Streaming Service'.

Installing .net framework 3.5 via ADS GPO

Deploying .net framework 3.5 via group policy is not as easy as it should be.
No idea why microsoft did create packages which can't be used by microsoft products....

To get installable .msi packages you can do the following steps:

Deployment of Microsoft .NET Framework 3.5 SP1 x86 using Active Directory.

Microsoft Windows Installer 3.1 must already be deployed.

1. Download dotnetfx35.exe from http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe

2. Run dotnetfx35.exe /x to extract the files

3. Move wcu\dotNetFramework\dotNetFX20 and wcu\dotNetFramework\dotNetFX30 into the root, eg to D:\dotNetFX20 and D:\dotNetFX30

4. To create Microsoft .NET Framework 2.0 SP2 admin install (a prerequisit) run
msiexec /a Netfx20a_x86.msi /update D:\dotNetFX20\ASPNET.msp;D:\dotNetFX20\clr.msp;D:\dotNetFX20\crt.msp;D:\dotNetFX20\dw.msp;D:\dotNetFX20\NetFX_CA.msp;D:\dotNetFX20\NetFX_Core.msp;D:\dotNetFX20\NetFX_Other.msp;D:\dotNetFX20\prexp.msp;D:\dotNetFX20\winforms.msp USING_EXUIH=1 REBOOT=ReallySuppress /log D:\dotNetFX20\netfx20a_x86.txt TARGETDIR=D:\dotNetFX20admin
then copy D:\dotNetFX20\Netfx20a_x86.msi to D:\dotNetFX20admin and move D:\dotNetFX20admin to network share.

5. To create Microsoft .NET Framework 3.0 SP2 admin install (a prerequisit) run
msiexec /a netfx30a_x86.msi /update D:\dotNetFX30\WCF.msp;D:\dotNetFX30\WCS.msp;D:\dotNetFX30\WF.msp;D:\dotNetFX30\WPF1.msp;D:\dotNetFX30\WPF2.msp;D:\dotNetFX30\WPF_Other.msp;D:\dotNetFX30\XPS.msp;D:\dotNetFX30\WF_32.msp;D:\dotNetFX30\WPF2_32.msp;D:\dotNetFX30\WPF_Other_32.msp USING_EXUIH=1 REBOOT=ReallySuppress /log D:\dotNetFX30\netfx30a_x86.txt TARGETDIR=D:\dotNetFX30admin
then copy D:\dotNetFX30\Netfx30a_x86.msi to D:\dotNetFX30admin and move D:\dotNetFX30admin to network share.

6. To create Microsoft .NET Framework 3.5 SP1 admin install run
wcu\dotNetFramework\dotNetFX35\x86\netfx35_x86.exe /x and move vs_setup.msi and vs_setup.cab to network share.

7. Add Netfx20a_x86.msi, Netfx30a_x86.msi and vs_setup.msi in order to an Active Directory GPO.

An x64 version can also be created and deployed using this method.

Running windows 2008 r2 adprep on a server in a different language

When you have a older active directory system, for example based on a Windows 2003 or Windows 2008 server, you have to upgrade the ads schema by running adprep.exe

The adprep.exe tool is found on the windwos 2008r2 DVD in the support\adprep directory.
You can copy over the whole content of the directory (including subdirectories) to your ads master  server.

If the "old" server is running a 32-bit windows, then you can start adprep32.exe instead of adprep.exe.

Now adprep.exe should tell you something about "At least windows 2000 sp4 required"
If you don't get any messages from adprep, then the languages of the windows 2008r2 dvd and your old ads server do not match.

It might be tempting to just type "c" for continue, it will then do some of the work, but unfortunally not everything you need.
adprep does write a logfile, which can be found in C:\windows\debug\adprep (or C:\windows\system32\debug\adprep for a 32-bit system)
You will see error like

There is a syntax error in the input file
Failed on line 169.  The last token starts with 's'.
An error has occurred in the program

The reason for this is, that there are some strings missing for the adprep utility.
To get it working correctly, you have to rename the language subdirectory to match the servers language. (Chaning it in the control panel is not enough)
For example if your new server is running german, then the subdirectory is called de-de.
If the old server for example is installed in english, you have to rename the de-de directory to en-us.

Now you can again run adprep, you will receive the prompts in the original language from the dvd, but everything will process as expected.