Who is listening on port 80 (http.sys ?)

In normal conditions there are several ways to check ports on a system.And there are lots of tools around like SysInternals, TCPView or good old “netstat -ano”.

But wait a minute, if we look netstat -ano;

As you can see my port 80 is reserved by “System” process (where PID=4) . Well it is easy to understand if your server installed Web Server like Apache, IIS or IISExpress to figure out who is using it but what if you don’t have any web server in your machine but who is then using port 80 ? OS itself ?

Well, I can tell you, definetly it is not “system” process itself. System process is only serving requested port for another process if your application utilize http.sys driver.
HTTP.SYS is a kernel driver so runs  under system process obviously.

Even you can use C# “HttpListener” to create small program that listen on a port by utulizing http.sys easily.

But is there any way to see which process actually using http.sys and bind this port ?
Netsh http show servicestate
It will give you all bindings for registered sessions.
Registered URLs:
Server session ID: FF00000220000001
Server session ID: FF00000020000001
Server session ID: FF00000120000001
Server session ID: FD0000012000001F

if you check the request queues section in results you can also see process identifiers.
Well the command results not exactly user friendly to show which PID matching which binding.But each session id order also match on printed request queue result.

Request queues:
Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /*first one*/

Request queue name: Request queue is unnamed.
Version: 1.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /*Second one */

Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /* Third one*/

Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Number of active processes attached: 1
Process IDs: /* Forth one*/

If i am looking for “HTTP://*:8855/” this binding the process ID is 19552.
For my port 80. PID => 6392.

When i checked with taskmanager; it is svchost.exe. Commandline column of task manager says:
PeerDistSvc is the guy in my case.



Win10 Search from Start shows a black box

This was an issue with the online Search service.

We are aware of a temporary server-side issue causing Windows search to show a blank box. This issue has been resolved for most users and in some cases you may need to reboot your machine.


This issue was resolved at Feb 05/2020 12:00 PM PST. If you are still experiencing issues, please restart your device. In rare cases, you may need to manually end the SearchUI.exe or SearchApp.exe process via Task Manager. (To locate these processes, select CTRL + Shift + Esc then select the Details tab.)

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.


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.