SharePoint 2007 Feature Activation Commandment

Thou shalt make sure thou art a Site Collection Administrator when running STSADM -o ActivateFeature that creates new sites or else thou art doomed to suffer painfully with Access Denied errors and half-baked sites.

On 2011-05-27. on a SharePoint 2007 SP2 project I was working on, the Farm Administrator was running a series of STSADM commands I had given her to install and activate  a brand new (to the first level integration environment she was logged into) feature.  The STSADM command, ActivateFeature, consistently failed for her yet never once failed for me in my development environment.

It turned out, the actions of the FeatureActivated event were such that they could only be performed by a Site Collection Administrator.  Farm Administrator privileges were not enough.   Once she made herself a Site Collection Administrator in addition to being a Farm Administrator, the feature activated with zero errors.

Running PowerShell script file from BAT file

I’ve seen a lot of information about how to run a PowerShell script from inside a BAT file, but most seem very outdated, using the “&” (ampersand) character together with a difficult to remember set of single and double quotes.   For me at least, the simple answer is something like the following, where we assume parameters are passed into the BAT file via the usual method, via %1, %2, etc.

PowerShell.exe -file c:\someplace\someScript.ps1 %1 %2

Very easy.  No convoluted &.  No complex double-quote characters surrounding single-quoted values.  I hope this helps others who, for whatever reason, have to call a PowerShell script from inside a BAT or CMD file.

Where is SharePoint 2010 Service Pack 1? The world wonders.

Those of you who know your history will instantly recognize the title above as borrowed from the coded message of October 24, 1944 from Admiral Nimitz to Admiral Halsey, which originally read “Where is Task Force Thirty Four?” plus the padding phase “The world wonders” which was designed to confuse the Japanese.

In today’s world, it means that approximately a year after it first appeared, SharePoint 2010 still lacks an official Service Pack. The world wonders when it will show up.

Yes, there are numerous (at least five) “cumulative updates”, but I do wonder what kind of person has converted or is planning a conversion of any large production SharePoint 2007 installation to a production SharePoint 2010 installation without first waiting for the official Service Pack 1.

Having used Microsoft technology since 1987, I’ve learned (sometimes the hard way) to always wait for Service Pack 1 before committing to a new major version of anything produced by Microsoft. If you don’t believe me, ask anyone who jumped into SQL Server 7 before Service Pack 1.

Update 2011-05-28: Microsoft says that Service Pack 1 should arrive by then end of June 2011.

No SQL Server 2008 R2 public beta or release candiate – Microsoft blows it again!

To compound their gross mistake of not providing a public Release Candidate for SharePoint 2010, today I learned that Microsoft has made an even bigger mistake: skipping public beta and public Release Candidates for SQL Server 2008 R2.  God help us all.

No SharePoint 2010 public Release Candidate = bad move by Microsoft

It appears Microsoft has totally disrespected the individual SharePoint developer by not making a public Release Candidate available for SharePoint 2010 to MSDN subscribers. Instead, I see that Microsoft has announced they are releasing SharePoint 2010 to manufacturing on April 27, May 1 or May 12 (none of which mention MSDN subscriber availability, a glaring omission). I would like to go on record as saying it’s a bad move on Microsoft’s part to only provide the Release Candidate to country club, blue-blood elites who can afford the huge price tag to be a part of those groups. The rest of us individual SharePoint developers “can eat cake” (which was not the sweet stuff you think it is – go read your history books if you don’t believe me) as far as Microsoft is concerned.

VSeWSS 1.3 – The Nearly Forgotten, Shunned Red-Headed Step-Child of SharePoint 2007

It was March 17, 2009 when Microsoft released Visual Studio Extensions for WSS 3.0 (VSeWSS) 1.3 in Community Technology Preview form. At the May 2009 DC Regional SharePoint User Conference, we were informed by Microsoft that the only supported migration path for custom solutions from SharePoint 2007 to SharePoint 2010 would be those solutions created using VSeWSS 1.3. During that same May 2009 SharePoint Regional Conference, we were informed that the final version of VSeWSS 1.3 would probably be available sometime during Summer 2009.

Well, here we are entering 2010 and it appears the sour economy has forced Microsoft to take a hard look at what products and services generate revenue and which ones are “nice to haves”. From where I’m standing, VSeWSS 1.3 seems to fall in the “nice to haves” category, shunned like an unwanted red-headed step-child, perhaps to be picked up and finished on a low priority basis if time and staffing permits in 2010. Maybe it will be available when SharePoint 2010 ships sometime in the second half of 2010. At this point, it’s anybody’s guess.

Windows 7 and SharePoint 2010 – Broken As Designed (B.A.D.)

If you are eager to use 64-bit Windows 7 Ultimate as your host for building Windows Virtual PC guest virtual machines running SharePoint 2010, you are in for a rude awakening.

Only months after confirming that SharePoint 2010 will run only in 64-bit environments, Microsoft has provided us no way to try out a virtual SharePoint 2010 appliance or build our own virtual machine guests because Windows Virtual PC won’t allow you to create a 64-bit guest, even though you are running a 64-bit host version of Window 7.

How does Microsoft expect developers to learn SharePoint 2010 if we cannot build a 64-bit guest VM to run under a 64-bit Windows 7 host? Do they really expect everyone to install a 64-bit server operating system on our laptops just so we can run 64-bit SharePoint 2010 VM’s?

Hey Microsoft.  That sound you hear is a bunch of people and their money going over to VMware Workstation, which will gladly install a 64-bit guest operating system in a virtual machine running on a 64-bit Windows 7 host.

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.