SharePoint Admin Tool Belt Addition – C2WTS Troubleshooting

I was troubleshooting an issue with the Claims to Windows Token Service the other day and found a great tool to assist. I was working in a SSRS integrated environment configured with Kerberos and was getting the error “Cannot convert claims to windows token” when configuring a data source to test against. The issue was that the C2WTS service account was not in the local admin group. I had requested this access, but in this environment the local admins were all in an Active Directory Group and I did not have permissions to confirm this and adding the account in local admin explicitly was whipped out with Group Policy. Anyways, enough about the issue..the awesome tool is at and is called c2WTS tester

Add it to your SP Admin tool belt!


Office Web Apps 2013 Moved to VLSC…Where are you?

Many of you have probably read that Office Web Apps Server 2013 has moved from the Download Center to the Volume Licensing Service Center(VLSC) from here (Evaluation availability is still available on MSDN for subscribers ):

Recently I went to the VLSC site ( and did a search for Office Web results. I did a search for Web results. After calling the VSLC phone number they indicated that the Office Web Apps Server 2013 install is located under the Office Professional Plus 2013 (and Office Professional Plus W/ SP1) download.

Just another day in the life..

Office Local Drafts Issue/ULS Logs…Can I see a Check-Out

Hey All – I ran across an interesting scenario with one of our clients last week that I thought would be useful to share. They were having issues with Office 2007 and SharePoint 2010. For some reason every now and then a highly edited document would revert back to a previous version. After this happened users continued to collaborate on that document until someone noticed that they’re changes weren’t saved from their last edits. After this happened I was brought in to take a look and see if I could find out what was going on here…

Some background – Office 2007 and Office 2010 have 2 different defaults (At least the base installs at this client did) for how to handle the check out of a file.

  • Office 2007: Defaults to “Use my local drafts folder”
  • Office 2010: Defaults to “The Office Document Cache”

We noticed this specific issue was happening because the users were using the local drafts folder and were not checking the file back in. With Office 2010 you get a nice little pop-up (With Office 2007 you do NOT):


The client went ahead and applied the group policy settings stated here (Thanks Joran!):

Now that we have the issue fixed the client wanted a little additional follow-up. They wanted to see what information the “logs” would provide us if this were to happen again. This client had all of the default ULS logging settings turned on. I was able to track down the last time this happened in the ULS logs and I could only see the user accessing the site, not much else. Once I turned on verbose logging I could see the following entry:

“Performing lock of checkout operation for documents/SPTestDoc.docx. Lock Flags = 5. Lock Id – . Lock timeout = 0.

The audit logs and IIS logs can show the user accessing the file, but we do not know if they checked it out, overrode a checkout, etc. I am not advising anyone to turn on verbose logging 24/7..This will most likely fill up your data drive (Hopefully you are putting logs on a secondary/Non-OS drive) and should only be used in troubleshooting. It is definitely good to know that the defaults do not “capture” a checkout and that verbose logging will need to be enabled for the entry above to show in logs.


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!



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:! 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: 

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!


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=”” 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

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.


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


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: