Earlier this month (Dec 2/09) the Director/Product Manager for SharePoint, Arpan Shah, posted a wealth of resources on his blog to aid in ramping up on the new platform.  I encourage going over and taking a look – and add his feed to your aggregator.  Here are some of my favourites:

White Papers – The closest thing to “books” before the release next year:

SharePoint 2010 Overview Evaluation Guide 
SharePoint 2010 Professional Developers Evaluation Guide 
SharePoint Server 2010 Evaluation Guide for IT Professionals
SharePoint 2010 and Office 2010 Scenarios

When to use ASP.NET vs. SharePoint:

SharePoint Server 2010 as an Application Development Platform 
SharePoint 2010 Developer Platform

The answer to the riddle from my first post on this case isn’t nearly as exciting as I thought it would be.  Prior to resolving the problem, I disassembled PSCONFIG.EXE and Microsoft.SharePoint.dll using Red Gate’s (nee Lutz Roeder’s) Reflector and thought I had made a startling discovery, as shown in the sequence diagram below:

It appeared that PSCONFIG was deliberately coded to throw an exception when the Central Admin site was created under Step 2/10.  My “smoking gun” was a snippet of code within the CreateDefaultInstance method of the Microsoft.SharePoint.Administration.SPAdministrationWebApplication object:

using (SPSite site2 = application.Sites.Add(string.Empty, "$Resources:core,nav_CentralAdministrationHome;", null, (uint) SPGlobal.ServerCulture.LCID, "CENTRALADMIN", ownerLogin, null, null, null, null, null))
{ …snip… }

In particular, I was interested in the last three nulls of the Sites.Add() method which correspond to the secondary owner’s login, name and email address respectively.  I’d been burned in the past by programmatically creating sites without secondary owners – exceptions get thrown.  And this intuition seemed to be reinforced when I looked at the SPSiteCollection.Add() method overloads in detail – all roads eventually lead to an internally-scoped overload where we see the following:

info = SPUtility.ResolvePrincipal(this.WebApplication, null, secondaryContactLogin, SPPrincipalType.User, SPPrincipalSource.MembershipProvider, false);
if (info == null)
{
  throw new SPException(SPResource.GetString("CannotFindUser", new object[0]));
}

However, this turned out to be more a false-positive than a positive conclusion:  I allowed some confirmation-bias to slip into my troubleshooting.  Bah-humbug.

Case Closed:  Run PSCONFIG While Connected to Corporate Network

The true solution turned out to be of the Occam’s Razor variety:  On the advice of a colleague, I logged on to my corporate network while running PSCONFIG.EXE which allowed the utility to resolve my domain credentials which I thought were cached.  Ta-daa.

As to why the problems with a null secondary owner don’t come to the fore, I’m not sure.  I will have to dig deeper.  However, for now, I have successfully installed SharePoint 2010 + SQL Express 2008 on my Windows 7 workstation with 4GB of RAM. It runs, but it runs slowly.  Double ta-daa.

I will need to boost myself to at least 8GB of RAM to make the workstation usable as at times I am finding my memory peaking at 92% capacity.  It has settled down to 74% after exercising it a little, but this is still a little high for my liking.

I’ll be dedicating a future post on how to manage 2010 and the rest of your apps – I’m thinking a little PowerShell is in order to automate startup/shutdown of the SharePoint services so you can reclaim memory with the flick of a switch.

Update:  See the anti-climactic conclusion to this case here.

For the past several days I’ve been struggling mightily to install the standalone version of SharePoint 2010 on my Windows 7 workstation.  Since the announcement went out at the recent SharePoint 2009 conference, all the cool kids are doing it.

So, I downloaded the beta bits from MSDN, got a copy of Setting Up the Development Environment for SharePoint Server from MSDN and settled in.  First stop was to get SQL Express 2008 installed – this was relatively simple, although I did have some issues around permissions that were easily and quickly resolved.

I then followed the guidance in the doc for pre-requisites.  Actually, a better source is Jie Lie’s blog post, SharePoint 2010 Pre-Requisites Download Links.  A key trip-up for me was obtaining the right version of the Windows Identity Framework (Geneva) – silly me, I got the latest version (3.5.0.0) rather than the version Lie has on his blog, 1.0.0.0.  The Microsoft SQL Server 2008 Native Client is also a must-have, as it creates a named-instance SQL database called SHAREPOINT that is required for the standalone install.  Other than this, I followed the instructions in the MSDN article for setting up my machine, altering the XML config file and tweaking IIS.

So, the installer ran smoothly until I hit a couple of snags:

If you search for “Error 1935 HRESULT 0x80070020”, you’ll find that it is a broad error code that essentially means another process has a lock on an assembly that you need access to.  The solution turned out to be calling up msconfig and disabling all the non-system services and restarting (see Aaron Stebner’s blog post from Nov. 25/06 on how to do this).

After I resolved this problem, the installer finally ran without a hitch.  So, the next step was to run the Configuration Wizard.  And so my troubles began.  The wizard would run until reaching 2/10 tasks for creating the configuration database.  Then it bailed:

The exception had me puzzled:  “User cannot be found”.  This got me thinking that maybe permissions in the database were not what they should be.  So I opened the Security/Logins node in SQL Server Management Studio to add the dbcreator role to the NT AUTHORITY\NETWORK SERVICE and NT AUTHORITY\SYSTEM accounts (these are used by the installer when running a standalone setup for the primary admin accounts).  I should add that I had issues earlier than this that required me to add the roles just to get the wizard to turn over.

I verified that the databases were indeed being created:

So, I deleted them and decided to try running PSCONFIG.EXE from the “14 Hive” (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN) by opening a command console using “Run As Administrator”.  Same issue:

I looked into the specifics of the exception via the Event Viewer and found these details:

Missed this one – on November 19/09, Microsoft launched a new TechNet site, Update Center for Microsoft Office, Office Servers and Related Products, that consolidates the hitherto somewhat scattered updates for their Office and Office Server stack.  It now provides an up-to-the-minute dashboard of the latest released service packs and security updates – with RSS feeds, of course.

Previously, a really reliable source for this kind of info was the SharePoint Product Team’s blog (still is), but their content, esp. around service packs, hasn’t been consistently tagged of late which can lead to some confusion.  I’d recommend keeping both sites in your pocket so you can get a good overview of the current patch state for the stack.