When we released our new system back in February we got most of our users printing with minimal support.  We encouraged all of them to upgrade to IE 7 (many were still using IE6) which did fine with the control.  Shortly after our launch Microsoft started rolling out IE8 and our users slowly started upgrading.

That’s when we found many of them having issues printing.  As you’ll see in this screen shot, they would simply get a generic error when clicking the print button, even after successfully installing the print control.  As a work around we were having folks export to PDF and then print from there.  Obviously this wasn’t an ideal solution and we started troubleshooting to figure out what the problem was.

After doing some testing on our end on virtual machines we were able to reproduce the problem and narrowed it down to Windows Vista running IE8.  Since we weren’t able to resolve the problem on our virtual machine configuration with anything we tried we eventually opened a support ticket with Microsoft.

After some support calls with Microsoft they informed us that in order for this to work properly you have to add the site that’s using the report viewer control as a trusted site if you’re using Internet Explorer 8 and Windows Vista. We thought this was odd because we definitely had tried this on our virtual machine setup and didn’t have any luck.

What we found out on our own later was that as that this solution does not seem to help if you originally started out with a Beta or RC (Release Candidate) copy of IE8 that had been upgraded to the final release.  That was the scenario we had on our virtual machine that we were using to test IE8 and even the trusted site fix didn’t help in that scenario.

So, if you are having this problem and you’re using a clean install of IE8 or an upgrade to the final release of IE8 from a previous version adding the trusted site to fix this problem is easy.

Just open up IE and click Tools > Internet Options and follow the steps shown here in the screen shot to add your site as a trusted site:

Restart your browser and you’re in business.

Now if they could only get away from Active-X so our users that decide not to use IE can print.

While not a new concept, for some reason I really hadn’t researched this too much before recently.  I knew that IIS 7, which we aren’t using,  had great support for this but didn’t think IIS 6 could support it.  After not much Googling I was all setup with HTTP compression and immediately noticed some great results (measurements were done with Fiddler, check it out if you want to debug your HTTP traffic).

This process I’m going to describe can easily be found out on the interwebs.  I figured I’d just streamline it a bit, provide some screen shots, and take out all the extra crap that I read to get my ASP.NET site screaming with HTTP compression.

You need to know is that these changes will require you to bounce (restart) IIS in order for them to take effect.  So, plan to do this during off hours or set them aside for your next regularly scheduled maintenance window.  Don’t just go and tweak all of this on your production web server in the middle of the day.  That would be bad!

The first thing you’ll want to do is open up the Internet Information Services (IIS) Manager on the target server.  Once in the management console you’ll want to right click on the name of your server and select All Tasks > Backup/Restore Configuration.  This will allow you to create a backup of everything in case you screw something up while trying to do all of this.

Luckily I didn’t need to use this but you can never be too careful.

After you save all that you will want to go back to that same server node and right click again.  This time you want too bring up the properties for the server instance.  From there, click the check box labeled Enabled Direct Metabase Edit.

Enabling this will allow us to later edit the metabase file (XML) directly.  This is much easier than trying to run some of the command line utilities that you can use that basically accomplish the same thing.  Some may disagree, but I feel like I can change a few values in an XML file way more quickly than trying to get the cryptic syntax right for various IIS script utilities.

Next, expand the local server node and right click on the Web Sites folder to bring up the properties.  From there select the Service tab and enable the Compress application files and Compress Static files check boxes.

Optionally, you can change the temporary directory where IIS will store the compressed files (default is %windir%\IIS Temporary Compressed Files) and put a size limitation on this folder.  I left both of these options with their default values.  I will probably revisit the size constraint option once our site is live and I can watch it for a while.  For now, unlimited is fine.

Next, go back up a level in the IIS management console and right click on Web Service Extensions and choose Create a new web service extension (as opposed to Web Sites, which we were just using).  Call the new extension HTTP Compression and point it to %windir%\system32\inetsrv\gzip.dll.  Finally, before you click OK be sure to check the Set status checkbox so that it is enabled (Allowed).  When it’s done you’ll see the new extension listed like this:

The good news is that you have set all of the settings that you need to get HTTP compression working in its most basic form.  If you restart IIS (I always use the trusty iisreset command) you will be compressing your HTTP requests right now.  The bad news is that the most basic compression won’t do you much good if you’re serving up anything other than Classic ASP pages or static HTML files.  The fix for that is to edit that Metabase file that we talked about earlier.

I’m not 100% sure if you really need or want to restart IIS now or not.  To be safe I would probably go ahead and do it.  When I first went through this process I was pulling information from a few different resources so I did things in more of a step process.  You’re getting a step by step list of things that I found over the course of a few different days.  So with that said, go ahead and restart IIS to get the compression working.

Now the easy GUI part is over.  We’re going to open up the Metabase file and start to change some values in the XML.  What you need to do is open up the Metabase.xml file located at %windir%\system32\inetsrv\Metabase.xml in Notepad or some other text editor.  Once opened we want to find the sections that look like this (search for compression/deflate):

We need to tell the types of extensions that each scheme is to support and compress. The static types need to go under the HcFileExtensions and the dynamic under HcScriptFileExtensions.  This needs to be set for both the gzip and deflate entries (so you’ll add each extension twice).  Like the samples show, you need to put each extension that you add on a new line.  Be sure to follow this carefully as I recall reading something that said IIS is very picky about this.  Here are the extensions that I added:

Static (HcFileExtensions):

• htm (default)
• html (default)
• txt (default)
• css
• js

Dynamic (HcScriptFileExtensions):

• asp (default)
• dll (default)
• exe (default)
• aspx
• asmx
• ascx

Finally be sure to set the HcDynamicCompressionLevel values to 9.  The level of compression for dynamic content is set to 0 by default. This could be increased to a maximum of 10 depending on your available CPU resources. Everything I read says that generally setting it to 10 is bad; in most cases it will have a negative impact on your throughput. This is something you’d need to do some tests with to figure out what works best for you. It’s also worth noting that setting it to 0 does not mean no compression, it just is a lower compression (which also means it will be the fastest).  I went with 9 to be safe and it seems to have worked out fine for me.

The end result looks like this:

Do another reset of IIS and you’ll be compressing content used by most ASP.NET sites.  You can obviously add more extensions to some of the areas if needed.  There are a few things like axd fieles that I considered compressing but read that it could cause all kinds of problems.  I am going to continue to research this and may do some testing for myself to see if I can potentially add this file type in to my dynamic (script) extension list.

Final Notes:

You should know that the process I’ve described here enables compression for all of the sites on your server.  If you would like to target only one website or a smaller subset of sites you will need to make some additional changes in the Metabase file in other areas (i.e. IISCompressionSchemes node).  I didn’t do that so I am not going to go into detail about that.  If that’s something that you want to do it shouldn’t be too hard to find additional information on doing this.

Also, while I stated in the beginning that enabling this was a way to get a “free” performance gain, it’s obviously not free.  You’re going to pay the price somewhere.  In this case the server will need to do more processing/work now to compress these files before they’re sent down the wire to your users.  Based on what I’ve read and what I’ve seen from my testing, IIS 6 is pretty darn efficient with this and as long as your CPU load is under 80% you should be fine to enable this.  That obviously will need to be a decision that you make based on the amount of traffic your site gets, the hardware your server has, etc.

After lots of reading and testing, I ended up reducing the size of most of our page requests by as much as 95% in some instances. In the next few posts I will go over, in detail, how you can use the following steps to optimize your ASP.NET (and non-ASP.NET) web applications with only a little bit of work:

• Enabling and configuring HTTP compression in IIS6
• Enabling content expiration for static content (graphics, css files, JavaScript files, etc) in IIS6
• Changing your application to store ViewState in the session rather than in each page
• Configuring Telerik’s Radcontrols to work as efficiently as possible

So far I’ve been very happy with it.  I am running it on my Macbook Pro with VMware Fusion 2.  Even though VMWare doesn’t officially support it yet it went on automatically when I picked Windows Server 2008 64-bit as my operating system when I setup a new VM for it.  All I had to do was put in the product key that Microsoft emailed me when I signed up for the beta and it was up and running in no time.

I only allocated 40GB of Hard Drive space to the VM and 1GB Ram (I have 4GB total).  So far it has been running great on that and seems to be much quicker than the Vista VM I had setup before.  From everything that I’ve been hearing Windows 7 is basically a cleaned up and more stable version of Vista.  So far I agree.

The next steps for me will be to install Visual Studio 2008 and SQL Server 2008.  Since Windows 7 comes pre-loaded with Internet Explorer 8.  One odd/annoying thing that I’m finding is that the Beta version of IE 8 that comes can’t be upgraded to the RC1 version they just put out this week.

For those of you that don’t know.  RC means Release Candidate, and is the final testing version before a software product is released with it’s final version.  The release cycles are typically:

1. Alpha
2. Beta
3. RC (Release Candidate)
4. RTM (Release to Manufacturing or Release to Marketing)
5. GA (General Availability)

Here’s my advice to you as far as Internet Explorer 8 goes.  If you insist on using IE, make sure you’re using at least IE 7.  I would not start using IE 8 until it’s released in a final version.  If you’re only using IE because that’s what came with your computer, do yourself a favor and go and download Firefox (for free) right now.  It is way faster than IE, much more secure, and will give you a much getter browsing experience.

What I quickly found was that IIS didn’t offer a way to automatically redirect any non-secure requests to a secure version of the same page, or some other page (i.e. http://www.yoursite.com/login.aspx redirect automatically to https://www.yoursite.com/login.aspx).

Luckily after spending a good amount of time Googling I found this post that involves a handy tip that you can use to change the custom error page for error 403;4 (the one displayed when you try to view the non-secure site).  I won’t re-state everything from his blog post, but it definitely has everything you need to get around this problem if you’re in the same boat.