64-bit only requirement will dampen SharePoint 2010 uptake

I hope that I’m not the only person who is concerned that the 64-bit only restriction of SharePoint 2010 will put a serious crimp on people who learn new technology by installing it in VM’s on their laptop (or laptop + external drive).

In the current bad economy, I don’t know of many developers who are ditching (or can afford to ditch) their 32-bit laptops for 64-bit laptops just so they can be prepared to install and run SharePoint 2010 in a virtual machine when it makes its debut in October.

How are we supposed to learn SP 2010 at workshops and seminars or give demonstrations to users groups if we cannot do so on our existing 32-bit laptop investments? I believe there will be a serious decline in developers willing to learn SharePoint 2010 with such a high barrier to entry.

Sure, there will be virtual labs, but for me, installing and configuring SharePoint from scratch in a VM is one of the best ways to learn “What Mother [Microsoft] Didn’t Tell You About Installing And Running SharePoint 2010.” Using VMWare Workstation 6.5.2, I can use Snapshots to fork in multiple directions (e.g., WSS-only or WSS+MOSS).

I have plenty of RAM on my existing laptop (4GB) to run a 1024KB virtual machine consisting of Windows Server 2008 R1, SQL Server 2008 SP1, and SharePoint 2007 SP1, so why should I pitch that fairly new laptop in the trash and buy a new one just to be able to run SharePoint 2010 and Windows Server 2008 R2?

Restart All SharePoint Services Using PowerShell

The following PowerShell script will quickly restart all SharePoint-related services except Windows SharePoint Services VSS Writer, which I normally do not have running automatically.

# Author: Fred Morrison

# Notes: We exempt the SharePoint VSS Writer since it is rarely used.

Restart-Service  -DisplayName “Windows SharePoint Services*” -Exclude “*Writer” -Verbose

WSS/MOSS 2007 Service Pack 2 breaks People Picker

After installing WSS 3.0 Service Pack 2 and MOSS 2007 Service Pack 2 on my main development server that is part of a development domain, when I launch Central Administration and try anything that uses the People Picker (create new site collection, add farm administrators, etc.), I can no longer see domain users (new or old). I can only see local users. At least I can create site collections by designating the local Administrator as the primary site collection administrator. However, that newly minted site collection can only see other local users.  Me not happy.

I had been careful. I first installed SP2 on a virtual machine and threw everything I could think of at it. Nothing broke. However, since my virtual machines are not part of a domain, the one thing that I could not test is the very thing that has come back to bite me in the behind.

I have a case open with Microsoft regarding this issue. It seems I’m not the only customer who has reported this problem. So far, we have found that it is possible to “repair the damage” done by SP2 with a couple of stsadm commands, but only for pre-existing site collections, not ones that were created after installing SP2. The same pair of command doesn’t repair Central Administration, so I still cannot change farm administrators.

Stay tuned…

2009-06-17 update.

Microsoft had me run a utility from CodePlex, SPS<something-I-dont-recall>.exe to gather up a bunch of information about my development box and then gave me a temporary link to upload it too.  They’ve been sifting through it since last Friday and I have yet to hear back from them.

2009-06-26 update:

The problem has been resolved through a combination of things which I will post later.   For now the main two things that stand out in my mind about what finally resolved the issue are:

1. Changing the service account for SharePoint from a local account that is a member of the local administrators group on my everything in one box except the domain controller development machine to a domain account on the domain controller that is a member of the domain administrators group and running a series of stsadm commands plus using Central Administration to make changes to various services.  Apparently, WSS 3.0 SP2 and/or MOSS 2007 SP2  ”fixes” something security-related that I must have been “getting away with” for the past two years on my development box in terms of its ability to reach over to its “parent” domain controller to populate the People Picker in various SharePoint dialogs.  I hope Microsoft makes a special effort to emphasize this so-called ”cure” for a “disease” I didn’t even know existed.
2. Running a SQL script provided by Microsoft in one of their KB articles (sorry, I don’t have the link handy as I write this) that directly modifies one of the SharePoint SSP content databases (e.g., dbo.SharedServicesNew1 in my case).  Yes, I was a bit shocked that Microsoft had me do this since we all know that doing so in a production environment leaves you with an unsupported environment.  In my case, it’s a development box and that’s what those are for – to take the arrows before you inflict whatever supposed “cure” on your QA or production boxes.

I’ll have to make a huge separate post with more details after the DC Regional SharePoint conference that is going on today and tomorrow.  Right now, I’m just glad the People Picker is working again.

Update 2009-06-30:

I’ve been a bit busy of late, but for those who are interested the (now closed) case number with Microsoft was 109061148666247.