Prevent Time Warner from Hijacking Your Bing Address Bar Searches

by Aaron 26. September 2013 19:43

I use Bing as my default search engine and browser home page.  What can I say?  I like the daily Bing image!  I also like Bing as a search engine.  If I can't find something on Bing, I sometimes fall back to Google, but that's pretty rare.

I noticed over the past week or two, when I do a search in the address bar, I end up with a Time Warner search page.  I thought maybe it was my new cable modem since it doesn't happen when I'm at work on the same laptop.

I searched around for some answers and found that some other people are experiencing the same thing.  One answer I found was to update my DNS servers to the Google public DNS servers.  I tried updating the DNS server entries on my router without any success.

I found that I could see the bing.com address in the address bar just before it switched to the Time Warner search page.  So I ran Fiddler2 to capture the traffic.  I did a search from the Bing home page directly to see the differences.

The major difference that I found is that the Bing add-on for IE uses a query string parameter named src with a value of ie9tr.  When I take that query string parameter out, the URL from the address bar search goes through and I get Bing results back.

The trick is to open the registry editor and go to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes\{0633EE93-D776-472f-A0FF-E1416B8B2E3A}.  Look for the TopResultURL value.  Edit the data changing the data from http://www.bing.com/search?q={searchTerms}&src=ie9tr to http://www.bing.com/search?q={searchTerms} removing "&src=ie9tr".

After doing that and restarting Internet Explorer, my address bar searches now go through without being redirected by Time Warner.

Tags: , ,

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.

image

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.

image

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.

image

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.

image

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

image

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.

image

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 https://sharepoint.domain.com, then the internet zone in the public rules for your SharePoint site should be https://sharepoint.domain.com.

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!

image

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.

image

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.

image

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

image

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.

image

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

image

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

image

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

image

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

Tags: , , , ,

Blog Publishing with Windows Live Writer

by Aaron 28. December 2011 05:46

I subscribe to quite a few blogs.  I put them in Google Reader so that I can easily read them from my phone or my tablet.  When I run across one that seems like it might be useful to me, either now or later, I "star" it.

Recently I decided to go back through my starred posts looking for posts on useful utilities.  I really look for anything that can keep my machine clean, running faster, help with productivity, whatever.  I wish I could double-star those because of how useful I find them.

This time around, the article that stood out for me, and I've gone back to it several times, is Scott Hanselman's 2011 Ultimate Developer and Power Users Tool List for Windows.  Say that three times fast.  Seriously.

The author, Scott Hanselman [blog | Twitter], apparently updates this list every year or two.  I already use a few of those utilities, but the one that I overlooked until a few days ago is Windows Live Writer.

One of my [failed] goals this year was to do a lot more publishing on all of my blog sites.  I find that it's maybe more than a little inconvenient to log into the various sites, go into the editor, which may or may not be very friendly (it is the web after all), write, spell-check, proof-read, and publish.  Windows Live Writer gives me a unified front for doing just that.

When I set up Windows Live Writer for this blog site, and the others, it downloaded the stylesheets.  It appears to be giving me an accurate view of what my post will look like once it’s published to the site!  The rich text editor in BlogEngine.NET doesn’t even do that for me.  There's a Preview tab so if this isn't good enough, I can see what it’ll look like on the site itself.

While this is obviously going to help me publish more blog posts, I still need to find something for mobile devices.  I find that using my tablet is easier than carting my laptop around the house.  Also, the aforementioned rich text editor in BE.NET isn't very Android browser friendly.  If anybody has a recommendation for something on Android, I would love to hear about it.

Tags: , , , ,