Couple things to be aware of:

1. You do not have to run sql  under a dedicated service account (although
from a security standpoint, you should). I just want you to realize that it
isn't a technical requirement for SharePoint to run, running SQL as the
local system will work.

2. You don't have to setup a SPNs in order for SharePoint to work either.
You will only need SPNs if you will be having SQL server  pass through
windows authentication from SQL server to another physical box. For example,
if I login to SQL Server using windows authentication and then run a stored
proc or use something that connects to a seperate physical box AND attempts
to pass the same login credentials to the remote box as I used to login to
the initial SQL server.

Depending on your environment, you may find this is either very rare or
never happens (it never happens in my environment).

I just wanted to clarify that you do not always need to have SPNs setup,
especially for SQL. I find in my environments that I need to have SPNs setup
for the app pool accounts in IIS on the WFE servers, which is something I
didn't see in the document you linked to. The reason for that is if I have
user logged into MOSS on WFE and then wants to connect to excel services on
a different box, it needs to pass his credentials over to the excel services
box, which requires an SPN to be setup for the app pool account on the WFE.

Basically, any time you have windows authentication attempting to be used
and it involves multiple servers  using a chain of requests (server 1 >
server 2 > server 3) then you will need an SPN setup for whatever service
account is making the request on server 2. In more complex scenarios such as
(server 1 > server 2 > server 3 > server 4) then you need SPNs setup for the
service accounts on server 2 and server 3.

I just bring this up so hopefully you can understand a little more about why
and when you need an SPN rather than just creating one because the
documentation says so.

Back to your original question, creating the SPN for SQL is very easy:


1. Get the setspn.exe utility by downloading "Windows Server 2003 Support
Tools" (google it)
2. Run "setspn.exe -A MSSQLSvc/<SQL Server Computer Name>:1433 <NT
Domain>\<SQL Server Service Account>"
3. Open the "Active Directory Users and Computers" Tool
4. Locate the <SQL Server Service Account> user, open up properties, and
on the "Account" tab make sure "Account is trusted for delegation" is
checked and then hit OK.
5. While still in the AD Users & Computers tool, locate the SQL Server
computer, open up properties, and make sure "Trust computer for delegation"
on the General tab.

Here [1] is a link to a great article that is far more in-depth that the
info I have provided.

If he is running SharePoint in a multi server farm  (he says 2 x Win2k8 servers)
then he won't be able to run it in local system mode. That only works in a
single server  environment where SQL is on the same server. He'll need either
network service or a domain service account. I wouldn't recommend running under
network service because it opens up all kinds of potential security exploits.

I appreciate the detail of the SetSPN steps. That's very helpful.

If I could beg another moment of your attention, would you agree or disagree
with the following for a two server farm  running 2008 technology:

1) Running the MSSQLService service using a domain account is the most secure.
The only functional alternative is using the NETWORK SERVICE account.

2)The SQL server  must be configured for Kerberos by assigning an SPN for the
serivce on the server through the approriate port to the domain account that the
service uses AND then trusting the server for delegation.

Finally, do you think that since I have not configured the serivce for Kerberos
authentication, that explains why my central administration home page won't load
after I run the wizard?

#1 is definitely true. #2 I think is true, but I don't have enough actual
experience in Kerberos environments to say so definitely. However, Jeff is
correct that kerberos is not required to run SharePoint. The SPNs will be
required if you want to use kerberos in your environment, but aren't needed if
you are running with standard NTLM.

One other possibility. Are you trying to access the CA website from the server
itself? Central Admin by default is only hosted on one server. So you could
just be on the wrong server.

What response do you get when you try to browse to the CA website?

I've eliminated a number of variables by installing WSS 3 SP1 on the database
server. It's SQL server  2008 running on Windows Server 2008. I have the database
service using the "NETWORK SERVICE" account and I'm running the Wizard with
domain admin permissions.

The configuration wizard runs to completion and CA returns with an HTTP 500
Internal Server Error "The website cannot display the web page."

There's nothing in Windows Event logs, the IIS logs or the SharePoint logs that
seems to make any sense.

When you run the wizard does the domain admin account have at least DB Creator
and Security administrator roles in the SQL server? Have you installed .net 3.5
and made sure its active in IIS?

Yes, I have a domain admin account with DBCreator, SecurityAdmin and SetupAdmin
permissions.

.Net 3.5 is installed; how can I tell if it's "Active"?