Thursday, December 08, 2011

SharePoint 2010 Lookup Columns & Projected Fields Limitations

SharePoint Lookup Columns and Projected fields are great way to build relationships between various lists.
However, there is a small limitation: You cannot lookup on Choice Columns, Lookups to other lists columns.
For e.g. I can establish a relationship to Title (Single Line of Text) Column, but not to Status (Choice) Column in my primary list.
On the Created Column UI, after you select the list, they are not listed in the dropdow to select the column (In this column:). They are also missing from the project fields check boxes (Add a column to show each of these additional fields:)
Quick Cheat Sheet: Created a Calculated Column in the Master List referring your original Choice Column.
SharePoint allows Calculated Columns to be used as Lookup Columns or Projected Fields in your Child List.

Thursday, November 24, 2011

SharePoint Content Export and Import – Importance of retaining GUID’s

We had to move some stuff from one environment to other.

There were number of Pages, Lists & Libraries, etc. The Pages has static content, custom and Out of Box Web Parts and whatever else you will normally have on a large SharePoint site.
There were 100+ pages, so it was not feasible to recreate them manually on destination environment.

We initially used SharePoint Granular Backups, available in Central Admin, to export from Source and then import using PowerShell into Destination environment. We restored the lists and then the pages library.

Post restoration, we had all the pages. Some of the pages worked as expected. However, webparts on some pages will not work as expected. For e.g. the Content Query Web Part (CQWP) will not display content and display a message that the query fired is not valid.

Guess, what was wrong? What were we missing?

The CQWP seems to internally keep a reference to the List GUID and not the List name. Same with few other web parts like the Image Slider Web Part.

To resolve, we exported using Content Management API and while importing, ensured that we retain the GUID’s. All the web parts are not working as expected.
We used Chris o'brien’s Sharepoint Content Deployment wizard  which is available on CodePlex for export and import. We however plan to replace it with PowerShell to automate the deployment process.

Note: You cannot import the list twice with same GUID to same content database. It will throw an error.
Key message of this blog: Important to retain GUID’s while exporting and importing lists and libraries if you have dependent pages/web parts internally referring them using GUID's

Monday, October 24, 2011

Enterprise Search market consolidation

Microsoft purchased FAST in Jan-April of 2008.
HP bought over Autonomy in Aug 2011.
And now Oracle buys Endeca in Oct 2011.

The Enterprise Search market is consolidating and getting serious, with big boys buying out the smaller players.
Will Microsoft, with FAST+SharePoint Search+Bing in its kitty, have an early mover advanatage over others in the Enterprise Search space?

Saturday, September 17, 2011

Installing PowerPivot for SharePoint on Denali

One of our enterprising team have installed SharePoint 2010 on Denali (SQL 2010) and things have been smooth so far.

While trying to install “PowerPivot for SharePoint” on the Server, we ran into the following error:

SharePoint version requirement for PowerPivot for SharePoint failed.

We were initially misled into thinking that it’s a Denali and not SharePoint issue. The Denali log files and Windows event viewer logs did not help.

To fix the error, you need to know the following:

·         BI Features are available only on SharePoint Enterprise edition. They are not available on SharePoint Standard edition.

·         How to check whether you are have Standard or Enterprise Edition installed. There is an option in Central Admin where this can be checked. Go to CAàUpgrade and Migration à Convert farm license type and it will display the current license type

·         A valid and genuine Enterprise License Key for SharePoint Server.

·         How to upgrade from Standard to Enterprise. You don’t need to re-install SharePoint. It can be upgraded by simply providing the key through the Central Admin.  If you run into issues, you may want to refer my previous blog post

As you have guessed by now, we were on Standard edition. We upgraded to Enterprise and then re-installed ‘PowerPivot for SharePoint’. Everything worked like a charm this time.

Thursday, July 28, 2011

Upgrading SharePoint from Standard CAL to Enterprise CAL

In Central Admin, first check your existing Farm license by clicking on ‘Convert Farm License Type’ under Upgrade and Migration.
It will display the Current License Type. It also has a text box for ‘Enter Product Key’. The textbox is always disabled on all the servers I have come across. It’s not what matters.
To upgrade from Standard to Enterprise CAL, go to Central Admin, click on ‘Upgrade on Migration’ in Left Navigation,  and then click ‘Enable Enterprise Features’. Enter the product key for Enterprise CAL, and then click OK.
You might see following errors:
·         “An error occurred while enabling Enterprise features. Refer to the event logs…”
·         “You do not have the appropriate permissions to use the SharePoint Products and Technologies Configuration Wizard.”
·         “The Execute method of job definition Microsoft.SharePoint.Portal.Administration.SkuUpgradeJob threw an exception”
It does not matter what account you have used to log in to Central Admin or remote into the machine. SharePoint uses Timer jobs to provision and enable the additional Enterprise features. You need to check the account under which your SharePoint Timer Job is running.
In my case, it was the SharePoint Farm account, but that did not seem to work.  I configured the Timer Job to run under the local machine admin account, and tried again. It worked like a charm. I have now reset the timer job to run under its original account. This was on a Single Server environment.  I haven’t tried on a multiple server farm, but I might add the Timer Job account to local Admin group on each machine in farm and then convert from Standard to Enterprise.
p.s.: In muli-server farm, do I need to make the account admin on each machine???

Wednesday, July 27, 2011

Workflow Errors on MOSS 2007

We have a MOSS 2007 Developer box. Actually it’s a training box and we give it to anyone wanting to learn and do some hands on for SharePoint 2007. With so many people using it and experimenting, shit happens and SharePoint on the machine is often broken. It’s not a Virtual Environment, and I cannot easily revert back to base configuration L
But I try to take it positively and tell myself “Fixing it is a good learning exercise” J
The Workflows on the machine were broken, and we were getting some errors in SPD. Below is a description of the errors and the resolution to fix it.
Error 1: On creating a new workflow using SharePoint Designer, it gave a popup message:
The list of workflow actions on the server references an assembly that does not exist. Some actions will not be available. The assembly strong name is ....
Obviously, the assembly did not exist in GAC. But I did not have the public key token to recreate it.
Check the following folder for custom .actions files:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\Workflow

By default, there should be only two files in the folder:
In my Training box, there were many additional .actions files like MySubStringActivity.actions.
I deleted all the custom files in the folder (after backup) and tried to create a new workflow again.
I still got the error. After some additional digging and semi-frustration, I did an IISReset. The error went away after the IISReset. SharePoint seems to cache them. Key is to do an IISReset after updating or deleting .actions file.
Error 2: After adding some valid steps in my workflow and clicking Finish, it gave the message:
“Errors were found when compiling the workflow. The workflow files were saved but cannot be run.”
I checked event logs, SharePoint logs, but nothing useful was being logged.
I opened my web.config, and Under <System.Workflow.ComponentModel.WorkflowCompiler>, <authorizedTypes> , noticed the following entry:
<authorizedType Assembly="Nintex.Workflow, Version=, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.*" TypeName="*" Authorized="True" />
We are not using Nintex in any of our current projects, but it’s a Training machine and someone must have tried it out. I am not saying Nintex breaks its. Its one of our developers, but we dont keep track of who does what on a Training box. I removed the authorizedType  Nintex.Workflow line, saved the web.config  and tried again.
I can now successfully create the workflows using SharePoint Designer. My Training box for MOSS 2007 is working again…for now.

Saturday, June 11, 2011

Never, Never Ever…Uninstall Office Web Apps from Your SharePoint 2010 Server

There are few things which you can do, have an UI for same, but should Never Ever do in SharePoint. One such thing is Uninstalling Office Web Apps from your SharePoint 2010 machine.
You can go to Add-Remove Programs, and Uninstall Office Web Apps. But uninstalling Office Web Apps will remove not only Office Web Apps, but also uninstall SharePoint 2010 and all traces of SharePoint in IIS from the machine. It will leave your databases intact, and if you are in Multiple Servers scenario and with Central Admin still available on another machine, no major harm is done. But if you are on a Single Box Development Farm, its all gone.  I am sure someone will come up with a way to recover since the config and content databases are present, but haven’t tried same.
Why you may want to un-install? Well, you may have deployed Office Web Apps only for POC purpose or realize that you do not have the license for same.  In my case, I was pushing content from one farm to another using content deployment. I had Office Web Apps on Source Staging Farm and not on Destination Farm. My content deployment job failed with a message informing Office web app related feature is not availalble on destination. I thought of disabling the feature, but did not find it in Site Collection Features or Site Features. Not sure if it was hidden or my oversight. I was anyways not using Office Web Apps on source farm, so though why not uninstall it.
It actually gives you a popup warning before it proceeds with Uninstall. Believe me, ignoring the popup and clicking Okay without reading the popup is the most stupid thing I have ever done in my life. Stupid, Stupid Me. No, it was not a customer environment, no data or jobs lost..but its going to cost me a lot (literally).
What’s the right thing to do? Disable the feature….don’t ever uninstall.
Powershell to Deactivate is available on Technet, and is as follows:
$webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname -eq "OfficeWebApps"}).Id
$singleSiteCollection = Get-SPSite -Identity http://<site_name>
Disable-SPFeature $webAppsFeatureId -Url $singleSiteCollection.URL
What's the most stupid thing you have ever done in SharePoint?

Tuesday, April 05, 2011

FBA in SharePoint 2010 - Access Denied

I was getting "Access Denied" after configuring FBA in SharePoint 2010. Configuring the Portal Super User and Super Reader resolved the issue.

"Users who submit valid credentials might be notified that they do not have permissions. If this occurs, the portalsuperuseraccount property and the portalsuperreaderaccount property of the Web application were probably configured prior to migration. If this is the case, you must update the portalsuperuseraccount property and the portalsuperreaderaccount property to use the new claims-based account name. After migration, you can find the new claims-based account name in the Web application policy for the migrated Web application"
$wa = Get-SPWebApplication -Identity "WebAppUrl"
$wa.Properties["portalsuperuseraccount"] = "domain\user"
$wa.Properties["portalsuperreaderaccount"] = "domain\user"

Update: Why we need to configure?

By default, the Portal Super User account is the site’s System Account, and the Portal Super Reader account is NT Authority\Local Service.

NT Authority\Local Service is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an “Access Denied” error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

Friday, February 25, 2011

Changes to SPD Workflow not reflected in MOSS 2007

On more than one occasion, I and my team have faced a problem where my updates to SPD workflow were not getting applied, and older version of workflow kept running. This usually occurred where the workflow had become large with multiple steps, and manually recreating each and every step would have been painful.

To resolve, we had to:
1.     Create new workflow on the same list
2.     Add dummy if condition to generate xoml.rules file in the new workflow
3.     Copy paste the steps and rules from existing workflow to new workflow by opening the files in notepad
4.     Publish new workflow, Disassociate the existing workflows and Associate the new workflow
5.     Post validation that things are working as expected, rename existing workflow to Workflow_Corrupted or Workflow_Old to clearly identify the same in future.

The solution is also described in another blog here, difference being my preference to rename instead of delete the existing workflow. 

Like Samar, what I really want to know is the root cause of what causes the workflow to get corrupted?

My colleague Rajdeep Chakraborthy suggests it’s a Caching issue. It’s a hosted server, and we don’t have access to server to do IIS reset and immediately validate. I am ruling out XML Well Formedness as we are copy pasting existing xml and it works. Wondering what else can cause the issue?

Rajdeep found a simpler solution. Detaach existing workflfow, do required changes, and attach it again to the list.
“Go to List Settings > Workflow settings > Remove a workflow > Select Remove option from the radio button and click OK. Then open the workflow again from SharePoint designer, make some changes and click Finish, so it is associated again.
Your changes should now appear”
The problem is likely to occur if there are running instances of previous version of the workflow. I did not have any pause/delay activity and ideally, all my workflows should have run to completion.

Thursday, February 24, 2011

MOSS 2007 Excel Services SoapException - You do not have permissions to open this file on Excel Services

We were programmatically trying to read an Excel file, uploaded to a SharePoint 2007 Document library, by making a Web Service call to Excel Services.
And the code was giving System.Web.Services.Protocols.SoapException error with message “You do not have permissions to open this file on Excel Services”.
We initially thought that it’s a permissions issue, the context under which code is running does not have access to the Excel file. To verify, we opened the file in browser using Excel Services View in Browser option, and the excel file was rendered correctly. Permissions issue was ruled out.
On closer look at code and debugging, the bug was found in the code. We were referring to the wrong Excel Services URL. The URL gets hardcoded when you add the Web Service Reference in Visual Studio.  The error can occur when you move from one Development machine to another and URL changes, or refer the Excel Service of SSP.
To resolve the error, simply update the Url of the ExcelService object.
ExcelService exlObj = new ExcelService();
exlObj.Url = oweb.Site.Url + "/_vti_bin/excelservice.asmx";
exlObj.Credentials = System.Net.CredentialCache.DefaultCredentials;
Status[] status;
string sessionId = exlObj.OpenWorkbook(filePathUrl,"en-US", "en-US", out status);