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.


But it can be fix easy and manually.

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


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.

#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




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

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:


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

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


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



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.
    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.

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.




Working with Microsoft Support; Explaining terms that Microsoft Agents using.

“Supported”: Thats mean our Agents help you on this specific problems. Microsoft Agents works on case bases system and one case for one problem.

“Not Supported”:  Well this means Microsoft Support team tells you we can not help you in this scenario or configuration until if you can return back to supported configuration or settings.
But this is not means that is not working. There are some scenarios that your product may still work without any error or underlying something bad not happen yet.
Also there are some scenarios that our product is not tested with related configuration by our Product Group (the people who develops the product)
thats means Microsoft don’t have enough information about the behaviours and future conditions.
Or some complex configuration that is never tested.
In this state you will be informed as “Not Supported” too.
Another example, any old product or version of the product that “Extended Support” is ended. This is time to upgrade.
Microsoft Agents can help you upgrade scenarios but still we have limitations and risks so you should better to upgrade in timely manner not in last resort.
If you exceed a boundary with related product.
If you dont met hardware or software requirement.
Lets assume you have a depended products new release but this is not tested yet for our main product with related Product Group.

“Not Recommended”, The Agents informs you there are several problems you may face in that area and we may not help you.
Examples, Using high priviledge account for a service. Increasing some threadhold values.

“Limited Support”, As obvious that Microsoft Agents limited options to help you in these scenarios.Sometimes you may heard “Grayout Area”
An example:There could be a 3rd party product integrated with one of Microsoft product that Microsoft support teams can try to help as best effort.
You may have a product thats Main Stream supported ended and its in an “Extended Support”.
For restricted environments, no log sharing or no remote session available scenarios considered “Limited Support” and we can help as best effort.

“Extended Support”: Starts after Main Stream supports ends, the duration vary by Product that you have used. In Extended Support there will be no new features added to the product,
also product related problems are not fixed except security related ones or a very major problem with big impact that effects most of the customer around the world.
Only Security fixes continues.We may help you configuration problems or something support team can fix or providing workaround if it is possible. But there will be no hotfix or design change available in “Extended Support” cycle.
In Extended Support, Root cause analysis is not possible.
Extended Support is not available for consumer, consumer hardware, or multimedia products
Enrollment in a paid support program may be required to receive these benefits for certain products.

“Reactive Incident”: It is a case type that you can get remote support from Microsoft Agents. Communication can be done with Phone Calls,Emails, Remote Sharing and Microsoft Support Tools.
Support incidents provide reactive support that focuses on a specific problem, error message, or functionality that is not working as intended.
An incident is defined as a single support issue and the reasonable effort that is required to resolve it.
A single support issue is a problem that cannot be broken down into subordinate issues. I
f a problem consists of subordinate issues, each of these issues shall be considered a separate incident.
Support incidents cannot be used for general advice and guidance

“Advisory”: It is a case type that you can get remote support from Microsoft Agents for a defined time duration.Communication can be done with Phone Calls,Emails, Remote Sharing and Microsoft Support Tools.
Typical Advisory Services cases focus on recommendations or best practices that are used to resolve how-to scenarios that take advantage of Microsoft products and technologies.
These can include guidance for migration, deployment, development, optimization, design and implementation, solutions, scenarios, and architecture.
For example: Root Cause Analysis,Performance problems,3rd Party related application problems,Custom Development issues,Customization considered Advisory.

“Root Cause Analysis”: A special “Advisory” cases that Microsoft Agents helps to figure out, finding the root cause of the issue/incident and share preventions actions as “Best Effort”.
Reaching a conculusion for Root cause analysis investigation is not always possible.It depends on collected logs type,health and verbosity.

“Out of Support”: An old product or a product version thats completed its life cycle. Like windows xp.

“Best Effort”, Microsoft Support teams try to help you with best they can do in a defined time limitation.
These are happens mostly in resticted environments,3rd party related issues and Limited Support conditions.

“By Design” , It indicates a design limitation, Mostly this design limitations can not be exceeded or changable. This limitations only change by Product Group.
This process called “Design Change Request” and depends several conditions should be met to submit this request.

“Regression”: Some already fixed problem or non problematic component/code part causing a new issue or same issue, after new updates.

“3rd Pary”: Most common belief here 3rd party doesn’t mean only products outside of the Microsoft. Depend on what you are using some of the Microsoft products or Microsoft Consultancy Services code or components are called 3rd Party.
Isolation of the problem it may not easy in this cases. Depends on the problem,In some cases the problem should open from the 3rd party vendor instead of consumer.
Or in some cases require prior 3rd Party vendor investigation. Microsoft support help you in 3rd Party related problems affecting Microsoft Products as “Best Effort”
if it is directly idendified or isolated 3rd party related issue which is considered “Out of Scope”.
Any kind of open source project even driven by Microsoft is considered 3rd Party. Like MIM Configuration scripts.
Some Examples:
Integrating a 3rd Party software or component is considered “Out of Scope”.
Troubleshooting a 3rd party software is considered “Out of Scope”.

Special cases for AntiVirus applications. Modern AntiVirus applications works in both Kernel and UserMode parts. Working on an incident to detect Antivirus effect may only happen with Full Memory Kernel Dumps.
Which is not a quick and easy task it sometimes takes months and several log/dump collection required. If any suspicion with Antivirus, the easiest way to test the effect is to complete uninstall Antivirus application and reboot the machine.
Why uninstall and reboot ? Because this is the only way to clear kernel from 3rd. party. Even you stop the service is not enough.

Special cases for Profilers. Ofcourse it is depends which Microsoft product you use. Any kind of applications injecting its codes to processes like profilers can cause several abnormalities.
Again the best action in this scenarios test to remove/uninstall them to see behaviour.
“Custom Code”: A code or component that is not belong to out of the box product.

“Out of Scope”: This is two different usage:
1) In every support case in Microsoft support start with “Scoping” that definining problem and scope agreement. Anything out side of the agreement called “Out of Scope”.
This may require to open another case or redirecting you to another team.
For example you have 2 different environment and same problem. The Agents provide a resolution and it fixes the issue in one environment but not the other one. Thats an out of scope.
Every Environment is unique, so the problem may vary and it requires another case to investigate for the other environment.
Another example after first investigation detection of the issue is related completely a different product.
2) This is also something Microsoft Support not allowed to do in a “Reactive Incident” or “Advisory” purporse.This is also synonym of “Out of Support”
For example if you demand developing a custom code or building a SharePoint Farm from Scratch from our agensts, this is something out of scope for us.
Depends on your demand and contract, we may redirect you Microsoft Consultancy Services, an onside Premier Field Engineer or a Partner Engagement.
Another example: “Could you suggest a backup 3rd party program?” Unfortunately this is out of scope too. Microsoft Agents not allowed to do this for protection of competition reason.

“Escalation”: In Microsoft Support we have different level teams previously. Currently our model we are working on cases in a swarming manner. That’s mean different level engineers works together on any case.
So Escalation is not possible inside Microsoft Support Team. But you may still do Engineer change request. Only definition of an Escalation now, if Microsoft Support creates a fix or design change request to product group.
Well still we have level 1 engineering which our partners handling our Broad Commercial cases.

“Design Change Request (DCR)”: An Escalation request to product group to change a product design. This is not usual any more by Microsoft Agents. We will redirect you to related product’s User Voice internet sites.

“Critical Design Change Request (CDCR)”: An Escalation request to product group to change a product design that is critical for product and high business impact.
Microsoft Agents are primary source to create this requests.

“Request for Hotfix (RFH)”: An Escalation request to product group to fix some product related problem. Microsoft Agents are primary source to create this requests.
There are several conditions for acceptance like Business Impact, Time to develop, Fragility, Complexity, Incident count etc. After request submitted to product group.
They makes a triage and decide to fix or fix later(means no ETA) or won’t fix the issue.
There some key points here, Microsoft Supports only trace the progress and informs customer about results.
Product Group have own priorties and scheduling which is different than Microsoft Support.

“Unified Support”: New Support model, Here more information:

“Service Pack (SP)”:A service pack is a combination of previously released fixes, fixes which have only been released in context of the service pack and potentially new functionality added to the product.

“Cumulative Update (CU)”: Cumulative update includes fixes for problems with our product that have been reported by customer in context of support cases.

“Public Update (PU)” A public update usually includes security fixes for the product or fixes for problems which affect a broad number of customers.

“Critical On Demand Fix (COD)”: A COD is a fix which is provided only to a small number of customers affected by a critical problem directly through Microsoft Support to provide a quick relief.
The code change in the COD will be included in one of the next CUs and it is advised to install that CU on top of the COD as soon as it has been released.