Category Archives: SharePoint

Want to change your MOSS MySite URL?

Recently I had a customer who wanted to change the URL of his MySite Application in MOSS.
He had the MySites running with a non-standard port, for example 1234:
1-port1234

He wanted to change the URL to, let’s say testapp.local.
Here is what you need to do:

1. Extend the MySite Web Application
2-extendwebapp

2. With the extension of a Web Application, you create an additional Alternate Access Mapping entry. You have to edit the entries for the MySite Application:
3-AAM1 4-swap1

3. It should look like this when you swapped the entries:
5-AAM2

4. Make an IISRESET to apply the changes.

6. Now your MySite Link should point to the new URL with Hostheader:
6-result

That’s it!

MOSS Update fails: Cannot start service SPAdmin on computer (update)

There were some admins recently, that installed a WSS and MOSS Hotfix (for example 12.0.6314.5000, 12.0.6315.5000, 12.0.6316.5000) and got an error message when running the Configuration Wizard (PSCONFIG):

clip_image002[4]
Windows Sharepoint Services Administration Service could not be started

In such a case you have to add two registry keys and restart the server:

1. HKLMSYSTEMCurrentControlSetControl -> add/modify DWORD value ServicesPipeTimeout to 60000 (60 seconds)

2. HKLMSYSTEMCurrentControlSetControl -> add/modify STRING value WaitToKillServiceTimeout to 120000 (120 seconds)

After the reboot, the service should start without problems, because it is set to automatic start.

Update: Eventually you have to start the service manually after the first boot.

Want to test and troubleshoot Kerberos authentication to your MOSS site?

Okay, we have configured our MOSS site so that the users are able to authenticate with Kerberos.
But how do we know for sure that Kerberos was used and the authentication has not fallen back to NTLM? Here is what we can do with the right tools.

At first, we should install a tool which allows us to have a look on the traffic between the browser and the server. The tool I prefer is called Fiddler, you can download it from here: http://www.fiddlertool.com/Fiddler2/version.asp.
Just install it on a client machine and start it. It works as a proxy between the browser and the client, so you should take a client that reaches the MOSS server without another proxy. Then just open your browser and then your MOSS site. Fiddler should log the HTTP packets and you should get something like that:
 1 - Fiddler-NTLM
In the screenshot we can see that NTLM was used and we have to find the reason why Kerberos was not used.

Very often the reason is a very simple one: duplicate SPNs.
Here is a way to export all existing SPNs of a domain:

ldifde -f c:spn_out.txt -d “DC=test,DC=local” -l serviceprincipalname -r “(serviceprincipalname=*)” -p subtree

In my test environment the Active Directory Domain was called test.local, you have to alter the command with your domain name.

Here is the output from the command:
2 - ldifde

Here is the generated text file:
3 - ldifde2

As you can see, there are a lot of SPNs, even in a very small environment. This makes troubleshooting very difficult, especially in large environments.
What can we see in the screenshot above? The problem is, that the SPNs are sorted by security principals (computers, users) and not by services. In my example I intentionally created two SPNs for my MOSS site testapp.local.

Here is the screenshot with the highlited duplicate SPNs:
3 - ldifde2

As you can see, the service HTTP/testapp.local is registered two times, for the user mossservice and the user sqlservice. When a user wants to authenticate to the MOSS site with Kerberos, he cannot know for which user he has to request a Kerberos ticket and Kerberos fails.

But there is an easier way to discover duplicate SPNs. When you are troubleshooting Kerberos authentication, you know the name of the service the user wants to connect to. In my case the MOSS site has the hostheader testapp.local and the service is HTTP/testapp.local.
Microsoft provides a script to discover duplicate SPNs. You can download the source here: http://support.microsoft.com/kb/929650. Just copy the sourcecode to a text file and rename it to SPNHelper.vbs. Then you can use this script with the following command:

cscript SPNHelper.vbs /f:duplicatespn /spn:HTTP/testapp.local

(Note that the help says the command should be cscript SPNHelper.vbs /f:duplicatespn /spn:HTTP:/testapp.local [the : after the HTTP in the SPN], but his is a typo!)

The script gives us this output:
4 - SPNhelper-Duplicate-SPN

Now we can be sure that Kerberos cannot work, because we have duplicate SPNs.
We have to delete the wrong SPN:
5 - setspn-delete

In my example, the application pool ID of the MOSS site is testmossservice, so testsqlservice was wrong.

Now we can make another authentication test with Fiddler, but at first we should delete the previously logged session for clarity:
6 - fiddler-cleanup

After we open the MOSS site another time, Fiddler states that Kerberos was used:
7 - fiddler-kerberos

That’s it!

Want to authenticate with Kerberos? (on your MOSS site)

When you create a new web application on your MOSS 2007 server, you have to make a tough choice: NTLM or Kerberos.
The differences for the user are not visible, but we have to make a few settings to make Kerberos work.

The easy settings are done with the Central Admin of MOSS:
Kerberos-CA
Just enable Kerberos in the Authentication Provider of the desired Web Application.

That was the easy one.

Another thing we have to do is to set a “Server Principle Name”(SPN). A SPN is needed, because the user who wants to authenticate with Kerberos needs to know the account under which the Application Pool is running (Application Pool ID). The authenticating user needs this information, because he needs to ask the Kerberos Key Distribution Center (KDC) for a ticket for this account.
Naturally, we provide this information with a directory service. You have three guesses what directory service we will use.

The tool for registering SPNs is called SETSPN and it is installed with the Support Tools.

Here is an example:

Application Pool ID:

Kerberos-Hostheader 
The application pool ID in my example is the user MOSSSERVICE in the domain TEST.LOCAL (TEST).

URL (Hostheader) of the application:
Kerberos-AppID
This is what your users enter into the address bar of their browser.

So we have:

Application Pool ID Hostheader:
testmossservice testapp.local

That gives us this SETSPN command:
setspn -a http/testapp.local testmossservice

That’s it.

Yes, really, it is that easy!

In my next post I will show you how to test if the authentication is made with Kerberos or falls back to NTLM.