Alright. So, the heading of this article will have pretty much given a brief explanation of what this post will be about and hence, I’m not going to write a brief introduction session here about this post.
Now, let’s get into the meats and potatoes ….
- Request Management Service in SharePoint 2013
For those who are new to SharePoint 2013 or if you’re hearing about “Request Management service” for the first time, please go ahead and take a look at my blog post on Request Management service. I’ve given a detailed explanation of what “Request Management service” is all about and how it works. However, to put it in simple words- Request Management service takes care of managing incoming requests by evaluating the logic rules set against them in order to determine which action to take, and which machine or machines in the farm (if any) should handle the incoming requests. Now, there’s a lot of mechanism which happens in RM service. Please take a look on Spencer Harber’s article on Request Management service to know in detail. As always, Spencer has done a fabulous job in explaining it.
In addition to this, there are couple of other important points that one should be aware of as far as Request Management service is concerned. - Request Manager is the first code that runs in response to the HTTP requests. It is implemented in SPRequestModule.
- Request Manager requires the SharePoint foundation web application service to be started on the server.
- Request Manager service should only be started on a server that’s acting as a WFE, else it’s of no use.

- Load balancer for SharePoint
Now, as you’re aware, high availability in SharePoint is achieved in the web tier level by deploying multiple front-end servers to serve web pages and host web parts. A load balancer directs traffic across these servers, monitors health, and ensures that the best possible target is used for individual requests. The default SharePoint architecture works in such a manner that any server in the farm which has the “SharePoint foundation web application service" turned on will be acting as a Web Front end server. Hence you can go ahead and turn off this service on a server that is acting as an App server. However, if your servers have enough resources, then there shouldn’t be any harm on leaving it on, as in case if your WFEs go down, you can let APP server handle user web requests temporarily.
Now, let’s discuss how they differ from each other, so that we don’t get confused by their similar functionalities:
The first thing which we need to understand is that the Request Management service becomes effective only when the user request gets passed the Network Load balancer which takes care of handling user traffic . As you’re aware, the NLB is the one which takes care of handling user traffic and if a user’s request doesn’t even get passed the load balancer, then technically it means that the user’s request is not hitting the SharePoint farm where the Request management service is configured .To put it in simple words, the user’s request needs to pass the 1st gate which is the NLB and only upon the successful completion of that, the user’s request will hit the appropriate Web front servers where the Request Management service will be configured . So, once the user’s request hits the SharePoint farm, the RM service will validate the request and will then act accordingly. I believe the image below will give you a clear understanding of how this is configured for a SharePoint 2013 farm.



Tarun DPosted Sep 1, 2016, 1:44 AM
Nice one..