SharePoint IRM – Azure RMS not installed issue

Recently we have faced an issue to installing Azure RMS Connector version 2.1 on SharePoint 2013 server.

“The required Active Directory Rights Management Service Client (MSIPC.DLL) is not installed, IRM will not work until the client is installed.”

The problem here SharePoint unable to load the module where it is the MSIPC.DLL and returns winerror 126 (0x7e) .

When we investigate the problem we have faced 2 issues.

  • The DLL location read from registery where the key data has an extra “\” at the end of it.
    C:\program files\active directory Rights Management Services Client 2.1\ -< HERE
    We change it as:
    C:\program files\active directory Rights Management Services Client 2.1
  • Related VC++ Runtime Redistributable package (where msipc.dll have a dependency) is not installed in the server. When we installed VC++ 2012 redistributable issue has been resolved.

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)



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)

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.

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

Pls check .NET Framework 4.7.2 Release Notes

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.

# .\CleanDraftVersions.ps1 -siteUrl <Site Url> -webName <webName> -listName <ListName> -versionsToKeep <Number> -delete=<$true|$false>
# -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 .

# .\CleanDraftVersions.ps1 -siteUrl “; -webName “” -listName “Pages” -versionsToKeep 10 -delete $false


Mainstream support for SharePoint 2013 will end in 6 months

Mainstream support for SharePoint 2013 will end on April 10th, 2018:

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

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.

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

More details explained for this.
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