I stressed the importance of keeping the Intelligent Message filter updated on various occasions. Spam is a moving target and IMF must follow it closely in order to keep up. We discussed this topic in Welcome to IMF Regular Updates and IMF Update Tips. Today I will focus on a specific issue that sometimes is reported at the newsgroups.

Basically the problem goes like this. SMTP email flow halts following the installation of an IMF Update. Digging a bit further it normally turns out that the IIS Admin service is stopped. I will straight away hint you that in reality normally there is nothing wrong with the IMF update. However the symptoms do give this impression.

Firstly it is worth remembering how Exchange 2003 heavily relies on IIS for its internet protocol support. In this case we are interested in SMTP. Apart for implementing the SMTP service, IIS also provides invaluable integration opportunities. Exchange plugs into IIS such that to adopt SMTP as its native transport. The IIS SMTP is also the natural host for the anti-spam Intelligent Message Filter. This is why updates, in order to restart IMF, have to restart the IIS Admin service.

However Exchange is not the only application exploiting IIS extensibility. Many third parties developing Exchange integrated solutions also plug into IIS in the same manner. Anti-spam, anti-virus and many other applications find the IIS interfaces very welcoming. Compounding everything we find the software version of the United Nations, with friends and foes running under the IIS hood.

So when an update restarts IMF, it actually does a lot more than that. It restarts IIS Admin and all components pluging into it. Every single plug-in has to shutdown and re-initialize itself. Depending on the machine resources and the type of extensions installed, this can be time consuming and failure prone. Any malfunctioning component could interfere with the restart process keeping the service down.

One could legitimately ask, why would have the component not exhibited problems at an earlier stage? The answer is that the component might have experienced temporary problems. Maybe it had a lot of time consuming cleanup operations causing it to fail due to a timeout. This is probably one of the most common reasons and a manual restart of the IIS Admin service would get everything back to normal.

A component with more serious problems might have signalled error events that went unnoticed. Otherwise the component might have only reported the problem during the restart because it only performs a thorough self-checking on start-up. Whatever the reason, start-up time is known to be a critical phase for most applications.

My advice is that if such a problem surfaces one should not jump to the conclusions that the IMF update is broken. Indeed I have never experienced a broken update myself and today I apply these with my eyes closed.

If starting IIS Admin manually succeeds then the timeout/temporary failure situation is the most likely. If the service still fails to start, you could uninstall the update from Add/Remove Programs. However don't be too surprised if the problem persists. As highlighted in this discussion the update might still be innocent. In that case try looking closely at what is running on the server. Disable applications that integrate with Exchange by elimination and see if the service starts. At all stages keep a close look at the event viewer and see what error events come up.

References

Welcome to IMF Regular Updates

IMF Update Tips