Tag: ASP

CDO Error Message “Error ‘80040211’”

C:Amie/ / IIS, Microsoft, Programming, Software

System Requirements:

  • Windows Server
  • Internet Information Services
  • ASP
  • CDO

The Problem:

When attempting to send an email using CDO under Windows Server you receive the following unspecific error message from your application debugger or web browser session:

error ‘80040211’
<path>/<file>.asp, line ##

Your application is unable to relay email into the SMTP system.

More Info:

The CDO error message is certainly due to your configuration of the SMTP server, or CDO’s inability to raise the stated SMTP server.

Step 1

A frequent cause of this error message comes from messages with lengthy message lines. It is common place within SMTP systems to refuse to transmit text lines that are greater than around 1000 characters (including the CRLF).

This does not mean that the message itself cannot be greater than 1000 characters, but that individual lines before the carriage return must be less than or equal to 998 characters (the CR [carriage return] and the LF [line feed] count as the remaining two characters).

This rule applies to plain text and to HTML messages. Ensure that your messages comply with this rule.

 

Step 2

Ensure that your ISP does not require authenticated SMTP access. If they do, you will need to modify your CDO connector to include authentication. In ASP this is achieved through the addition of the following lines into the CDO settings.

.Item(cdoSMTPAuthenticate) = cdoBasic
.Item(cdoSendUserName) = “YOUR-USER-NAME”
.Item(cdoSendPassword) = “YOUR-PASSWORD”

 

Step 3

Ensure that your system is able to connect to to the SMTP service port. A quick trick to check for SMTP connectivity without relying upon port scanners is:

  1. Open a command prompt
  2. Type:
    telnet <fully-qualified-domain-name / SMTP Server IP address> 25For example: telnet smtp.www.c-amie.co.uk 25
  3. If the path to your SMTP server is being blocked you will see the following message
    Connecting To <server>…Could not open connection to the host, on port 25 : Connect failed

If your server is unable to access the STMP network, then this error message is consistent with such a failure. The most likely cause of such a block is a firewall rule from a software firewall or a rule configured on a hardware firewall by the network administrator.

An additional consideration to make while checking for connectivity is the impact that Anti-Virus and real-time Anti-Spyware products may have. For example, McAfee Virus Scan Enterprise 8.0.0i makes use of an anti-spyware rule that prevents mass mailing worms from sending email. McAfee will block the SMTP port by default and must be configured to allow IIS (or your application) to relay email.

To reconfigure McAfee Enterprise 8.0.0i:

  1. Open Virus Scan Console
  2. Double click Access Protection
    McAfee Filters
  3. Highlight the “Prevent mass mailing worms from sending email” and click Edit
  4. For IIS 6.0 running in with standard IIS 6.0 application protection add w3wp.exe to the exceptions list.
    Exceptions List
    For application you will need to query the McAfee log file for the executable name involved in the error message. By default this log can be found at:
    C:\Documents and Settings\All Users\Application Data\Network Associates\VirusScan\AccessProtectionLog.txt

“Server Application Error” error message when attempting to run ASP page under IIS 5.0

C:Amie/ / IIS, Programming

System Requirements:

  • Windows 2000 & IIS 5.0

The Problem:

Yet another hpcfactor.com server failure later and we have some new problems. When attempting to parse asp pages, the browser retorts with an error headline “Server Application Error” and populates the event log with Event ID 36:

The server failed to load application ‘/LM/W3SVC/1/Root’. The error was ‘No such interface supported’

Note that the 1 in /LM/W3SVC/#/Root can be any number representing the identifier for any virtual web on your server e.g. ‘/LM/W3SVC/2/Root’, ‘/LM/W3SVC/3/Root’, ‘/LM/W3SVC/23/Root’.

HTML pages will display correctly, however anything that is running through the ASP interpreter will fall foul of this error message.

An additional symptom that you may have noticed is that the error will only occur if your Application Protection settings in IIS 5.0 are set to Medium or High.

More Info:

In the case of hpcfactor.com the problem began quite innocently with Teoma (Ask Jeeves’ crawler) starting a run over the site root, and suddenly stopping seemingly randomly when the server kicked back a 500 error:

Out-of-process ISAPI extension request failed

From that single request on, for another 6.5 hours before an administrator noticed every single request to the ASP interpreter on the particular server returned another 500 error:

Out-of-process ISAPI extension has exceeded crash limit.

Rendered in MSIE as:

The server has reached the maximum recovery limit for the application during the processing of your request. Please contact the server administrator for assistance

In playing around with the server for a little while, restoring a metabase backup and repairing some lost NLS files, we were able to get the server to perform again without the ISAPI errors, however the server would not output any ASP, returning “Server Application Error” every time and for each page request writing Event ID 36 to the System log.

I quickly discovered that if I lowered the Application Protection settings from Medium, to Low, the site would correctly load ASP pages, however there is an inherent problem in doing this – it does not lead to good stability; in fact you are essentially running IIS 5.0 as if it were IIS 3.0.

Low (IIS Process): This is the way IIS ran prior to IIS 4; all requests are performed in the InetInfo.exe process. This is the fastest option, but it is also the least robust because a rogue application could crash the InetInfo.exe process.

Medium (Pooled): This is a new option in IIS 5 and is the default setting for all new Web applications. In this model, all parts of the Web space marked as Medium (Pooled) run in the same process external to InetInfo.exe. As already mentioned, the process name is DllHost.exe and this process does not run as LocalSystem as InetInfo.exe does. Instead, DllHost.exe runs under the identity of an account controlled by IIS. By default, the identity is IWAM_machinename.

High (Isolated): This option, introduced in IIS 4 and shown in Figure 5-33, executes each Web .application in its own instance of DllHost.exe that runs in the context of the IWAM_machinename account. In doing so, it offers the highest degree of robustness, but it’s not as fast as Medium.

Source: MS Press Book Sample

In case you have read anyone else’s ideas over doing this – this is NOT a solution, it’s madness unless you are hosting your own little photo album for Billy Bob and the rest of the clan.

The common link between the higher process modes is obviously the IWAM_machinename account on the system, there is some excellent advice around the Internet on troubleshooting it already, and unless the next line matches your case, I suggest for follow it – start by re-synching the IWAM account using the AdminScript for IIS 5.0.

The next line: Check to see whether IIS is still registered in the COM+ registration database.

MMC the console applet found at %SystemRoot%\system32\Com\comexp.msc

If you see this, troubleshoot IWAM
ASP COM+ Registered
If you see this, you know why ASP doesn’t work (It should look like the image above)
ASP COM+ Failure

Effectively it is not possible to utilise Application Protection without the COM+ registrations. To fix them:

  1. Backup your server
  2. Backup the IIS 5.0 metabase
  3. Stop IIS Admin and associated services
  4. Pull up a command prompt
  5. Enter (Case sensitive):
    rundll32 %windir%\system32\inetsrv\wamreg.dll, CreateIISPackage
  6. Hit OK
  7. Enter:
    regsvr32 asptxn.dll
  8. Hit OK
  9. Restart IIS Admin and associated services
  10. Return to the comexp.msc view and check whether the three IIS registrations have returned, if they have start returning your web sites to Medium (Pooled). You will need to restart IIS in order for the Application Protection change to take effect.

Error: “Could not use ‘(unknown)’; file already in use” when using Microsoft Access databases in conjunction with IIS, Dreamweaver and others

C:Amie/ / IIS, Microsoft, Programming, Software

System Requirements:

  • An Access database
  • Internet Information Services (IIS) 4.0, 5.0, 5.1, 6.0, 7.0
  • Dreamweaver

The Problem:

This error can arise for a variety of reasons, however the specific one which prompted me to write this was to do with using IIS and Dreamweaver to fiddle with its ‘Application’ management system for connecting to and inserting dynamic information onto web pages.

When you attempt to use the database you receive the following error message in your web browser:

Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access Driver] Could not use ‘(unknown)’; file already in use.
/<file>.asp, line #

This occurs despite giving the IUSER_<system_name> account permissions to access the MDB file.

The Fix:

This could be:

  • A bad/corrupt MDAC install
  • An old MDAC install; ensure you are using 2.8
  • An old version of JET – ensure that you have the latest 2000/XP/2003 service pack or have installed Jet 4.0 SP8 on anything else

However is is more likely that you are running into a permissions error (yes, even though you gave the IUSR_<system_name> permissions on the MDB).

When you are using an Access database, of course the IIS service account IUSR_<system_name> needs to have correct permissions on the .MDB file that you are using. This goes without saying.
If you haven’t got that far, ensure that you have disabled simple file and folder sharing (on XP Pro) and offer up modify permissions or higher (do so with care) on the .mdb, however this will not solve the error!

When you use an Access database, during that fleeting second when the database is being structurally polled, Access will lock the database to prevent concurrent activity from taking place, however it does this in a relatively unsophisticated manner using a file-system flag.

By default Access will attempt to create the file system flag, a .LDB file named in an identical fashion to that of your database next to the .MDB. The problem is that the LDB is being written using the IUSR_<system_name> account which under Windows 2000 will be part of the everyone group, and has more secure default permissions under later version.

What is happening is that your system is either unable to create the LDB because of a permissions conflict, or more likely in the case of you receiving the error listed at the beginning of this article it is creating the LDB file, but is unable to clear the file-system flag.

In other words: Access is locking the database, but in its crudeness is unable to unlock it!

You must ensure that you have set the necessary permissions on the database folder/directory with the permissions on the folder inheriting down to the files contained within it.

 

Now that you have a folder with write/modify (or worse) permissions for the IIS process/guest account, you need to think about security. Never, ever put the database folder beneath the public wwwroot of the site. Always place the database directory at the bottom of a folder hierarchy and always keep your permissions as tight as possible.