SharePoint files moved into root folder

Tech Trek – 2016 January

Users reporting that files are missing in their respective child folders, and eventually being moved into the root folder of the document library.


  1. Identify if the affected SP 2013 site/library is being accessed via SharePoint Workspace (formerly Groove) client and your content is not over these file restrictions.
  2. Make sure that the following patch is applied for Workspace 2010 client
    SharePoint Workspace 2010 hotfix – February, 2012
  3. To temporarily address the automatic transfer into the root folder –
    Set Offline Client Availability to No under Advanced Settings for the affected Document Library.Missing-Files-Offline



MS Excel Add-Ins

Tech Trek – 2016.03.14

One or more MS Excel COM Add-Ins are not loaded correctly even after enabling items in Excel Options dialog.


  1. Check whether the add-in is listed under Disabled Items in File … Excel Options.


  2. Otherwise, open registry editor and find the affected Add-Ins in the following registry key path. Change the LoadBehavior value data into 3 (Load at Startup).


Make registry updates with care since changes can render your system into an unusable state. Make sure you have a system restore point, or necessary backup before doing changes.

SharePoint Foundation compatible application could not be found.

Tech Trek – 2014.02.13

Recently, our remote users have been frequently getting the following issue when opening Microsoft Office documents within SharePoint.

In Word Web App,
“To open this document, your computer must be running a supported version of Microsoft Word and a browser that supports opening files directly from the Office Web Apps.”

In Excel Web App,
“To open this workbook, your computer must have a version of Microsoft Excel installed and your Web browser must support opening files directly from Excel in the browser.”


I’ve outlined how to troubleshoot the issue so that hopefully you wouldn’t get crazy in attempting to decipher the misleading message and find out what happened to the user’s PC.

Note, we have the following basic assumptions —

  • Microsoft Office was installed in the first place.
  • Internet Explorer 7 (32-bit) or higher is used. Non-IE browsers will open files locally by default and results into the error message below.

First, try opening the affected file using Edit in Microsoft Word (or Excel) from the list item menu. If you get the following message, then, it confirms that this isn’t just an Office Web Apps issue.

SharePoint error

Second, try opening another document with a different file format, e.g. PDF document, or ZIP file. Then, open Microsoft Word/Excel application and load the document by accessing the site URL directly.

If you were able to succesfully open files from SharePoint, proceed to the steps below.

  • Open Tools … Manage Add-ons in Internet Explorer
  • Make sure that the following SharePoint add-ons are enabled especially SharePoint OpenDocuments class.


Most of the time, this will resolve the issue. Close and re-open the browser window to load these add-ons properly, then, try opening Office documents again.

Third, open Office Upload Center via Taskbar icons, or from Microsoft Office –> Office Tools in the Start Menu. Check if there are Pending or Cached Files that have failed recently from the list. Follow the steps below to delete cached files:

  • Click Settings and select Delete cached files button. Try to re-open the document to see if it helps. I’ve found most of the time this doesn’t properly delete files in the hidden folder.

Lastly, the following steps should be performed by technical personnel since it involves a couple of steps.

  • Exit SharePoint Workspace from Taskbar icons.
  • Start Task Manager and click End Process for the following: MSOSYNC.exe, MSOUC.exe, or GROOVE.exe (if SP Workspace is still available).
  • Open Windows Explorer and proceed to Users folder in your local hard drive. Make sure that hidden files is selected under View tab of Folder and search options.
  • Expand to the following location —
    \Users\<userId>\AppData\Local\Microsoft\Office\<Office version>\OfficeFileCache
  • Delete the entire folder.
    Close any Microsoft Office applications if you’re unable to delete the folder successfully.

By this point, most of the issue should be resolved. A workaround that you may instruct end-users is to open files via Open with Explorer under Library ribbon menu, or use SharePoint Workspace to open the site.

InfoPath template publishing issues

Tech Trek – 2012.01.22 Sunday

I’ve recently updated an InfoPath form template for a project and ran into the following Microsoft Support issue KB2554288.

Columns published from InfoPath fields are recreated when the same InfoPath form template is re-published to more than one document libraries in a SharePoint site

I read this knowledge base article after I had already re-published the InfoPath template into a second form library so I can test” the changes before applying them in production. In my case, I’m not re-publishing the template as a Site Content Type, or creating Site Columns.

I proceeded to delete the second library even before re-publishing the production form template. As mentioned in the article, the promoted columns were re-created when publishing a form more than once within the same SharePoint site. In my situation, this resulted into the following issues to the original form library:

  • Promoted columns were removed in list views
  • Calculated columns resulted into invalid values (#VALUE) even if column names are the same
  • Custom workflow lookups didn’t resolve the promoted columns

Luckily, my form was not too complex but I had to perform these steps to correct the form library:

  • Re-create the list views
  • Re-create the calculated columns
  • Modify custom workflows in SharePoint Designer and later re-published them to the site

It was a good thing that I had backup of the configuration settings so I will able to re-create them as needed. Thus, it would be nice to have a SharePoint tool to create documentation about  configurations. Also, the ability to restore custom workflow would be helpful in case of a worse-case scenario of re-creating the library or list.

The intent of this post is to shed light on some of the nuances of InfoPath development as compared to the traditional deployment procedures into a test or staging environment. Thus, it introduces additional work for SharePoint Administrators when applying “change control” practices and poses a challenge when trying to adhere into legal compliance scenarios.

It does take a different mindset coming from strict software configuration management (SCM) principles in my previous work experience. What we’ve done in our organization was to store application configurations in transactional database tables and XML files coupled with version control system which made auditing changes more feasible.

Disable or hide SharePoint “Send To” and “Open with Explorer” menu options

Tech Trek – 2011.08.15

I was building an InfoPath form that requires security from certain users of the solution. One of those involve preventing access to the following context menu and ribbon menu options:

  • Send To … Download a Copy
  • Open with Explorer

Unfortunately, these options becomes a loophole if they are available for the security mechanism that I was planning to enforce through browser-based form services. Note, configuring the “Default open behaviour for browser-based documents” in Advanced settings of form library doesn’t prevent a user from selecting the “Edit in InfoPath” option from item menu.

Downloading a local copy allows the end-user to see any restricted views while allowing the “Open with Explorer” option opens the WebDAV folder that could give access to other files in the form library. Not good!

As I conduct my research, it’s amazing how many programmers came up with different solutions to resolve such issue. Although, some are simple to implement one key criteria that I had in mind is a “no-code” solution since that is what SharePoint offers in the first place. So with that principle applied, I ended with configuring the permission levels to disable or hide such menu options in both the 2010 ribbon menu and item dropdown without opening SharePoint Designer that could affect any future upgrade issues.

Note, I’m not going to provide the steps here since most SharePoint administration references would walk through such configuration but the key site permission options to note are the following:

  • Use Remote Interfaces
  • Use Client Integration Features (removes Edit in … option)

The best practice is to copy a default permission level and remove the particular permissions that you want to exclude. Just a reminder that disabling the above permissions may include other features that you may want for your site so make sure to “test early and test often” with different accounts that would use the system. Lastly, I created a separate list view page that is similar to the All Items view in a secure document library so that only site administrators have access to it for additional security measures.

The end result, problem solved without custom coding.

Technet User Permissions and Permission Levels (SharePoint 2010)
Technet Configure custom permissions (SharePoint 2010)