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.