The LandPhil be honest, be honorable, be kind, be compassionate, and work hard.

September 22, 2011

SharePoint: Search gotcha

Filed under: SharePoint — phil @ 9:36 am

So below I detailed the steps I had to take to get SharePoint Foundation Search running on my farm.  It worked great.  It even indexed content I didn’t expect it to index!

On the one of the sites that I am indexing now is a list.  That list contains seemingly innocuous information, but one of the requirements that the group had for that list was that some of the information contained on it was not ‘publicly’ (visitors) viewable.  No problem.  I created a new Display Form for the list, set it as the default and I thought I was done.  Until the crawler got to the site.  See, I didn’t remove the original display form because I thought: 1) I might need it, and 2) I’m not a big fan of removing default content unless I really have to.

You can guess what happened.  I entered form data into the search box and I got back links to the original (no longer default) display form aspx page.  That was no good.  I was hoping that I could somehow restrict access to, or hide the page but, after poking around in SharePoint Designer for a little bit, I decided I’d just delete the file.  The interesting part is that that appeared to break the index for the site and I had to wait for the crawler to run again before searching worked.

Worst case, I mount and recover the file from an SPSite backup that I have.  Though, I can probably also just copy the default display form aspx page from another list.

September 20, 2011

SharePoint: Configuring Foundation Search

Filed under: SharePoint — phil @ 12:08 pm

You’ve got SharePoint installed.  You’re generating content.  Now you’d like it if that little Search bar on the top right actually returned something other than:

  • Your search cannot be completed because this site is not assigned to an indexer.  Contact your administrator for more information.
The first step is to turn on the Foundation Search Service.  You do that with the following:
  1. Open Central Administration
  2. Go to System Settings -> Manage services on server
  3. Click on SharePoint Foundation Search
  4. Assign a service account to start the service (this is a managed account, so select on or add a new one)
  5. Assign a content access account (more on that below)
  6. Enter a database server and database name (or accept the defaults)
  7. Choose an indexing schedule
  8. Click Ok
  9. When you return to the Manage services on server page, click Start next to SharePoint Foundation Search
That’s only the first part, however.  You’ve got the Search service running and the indexer on a schedule, but you actually have not yet identified what to index.  In standard and enterprise version of search, you get a full blown service application and a lot of that configuration takes place there.  However, that’s not the case with foundation search, so let’s continue.

The next thing that you need to do grant the content access account (that you entered above) read access to your applications.  Do this:
  1. Go to Central Administration
  2. Go to Application Management -> Manage web applications
  3. Highlight the web application that you want foundation search to index
  4. Click User Policy in the ribbon
  5. In the Policy for Web Application box that appears, click Add Users
  6. Leave the Zone selection at (All zones), click Next
  7. In the Choose Users box, enter the username of the Content Access Account you used above when you configured SharePoint Foundation Search
  8. Check Full Read for permissions
  9. Click Finish
Alright.  Now you have the indexer running and the content access account has privileges to read all of the content in your web application.  But you still haven’t identified the content to crawl.  That’s done at the content database level. So:
  1. Go to Central Administration
  2. Go to Application Management -> Manage Content Database Settings
  3. Click on the content database that contains the site(s)/site collection(s) that you want to index
  4. In the settings for that content database, in the section Search Server, use the drop down list to select the server with SharePoint Foundation Search service running
  5. Click OK.
Viola!  You have turned on and set a schedule for indexing, granted permissions for the crawl account, and identified content to crawl.  More than likely, you’re done.  Based on the schedule that you created in the first part, and the amount of data that you need to crawl, you may need to wait a little while to check to see if everything is working.

In my case, it did not.  The search box continually returned “no results” for anything that I typed in.  So I turned to the Application Event Log and found this:
Log Name: Application
Source: SharePoint Foundation Search
Logged: <datetime>
Event ID: 14
Task Category: Gatherer
Level: Warning
User: <search service account>
Computer: <sharepoint server>
OpCode: Info
The start address sts4s://<website address>/contentdbid={<guid of content db>} cannot be crawled.
Context: Application ‘Search_index_file_on_the_search_server’, Catalog ‘Search’
Access is denied.  Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository.  If the repository being crawled is a SharePoint repository, verify that the account you are using as “Full Read” permissions on the SharePoint Web Application being crawled. (0x80041205)

This was rather disheartening as the error message indicated that the fix was to do all of the things that I had already done.  It turns out that the answer was hidden in the start address.  You see, I had created the web application with <address1> and that was the Default address.  I had then created a multitude of Custom addresses and was using one of those as the main address for the website <address2>.  However, no matter how you are viewing the web page, the crawler will always use the Default address <address1>, but when you search the site while viewing it at <address2>, it cannot match them and the search engine returns “no results found”.  I resolved the problem by changing around the Default and Custom zone access mappings in: Central Administration -> Application Management -> Configure alternate access mappings.

However, I also had Audit Failures for logons with the Content Access Account.  After much gnashing of teeth and dead end searching, I stumbled upon this article: which details a registry change that allows for loopback to a specific list of addresses.  The details are at the link, but I will also include what I did below:
  1. Click Start, Click Run, type regedit, and then click Ok.
  2. In the Registry Editor, locate and then click on the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  3. Right-click MSV1_0, point to New, and then click Multi-String Value.
  4. Type BackConnectionHostNames, and then press Enter.
  5. Right-click BackConnectionHostNames, and then click Modify.
  6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click Ok.
  7. Quit Registry Editor, and then restart the IISAdmin Service
I included all of the alternate access mapping addresses in the list above.

My foundation search works fine now.  I am able to query and return information for sites and sub-sites for all of the content databases that I’ve identified for indexing.

August 30, 2011

SharePoint: Using custom CSS

Filed under: General,SharePoint — phil @ 3:03 pm

For the love of all that is holy, don’t try and do this in SharePoint designer.  I’m still not entirely sure what was going on, but it’s not pretty.

Let’s say you have a page that you want to put some custom CSS on.  You could open the page in designer and modify the corev4.css.  What this actually does is copy the file from the web application root to a _styles directory in your current site collection and then in the background re-link everything to it.  This is handy, except that the one thing that it doesn’t re-link to it is Themes.  Any themes you select still only make changes to the root corev4.css file, which (if you’re following along) is overridden by the copy you have in your site collection.  Short story: your new site collection isn’t themable.

The solution: Only update the styles you specifically want to change, and do it directly on the page your editing…in the web browser.  In the ribbon under Editing Tools:Format Text, there’s a drop down for HTML Markup.  Choose to Edit HTML Source, and just drop your custom css in between <style></style> tags and close the window.

The net upshot is that this doesn’t break the site definition template that your page is based on (which IS what happens when you try and do the above in SharePoint Designer).  Another bonus is that the style is truly page dependent.  If you reopen the HTML source, you’ll see that SharePoint has renamed your styles with an .ExternalClassHASH.

Slick, easy, and it doesn’t break anything.  Too bad it took me like 4 hours to figure out.  Hopefully I’ll save you the headache.

Addendum: If you’re editing a web part page, you may notice that you don’t have an HTML Markup button on your ribbon.  You can get around this issue by dropping a Content Editor web part on your page.  Once it’s there and you go to enter content, you will see that you now have an HTML Markup button.  You can drop the style into the content editor web part (in HTML view) and it will work the same way…just for that page.

August 9, 2011

SharePoint Designer: Getting the DateTime into a readable format

Filed under: SharePoint — phil @ 10:15 am
There are 3 view forms in SharePoint Designer for lists:
The default versions of these forms are created by SharePoint when the list is created.  They use a ListFormWebPart to display their information.  This is done by querying SharePoint for the objects directly.
When you create a custom form of any of the types specified above (New, Edit, or View), the default web part that is included is actually the DataFormWebPart.  This queries SharePoint for data and feeds it into an XML stream and the web part uses XSLT to parse data out of the string.  Unfortunately, this means that all parts of the SharePoint objects are serialized and thus you may run into problems rendering the data in string form.
Case in point, the DateTime object.  The DateTime object has fields for the Date and the Time separately.  When serialized, however, the data is concatonated into a single string.  This has two downsides, 1) A single string with no white space is hard to read, and 2) since the time is stored in zulu time (so that a particular user can display based on his chosen time zone), the string data is also displayed in zulu time.
There is, fortunately, a way around this.  If you edit the DataFormWebPart and do the following:
1.  Right above the table that contains the data rows, below the <xsl:template> tag, insert:
  • <xsl:param name=”Pos” select=”position()” />
2.  In the table row that contains the dates and times you wish to display:
  • Comment out the <xsl:value-of select=”*” />  with <!– –>
  • Add the following (inside of the <td> tags):
  • <SharePoint:FormField runat=”server”id=”ff3{$Pos}” ControlMode=”Display”FieldName=”EventDate”__designer:bind=”{ddwrt:DataBind(‘i’,concat(‘ff3′,$Pos),’Value’,’ValueChanged’,’ID’,ddwrt:EscapeDelims(string(@ID)),’@EventDate’)}”/>
  • <SharePoint:FieldDescription runat=”server” id=”ff3description{$Pos}” FieldName=”EventDate” ControlMode=”New”/>
3.  Replace parts of the code as follows:
  • id=ff#{$Pos} (where # is equal to the display row on the form)
  • ControlMode=”Display” (can be Edit, New, or Display)
  • FieldName=” “ (Use the same field name as the value-of select statement you commented out)
  • bind=” “ (in the bind string change the row position number and the field name)
  • Update the id, FieldName and ControlMode settings of the SharePoint:FieldDescription to match SharePoint:FormField
Viola, the date and time in a readable format and still encoded with the logged in user’s time zone choice.

June 6, 2011

SharePoint: PowerPivot gotcha

Filed under: PowerPivot,SharePoint — phil @ 9:42 am

PowerPivot is an interesting beast. If you don’t know what it is, I’ll give you a very brief (and probably incorrect overview): PowerPivot is an Excel plugin, provided free from Microsoft, that allows you to import data from external sources into your very own localized cube for analysis. It’s very, very fast AND very, very small (bordering on the impossible as far as compression goes.) However, it makes your Excel workbooks pretty big (still much smaller than the amount of data you can have, but big enough that sending it to someone via email is pretty much out of the question.) Enter PowerPivot for SharePoint. What this does is create a dedicated analysis services engine on your application layer and when you upload a workbook with powerpivot data, that data is separated out into the analysis services engine. Thus allowing anyone viewing to see the fruits of your labor without needing to install Excel and PowerPivot on their local desktop. There’s a catch, of course, there always is.

Installing PowerPivot on your SharePoint farm is no easy feat. Well, Microsoft claims its an easy feat, but only sort of, and only if you install PowerPivot and your farm at the same time. Most people don’t do that. In fact, no one should do that. In fact, if you’re thinking of doing that just stop now and redesign your farm. But that’s a different discussion. You want to install PowerPivot. And you want to install it on your existing farm. Good news: There’s lots of documentation. (How to: Install PowerPivot for SharePoint on an Existing SharePoint Server)

Here’s the gotcha. You’re going to read through all of that documentation. And you’re going to install the analysis services engine off of the SQL CD. And you’re going to configure a PowerPivot service application in SharePoint. And you’re going to create an unattended refresh account in the Secure Store.

And you will have a 50/50 chance that this will all work just fine. Here’s the rundown: If you installed your farm with default settings, and ran the configuration wizard with default settings, and installed SQL with default settings, it might work. If you, like most everyone else, used service accounts instead of the “local service” and the “network service”, then there is a fairly good chance you did all of the above and missed a critical step.

Let me first explain how the services work together. First off, Excel Calculation Services is what displays your workbook in the browser. In order for Excel Calculation Services to use the slicers against your PowerPivot data, it needs to be able to communicate with the analysis services cube on the application server. This is the unattended refresh account inside the Excel Calculation Services service application settings. In order for the analysis services engine to refresh the cube data from the original external source, it needs a separate account. This is the unattended refresh account inside the PowerPivot service application settings. Now, you’ve configured those accounts if you read the information from Microsoft above. But you get the dreaded error: “The data connection uses Windows Authentication and user credentials could not be delegated. The following connections failed to refresh: (name of connection in workbook for powerpivot cube).”

Here’s what you need to know: The account that is running “Claims to Windows Token Service” needs two more permissions. One is it needs to be a local administrator on the machine that has the PowerPivot analysis engine installed, and the second is that that account also needs the permission “Act as part of the operating system” that can be found in the Local Security Policy -> Local Policies -> User Rights Assignment. These are changes that need to be made to the server, not to SharePoint or SQL.

As it turns out, you can find that information here: (It’s under Community Content, if you, like me, read the article and were still frustrated.)

March 23, 2011

SharePoint: Error, Event ID 6482

Filed under: Errors,SharePoint — phil @ 6:06 am

Affected software: Windows SharePoint Server 3.0

Type : Error
Date : 3/23/2011
Time : 8:52:17 AM
Event : 6482
Source : Office SharePoint Server
Category : Office Server Shared Services
User : N/A
Computer : xxxxxxxx
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (94fda143-13d5-4bd2-bab1-d23b38f4ad95).
Reason: The current operation timed-out after 3600 seconds
Techinal Support Details:
System.Net.WebException: The current operation timed-out after 3600 seconds
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.SynchronizeDefaultContentSource(IDictionary applications)
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

Solution: This is caused by the Office Server Search Service having bad authentication information. First, go to Central Administration and click on the affected server. This should take you to the services on server view. Click on the Office SharePoint Server Search Service link and it will take you to the settings page. Enter the correct login information. On the machine itself, restart the Office SharePoint Server Search service in the Services management console. This should generate two new log entries Event IDs 10044 and 10045 indicating that changes to the configuration were successfully saved and imported. To re-enable search indexing on your site, restart IIS.

February 28, 2011

SharePoint: The State Service

Filed under: PowerShell,SharePoint — phil @ 8:13 am

Normally, one wouldn’t be writing this blog post. Normally, one wouldn’t be looking for the information contained in this blog post either. See, usually when you do the installation of SharePoint, you run the Configuration Wizard and the end and tell it to set up all of the basic services. We didn’t do it that way.

In fact, we manually set up all of our service applications so that we had complete control over what application pools they were assigned to, what they were named, and what database (if any) was created to support them. This worked splendidly for all of the service applications that have a constructor accessible via the Central Administration interface. As you may have already surmised by the content of this article thus far, the State Service does not. The only way to created a State Service application (and associated proxy) is to either create it using the configuration wizard, or create it via PowerShell.

Using the configuration wizard will create the service and create the application proxy and create the application database using the farm SQL server. This is perfect if you don’t really care what things are named or where they are stored. I don’t like to do things that way.

When you use PowerShell, you have control over the name of the service application, the name of the application proxy and the name and location of the database file. Below is the code to create the State Service application.

$serviceApp = New-SPStateServiceApplication -Name "State Service"
New-SPStateServiceDatabase -Name "StateServiceDatabase" `
-ServiceApplication $serviceApp
New-SPStateServiceApplicationProxy -Name "State Service" `
-ServiceApplication $serviceApp -DefaultProxyGroup

The following site contains this information as well as the instructions on how to do this using Central Administration and the farm configuration wizard.

January 24, 2011

SharePoint: Error, EventID 5586 (and 2159)

Filed under: Errors,SharePoint — phil @ 10:59 am

Log entry for EventID 5586:
Unknown SQL Exception 297 occurred. Additional error information from SQL Server is included below.


The user does not have permission to perform this action.

Log entry for EventID 2159:
Event 5586 (SharePoint Foundation) of severity 'Error' occurred xx more time(s) and was suppressed in the event log

What’s going on? This is occurring because your SQL Server has not been configured to use named pipes.


  1. Open the SQL Server Configuration Manager (assuming you are using SQL 2008)
  2. Browse down to SQL Server Network Configuration – Protocols for <namedserverinstance>
  3. Right-click “Named Pipes” in the right pane and choose Enable
  4. You may need to restart the server for changes to take effect

> EDIT < Christopher Hatton adds (from the comments):

Granting the farm database access account “VIEW SERVER STATE” under the SQL Server properties will also resolve this issue.

SharePoint: Error, EventID 6482

Filed under: Errors,SharePoint — phil @ 8:14 am

Log entry:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (2059dee5-7de2-4e07-ba60-3a5630abdbe1).

Reason: Object 67211af6-bd76-4344-852c-3d331ab57d81-query-0 not found.

Technical Support Details:
System.Collections.Generic.KeyNotFoundException: Object 67211af6-bd76-4344-852c-3d331ab57d81-query-0 not found.
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

What’s going on? The service account specified for “Windows Service – SharePoint Server Search” does not have permissions in DCOM to launch and activate.

The fix:

  1. Go to the Control Panel on the SharePoint application server running search
  2. Launch Component Services
  3. Browse to Component Services – Computers – My Computer – DCOM Config – OSearch14
  4. Right-click OSearch14 and choose Properties
  5. Go to the Security tab and click the first Edit button (under Launch and Activation Permissions)
  6. Add the domain\username of your service account and make sure the check boxes for Local Launch and Local Activation are checked

You should no longer receive Event ID 6482 errors.

SharePoint: Error, Event ID 8213

Filed under: Errors,SharePoint — phil @ 8:02 am

Log entry:
Volume Shadow Copy Service error: The process that hosts the writer with name OSearch14 VSS Writer and ID {0ff1ce14-0201-0000-0000-000000000000} does not run under a user with sufficient access rights. Consider running this process under a local account which is either Local System, Administrator, Network Service, or Local Service.

Initializing Writer

Writer Class Id: {0ff1ce14-0201-0000-0000-000000000000}
Writer Name: OSearch14 VSS Writer

What’s going on? The account you have designated as the service account for the “Windows Service – SharePoint Server Search” service does not have the correct permissions to the registry keys required for normal operation. By default, this account is the local system or farm account, both of which already have permissions.

The fix:

  1. Open regedt32.exe on the SharePoint application server running search.
  2. Browse to HKLM/System/CurrentControlSet/Services/VSS
  3. Right-click the key VssAccessControl and add a new DWORD (32-bit) value
  4. Name it with the domain\username of the account you have specified as the service account, set the value to 1
  5. Right-click the key Diag and set permissions; add the service account username and grant it full control
  6. At a command prompt run: net stop osearch14. Once the service has stopped, run: net start osearch14.

You can now check the logs and make sure you are no longer getting Event ID 8213 errors.

The generic information for any vss writer application is also available on the german technet site:,WS.10).aspx

As an addendum, you may also receive errors with Event ID 12289:
Volume Shadow Copy Service error: Unexpected error RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...). hr = 0x80070005.

Initializing Writer

Writer Class Id: {0ff1ce14-0201-0000-0000-000000000000}
Writer Name: OSearch14 VSS Writer
Writer Instance ID: {3e52236a-60d3-4ffa-a0ac-22e0f676c972}

You might receive this error if you add the service account value to the VssAccessControl key, but do not also grant them permissions to the Diag key.

Older Posts »

Powered by WordPress