Change default File Open Behavior of SharePoint Online

The default option in SharePoint online to open files stored in document libraries is “Open in Browser”. You can leave it like that as long as you don’t have an specific requirement to change this behavior.

In some cases, end users prefer to open file by client application due to many reasons and they are fair reasons, mostly.

1. Client application offers rich capabilities which allows users to get things done effectively and efficiently
2. Some organizations using SharePoint as the central document management platform across the entire company. At this point they might prefer to have the files opened by client application as default.

There are various ways to enable this functionality which impact different levels.

1. Document library level
2. Single site collection level
3. Across the entire tenant

If you’d like to set a specific document library to open files in client application by default. Simply log in to your SharePoint online tenant, direct to the desired library and select the radio button under the Advance Settings as you wish (This overrides the setting applied at site collection level and open documents in client application instead of browser)

Navigate to the Document Library –> Click on Settings gear –> Library Settings from the menu.

Under General Settings –> Click on “Advanced Settings”

To enable this for a specific site collection (applies for the entire collection unless you have chosen from individual libraries manually as shown in the screenshot above to opt out)

To do this for an specific site collection, we have to activate a site collection level feature. Simply log in to your SharePoint online tenant, direct to the desired site.

Go to Site Settings –> Site Collection Features

Click on “Activate” button next to “Open Documents in Client Applications by Default” feature

You can use the following PowerShell script to do get the same thing done in a bulk mode across all site collections in the tenant (ORG WIDE).

This is a SharePoint PnP PowerShell script which uses an CSV file as the source for site names.

1. First you have to get all the site URLs exported from the SharePoint Admin Centre in Office 365 Admin Portal
2. Then save it as an CSV file and point this script to that file (Change the CSV path in the script)

Your CSV should look like this (Site URLs separated in to individual columns, not rows. If you are having hard time getting this format, it’s quite easy, use the Transpose feature under Paste special)

Note: Obviously, this script will only cover the existing site collections of your tenant. For any upcoming new site collection created after running this has to enable it manually again.

$username = Read-Host "Provide the username"
$password = Read-Host -Prompt "Password for $username" -AsSecureString
$O365credential = New-Object PSCredential($userName,$passWord)

# Chnage CSV path here
$site = Import-csv C:\Official\Tools\remain.csv

Foreach ($URL in $site.URL)
{
try {
    Connect-PnPOnline -Url $URL -Credentials $O365credential

    Write-Host "Connected to " $URL 
    Write-Host "Enabling features on" $URL 

	# Enter Feature Id & scope

    Enable-PnPFeature -Identity 8a4b8de2-6fd8-41e9-923c-c7c3c00f8295 -Force -Scope Site

    Write-Host "Disconnecting from " $URL 
    Disconnect-PnPOnline    
    }
    Catch 
    {
    Write-Host "Got error" $error
    }
}
Write-Host "Completed"

Advertisement

Calling all SharePoint Admins: Have you patched your servers?

A critical vulnerability of SharePoint Server has been identified which could lead to potential hacking.

Many enterprises use Microsoft SharePoint as the prime collaboration and content management platform and there are still a significant amount of SharePoint on-premise deployments across the world. This alert for the admins who manage on-premise deployments which you better take seriously and act fast.

A critical security vulnerability identified as CVE-2019-0604 | Microsoft SharePoint Remote Code Execution Vulnerability which behaves as explained by Microsoft below.

• A remote code execution vulnerability exists in Microsoft SharePoint when the software fails to check the source markup of an application package. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the SharePoint application pool and the SharePoint server farm account.
• Exploitation of this vulnerability requires that a user uploads a specially crafted SharePoint application package to an affected versions of SharePoint.
• The security update addresses the vulnerability by correcting how SharePoint checks the source markup of application packages.

Critical: It is highly important that you follow the table below and update your servers accordingly. As of now, Microsoft have not identified any Mitigation facts or Workarounds for this issue, however, the list of security updates shall keep your server away from the vulnerability.

CVE-2019-0604 (Critical)

SharePoint Updates

And, following links shall help you on patching servers.

2016: https://docs.microsoft.com/en-us/SharePoint/upgrade-and-update/install-a-software-update
2013: https://docs.microsoft.com/en-us/SharePoint/upgrade-and-update/software-updates-overview-for-sharepoint-server-2013

Fix: SharePoint hybrid picker wizard fails to run the validation

Hybrid capability is a great addition from Microsoft since SharePoint 2013. In 2019 version, Microsoft has made sure that Hybrid area is much more robust so I was very keen to find out the latest by deploying it and wrote a book too on that (Install and Configure SharePoint 2019). However, while I was configuring the farm, suddenly got this Hybrid setup wizard error. This article talks on the resolution to this issue in case if you are facing the same.

First thing’s first, I gave it a try again by running the application as the administrator.  Guess what !, it didn’t even start so felt like its a dead end there.

Ultimately, PowerShell saved me on this one. If you have the same issue, run Windows PowerShell from your SharePoint box and execute the following line. You have to replace the folder location with yours.

& 'C:\Users\sp_farm\Desktop\Microsoft SharePoint Hybrid Configuration Wizard.appref-ms'

It should now run the prerequisites smoothly.

Fix: SharePoint blank site template gone missing

We used blank templates back in SharePoint 2010 days for various reasons but it isn’t there anymore as being hidden from 2013 onwards. As in this screenshot, when you open up Central Administration and try to create a Site Collection, “Blank Site” Template will not be visible in SharePoint 2013 or later versions.

Nevertheless, worry no further as this article will demonstrate the way to get it back just in case you badly need it. Just follow the steps (recommended to try in a test setup before you have it in production environment).

There are two ways to enable it again.

Method A:

This is a permanent change which allows you to use this template anytime. However, you can revert it back if not necessary. Find this folder in your SharePoint Server/s – C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\1033\XML

Then from there, open up WEBTEMP.xml file from the notepad and search for this tag line.

<Configuration ID=”1″ Title=”Blank Site” Hidden=”TRUE” ImageUrl=”/_layouts/15/images/stbs.png?rev=23″ Description=”A blank site for you to customize based on your requirements.” DisplayCategory=”Collaboration” AllowGlobalFeatureAssociations=”False” > </Configuration>

You can clearly see the Hidden attribute has been set to TRUE here on the 1st line. Make it back to “FALSE” and the tag should now look like below.

<Configuration ID=”1″ Title=”Blank Site” Hidden=”FALSE” ImageUrl=”/_layouts/15/images/stbs.png?rev=23″ Description=”A blank site for you to customize based on your requirements.” DisplayCategory=”Collaboration” AllowGlobalFeatureAssociations=”False” > </Configuration>

Save the changes and close the file then do a IIS reset on the target server/s.

Method B:

You can use PowerShell to create a site using Blank Site template as well. This is a temporary method where you just use the hidden template by calling it without seeing it in the “Create new site” choice list, and, you have to use PowerShell to provision the site.

Add-PSSnapin “Microsoft.SharePoint.PowerShell”

Get-SPWebTemplate

$template = Get-SPWebTemplate “STS#1”

Then run this: It will simply create a brand new site collection using the “Blank Site” template for you. There is no need of changing the backend if you choose this way,  however, there’s no UI to get this done.

New-SPSite -Url “http://mantosospfarm/sites/NewSiteName” -OwnerAlias “Mantoso\SP_Admin” -Template $template

InfoPath Error in SharePoint 2016: There has been an error while processing the form

Warning There has been an error while processing the form. click OK to resume filling out the form. You may want to check your form data for errors.

Let me guess, you have gone through all possible verifications on data sources and form fields and everything pretty well developed and verified ? same goes for me. one of my colleague was developing a form and she came up with this error on SharePoint 2016 recently.

She was using GetUserProfileByName SOAP Web Service to fetch current user’s group in to a field, and that’s where this error prompts. that was verified by removing the particular connection and rules filling up data.

After verifying form fields, Data connections and other basics, I decided to inspect the infrastructure step by step. SharePoint logs and Event Log did not had any relevant entry. Finally in the lonely boat, I took following steps one after one to sail towards an island.

1. Enabled all InfoPath services from CA (General Application Settings) – Everything is already set

1. Registered the HTMLCHKR – no luck

regsvr32 “C:\Program Files\Common Files\Microsoft Shared\OFFICE14\htmlchkr.dll”

1. 3. Added the target site to InfoPath application’s trusted Locations – no luck
3. 
5. 4. Restarted and recycled Security Token Service Application/pool for all WFEs – no luck
6. 
7. 5. Restarted Servers – no luck

Two last steps were able to shed some lights !

1. Disabled loopback check

What is Loopback check?. If you have been prompted continuously for credentials in a SharePoint server when you try to access your site within that server, that’s obviously because of loopback.

Microsoft: Windows Server 2003 SP1 introduced a loopback security check. This feature is obviously also present in Windows Server 2008/12. The feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.
Unfortunately 401.1 is not really helpful as this error code means there is a problem with the user credentials. Of course, the HTTP spec doesn’t know about security features in a vendor’s implementation so there can’t be a HTTP error code for such a feature. This can lead to much banging of the head on the desk. It’s one of numerous causes of the 401.1 which are nothing to do with invalid credentials (e.g. attempting to use Kernel Mode Authentication with domain account in IIS7).

Option1 : Logged in to target SharePoint Server/s and launch PowerShell as administrator, then ran – New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -value “1” -PropertyType dword)

You don’t need to add it if its exists (means loopback is already disabled)

1. Option 2: You can also Add this registry entry manually
2. Click Start, click Run, type regedit, and then click OK
3. In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
4. Right-click Lsa, point to New, and then click DWORD Value. (In Win 2008, its DWORD 32bit)

Type DisableLoopbackCheck, and then press ENTER.

Right-click DisableLoopbackCheck, and then click Modify.

In the Value data box, type 1 and then click OK.

Quit Registry Editor.

1. Then I ran SharePoint Product Configuration wizard on SharePoint Server just to give it a refreshment.

After restarting Servers, added the form connection and rules back and InfoPath form loaded perfectly normally !

SharePoint 2016 Product Configuration Wizard Error: Configuration Failed with Unauthorized Access Exception

If you are going to deploy SharePoint 2016, this is a common error that encountered.

The error pretty much pointing to a Access permission which you might doubtlessly think its database permission but no it’s not !

If you expand the event log, It will have 100, 104 errors logged due to this.

Resolution is to permit setup account to access Tasks folder (C:\Windows\Task). This is a critical folder which needs to be able to access by the setup account during the Product Configuration.

To take the ownership of this folder, log in to relevant SharePoint server using a local admin account and right click on the Tasks folder.

Under Security tab, go to Advance

Change the Owner from SYSTEM to your Setup account (the account will be used to run Product Config Wizard)

Once changed, the new owner can be seen as showed below.

Repeat the same for all SharePoint Servers in your farm if you planned to have multiple. Now run the Product Configuration Wizard again and you will notice its smoothly passing to task 5. within few minutes, the Wizard will be successfully complete.

And here comes the winning moment !

If you are still accounting with any additional errors in the Wizard, these points are some basic ones to verify.

Ensure:

1. 1. Antivirus Disabled for all SharePoint and Database Servers (If any)
2. 2. Firewall
3. 3. Named Pipes in SQL Services enabled (Sometimes this isn’t enabled by default)

And then:

1. 1. Disable UAC (Never Notify)
2. 2. Restart Server
3. 3. Run the Product Config Wizard again as Administrator

Enjoy the all new SharePoint !