Hi all.

Lawrence from the MS MOSS team has recently posted an article linking to some content released by the MS Internal IT group designed to help MS employees quickly come to grips with basic SharePoint functionality (eg creating a site, Web parts, meeting & document workspaces, etc...).

You can check out the SharePoint-specific list here - Everyday Productivity Education (EPE) content for SharePoint - or the full list for all office products here - http://technet.microsoft.com/en-us/library/bb687781.aspx.

I've had a look through some of them, and if you are the one stuck producing this for a client or an internal IT team, then it will be a big help and probably halve your workload.

Cheers!

Traditional restrictions around the way Kerberos works throw up a problem with setting up a load-balanced Kerberos-enabled web site. Basically, if you use port numbers to separate sites with the same DNS name on load-balanced web servers AND the sites run in application pools using different account names, you're stuffed - the server will either not be able to decrypt the SPN using a different AD account key, or you will have 2 or more SPN's created for the same site but 2 different accounts, generating a Duplicate SPN error.

When setting up a load-balanced SharePoint environment using Kerberos or Kerberos delegation, follow these guidelines to minimise hassle:

• For each MOSS site accessed by clients, create a shared DNS name that clients will use to access the site. The name must be uniquely mapped (using Setspn.exe) to one user only
• Create Alternate Access Mappings (AAM's) in MOSS for the shared DNS name for each site (Web app)
• Update the IIS Site (using the IIS Admin Tool) with the new HOST mappings that reflect the shared DNS name
• To manage session transfer:
  • Use ASP.NET SQL Session management so all sessions are recorded in a central location OR
  • Use affinity on the switch so that concurrent requests from a particular IP address within the same session go to the same target server
• If you are using Kerberos Delegation, follow the steps in my Kerberos SPN mapping blog entry
• It is also worth creating unique DNS entries on each MOSS Web Application on each web server (and setting up SPN's for those DNS entries if required for Delegation). This will allow you to quickly navigate to each specific server and determine where a failure exists if you have some users getting errors while others do not (this can be tough to do in a NLB configuration, unless you have this set up before the outage).

The diagram below describes how the information flows between servers during a Kerberos authentication request.

I will keep adding to this post with hints & tips as I progress through more of these kerberos-based load-balanced rollouts.

Stay tuned!

After battling with setting this up for 3 days before it finally started to authenticate, I thought I'd add the lessons learned to the configuration processes listed here including the troubleshooting tools used.

Firstly, Credits and Thanks - Without Martin Kearn's blog entry, I would have had no hope translating these 2 Technet articles (1, 2) into the steps in Martin's guide. If I'd needed to configure delegation to the SQL server, I would have also taken advantage of this article from Mosha Pasumansky. James World's blog article validated what I was seeing in NetMon with Site access authentication requests being passed through without a port number (I'm glad it wasn't just me). Finally, the tips in this article gave me significant insight into how Kerberos worked and how it was supposed to work in a multi-tiered web environment, as well as how to troubleshoot it.

The major challenge that I had following the steps in Martin's blog is that he does not give an explanation on how to determine what SPN's you need - this makes determining the correct SPN's for configurations different from Martin's configuration difficult - it's my aim to alleviate some of that confusion for others also venturing down this path, especially if your setup is a high-availability one.

Some of the following will be similar to Martin's blog, however I'm also going to build in:

• How to determine the SPN's required
• What SPN's are necessary, what are not
• Troubleshooting Kerberos issues that may be seen while setting up Excel Services (and which tools to use) - Coming soon...
• What can still be achieved without using Kerberos in Excel Services (Yes, you don't NEED Kerberos or SSO to run most ECS functionality... but there are some bits that will refuse to work) - Coming soon...

So where does SharePoint need to double-hop credentials anyway? How can you test to see if your issue is caused by a double-hop failure because you are using NTLM authentication? Is a Double-hop something a Kangaroo does? Find out here... :)

Kerberos was created to be more secure and faster than NTLM - and to fill the double-hop void... but by default, it does not allow accounts to impersonate other accounts unless you explicitly allow them to do so. That's probably why you're here - because in order to get the full functionality of Excel Services working with Kerberos authentication, you need to allow the service accounts of the SharePoint application to impersonate the user's account that is currently logged into SharePoint. If you do not need to authenticate users and you don't mind if people who are connected to your network can see your back-end data source then there are instructions coming soon on how to set up ECS without using Kerberos.

In the diagram below, I outline the process that occurs to retrieve data from the SSAS cube via ECS using Kerberos & Delegation.

You can see that it's a fairly involved process, and each arrow encapsulates a further series of sub-tasks that occur to achieve the desired outcome (The Visio diagram used to create this image is here). In some cases you may also require delegation (represented by the arrows with the yellow highlights) at the SSAS server, if you are querying live data from the database and you want the figures to be security trimmed.

Based on the diagram above, in the table below I highlight which SPN's are required for Excel to work and which ones can be left alone. I recommend migrating all of the authentication types over at once - mainly because it's easier to manage... however it's not necessary as indicated...

Other accounts that are needed during an installation of SharePoint

Let's get underway. First we'll run through the work that needs to be done by your local friendly Domain Administrator :)

Create the SPN's:

Start by filling out the following table - this makes it easier to work out the required SPN's

ID	Account	More Info	Fill out the information here
PWSNBN	Primary Web Server's Net Bios name	Get this from the "My Computer" properties (Computer Name tab and look beside the "Full Computer Name" heading - will look like servername.companyname.internal - write down the servername part, not the whole lot)	PWS Machine NetBIOS name:
PWSDNSN	Primary Web Server's DNS Name	The name set up in DNS that allows access to the site using a name and normally the default port 80 (this site would normally have a host header mapping in IIS and a matching Alternate Access Mapping in MOSS if set up correctly) eg http://ExcelSite	PWS DNS Name:
IDN	Internal Domain Name	Get this from the "My Computer" properties (Computer Name tab and look beside the Domain heading)	eg companyname.internal
PWSID	Primary Web Site application Pool Identity	Open up IIS Admin console, expand primary web site, view properties and look on the "Home" tab. These's a Web Application field listed and it's the identity of this app pool we are after	domain\username
ECSNBN	The ECS Machine's NetBIOS Name	Get this from the "My Computer" properties of the server running ECS, if it is different from the server running the SSP (Go to the Computer Name tab and look beside the "Full Computer Name" heading - will look like servername.companyname.internal - write down the servername part, not the whole lot)	ECS Machine NetBIOS Name:
SSPNBN	SSP Machine's NetBIOS Name	Get this from the "My Computer" properties (Computer Name tab and look beside the "Full Computer Name" heading - will look like servername.companyname.internal - write down the servername part, not the whole lot)	SSP Machine's NetBIOS Name:
SSPID	SSP application Pool Identity	The application pool identity for the Shared Services Management site	domain\username
SSPNAME	The SSP Name	The name you have assigned the SSP attached to your web application	SharedServices1
MYSITEDNS	The My Site DNS name (If defined)	This is the DNS name you have assigned to My Sites (eg mysite.intranet) - only required if you are planning on running My Sites under Kerberos	mysite.intranet

Now we need to create the SPN’s attached to the Accounts used to run the site’s app pool. You need an SPN for the machine’s NetBIOS name, the FQDN and any DNS names you have set up. So, using the table above you need to run the following lines (without the square braces[], replacing the ID's from the table you have just created):

setspn -a HTTP/[PWSNBN] [PWSID]
setspn -a HTTP/[PWSNBN].[IDN] [PWSID]
*setspn -a HTTP/[PWSDNSN] [PWSID]
*setspn -a HTTP/[PWSDNSN].[IDN] [PWSID]
setspn -a HTTP/[ECSNBN] [SSPID]
setspn -a HTTP/[ECSNBN].[IDN] [SSPID]
setspn -a HTTP/[SSPNBN] [SSPID]
setspn -a HTTP/[SSPNBN].[IDN] [SSPID]
^setspn -a HTTP/[MYSITEDNS] [SSPID]
^setspn -a HTTP/[MYSITEDNS].[IDN] [SSPID]

Update 13/9/2008:
Thanks go to deannie for pointing out the missing HTTP/ in the setspn commands

Update 23/2/2009:
A good friend of mine, James Milne from Myriad Solutions used the information in this article to create an InfoPath form that generates all of the settings for you - which means all you need to do is copy and paste it into a Command prompt. You can download the package and user guide here. You do need InfoPath 2007 installed to view the form, though.

* - Note there may be more than one pair of these to do if you have multiple DNS / Host names set up for the main site.
^ - You only need to set these up if you plan for users to access MySites under a different DNS name using Kerberos

Example:

if you ran a site called  http://mymossWFE:1234 with a host header mapping to http://myintranet and the web service ran under the Application pool account SVC_MOSS_WEB, you would need the following SPN’s created.
http://myintranet domainName\SVC_MOSS_WEB
http://myintranet.companyname.internal domainName\SVC_MOSS_WEB
*http://mymossWFE domainName\SVC_MOSS_WEB
*http://mymossWFE domainName\SVC_MOSS_WEB

The Shared Services account being used by the Excel site – building on the previous example, if the SSP used by the myintranet site was running on the site http://ecsserver:10070 under the user SRVC_MOSS_SSP, you would also need the following SPN’s:
http://ecsserver domain\SRVC_MOSS_SSP
http://ecsserver.companyname.internal domain\SRVC_MOSS_SSP

* Note - If the ECS Server and the WFE server are the same, do not create these SPN's (as you will be mapping the same SPN's to 2 different user ID's)

For all of the user accounts you have just created SPN’s for, set them up in Active Directory so they can use delegation - 'Trust this user for delegation to any service (Kerberos)* - and ensure that the account is not marked 'Sensitive (Cannot be delegated)'

*Note - Microsoft recommend using constrained delegation - where you nominate the servers you are delegating user credentials to (on the same tab in AD Users & Computers). I think that's a great idea as part of a process to lock down the production environment once you have everything up and running - but make it work first, that way when you make changes locking it down, you know what breaks the system as soon as it breaks.

This ends the work that the AD Administrator needs to complete

Next, Enable Kerberos on your web applications (this section is direct from Martin's Blog):

• Open Central Administration
• Navigation to Application Management > Authentication Providers
• For each web application that you need to change, based on the SPN's you have just created:
  • Choose the web applications you wish to configure for Kerberos from the drop-down in the top right corner
  • Click on 'Default'
  • Set the authentication to Negotiate (Kerberos)
  • Click OK

IISRESET when complete

Enable Kerberos on your SSP (The machine hosting your Admin Site):

• Open a Command Prompt and navigate to your '12\Bin' directory (normally c:\program files\common files\microsoft shared\web server extensions\12\bin) 
• Run 'STSADM.exe -o SetSharedWebServiceAuthn -negotiate'

Configure Component Services on all web servers:

• Open Component Services on the MOSS server
• Navigation to Component Services > Computers > My Computer
• Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate (see http://support.microsoft.com/kb/917409)
• Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
• Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
• Edit Launch and Activate Permissions
• Grant all of your application pool accounts 'Local Activation' permissions (see http://support.microsoft.com/kb/920783). In our example, these accounts would be domain\MySiteAppPool, domain\SSPAdminAppPool, domain\PortalAppPool

Configure Excel Calculation Services for Delegation:

• On your SharePoint server running ECS, Run the following command where [SSPNAME] is the name of your Shared Service Provider:
• stsadm.exe -o set-ecssecurity -ssp [SSPNAME] -accessmodel delegation
• Now run the following command:
• stsadm.exe -o execadmsvcjobs
• IISRESET

Still to come:

• Configuring ECS & Moss to display Spreadsheets
• Kerberos Troubleshooting - What to do when it turns to poo
• How to run multi-tier ECS without Kerberos or SSO (and what you miss out on)

Hopefully this article has been of use to you. Thanks for dropping by!

I wanted to capture this as it's a really useful way to get a hotfix that's not immediately needed but still offers some benefits - from Stefan Goßner's blog, go here - https://support.microsoft.com/contactus2/emailcontact.aspx?scid=sw;en;1410&WS=hotfix - fill out the form and receive the hotfix within 8 business hours (vs spending 10 minutes on the phone answering 20 questions with a MS support staff member).

Brad

Just got back from the Australian Partner Conference at Hamilton Island with the wife & kids - had a great time up there and got to meet some amazing people, like Ian Palangio (an Office Solution Specialist from MS), Robin Young (SharePoint Product Manager), Colin Timm (MS Director, Enterprise Customers), Emy (our PAM's Manager and someone who really looks after livePoint) and a whole stack of partners (Brett, Brian and co from OBS, Correct Solutions, Simon from Inspire IT, Craig - my old boss - from Dataract - some of which we will be working closely with in the very near future for both internal & client-facing projects).

Best work-oriented experience: To see what networking is all about. I mean, I'm a tech dude. What do I need to know about all this Salesy stuff, right? Some of our biggest deals this year will probably end up being made based on the outcomes of a discussion at a pub on Hamilton Island.

Best Drink: Vodka Red-bulls. I've had them once before. My mind was a bit messed up from the Vodka, but I did not blink for hours at a time.

Best Recreational Experience: Hmmm. There were 3 things that I probably will not get the chance to do again, but only one that can be done around that part of Australia - Snorkeled at the Great Barrier Reef off Hayman Island. Unforgettable.
I was a "Grinder" on a yacht (one of the guys who spins the handles really fast to move the sails around) and also went to a Shooting range (learning that "Skill in First person shooter <> Skill with real guns"). Pull!

Most embarrassing moment: When my son started to snorkel after about 2 minutes of practice while dear old dad sits in knee-deep water trying not to hyperventilate for 15 minutes (I got out to look at the reef eventually, then it was all over too soon  )

Biggest disappointment: Not enough photos or time with the family (I only really got to spend Saturday with them... but I was there to work after all).

Most Entertaining Moment: Well, livePoint got to present a 15-minute talk as part of Robin's presentation on MOSS 07 CRM about the company, some of the solutions we've done (For BT, Nutrimetics and Qantas) and how Echo for SharePoint allowed us to roll out these large MOSS applications with a lot less effort than might have otherwise been required (public beta coming soon) - the entertaining part was when the boss walked on his hands at the end of the presentation - I kid you not, there was one of the company owners, doing handstands in front of 100 partners. He had people coming up to him for the rest of the conference saying how entertaining the presentation was, so I guess it helped to keep livePoint in people's minds.

If you are a partner and are looking at aligning your business strategy with Microsoft, or want to see what others are doing then get along to next year's conference - you will not regret it.

Brad

Hi all.

Just noticed that Joel has released a list of the top 17 support calls for the latest version of SharePoint products - well worth a look and could be an effective "List of things to check when reviewing a Client's site for the first time" type of list. Some timely reminders in there of basic things that can trip up a SharePoint deployment, especially around permissions. What's the first one at the top of the list?

Backups!
Backups!
Backups!
Backups!
Backups!
Backups!
Developers!
Developers!
Developers!

Oops - different speech. The point is, make sure your backup plan is running and can be restored before you start making wholesale changes to the environments or investing months of development time into a custom SharePoint app.

The list...

• Do you know your backup frequency and last successful backup?  You would be surprised how many customers call support with catastrophic failure and have no backup to recover with.
• Are you monitoring all your disks?  If you did a simple/basic all in one install is it all on one drive that you are watching?  Disk space available on WFE and SQL, common support issue is Basic install running out of drive space for SQL
• When you enumerate your site collections in your farm are the URLs correct?  Are you using localhost or servernames?  If you are are you using alternate access mappings.  AAM not set or misconfigured is common.  This is a top support issue and one to watch out for.  If you are confused about these check out the SharePoint blog which has 3 posts on what every administrator needs to know about alternate access mappings. http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx
• Changing permissions behind the back of SharePoint on the installation directories, home directories, where the app pool doesn't have appropriate permissions can and will break the farm silently (browse/read access often will look good) without you realizing it - Permissions check, do all of the managed directories owned by WSS/MOSS have default or expected permissions configured
• Ensure that each content database in the manage web application manage databases has a server assigned for indexing - Search, are content databases assigned to an indexer (WSS Search top support issue)
• Kerberos more secure right?  It is more complex, no question, but it can be worth it.  If Kerberos is enabled does customer have an SPN configured, http://support.microsoft.com/kb/832769
• One of the more common problems I've seen... Status of service accounts, are any service account passwords expired or otherwise broken, http://support.microsoft.com/kb/934838
• If large file support is enable are the myriad of configuration settings to make this work configured, http://support.microsoft.com/?id=925083
• Scan the SharePoint farm and report if any of our capacity limits are exceeded, http://technet2.microsoft.com/WindowsServer/WSS/en/library/2aa12954-2ea7-475c-9dce-663f543820811033.mspx
• SMTP relay or anonymous relay - Ensure outgoing email server settings set correctly and can we relay through specified SMTP server (you can verify by using telnet to the SMTP server and if we get 220 then it's successful)
• Is Client Integration turned on even though we don’t support it with Forms Auth (warning/caution)
• SQL and OS versions - Is SharePoint deployed on a supported OS.  Common problem is for MOSS customer dose not have SQL 2005 SP 2 installed and Search breaks, WSS 3.0/MOSS 2007 is not supported on Windows 2000/NT 4.0
• Does web server administrator have admin permissions on SQL server to run stsadm?  Stsadm runs in context of logged in user and must have service account level permissions on SQL to run commands.  Also ensure app pool account when switching has appropriate access.
• Remember, remember to install prerequisite service packs and run prescan as successful before upgrade.
• Ensure that a domain account is used to connect to the databases prior to upgrade
• Check if /3GB switch is enabled in boot.ini, WSS does not support /3GB switch http://support.microsoft.com/kb/933560

Cya!

As part of implementing some improvements to a client's MOSS Enterprise site that I'd recently recommended they undertake, I had to change the accounts that were being used in their environments to ones that were independent from each environment. I've been caught too many times by a developer doing some development who manages to miss-key the AD User's password into a config file / registry key. The app being developed is then fired up and promptly locks the account out. At the same time, another unrelated system in another part of the building stops working. Why? Because the same AD Account was used in critical aspects of both systems.

Never Ever Use The Same Accounts to Run Your Development And Production Environments!!!

Anyway, they got me back to make this change because it can be tricky. Sure enough, it was. The biggest challenge when making wholesale changes to the service / app pool accounts is that if the farm account update fails to work properly, you then struggle to perform the rest of the changes because the security decryption keys MOSS uses to keep a track of passwords is corrupted. Oh man!

So I fired off the first change and waited... and waited... the WWW Publishing service failed to shut down properly, so after 20 minutes I figured I'd reboot the server and try it again (looking back, I may have saved some time by using pskill to terminate the process instead of rebooting, but it would have resulted in the same issue). Then in the event log, I started to see a proliferation of these error messages - "Error during encryption or decryption. System error code 997" and "An unhandled exception occurred in the user interface.Exception Information: Unable to connect to the remote server"

Once in this precarious position, Microsoft's recommended solution - for the closest example of something that comes close to the error message - is to rebuild the config database (http://support.microsoft.com/kb/927156) - but it's not much help onsite at a client's place... luckily there are some alternatives. Once the Farm account is half-changed, you cannot successfully change the rest of the accounts through the UI... but stsadm is the answer. Joel has the information on this page - http://blogs.msdn.com/joelo/archive/2006/08/22/712945.aspx

 Just like using a sledgehammer to swat a fly, stsadm is not encumbered by a user interface or any of those nice-to-have things - it seems to be built around the premise "If it doesn't work, force it. If it breaks, it needed reinstalling anyway!" :)

So with stsadm, I went through the following steps:

First, to fix the central admin account's decryption key used to drive the app pools, complete the following on the server running the Admin site -

• From the bin directory, run Stsadm –o updatefarmcredentials –userlogin <domain\name> -password <password>
• Then run iisreset /noforce.

On each other server in the farm, you will need to perform the following step -

• As each server stores an encrypted version of the admin account password, you will also need to execute the following command for the account used to run the admin app pool -
•  stsadm –o updatefarmcredentials –userlogin <domain\name> -password <newpassword> -local
• Then run iisreset /noforce.
• You will have to remove the "Administration Application Pool Credential Deployment" job that gets created (if it still exists) using the timer job definitions page (otherwise it will prevent you from progressing through the next steps). You can delete it using
  "%commonprogramfiles%\microsoft shared\web server extensions\12\bin\stsadm" -o deleteconfigurationobject -id "d36cd1d0-4f27-490a-842a-80e587110411"
  
•  Then to update the other moss site app pools -
• Stsadm –o updateaccountpassword –userlogin <domain\name> -password <password>
• If you happen to use the same account to drive the admin site and the web site(s) (naughty) then you will need the noadmin switch eg
• Stsadm –o updateaccountpassword –userlogin <domain\name> -password <password> [-noadmin]
• The Web site app pools for the non-admin sites should take care of themselves once you do the Farm Admin account, but if not then just use the "UpdateAccountPassword" function on the server to resolve the issue.

Then you will need to fix the SSP's...

• From the server running the SSP you need to run the following command for each SSP that uses credentials to operate (like ECS and FS), except for the search services (they're next) -
• stsadm -o editssp -title <ssp name from the farm's Shared Services page> -ssplogin <domain\name> -ssppassword <password>
• You then run the following commands for the search services
• stsadm -o osearch -farmserviceaccount <OSS searchserviceaccount> -farmservicepassword <OSS password>
  and...
• stsadm -o spsearch -farmserviceaccount <WSS searchserviceaccount> -farmservicepassword <WSS password>
• You now need to go into the search service section of the UI and change the indexing and crawling accounts if required.
• Lastly, the SSO Service has to be changed using the Services Applet in the Administration Control section of the server it runs on.

At this point, an IISReset is probably a good idea (a reboot is an even better idea) - once this is done, attempt to access each affected area of the farm and verify that they are all now functioning correctly. If you still see some issues, use the relevant part of this guide to try and reset the credential information. Eventually (after 4 attempts) I moved past the first set of steps to change the Admin site app pool account - the rest was plain sailing from there.

Hope this is of help to someone one day :)

Brad