Since leaving MSFT, I’ve had to undertake building my own dev machine that’s ready to take on SharePoint 2010 projects, and today I got the final piece in place.  Well, it’s actaully a “penultimate final piece”:  8 GB of DDR3 1066Mhz RAM.  I’ve already configured my Lenovo T510 to dual boot using VHDs for Win7 Ultimate and Win2k8 R2, but the latter was really taxed after installing SQL Server 2008 and SharePoint 2010 – it was peaking at 3.67 GB, bringing my machine to its knees.

No longer:  With the new RAM installed, it now cruises along at a liesurely 2.68 GB with all four engines sipping cycles:

Fantastic.  Next up is to put Visual Studio 2010 Premium on the image and she will be complete!  Then I can back up the VHD to an external drive for disaster recovery, or to run as a Hyper-V image from a stock Win2k8 R2 VHD.

Today, a friend remarked to me that according to an SSL framecheck site he uses (Fortify SSL Check) his 64–bit Win7 + IE8 configuration was registering as 128 bit AES by default, and not – as he anticipated – 256 bit AES (as FireFox does, for example).

This is true and by design:  The IE team made a conscious decision to trade off cipher strength for speed, since 128 bits is sufficient for securing most channels reliably and not impact speed on HTML-heavy sites.  However, what if you do want 256–bit AES cipher strength as the default for securing IE’s channel?  Fear not – here’s the resolution I was able to surface:

1. Launch “Edit Group Policy” from the Start menu.
2. Navigate to Computer Configuration—>Administrative Templates—>SSL Configuration Settings via the treeview control.
3. Note that in the right pane, the entry is not enabled – double-click the entry to bring up the edit dialog and select the “Enable” radio button.
4. In the text box under Options on the left side, paste-in the comma-delimited list from the following file:  File Attachment: ie8_ciphersuites_group_policy.txt (1 KB) 
5. Click OK and close off the policy editor dialog.
6. Reboot.
7. Navigate to the Fortify site and verify that AES 256 is your default cipher strength.

The “magic” that makes this happen is in the list of ciphers which are parsed sequentially – I simply changed the order of the first four entries from:

TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA

to:

TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA

By now you’re probably well-acquainted with the “discovery” of so-called “god modes” or “superuser” features in Windows 7.  In actuality, these are nothing more than undocumented developer shortcuts to common control panel dialogs, apps and utils.  In fact, the wild-eyed brouhaha that’s erupted from this has caused some mirth down Redmond way, with Windows Division President, Steven Sinofsky even providing a C|NET reporter with a list of the shortcuts.

Here’s how you can quickly create your own “god mode” shortcut links to experiment with:

Step 1:  Copy the following code into your fave editor and save as a batch file – I called mine “godmodes.bat” (removing the line numbers).  Save this file in a folder on your desktop or other preferred location.

    1 mkdir "GodModeA.{05d7b0f4-2121-4eff-bf6b-ed3f69b894d9}"

    2 mkdir "GodModeB.{1206F5F1-0569-412C-8FEC-3204630DFB70}"

    3 mkdir "GodModeC.{15eae92e-f17a-4431-9f28-805e482dafd4}"

    4 mkdir "GodModeD.{17cd9488-1228-4b2f-88ce-4298e93e0966}"

    5 rem mkdir "GodMode.{1D2680C9-0E2A-469d-B787-065558BC7D43}"

    6 mkdir "GodModeE.{1FA9085F-25A2-489B-85D4-86326EEDCD87}"

    7 mkdir "GodModeF.{208D2C60-3AEA-1069-A2D7-08002B30309D}"

    8 mkdir "GodModeG.{20D04FE0-3AEA-1069-A2D8-08002B30309D}"

    9 mkdir "GodModeH.{2227A280-3AEA-1069-A2DE-08002B30309D}"

   10 mkdir "GodModeI.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}"

   11 mkdir "GodModeJ.{4026492F-2F69-46B8-B9BF-5654FC07E423}"

   12 rem mkdir "GodMode.{62D8ED13-C9D0-4CE8-A914-47DD628FB1B0}"

   13 mkdir "GodModeK.{78F3955E-3B90-4184-BD14-5397C15F1EFC}"

   14 mkdir "GodModeL.{ED7BA470-8E54-465E-825C-99712043E01C}"

Note:  The rem’ed entries were included in Sinofsky’s list, but didn’t work when I created them – I’ve included them here for completeness.

Step 2:  Open a command console using Run As Administrator from your Start Menu and execute the batch file created in Step 1 above.

Step 3:  Behold the “God Mode” links that have been created – double-click and explore away!  The most useful one by far is the last one, the “original” God Mode discovery that provides a consolidated list of shortcuts to just about every imaginable Windows 7 control panel feature, property manager or utility.

One more note:  The folder names don’t have to be prefixed with “GodMode” – in fact, any prefix will do.  As the batch file reveals, the trick is in naming the folder with a “.[GUID]” suffix.  I’ve added an alphabetical identifier to each of my entries to keep them in order.

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: