Archives / 2011 / June
  • Service Pack 1 for SharePoint 2010 is here

    Tags: SharePoint 2010

    SharePoint 2010About a year has passed since SharePoint 2010 RTM:ed and now the first Service Pack is released, Service Pack 1. A Service Pack is always a big deal for SharePoint. Service Packs contains all the previous cumulative updates and in most cases some new features. SP1 for SharePoint 2010 is all that.

    Before diving into some of the new stuff I want to raise a finger of warning. Plan and test your SP1 upgrade thoroughly! Even though Service Packs are tested more than CU's they are not tested in your environment and with your customizations. Read more on this topic.

    Update 1: Also read this known issues KB article before proceeding.

    Update 2: It is (by Microsoft) strongly recommended to immediately after patching with SP1 to apply the June 2011 Cumulative Update.

    Update 3: June CU has been re-released to fix some imminent issues. Read more by Stefan Gossner.

    Cumulative Updates in SP1

    Service Pack 1 for SharePoint 2010 contains all the Cumulative Updates up to the April 2011 CU. This means that you do not need to install any of the CU's prior to the SP1 or if you have already installed one or more of them you can just apply SP1. Depending on what CU level you are on your upgrade may take more or less time and require more or less testing (but there's nothing like "less testing"!). For instance if you're still on SP2010 RTM you really need to test your upgrade - so much has happened for the last 12 months.

    Other fixes

    Part from the CU's the Service Pack contains other fixes that improves the overall experience, performance, reliability etc. Some of these fixes have previously been released as hotfixes and some of them are new to the Service Pack.

    New features

    The new features is what most of us are looking for in Service Packs and this SP1 really comes with some nice enhancements. I'll briefly explain them here and give you my take on it (you'll see a gazillion other posts with more details).

    • Support for SQL Server codename "Denali": This is really cool and my favorite enhancement. SP1 introduces support for SQL Server "Denali". Denali will introduce some kick-ass BI/Insights features with "Crescent" that really will stir up the BI market and the new "AlwaysOn" HA/DR features will make your SQL Server more stable and reliable for less money! Did I mention Windows Core support!!!
    • Site Recycle Bin: This is one of the most awaited new features ever in SharePoint. Finally a solution that allows you and your admins to restore whole Site Collections without reverting to backups or custom solutions. The Site Recycle bin also has a set of PowerShell commands; Get-SPDeletedSite, Restore-SPDeletedSite and Remove-SPDeletedSite.
    • StorMan.aspx: A small but welcome new/old feature. The Storage Space Allocation page is back.
    • Shallow copy: This feature should not be a big deal since it is aimed for RBS - and you should not use that unless it's necessary. But if you do, then Shallow copy makes it easier and more reliable to move Site Collections using RBS.
    • Browser support: Yes, SP1 introduces IE9 support (in IE8 standards mode) and Chrome is now supported in SP2010 (not only in Office Web Apps). Native IE9 support in Office Web Apps (updated)
    • Office Web Apps: a whole bunch of new stuff such as charts in Excel, printing support, ODF support. Clip art support for PowerPoint (admin enables/disabled).  (updated)

    Summary and download!

    I just can't wait to get back to my customers and start the planning and testing for SP1. I know they will love the new features. So where do I get it then? Now! Just head on over to the SharePoint 2010 Updates portal on TechNet: or the Office Update Center: or if you want to get it right now then these are the places:

    Have a nice summer!

  • Give your SharePoint 2010 custom Application Proxy Groups pretty names

    Tags: SharePoint 2010

    SharePoint 2010 allows you to configure your Service Application in Application Proxy Groups. By default all Service Applications ends up in the Default Proxy Group, named default. This Proxy Group is used by all Web Applications unless otherwise specified. Sometimes there is need to create specific Proxy Groups for different Web Applications, the reasons may vary but often it is a result of having different service offerings. For instance you would like to have different Managed Metadata Service Applications for different Web Applications.

    Service ConnectionsCustom Proxy Groups can be created in the user interface (Central Administration) and is automatically created once you customize the Service Connections for a Web Application. To create a Custom Proxy group for a Web Applications you go to Central Administration and select the Web Application you would like to configure and then choose Service Connections in the Ribbon. A modal dialog window with all available Service Applications appear, this dialog contains a drop down in the top where you choose Proxy Group. This drop down contains two values by default; default and [custom]. To create a custom Proxy Group for the Web Application you just select the [custom] option and then select the service applications to use.

    No pretty names

    When you start to create a number of custom Proxy Groups it might be hard to differentiate them from each other. The name [custom] doesn't mean anything, but that it's custom.

    Instead I prefer to name these custom Proxy Groups into something meaningful. Unfortunately you cannot create named Proxy Groups in the user interface and have to revert to PowerShell. But it's a really simple PowerShell cmdlet to do this:

    New-SPServiceApplicationProxyGroup -Name "Extranet Service Group"

    This simple command creates a named custom Application Proxy Group, in this case Extranet Service Group. Now when configuring Service Applications for a Web Application this new Proxy Group will appear in the drop down:

    Man, this is pretty!

    A far better alternative, don't you agree?

  • You cannot create property based search scopes in Office 365 (SharePoint Online)

    Tags: SharePoint 2010, Office 365

    Post is updated, see comments at the end of the post.

    We're really getting close to the go live of Office 365 and I am, and I guess a lot of you are as well, preparing to launch a couple of Intranets and sites. As you know by now there are some major differences between SharePoint 2010 on-premise and SharePoint Online in Office 365. And there are also some more subtle ones that jumps up right in your face.

    Today we were designing a topology for an intranet and we thought that we could use Search Scopes to search and aggregate data. Site Collection Search Scopes are available in SharePoint Online, but you cannot access the Search Service Application and create global Search Scopes. That's fine, we're in a megamulti-tenant environment here. Search Scopes are very convenient to use when you would like to do a search for a specific type of documents or information since you can create Property Query based Search Scopes. This is how it looks like in a standard on-premise SharePoint 2010:

    On Premise Search Scope

    So I tried to do the same thing in Office 365! And found out that a Property Query is not possible to create. You can only create Search Scopes based on the Web Address/URL! Sigh! I can't really see why this is disabled (see update below). Yes, I understand that they won't let us create Managed Properties, but this is to sneaky!

    Cloud Search Scope

    So back to the drawing board for me!


    After some discussions on Twitter with SharePoint Master2 Mirjam van Olst the actual answer wasn't that far. She led me to the SharePoint Server 2010 capacity management: Software boundaries and limits document on TechNet (which I read a gazillion times lately when studying for the MCM). This document clearly states that the Threshold is "200 site scopes and 200 shared scopes per search service application" and "Exceeding this limit may reduce crawl efficiency and, if the scopes are added to the display group, affect end-user browser latency. Also, display of the scopes in the search administration interface degrades as the number of scopes passes the recommended limit.". This of course does not work in a multi-tenant environment. Notice that it's only a threshold.

    But! Why can we create URL based scopes? To find out I created two different scopes in an on-premise box and took a peek on the SSA admin database (I only looked, no hands!). All scopes global or site collection scoped are stored in the SSA admin database and compiled every 15 minutes. Both property query rules and URL rules are treated the same. That lead me to the lovely SharePoint protocol specifications, and specifically the MS-CIFO which describes the index files. This document describes how the scopes are handled in the index, using the Scope Index File format (.bsi files). My interpretation of the specs are that these files in the index are used when querying using a specific scope and therefore affecting the crawling since they are index files and behaves just like any index with merges etc. I didn't go any further...

    I still cannot tell for sure why URL rules are allowed, but my best guess is that they do not affect performance in the same way as property based rules are. So in Office 365 URL rules can be used. Also, since URL based rules are not that useful they will not be used as much anyways...

    /end update

    (Notice that I didn't mention "cloud" anywhere...dang, I just did...)

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...