Unable to open documents using direct links from SharePoint 2019

23/08/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)

 

Advertisement

Filed under SharePoint 2019 Tagged with , , , ,

An Issue with changing ProxyGroup for a ServiceApplication in SharePoint

07/08/2019

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

Filed under Sharepoint Tagged with , , , , , ,

Redirecting http to https in SharePoint with AAM

01/07/2019

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.

 

Filed under Sharepoint Tagged with , , , , , ,

About Supportability of SCOM APM Agent by SharePoint Products

01/07/2019 1 Comment

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.

Filed under Sharepoint Tagged with , , , ,

SharePoint IRM – Azure RMS not installed issue

11/06/2019

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

Filed under SharePoint 2013, Uncategorized Tagged with , , , ,

← Older posts

Newer posts →