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

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