SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The WFEs for our OnPrem SharePoint farm sit behind an F5 load balancer. As a result, client requestor IPs are not captured in the IIS logs as everything appears to come from the F5.

One way to get around this is to use the X-Forwarded-For header to transfer the original client IP address through to the IIS server. Unfortunately, IIS 7 doesn't support collecting this header natively.

So can I use the X-Forwarded-For header with SharePoint, and if so, how?

What tools and/or IIS plug-ins should I use?

What configuration changes do I need to make to the load balancer, IIS and/or SharePoint?

I'm looking for SP2010 answers in particular, but post any 2007 tips you may have too.

share|improve this question

I've never tried this but the IIS team seem to have created a module to solve this issue.

Its not clear if it will work in conjunction with SharePoint but there it seems worth a try.

share|improve this answer

Steve P is correct. The ARR Helper module that he linked to does the variable replace prior to the initialization of the SharePoint request. We have been using it on our SharePoint 2010 farm for several months and see the original requestor address in both the OOB SharePoint Analytics and the IIS Logs.

Application Request Routing 2.5 is supposed to include the same feature that the helper module added to v1 with additional configuration options but I have not tested it on my farm as the helper did all I needed it to.

-Robert Colbert

share|improve this answer

From SharePoint Side : I just study the case and I concluded that it is not possible to take into account the header for use in the OOTB Usage Reports (and Web Analytics). We have to "modify" the Microsoft.SharePoint.dll to achieve this goal: a job for the SharePoint Team.

If you still want to exploit this header you have to develop your own HTTP Module combined with a custom usage provider to generate ".usage" files and import them in the logging database.

From IIS Side : Perhaps there is a possibility to alter the HttpRequest before the Http Module deployed by SharePoint (« Microsoft.SharePoint.ApplicationRuntime.SPRequestModule ») process it (not sure the request could be altered....)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.