Solution for SharePoint incompatibility with Chrome

Solution for SharePoint incompatibility with Chrome

There have been a number of issues relating to how SharePoint behaves within Chrome. Most relate to legacy applications. These include SilverLight and ActiveX controls.
One significant issue is that Chrome won’t open InfoPath Filler forms in InfoPath Filler, and instead tries to open it in the web version of InfoPath.

A solution to these can be found in this 3rd party Chrome plug-in: IE Tab

It does have a per-user cost, but it enables IE to activated from within Chrome. One just specifies the URL string pattern that should be opened in IE.

SharePoint 2016 News


Release Candidate is an update to SharePoint Server 2016 Beta 2 and can be installed over Beta 2, so you can upgrade SharePoint Server 2016 Beta 2 to RC.


SharePoint 2016 is planned for release in spring 2016.


SharePoint 2016 is planned for release in spring 2016.

Support for end of life services

  • SharePoint Server 2016 will include the ability to support InfoPath Forms Services. InfoPath Forms Services on SharePoint 2016 will be supported for the duration of SharePoint 2016’s support lifecycle.
  • InfoPath Forms Services on Office 365 will continue to be supported.
  • InfoPath 2013 and SharePoint Designer 2013 will be the last versions of those products. SharePoint Designer is not being re-released with SharePoint Server 2016, although it will continue to be supported for custom workflows built with SharePoint Designer and hosted on SharePoint Server 2016 and Office 365.
  • Support for InfoPath 2013 and SharePoint Designer 2013 will match the support lifecycle for SharePoint Server 2016, running until 2026.

Challenges in SharePoint projects

SharePoint is a great platform for application development. However there exist some challenges that need to be kept in mind during planning, that are common across a range of SharePoint projects. Each topic is worthy of its own article. Some design aspects are easily changed on the fly, while other changes come at a great cost when discovered late, resulting in significant additional effort to remediate; hence having a seasoned architect early on in the design can be very cost effective, and reduce project risk.

Site Topology

The set of Site Collections needs to be designed for scalability and secure isolation. Too often projects attempt to save effort by unnecessarily restricting the system to function within a single Site Collection. Such a design can hit performance and scalability limits of single Site Collections. Peeling apart a Site Collection in a large production farm can be fraught with risk and take significant effort.

Design for upgrades

Design should include plans for upgrading, as patches and new versions come out; not just of SharePoint, but of SQL Server and 3rd party selected add-ons and operating systems.

3rd Party Software Dependency

Purchasing add-ons is often cost-effective and preferable to writing code, however the vendor dependency is a serious issue to be considered, including vendor viability. SharePoint 2013, for example, requires solutions (WSPs) to be rebuilt (using different DLL versions, deploying to a different hive location, using a different .NET version etc). If a vendor is not around when you upgrade, you may be forced to rewrite the application first a different way.

Flexible AMC

The full cost of a system needs to be taken into account, as well as a viable support model, for the AMC (Annual Maintenance Cost). This considers the full cost, not just for development but for Post deployment and Maintenance Support. A proper cost assessment in a business case should take into account a 3 or 5 year cost horizon.


It’s not just the software costs that need to be taken into account, but harware costs as well, even in a multi-tenancy model. Proper costing takes into account the allocation utilized by a proposed system. One should complete an Assessment of the existing Hardware Infrastructure and Environment and provide necessary recommendations for Server Configuration and Farm Topology.


After doing the Requirement Gathering, some thought should be placed on the Governance Plan. This would identify business needs that can be achieved by OOTB features of SharePoint and which would require custom development, how the system would be authorized, users authenticated, policies, procedures, access levels, auditability and the like.

Market Awareness

This circles back to the concept of buy-vs-build. Too often developers reach into their coding bag-of-tricks, before considering what exists. All too often I’ve seen web parts written that duplicate what comes out of the box in SharePoint. Awareness of 3rd party solutions is also critical, to managing risk, timelines and project costs. Designers and developers need kept aware about market trends, new release, updates and patches. Senior team members in SharePoint can gain this through conferences, and just plain experience. Certifications are one indicator of knowledge, but that alone may not be sufficient.

Best practices

There is a wealth of knowledge in the industry on best-practices, starting from Microsoft. Development and Implementation should be done as per Microsoft suggested practices, but also considering leading authority opinions.


Architecture and System design is done for scalability and high performance keeping in mind future data size and increase in the number of users. All too often a system that passes a demo, can’t scale to the planned level of usage. This includes handling geographic diversity, and concurrency.

Deployment Model

Now more than ever, the deployment model is key. Where once Sandbox solutions were promoted, these are now deprecated. Where once onPremises was the only option, now the App Model in Office 365 and Azure present not just viable options, but recommended approaches.

Awareness of roles

SharePoint team members should be included with specific expertise including crucially Administration, Development, Branding. A pure development approach may lead to taking a blind alley where a system is not easily maintained, or not easily branded.


Finding real SharePoint talent is a challenge. One needs to be aware that a purely .NET background is useful, but is not the complete skillset needed for successful projects.

How to start?

In short, one has to start and focus on the problem at hand. The solution comes only after the problem is crystal clear and understood. It is all too easy to jump into the technology, but must first start with the problem. One way to look at it is that there is no real solution without a specific problem.

WebDAV crashes using MS-Office and SharePoint with Win7

There is a issue in SharePoint 2010 with WebDAV with Windows 7. Just making my readers aware, in case other users of WebDAV ever encounter versions discarded or hung (spinning circle) when saving a document. I’ve seen in for Office 2007 with Windows 7 with SharePoint 2010. This can occur without required fields on a content type, and appears rarely and totally at random.

In a bit more detail, anytime a user interacts with a file through WebDAV, a local copy gets cached on the disk in the temp location C:WindowsServiceProfiles…) and a reference to the file gets created in WebClient’s internal memory. “interacting with a file” means opening and working with it in Office. It also includes anytime you simply touch the file through Window Explorer – getting its properties, even highlighting it with a mouse click counts. Copies of documents are continually being cached and eventually cleared away – it’s normal WebDAV behavior. Of course, only one cached copy per document is supposed to be in that directory. So, if a user opens a file, makes a change to it but doesn”t save it for a while, then go back to the WebDAV location and “interact” with the file – simply clicking on it once is good enough. Wait a few more seconds, and the next time you go to save you open document, the error occurs. What’s happening is the WebClient is grabbing another copy of the file when you click on it, and throwing away its original internal reference – the reference that represents your open document.

Microsoft just patched the crashing behavior, as part of KB2712435,

SharePoint Database naming

The primary naming convention to put in place is the Database Naming standard.  By default, SharePoint puts a GUID at the end of every database.  This is to ensure that two SharePoint farms can use the same database server without conflict.  However the GUIDs make memorizing a database name practically impossible.  Here are some basic naming conventions to consider adopting:

  • Avoid GUIDs at all costs
  • Avoid blanks
  • Avoid underscores
  • Leave “DB” and “database” out of the name
  • Use Capital Letters to highlight the start of words (CamelCase)
  • Consistent description to allow a database to be clearly associated with a specific Web App, and Service App
  • References to Production vs. Development are not necessary
  • References to SharePoint version are not necessary
  • References to “SharePoint” are unnecessary, especially for a dedicated SQL Server
  • Leave the obscure “WSS” SharePoint convention for content databases, instead use “Content” at the start of the database name.  That’s clearer for DBAs who are not versed in the mysterious acronyms of SharePoint.

Here’s a proposed syntax for structuring database names:

[Major Application][Type] [Minor Application] [Specific]

Component Description Sample Values
[Major Application] Major category of Application [left blank for SharePoint]

MSPS  (for MS Project Server)

 [Type] Category or type of database, based on primary system using the database Content


[Minor Application] Can be Service Application PerformancePoint


[Specific] Can describe each of multiple service app DBs.  Description of use of Content DB for Web App CentralAdmin


Default: Search_Connector_CrawlStoreDB_4040b7300e9e42779edb3e6b926be5a7

New: ServiceApp_SearchConnectorCrawlStoreDB

Default: SharePoint_AdminContent_ff35d171-482c-4f9d-8305-a4a259ec1a15

New: Content_CentralAdmin

Default: wss_content_eaee9d8f-ed75-4a56-bad3-5abf232b4f66

New: Content_ DIV_HR

Default: StateService_0f2a42e8b90d4c60830ca442e753de13

New: ServiceApp_State

Inconsistent SharePoint timestamps with WebDAV

There are situations when moving documents using Explorer mode can retain the correct “Modified” timestamp in the browser, yet show an updated timestamp in Explorer Mode.

This is due to WebDAV showing the date associated with the File (SPFile) rather than the date associated with the SPItem. Explorer mode can update the modified date in the SPFile.

When you probe further, the “Item” has the correct timestamp (item[“Modified”] is in the local timezone. However the SPFile has a property called vti_timelastmodified that has the GMT timestamp.

Note the File has a property called vti_nexttolasttimemodified as well.

Both[“vti_timelastmodified”] and item[“Modified”] are the same type (DateTime) so I can compare them, which is precisely what I did in a special report looking for such timestamp divergence. I generated a filtered report custom written in PowerShell to show files that are more or less than 4 or 5 hours off (depending on the time of year, the hours diverge by either 4 or 5 hours) given my ET timezone. I only look to the “minute” and not the “second” on purpose, so I don’t flag false positives.
Here is how to fix a single instance of this issue:

$docurl = "http ://sharepoint/site/list/TimestampTest/test2.docx"
$site = New-Object Microsoft.SharePoint.SPSite($docurl)
$web = $site.OpenWeb()
$item = $web.GetListItem($docurl)
$list = $item.ParentList
[System.DateTime]$date = $item["Modified"]
$user = New-Object microsoft.SharePoint.SPFieldUserValue($web, $item["Editor"])
$item["Modified"] = $date;
$item["Editor"] = $user;
try { $item.Versions[1].delete() } catch {write-host -foregroundcolor red "Error (1) could not delete old version of $($item['Name'])"}

Here’s a function that reports on all URLs that suffer from this issue.  Note the use of date comparison, and the check for timestamp being off by either 4 or 5 hours, and matching on the delta of both days and minutes:

function Reset-Dates ($WebUrl, $ListName)
#Get web, list and content type objects
$web = Get-SPWeb $WebUrl
$list = $web.Lists[$ListName]
IF ($ReportFile -eq $null) {$reportFile = C:report.csv"}
#Check if the values specified for the content types actually exist on the list
#Go through each item in the list
$list.Items | ForEach-Object {
$item = $_;
$fd = $["vti_timelastmodified"]
$id = $item["Modified"]
$dd = ($id-$fd)
$hoursMatch = (($dd.hours -eq -4) -or ($dd.hours -eq -5))
$daysMatch = ($dd.days -eq 0)
$minutesMatch = ($dd.minutes -eq 0)
if ($hoursMatch -and $daysMatch -and $minutesMatch)
Write-Host '.' -NoNewline
$xfMod = $["vti_timelastmodified"]
try {$xEdi=$item["ows_Modified_x0020_By"].replace("DOMAIN",$null)} catch {$xEdi=$item["ows_Modified_x0020_By"]}
try {$xAut=$item["ows_Created_x0020_By"].replace("DOMAIN",$null)} catch {$xAut=$item["ows_Created_x0020_By"]}
$Line1 | Out-file -Filepath $ReportFile -Append

Getting your arms around the database sizing of your SharePoint farm

SharePoint Database Size Planning

In order to manage your SharePoint farm, and especially for planning for backup/recovery you need to understand data sizing of your farm. Here are the steps you can take to gather the information needed to understand the existing farm and estimate its growth. This will give you a clear understanding of the size of your backups, so you can plan for recovery timeframes, and will also give insights into the rate of growth and on quotas that can govern growth of databases.

Size of all SharePoint Databases

To plan for DR one needs to know the size of all databases to be backed up and restored. This small script will produce a CSV report of the bytes per database attached to the SharePoint farm:

Get-SPDatabase | select name,DiskSizeRequired | convertto-csv | set-content "C:DBsize.csv"

RBS Report

There is no direct mechanism in Central Admin to view RBS configuration. This script will give you a report of the RBS settings throughout your farm:

Get-SPContentDatabase | foreach {$_;
try {
$rbs = $_.RemoteBlobStorageSettings;
write-host "Provider 	Name=$($rbs.GetProviderNames())";
write-host "Enabled=$($rbs.enabled)";
write-host "Min Blob 	Size=$($rbs.MinimumBlobStorageSize)"
{write-host -foregroundcolor red "RBS not installed on this database!`n"}
finally {write-host "End`n"}

Site Collection size report

It is useful to know the sizes of your Site Collections, and their distribution among your Content Databases. You can report on the size of each Site Collection within each Content DB within a given Web Application with the script below. The output is a CSV (Comma Separated Value) file easily read into Excel. If you have a lot of Site Collections, just convert to a PivotTable, to see the distribution and sizes of Site Collections across Content Databases.

get-spwebapplication http ://SharePoint | Get-SPSite -Limit all | select url,contentdatabase,@{label="Size in GB";Expression={$}} | convertto-csv | set-content "C:TEMPDBsize.csv"

Site Collection sizes help inform how to rebalance Content Databases for optimal sizing to allow you to meet your RTO.
One common situation is for MySites to be distributed unevenly across Content Databases, leading to one Content Database being much larger than others. As discussed earlier, managing Content Database sizes is key to meet your RTO.

Quota Report

Setting quotas puts in place limits on Site Collection growth. It also gives the Administrator weekly notification of Site Collections that have exceeded a preset warning size.
This report gives you a list of all the quotas in place across a Web Application:

$webapp = Get-SPwebapplication "http ://SharePoint"
$webapp | get-spsite -Limit ALL | ForEach-Object {
$site = $_;

What you want to look for first are Site Collections that have no quotas. These represent opportunities for unconstrained growth without notification that could result in Content Database growth that exceeds your RTO targets.