Thursday, August 30, 2007

Don't Use Google for ISA Health Checks

Have you or your users run across the following lately when accessing Google?

403 Forbidden


We're sorry......

but we can't process your request right now. A computer virus or spyware application is sending us automated requests, and it appears that your computer or network has been infected. We'll restore your access as quickly as possible, so try again soon. In the meantime, you might want to run a virus checker or spyware remover to make sure that your computer is free of viruses and other spurious software.

We apologize for the inconvenience, and hope we'll see you again on Google.

The trouble may not be a virus or spyware, it may be your ISA server. One of the features that ISA server offers is HTTP health checks. This allows you to configure a web address that ISA will access on a regular basis and alert you if the response time exceeds the configured threshold.

Google must be getting hit hard with spybots that frequently hit their network. They've taken steps to monitor repetitive access to the same page from a single source IP. When they detect this, they serve up the page above with something akin to CAPTCHA to ensure that a real human is accessing Google and allow you to continue your search.

If this is happening to you, it may be because you've configured your health checks to target Google. Reconfigure your proxy server's HTTP health checks to use another site.

Labels: ,

Monday, August 27, 2007

So when it catches fire, do you get caramel?

Sony has developed a battery that runs on sugar. Sweet!

Friday, August 17, 2007

Deferred Delivery Behavior in Outlook and Exchange 2003

Over time I've fielded a lot of questions about deferred delivery behavior using Outlook and Exchange Server 2003. The purpose of this post is to try and clear up some of the confusion.

Users can defer delivery using Outlook 2003/2007 by selecting the "Do not deliver before" date and time in Delivery Options of a message. This is done from the View Options menu of the new message:

My example message was sent at 12:04pm and schedule to be delivered at 12:10pm. Once sent, the email will stay in the Outbox until 12:10pm. If the sender isn't using Cached Exchange Mode, the email actually resides on the Exchange server. This means you can close Outlook and the email will still be delivered at the scheduled time. If the sender is using Cached Exchange Mode, Outlook needs to be running for the email to be delivered at the scheduled time.

Once the email is sent, it shows in the sender's Sent Items folder as being sent when the user clicked the Send button (12:05pm instead of 12:10pm). Outlook rounds the seconds up or down, which accounts for the lost minute.

When the recipient receives the email at the scheduled time, it shows in the recipient's Inbox as received at 12:11pm. This is the time the Exchange server delivered the message to the recipient's Inbox. Again, the time is rounded up by Outlook to show that it was received at 12:11pm:

When the recipient opens the email, he will see the email was sent at 12:05pm. This is the time the user clicked the Send button.

If we track the message through the Exchange Message Tracking Center, we will only see when the message was actually in transport through the Information Store. Note that there is no indication in message tracking that this message was sent with deferred delivery:

Taking a look at the SMTP headers, we see that the email was sent at 12:04:52.

Microsoft Mail Internet Headers Version 2.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: application/ms-tnef;
Content-Transfer-Encoding: binary
Subject: Email written at 12:04pm
Date: Thu, 16 Aug 2007 12:04:52 -0700
Message-ID: <>
X-MS-TNEF-Correlator: <>
Thread-Topic: Email written at 12:04pm
Thread-Index: AcfgOE14IdGWt/ZvRTS3VBrfx1yACQ==
From: "Jeff Guillet" <>
To: "Brian Peladeau" <>

Hopefully, this helps clear up some of the confusion about deferred delivery.

Labels: , , ,

Thursday, August 16, 2007

Installing ISA 2004 SP3 Remotely

I do most of my work remotely using Remote Desktop Protocol (RDP).  Best thing since sliced bread!!
Working on ISA remotely can be tricky, especially if the ISA server is the Internet firewall.  Anytime you need to bounce the ISA services or the server itself you'll drop the RDP connection.  If you're using a current version of Remote Desktop Connection (mstsc.exe), the connection will drop and RDC will automatically attempt to reconnect to the server.
Recently, I had to do some work on a customer's ISA 2004 server that required me to upgrade the server to ISA 2004 Service Pack 3 (you can download SP3 here).  Naturally, the installation will stop the ISA services when the upgrade is being performed. 
Having tested the SP3 installation in the lab, I found that ISA 2004 SP3 installation takes about 3 minutes, but doesn't always restart the services after the upgrade.  To keep from getting "shut out" from further remote administration I ran the following command from the CMD prompt before the upgrade:
shutdown /r /t 300 /f /d p:4:1
This command will forcibly restart the server in 5 minutes (300 seconds) with the shutdown reason of "Application: Maintenance (Planned)".  I then proceeded to install ISA 2004 SP3.  If the connection is restored after the upgrade, I run the following command from the CMD prompt to abort the server restart:
shutdown /a
If the services don't start (as was the case in my situation) the server will automatically restart and connectivity is restored.

Labels: ,

Tuesday, August 14, 2007

ASP .NET 2.0 is Reported Missing

Various applications may return a failure indicating that ASP .NET 2.0 is missing, even though it's installed. Systems Center Operations Manager 2007 (SCOM) is an example.  This failure occurs if you install Internet Information Services (IIS) after you have installed .NET Framework 2.0. If you install .NET Framework 2.0, then install IIS while selecting ASP .NET 2.0 as an optional component, the ASP .NET 2.0 extensions might not be registered correctly in the IIS metabase.
The workaround for this is to go to the <SYSTEMDRIVE>\Windows\Microsoft.NET\Framework\v2.0.50727 folder and from a command prompt, run the command aspnet_regiis.exe –i –enable.