When running Enable-SPFeature, you may get the weird error:

“Enable-SPFeature : The file is currently checked out or locked for editing by another user.”


One possible cause of this issue could be that some file(s) the are deployed by the feature could be checked out by a user.

Checking the ULS logs you could find something like


Instantiating module “NAMEOFMODULE”: File could not be added at URL “FILENAME.jpg: Error 689225296 99e77593-d0d4-49df-adcc-c8f8251fbb82
04/06/2017 20:53:42.02 PowerShell.exe (0x107C) 0x1334 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (SPSqlClient). Execution Time=11589.5652 99e77593-d0d4-49df-adcc-c8f8251fbb82
04/06/2017 20:53:42.02 PowerShell.exe (0x107C) 0x1334 SharePoint Foundation General 8kh7 High The file is currently checked out or locked for editing by another user.<nativehr>0x80070021</nativehr><nativestack></nativestack> 99e77593-d0d4-49df-adcc-c8f8251fbb82
04/06/2017 20:53:42.03 PowerShell.exe (0x107C) 0x1334 SharePoint Foundation General aix9j High SPRequest.EnableModuleFromXml: UserPrincipalName=i:0).w|s-1-5-21-995927836-1113283497-4239367599-17896, AppPrincipalName= ,bstrSetupDirectory=C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\Template ,bstrFeatureDirectory=Features\ABCDEP ,bstrUrl=,bstrXML=<Module Name=”images” Path=”Style Library\images” Url=”Style Library/images” RootWebOnly=”TRUE” xmlns=”http://schemas.microsoft.com/sharepoint/”><File ReplaceContent=”True” Type=”GhostableInLibrary” Path=”favicon.ico” Url=”favicon.ico” /><File ReplaceContent=”True” Type=”GhostableInLibrary” Path= ,fForceUnghost=False ,pModuleContext=<null> 99e77593-d0d4-49df-adcc-c8f8251fbb82
04/06/2017 20:53:42.03 PowerShell.exe (0x107C) 0x1334 SharePoint Foundation General ai1wu Medium System.Runtime.InteropServices.COMException: The file is currently checked out or locked for editing by another user.<nativehr>0x80070021</nativehr>

We had a very weird issue today with a SharePoint publishing site. Some js and css files (which were deployed as part of a WSP) were not updated in the publishing zone.

When checking from the authoring zone, everything looked ok: the latest file was published and approved (was v1.0 since it was deployed as part of a solution). In the publishing site though, for end users, We were getting an older version of the file.

Tried clearing browser cache, close and open browser, use in-private browsing, resetting IIS, restarting server, restarting client machine, nothing worked.

After a lot of investigation and trials and errors, the issue turned out to be caused by the BlobCache. When we disabled the blob cache in the publishing zone, latest files started to work fine. With Blob Cache enabled, we were getting an older version.

For some reason even flush cache powershell command didnt seem to fix this issue. We had to disable the blobcache in the web.config for the publishing site and then manually delete the blob cache files. We then enabled blobcache again and things seemed to work fine.

More details about the nuts and bolts of BlobCache (long but interesting read) can be found at: https://sharepointinterface.com/2012/03/12/do-you-know-whats-going-to-happen-when-you-enable-the-sharepoint-blob-cache/ 


A new tool by google to test how mobile friendly is a web site: https://testmysite.thinkwithgoogle.com


Just came up across this very useful post : http://sadomovalex.blogspot.ca/2015/08/fix-problem-with-returned-xml-instead.html

It shows how to use JSON light with SP2013 SP1+.


If all SharePoint sites are returning 404 errors, including Central Admin site after a fresh installation. the problem might be the IIS setting about unlisted file extensions.

To check if this is the case:

Enable IIS logs and check the sub status of the 404 error.

If the sub status is 7 (i.e. error is 404.7), then check the IIS config file located at C:\Windows\System32\inetsrv\config\applicationHost.config

look for the segment

<fileExtensions allowUnlisted="false" >
and change it to
<fileExtensions allowUnlisted="true" >

this setting (false) basically only allows IIS to return the specified file extensions and will block any other files. Setting it to true may fix the 404 error.


The list/library template you just created by saving List or library as a template is not showing up when you try to create a new list/library based on that template.


One thing to check first is to go to the List templates Gallery (Site settings-> List templates under web designer galleries).

If the template in question does NOT have product Version and Feature ID assigned. Then the problem might be that the ParserEnabled property is set to false on that site.



Using PowerShell , set the ParserEnabled property to true.

$web = Get-SPWeb <url of web>
$web.ParserEnabled = $true


Reference: https://support.microsoft.com/en-us/kb/2779729


Thanks to


When Creating an Office 365 SharePoint site, you might want to turn on custom Scripting.

Steps here: https://support.office.microsoft.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f?CorrelationId=365c212d-8b7e-45b9-b285-84416dd95952&ui=en-US&rs=en-US&ad=US


With Custom Scripts turned off you might experience some weird behavior like:

  • Content Types and Site Columns Galleries are not showing up in the Site Actions menu.
  • When Mapping a SharePoint Library to a local drive, you might get Access denied errors when trying to upload files.
  • CEWP and Script editor web part might be missing from the Web parts list when editing a page.