February 2012 - Posts

I was working with a client recently who had purchased Metalogix Migration Manager for SharePoint and I came across an issue that confused me for a minute.  I installed the Metalogix SharePoint Extensions Web Services on a few farms.  However, in the middle of this process a new version of the tool came out and I didn’t realize that some of the farms were running one version while the other farms were running a new version.  I could connect to one farm just fine.  However, when trying to connecting to the other farm (that had the newer version), I received a 404 error. 

In my round of troubleshooting, I tried reinstalling and redeploying the solution package but to no avail.  It wasn’t until I dug deep into the documentation that I realized that the version number was included in the path to the web service itself.  It was then I realized that the version number of all web service extensions as well as the Migration Manager itself all have to be the same.  If you are using this tool and run into a 404 error, be sure and check those version numbers.

Note: By writing this, I am not endorsing one particular SharePoint migration product over another.  I work with all of them.  It’s simply the tool being used on this migration.  That means I don’t need any of Metalogix’s competitors calling or E-mailing me this afternoon.  That means you Axceler and AvePoint. :)

I’m excited to be speaking at the first Office 365 Saturday in Redmond on 2/25.  This new event will be an exciting display of all things Office 365.  I’ll be talking about all of the cool things you can do with Search in SharePoint Online.  I gave this talk at SPC11, but I gave the talk an upgrade with the use of Visual Studio 11 Developer Preview.  We’ll look at what you can do out-of-the-box with search and then write a custom Silverlight application to query search web services.  If you’re looking to get more out of search be sure to stop by and check out my session.

For those of you familiar with SharePoint 2010, the content type hub is nothing new to you.  However, in SharePoint Online, the content type hub works a little differently.  The first thing to know is that a content type hub has been set up automatically for you.  You just have to know where to find it.  You can’t get to it from Tenant Administration like you might expect.  Instead, you can find the location by going to the Site Settings page of any site collection and then the Content Type Publishing link.  You will see a screen like the one below which links directly to the content types of a site collection containing your hub.


From here you will learn that your content type hub is located in a site collection named /sites/contentTypeHub.  Clicking on the link from this page will allow you to view the content types in the hub.  One issue I have noticed here though is that only the original Office 365 account creator has access to the site collection.  Accessing it with another user will get you an access denied error message even if you are a global administrator.


Unfortunately, you cannot fix this yourself from the tenant administration page because this site collection does not show up on the list.  This means you need to get the person who created the original Office 365 account to go to this site collection and add you as a site collection administrator.  It’s easy to fix but it requires you to involve whomever set up the account to begin with.

Once you get into the content type hub, you can create and publish your desired content types just like you would in SharePoint 2010.  When you publish a content type, you should see it in the other site collections within a few minutes.


Working with the content type hub is easy.  Try it out with your account today.  These examples were demonstrated with an E3 account.

During configuration of FAST Search for SharePoint, you will need to use PowerShell to finalize your configuration.  One common error you might receive is the one below.  This error occurs when you execute any PowerShell command for FS4SP.

Failed to communicate with the WCF service.


This error can occur for a number of reason such as the FAST service is unavailable or the services aren’t started.  However, a really common cause is due to lack of permissions.  In this case, I executed the script with another administrative account I had.  It would be nice if the error just said “access denied” or something like that.  To correct this, you have two options.   You can either use the Run as different user menu item and use the FAST user account specified during configuration when running the FAST Search Server 2010 for SharePoint management shell.  Your other option is to add the account in question to the FASTSearchAdministrators local security group on your FAST Search for SharePoint servers.  Here’s an example of how mine is set up.


After you add the user to this group, you will likely have to reboot for it to take effect.  Once you do, run PowerShell again and try your command.  If all works successfully, the command should work.


Hopefully this works for you.

A lot of times we have a need to activate a feature on multiple site collections.  This could be a custom feature to do branding or you may simply be activating publishing on multiple site collections.  PowerShell makes tasks like these easy.  We’ll take what we learned from my original Activating Features with PowerShell post and use some common techniques to iterate through the site collections and activate the desired feature. 

For this example, we’ll activate the SharePoint Server Publishing Infrastructure.  The internal name of that feature is actually PublishingSite so we’ll start by using PowerShell to get a reference to that feature.  We’ll assign the result of that value to a variable.

$feature = Get-SPFeature PublishingSite

If this is your first time working with this feature, be sure and test it by typing it into PowerShell to ensure that you are getting the reference to the feature correctly.  Once you have the feature we can get a list of site collections.  Retrieving site collections is simple.

$siteCollections = Get-SPSite

However, this will return every site collection from every web application.  You probably want to limit it to a single web application using the –WebApplication parameter like this:

$siteCollections = Get-SPSite –WebApplication http://sp2010

We can then just use ForEach-Object to iterate through each site collection and then activate the feature.  I use a pipe bind with the $siteCollections variable.  Then I just use the Enable-SPFeature command passing it $feature for the feature and the Url to the site collection which we can get from the Url property of the $_ object.  I also wrote some output to the screen so we could see which site collection was activating.  Here is what the whole script looks like.

$feature = Get-SPFeature PublishingSite
$siteCollections = Get-SPSite –WebApplication
$siteCollections | foreach-object {
   Write-Host "Activating" $feature.DisplayName "on" $_.Url
   Enable-SPFeature $feature -Url $_.Url


Of course this works with deactivation as well too.  I just updated the script to use Disable-SPFeature instead.

$feature = Get-SPFeature PublishingSite
$siteCollections = Get-SPSite –WebApplication http://sp2010
$siteCollections | foreach-object {
   Write-Host "Deactivating" $feature.DisplayName "on" $_.Url
   Disable-SPFeature $feature -Url $_.Url -confirm:$false


Note that I added –confrim:$false to the Disable-SPFeature line to prevent being prompted by the script.

This is a simple script that makes it easy to activate and deactivate features in bulk.  This same logic could be applied to site scoped features as well if you had the need.

I’ve written a number of posts in the last couple of weeks about the new SharePoint features in the Visual Studio 11 developer preview.  These posts include publishing to SharePoint Online, Visual Web Parts, Silverlight Web Part, and the Content Type Editor.  I’ll wrap up this series with a look at the new list editor.  The list editor looks fairly similar to the content type editor actually.  You start by choosing the List SharePoint Project Item from the New Item menu.


Selecting the List SPI will take you to the next screen where you have the choice of creating a new list which is based off of an existing list (i.e. tasks or document library) or to create a new instance of an existing list type.


Once it is complete, you will see the list editor where you can edit site columns and content types.  The site column editor works very similar to the one used for new content types.


The only difference in this interface is that you can actually create new list columns here.  If you click the Content Types button at the bottom, you will see a window allowing you to select content types from those available on the server as well as in your current project.


After you have set your content type, the site columns of the content type will automatically be added to the site column list.  From here, you can click on the Views tab to edit the existing views (or add a new one).  You’ll notice that all views are visible (including ones you normally wouldn’t touch).  Be careful with what you do here.  You can customize the columns in each view.  Unfortunately, the user interface doesn’t give you any control over how things look, row groupings, or sort order though.


Finally, the Common Properties tab lets you set the title, URL, description, whether the list is hidden or not and on the Quick Launch bar.


Once you have finished your list, you can deploy it to a local SharePoint server or publish it to SharePoint Online.  When you visit the site, an instance of the list will be there ready to go.


That’s just a quick look at what you can do with Visual Studio 11 Developer Preview.  If you haven’t checked it out yet be sure and visit the developer center on MSDN.

Visual Studio 11 introduces a new content type editor that you might find useful when building your next content type.  It starts with a SharePoint Project Item that you can pick from the New Item menu.


From this screen, give your new content type a name and then you’ll be presented with this next screen allowing you to pick a content type to inherit from.  This pulls a list of every content type currently on the site collection that you have your Visual Studio project associated with.


Pick the content type you want to inherit from and you will then see the new content type editor.


From here you can begin adding exiting site columns to your new content type.


Selecting one will bring over the type automatically.  Unfortunately the only option you get here is whether the column is required or not.  However, you can click on the elements.xml file in the solution explorer to edit the XML directly.  I’ve tested and it will preserve any additional attributes you add to your site column references there.


You might be wondering what about site columns that have not been created yet.  The editor is actually smart and knows to look at any site columns defined in the same project as well.  For example, I created this new site column below.


Unfortunately, creating site columns still requires XML, but Visual Studio at least gets you started.  After you save your new site column, you will find the site column in the list.


You can also set some of the common properties such as the group and description of the content type itself by clicking on Common Properties


What about inheriting from your own content type in the same project?  That actually works as well.  However, you will have to look for it at the top of the content type list.


That’s a quick look at what Visual Studio offers for content type editing.  I think the SharePoint Designer still has a few more features, but the main difference is what you create here can actually be deployed elsewhere.  This will work with SharePoint Online as well.  Just use the new publish feature I have talked about earlier.

For more information on Visual Studio 11, go to the Developer Preview site.