Feb 13, 2013

Office Web Apps problems with 100% CPU

I had a problem trying to use Office Web Apps with SharePoint 2010 on a virtual machine demo.  On a simple Word document, the AppServerHost.exe service would jump to 100% and render the system unusable.

The problem is that Office Web Apps was not designed to be installed on a system that is also a domain controller (the case with my all-in-one virtual machine).


http://blogs.msdn.com/b/scicoria/archive/2011/04/14/getting-office-web-apps-to-run-on-a-domain-controller-appserverhost-exe.aspx

http://blogs.msdn.com/b/opal/archive/2010/04/25/faq-sharepoint-2010-rtm-installation.aspx

Here are the steps to fix the configuration:

Open SharePoint 2010 Management Shell, then run:

#Enable Word Web App (you can search by TypeName - language dependent or DisplayName - as it appears in SharePoint Central Administration)

$e = Get-SPServiceApplication | where {$_.TypeName.Equals("Word Viewing Service Application")}
$e.WordServerIsSandboxed = $false
$e.WordServerIsSandboxed

#Enable PowerPoint Web App - you need to answer "Y" for each command:
Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedViewing $false

Get-SPPowerPointServiceApplication | Set-SPPowerPointServiceApplication -EnableSandboxedEditing $false

On the server, use Notepad to open c:\windows\system32\inetsrv\config\applicationHost.config.  Add the line below at the end of the dynamicTypes section.
<add mimeType="application/zip" enabled="false" />

Feb 10, 2013

Empy SharePoint Search results

We had this problem using the combination of SharePoint Foundation 2010 with Search Server Express 2010 where the results would come back empty.

The logs showed some errors with a SOAP request including an exception in: Microsoft.SharePoint.SPUser.get_Sid()

I remembered that we had moved this SharePoint installation from one domain to another and had to do some database tinkering of the UserInfo table (not recommended) after SP-MoveUser didn't quite get the job done. So I did the following:
  1. A quick listing of logins and their SID via PowerShell of all users of the root SPWeb object. Sure enough, the problematic migrated users showed a null SID. 
  2. A listing with the RawSID field showed that these users had an SID, but its format was very different from other valid SID's.
  3. I edited the UserInfo table (not recommended as it got us here in the first place) and updated the t_SystemId field to a valid SID with "Update UserInfo t_SystemId = CONVERT(VarBinary(512),"0x150049595959994939")) where t_Login = "domain\baduser". It's important to insert a unique SID (copied and modified from another user) as the t_SystemId column has a Unique index on it.
  4. After that, I did a full crawl and it seemed to find results in the search administration page. BUT THE RESULTS IN SHAREPOINT WERE STILL EMPTY!
  5. A Google Search found a tip (http://go4answers.webhost4life.com/Example/foundation-server-2010-search-returning-30817.aspx) : the URL's in the search content source must be the same as the default site URL (not the intranet, public or external URL's).
  6. Changing the content source URL fixed the problem.