SharePoint Indexing - mssdmn.exe is using 100% CPU

After experiencing a slow SharePoint system it was discovered that the process mssdmn.exe was consuming all available CPU. (Frontend and Indexing service on same server)

SharePoint indexing was correctly configured, and performance configured not to use all CPU…

The resolution in this case was to install the latest IFilters for Office from Microsoft and the latest IFilter for Adobe PDF from Adobe (Version 8 and 9 has also support for for 64-bit systems)

Note: To compare Foxit and Adobe see the “Jie Li's GeekWorld (BLOG)”

After installing the filters, and changing the ObjectID in registry for PDF files (See documentation at Adobe (Page 2)) The process started indexing, and stopped consuming CPU after the indexing tasks were finished…

No need to restart the server, just restart the Search Service and the IIS

• net stop ossearch –> net start ossearch
• iisreset /noforce

Reminder – Disable Loopback Check

Posting this to remind me that this has to be done to successfully debug SharePoint locally…

When running IIS and logging on locally to a site that uses Integrated Security (Most SharePoint installations do) You must logon to the site.

This is a security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.

To disable this feature you must edit Registry (Windows 2008 Server) or you can use a Microsoft Utility (Fix it) (Currently the Fix it application does not run on Windows 2008 R2)

Read more at Microsoft (You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version)

Using Regedit:

Insert a DWORD Value named DisableLoopbackCheck and set the value to 1

Error when opening a list in Datasheet View

“Access web datasheet is attempting to retrieve data from a different domain…”

When seeing this error message I first thought of cross domain access using JavaScript.

By checking the field types of the dropdowns that did fail I discovered that the only fields that failed was lookup fields that uses other tables as data source, other dropdown menus that where static worked fine. The lookup fields returned blank in datasheet view, but worked  in a normal list view.

By examining the links that the site presented I saw a combination of links pointing to different server names. ex: the user entered intranet in the address field in the browser and some links where pointing to the server name (Without the domain suffix or zone)

The problem: Alternate Access Mappings were not configured for the alias intranet. Therefore the server returned different links. And to my understanding this was the case for the error message, and the empty lookups.

The Solution: Add a internal URL in the Access Mappings located in the SharePoint Central Administration->Operations->Global Settings->Alternate Access Mappings that points to the alias (intranet)

After adding a new url to the access mappings the datasheet view returned correct values in the lookup fields.

Can not enable anonymous access for internet zone

Just to clarify the relationship between alternate access mappings host headers and SharePoint Zones…

While configuring multiple frontend servers and different zones, including Internet. I discovered that I could not set the anonymous access to my site in the Internet Zone.

What puzzled me was the fact that I could not set the anonymous access rights on the site after enabling anonymous in the Zone. The choices were all disabled. (_layouts/setanon.aspx)

Not having my mind correctly set I missed the fact that I was configuring the site collection using a url that was NOT configured for the Internet zone. I was only configuring using the default zone (or the server name as host to be specific)

The host header and the alternate access mappings is the only link that SharePoint has to discover that the site actually is in a zone. It all makes sense, but when you are configuring your site before the DNS entries are set you may stumble on this little problem…

By using the correct hostname, that is referring to the internet zone in my browser it all worked out.

ASP.NET error after installing a SharePoint WFE

After installing a new SharePoint Web Frontend you  receive a “normal” ASP.NET error message the address in the browser will point to the _Layouts “directory”, so SharePoint is in play.

When studying the event log the message contains “Could not load file or assembly RSSharePointSoapProxy…”

This is a Assembly that is used by the SQL Server Reporting Services Integration for SharePoint.

The problem: Reporting Services is installed on the SharePoint Farm and the binaries does not exist on the new frontend server.

Solution:

Start by downloading the Microsoft SQL Server Reporting Services Add-in for Microsoft SharePoint Technologies for SQL 2005 or SQL 2008 (May 2009 release) (SharePointRS.msi or RSSharePoint.msi)

Note: The description below is based on the 2008 version of the Add-in

Do not run the MSI as a ordinary setup process, this will result in a error message in the event log and a rollback of the package. The error indicates that the SERVERNAME$ can not logon to the database.

Start the MSI with the parameter SKIPCA=1 this will extract the file rsCustomAction.exe to the TEMP folder of the current user.

To install the binaries and configure the Reporting Services run rsCustomAction.exe /i

Be sure to run as a user that has rights to the SharePoint Site Collection.

After the executable finishes your new SharePoint Front End should display the SharePoint sites normally.

By running this application the Solution will be redeployed on the existing servers as well, even upgraded if possible.

For more information see the readme bundled with the Add-in

Access denied when configuring SharePoint WFE

When adding a new Web Front End Server to a SharePoint Farm you may get a access denied error in step 2 when connection to the configuration database. This error will occur regardless of the configuration entered before the configuration begins. (The search for configuration database is successful.)

Before starting SQL Management Studio or another tool to check permissions on your database server. Check the version of the existing SharePoint environment.

You will get this error if the new SharePoint server binaries is another version than the existing system. Remember to update the SharePoint installation (Both WSS and MOSS) before running the SharePoint Products and Technology Configuration Wizard.

Refer to the SharePoint AdminWiki to get your SharePoint Version.

Error when configuring SharePoint Services Search Service

You probably know this already this is just a notice to self :-)

When configuring a SharePoint Services Server running everything locally you normally specify the user accounts only by the username during the installation and configuration.

When looking at the Services in the server you notice that there is one service that is not starting. The “Search Service”. You click on the start link and the configuration page pops up. You enter all the user settings and click on start. After a second or two a rather generic error message appears SPSearch(Username).

After rechecking passwords and usernames you try again, with the same result…

The problem is that the “Service Account” username must have domain\user or server\user syntax (server\user in this case)

The “Content Access” Account can be specified using the username only (But it does not hurt to add the server name as well)