About future of the Content Deployment feature for SharePoint 2019

This article is about future of the “Content Deployment” functionality in SharePoint.
SharePoint production team is not improving the feature till SharePoint 2013 and they will not invest “Content Deployment” in newer SharePoint Builds.
So you should be consider to find an alternative on it.

Feature itself It is not depreciated but it will be present in SharePoint “AS IS” for backward compatibility mode and if any new feature implemented in SharePoint 2019 if it is not convenient or breaks content deployment, it will not going to be adjust/fixed.
Another meaning; SharePoint engineering team will not consider the effect for any new features on Content Deployment.
If you want to continue to use “Content Deployment” Either you should disable the newly implemented features in SharePoint 2019 (Where it may not possible some scenarios) or you need to switch an alternative (Mostly 3rd party products or manual operations)

Our official statement on this issue: Content deployment was announced as NOT recommended since SharePoint 2013 and also this statement valid for higher builds, with limitations and alternatives called out here https://blogs.technet.microsoft.com/tothesharepoint/2013/07/15/changes-to-content-deployment-in-sharepoint-server-2013
While it has not been formally deprecated, it has a limited degree of support, including not supporting the deployment of many features.

An Issue with changing ProxyGroup for a ServiceApplication in SharePoint

We had an issue with multiple proxy groups and UPA , MMS configurations.

My suggestion is, Do not use Central Administration UI for creating or changing proxy group of Service Applications from UI.

Instead use Powershell scripts.

And don’t forget to set manually “SPServiceApplication.ServiceApplicationProxyGroup” property for each ServiceApplication if you move it rather than default proxy group.

If you do it from UI this property always be “NULL” in configuration database and persisted object of ServiceApplication is not updated. SO when you or SharePoint reach to ProxyGroup of a Service Application, if this property is NULL it returns the Default proxy group even the Service Application is on another proxy group.

Well if you already move it from UI, you should update the ServiceApplications as below where they are not in default proxy group.

Example:
#Lets assume we have 2 proxy group  “default” and “myProxyGroup”
#Get the related Service Application where it is present in “myProxyGroup”
#You should do it for all ServiceApplications if they are not in default proxy group.

$app = Get-SPServiceApplication -Identity <GUID>

$ProxyGroups = Get-SPServiceApplicationProxyGroup
$myProxyGroup = $ProxyGroups[1]   # -> this is my second proxy group.

#Set it manually
$app.ServiceApplicationProxyGroup = $myProxyGroup
$app.Update()

Resources:
https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/get-spserviceapplicationproxygroup?view=sharepoint-ps

https://docs.microsoft.com/en-us/sharepoint/administration/add-or-remove-a-service-application-connection-to-a-web-application

https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/add-spserviceapplicationproxygroupmember?view=sharepoint-ps

Creating New Service Application Proxy Groups and Associating Services and Sites

Redirecting http to https in SharePoint with AAM

There is a common mistake in redirecting http to https on any SharePoint site that thinking that AAM configuration is enough. Well thats not true !

Let’s assume we have following settings on AAM.

HTTPS -> HTTPS : https://www.contoso.com  zone:default  public url: https://www.contoso.com
HTTP -> HTTPS   : http://www.contoso.com  zone:default public url: https://www.contoso.com

And having correspoinding IIS binding:
http://www.contoso.com:*:80 (http)
*:443 (https)

In most of the cases this works fine. like
http://www.contoso.com
http://www.contoso.com/subsite
http://www.contoso.com/pages/home.aspx

but the problem happens when you try to land a one of the default layout pages ,
For example that you have sending a workflow emails pointing an item in a library
with querystrings:

http://www.contoso.com/SubSite/Lists/TestList/DispForm.aspx?ID=1
&Source=http%3A%2F%2Fwww%2Econtoso%2Ecom%2FSub1%2FLists%2FTestSub%2FAllItems%2Easpx
&ContentTypeId=0x0100AFA0B78F421E78408D29FBEA2D5EF4F9

Unfortunately this doesn’t work as expected , Either you can get 404 not found or the related page loads as http instead of https (depends on how you configure bindings on IIS). Well this is  a production design problem that we can not fix at that moment.
Valid for all SharePoint versions (2013,2016,2019)

Suggested solution:
A simple workaround is using another dummy IIS site with binding that intercepting all port 80 requests with host header of your site (www.contoso.com)
and use HTTPRedirect functionality (module) on IIS to redirect to correct IIS site as HTTPS:

Complex Solution:
That you may use URLRewrite module.

 

About Supportability of SCOM APM Agent by SharePoint Products

For SharePoint 2013, SharePoint 2013 is in “extended support” state. Any integration of newer version of SCOM agent is out of support for SharePoint supportability perspective.
Microsoft strongly suggest upgrade to the most recent version of Sharepoint which is “SharePoint Server 2019”.
Supportability options are also available for SharePoint 2016 with builds of May CU 2018 or higher.

Please check the product life cycle
https://support.microsoft.com/en-us/lifecycle/search/935

Since November 2018, SCOM 2016 APM agent with UR6 or higher builds are supported using with Sharepoint 2016 and SharePoint 2019.
More information about Update Rollup 6 (UR6) for SCOM 2016

https://kevinholman.com/2018/10/31/ur6-for-scom-2016-step-by-step/

Be aware that SCOM build number versus Monitoring Agent version is different things.

https://buildnumbers.wordpress.com/scom/

https://blogs.technet.microsoft.com/kevinjustin/2018/09/06/mma-agent-and-scom-agent-version-numbers/

Using earlier version SCOM 2012  (including SP1 , R2 )  APM agent with any SharePoint product is “Not supported”. Because the necessary fixes are not implemented on this version.
Again SCOM product compoents may use without APM agent.

Most of the SCOM APM and SharePoint problems also related with .NET version that in use. It is impossible to test for every scenarios and builds.
Which causes limited supportability options most of the scenarios.

Our main supportability approach for Sharepoint;

Any kind of 3rd party profiler or Microsoft based profilers (which is also considered 3rd party for SharePoint perspective) we have only “Limited Support” and “Not recommended
(If the products are in supported builds otherwise it is “not supported” at all)

For Microsoft based (like APM) or 3rd party (.NET) profilers (where injects their binaries inside IIS worker processes and intercept executions in several points) is “not recommended” with SharePoint production envrionment.
Still they may be useful for pre-production to test and verify custom solution behaviours with in “Limited Support”.

SharePoint have highly complex implementation with IIS and ASP.NET which profiler may cause extra overhead and abnormalities.

SharePoint core works on native code and mostly wraps with .NET wrappers and do heavy interops which mostly .NET profilers useless for monitoring the core and very open to causes abnormalities and may crashes.

Profilers causes extra overhead already on SharePoint which is already a heavy product.

Sharepoint with combined .NET , ASP.NET and OS system has more than enough performance counters for profiling and monitoring perspective.

Profilers may mask underlying problems or hardining troubleshooting for deepdive analysis like dumps and memory traces, that increases our problem resolution times and may cause misleading directions.
Microsoft Support team mostly request to remove/uninstall the 3rd party profiler for before working related scenarios.

In Summary,

Use as much as possible for monitoring or profiling purposeses already provided performance counters by the SharePoint, .Net and OS System.
Avoid any kind of binary injecting codes/profilers inside worker processes where SharePoint runs for specially production environments.

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.
    HKLM_\SOFTWARE\MICROSOFT\MSIPC\CurrentVersion\InstallLocation:
    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.
    https://www.microsoft.com/en-us/download/details.aspx?id=30679

Be aware, another “May” the update be with you !

Be aware that starting 30th of April, 2019 the SharePoint installations have to be on a minimum patch level of  May 2018 CU for SharePoint Server 2016 and on April 2018 CU for SharePoint 2013.

According Product Servicing policy, All SharePoint Server 2016 builds will be supported for at least one year from its release date. (The similar policy applies also SharePoint 2013)

Microsoft will update the minimum supported build of SharePoint Server 2016 on each anniversary of General Availability (GA) which is 30th of April of each year.

 

https://docs.microsoft.com/tr-tr/SharePoint/product-servicing-policy/updated-product-servicing-policy-for-sharepoint-server-2016

https://docs.microsoft.com/tr-tr/SharePoint/product-servicing-policy/updated-product-servicing-policy-for-sharepoint-2013

Field experiance on SharePoint Onprem Apps configurations for SharePoint 2016

Well, It is really hard to configure apps if you have challenging environment so i would like to give some advices and suggestions.

For ADFS 3.0 or Higher

  • Avoid using multiple Relaying Party or IDP. Instead use a single relaying party with single URN and multiple endpoints if you have more than one site url and apps wildcard urls. To able to work with multiple endpoints you need to enable SPTrustedLoginProvider.UseWReplyParameter. https://docs.microsoft.com/en-us/dotnet/api/microsoft.sharepoint.administration.claims.sptrustedloginprovider.usewreplyparameter?view=sharepoint-server
    Example Configuration in ADFS Relaying party:
    Identity :  urn:sharepoint:sts
    Endpoints:
    https://web1.contoso.com/_trust/
    https://web2.contoso.com/_trust/
    https://*.contosoapps.com/_trust/
    https://plan.fabrikam.com/_trust/
    https://*.fabrikamapps.com/_trust/
  • If you have Host Named Site Collection (HNSC) do not use any “extended” zone. Instead use “default” zone with multiple authentication if required. Like NTLM + ADFS.(You can use bypasslogin solution to get rid of authentication selection page)
    Otherwise you may face SiteLookUp failure with sub site collections if you are using SAML authentication with apps url redirection.
  • For Path Based Site Collections (PBSC) (you can use mutiple zones) enable and use Multiple App Domain feature via New-SPWebApplicationAppDomain.
  • Do not use same appdomain name defined in Central Admin -> Apps-> Configure Apps URL if you are using Multiple App Domain feature via New-SPWebApplicationAppDomain.
  • Try to use combined certificates as much as possible. That make possible to use single 443 port both your apps and site urls. (Don’t forget your apps configuration need a wildcard certificate if you want to use SSL)
    (Yes I know our article says you need a different port but it works)
  • Avoid any hostname binding in IIS if you have HNSC.
  • Avoid using SNI for HNSC or Mixed webapplications instead use IP address isolation in bindings for IIS if you have multiple certificates.
  • If you have HNSC web application and wants to create another HSNC web application but you want to use different appdomains. It is possible that may doesn’t work.
  • Multiple PBSC and one HNSC senarios, Only use CA global apps domain for HNSC web application and configure appdomains via multiple app feature for all PBSC.
  • Always test the configuration with a realible app which you know it is working .
  • Double Check DNS configurations and don’t forget to clear DNS cache on your clients and servers if you make any change.
  • For troubleshooting suggestion: Check always where is your request is landing in IIS  and verify the Certificate is correct.
  • LDAPCP doesn’t work with mutliple Trusted Identity Provider.
  • I would suggest use single Trusted Identity Provider.But If you have to using multiple Trusted Identity Provider, you posibble hit “URN” mismatch issue with apps redirection urls. (You can use URL Rewrite to workaround it for related web application)