Anjular.js fragment identifier “#” hash issue with SharePoint 2019 Modern UI

OnPrem SharePoint 2019, Modern UI, Horizontal Navigation Bar trimming special characters in our case “#” (Hash) in query strings for link entries which breaks 3rd Party Angular.js navigation.
like: http://www.contoso.com/home.aspx/?#/banner/yellow

(Btw:This issue is not present on SharePoint Online)

This issue only happens with SharePoint 2019 Modern UI and if you store your links with Vertical or Horizontal Navigation OOB control.

The reason is OOB Modern UI Navigation components trims any fancy character including hashes (#) where it is required for your angular.js custom solution navigation or routing purpose.

For resolution; you may try following workarounds:

There are several articles in related Angular design and how it may change this behavior.

There are always some issues we are expecting integrating 3rd party tools with SharePoint. We are trying to support as much as possible 3rd party JS library usage with SharePoint like Angular.js, but we don’t have support for Angular.js itself. It is an open source project that we cannot help much to removing “#” on Angular.js for angular navigation. This is out of scope for Microsft Support.

Luckily, Microsoft SharePoint product group fixed that behaviour and the resolution has been addressed with November CU 2019 for SharePoint Server 2019.

November 2019 CU for SharePoint Server 2019 is available for download

 

 

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.

Unable to open documents using direct links from SharePoint 2019

Update (30-09-2019): This issue will be fixed by Microsoft with November CU 2019 for SharePoint Server 2019.

The response from the server is missing the X-MS-InvokeApp: 1; RequireReadOnly header.

This issue happens when SharePoint configures new IIS Site, when we are creating a new web application or extending it. Where messed up one of the Response Header configuration which causes missing other required response headers like X-MS-InvokeApp: 1; RequireReadOnly

That causes Unable to open documents using direct links from SharePoint 2019.

ResponseHeaders

But it can be fix easy and manually.

Just go for your SharePoint IIS Site in IIS and open Response Headers and locate
-> “MicrosoftSharePointTeamServices: 16.0.0.10347” this is the issue
you need to move version to “Value”.

https://social.technet.microsoft.com/Forums/en-US/7f9d9994-e1a1-4e9d-aed3-8b28df848341/sharepoint-2019-response-headers-are-mixed-up?forum=SP2019

Our product group is aware this issue and working on this. (26/Agu/2019)

 

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