SharePoint – Search Issues

I recently had an issue with a SharePoint Server 2007 farm where the Search service was completely ignoring an entire document library on one of the sites. It was the only issue that we were aware of at the time and it was very odd. We engaged with Microsoft to try to solve the issue. After what seemed like a very long time, we finally solved it.

The answer: Check Response Headers in IIS for your SharePoint Web Applications and ensure that the MicrosoftSharePointTeamServices header is listed with a value that matches your farm’s build number (ie.

The SharePoint Search service checks Response Headers to identify whether the site is a SharePoint site or not. If this Response Header is not detected, then it will be crawled like a normal site. When a non-SharePoint site is crawled, things like permissions, visibility settings, etc are ignored and some content may not be crawled at all. This was the issue we ran into.

Before adding the Response Header, our CPU was getting maxed out more than normal and crawls were taking a very long time. Now that the Response Headers are in place, the server is much more responsive and crawls take a fraction of the time that they did before!  In addition, this issue applies to SharePoint 2007, SharePoint 2010, and SharePoint 2013.

Overcoming SharePoint’s Achilles Heel: User Adoption

As a SharePoint consultant who has worked with dozens of customers, the one constant I face, over and over, is that users are inherently resistant to change. It’s just a fact. And, who can blame them if they’re not properly educated and supported over the course of that process change – whatever that may be.

So, with respect to SharePoint, driving user adoption is one of the most important, but also one of the most difficult tasks that a SharePoint architect/administrator has. You could even say that it is the single most important task when designing/deploying SharePoint. Simply because it drives everything else. If the deployment doesn’t function correctly, then user adoption will suffer. If it is difficult to navigate or understand, then user adoption will suffer.

Couple all of these factors together and it will be difficult to meet your SharePoint project success metrics. Here are some key areas that I like to focus on when planning for user adoption:

1. Familiar

In order to properly design a SharePoint deployment, you must think like an end user. And not just any end user…YOUR end users. Every corporate IT environment is unique.

How do your users access shared documents?
How do they access their personal documents?
How do they access reports?
How do they share ideas?

These are all key questions that need to be asked. A survey of a portion of your users probably wouldn’t hurt either.  The closer you can make accessing documents and information to the way your users are familiar with will help tremendously with user adoption! For example, if your users are used to the traditional network share filled with folders, then a single document library may work best.  If the folder structure is broken out by department already, then setting up separate document libraries for each department may be best.

2. Functional

One of the biggest reasons for choosing SharePoint that I hear is for ‘document sharing’. But, why use SharePoint? Why not just use a network share or maybe even a cloud based sharing solution? These are common questions and they are completely understandable. However, it shows a lack of understanding of the key enterprise features that SharePoint offers. Here are some key features that users should be well trained on prior to deployment so they fully understand how to use the tool.

Enterprise Search
Content Types and Document Templates

These are just some examples of features that most users find indispensable. So make sure you engage and educate them prior to going live with the deployment.

3. Automation

Automation is key when implementing SharePoint as well because it makes refusing to use SharePoint very difficult to justify. Automating processes such as HR On-boarding, Capital Purchasing Approval, Information Requests, IT Help Desk Ticketing, and so much more have huge ROI potential! A simple, high-level review of ‘painful’ processes that departments have to deal with could reveal perfect use-cases for automation.

Have you deployed SharePoint in your business?  If so, what is your user adoption rate?  What could make it better?  If you haven’t deployed it, but would like to, did this post help give you a good idea on how to drive adoption? Let us know how we can help!  Contact eGroup’s Application Services Team at for more information.

SharePoint 2007: Mainstream Support Ends on 10/9/2012

Is your company still running SharePoint 2007? Has your company been considering an upgrade to SharePoint 2010? Well here’s another compelling reason to upgrade – Microsoft’s Mainstream Support will end on 10/9/2012.

See this link for more information…

What does this mean? Here is Microsoft’s explanation on what that means…

What is the difference between Mainstream Support, Extended Support, and online self-help support?

Support provided

Mainstream Support phase

Extended Support phase

Paid support (per-incident, per hour, and others)



Security update support



Non-security hotfix support


Requires extended hotfix agreement, purchased within 90 days of mainstream support ending.

No-charge incident support


Warranty claims


Design changes and feature requests


Product-specific information that is available by using the online Microsoft Knowledge Base



Product-specific information that is available by using the Support site at Microsoft Help and Support to find answers to technical questions



Note: A hotfix is a modification to the commercially available Microsoft product software code to address specific critical problem

See this link for the FAQ…

What is your upgrade plan?


I recently had a project where I needed to migrate a 2007 sub-site from WSS 3.0 to SharePoint Server 2010 Enterprise. I needed to move all of the lists and keep the metadata (Created Date, Created By, etc) in tact. Here’s how I did it…

  1. Move Content DB from MOSS/WSS to SP2010 using the attach db method and use the -UpdateUserExperience switch
  2. Export the list using the Export-SPWeb Powershell command and the -IncludeUserSecurity switch
    1. export-spweb -identity -ItemUrl Lists/MyList -IncludeUserSecurity -IncludeVersions All -path serversharefilename.cmp
  3. Import the list into your new site using the Import-SPWeb Powershell command
    1. import-spweb -identity -IncludeUserSecurity -path serversharefilename.cmp

You should now have your list in the new site with all of the permissions and metadata in tact!