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.