Getting the most out of SharePoint Search — SPTechCon Boston 2012

Thank you to everyone who came out to my session!  Here’s a link to the latest slides as promised!

Sample Branding Deployment for TechEd Session

In my session at TechEd called “Exploring the Power of Page Layouts in SharePoint 2010 WCM Sites” that I co-presented with Randy Drisgill I touched on the subject of deployment.  The topic itself is one that can get very complex quickly so I thought it’d be best to start with sharing an example of a simple branding deployment that includes page layouts.  The download includes a Visual Studio solution that deploys a Sandbox WSP (so you’ll need to make sure to check in and publish the masterpage, page layouts, css, images, etc).  But it should serve as a good reference:

Here’s some of the other references that I mentioned in my slides:

Creating a Page Layout in SharePoint 2010 using Visual Studio 2010 by Becky Bertram [SharePoint MVP] —

Packaging master pages and page layouts —

CKS:Dev Extensions —


Rackspace and me

You’ve probably heard by now, but SharePoint911 was acquired by Rackspace (  Some folks have been sending me various messages asking “Congrats! Is this a good thing?”  I thought it’d be good to take to the blogosphere to share my thoughts on this.

The week after Christmas our fearless leader, Shane Young, called a very mysterious meeting on Friday at noon.  We have meetings all the time, but the phrasing and wording of this meeting request made us all a bit nervous and I probably got IMs from everyone on the team with various theories.  But the news came down then that Rackspace wanted to buy us.  Everyone had a million questions and I can’t actually remember most of that meeting — all I remember is that we needed to all book flights immediately to head out to San Antonio to head to Rackspace the following week.

I’ll spare you all the nitty gritty details, but the next week or so was one of the most stressful of my life.  Initially I was very excited about the news but there were so many open questions.  The whole SharePoint911 crew came down The Castle (Rackspace’s home office which is a renovated old mall) on January 4th and 5th.  I was completely blown away from the sheer coolness factor of their offices — they have a slide! But slides alone aren’t enough to give warm and fuzzies.  During our time there we had a chance to meet upper management and the rest of the SharePoint team as well as a cast of characters from across the organization.  One of the best parts about working for a small company is that “start up” feeling and at SharePoint911 we always worked hard and tried to have a lot of fun doing that.  Walking around the Rackspace offices, they’ve figured out a way to keep that same “start up” feel in a company with more than 4,000 people.

Last Friday as we were doing final preparations for today’s annoucement, I mentioned that we might want to move our website out of our current “datacenter” over to some servers at Rackspace.  I think the whole process of creating the servers started at about 4pm EST.  Somewhere in the middle I went to dinner with my wife, then came back and had everything moved over to Rackspace by about 11pm EST.  It was the first time the teams from SharePoint911 and Rackspace had worked together on something like this and it was pretty awesome to see what we were able to do in such a short amount of time.  For me, that was a little glimpse into what the future holds and I’m excited.

I left my last job more than 4 years ago to go to work with Shane and Nicola Young at this company called SharePoint911 that they ran out of their house.  I’ll never forget when I told my wife this guy wanted to hire me that had never even met me.  We were pretty sure it was some type of scam.  But Shane and Nicola both came down to Orlando and went out to lunch with my wife and me.  I decided to make the jump to go work for SharePoint911 and I’m sure some folks thought I was a bit crazy.  At the time, the idea that one day we’d be acquired by a company like Rackspace wasn’t even close to something I thought was ever possible.

I’m so proud to work with such great people at SharePoint911 and excited to join the team at Rackspace.


Presentations from SharePoint Saturday: The Conference DC

I just got back from SharePoint Saturday: The Conference (SPSTC) in DC.  What a great time! I got to a number of events throughout the year and really have to say I had more fun at SPSTC than I’ve had in a long time.  Kudos to the organizers and volunteers on a great event!

It was great get to talk with so many of the attendees and see others in the community that I don’t often get to see!  Not to mention the location in the DC area was awesome.

For those of you that were able to come out to my sessions, thank you for coming out!  A special shout out to everyone at my search session for helping me get the room set up.  I apologize for being a little late making the slide decks available, but here they are.

Hope to see everyone again at SharePoint Conference in Anaheim!

Using tabs in the Enterprise Search Center in SharePoint Server 2010

When I give search presentations, one of the demos I always do is about showing users how to do some quick and easy customizations to the Enterprise Search Center to improve the search experience a little better. 

Just a quick note before we get into things too deeply. This blog post is specifically for users with SharePoint Server 2010 or Search Server Express 2010.  If you happen to have FAST Search for SharePoint (FS4SP) the process for creating scopes will be different, but the same concepts would apply.  In fact, you’ll be able to create scopes if you FS4SP the way I describe but you might get incorrect results. 

For more information on creating scopes with FS4SP check out these great blog posts:


Just about every organization has a need for scopes.  If you aren’t familiar with what a search scope is, you can think of it this way: All of the content that has been crawled by SharePoint is tossed into an index – like the index of a book.  But the issue is, that sometimes you might just one to look at a small piece of that content.  Maybe just content from a specific department, or all content tagged with a specific piece of metadata (maybe you wanted to only search within documents that were tagged as “proposals”).  A scope is what makes this possible.

One thing I suggest in my session, is that you could move old content to an archive location.  This could be a specific site, separate site collection or web application, or even a metadata flag on the content itself.  Either way, the goal is the same – get the older information out of your active search results.  But sometimes, users want to search the archives.

    In this example, I’ll walk you through the steps about how to create a scope and set up the Enterprise Search Center with a separate tab your users can use to specifically search the archive.

    1. For this demo I’m using an Enterprise Wiki as my starting point.  If you are using a different template, your steps might be slightly different.  But for the first step, you’ll want to create an Enterprise Search Center if you don’t already have one.  To do this, you’d simply need to click Site Actions > New Site then click on the Enterprise Search Center.  Give the site a title and URL and hit the Create button.

    2. The next step is to create a scope.  You’ll need to make sure you have Site Collection Administrator permissions.  Click on Site Actions > Site Settings and then from under the Site Collection Administration section click on Search Scopes.

      3. From the Toolbar click the New Scope button.

      The create scope page will open, for the purposes of this demo you can simply fill in a Title for the scope and then hit OK.

      4. This will take you back to the View Scopes page.  You should see your newly created scope listed here, but you’ll notice that under the Update Status column it will say “Empty – Add rules.”  To add rules, click on the Add Rules link.

      5. On the Add Scope Rule page, at the top you’ll see you’ve got 3 options for scopes: Web Address, Property Query, and All Content.  In this example we’ll use the Web Address option.  However, the Property Query option is useful if you wanted to create a scope based on specific metadata values.

      For the folder value, I’m just going to use one of my existing document libraries. So I’m going to cut and paste the URL into this field and remove the /Forms/AllItems.aspx part of the URL since it isn’t needed.

      Then for the behavior section at the bottom, I’m going to leave Include selected and hit the OK button.


      6. You’ll notice that when the View Scopes page loads that your new scope will likely need some time before it gets populated.  In my case, it’ll be another 6 minutes.  I With many other search related activities there’s a bit of waiting involved.  I usually take this time to catch up on my web surfing Smile


      7. Once your scope has been created, it is time to head over to the Enterprise Search Center you created in the first step.  Specifically, the results page.  In my case the URL is:

      It is okay if the page throws an error if there are no results.  But if it would make you feel better, you can always execute a query.

      8. Put the page into edit mode by clicking Site Actions > Edit Page.

      At the top of the page click the Add New Tab link:


      9. On the tab page, be sure to give it a Tab Name and enter a value for the Page.  In this case, it is important to remember that when you enter the page name you need to include the full name of the page.  In my case, it was archive.aspx.  Then hit the Save button.


      10. You’ll notice that the new tab has been created, but if you click on it you’ll get an error.  Don’t worry.  All we need to do is just create the page.  And to do that click on Site Actions > New Page.  Then press the Create button.  In this case, we’ll call the page ‘Archive’ – no need for the .aspx.  I know it isn’t consistent.  Don’t blame me – I just write blog posts.


      11. Once the new page has been created, there’s a couple quick modifications we’ll need to make to a couple of the web parts.  First, modify the Search Box web part by clicking the Edit Web Part.  When the web part properties menu opens, expand the Miscellaneous section and edit the Target search results page URL to point to itself.  The goal here is that when someone does a search from this tab, we want to make sure it doesn’t redirect them to another page.  Once complete scroll down to the button and press OK.


      12. Next, edit the Search Core Results web part.  Expand the Location Properties section and enter the name of the scope you created earlier. This will make sure that the results displayed in this web part are restricted to the scope we created.  Press OK when you are done.


      Then all you’ve got to do is Check in your page and give it a test. Just remember to publish the page if you want to enabled all users to see this.  You can run a query against the All Sites scope and you should get back a big number, and then you click over to the new tab you’ll be only getting results back from your new scope – which should yield far fewer results.

      Happy Searching!

      Quick Tips for Improving Search in SharePoint 2010

      Many organizations implement SharePoint for a number of different reasons including collaboration, content management, business intelligence, process improvement, and many others. These are areas where organizations are leveraging the vast capabilities of SharePoint 2010 to allow their users to work smarter and not harder.

      But one area that many organizations seem to forget about is the powerful enterprise search capabilities that are available out of the box with SharePoint 2010. Search tends to be one of those areas with SharePoint that “just works,” so what usually happens in an organization is that the farm gets setup and search gets configured — results come back and it is assumed that everything must be working. Right? This approach is very common which is why when I go to work with different companies I often hear the same story about how “Search is broken” or “search sucks.” But the fact of the matter is that in order to work to its full potential, search can’t be entirely an afterthought. However, getting better results from search doesn’t require a lot of effort.

      Before we can get into any search discussion we’ve got to start with the key measuring stick for determining whether any search engine works — relevancy. Relevancy is just another way of saying “did you find what you were looking for?” Users who have negative things to say usually aren’t finding what they are looking for and therefore have an issue with relevancy. The following are a few quick and easy ways to improve relevancy across your organization with very little effort.

      Put more important documents near the root of the site, less important documents farther down the hierarchy – They say the cream always rises to the top, and with search the same is true. There are many factors that work together to determine the relevancy of a document but one rule of thumb is that the deeper the document is buried in your hierarchy the less relevant SharePoint is going to assume the document is in comparison to a similar document closer to the root. As a rule of thumb, the less “/” in a URL to a piece of content the more relevant it is. For example a document at http://sales/sharepoint-presentation.docx would be considered more relevant that http://sales/products/sharepoint-presentation.docx.

      Just remember that you can use this to your advantage. Less important documents and sites can be nested deeper in your hierarchy and more important ones can be closer to the top.

      Use natural language for site and file names – Among the easiest and most effective things people can do to improve search relevancy is to name their sites and files effectively. Look at these two URLs:

    1. http://sales/north-america/presentations/april-2011-widgets.docx
    2. http://slsna/p_wdgts411.docx
    3. The first document has a URL which has actual words used for the sites and document where the second one has some shorthand for the sites and document names. The first one is far more effective because the URL and file names for a document in SharePoint are a heavily weighted component of the relevancy algorithm. If you were to type a search query of “sales presentations widgets” SharePoint would be able to determine clearly that the first document was relevant to the query. Although the second document might have some of those words typed somewhere in the content, and would likely still show up somewhere in the results — the first one will be considered more relevant simply because of the way it is named.

      It should also be noted that in order for this to work as effectively as possible it is important to NOT run your words together. This is because SharePoint doesn’t know where words break unless you’ve got something between them that it identifies as a “wordbreaker.” Although spaces are recognized as a word breaker in SharePoint, my recommendation is to use “-“ between words instead. The main reason for this is because if you use spaces in things like site or page names when SharePoint will automatically remove them and you’ll lose out on the relevancy benefit you’d get otherwise. Other common word breakers that get used are things like underscores (_), periods, semi-colons. If you happen to be using these, they are also all valid word breakers.

      Supply metadata for your files — If you aren’t familiar with the term metadata it basically means “data about data.” If you were talking about a car some common pieces of metadata would be make, model, color, mileage — think about the types of things you’d use to find a car on a web site. All of those pieces of data describe the car; they are its metadata.

      For your files in SharePoint, by tagging them with descriptive metadata you can make it easier for your users to find what they are looking for. Remember, that metadata is always going to carry a heavier relevancy weight than content in the body of a document.

      How much metadata do you need? Generally I recommend 5 to 10 fields that would be useful for categorizing a file. Common examples would be: department, product name, type of document, client, etc. The key to metadata is that it needs to be clear and consistent. Here are a few metadata recommendations:

    4. Use managed metadata fields, choice, or lookup fields so your users don’t have to manually type in metadata to ensure consistency.
    5. Make as much of it required as possible – if you don’t your users likely won’t fill it out!
    6. Resist the temptation to add too many fields. The idea is to make it easier for your users to find things, not make them have to take an hour to upload documents.
    7. Summary

      This article covered just a few basic tips, but even though they may seem small, they can have a huge impact on search relevancy for your users. And the best part is that it doesn’t take any custom code or even a lot of effort. The end result should be that users will spend less time looking for things in SharePoint which can add up to tons of ROI. Managers like things that bring ROI and it usually puts them in a better mood when it is time to do performance reviews!

      Customizing The Refinement Panel for SharePoint 2010 Search

      One of the quickest and easiest ways to begin customizing the search experience with SharePoint 2010 is to customize the refinement panel web part. If you’ve aren’t familiar with what I’m talking about it is web part that shows on the left hand side of search results page. Each of the sections, are ‘refiners’ which are basically just metadata – and below each refiner the available values that have been entered for content that is being returned in your search result.  In this screenshot you’ll see the refinement panel that was displayed when I did a search for ‘contoso’


      What is being shown in the screenshot is the default refiners that are displayed for SharePoint search.  The refiners allow me to perform a very general search and then click on the refiners to basically filter my results.  I can start with a very broad search and then keep refining until I get to what I’m looking for.

      But in many organizations, they might want to display their own values here instead of the out of the box ones.  The refinement panel uses XML to display the results, so if you wanted to change what you see – it only takes a few steps.

      1) Go to your search results page in your Search Center and put it in edit mode.  Then edit the Refinement Panel web part.

      2) Expand the ‘Refinement’ section.  After the field that says ‘Filter Category Definition’ click the ellipsis button which will bring up an editor that allows you to more easily see the code.


      I know, there’s no formatting for the XML. It is pretty terrible to look at.  You can try to parse it out on your own if you enjoy that kind of thing.  I don’t – I’ve found the easiest way to clean up the code is to paste it into Visual Studio 2010.  I’ve experimented with a few other editors, and Visual Studio 2010 is the best one. 

      3) Assuming you are us VS2010, you can open up any project (or create a new one) and Add a New Item.  Choose to add an XML file (under the data section).  You can name it whatever, because you don’t really need to save it. Then paste your code in and it will all be automagically formatted for you!

      QUICK TIP!  Visual Studio will add the following code to any new XML file: <?xml version=”1.0” encoding=”utf-8”?>  You’ll want to remove this before you paste your code in. If you don’t, it will cause the Refinement Panel to error because that line is already included in the XML you are pasting in from the web part.  SharePoint doesn’t like it if it sees two of those lines at the top of your XML.

      4) This is going to be a very basic example and we are going to configure the refinement panel to only show the Author refinement.  To do this we want to everything inside the <FilterCategories> tag except line 85.  In other words, when you are done your XML should look like this:

      <?xml version="1.0" encoding="utf-8"?>
        <Category     Title="Author"     Description="Use this filter to restrict results authored by a specific author"     Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator"     MetadataThreshold="5"     NumberOfFiltersToDisplay="4"     MaxNumberOfFilters="20"     SortBy="Frequency"     SortByForMoreFilters="Name"     SortDirection="Descending"     SortDirectionForMoreFilters="Ascending"     ShowMoreLink="True"     MappedProperty="Author"     MoreLinkText="show more"     LessLinkText="show fewer"     />

      It should be pretty obvious what most of the tags do here – but the most important one is MappedProperty.  In this case, the refiner is looking at the Author managed property.  But really you could set this to be whatever you wanted. So if you had a custom field that you wanted to refine on, no problem!  All you’d need to do is add a managed property, and copy/paste the line in the XML which defines the Author refiner, and rename it to match the name of your managed property.  Obviously update the other values too – like title and description. 

      Don’t know how to create a managed property?  Check out my blog post on the topic:

      5) Copy and paste your new XML from VS2010 back into the text editor in SharePoint. Then his the OK button on the text editor.

      6) Now here’s the tricky part that trips people up.  Before this will work you need to remove the check from the box at the bottom of the ‘Refinement’ section in the web part properties that says ‘Use Default Configuration’ – if you don’t do this, your changes will not be applied!



      7) On the web part properties panel, hit the Ok button.  Then you’ll need to press the Check In button on the ribbon.

      8) Run a new search and you’ll see that your refinement panel has been customized!  If you don’t see results, there could be a couple reasons why. First, make sure that there’s enough items being returned in the search which contain the refiner you are looking for. I’m not sure of the exact number needed, but generally at least 5 will do the trick.  Second, if that isn’t the issue you might want to double-check your XML.  It is very unforgiving by nature.


      This is one of the more common search customizations I’m doing these days for clients.  As a final thought, my recommendation is that if you plan on a field being used as a refiner it is best if it isn’t free-text.  That means something like a Choice or Managed Metadata field works best. 

      The other tip I’d suggest is when customizing the refinement panel, don’t try to do 50 refiners all at once.  It never seems to end well.  I suggest starting with a couple, confirm they work, and then add a few more.  Repeat that until you are done.  Slow and steady win the race!

      Final thought – remember you can always just add the out of the box refinement panel to the page if you want to get back to the original.  Or, just go back into your custom web part and check the box again to use the default configuration. Just remember if you check that box again it will overwrite the changes you made to the XML so you’ll have to start over again to reapply your changes.  That’s why once I get my refinement panel web part customized the way I like it – I export it out just in case!

      Creating Custom Managed Properties

      I speak frequently on the topic of search at various conferences, and one of the challenging parts about this subject is that many of the demos simply take a lot of time.  For example, if I wanted to do a demo about to show how users could search on their own custom fields it would require that I subject the audience to sit there while I run some indexes.  Which is no fun to watch, and I simply don’t have enough bad jokes to keep an audience entertained for more than 30 seconds at the most. 

      I’m writing this post as a way to provide the steps required to do that demo for creating your own custom fields.

      Quick Summary:

      -Create a field in a list or document library. 

      -Make sure some items in the list or library have the field and it is filled out.

      -Run an incremental crawl to add the field into the index as a crawled property.

      -Create a managed property.

      -Run a full crawl.

      -Wait patiently.

      -Enjoy searching on your new managed property.

      Longer Explanation:

      1) The first step is to create a list or document library with at least one custom field in it.  In my case, I’ve added a column to an existing list called ‘Type of Document’ and made it a Choice field.  This was a very deliberate choice – in larger organizations a Managed Metadata field has a lot of benefits for this type of scenario, but in my case I’m trying to move this along as quickly as possible.  Managed Metadata fields can’t be updated in the datasheet view.  Choice fields can be. And we need the fields to be quickly filled with information so we can then index it….but let’s not get ahead of ourselves.

      2) Make sure you’ve got some items in list or document library and using the datasheet view populate the values of your new field. You should be able to select a value and then just like in Excel, click the box in the bottom right corner and drag down to fill the cells below:



      3) Once you’ve filled in some data, the next step is to go to your Search Service Application in Central Administration (Application Management > Manage Service Applications > Search Service Application) and kick off an index.  You can do this by clicking Content Sources from the left navigation.  Then click the dropdown next to Local SharePoint Sites and select Start Incremental Crawl (this assumes you’ve already done a full crawl at some point – if not then click Start Full Crawl)



      On my dev server (without much content) and incremental crawl took anywhere from 2.5 minutes to almost 6 minutes.  This is exactly why I don’t demo this live! 

      4)  Once it completes, from the left navigation click on Metadata properties. The from the toolbar across the top click Crawled Properties:


      5)  To quickly find my new custom column, I typed in ‘type’ into the search box at the top and hit the green arrow.  There were several results that came but, but the one I’m looking for is called": ows_Type_x0020_of_x0020_Document(Text). We aren’t really doing anything special in this step – just proving that our new column got indexed.


      I know, it has a strange looking name.  This is the internal name for the field.  But we are going to take care of that in the next step.

      6) The next thing we are going to do, is create a Managed Property which will take care of that strange looking name for the crawled property.  From the toolbar at the top, click on Managed properties and then New Managed Property.

      From the New Managed Property Page fill in the following information into the fields:

      Property name: TypeOfDocument

      Type of information in this property: Text

      To map our column, press the Add Mapping button and in the Crawled property name field enter ‘type’ and press find.  This is about the same process you’d have followed in step 5. Once you’ve located the field, select it and press Ok.


      You’ll see that the field mapping has now been added to the Mapping to crawled properties field on the New Managed Property page.  Next, place a check in the box to Allow this property to be used in scopes.  Then once complete press OK.  The page should look like this:


      7) Now, go back to your site.  You can test to see if your managed property works by typing in the following into your search box – make sure you are using the All Sites scope: TypeOfDocument:HR


      You’ll notice that it doesn’t return any results. That’s because in order for our managed property to work, we’ve got run (another) crawl.  But this time, an incremental crawl isn’t going to work – we’ll have to run a full crawl.  In my case, this took just slightly more than 33 minutes – which brings the total time spent indexing to about 38 minutes. Definitely not something that would make for a great demo to have to watch.

      When the full crawl completes, if you run the same query above you’ll get results this time.  That type of query syntax we used for the search is called a restriction.  What we are doing is only searching against our managed property we created for documents that contain HR.  If you happened to have a value such as Human Resources to accommodate for the space, you’d need to enclose the string in quotations like this:  TypeOfDocument:”Human Resources”

      Next Steps

      Once you’ve created a managed property there’s several other things you can do.  You could create custom search refiners, scopes, customize search results, or even use it to create custom search applications.  But that is the topic of another blog post. 

      FAST Search for SharePoint Error: Unable to resolve Contentdistributor

      I’ve been working on a custom search project recently and ran into an issue that had me scratching my head.  My FAST Content SSA wasn’t able to crawl successfully crawl content.  When I kicked off a full crawl it wouldn’t fail, but it would continue to run until I manually stopped it, never returning a single error, warning, or anything.  When I looked at the Event Viewer on the SharePoint Server I saw this:

      Log Name: Application
      Source:    SharePoint Server Search
      Event ID:  2567
      Task Category: Content Plugin

      General: Failed to connect to Failed to initialize session with document engine: Unable to resolve Contentdistributor

      I’ve solved this problem several times before, either by updating the certificate that SharePoint and FAST use to talk to each other or updating the port number listed for the content distributor. In fact when you search on this issue, that’s going to be what you are going to find as the most common solutions.  Apparently, in this case it was special.

      It turns out there’s another reason why you get this issue – and that is because the user ID used to run the scripts to apply the SSL certificates needs to be same as the one that is listed for the SharePoint Search Service.  Once I realized this, it was easy enough to go into Central Administration and simply change the service account that is used for the SharePoint Search Service to the same one that is being used to run the script. 

      The challenge here, is that if we use our typical install methodology with SharePoint that means that the account that is configured to run the SharePoint Search Service is not an administrator – but to run these SSL scripts for FAST you must be using an administrator account.  It isn’t surprising that this misconfiguration happened.

      What is surprising is that after initial configuration, this wasn’t an issue.  In looking at the crawl logs, everything seemed to be fine until there was a password change. There could have been some strange order of operations thing – but I thought I’d mention that in case someone else runs into the issue.

      For more information on the issue, the post that helped me solve this one came from here:

      For more information on Creating and setting up the Content Search Service Application:

      Managing certificates (FAST Search Server 2010 for SharePoint)

      SharePoint 2010: Deploying Custom Branding Files – Part 1

      Wow, it sure has been a long time since I last blogged. Nearly 5SPBrandingBook months! Part of the reason for the long hiatus is that most the of words I’ve written since my last blog post have been dedicated to a few different SharePoint 2010 book – but most specifically Professional SharePoint 2010 Branding and UI Design from Wrox.  If you’ve preordered the book or watching it on Amazon, first off thank you very much! Second, the publish date has been bouncing all around but I’m happy to report that the last chapters have been completed and we are pretty much just waiting for the printing presses to put ink on paper. If you’ve preordered the book, it shouldn’t be too much longer.  If you haven’t preordered the book you should – it has a motorcycle on the cover! I’m very excited about the book because I think it will speak to anyone and everyone looking to customize the SharePoint UI. Whether you are need basic help changing the look and feel or your site or you are trying to create an extremely custom design this book will help you out.

      Enough of the shameless plug, but the reason I mention it is because one of the topics I cover in the book is around deploying custom branding files.  How should you do it and why? This is a fairly large topic but in this post I’m going to focus on some of the higher level issues and then dig deeper in later posts.

      What is deployment?

      Others may think about it differently, but to me deployment is simply how you get files into SharePoint. Often people associate SharePoint Solutions and Features (will discuss below) with deployment and while that is true, deploying files can be done manually too.  Ultimately, that’s the big decision point many have – “how should I deploy my files?”

      What are the options for deploying my files?

      If we wanted to get really technical there’s probably a lot more ways, but I’m going to break down the deployment options into three categories:

      1) Manual Deployment: The act of deploying files by using SharePoint Designer or manually uploading them through the SharePoint UI.

      2) Features and Solutions: If you aren’t familiar with SharePoint features and solutions at least on a basic level you should be. Although they have relatively generic names they refer to very specific capabilities in SharePoint. Solutions are a type of sealed cabinet (.CAB) file which has the extension of .WSP. In fact, if you have a SharePoint solution and change the extension to .CAB you can take a look at the contents inside – little troubleshooting tip that can be useful. Solutions are a way to move files around and get them physically to where they need to be in an organized way. For SharePoint 2010 there are two types of solutions: farm and sandboxed.  Farm solutions behave the same way solutions behaved in SharePoint 2007 – they deploy files to file system of the SharePoint server. To be more specific – the actual source of the files lives on the server file system similar to how all of the system files are deployed. Sandboxed solutions are deployed at the site collection level and the source of their files actually resides in the content database. There’s a lot more to the topic of solutions and a lot more you can do with them other than deploy branding files, but to avoid this post from becoming a book itself, I’m going to leave the description very high level.

      SharePoint features are the mechanism that actually puts your files into SharePoint or performs the specific functionality you’ve defined.  A feature itself is comprised of a feature.xml file which has a schema that defines some basic things like title, description, has a unique identifier, the scope at which it can be activated, as well as references to assemblies (custom code you’ve written that will be run when the feature is activated), or references to manifest files which themselves are just files written in an XML-like language called CAML that define how and where certain files will be put in SharePoint. Again, the topic of features a massive one so I’m just scratching the surface.

      3) Custom site definitions: When you create a site collection, the site definition itself is what defines it.  It can get a little confusing, but in this case the term “site” is actually referring to site collection.  A site definition itself is primarily made of a file called onet.xml and like a feature it is written in CAML. So when you actually go to create a new site collection, you choose a template from Central Administration and SharePoint goes and looks at the corresponding site definition to determine what features and files get deployed. One more time, I’ll mention custom site definitions are a big topic and just staying high level.

      Which option should you choose?

      Like with most technical discussions the answer is “it depends” – but what are the decision points? The biggest issue is going to be around whether to deploy your files in an uncustomized or customized state. Essentially the difference is going to be that files that are uncustomized all point back to a single source file.  Changes can be applied to that single file which could impact many places where that file is referenced.  Conversely, customized files are unique instances of a file.  This concept can get a little tricky to describe, and I’m planning a follow-up blog post to help clarify further.  Until then, for more information on the subject take a look at Andrew Connell’s article on TechNet called Understanding Customized and Uncustomized Files in WSS v3.  Most of the concepts still apply.  But consider that files deployed out of the box by SharePoint are all uncustomized and it would be possible to update an out of the box master page like v4.master and have the changes be applied to every site that uses v4.master.  (DISCLAIMER: That was just an example to demonstrate a concept – don’t modify system files! If you need to make a copy first!)

      Of the deployment options described above, #1 deploys files in a customized state. #2 and #3 deploys files in an uncustomized state.  Keep that in mind as you read the rest of the post.

      Your project is small and not very complex

      If the project is very simple and the site is relatively low traffic then deploying manually will be just fine. But if you’d consider the project to be more complex or you aren’t sure then I’d suggest one of the other methods.  In other words, if you project is very simple deploying files in a customized state is probably fine.  But for even mildly complex projects deploying files in an uncustomized state is likely the better option.

      For most projects – the next best option is to deploy files as a sandboxed solution

      Sandboxed solutions have several advantages when it comes to branding. First off, most branding files such as master pages, page layouts, CSS, and images don’t require a DLL or assembly or anything else that would require they be deployed with full trust to the server.  This means that SharePoint admins don’t need to get involved with deploying sandboxed solutions – it just makes the deployment process easier.  Since there’s a limit to what can run in the sandbox there’s naturally much less risk to the farm so that is a great thing.  Another thing to consider is that if you are in a hosted model, whether internally or in the cloud, this might be the only option you have!

      The biggest downside to deploying files via a Sandboxed Solution is that they are isolated to a single site collection.  So if you had a very large project and wanted to deploy your branding across several site collections then you’d either have to deploy the same sandboxed solution over and over again (which doesn’t sound like the best idea if you can avoid it) or you should consider a farm solution.

      Farm solutions offer the most power and flexibility – but also require higher permission levels

      For large projects that involve deploying consistent branding across multiple site collection farm solutions are going to be the way to go.  For example you could update a single master page file which would in turn apply those updates to every site collection where that master page is being used.  So if you had a corporate branded master page used across 10 site collections you could update one file and all of your sites would get updated.  Additionally, a farm solution might be required if you are deploying something else that can’t operate in the sandbox.

      However, like solutions in SP2007, farm solutions in SP2010 need to be deployed by a farm administrator – which isn’t really a bad thing it just means that you are going to have to follow a few more steps every time you need to deploy something.  Which shouldn’t be a big deal if this is a bigger implementation; hopefully you’d be taking the proper steps to ensure that you are testing everything you deploy anyway!

      What about custom site definitions?

      They are definitely an option but personally I’m not a big fan except in very specific circumstances. My preference would be to evaluate what’s possible by using solutions and features.  If you still aren’t happy make sure you read this blog post from Eric Shupps called Site Definitions – the Good, the Bad, and the Ugly.

      Quick summary:

      Deploying files is all about how do you get your files onto your server, which option is best for you?

      1) If your project is really small and simple, then manual deployment is probably fine.

      2) Try to use sandboxed solutions the first choice if you need more than manual deployment. There are some limitations to deploying files as a sandboxed solution…

      3) If sandboxed solutions are too limiting for your needs then a farm solution is likely the way to go but does require farm administrator permissions to deploy.

      4) Custom site definitions are an option for very specific scenarios, but read up before going down that path to make sure you do it correctly!

      What’s next? This is part 1 isn’t it? One might assume there will be a part 2.

      In the next post I’ll be talking about the methodology that I typically use for deploying branding files.  Specifically, where do we deploy files to in SharePoint and why?

      Stay tuned!


      Get every new post delivered to your Inbox.