SharePoint 2010 - Reverse Proxy

by Aaron 18. January 2012 00:23

We have two web servers.  One server accepts traffic from the WAN on port 80.  The other accepts traffic from the WAN on port 443.  Our SharePoint 2010 instance lives on the former, but we only want public traffic coming to the SharePoint server over SSL.  Which, as you probably know, is port 443 by default.

What to do, what to do?

We had several options including opening up another port and allowing SSL traffic over a different port to the port 80 server.  I didn't like that idea.  In the past, for various things, I've used the IIS URL Rewrite module for various things, so I decided to see if I could put some rules in place with that.

What I found is that URL Rewrite has a template for doing a reverse proxy.  Brilliant!  Fortunately for me, it's a common enough scenario that Microsoft decided to add a rules template to version 2 of the Rewrite Module.

If you haven't done so already, and I recommend doing it regardless of whether or not you're doing a reverse proxy, download and install the URL Rewrite module.  If you already have the IIS Manager open, you'll need to close it and reopen it for the extension to show up.


Select your site in the Sites under your server on the left.  Open the URL Rewrite extension, and click Add Rule from the Actions bar on the right-hand side.  You'll be presented with a dialog.  Choose Reverse Proxy from the Inbound and Outbound Rules category.


You are likely to be presented with a dialog saying that you need Application Request Routing installed to do the reverse proxy.  Not a problem, just follow the instructions and install it.


This one doesn't have a standalone installer.  At least not one that I could find.  You'll need to install it using the Microsoft Web Platform Installer.  I didn't care for that because I wanted to keep the number of components on the server to a minimum, but I didn't have much choice.

After installing it, closing IIS Manager, and opening it again, I repeated the previous steps and this time, I was presented with a dialog related to ARR, but asking if I wanted to enable it.  Of course I clicked OK.


Finally, I was presented with a simple data entry screen to configure some server and routing  information.  I filled it out similar to this:


If you're doing what I'm doing and taking an HTTPS connection and forwarding it to an internal URL over HTTP, then make sure that the Enable SLL Offloading checkbox is checked.  Also, if SharePoint is configured properly, as I'll explain below, you won't need an Outbound Rule for rewriting URLs in the response.

Now SharePoint needs to be configured properly.  The internal domain that you use needs to be configured as an internet address in the Alternate Access Mappings, and the public URL needs to be the primary internet URL for the site.  Let me show you what I'm talking about.

In Central Administration, go to Application Management and select Configure alternate access mappings.  On the top right, there's a drop down named Alternate Access Mapping Collection.  Choose the SharePoint site that you're putting the reverse proxy in front of.

Whatever you used as the server name in the Inbound Rules for the reverse proxy, this needs to be an internal URL for the internet zone.  If it's not already, click on Add Internal URLs and add it.


If the URL that you're using is one of your public URLs for the SharePoint site, like mine was the public URL for the intranet zone, you'll need to either choose a different internal URL for your inbound rule, or you'll need to change the public URL.  I changed the public URL.

The internet URL is what your HTTPS web server is using.  So if the URL that you're using on the receiving web server is, then the internet zone in the public rules for your SharePoint site should be

I believe that's it!  Because of the alternate access mapping, SharePoint 2010 will do the work for you of updating all of the URLs in the responses to use the internet URL for any requests coming in on http://sharepoint.internaldomain.internal alleviating you of the need to have an outbound rule to rewrite responses.

Tags: , , , , ,

SharePoint 2010 - Can't Delete Search Service Application

by Aaron 17. January 2012 04:47

Yesterday, I discussed my issue where my Search Service Application wasn't working.  It wasn't crawling, couldn't connect to some back end, and searching was returning an error.  After I created the new Search Service Application, I had to delete the old one.

Sounds simple, right?  Sure, if you understand that you might not be able to delete it from the SharePoint Central Administration.

Here's the problem: the Search Service Application is selected.  Delete is clicked.  You get a fancy-looking popup with a swirling logo asking you to please wait.  And you do!  FOREVER!


That spinning logo never goes away regardless of how long you wait.  You close out and go back into the Manage Service Applications page to see that it's still there.

The solution is to use stsadm.exe.  I found this solution.  Following the solution on that page, I executed:

stsadm.exe -o deleteconfigurationobject -id "<insert Application Service GUID here>"

It didn't complete instantaneously, but it did complete.  When I went back into Central Administration, the extra Search Service Application was gone!

Tags: , , , ,

SharePoint 2010 - The search service is not able to connect to the machine that hosts the administration component

by Aaron 16. January 2012 05:05

A couple of months ago, I set up a SharePoint 2010 instance.  I had some issues, but the site was up and working for the most part.

One of the issues was the Search Application Service.  For some reason, the service wouldn't crawl the site, and it was giving me an error in Central Administration in the System Status.  The message said, "The search service is not able to connect to the machine that hosts the administration component.  Verify that the administration component '<guid goes here>' in search application 'Search Service Application' is in a good state and try again.

Also, when running a search from within a SharePoint site, I would get the error message, "The search request was unable to connect to the Search Service."  Of course it can't.  The search service isn't working, right?

I read several things that told me to change the app pool to a different one [link], make sure the indexing service is running [link], and to make sure that the search application is associated with the proxy group (same thread in the previous link).  This latter solution is what helped me out.  Not only did the contributor mention the association, but he also said that he deleted the old service and created a new one.

The first thing I tried was following his instructions of checking the "Service Application Associations."  This is under Central Administration > Application Management > Service Applications > Configure service application associations.


After clicking on the "Configure" link, you're presented with a page that has your web applications and an Application Proxy Group associated with the web applications.  Mine was named "Default" and was associated with the user site and the main site.


So, clicking on Default, I get a dialog showing me all of the application services associated with the Application Proxy Group.


I noticed that there was no Search Service in the list at all!  Looking at the "Type" I did see that everything was a whatever-service "Proxy".  My search service wasn't there, and after looking in the service applications, I didn't have a Search Service Application Proxy on the Search Service Application.  Either it was never there, or I accidentally deleted it.


I created a new Search Service Application.  After creating it, I verified the proxy was there:


Then I verified that the search service was associated with my web application:


After that, all the bells and whistles came on for the crawl status:


Finally, I now get results in my searches through the SharePoint site.

Tags: , , , ,