Update: This article covers removal, see the IE9 Blocker Toolkit from Microsoft to keep it from installing. If you’re looking for registry options, the important values are DoNotAllowIE90 and DoNotOfferIE90 in HKLM\SOFTWARE\Microsoft\Internet Explorer\Setup\9.0.

I’ve had to remove Internet Explorer 9 from a variety of new PCs lately because they’re connecting to online services (hospitals, medical labs, radiology services, etc.) that are not yet compatible with the new version, including issues in Compatibility mode. I’ve also needed to provide instructions (now reproduced here) for some physicians to do the same on home PCs so they can connect into those same systems.

Here’s a bit of a writeup I did for some folks who were being hit with a bout of malware email messages (the actual attachments were being removed by our filters).

The message(s) you received were an attempt to infect your computer with malware, the mail server on receiving the message removed the dangerous attachment but in general if you receive an attachment that you’re not expecting, do not open it – malware writers are creative and may come up with something that the mail server won’t block, at least not while the attack is new. This is the first attempt I remember seeing that pretended to be travel arrangements, but it’s not a surprising development.

We had a problem last weekend with Postfix not accepting email for a single domain when it was coming from outside our network, while messages from hosts on the local network were accepted and routed with no problems. Messages from outside the network were rejected with a 450 (temporary) code and the error message “Recipient address rejected: Domain not found”. The cause did end up being a DNS problem (apparently the most common kind of issue with Postfix), but not one that I would have expected (a missing host entry for the top-level domain, so example.com wouldn’t resolve even though mail.example.com did). Finding the source of the problem was complicated because of a set of several changes during a weekend maintenance window.

I ran into a minor difficulty recently on a Linux desktop PC (CentOS 5.4) updated to the recently released OpenOffice.org 3.2, specifically the Go-Oo.org variant that includes some options and tweaks left out of the primary branch. OpenOffice.org 3.2 would start without difficulties, but as soon as I started to type the application would completely freeze up or hang. I only checked this in Calc and Writer, but I suspect that it applies to all of the other components as well and from what I’ve read it’s not specific to CentOS (or other RedHat-derived distributions).

I had an interesting problem with a server (Windows 2003 Standard) at a small business (6 users total) the other day – a very long startup time. The server in question is a standalone domain controller/DC as well as a database/application server and file/print server. Terminal Services is installed & configured, but rarely used – mostly for access from outside the office. Database and domain services/authentication were available fairly quickly, as were console logins (via UltraVNC/uVNC) – probably 15-20 minutes to that stage, but more than an hour before terminal services/remote desktop was available.

Digging around on the console attempting to track down the source of the problems, I found multiple services listed as “Starting” – all of them malware-based, with the actual infection cleaned out. My suspicion is that these non-startable services were causing the startup of other services to be delayed, though in this case I’m not really planning on setting up a test system to verify that.

In the rest of this post I’ll give a bit more detail on the scenario, what I found, what was needed to clean it out, and a few more notes on what I suspect was happening.

Ran into an interesting problem this evening – I was helping someone who was having problems with installing Office 2007 on an XP system with Office 2000 (I believe Professional) installed. The problem was that when the actual installation process started, it would hang up because another installation was running.

The standard fix for that is restarting the system to let the in-progress installation do the processing that it needs a system restart for, but in this case that wasn’t the issue.

Earlier this week I spent some time troubleshooting a browser-based application that a client is using. The problem cropped up on a PC with a clean install of Windows XP SP3 after assorted system corruption that wasn’t worth the time to repair.

Spent some time recently with a Windows XP laptop that would see networks fine (although IP address acquisition via DHCP seemed slower than I’d expect), but which was unable to resolve names with DNS. This was affecting IE, Firefox, ping, basically anything that used the built-in Winsock calls such as gethostbyname(). NSLookup, on the other hand, worked just fine.

The first thing to do when facing any computer problem is to figure out where the problem lies, so it was time for a bit of sleuthing.