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 !!!

Why a Content DataBase is not cleaning the free space after Move-SPSite or Delete-SPSite?

Hi all,

I was faced to a full Database, and the quick-win solution, was to move some sites to another Database.

After making the list of the site collection present in the database, I found that the moved sites were no more present, as expexted.

But on the SQL side, the Database was still full…

I’ve asked our SQL Team to Shrink the Database, but nothing was changed.

Then, I’ve search why the space used by the moved sites was not cleared by the Timer Job.

Timer Job… The Gradual Site Delete timer job.

I’ve found why the Database didn’t change the free space after moving sites.

The timer job in SharePoint wasn’t correctly set.

After checking, the job supposed to be run automatically every day from 10PM to 6AM, but it wasn’t run.

Reason: start time is before end time. Seems that Microsoft logic is … special.

In the drop down list, the time for the timer job (same problem for all timer jobs in all SharePoint versions) start at 12AM and ends at 11PM.

The problem, is that by default, the Gradual Site Delete timer job is set as below: from 10PM to 6AM

This is quite logic for us (human), but I’ve the impression that the timer job doesn’t see the 6AM after 10PM in the drop-down list.

Also, I found that clicking on the “Run Now” button didn’t free the space in the concerned Database.

Thus, this default setting seems not allowing the Timer Job to run:

Solution: instead  of starting at 10PM, I’ve set it to start at 12AM

                                Now, no more red warning message.

                                And clicking on “Run Now” button is directly clearing the free space of all the                                      databases of my Web App.

So, I’ve had to check all my Gradual Site Delete timer job for each Web App I have.

Also, I found this problem to my SharePoint 2010 Farm and my brand new SharePoint 2013 Farms.

Hope this could help.

That’s all Folks

SharePoint 2013 returns to 'upgrade required' status

Hi all,

This post is related to the fact that after upgrading your SharePoint Farm with success, you are faced again with some servers in the "Upgrade Required" status.

As this issue was still coming and coming after each try to re-upgrade my farm, I decided to open a case at Microsoft support.

So, hereunder, you can find the resolution steps that will bring your smile back.

In summary, if one or several servers (my production farm is composed by 25 servers) are going back to the "Upgrade Required" after being marked as "No Action Required" during few days, check first if you don't have some sites that were not upgraded.

In this case, only 1 Site Collection wasn't correctly upgraded, and after a manual upgrade (via powershell cmdlets), all was solved.

Here is the case summary for your records:

==================

Title: SHP2013 returns to 'upgrade required' status

Severity: B

Status: Resolved and Closed

ACTION/RESULT:

Customer reported that after completing the upgrade to CU December 2014 (more than once) on the SharePoint 2013 farm - some the "Servers in this Farm" were still showing "Upgrade Required"

CAUSE/RESOLUTION:

In a previous upgrade attempt, there was the indication of a Site Collection that was not provisioned correctly:

07-24-2015 13:12:59.59 OWSTIMER (0x1CEC) 0x1F5C SharePoint Foundation Upgrade SPSiteWssSequence alsj5 WARNING SPWeb [https://mysite.sharepoint.me/sites/myname] [MyName, MyFirstName] is in a partially provisioned state. 021f1d9d-33b4-00ca-36cd-9ce05d7b2e40

Running (Get-SPSite https://mysite.sharepoint.me/sites/myname).NeedsUpgrade showed that this needs to be upgraded.

Customer ran the script:

$dir = Get-Location

$file = "$dir\farmSCUpgradeRequired.txt"

#Sites

Get-SPWebApplication -includecentraladministration | ForEach-Object {

               $webappurl = $_.Url

               $_.Sites | ForEach-Object {

                              "{0};{1};{2}" -f $webappurl, $_.URL, $_.NeedsUpgrade

               }

} | Out-File $file

This showed that the site collection mentioned before was in fact the only one needing an upgrade.

Customer run the powershell command:
  Upgrade-SPSite https://mysite.sharepoint.me/sites/myname -versionupgrade

The Site Collection was upgraded successfully.

After this, customer ran the "Product Version Job" timer job, and only 2 servers were still showing "Upgrade Required".

Running "stsadm -o localupgradestatus" showed only for these 2 servers, the following error message:

  <object>

    <name>Sharepoint_SA_UserProfile_Profile</name>

    <type>Microsoft.Office.Server.Administration.ProfileDatabase</type>

    <level>2</level>

    <status>Cannot Upgrade</status>

  </object>

  <object>

    <name>Sharepoint_SA_UserProfile_Social</name>

    <type>Microsoft.Office.Server.Administration.SocialDatabase</type>

    <level>2</level>

    <status>Cannot Upgrade</status>

  </object>

This means that the servers had something different than the rest of the servers, as the Databases were already up to date.

Running Get-SPDatabase | where {$_.Name -like "*UserProfile*"} | ft Name, NeedsUpgrade, NeedsUpgradeIncludeChildren, CanUpgrade also showed the information for these databases on the affected servers.

As this issue could only be on the servers, running the Configuration Wizard on both affected servers, made the message "Upgrade Required" go away.
After some days, the servers are still on a stable state.

=================

That's all folks

Search did not provide new items

Hi All,

Today, I’ll talk about the Search issue I had few weeks ago.

This started on our SharePoint 2010 production Farm, with complain from users that weren’t able to find they newly added documents in the Search box.

At the beginning, I was asking them to wait until next working day, as the Incremental Crawl was running.

Then, days passed, and more and more users were complaining again and again.

Checking the server was showing that the Incremental Crawl were running, but really slowly.

Every days, I was receiving tickets about the usage of the CPU of my crawl server that was stuck at 100%.

When reading over the web, I discovered that the Crawl engine was using all the CPU while crawling.

This was driving me to the wrong path, and letting my server going deeper in the “glue”

I started to pause all the Content Sources, except one, but nothing seems to unstruck the index crawl.

So, I started to think about this problem, and facing Incremental Crawl of more than 300 hours, I decided to call Microsoft for having their support.

First of all, they confirmed that the Crawl process is using 100% of the available CPU, even if you add more and more CPU.

But the advantage, is that the Crawling Time is reduced.

Then, Microsoft asked me to run the Diagnostic Tool on my Service Farm, and they first pointed out that my servers were not fitting to the minimum hardware requirements: 2CPU + 40Gb HDD.

Then, I made a CPU and HDD upgrade: 4CPU + 270Gb HDD.

I started a Full Crawl of each Content Sources, then gradually, I’ve implemented the “Crawl Schedules” for each Content Sources.

Since last week, all the Content Sources are correctly crawling, and nobody is complaining.

So, this is the point to check when you have a search issue:

 - Number of CPU

 - Size of your log disk

 - Crawl Schedule starting at different time

 - Content DataBases are attached/detached, a Full Crawl must be performed (information given by Microsoft)

Voilà,

Thanks all folks