SharePoint Fun

I’m really excited to be down at SP Conf 2011 this year, along with my fellow colleagues @c0deNinja and @matthewcarriere.

We’re particularly eager this year because we’ve been working hard on the launch of our SharePoint line of add-ons: www.blackninjaparts.com. We’ve officially gone live today, just in time for SP Conf and we’ve got some super awesome t-shirts to give away throughout the week. You’ll see a few of us wearing them, so don’t hesitate to stop us anytime and grab yourself one before they’re all gone.

Black Ninja Parts Tshirt

We have a lot to offer with our web parts, super support being one of the main things you can expect. We’ll be doing our best to answer any questions, field any support issues, and overall, ensure our clients and customers get the best experience possible when purchasing with us.

We’ve also got a lot planned for the future in terms of more web parts and unique applications built right into SharePoint, so please, please, if you have any feedback or questions, reach out to one of us, we hope to surprise you with our quick and friendly response. We love it when we get superior customer support from the products we use, so our aim will be to provide our customers with the same level we’ve come to expect and appreciate from other vendors.

So check our the site, come get a shirt, and have a great week at SP Conf 2011. I hope to meet some of you there and look forward to participating in the live blogging that’s been setup by SharePointTechEdu.

I’ve been doing a fair bit of FAST search configuration and re-configuration lately, and I just wanted to point out a few things that are good to know and understand.

Let’s start with some basics. If you use the following guide for configuring FAST (and I usually do) http://technet.microsoft.com/en-us/library/ff381243.aspx, then you should be aware of:

• You configure two service applications for FAST: FAST Content and FAST Query SSA. FAST Content is a FAST Search Connector. FAST Query SSA is FAST Search Query.
• The FAST Content service application is where you configure your Content Sources and crawl MOST content. Please note that I say MOST and not ALL. Your user profiles or ‘People’ search, are crawled using the FAST Query SSA.
  
  Please reference this article for details: http://sptechland.wordpress.com/2010/10/08/fast-people-and-content-search/. This is a key thing to understand, because until you initiate a crawl for the Local SharePoint sites Content Source in the FAST Query SSA, you won’t see any people results in the People scope.
• If you’re trying to figure out HOW to crawl your user profiles, make sure that the following url is added to your FAST Query SSA – Local SharePoint sites Content Source: sps3://serverurl.

Some other things I’ve noticed:

• My scopes in the FAST Query SSA service application don’t accurately display the number of items in each scope. I haven’t gotten to the bottom of this yet.
• My Content Distributor port as recorded in the Install_Info.txt was not accurate. Read more here: http://blog.qumsieh.ca/2011/08/02/error-unable-to-resolve-contentdistributor/
• There is a neat codeplex tool for querying your FAST farm to test search results. http://fastforsharepoint.codeplex.com/

And finally, if you come across this error:

The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component ’43fa5edd-3e14-4dba-b54c-7aad045dfdf7′ in search application ‘FASTContent’ is in a good state and try again.

Run the following command:

stsadm -o provisionservice -action start -servicename osearch14 -servicetype "Microsoft.Office.Server.Search.Administration.SearchService, Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

I thought I’d do a quick post for the visitors of my blog on a new initiative by SharePoint Nick called SharePoint Weekly.

So what is SharePoint Weekly. Well, as Nick describes it, it’s “a free, once weekly email round up of SharePoint news and articles.” If you’re like me at all, you really struggle with keeping up to date with all that goes on in a given day surrounding SharePoint. It’s so overwhelming at times, that I could easily spend my entire day reading through blogs and new content just to keep up with it all. I could repeat this every single day, that’s how quickly evolving this community is! At Black Ninja, we’re a bit unique, because we run an Apple shop, using VMWare Fusion to drive our Windows/SharePoint VMs and we are heavy into iOS and Ruby on Rails development. We’ve come to really love and absolutely rely on the weekly updates available in the iOS, Ruby on Rails and Javascript communities. I feel in some ways, the SharePoint side has been lacking a bit when it comes to this type of service.

For example, on the Ruby side, we have so many wonderful weekly podcasts and round ups for content. We’ve even sponsored some of them:

• Ruby5 – Great 5 minute round up of all things Ruby for the week.
• Ruby Weekly – Another great example, and very similar to the SharePoint Weekly format.
• Javascript Weekly – Weekly updates on the javascript world.

I’m a huge fan of this idea, and I’m sure Nick would appreciate any feedback or ideas the community might have on making this service even better. I’m open to supporting it in anyway we can as well. I think what would also be interesting to see is if the SharePoint Weekly concept will need to be broken down further into different categories, such as SharePointDevWeekly, or SharePointAdminWeekly, etc.

So take a minute and sign up here: http://www.sharepointweekly.com/

Thanks Nick for taking the time out to set this up and maintain it weekly.

We’ve recently upgraded a server farm from SharePoint 2010 Server Search to SharePoint 2010 FAST Search and ran into a couple of issues with getting the content sources crawled correctly.

Scenario: We have a 2 server farm: a single application server, and a WFE. There is a separate SQL Server installation where we host our databases. FAST was installed on the application server, which it’s worth mentioning, was already running SharePoint 2010 Server Search successfully.

After going through the steps for installation, what we’ve got configured are two NEW service applications and one old one:

1. FAST Search Connector
2. FAST Query SSA
3. Search Service Application 1 – to be deleted once FAST was configured correctly

FAST Search Connector is where we configure our content sources. In the case of the SharePoint content source that we had configured, a full crawl was generating several warnings and errors, but not a single success message. Something was not right.

Checking into the event logs, I found Event ID 2567.

Failed to connect to VCVANKMSSEARCH1.vci.local:13391 Failed to initialize session with document engine: Unable to resolve Contentdistributor

The issue for us was an error in the port listed for the Contentdistributor. Note: for those of you who did not install FAST personally, and need to know what settings were inputted during installation, you’ll find them in the root of the installation folder where FAST was installed.

\\FASTInstallationFolder\Install_Info.txt

Open the above file up, and locate the following configuration section:

---------------------------------------------------------------
 
FAST Search Content Search Service Application configuration
 
---------------------------------------------------------------
 
Content Distributors (for PowerShell SSA creation):   servername:13391
 
Content Distributors (for GUI SSA creation):          servername:13391
 
Default Content Collection Name:                      sp

Notice the port number. Now navigate to:

\\FASTInstallationFolder\etc\contentdistributor.cfg

When viewing the contentdistributor.cfg file, I was able to see that the port number was different from what was specified during installation. It was in fact set to 13390. So by looking at this setting, we know that the FAST Search Connector is going to be configured incorrectly as well.

Open Central Administration, Manage service applications. Click on the FAST Search Connector and select Properties in the Ribbon. Scroll down to the Content Distributors section and change the port number from 13391 to 13390.

In our case, I deleted and recreated the content source, and now the success messages are pouring in and search results are coming back. As always, I would love to know why the port for the Content Distributors was configured differently from what was specified during installation, but unfortunately I do not have the answer to that. If anyone does, ping me and I’ll update this post.

It’s also worth noting that now that my search results are being returned, I am still seeing Event ID 2567 pop up in the logs, and am currently investigating this. Also on my radar are several Timer errors: Event ID 6398 – Failed to communicate with the WCF service.

UPDATE: After trying several different calls to MS and being told by some that my only option was to upgrade to the Feb 2011 CU for MOSS, I finally got in touch with someone who was able to give me the CU I needed. According to MS, the CU was pulled due to an issue with Project Server. They seemed to indicate to me that it will be available again at some point, but with no concrete date for when that will be. So my advice, call and be persistent and try to get someone to send you a copy.

This issue has caused me quite a lot of grief and at the time of writing this post, is yet to be resolved.

Thanks to all who attempted to help out by providing links to the CU, I’m going to outline in this post what the issue is and why those links don’t work. Hopefully someone else can make use of this and get past where we are now.

I have a current production farm whose patch level is the MOSS August 2010 CU, or 12.0.0.6545. Let’s say I need to add a new server to this farm. If I download the SharePoint Server software for MOSS from the MS site and install it, I’ll end up with 12.0.0.6421, which is SP2. Makes sense. Downloads from MS should be at the SP level, and you apply the cumulative updates as required.

In our case, we required that we patch to August 2010 CU, so that we could run the configuration wizard on this server and add it to the farm. For those of you who don’t know, if the patch level of the server you are adding to the farm is DIFFERENT from the farm itself, the config wizard will fail with an access is denied error in the upgrade log file. So getting the right patch level is important.

Now let’s review what’s currently published on this site: http://blogs.technet.com/b/stefan_gossner/archive/2010/09/02/august-2010-cumulative-update-for-sharepoint-has-been-released.aspx.

Stefan kindly lists all of the CU information for the August 2010 update. Please note I’m not talking about SharePoint 2010 here, but rather the August 2010 CU for MOSS 2007. Anyways, let’s try the following two links from Stefan’s site:

WSS: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbln=en-us&kbnum=2276474
MOSS: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbln=en-us&kbnum=2276472

You will notice that the WSS link has a hotfix available for download, whereas the MOSS link gives you:

The KB article has no public hotfixes. Please contact support if you need immediate assistance.

This means the CU has been pulled. Several phone calls with MS have occurred and I’ve received confirmation from them that the August 2010 CU for MOSS has been pulled due to an issue that affects Project Server. How frustrating! I get that they’ve pulled it, but what about those customers not using Project Server in need of this CU?

It’s been suggested by others and MS that we upgrade the farm to the Feb 2011 MOSS CU. I understand that this is an option, but it’s really not. This will take us days worth of effort to test, plan and upgrade a QA, Staging, Production and Dev environment.

I have noticed that the individual updates that make up this CU are available for download, but I would feel much better patching this server to the exact same configuration as the others. I’m not confident that what’s available now is not different from what’s been pulled.

That’s it, that’s all I have for now, I will update this post as soon as I hear back from MS. They are attempting to get the CU for us in a back channel sort of way. Anyone who has additional information, I’d be happy to post.

Lesson Learned:

WHEN DOING AN INSTALLATION OF A PRODUCTION SHAREPOINT ENVIRONMENT, KEEP THE INSTALLATION FILES SOMEWHERE DOCUMENTED AND ACCESSIBLE SHOULD THEY BE PULLED IN THE FUTURE.

In Rails, we have a concept called Freeze Gems that’s similar to this idea:

Freezing Rails is recommended if you are using a Rails application for a business site or another production environment where stability is the most important concern. If you don’t freeze your application, there is a small possibility that your application might stop working due to compatibility problems when a new version of Rails is installed on our servers.

Reference: http://support.tigertech.net/freeze-rails

I want to clarify the well known WSS SP1 declarative workflow issue that’s found in abundance on the web. We ran into this recently when attempting to use the Start Another Workflow activity that comes with the Useful SharePoint Designer Custom Workflow activities codeplex solution. Actually, if you read through the comments on codeplex, others are having the same problem with nothing really identified as the fix. This post will outline our solution, along with some guidance on the recommended Microsoft route.

This issue is outlined in detail here: http://support.microsoft.com/kb/947284.

Directly from MS: After you install Windows SharePoint Services 3.0 SP1, declarative workflows do not start automatically if the following conditions are true:

• The Windows SharePoint Services Web application runs under a user’s domain account.
• The user logs in by using this domain account.
• The site displays the user name as System Account.

So typically, when we install SharePoint 2007, we have a domain admin account that we do the installation under, or even a local administrator, and we specify a service account during installation that’s responsible for running our services and app pools. You’ll notice that when you log into SharePoint using this service account, regardless of the name of that service account, it will display System Account. This is important to understand.

What Microsoft is asking us to do is change the application pool, so it runs under someone other than what you’ve specified for the service account. So, if for example our service account upon installation was domain\wss_service, our app pool will run under domain\wss_service. You’ll need to change that to domain\new_account.

Ok so none of that was really new information, but I do want to shed some light on the issues that users are experiencing with the Start Another Workflow activity that was the original motivation behind this post. Basically, if you look through the codebase, Start Another Workflow uses elevation to do what it needs to do, to trigger the requested workflow. Elevation always runs under the credentials of the account specified to run the application pool. Read this post and it’s comment entirely to understand this process: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx.

Because we’re trying to trigger another workflow (that’s the whole point of this activity) and we’re doing it while elevated, thus running as the app pool account, IF this account also happens to be the System Account, you will receive the declarative workflow error. So, again, you either change that app pool account, or you can do something like this:

// even when taking the elevation out of this code, the workflow would still
// trigger as System Account. In theory, users may not have Start Workflow permissions
// on a given list, so it makes sense to impersonate and leverage a workflow_svc account
SPUser user = web.SiteUsers[@"domain\\new_account"];
// we could use: __Context.Web.CurrentUser.UserToken
// but what if user does not have access, so we use user instead
SPSite site2 = new SPSite(site.ID, user.UserToken);
SPWeb web2 = site2.OpenWeb();
 
// using the debugging information below, we are able to see the following output:
// user running under: Joe User
// site user: Sytem Account
// context user: Joe User
// so the web objected instantiated above is using the System Account context
string userString = "user running under:" + __Context.Web.CurrentUser.Name;
string siteUser = "site user:" + web.CurrentUser.Name;
string contextUser = "context user:" + web2.CurrentUser.Name;
 
Common.AddCommentWorkflowHistory(userString, executionContext, this.WorkflowInstanceId);
Common.AddCommentWorkflowHistory(siteUser, executionContext, this.WorkflowInstanceId);
Common.AddCommentWorkflowHistory(contextUser, executionContext, this.WorkflowInstanceId);
 
// so when we create our SPList object below, we have to use web2, not web
// so that we can make sure our workflow runs under the user context not System Account
// why don't we want to run under System Account? because SP1 prevents declarative workflows.
SPList list = web2.Lists[new Guid(ListId)];
 
SPListItem listItem = list.GetItemById(ListItem);
 
SPWorkflowAssociation myWorkflowAssoc = null;
 
//resolve any lookup parameters
string wkId = Common.ProcessStringField(executionContext, this.WorkflowIdentifier);
 
//find workflow association by name
myWorkflowAssoc = list.WorkflowAssociations.GetAssociationByName(wkId, System.Threading.Thread.CurrentThread.CurrentCulture);
 
if (myWorkflowAssoc != null)
 {   
     // using site2 to start the workflow is not enough, the listItem passed into the StartWorkflow
     // method has to have been instantiated using the web2 object
     site2.WorkflowManager.StartWorkflow(listItem, myWorkflowAssoc, myWorkflowAssoc.AssociationData, true);
}
 
site2.Close();
web2.Close();

The above code is a direct replacement of what’s currently in source on codeplex for the Start Another Workflow activity. This is just presented as an option to those not wanting to change their app pool configuration for whatever reason.