This weekend is SharePoint Saturday: Richmond, and I'm lucky enough to get to speak twice!  The first session will be an introductory topic on SharePoint 2010 Lists and Libraries, walking through a few examples and scenarios.  The second will be a discussion on the management of Large Lists in SharePoint 2010, with discussions of throttling, concepts on how to maintain those lists, as well as a couple demos.  It's gonna be a great time!  See y'all there! - M

Some folks may already be aware of this but I've been asked it a number of times lately so I wanted to put it up for the masses.

When accessing a list's RSS feed, the columns that are displayed in the feed are actually set in a different location than the view that you're working with.  From the settings of the list, look for the RSS Settings item under the Comunications section.  Clicking this will take you to the Modify RSS Settings page where you can select the columns to display in the feed.  Select the ones you want, and then *bam* they appear in your feeds.

Just a quick hit, relatively simple, but I had a few people ask me the same question on this recently.

Enjoy! - M

This was one that was wracking my brain, and then I came across a post that explains the issue and proposes a resolution.

In a nutshell, there's a hidden list at the top-level site of a site collection named Relationships List.  This list is an internal list that stores all of the metadata involved in the creation of Variations.  Apparently during the migration (in this case I was doing a Content DB migration/upgrade) this list wound up not migrating correctly, and it didn't have the necessary GroupGuid column.  The article says that you can download a tool from codeplex to perform the migration of this list, however, given where I was doing this work, external tools weren't an option.  So...

Enter PowerShell!

(I'm really liking PowerShell more and more...granted I'm a devhead at heart, but you're able to quickly address issues that occur in your implementation in a quick manner, with repeatable solutions)

So...how to do this?  Well, deleting/migrating the list wasn't really an option, and given that the field type of the column isn't available through the UI (it's a GUID, as well as being a hidden column), I turned to PowerShell to create it.  So...let's take a look...

Basically, I took a look at the list in a working site collection and grabbed its properties, and used it to create a working script to add the missing field to the site collection with the issues.  It's relatively smiple...grab your web, grab your list, create the field, add it, modify some properties, and you're good to go.  Running the script enabled the site collection that had the above error work right away.  So, take a peek at the below, and enjoy. - M

# load up SP PS Snappin            
Add-PSSnapin Microsoft.SharePoint.Powershell            
# get web            
$web = Get-SPWeb -Identity http://websiteUrl            
# get list            
# note that the code below isn't optimized            
# but just to get the list quick 'n' dirty            
$list = $web.Lists["Relationships List"]            
# create Guid SPFieldType field            
$guidField = [Microsoft.SharePoint.SPFieldType]::Guid            
# add the created field to the list, the name 'GroupGuid' is necessary            
# and it's required            
$list.Fields.Add("GroupGuid", $guidField, $true)            
# once added, let's grab it as a SPField            
$groupGuidField = $list.Fields.GetField("GroupGuid")            
# set its ShowInEditForm property to False            
$groupGuidField.ShowInEditForm = $false            
# add an index on this field            
$list.FieldIndexes.Add($groupGuidField)            
# cleanup            
$web.Dispose()            
# remove SP PS Snappin            
Remove-PSSnapin Microsoft.SharePoint.Powershell

I was pulling out my hair (figure of speech as I don't have any, ha!) trying to find information around this, and, as is the case pretty much all the time, the second I post a question to the SharePoint forums, I find it on my own.  So lesson learned: whenever you want to find something, ask the question to the masses, then you'll find it right after you ask the question.  Now, onto the "meat" of this post.

When SharePoint 2007 came out, there were a lot of folks that were using the Office Web Components in their SharePoint 2003 implementations, and they wanted to use them in '07.  There've been many an article written on how to do the installation in '07 (like this one here) that walked you through the steps necessary (as it's not just "install-and-go") and I was looking for information that stated whether this was supported or not for SharePoint 2010.

Lo-and-behold, buried in the Changes from Office SharePoint Server 2007 to SharePoint Server 2010 TechNet article, in the Features removed from SharePoint Server 2010 section, it's explicitly called out.  The excerpt related to OWC is below:

*****
Office Web Components
Description: SharePoint Server 2010 no longer supports Office Web Components (OWC). The PivotChart, PivotTable, and Trend Chart report types are no longer available as options in the SharePoint Dashboard Designer.
Reason for change: This is a 2007 Microsoft Office system feature that is now replaced by the features available in Excel Services in Microsoft SharePoint Server 2010 in SharePoint Server 2010.
Migration path: In SharePoint Server 2010, use Excel Services instead of Office Web Components.
*****

So, per the Microsoft documentation above, these components are *not* supported for SharePoint 2010 implementations.

Now, as these have been considered deprecated for a while, you've already started moving off these and onto Excel Services, right...?

- M

I was trying to figure out what to title this because the issue seems to effect a couple things.  If you've seen the following:

• Typing the [[ brackets in a wiki page result in a List Not Found message
• Navigating to a REST service (like http://sitename/_vti_bin/ListData.svc) results in an error that states Security settings for this service require Windows Authentication but it is not enabled for the IIS application that hosts this service

I started going down the path of our kerberos setup here, cause that's what we're using, and anything related to any sort of security error I look there first.  All the SPNs, account delegations and such were set up correctly.  What I did find tho' is that the Authentication Providers (inside IIS Manager) for the web application in question only had Negotiate:Kerberos in the Enabled Providers list.  This is available as a new feature in Windows Server 2008 R2.  Note that you can choose from Negotiate:Kerberos, Negotiate, or NTLM as enabled providers.  Here, we only wanted Kerberos without the fallback, so we just enabled Negotiate:Kerberos.

After doing some analysis, it looks like when you also select NTLM as an Enabled Provider, the calls to the REST services work.  Running a tool like Fiddler and examing the output right after typing the '[[' shows the NTLM traffic for that specific operation.  Regular browsing of the pages were showing Kerberos.

So, as it looks, in order for REST calls to work, NTLM must be one of the Enabled Providers in the Authentication properties of the web application.  I'm doing some additional searching to try and find some "official" supporting documentation, but as it stands, in order for those errors above to go away, adding NTLM did the trick.

Hopefully this one helps out some folks seeing this as an issue.

- M

Well lookie here, not only do we get SP1, Microsoft just released the June 2011 Cumulative Update.  In fact, they recommend to install both, as both contain important features and capabilities.  Note that the June CU contains fixes post-SP1, so the recommendation is SP1 first, then the CU.  Note that the Foundation "stuff" should be applied first, then the Server ones.  After that, run the Products Configuration Wizard on each box, and you're good to go.

Check out all the details here.

- M

Just announced, SP1 for SharePoint 2010 (Foundation and Server) has been released!  Aside from the requsite list of enhancements around performance, and the rollups of the existing Cumulative Updates, this one's the biggie:

• Adds backup and restore functionality to recover deleted site collections and webs

That's huge right there!  No more jumping through hoops to get back "accidentally" deleted sites!  That really is a huge item, IMHO.

Links to the respective download locations below:

• Description of SharePoint Foundation 2010 SP1
• Description of SharePoint Server 2010 SP1

- M

Announced on the TechNet blogs...SP1 for SharePoint is on track for release at the end of June...

http://blogs.technet.com/b/office_sustained_engineering/archive/2011/05/11/announcing-service-pack-1-for-office-2010-and-sharepoint-2010.aspx

- M

*** Update: 5/17/2011 ***

Now posted on the MS SharePoint Team Blog with additional explanation of what's in SP1...now with deleted Site/Site Collection restore capabilities through the Recycle Bin...woo hoo!!

We're going to have our first DevReady event for SharePoint on June 3rd.  These events facilitate getting back to the basics around development and the next one is focused on SharePoint.  This is a free event that all are allowed to attend, you just need to register.  Hit up the link here and come on out for a full day (well, 8:30am - 5:00pm ET)!

- M

The question was asked of how to delete all versions of a document in libraries in a site collection.  So, I wound up whipping up this script kinda quick.  It's nothing too crazy, but what I've been trying to do of late is to see how often I can write the script so that it'd work in both SharePoint 2007 and 2010.  Granted I do this cause I've been worknig on both versions of late, but I can see more and more leaning more towards the SharePoint 2010 cmdlets as 2010 is adopted more.  So, that being said...

What we have below is a script that instantiates a site collection, loops through all its webs, identifies the document libraries only, goes through each item, and deletes all of the versions of the item, leaving only the current version.  It's good to note here that since this is a document library we're dealing with you need to work with the SPFile object.  That's pretty much it, nothing crazy and it's not rocket science, right?  Again, as before, keep in mind that the disposal of the web and site objects are a necessity.

[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
# get site
$site = new-object Microsoft.SharePoint.SPSite("http://mossdev:8000")
# loop through webs
foreach ($web in $site.AllWebs)
{
  # loop through all lists in web
  foreach ($list in $web.Lists)
  {
    # examine if BaseType of list is NOT a Document Library
    if ($list.BaseType -ne "DocumentLibrary") 
    {
      # forget the rest and return to top
      continue
    }
    # loop through each item
    foreach ($item in $list.Items)
    {
      # work with the file object as we're in a document library
      $file = $item.File
      # delete all versions
      $file.Versions.DeleteAll()
    }
  }
}
$web.Dispose();
$site.Dispose();

Note: Take a look at Gary Lapointe's blog for all things (and I mean all) PowerShell.  Awesome reference out there.

Enjoy! - M