Would anyone urgently know how to locate the GUID of a SharePoint
contentdb ?

I am trying to perform a database moving using stsadm preparetomove.

look in your backup logs. they should be there (either in the spbr directory
where you backup, or in Central Admin backup history)

What account did you create  the SPN for? The computer account or the
account that is the identity of the SSP app pool?

I wasn't aware that an http  SPN was needed for a server  that is only
hosting the index  service but if it is, I would assume it would be
for the identity of the SSP app pool. Also, I believe best practice
is to always create 2 SPNs, one fully  qualified and one not because
some services  make the requests with it and some without.

If you haven't come across it already, you might find this article
useful:
blogs.msdn.com/.../configuring-
kerberos-for-sharepoint-2007-part-1-base-configuration-for-
sharepoint.aspx

It depends on which server  is selected for crawling. See 'Central
Administration, Services on Server, Office SharePoint Search'

What is selected at the bottom of the page?

In my case, The current one is doing crawling is the one hosting
cnetral admin. I would like to start  the service  on the new index
server and received  the errors.

I wouldn't think starting the service  should require the SPN, unless you
are using that box for crawling. If so, I assume you will have to register the
SPN for all Web apps.

haven't tried this myself, but will be this Friday on a gov't system. lemme know
what you find?

Here are the SPN I registered:

For the server  which hosting  portal and central admin, I registered
the SPN as:

HTTP/Servername.FQDN domain\userename

HTTP/Portalname.FQDN doamin\username

HTTP/portalname domain\username

These usernames are used in app pools.



For SQL Server

MSSQLSvc/DBservername.FQDN:1433 domain\username

For index  server

HTTP/servername.FQDN domain\username

I thought lots of larger farm  have the index server setup and some of
them may run into this situation. However I have been searching for
cluse for two months and so far no solid ones.

First, I apologize for this being so long. I don't think I can
explain it adequately any more condensed and I don't currently have
an external blog to post to.

I finally got Kerberos to work for all of the web apps, central
admin, excel services, search, and the BI web parts that display SSAS
and SSRS a couple months ago. I won't lie to you, it was painful.

The structure of our environment is two load balanced Web Front-end
servers hosting  the Portal Web Application, MySite Web Application,
and the SSP Admin Web Application. We also have the query service
running on each of these web front-ends. We then have a separate
server that I am calling an application server  that hosts Central
Admin, Excel Services, and document conversion. There is also a
separate server that just does the indexing. Our SQL Server is a
cluster with multiple named instances. We have a separate server that
hosts SSAS and SSRS. We are running SSRS in sharepoint  Integrated
Mode and are connecting to SSAS through Excel spreadsheets, which get
published to Excel Services.

There were several gotchas along the way but here are some of the
biggest:
1. SSAS uses the instance name for the SPN request  whereas SQL
Service uses the port number of the instance.
2. IE (or probably more appropriately .NET) doesn't append the port
number when making an SPN request so all of the HTTP SPNs needed to
be created without the port number or they wouldn't work.
3. The HTTP SPNs not using port numbers caused another issue which I
didn't find documented anywhere. The best practice that is documented
everywhere details out some 15 different service accounts  that should
be used when setting up a MOSS environment. One of these is what is
often called the Farm Account that is supplied when you first run the
configuration wizard. This account becomes the identity of the
Central Admin App Pool. Another is the SSP service  account that is
requested when setting up a SSP. This account becomes the identity of
the SSP Web Service App Pool that MOSS search, Excel Services, etc.
uses. Typically, neither of these websites use host headers. The SSP
WS App Pool uses ports 56737 and 56738. Central Admin uses whatever
port you tell it to use when you are configuring it. So, if the HTTP
SPNs did use port numbers your SPNs would be, for
example, "HTTP/CentralAdminServer:1234 domain\FarmAccount"
and "HTTP/ExcelServicesServer:56737 domain\SSPServiceAccount" but,
since they don't, they
become "HTTP/CentralAdminServer" "HTTP/ExcelServicesServer". Now if
Central Admin and Excel services  (or any of the other SSP services)
run on the same server you have a problem because this is forcing you
to register the same SPN for 2 different accounts, which isn't
allowed. Neither SPN will work in this case. So, what I found I had
to do was use the same account for the Farm Account that Central
Admin uses and for the SSP Service Account. This allowed me to use
one SPN that covered both Central Admin and Excel Services, since I'm
hosting them on the same server currently.

These are the steps that I took. If you aren't worried about Excel
Services, SSAS, and SSRS then several of these won't be necessary.


SPNs:
- MSSQLSvc/SQLServerName:port domain\SQLServiceAccount
- MSSQLSvc/SQLServerFQDN:port domain\SQLServiceAccount

- MSOLAPSvc.3/SSASServerName:InstanceName domain\SSASServiceAccount
- MSOLAPSvc.3/SSASServerFQDN:InstanceName domain\SSASServiceAccount

- HTTP/CentralAdminServerName domain\FarmAccount
- HTTP/CentralAdminServerFQDN domain\FarmAccount

- HTTP/PortalName domain\PortalAppPoolAccount
- HTTP/PortalFQDN domain\PortalAppPoolAccount

- HTTP/MySiteName domain\MySiteAppPoolAccount
- HTTP/MySiteFQDN domain\MySiteAppPoolAccount

- HTTP/SSPSiteName domain\SSPSiteAppPoolAccount
- HTTP/SSPSiteFQDN domain\SSPSiteAppPoolAccount

Granted the following service/computer accounts the "Trust this
user/computer for delegation to any service(Kerberos)" Delegation
right within AD:
- PortalAppPoolAccount
- MySiteAppPoolAccount
- SSPAppPoolAccount
- FarmAccount
- WebFrontEndServer1
- WebFrontEndServer2
- AppServer1
* Once you have proven that everything is working, going back in and
defining exactly what services each should have the right to delegate
to would probably be wise.

I am really appreciated that you spent time to write this. One quick
question:

If I have the same web application hosting  content, mysite and SSP,
then I only need to register the SPN for content since the rest of
them are the same, correct?

I'm sure right now you are just trying to get this to work but, I
would strongly suggest that you look into breaking these out into
separate web apps when it is implemented in your production
environment. There are many reasons that this is advisable but I
won't get into that now.

However, with how your current environment is configured, it sounds
like you would probably need SPNs for your multi-purpose web app,
Central Admin, and SQL Service. I'm assuming you aren't attempting
Excel Services, SSRS, or SSAS right now.

- HTTP/PortalName domain\PortalAppPoolAccount
- HTTP/PortalFQDN domain\PortalAppPoolAccount

- HTTP/CentralAdminServerName domain\FarmAccount
- HTTP/CentralAdminServerFQDN domain\FarmAccount

- MSSQLSvc/SQLServerName:port domain\SQLServiceAccount
- MSSQLSvc/SQLServerFQDN:port domain\SQLServiceAccount

Where is the MOSS query service  running (a.k.a. What server
is "serving search  queries")? I didn't run into any issues with this
in my implementation so I am assuming you are fine  if it is running
on the server  that is hosting  the multi-purpose web app. If it is
another server though, it seems plausible that you might need SPNs
for it also because the MOSS search web parts may be communicating
with the query service using web services.

- HTTP/QueryServiceServerName domain\SSPAppPoolIdentity
- HTTP/QueryServiceServerFQDN domain\SSPAppPoolIdentity

I think I missed the central
admin FQDN and SQL server  FQDN SPN. Also I will create  HTTP Index
server FQDN name to join  the new one.

The crawling will split out to the new server but the query will stay
with where the central admin is.

The account I used to create  the SPN for the index  server is the same
account of SSP App Pool.

I will create another one with HTTP but server  name only. However, if
I do not create SPN for this server, how to make the Kerberos works?
I tried it before and it could not pass the creditenal to the
database. Perhaps I missed anything?

does the 401 happen every time the new server  is used or
only from time to time?

The 401 error  only happened when I tried to start  search services  in
Central Admin and define the new server  to start it.