Developers – Beware of Skype grabbing port 80….

I just posted this information as an update to an earlier post about problems with the Reporting Services /ReportServer and /Reports virtual directories sometimes not responding on port 80.  Today I realized that my problem wasn’t limited to just Reporting Services.  This morning, none of my IIS hosted sites were responding.  I’d get 404’s for anything I tried.

It turns out that by default, Skype will use both ports 80 and 443 as alternatives to its regular port for incoming connections (for firewall purposes).  If Skype get’s to port 80 before the System does (not sure how, but it happens), then Skype grabs the ports and prevents the other services for receiving any requests.

To turn this off in Skype, open Skype and go to “Tools” | “Options”, on the left hand side of the options dialog select “Advanced” | “Connection” and then turn off the checkbox for the “Use port 80 and 443 as alternatives for incoming connections”.

Skype port 80 usage

A Quick FYI, the tools I used to figure it out were Fiddler, the netstat command line utility included with windows, and the Windows Task Manager, and the web.

First, Fiddler.  As I used fiddler to try and browse local sites, I got a VERY basic 404 Response back.  No server information or anything.  That let me know that I wasn’t hitting IIS.

Next, netstat.  To figure out which process was grabbing my port 80 traffice I used “netstat –ao” and saw the Process ID 2384 was the process listening on port 80.

On to Task Manager.  I looked that up in my task manager, and found that it was Skype.

Finally a web search. Did a quick search on Skype and Port 80 and found a number of hits discussing the same problem.

Normally, the System process should be grabbing port 80.  If you open a command prompt using the “Run as Administrator” option and run “netstat –ao” you should see the PID (Process ID) that is listening on each port.  Then open up your Task Manager (or better yet Process Explorer).  In task manager, switch to the “Processes” tab and use the “View” | “Select Columns…” menu to enable the “PID (Process ID”) column to be displayed.  You should see something similar to the following:

System using Port 80

Today however, when I looked I found Skype’s process ID, not System’s.  (Sorry, I didn’t take a screen shot when I had it).

This isn’t a problem if you are using Visual Studio .Net’s development web server (aka Cassini) because it uses a dynamically chosen port for each site. It could be a problem if you are hosting any sites in IIS or trying to use things like SQL Server Reporting Services which has web based components that want to listen on port 80.

So I put this here for me to remember the problem, and in hopes that it may help some other frustrated developer out there.

Configuring IIS on 64Bit Windows 7 to Work with the Access 2007 OLEDB Driver

I have been working on a website for a client where they need to be able to upload Excel 2007 files with updates for the data the website uses.

In order to easily extract the data from the excel file from my .Net code, I have been treating it as a database by connecting to it using the Microsoft.ACE.OLEDB.12.0 driver with a connection string like this (The following connection string should be all on one line):

Provider=Microsoft.ACE.OLEDB.12.0;
Data Source="C:\MyExcelFiles\ExcelFile.xlsx";
Extended Properties="Excel 12.0 Xml;HDR=YES";

My current development machine is a 64bit version of Windows 7 RC box (haven’t installed the release version yet) with Visual Studio 2008. My site has been working fine using the Cassini web server built into Visual Studio 2008. However, when I tried to change the startup options to using the local IIS instance, I was receiving the following error:

"The ‘Microsoft.ACE.OLEDB.12.0′ provider is not registered on the local machine."

After some searching around, I found a number of blog and/or forum postings that addressed various possible solutions.

IIS 7.0, Access 2007 and ASP.NET 2.0 by Steve Scholfield in which he suggests installing the driver. However I knew the driver was already installed on my machine because I had been using it fine in Visual Studio’s web server.

Other forum postings seem to repeat variations of a suggestion in a post by Thomas Deml, Group Program Manager for IIS at MS where he suggests a command similar to the following:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/applicationPools -applicationPoolDefaults.processModel.loadUserprofile:false

However, I wasn’t convinced that security was my problem. Finally a came across a blog posting on Chris Crowe’s (IIS MVP) blog. In that post he suggests that the problem he was having when receiving the "The ‘Microsoft.ACE.OLEDB.12.0′ provider is not registered on the local machine." error had to do with the fact that there was not a 64bit driver, and his program was being run as 64bit.  He suggested compiling the program to run as 32Bit rather than 64bit. 

With an ASP.Net website in Visual Studio 2008, you don’t get to set the output.  Instead, the fix appears to be to configure II7 to run your program to access 32bit stuff. So….

To fix it (at least this is what works for me):

  1. Open IIS Manager
  2. Select "Application Pools" under your server in the "Connections" panel on the left.
  3. Select your application’s application pool from the "Application Pools" panel in the middle.
  4. Right Click on your Application Pool and select "Advanced Settings…"
  5. Set the "Enable 32-Bit Applications" setting to True

image

I should mention that I DO have User Account Control settings at the default, and am having to run IE8 using the “Run as Administrator” option because I am also trying to use Windows Authentication to access the site.  They may be part of the reason I don’t have a security problem where as some other folks do.  I don’t know that for sure though because I have not tested it.