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.

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.

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.

SQL Server job schedule needs to be disabled after rebuilding MOSS 2007

A few months back, I had to perform a partial rebuild of my MOSS 2007 SP1 environment. One of the steps was to build a new SSP using SharePoint Central Admin which in turn created a new SQL Server 2005 SP3 database for that new SSP. Everything has been working fine. The other day, I fired up SQL Server Management Studio and decided to explore the SQL Server Logs. Inside those logs I found endless occurrences of the following error message:

Login failed for user ‘mytestdomain\sqlserver’

The message was occurring every minute.

I searched the internet and found several references to various SQL Server Jobs that MOSS 2007 SP1 sets up under SQL Server Agent. One such job has a long title that ends with “DB_Job_DeleteExpiredSessions”. In my case, there were two of those jobs, one for the old, discontinued SSP and one for the new replacement SSP. When I right-clicked on the old job and chose View History, the same pattern of errors was visible that I had seen earlier in the SQL Server Logs. I disabled the scheduling of that job and the errors stopped.

Lesson learned: when you reconfigure your SharePoint SSP’s, don’t forget to check SQL Server Jobs associated with any SSP’s that you replaced or deleted to insure your SQL Server Logs aren’t filled with needless error messages about failed logins.

Initial Thoughts On SharePoint 2010 Workflow Development Using WF 4.0, Visual Studio 2010

After reviewing the workflow-related videos from PDC 2008 and the SharePoint-related videos about Visual Studio 2010 on Channel9, I’ve come to the initial conclusion that SharePoint 2007 was not the “real” SharePoint for developing real-world workflows.  By that I mean that SharePoint 2007 is merely a “revenue making place holder” for Microsoft until the real SharePoint (2010, a.k.a. 14) comes out, complete with “proper tooling” for creating real-world workflows.

Think about how many add-ons it takes to turn Visual Studio 2005 into a viable custom SharePoint workflow creator.  Visual Studio 2008 takes fewer add-ons, has improved debugger support and some deployment capabilities,  but still lacks built-in capabilities to perform fundamental “duties” like generating a WSP.  You still need add-on tools from CodePlex and other places to turn Visual Studio 2008 into a half decent custom workflow development tool.

Even the latest CTP for Visual Studio 2008 Extensions for WSS version 1.3 does not provide the new Package or Retract commands for any project based upon the Office 2007 SharePoint Sequential Workflow template.  I know.  I tried it and found out the hard way that the workflow project templates in Visual Studio 2008 SP1 are still second-class citizens when it comes to VSeWSS.  You still need WSPBuilder and other tools available from third parties to perform the things that Microsoft tools still won’t do.

Don’t you just love the “flying blind” approach to creating ASP.Net workflow task forms in Visual Studio 2005/2008?  May God have mercy on Microsoft if that is still the case in VS 2010.  Better yet, why not let me design MOSS 2010 workflow task forms using WPF, perhaps in combination with Expression Blend or a similar XAML-based GUI design tool?

It’s only in Visual Studio 2010, together with .Net 4.0, WF 4.0 and its underlying XAML do we see (at least from the videos I’ve watched and the MSDN Developer Conference I recently attended) what I call “professional grade” tools for developing complex custom SharePoint workflows.  You can read about some of the improvements in the January 2009 edition of MSDN Magazine.

The fact that the workflow engine and the Visual Studio 2010 workflow designer were completely rewritten should tell you a lot about how Microsoft regards the quality of the “developer experience” when designing, coding, and even unit testing a custom SharePoint 2007 workflow in Visual Studio 2005/2008.  I found myself spending more time “wrestling” with SharePoint, InfoPath 2007 and WF 3.x to overcome their short-comings rather than spending time on the business process that caused us to turn to custom SharePoint workflows in the first place.  Have you ever sprinkled extra Delay Activities as part of a loop in your custom workflows for the sole purpose of waiting for the workflow to serialize a workflow task and thus generate the needed ID value for the purposes of generating a hyperlink value?  With SharePoint 2010 workflows, all you have to do is issue a Persist command.  Where was this KISS principle two years ago?  Probable answer: not enough time and too much pressure to keep feeding the Microsoft “revenue machine”, which requires regular feeding a minimum of four times a year when those all important 10Q and 10K reports are reviewed on Wall Street.

As more and more information about the initial “tooling” for SharePoint 2010 workflow development becomes available, perhaps in the form of downloadable virtual machine images, I’ll be interested to see if other people come to the same conclusion about the viability of the “tooling” that was initially delivered by Microsoft for SharePoint 2007 workflow development (i.e., minus all the subsequent add-ons).

The short version of this article: Under VS 2005/2008, SharePoint 2007 workflow development was more of a “bolted on” (after the fact) experience, not the “built in” experience we were all looking for.

Now if I could only find a decent 64-bit laptop running Windows Server 2008 R2 (a.k.a. Windows 7 Server) for that next SharePoint development machine…oh, well, subject for another post.

Keeping SQL Server 2005 Patched

SharePoint depends on SQL Server 2005.  Therefore, keeping SQL Server 2005 patched is something every developer should be aware of.

You may think putting Service Pack 3 (SP3) on is all you need to do to keep SQL Server 2005 up-to-date.  Not true.  To understand how/why Microsoft delivers fixes for SQL Server 2005, the support article that describes SQL Server Incremental Servicing Model  is a “must read”, not just for DBA’s, but anybody who deals with SQL Server 2005, even indirectly (e.g., SharePoint administrator or SharePoint developer).

While I’m at it, visit The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 3 was released.  In addition to information about the three releases of “post-SP3 cumulative update packages”, you’ll see the latest SQL Server 2005 internal numbering.

To see what version of SQL Server 2005 you are running, run the following query:

SET NOCOUNT ON;

SELECT serverproperty('Edition') [Edition],

        CASE serverproperty('EngineEdition')

               WHEN 2 THEN 'Standard or Workgroup'

               WHEN 3 THEN 'Enterprise, Enterprise Evaluation, or Developer'

               WHEN 4 THEN 'Express, Express Edition with Advanced Services, or Windows Embedded SQL'

               ELSE '{unknown}'

        END [Engine Edition],

        serverproperty('ProductVersion') [Product Version],

        serverproperty('ProductLevel') [Product Level]

 

With just Service Pack 3 installed on my SharePoint development box, the output from the above command is:

Engine: Enterprise Edition

Engine Edition: Enterprise, Enterprise Evaluation, or Developer

Product Version: 9.00.4035.00

Product Level: SP3

 

The latest downloadable post-SP3 cumulative update package (#1) can be found here.

Using PowerShell With SharePoint – an example

I recently needed to clean out some tasks from the task lists on my development box.  Unfortunately, I had attached an ItemDeleting event receiver to most of the task lists as part of a custom workflow.  The event receiver prevents a task assignee from deleting their assigned task.  Instead of writing a C# console application, I wrote the PowerShell utility (using my favorite tool, PowerGUI) shown below and simply typed the following at a PowerShell prompt to remove all the ItemDeleting event receivers from all the lists:

SPRemoveItemDeletingEventReceivers http://workflow2/FredsWfTestSite

# SPRemoveItemDeletingEventReceivers.ps1
#
# Purpose: Removes any ItemDeleting Event Receivers from all lists on the specified site collection
#
# Example: SPRemoveItemDeletingEventReceivers http://workflow2/FredsWfTestSite
#
# show what we expect in the form of parameters to be passed to this script
param([string] $siteName)

# following makes it easier to work with SharePoint and also means you have to run this script on the SharePoint server
[void] [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint' ) | Out-Null

$site = New-Object -TypeName Microsoft.SharePoint.SPSite $siteName
[Microsoft.SharePoint.SPWeb] $web = $site.OpenWeb()
[Microsoft.SharePoint.SPListCollection] $lists = $web.Lists
Write-Host $sites.Count
[Microsoft.SharePoint.SPList] $list = $null
[int] $iList = 0
for( $iList=0; $iList -lt $lists.Count; $iList++)
{
	$list = $lists[$iList]
	# since we only attached an ItemDeleting event receiver to task lists, only look at the those types
	if ( $list.BaseTemplate -eq 'Tasks' )
	{
		[string] $listTitle = $list.Title
		Write-Host $list.Title $list.EventReceivers.Count
		[int] $evIdx = 0
		[bool] $found = $false
		# for every Event Receiver defined for the list ...
		for($evIdx = 0; $evIdx -lt $list.EventReceivers.Count; $evIdx++)
		{
			# get a reference to the Event Receiver
			[Microsoft.SharePoint.SPEventReceiverDefinition] $er = $list.EventReceivers[$evIdx]
			# if it's a type we care about ...
			if ( $er.Type -eq 'ItemDeleting' )
			{
			    [string] $erType = $list.EventReceivers[$evIdx].Type
				# get rid of it
				$list.EventReceivers[$evIdx].Delete()
				Write-Host "Removed an $erType Event Receiver from $listTitle"
				$found = $true
			}
			# if we removed any of the specified Event Receivers from the list, update the list
			if ($found)
			{
				$list.Update()
			}
		}
	}
}
Write-Host 'Done'