This fix apparently worked for me and one co-worker.
Recently we had cause to do a whole lot of research ourselves and end up calling Microsoft to get our implementation vetted and troubleshot (it was not working – all or almost all connections that should have been Kerberos connections were degrading back to NTLM).
Here are the salient notes and facts about troubleshooting and achieving the ultimate goal (having Kerberos working with our systems).
Okay, so Wednesday and Thursday were my days for installing MOSS 2007 Beta2TR on our pilot servers.
I followed Steve Smith’s excellent PDF-based instructions for “slipstreaming” the Technical Refresh updates into the normal install files for MOSS 2007 Beta 2, and then prepared a DVD-ROM with those files and the .NET 3.0 CTP release, which I’d mistakenly thought were the right .NET framework and Windows Workflow Framework installs to carry out before installing MOSS 2007 Beta 2 TR.
It turned out the .NET 3.0 CTP release was the wrong choice.
What you really need are the .NET 2.0 Redistributable Framework (x86 or x64) and the appropriate install for MicrosoftÂ® WindowsÂ® Workflow Foundation Runtime Components Beta 2.2 and Visual StudioÂ® 2005 Extensions for Windows Workflow Foundation Beta 2.2 (you choose x86 or x64 near the bottom of the web page). I found this out in the comments to this post on the A Marvellous Point blog.
With these pre-installed, the MOSS 2007 Beta 2 with slipstreamed Technical Refresh went perfectly, but I must admit I’m not done with the configuration portion of the work. Lord willing, that’s coming on Tuesday.
I know that the Release bits will be out soon, but this may help folks still trying to install the Beta (which I think is still good until February 2007, if I remember correctly).
So it turns out that the 3.0 .NET framework (workflow) was the right choice, but I applied it too soon.
The best URL for the proper install procedure that I could find was on Technet, and it was hard to read and puzzle out, so here’s the read I give it. This series of steps ended up working for my MOSS 2007 Beta 2 Technical Refresh Install entirely:
- Install OS
- Install SQL 2005 (if on another server, be sure you use domain accounts for services and Application Pools for your Web Applications)
- Install Microsoft .NET Framework 2.0 and Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 (Build 3807.7).
- Also make sure IIS is installed and ASP.NET 2.0 Extensions are enabled.
- Install the MOSS 2007 Beta 2 & TR slipstream. UNCHECK OPTION TO RUN CONFIGURATION WIZARD.
- Uninstall Windows Workflow Framework.
- Install Microsoft .NET Framework 3.0 – Release Candidate.
- Run the Configuration Wizard to complete the install/configuration.
- Open Central Administration (CA) and complete the deployment.
The other gotcha I’ve already mentioned but it would be wise to keep an eye out for is that if you are running SQL Server on another box, then the same advice for SPS 2003 holds here, which is that your SharePoint Service accounts should be domain accounts, as should be the Identities you run your Web Applications, since you need to grant that account access on the SQL Server. Remember, kids, that the Network Service account has a different, unique, random PID on each server, so you can’t expect a Network Service on one server to authenticate correctly on another.
So as you may know, Microsoft and many SharePoint dev houses swear by doing development on Virtual PCs/Virtual Servers. The reason for this boils down to the fact that when you are debugging a SharePoint Web Part with Visual Studio 2003, you have to connect to the active w3wp.exe process that IIS is using and have your debugger work with that. This single-threads that process and halts/pauses it as you explore the reflected data structure states/etc.
I.e. SharePoint development doesn’t share well. I.e. Two developers trying to share the same server, while one is debugging, is ugly and crass and doesn’t belong in Kindergarten.
So the fix is to give each developer her/his own VPC to do with as he/she likes.
Anyhow, if you are doing this via Microsoft VPC 2004 SP1 (free for download these days, by the way), and you happen to be using it on a laptop/notebook, you need a hotfix (Microsoft KB 889677). If you happen to be using a laptop/notebook that’s using Intel’s 915 Chipset (i.e. some forms of Centrino chipsets), you need an additional hotfix (Microsoft KB 899525). I hear that Tablet PC owners may need a different one.
Add to this pain that you have to either find some place to download the patches that’s illicit or ask Microsoft support for the patches (i.e. risk some idiot deciding to charge you for it). I managed to find a non-Microsoft source for the hotfixes, but if you do the same, do what you can to be paranoid and cautious about the hotfixes you didn’t get from Microsoft – the reason it’s a good idea to get it from Microsoft directly is that you’re reasonably sure someone isn’t slipping you a trojan horse or something worse instead of the actual patch.
Anyhow, after installing the additional patches, VPC is flying compared to previously.