Tag: SharePoint 2010
Working with Correlation IDs in SP2010
One of the most useful (from an Admin’s perspective) improvements in SharePoint 2010 was the introduction of Correlation ID’s to assist with diagnosis of errors. Unfortunately a lot of people I’ve talked to don’t use them because they don’t understand how.
I recently came across this post from Tobias Zimmergren that does a superb job of showing you several quick and easy ways to make these little GUID’s work for you.
In short…
get-splogevent | ?{$_.Correlation -eq "<GUID>"} | select Area, Category, Level, EventID, Message | Format-List
…will return the detailed log chain relating to that ID, in a human readable format. Handy.
And this..
SELECT [RowCreatedTime], [ProcessName], [Area], [Category], EventID, [Message] FROM [WSS_UsageApplication].[dbo].[ULSTraceLog] WHERE CorrelationId='<GUID>'
…in a SQL query will return much the same detail. I particularly like the suggestion of inserting this in a data-query web-part in Central Admin web-part. Super handy.
PDF Security in SharePoint 2010
Here’s a handy nugget of information I picked up at NZSPC2011.
Out of the box, SP2010 will force you to save PDFs from SharePoint, not open them. This is to prevent XSS which is pretty easy to do in PDFs. Good solid security principal that one – I like it.
For most users however, this comes as a jarring change to what they’re 
used to, so queue complaints from users, and an SP Admin looking for a quick fix. Google will quickly point you at hundreds of suggestions to change the Browser File Handling setting from Strict to Permissive (set per web-application, under General Settings).
This is a purely evil approach, as it immediately relaxes file handling security for ALL file types, not just PDF.
The better way of doing this, is setting an ‘Inline Download’ exclusion just for PDF files. There’s a good post at pdfsharepoint.com by Dmitry that covers this in detail, but here’s the important bit..
Via PowerShell, run the following script to create a MIME type exclusion for PDF files in your web application. The only value you need to change here is the http://webapp.domain bit – set it to your web application hostname.
$webApp = Get-SPWebApplication http://webapp.domain
If ($webApp.AllowedInlineDownloadedMimeTypes -notcontains "application/pdf")
{
Write-Host -ForegroundColor White "Adding Pdf MIME Type..."
$webApp.AllowedInlineDownloadedMimeTypes.Add("application/pdf")
$webApp.Update()
Write-Host -ForegroundColor White "Added and saved."
} Else {
Write-Host -ForegroundColor White "Pdf MIME type is already added."
}
Removing server from SharePoint farm
It might sound obvious, but it is often the little things that catch out even the best of us at times.
If you’re in a situation where you need to remove a server from a SharePoint farm, then re-join it to the farm again (perhaps to resolve some sort of local corruption of the site config), make sure you manually check that all remnants of SharePoint farm membership are removed before you try adding it again. Normally SharePoint keeps a fairly tidy house and cleans up after itself well – but occassionally it leaves something behind, and this can wreak havoc on your environment if not picked up. Depending on which server role you’re dealing with in the farm, this could mean websites and/or application pools in IIS, databases, web application folders on the filesystem, or a bunch of other things.
This tripped up a colleague of mine recently – in this particular case the Security Token Service was for some reason not removed when the server was removed from the farm. When the server was re-joined to the farm, there were no errors, or issues that suggested there was a problem, but things started falling apart shortly afterwards.
How we located the issue was that the search functionality within a SharePoint site on the farm started returning those lovely generic SharePoint errors, and digging through the logs we found that old chestnut “Object reference not set to an instance of an object”.
Removing the server from the farm again, manually removing STS from IIS (including its application pool), then re-adding the server to the farm solved the problem immediately. Presumably there was some GUID under the hood that binds the STS to the farm, and as a result of the remove/join this GUID got out of sync with reality.
On The Socials
SharePoint column lookup and calculation limitations
June 5, 2011
2010, BPOS, Cloud Services, Office 365, SharePoint, SharePoint 2007, SharePoint Online
7 Comments
gingerninjanz
List lookup columns in SharePoint are great. Easy to setup, simple to use, and powerful. But they have some limitations that can be frustrating.
Let me paint you a picture..
You have a SharePoint list that contains information about a customer entity (yes it should probably be in CRM, but lets assume you don’t have one) – fields like contact names/numbers, addresses, unique systems, notes, etc. Some of these fields are single lines of text, pull-down menus, yes/no radio buttons, multiple lines of text, you name it.
You have another list that relates to sales of products to customers. Unsurprisingly, you want to link a sale to a customer, and you want to leverage the power of lookup columns to make that a simple and seamless process.
Not an unrealistic scenario. Sure there are better ways of doing it with the likes of webservices into CRM or BCS connections into LOB databases, but they all involve additional systems, coding skills, and generally more effort. All things that aren’t always readily available.
By adding a lookup column type to the sales list you can allow a customer entity to be selected from your customer list. Where this gets handier is you can have the sales list pull other values from the customer list without adding extra columns. Awesome.
But… not all the columns from your customer list are available. Why not?
SharePoint can only perform a lookup of values from columns that contain a ‘text’ value, and then only if it contains a single line of normal text (ie. “Single line of text”, a “number”, or “date”). Any field that contains multiple lines of text, other lookups, or multi-select items won’t be available to you, as SharePoint will automatically hide any columns that it knows it can’t return.
This same restriction applies to using these column types in calculated columns, and there is a great post by Dessie Lunsford on getting around this limitation in terms of calculated columns which you’ll find here – http://www.endusersharepoint.com/2009/06/17/taming-the-elusive-%E2%80%9Ccalculated-column%E2%80%9D-referencing-multiple-lines-of-text-column/
The workaround involves creating your problem field as a “single line of text” column, then creating a second calculated column that references the first column name – eg. [=ColumnName]. You then delete the first column and recreate it with the exact same name but this time selecting your column type of choice.
While Dessie’s post deals specifically with referencing these columns via calculated fields, by dint of good fortune and SharePoint consistency, the same workaround fixes the lookup problem as well. Thanks Dessie!
This issue applies to all versions of SharePoint since 2007, including SharePoint Online (BPOS/Office365)
SharePoint 2010TipsWorkarounds