Update-SPSolution fails for SharePoint 2016

We have a nasty problem specific for SharePoint 2016 with Update-SPSolution command-let and currently we don’t have a permenant fix for it.

Basically the problem only happens if you run Update-SPSolution (for a specific wsp file) twice or more inside one OwsTimer Cycle period (Default is 24 hours). Timer service recycle timer job  is responsible to reset owstimer process.  (a.k.a. job-timer-recycle) .The default schedule is Daily  at 6:00 AM. We are calling this 24 hours period “OwsTimer Cycle”.

You may face something similar exception below:

Solution Updates fails.
Some of the files failed to copy during deployment of the solution
<server>:c:\windows\temp\solution-<Guid> folder the <solutionname>.wsp could not be created because the contents could not be found under  id <guid> in the configuration database.

The workaround of this problem:
When ever you need to run Update-SPSolution commad-let “more than once” for “a single solution file” in one “timer service cycle” duration; you need to reset OWSTimer on all servers (“net stop sptimerv4” then “net start sptimerv4”) between each Update-SPSolution execution (for same wsp file)

 

 

Advertisements

About SharePoint with 16+ Cores

Well, If you update .Net 4.7.2 or higer it is OK, otherwise it is a bad idea.

More speficially,
ReaderWriterLockSlim with reentrant have design limitation which can lead serious performance down for previous .Net versions. And Sharepoint pretty much depended on this thread syncronization object. Specially Blob Cache and ObjectCache wraps and using them. More CPU causes more thread contention, excesive locking thats brings slowness.

Example callstacks:
SPReaderWriterLock named [BlobCache] waited 43992 milliseconds to acquire lock. Call stack:
at Microsoft.Office.Server.Utilities.SPReaderWriterLock.AcquireLock(Boolean readerLock, Boolean upgradable, Boolean throwException)
at Microsoft.Office.Server.Utilities.SPReaderWriterLock.AcquireLock(Boolean readerLock, Boolean upgradable)

System_Core_ni!System.Threading.ReaderWriterLockSlim.EnterMyLockSpin()
System_Core_ni!System.Threading.ReaderWriterLockSlim.TryEnterWriteLock(Int32)
Microsoft_Office_Server!Microsoft.Office.Server.Utilities.SPReaderWriterLock.AcquireLock(Boolean, Boolean)
Microsoft_Office_Server!Microsoft.Office.Server.ObjectCache.SPCache+MossObjectCache.UpdateUsageMap(System.String, UInt32, UInt32)
Here are some threads about the problem.
https://github.com/dotnet/coreclr/pull/13243
https://github.com/dotnet/coreclr/pull/13495

These issues has been fixed with .Net Framework 4.7.2 version!.

Pls check .NET Framework 4.7.2 Release Notes
https://github.com/Microsoft/dotnet/blob/master/releases/net472/dotnet472-changes.md

Again don’t think about 64cpus makes more performance. It depends of the software boundaries/limitations and several other things..
My suggestion, scale up with multiple machines. It is more cheaper and stable. ! Not with excessive hardwares. (8 cores are fine 🙂 )

If you have that monster machines, don’t worry you can  use it with HyperV and scale up VMs.

Clean draft versions via PowerShell

SharePoint versionining is very cool feature, but in time or setting incorrect version limitations can cause performance issues. When this happen you may want to get rid off older draft versions.

Following script is cleans for older draft versions in a library while keeping all major versions. Also you can keep defined number of last major items drafts available.
Note: This script doesn’t delete any major item.

#USAGE:
# .\CleanDraftVersions.ps1 -siteUrl <Site Url> -webName <webName> -listName <ListName> -versionsToKeep <Number> -delete=<$true|$false>
#PARAMETERS
# -siteUrl : Url of the Site Collection
# -webName : Specific subsite (leave empty for root web)
# -listName : Specific ListName
# -versionsToKeep: Number of major item’s drafts will be preserved (including current version)
# -delete : $false (default) for reporting only ,$true for deleting.
# Highligts: Red will be deleted , Yellow will be preserved , Green current Item .

#EXAMPLE
# .\CleanDraftVersions.ps1 -siteUrl “http://contoso.com&#8221; -webName “” -listName “Pages” -versionsToKeep 10 -delete $false
Download:
https://github.com/bpostaci/CleanDraftVersions/blob/master/CleanDraftVersions/CleanDraftVersions.ps1

 

Mainstream support for SharePoint 2013 will end in 6 months

Mainstream support for SharePoint 2013 will end on April 10th, 2018:
https://support.microsoft.com/en-us/lifecycle/search?alpha=sharepoint%202013

After this date only security fixes will be provided for SharePoint 2013. Regular hotfixes can no longer be requested.

If not already done we recommend to start planning the migration to SharePoint Server 2016 as soon as possible.

Outgoing emails are not working in SPS2016 after Security Update May 2017

This article has inform you previously there may be some concequences after May 2017 Security Update for SharePoint in some special configurations.

There is a security update May 9,2017 for SharePoint Server 2016
You can find details in following KB
https://support.microsoft.com/en-us/help/3191880/description-of-the-security-update-for-sharepoint-server-2016-may-9-20

Well it is confusing, as you may know, out of the box mail configuration for SharePoint always anonymous. Thats correct.
But in some special configuration applied by customers to force SharePoint processes (w3wp or owstimer) to authenticate with their identities to Exchange server;  If aspnet:AllowAnonymousImpersonation settings was disabled for Authenticated users (well it doesn’t work for anonymous users at all) it may work.

<appSettings>
<add key=”aspnet:AllowAnonymousImpersonation” value=”false” />
</appSettings>

More details explained for this.
https://support.microsoft.com/en-us/help/2686411/sharepoint-impersonates-the-iusr-account-and-is-denied-access-to-resources
Security Warning : Well the suggested action for this settings , this should be enabled. Otherwise anonymous request will have higher rights with Application Pool Identities does.

The problem of this kind of authentication is incorrect ,not expected  for SharePoint and Microsoft considered this is a Security Issue. As Microsoft said by design it has to be anonymous. With that Security fix will prevent this. SharePoint will be always use anonymous authentication through SMTP servers.

For customers who interested force authentication , well there’s no way to disable the anonymous-only behavior but we have valid workaround for that:

  1. If you are using Exchange, you can set up a separate receive connector configured as externally secured, and restricted to the IP addresses of the SharePoint server(s) in their environment.  This will allow SharePoint to send e-mails anonymously through this receive connector, but the connector will treat the e-mails as if you were authenticated.  All other SMTP clients will continue using the regular receive connectors and any authentication policies associated with those receive connectors.
  2. Set up a smarthost SMTP relay that will accept e-mails anonymously from the SharePoint server(s), and then relay them to the company’s SMTP infrastructure using authentication.

Single Label Domain names (SLD) and SharePoint

About global threat of WannaCrypt attacks

A significant number of customers have reported ransomware (Win32.WannaCrypt ) that was suspected to be introduced into their environment via email, this malware is using Social Engineering to target companies. Microsoft Anti-Malware products have been updated and detect the present version of this malware from definition version 1.243.290.0 onwards

Customer Guidance for WannaCrypt attacks

https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

Impacted customers who were unpatched and infected will work through disaster recovery plans to rebuild and/or patch their systems.

1. Install Security Update MS17-010, to PREVENT further spread of the malware
https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
2. Create the registry key to disable SMBv1 (used only if Security Update MS17-010 cannot be applied)
3. Updated Antivirus definitions should be applied (Microsoft Anti-Malware products detect the present version of this malware from definition version 1.243.290.0 onwards

For More details pls follow Windows Security Blog
https://blogs.technet.microsoft.com/mmpc/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/