SharePoint 2016 On-Prem ::: Error within Word and Excel Online

Hi All,


Today I'm closing this case opened last month at Microsoft.

The issue is that on SharePoint 2016 On-Prem, it is no more possible to open any excel nor word file in the Word/Excel Online, or to have a preview of the document.

This is the error exemple that we were experiencing:

After several hours, passed with Microsoft engineer, lot of test and logs, we came to the fact that Office Web App must be reinstalled with the latest version.

And today, I was executing the latest Action Plan (A.P) proposed by the Microsoft Engineer: cleaning the Config Cache in SharePoint 2016.

Before going further, the A.P must be executed on each servers in your Farm, otherwise, you will be facing with a nice correlation ID with this message: "An update conflict..."

Below is a summary of the issue:

Scope:
You are using SharePoint Server 2016 OnPremise and lately you noticed that the users cannot open the Office files in the browser anymore.

Also the preview does not work as expected.

To be more specific:

1. The user john.doe@contoso.com navigates to https://shp.contoso.com/sites/TeamSite01/_layouts/15/start.aspx#/MyDoc/Forms/Default.aspx and selects the Word file called “Migration Doc-01.docx
2. By opening the file in Word Online, the following message appears:

Server Error in ‘/x’ Application.
Runtime Error

Description: An application error occurred on the server. The current customer error settings for this application prevent the details of the application from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “Off”

<!—Web.Config Configuration File -->
  <configuration>
<system.web>
<customErrors mode=”Off”/>
</system.web>
</configuration>”

Notes: The current error page you are seeing can be replaced by a custom error page by modyfing the “defaultRedirect” attribute of the application’s <customErrors> configuration tag to point to a custom error page URL.

<!—Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode=”RemoteOnly” defaultRedirect=”mycustompage.htm”/>
</system.web>
</configuration>”

Action Plan:
1 - Delete the configuration cache, on EACH servers in your Farm,  using the information from this article : https://sharepointfordummies.blogspot.com/2019/01/an-update-conflict-has-occurred-and-you.html

I've used the PowerShell script after verifying that the cache was in the correct location
(URL : to check ::: http://luisevalencia.com/2016/09/28/how-to-delete-the-sharepoint-configuration-cache-with-powershell/)

     - Stop "SharePoint Timer Service" (SPTimerV4)
     - Find folder with cache.ini and .xml
        Location on SharePoint 2016 : C:\ProgramData\Microsoft\SharePoint\Config
        Create a backup folder, and move in all the .xml
        Copy the cache.ini into the backup folder
        Edit the cache.ini file, then replace all it's content by '1' + save
      - Do this previous procedure on each server in your Farm
      - Start SPTimerV4 on each servers of your Farm

2 - Run this command Update-SPWOPIProofKey  in PowerShell, from each server in your Farm
3 - Start the timer job WOPI Discovery Synchronization from Central Administration Console : as I have 2 WFE servers, I've executed both WOPI timer jobs
4 - Test the Preview and opening online your document:

This procedure will also be working with SharePoint 2010 and 2013.
Only check the path where the config folder of SharePoint is located, and adapt into your PowerShell Script.
In 2016, it is located at: C:\ProgramData\Microsoft\SharePoint\Config

Voilà,

That’s all Folks !!!

SharePoint 2013 ::: Event ID 6482 ::: An update conflict has occured

Hi all,

Today, I'm facing with Event ID 6482, indicating that the job is failing due to an update conflict.

The resolution for this issue is to delete ALL .xml files where the mentioned file is located.


1. Finding the filename:
The first line give the file name of the .xml file to find. The name is located into the brackets at the end of the line:
service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (a5744ce1-d592-42fc-a081-82188cbee126).

2. Stop the "SharePoint Timer Service"

3. Browse on each servers of your farm to this path:
C:\ProgramData\Microsoft\SharePoint\Config

4. Delete all .xml files present into the folder where .xml files are located (the other folder does contain  ".PERSISTEDFILES" : do not toutch them)

5. Edit the file "Cache.ini", and write down the number "1"

6. Save the "Cache.ini" file

7. Repeat steps 2 to 6 on each servers of your farm

8. Restart the "SharePoint Timer Service" on each servers of your farm.

9. Check that all cache files are automatically recreated.

10. Check that the file "Cache.ini" contains another number then "1"



==> Problem solved.

---

Voilà,

That’s all Folks !!

SharePoint 2013 ::: .NET Server Error ::: Event ID 1023

Hi all,

Today, I'm checking one of my Farms, in my test environment, and while opening Central Administration site, I was faced to this nice Runtime Error:

Following this discover, I've tested to access to the Farm via PowerShell commands.

- First, let's load the SharePoint snapin:
          add-pssnapin Microsoft.SharePoint.PowerShell
     ==> no errors, ths it means that my farm isn't broken.

- Secondly, let's check the Farm version:
     ==> (Get-SPFarm).buildversion

Major  Minor  Build  Revision
-----  -----  -----  --------
15     0      4957   1000   

Ok, defenitely, it is not a SharePoint Farm issue.

Then, I saw some .NET Runtime (Event ID 1023) errors in the Event Viewer.

After googleling a little bit, I found the solution explained by Bryan Peters in this post.

I've made the exactly same procedure, on my both servers, and the Farm is back to live.

Create a new DWORD, followed by an IIS Reset:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
New registry DWORD : LoaderOptimization
Value : 1
IIS Reset


==> Problem solved.

---

Voilà,

That’s all Folks !!

SharePoint 2013 ::: BCS Database is in compatibility range and upgrade is recommended

Hi all,

A few time ago, I went trought this message for the BCS Database on SharePoint 2013:

BCS Database is in compatibility range and upgrade is recommended


To solve this issue, I've executed this PowerShell commands:

This solved my particular issue.
If you have the same type of message for other databases, please proceed by the same way, by replacing the name of the DB by the known name when doing a Get-Member 


Add-PSSnapin Microsoft.SharePoint.PowerShell

Get-SPDatabase | FT -auto name,type

(Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase"}).Provision()

---

Voilà,

That’s all Folks !!!

SharePoint 2013 ::: How to restore the deleted "Suggested sites to follow" Web Part from a user's MySite

Hi all,

Today’s challenge is to restore the Web Part “Suggested sites to follow” that was deleted by the user himself.

So, do not lose your time in trying to find the Web Part in the Add Web Part page of the mySite, it is not available.

After googleling, I found this link to a Microsoft article to remove the concerned Web Part using PowerShell.

The script, provided by Microsoft, that put me on the track is:

Add-PsSnapin Microsoft.SharePoint.PowerShell

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.WebPartPages")

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Publishing")

$useraccount = "useraccount"

$url = "http://" + [System.Net.Dns]::GetHostName() + "/my/personal/" + $useraccount

$site = get-spsite $url

$web = $site.RootWeb

$pageUrl= "Social/Sites.aspx"

$webPartManager =  $web.GetLimitedWebPartManager($pageUrl, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared);

$webPart = $webPartManager.WebParts | where-object { $_.WebBrowsableObject.GetType().Name -eq "ProjectSearchBrowseWebpart" }

if($webPart -ne $null)

{

    $webPartManager.DeleteWebPart($webPart)

}

$web.Update();

In the script, I found the name of the Web Part "ProjectSearchBrowseWebpart", and the page to find it.

Then, I decided to compare the code of both pages “Social/Sites.aspx” from my mySite and from the user’s mySite, using SharePoint Designer 2013.

I found then the difference at the end of the code:

Hereunder is the code from my mySite, and in yellow, the missing code in the user’s mySite code:

            <div class="ms-contentFollowing-sitesRightZone ms-tableCell ms-verticalAlignTop">

                <div class="ms-contentFollowing-bottomZoneContainer">

                    <WebPartPages:WebPartZone runat="server" FrameType="None" ID="RightZone" Title="<%$Resources:sps,LayoutPageZone_RightZone%>" Orientation="Vertical"><ZoneTemplate>

                                                                           <SPSWC:ProjectSearchBrowseWebpart runat="server" CategoryString="Site" AllowEdit="False" ChromeType="TitleOnly" Description="The recommendations web part suggests content a user may wish to follow within a farm." Title="Suggested sites to follow" ID="projectSearchBrowseWebPart" __MarkupType="vsattributemarkup" __WebPartId="{344EF58F-509A-3DE1-T3DG-ID0T674FOR6Z}" WebPart="true" __designer:IsClosed="false" partorder="2"></SPSWC:ProjectSearchBrowseWebpart>

                                                                           </ZoneTemplate></WebPartPages:WebPartZone>

                </div>

            </div>

        </div>

    </div>

</asp:Content>

So, I simply made a copy/paste of the missing line, save the user’s “Social/Sites.aspx” page, and made a refresh of his mySite in the browser.

 ==>Problem solved.

---

Voilà,

That’s all Folks !!!

SharePoint 2013 and Microsoft Security Patch side effects

Hi all,

Last week, I've patch with big success my production Farm (15 servers) and my Disaster recovery Farm (15 servers).

Little explanation about our configuration:

All the db (system, content, search, etc) are located on a SQL Cluster, set with several availability groups. (this point made me having white hairs during the previous Cumulative Updates).

On that Cluster, there is a primary group, where all the changes made in SharePoint (system, content, search, etc...) are committed (Read/Write).
Then, on the secondary group, all dbs are automatically sync from primary to secondary group (thus, in case of ay issue, I can easily have a fresh backup and replace the faulty db).

So, those 2 SQL cluster, are "dedicated" to my Primary Prod SharePoint Farm.

Beside this, I have a backup farm. She is identical to the primary farm, and was designed in case of disaster recovery, to replace the main Farm.

In the procedure, I've changed it to reduce the user impact to it's minimum.
The estimation is 2 time 5 minutes: DNS switch from Primary Farm to Secondary Farm, and Secondary Farm to Primary Farm.


So, to be short, both Farms were patched without issue.

The problem came 3 days later, when the mandatory security patch where applied on half of the servers in the company (Next half is done 2 days later).

I discovered that 1 server was back in "Upgrade required"... Oh, my words!!!!
Then, the day later, I had 5 other servers back in that status.

During that time, we had the support of Microsoft, and they recommend us to execute this powershell command:
     Get-SPProduct -local
     Reboot the server

Then, I did this procedure, and it works!!!!

After that, I've only execute the powershell command without rebooting the server, and my servers went back to "No Upgrade Required".

This powershell command must be executed on each server that have received a Microsoft security patch.


So, If your farm was successfully patched, and some server are back in the status "Upgrade Required", thus try this powershell command.
Your Farm and server are still up and running, and in take less than 5 minutes to correct the issue.

---

Voilà,

That’s all Folks !!!

SharePoint 2013 ::: Database is in Compatibility range and upgrade is recommended ::: Database is too old and upgrade is required

Hi all,

After the December 2014 CU, all my farms have their BDC Service Database in compatibility range.

I found the solution from Markus’ Blog and I’ve executed this PowerShell command:

Add-PSSnapin Microsoft.SharePoint.PowerShell

(Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase"}).Provision()

Also, I got an error (as mentionned in his post), and checked the access rights.

This is the error I had:

PS C:\Windows\system32> (Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase"}).Provision()

Exception calling "Provision" with "0" argument(s): "Cannot find the object "dbo.Versions" because it does not exist or you do not have permissions."

At line:1 char:1

+ (Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

    + FullyQualifiedErrorId : SqlException

So, I’ve asked to the SQL Team to add the SPDataAccess for the service account:

Then, I ran again the PowerShell command, and my BDCS database is now in “No action required” status.

I’ve also 3 system database that are in “Database is too old and upgrade is required” status.

For those 3 DBs, I’ve tried the same way as for the BDCS database:

First, getting the correct Type Name for each DB:

Get-SPDatabase | ft -Auto

Second, preparing the PowerShell commands:

(Get-SPDatabase | ?{$_.type -eq "Microsoft SharePoint Foundation Subscription Settings Database"}).Provision()

(Get-SPDatabase | ?{$_.type -eq "Microsoft.Office.Server.Administration.ProfileDatabase"}).Provision()

(Get-SPDatabase | ?{$_.type -eq "Microsoft.Office.Server.Administration.SocialDatabase"}).Provision()

Third, checking and adapting the SQL settings for SPDataAccess

Finally, executing my PowerShell commands.

---

Voilà,

That’s all Folks !!!