SharePoint24x7 It's all about SharePoint.

9Jul/140

Article – Anonymous Crawl Configuration in SharePoint 2013

Posted by Joy

SharePoint 2013 introduces a new approach for passing credentials to Search Crawler for crawling public-facing sites with Anonymous authentication. SharePoint Search requires a user account for being able to crawl content. One of the bottlenecks we had to deal with SharePoint 2010 Search was difficulty of crawling public-facing sites with Anonymous authentication. SharePoint 2010 requires a user account for crawling content from sites, even if they are configured for Anonymous authentication. SharePoint 2013 resolves this issue by introducing a new approach – Anonymous which eliminate the need of passing an user account and trying to authenticate for crawling content for public-facing web sites with anonymous authentication.

Following are the ways we can configure SharePoint 2013 to pass credentials to SharePoint Search to crawl content:

  • Default Crawl Account
  • Specific Account
  • Client Certificate
  • Form credentials
  • Cookie
  • Anonymous

Following steps demonstrate how to configure SharePoint Crawler to use new Anonymous option to crawl public-facing web sites:

Task 1 – Configure public-facing web site Content Source

  • Open SharePoint 2013 Central Administration web site
  • Navigate to Manage service applications from Application Management group
  • Select Search Service Application instance and navigate to Search Administration page
  • Select Content Sources from the left hand side Search Administration linksSearch Administration links
  • Select New Content Source from Manage Content Sources page
  • Enter Name for the Content Source and select Web Sites option for Content Source Type.
  • Enter web site URL for the Start Address field and click OK.New Search Content Source

 

Task 2 – Create a Crawl Rule to use Anonymous option

  • Select Crawl Rules from the left hand side Search Administration links.Search Administration links
  • Select New Crawl Rule from the Manage Crawl Rules page
  • Enter Path and select Include all items in this path option from the Crawl Configuration section
  • Select Anonymous access option for the Specify Authentication sectionCrawl Rules

 

Task 3 – Crawl content

  • Select Content Sources from the left hand side Search Administration links
  • From the context menu for the new content source added, select Start Full Crawl to start crawling contentFull Crawl
4Jun/140

Article – Fixing PowerPivot Management Dashboard Errors

Posted by Joy

We installed SQL Server PowerPivot for SharePoint and we also executed PowerPivot for SharePoint 2013 Configuration tool and configured PowerPivot for SharePoint.

Now we need to make sure that PowerPivot Service Application instance is configured correctly for us to move forward. Unlike any other service application settings/ configuration pages, PowerPivot Service Application instance settings page is considered as the Dashboard for PowerPivot Service Application instance.

Let’s go and explore PowerPivot Service Application instance and it’s configuration.

  • Open SharePoint 2013 Central Administration web site. Click Manage service applications from Application Management section.
  • Click PowerPivot Service Application instance name to navigate to PowerPivot Management Dashboard.PowerPivot Service Application instance
  • Most of the time, you will end up getting following screen. You will see Excel Services error in the Infrastructure – Server health web part and another error in Workbook Activity – Chart web part. The reason for this error is, App Pool Service Account doesn’t have access to Central Administration content database.PowerPivot Management Dashboard
  • Open SQL Server Management Studio and connect to Database Engine.
  • Expand Databases folder and locate the SharePoint Central Administration content database. Expand the Security folder and then expand the Users folder.Granting membership in SQL Server
  • Select the App Pool Service Account, right click the user account and select Properties. Select Membership page from the Select a page list. Select SPDataAccess database role membership.Granting membership in SQL Server
  • Click OK and close SQL Server Management Studio.

Now you can go and verify PowerPivot Management Dashboard to see that both Red X are gone.

3Nov/113

Fix it – Configuring Object Cache service

Posted by Joy

If you are using Web Content Management (WCM) solutions implemented with SharePoint 2010 Publishing Infrastructure features, you will notice following Critical error in your server Event Log.

Capture9

What does it mean and how do you fix this?

This error is generated by SharePoint’s Object Cache service. In order to get rid of this error, you will have to configure Object Cache service.

What is Object Cache service?

Object Cache is a very powerful built-in service in SharePoint 2010 Publishing Infrastructure which instructs every Web Front End (WFE) to cache object properties in order to boost the performance. This reduces the load on SQL Server tremendously by reducing number of round trips required to retrieve same data from the content databases. In scenarios where you have Web Content Management solutions which go through less content changes, by configuring Object Cache, you can reduce the latency and increase the throughput.

Configuring Object Cache is all about configuring User Policies for each and every Web Applications. Object Cache is configured at the Web Application level and you need to have 02 AD user accounts for configuring Portal Super User and Portal Super Reader. Portal Super User account has full control and Portal Super Reader account has full read-only access.

Let us begin the configuration.

Task 1 – Create required AD accounts

You need to create 02 service accounts in order to configure Portal Super User and Portal Super Reader. Go to Active Directory and create 02 service accounts.

I already have 02 service accounts created named, SP_ObjectCacheUser and SP_ObjectCacheReader.

Capture1

Task 2 – Configure Object Cache User Accounts using CA

Initial configuration done using CA.

  1. Fire up the SharePoint 2010 Central Administration site by navigating to Start –> All Programs –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Central Administration.
  2. Select Manage web applications link from the Application Management group.
  3. Select the web application you are planning to configure Object Cache. In my environment, for this demo, I’m selecting SharePoint – 80 web application.
  4. Click the User Policy from the Policy group in the ribbon.
    Capture2
  5. Click Add Users link in the Policy for Web Application dialog box.
    Capture3
  6. Select (All Zones) for the Select the Zone field in the Add Users dialog box and click Next > button.
    Capture4
  7. Enter the Portal Super User account for the Choose Users field and select Full Control from the Choose Permissions section and click Finish. In my demo, I have configured SP_ObjectCacheUser as the Portal Super User.
    Capture5
  8. Click Add Users link again in the Policy for Web Application dialog box.
  9. Select (All Zones) for the Select the Zone field in the Add Users dialog box and click Next > button.
  10. Enter the Portal Super Reader account for the Choose Users field and select Full Read from the Choose Permissions section and click Finish. In my demo, I have configured SP_ObjectCacheReader as the Portal Super Read.
    Capture6
  11. Policy for Web Application dialog box now will look following.
    Capture7

Task 3 – Committing configuration changes using PowerShell

Final step is to commit configuration changes using PowerShell.

  1. Fire up SharePoint 2010 Management Shell by navigating to Start –> All Programs –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Management Shell.
  2. Enter the following PowerShell commands to update the settings. Change the Web Application name placeholder depending on the name of the Web Application.$wa = Get-SPWebApplication – Identity “SharePoint – 80
    $wa.Properties[“portalsuperuseraccount”] = “CONTOSO\SP_ObjectCacheUser
    $wa.Properties[“portalsuperreaderaccount”] = “CONTOSO\SP_ObjectCacheReader
    $wa.Update()

    Capture8

Now you will not see the earlier Critical error in your server Event Log as well as you will experience a reduced latency and an improved throughput.

6Sep/111

Fix it – SharePoint Server Search doesn’t crawl/ index Project Server 2010 PWA content.

Posted by Joy

I have been working with Element K team on supporting their new Microsoft Project Server 2010 – Project Web Access course development. They have setup a new Project Server 2010 server with PWA and have been facing issues with Search using PWA portal. In simple, they were getting no records found response when they search for an item which is already available in their portal.

I have been asked to support them and volunteered for the same.

  • First things first. I went and logged into SharePoint Central Administration website and checked "Services on this server" page and found out that SharePoint Server Search is not running. I navigated to "Manage service applications" page and created a new "Search Service Application" and an associated proxy.
  • Configured Crawling and executed a Full Crawl immediately. It indicated 4 successes and 1 error. When I checked the error, it stated that "http://[servername]/PWA - The SharePoint item being crawled returned an error when attempting to download the item." I didn't understand what was it and did some searching and found out a very nice helpful blog post - http://blogs.msdn.com/b/maulikr/archive/2011/06/15/project-server-2010-how-to-configure-search-for-pwa-sites.aspx.

As per the MSFT blog post, SharePoint Search Service doesn't index PWA content automatically without doing some Registry tweaks. To resolve this we will need to change the registry key value for the "UserAgent" in SharePoint Server. The original value for "UserAgent" key is "Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" and we need to change it to "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; MS-RTC LM 8; Tablet PC 2.0)".

  • Open the registry editor by executing regedit in Start -> Run.
  • Navigate to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager" folder and locate the "UserAgent" key. Right-click the "UserAgent" key and modify the value to read as "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; MS-RTC LM 8; Tablet PC 2.0)".
  • Restart the SharePoint Server.
  • Reset the Search Index.
  • Run a Full Crawl again.

Now we should be able to see that PWA content spitted into Search Result page in PWA portal.

6Aug/114

Fix it – Office Web Apps couldn’t open the document for viewing because of an unexpected error

Posted by Joy

I tried Office Web Apps with SharePoint 2010 when the product was in beta and I was thrilled with the features introduced. I also setup a virtual machine with SharePoint 2010 and Office Web Apps on the very next day after they released the RTM bits of SharePoint 2010 and Office Web Apps. I did few articles on the same topic using that virtual machine and recently I updated it with Service Pack 1 bits.

I applied SharePoint Foundation 2010 SP 1, SharePoint Server 2010 SP 1 and Office Web Apps SP 1 and I tried opening a Word document using browser and then boomed. I got the following error when I try to open a Word document within browser. The error says "Word Web App cannot open this document for viewing because of an unexpected error. To view this document, open it in Microsoft Word".

Office Web App error

Office Web App error

Usual troubleshooting exercise started by going to ULS logs. ULS logs stated that Word Viewing Service cannot access the database server and also it stated that App Pool account doesn't have write permission to C:\Windows\Temp directory. Next, I checked the Windows Event Viewer and it also stated that the database server is not accessible and the related content database is not accessible by the App Pool account.

I went and checked the SQL Server security and found out that App Pool account already has been given right set of permission and then checked the file permission to C:\Windows\Temp directory. What I found out was that write permission was assigned to a group called WSS_ADMIN_WPG and when I checked closely I saw that my App Pool account was part of the same security group. Then where was the issue?

I started Googling and found out that some of the users encountered this when you have Active Directory also running in the same machine. Then I found out some PowerShell scripts from http://www.dilukj.com/2011/04/setup-office-web-apps-for-sharepoint-2010/ to configure Word Viewing Service and PowerPoint Service Applications to disable Sandboxed execution which is preventing Office Web Apps to function properly in a machine in which we have both Office Web Apps and Active Directory configured.

I ran those commands there was no luck and then I was breaking my head for few minutes to find out why is this happening? Then I remembered that I have another service account which I have configured to run all the Service Applications in my farm and I went and checked SQL Server security again for the content database for the same account. Damn, that account didn't have access to the content database. I added the same service account which I have configured to run all my Service Applications as a new login to the content database and assigned the "db_owner" role.

Wow, Office Web Apps started working nicely as I expected.

I thought of sharing this experience so that when you get the above error, now you now what are the things you need to check to fix the problem.