SharePoint 2010 – Office Web Apps Cache Expiration

I was doing some browsing around a SharePoitn 2010/Office Web Apps-Enabled farm the other day and noticed something interesting that I thought I’d share. By default when you setup Office Web Apps in SharePoint 2010 the cache expiration does not get set in the web app’s property bag.

I started by checking the web app cache URL’s propery bag items. As you can see there is nothing related to cache expiration:

After this I went ahead and set the max size/cache expiration for the Office Web Apps cache URL and then checked the property bag items:

Notice the waccacheexpirationperiod entry now!

 

-AJB

Document Inventory PowerShell Script

The other day I had a request to get a list of all documents in a web application and some information about each document. From here I was able to open the file in Excel and create a PivotTable of each site collection, site, and library, and get counts of the versions and unique permissions for each. In this case a few of the libraries were approaching the 50,000 unique security scope limit in a list/library…be careful of that limit (Described here: http://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#ListLibrary)! Here is the script:

Additional Notes:

Site Owners PowerShell Script – Kind Of

I was asked to come up with a script to generate the site owners for all the sites in a specific web application recently. I didn’t have much time to put anything together too fancy so I came up with this script. It looks at each SPWeb object and determents the users in the associated owner group for each SPWeb (SharePoint sub site).  This doesn’t take into account anyone who may have been granted full control explicitly and the $web.AssociatedOwnerGroup may or may not be correct..In this case it was. Hopefully this helps you out..or even provides a starting point to what you are trying to report on.

 

Additional Notes:

  • This script causes additional overhead on the SharePoint farm and should be ran in off hours. This sends a lot of requests to the database
  • Copy everything from function to the last “}” to load the function. Once the function is loaded you can run it using the last line of the script “GetSiteOwnersReport”
  • This does NOT take into account unique permissions. It only looks at the AssociatedOwnerGroup members for each SPWeb object

Cannot Activate Site Feature for SharePoint Publishing – Dang that pages library!

They other day I went to activate the Site (SPWeb) level publishing feature and I ran into an error. I tracked it down in the ULS Logs and found this entry:

08/13/2014 11:15:04.24 w3wp.exe (0x4D94) 0x4E50 SharePoint Foundation General 75fg High Exception was thrown while ensuring dependencies met for feature ‘PublishingWeb’ (id: 94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb): Microsoft.SharePoint.SPException: List does not exist. The page you selected contains a list that does not exist. It may have been deleted by another user. —> System.Runtime.InteropServices.COMException (0x81020026): List does not exist. The page you selected contains a list that does not exist. It may have been deleted by another user. at Microsoft.SharePoint.Library.SPRequestInternalClass.GetListsWithCallback(String bstrUrl

I did some digging and found 2 good links on the matter:

The following script worked for me. Note: I have ran into this issue multiple times and the main culprit is that the Pages library (Or another publishing library) is already created when you go to enable the SPWeb SharePoint Publishing Feature. You could use PowerShell or SharePoint Manager to delete those lists. Or even to update the pages library for the SPWeb object, but this script is much easier :)

Also, there was one instance where this script did not work and I needed to run the Enable-SPFeature cmdlet and use the -Force parameter. Once I did this I ran the script below and then everything started working.

 

 Update (10/29/14) – I have ran into this issue multiple times in the same environment now. Even though the above scripts fix the feature activation, the easiest fix has been to just deactivate and reactivate the SharePoint Publishing Infrastructure Site Collection Feature. This company is using a custom master page which needed some fixing up (Reactivating the site collection feature seemed to make the necessary changes).

KB2775511 – Blowing up my Usage Data Import Timer Job

This issue is described here: http://support.microsoft.com/kb/2916922 

This patch (along with  KB2682011 or KB2882822) could cause the Usage Data Import timer job to not import the .Usage files into the Usage Logging Database. When this timer job runs you will notice the following in the ULS logs:

OWSTIMER.EXE (0x51A0) 0x59E4 SharePoint Foundation Usage Infrastructure a5rv High Failed to delete usage log file ‘E:\Logs\ServerName-20130701-2117.usage’ after data import. Exception: System.IO.IOException: The process cannot access the file because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileInfo.MoveTo(String destFileName) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.MoveFileOrDirectory(FileSystemInfo fi, String newPath) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DeleteFileOrDirectory(FileSystemInfo fi) at Microsoft.SharePoint.Administration.SPUsageLogImporter.ImportUsageLogFiles(List`1 usageLogFileList)

This causes a few unwanted side effects: The usage logs will grow as they are not getting imported and purged and this timer job will take a looong time to run and can cause your timer service recycle timer job to fail. I was manually restarting the timer service each day for a while, but we ended up uninstalling the patch as a longer term solution. This issue is fixed in the December 2013 CU, but that was not an option in this case.

This is why I always recommend you have a test environment…This was caught before it got pushed to PROD!

-AJB

SharePoint List Error – Exception from HRESULT: 0x80131904

Short version – This was fixed with the following procedure:

  1. Go into List Settings for the list in question
  2. Under columns I clicked the Column Ordering link
  3. Changed Title’s position from Top to be 1 (It was 2 from the top in my case)

Explanation – This list had a lot of columns (60 to be exact). After further research there’s something unique that happens when you have 16 columns in a list. Any time someone creates 16 columns in a list and then sets any column that was created in position 16+ to position 1 (It doesn’t matter the type of column) in the list you will receive that error.

Technical Explanation:  The problem here is because SharePoint utilizes SQL server row wrapping to allow a maximum number of columns in a SharePoint list where SharePoint Server will create several rows in the database when data will not fit on a single row. This is controlled via the property RowOrdinal, which identifies which row a certain field should be stored. When RowOrdinal = 0, the field is stored in the first row of the row set for that list item and when RowOrdinal = 1, the field is stored in the second row of the row set for that list item.

Lets take a look at this in action:

  1. Save list as template, open Manifest.xml
  2. Find the <Fields> Section (Notice The RowOrdinal values??)<FieldName=”Test_Task” Version=”2″ DisplayName=”Test Task” Type=”Choice” RowOrdinal=”1″ ColName=”nvarchar35″ StaticName=”Test_x0020_Task” SourceID=”{f62365c4-32fa-4f67-a714-963aa49a3f8a}” ID=”{402b7fff-701c-45b4-bc06-ffaf51dd3fe8}” FillInChoice=”FALSE” Format=”Dropdown” Indexed=”FALSE” EnforceUniqueValues=”FALSE” Required=”TRUE”>

    <FieldName=”Title” Version=”2″ DisplayName=”$Resources:core,Title;” Type=”Text” RowOrdinal=”0″ MaxLength=”255″ Indexed=”FALSE” EnforceUniqueValues=”FALSE” ColName=”nvarchar1″ FromBaseType=”TRUE” StaticName=”Title” SourceID=”http://schemas.microsoft.com/sharepoint/v3” Required=”FALSE” ID=”{fa564e0f-0c70-4ab9-b863-0177e6ddd247}”/>

Errors in ULS Logs:

System.Data.SqlClient.SqlException: Cannot insert the value NULL into column ‘tp_DocId’, table ‘SP2010_Content_10030.dbo.AllUserData'; column does not allow nulls. INSERT fails. The statement has been terminated.

This issue is similar to http://blogs.msdn.com/b/allenwang/archive/2012/05/21/sp2010-survey-list-error-and-event-id-5586.aspx

SharePoint Error – Database is too old and upgrade is required

I was recently working on a SharePoint Migration Project where we migrated from a SharePoint 2010 farm to a shiny new SharePoint 2013 SP1 farm. Some of the sites were to stay in “2010 Site Collection Mode” until the site owner was ready to upgrade and others were upgraded to 2013 right away. Below is a screenshot or Central Admin showing the database upgrade status for 3 content databases:

  1. The top database was completely upgraded to 2013. Looks beautimus!
  2. The middle database has some sites upgraded and others in 2010 mode…Looks OK..
  3. The bottom database SHOULD have some site collection in 2010 mode and others in 2013 mode just like the middle database. Something looks off here right? Running the Upgrade-SPContentDatabase cmdlet did nothing and PSConfig did nothing.

CADBTooOldError

Looking at the eventvwr Application Log shows some interesting new errors:

eventvwrdbtooolderror

Nothing has changed in the farm from a SharePoint Server perspective…I was able to run the Get-SPContentDatabase command on each content database in this state and get back the appropriate webapp object for each. When clicking the content database anywhere in Central Admin I would get the error “Object Reference not set to an Instance of an Object” and this was causing other errors in the environment:

  1. Alerts were not working
  2. Issues with editing files/check-in and check-out
  3. Not able to select any site collection in Central Admin

Users could still get to the site collections…The experience just wasn’t optimal. I took a look through ULS, Eventvwr, and SQL Logs and couldn’t find anything besides a larger stack trace for the Object Reference Error and not much else.

Something happened between this content database and the SharePoint server causing the database to be in this funky state. PowerShell to the rescue!
The Fix: Running the Dismount-SPContentDatabse and Mount-SPContentDatabase fixed the issue.

For example:

SharePoint – Query User Information List in SQL

NOTE: DIRECTLY querying any SharePoint SQL database is NOT SUPPORTED (Except the Logging Database). If testing the query below I’d recommend backing up and restoring the content database to a different SQL Server (Non SharePoint and Non Production) and running through this.

Now that we got the disclaimer out of the way, here is the background –  I was working with Microsoft on a support issue which involved user accounts not showing up in the User Information List correctly. Here’s a SQL script that Microsoft provided that helps query this information in SQL.

Replace the sitecollectionurl with the site collection URL and ADAccount with the samAccountName in question. This will return quite a bit of information about that user in the specified site collection.

SharePoint – Publishing Site Collection Features Enabled and then Disabled. Save Site As Template is gone!

I ran into an issue recently where we enabled the SharePoint Server Publishing Site/Site Collection features and then disabled them at a later time. Microsoft doesn’t allow Publishing sites to be saved as a template per: http://support.microsoft.com/kb/2492356

When you disable the site collection/site feature it SHOULD bring back the Save Site as Template option, but in my case it did not. I tried enabling and disabling the feature a few times, but no such luck. PowerShell to the rescue!

Run the following script to bring back the Save Site as Template Option (Make sure you have already disabled the Publishing site collection feature):