1

Good day, and so sorry for such a lengthy question, but I am a bit confused and so close to making headway.

I cannot find any reference to creating SPN's in the PowerShell scripts, and in all online guides for AutoSPInstaller, nothing mentions to create the SPN's ahead of time. Is not configured with AutoSPInstaller?

Additionally, I read on another post that FQDN circumvents the use of SPN. Is that true?

My current 2010 environment uses shortnames such as http://siteA and I am moving it to http://siteA.domain.com in the new 2016 farm, and will use AAM to map it appropriately so the old shortname references work.

I assume that even if SPN's were unnecessary for FQDN, that the use of a netbios shortname to keep backward compatibility would still require SPN's be registered.

If I need to make these manually, do I only do it for the Application Pools for each web application, or does it also need to be completed for each service account like spservice, spvisioservice, spfarm, etc

Is this correct? setspn -d HTTP/server1.domain.com domain\AppPoolAccount setspn -d HTTP/server2.domain.com domain\AppPoolAccount

Thank you for your help.

Improve this question

1 Answer 1

Reset to default
5

The correct implementation is:

setspn -U -A HTTP/sitea.domain.com DOMAIN\AppPoolAcct

Only specify the FQDN of the Web Application URL (unless using HNSC).

You should also set an SPN for the SQL Server service account, e.g.:

setspn -U -A MSSQLSvc/sqlserver.domain.com:1433 DOMAIN\SqlSvcAccount
setspn -U -A MSSQLSvc/sqlserver:1433 DOMAIn\SqlSvcAccount

The reason we specify both the hostname and FQDN for SQL is that both may be used. In SharePoint, that's not the case with your new configuration -- only the FQDN will be available.

Hopefully you're only using a single Application Pool for all Web Applications (for memory consumption and performance), but you'd have to specify the FQDN for all Web Applications regardless.

You do not need to specify an SPN for Service Accounts unless you're performing Kerberos Constrained Delegation scenarios for Business Intelligence purposes (e.g. PowerPivot connecting to a back end data source, as an example).

Improve this answer
4
  • Thank you kindly for your reply and detailed information. So it is my understanding based on that reply that AutoSPInstaller does not handle SPN creation, and it should be done manually. Also, I did not use domain accounts for SQL. Hopefully that is not too much of an issue, since it is using the built in engine and agent service accounts. With memory efficiency in mind, as well as individual management, I created application pools for intranet, extranet, and workspace (separate workflow focused web application). This will allow me to recycle individual web applications individually.
    – raredesign
    Commented Mar 7, 2017 at 19:16
  • Using separate Application Pools on a per-Web Application basis is a huge memory expenditure. These pools cannot share memory, thus you have to load, for example, Microsoft.SharePoint.dll into each process (as well as all of the other binaries). This is very expensive. There should never be a need to where you need to recycle pools by hand; SharePoint does this automatically daily in the early AM hours. As for AutoSPInstaller, unsure. I don't use it myself.
    – user6024
    Commented Mar 7, 2017 at 19:25
  • Thank you Trevor, I appreciate the recommendations. Hopefully the configuration works out well for this farm. I believe the extra overhead per application pool sits at around 500MB's when I checked my 2010 farm. One benefit is for solution deployment or troubleshooting of errors, since it can recycle without affecting the others. Also, regarding SQL is the built in account going to hurt since I won't have an SPN?
    – raredesign
    Commented Mar 7, 2017 at 19:34
  • Yep, the overhead is roughly 500 - 800MB, baseline (as more binaries get loaded, the overhead increases). The startup time is also individual for each Pool, rather than a single request starting a Pool for all Web Applications. For the SQL service accounts, I always prefer Domain Accounts, but you should be able to just assign the SPN to the computer account (e.g. SQLServerName$). Leave out the -U switch from setspn.
    – user6024
    Commented Mar 7, 2017 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.