It's late so I'm going to keep this brief but since we don't have any public content I wanted to get the word out.  Exchange's CDO 1.21 was never tested and will not work with Kerberos authentication.  While Outlook's version of CDO 1.21 does have Kerberos support, it is not suitable for use in serviced applications.

Problem

A lot people install Exchange System Manager on an IIS box in hopes of using CDO 1.21 inside an ASP application.  Typically this ASP application was hosted on the Exchange server itself in the Windows 2000 days but Windows 2003 fully supports Kerberos and this seems like an opportunity to seperate the tiers a bit.  What we see people wanting to do is seperate the ASP application to a seperate IIS server with integrated authentication turned on thus allowing users to use this internal web application to pull information from their mailbox or a public folder using their credentials against Exchange through CDO 1.21.  What they find is that they get a MAPI_E_LOGON_FAILED error even though they verify the IIS application is running as the logged in user.  The problem is that CDO 1.21 doesn't support Kerberos.

Resolution

Unfortunately we can only offer workarounds.  CDO 1.21 is old and being de-emphasized in Exchange 12.  Here are your options:

• Use Basic Authentication.  Basic authentication will work because it generates an Interactive token which can be passed to different servers.  The drawback with Basic authentication is that users are prompted for a user name and password.  Additionally that user name and password is sent in clear text to the server so you should be sure to run your web application with SSL if you are using Basic Authentication.
• Use WebDAV.  WebDAV uses HTTP requests and responses with XML to query, create, and modify Exchange data.  Since you are using HTTP requests, IIS handles authentication and security is much easier to handle.  WebDAV can be cumbersome to use but must be given create for its wide supportability (supported with managed code and from non-PC clients) and its ability to support Contacts, Meetings, and Mail Items.
• Host your web application on the Exchange server.  Since Kerberos is used to pass credentials between servers, if the web application and Exchange are on the same machine there is no need to use Kerberos and your web application will work.

...I thought I was going to keep this brief but I guess not.  Anyway, like I said we don't have offical content up yet but I will update this post with the KB article when it goes public.  Until then look into WebDAV.

...Update, here is the only offical explaination of this issue that is out there right now...

http://www.microsoft.com/technet/prodtechnol/exchange/2003/insider/providers.mspx

Ryan Gregg, an Outlook 12 PM, gives an enticing preview of the enhancements and new features of the Outlook Object Model to be available in O12.

...At first glance this is very exciting.  I look forward to these changes, improvements, and additions as they seem to hit on a lot of customer requests. 

While we are on the topic of System.Web.Mail, it is important to note a new namespace in version 2.0 of the .NET Framework.  There is a brand new namespace for sending mail via managed code, it is called System.Net.Mail.  Have no fear, System.Web.Mail is still accessible in v2.0 but it is deprecated.  (Which means v2.0 won't break your code but you should strongly consider using System.Net.Mail in new development.)  The documentation for System.Web.Mail is updated to reflect this.

This is more than an annoying namespace change.  This is a reimplementation of the mail objects in .NET in order to seperate System.Net.Mail completely from CDOSYS therefore making it a completely managed solution.  In the coming weeks I hope to investigate these new objects further, creating or linking to how-to's, and making sure to point out the major differences between the old and new objects.

...A great improvement of SNM over SWM is that there is not COM interop involved which should greatly improve performance.  Additionally, SWM was merely a wrapper for CDOSYS and only exposed limited functionality available in CDOSYS.  SNM is a complete implementation, I look forward to illustrating how to do things in SNM that weren't exposed by SWM.  Stay tuned...

One of the principles of the Information Age is that anybody with a blog like mine or a Code Project account can write an article viewable to millions of people around the world.  As a support engineer, I love and hate this at the same time.  Take the following Code Project article for example...

http://www.codeproject.com/useritems/Techblaster.asp

This article is full of very useful information about how to use System.Web.Mail and would probably help a novice get a good start.  I don't mean to call this author out as the only person who is spreading false information, the fact is he or she probably got a lot of this information from another source to begin with.  However there are a number of inaccuracies that don't properly communicate how System.Web.Mail works and ultimately led to developers giving me a call.  (Which is fine, that is my job and I'm more than happy to help!)

I'd like to address a common inaccuracy right now.  The following line of code is lifted from the article I mentioned above...

SmtpMail.SmtpServer.Insert(0,"127.0.0.1"); //specifying the real SMTP Mail Server.

The intention in specifying an SmtpServer is to specify the name of the SMTP server you wish you relay your mail through.  Setting this property will send the mail via port through the server mapped to the name or IP address provided.  In this case the author is intending to send mail via port through the local SMTP service.  There are two problems with this line of code, one relates to proper usage of the SMTP Service and the second relates to understanding what the Insert function does.

Error 1 - Understanding the SMTP Service, System.Web.Mail, and CDOSYS

I will expand on this in a later feature article so I will try to be brief here.  System.Web.Mail is simply a managed wrapper for CDOSYS which is a COM component that sends simple SMTP mail to remote and local services via port or local pickup directory.  When using CDOSYS directly you specify which "sendusing" method to use when sending mail.  When using System.Web.Mail you simply set SmtpMail.SmtpServer to send via port or leave it blank to send via local pickup.

If you have a local SMTP Service running (which you should if you are sending a lot of mail, say from a web server) you only leverage the SMTP services Queue folder, retry attempts, delay sending, and general management when you send via pickup.  If you send via port you do just that, you are connecting to the SMTP port (usually 25) and either successfully or unsuccessfully sending mail in one shot.  When sending via port, if you can't connect to the SMTP server or successfully transmit the message your code will throw an exception.  However, when you send via pickup directory, you are simply writing an EML file to the local directory (usually C:\inetpub\mailroot\pickup\), you will not see any errors unless you cannot write the file to disk.  The SMTP Service will handle sending the message, retrying failures, and sending NDRs.  Therefore I STRONGLY recommend that you send via local pickup directory if at all possible.

But let's get back to this code sample.  This code specifies the intention that the mail should be sent through the local server via port, which would require that the SMTP service be running on the local machine.  In that case you should go ahead and send mail via pickup by commenting out this line.

Error 2 - Taking a closer look at Insert(0, "127.0.0.1")

Now that we have clarified how System.Web.Mail is used to specify the send using method, let's take a look at what is actually happening with this line of code.  We will start by looking at the data type of the static property SmtpMail.SmtpServer.  You will notice that its datatype is string.  So when we call the Insert method of SmtpServer we are actually calling the Insert method off of any string.  Let's take a look at the Insert method to see what it actually does...

"Inserts a specified instance of String at a specified index position in this instance."

Okay, sounds alright to me so far.  We definitely want to insert "127.0.0.1" or some other IP address or server name into the SmtpServer property value.  However, you will notice that this Insert method returns to a string.  What is the returned string?..

"A new String equivalent to this instance but with value inserted at position startIndex."

The modified string is returned, the original string is NOT changed!

So what does this mean for our line of code from the article?  If you notice we don't do anything with the return value from the Insert method.  We just call the method and move on.  If you were to print the value of SmtpMail.SmtpServer to the debug window right after this line you will notice that SmtpServer has no value.  What happens when we don't set the SmtpServer in System.Web.Mail?  That's right, we send via local pickup.  In this case we are specifying the local server with "127.0.0.1" so we are required to have an SMTP service running anyway.  However what if we changed this line of code to specify our Exchange server or coporate SMTP relay?..

SmtpMail.SmtpServer.Insert(0,"SMTPHost"); //specifying the real SMTP Mail Server.

The intention here is that we will send mail via port to a server named "SMTPHost".  However, what is really happening?  We are simply writing out an EML file to the local SMTP directory.  "SMTPHost" is never contacted about this message and it may or may not get sent depending on if you happen to have SMTP services installed on your local machine.

Here is my theory on how this code sample came about.  If you remember in my description of Error 1, I mentioned that when you send via pickup you are simply creating a file on the local hard disk.  When you send via port you are connecting to a remote machine using whatever network credentials you have an attempting to transmit a message over the wire to a server.  Most likely someone was trying to send mail through "SMTPHost" with code like this...

SmtpMail.SmtpServer = "SMTPHost"; //specifying the real SMTP Mail Server.

But for whatever reason (misspelling, network connectivity problems, authentication, etc.) the were getting an error ("Could not access 'CDO.Message' " is most common.) when they tried to send the message.  Then they noticed that if they use the Insert method that they don't get any errors at all so they used it.  What they never realized (until they read this post) is that their code doesn't do anything near what they intended it to do.

..In conclusion, you should only set the SmtpServer if you want to send via port to a particular SMTP server and if you set the SmtpServer use SmtpServer = "servername" and don't get caught up in the "Insert Method Myth".  If you want to send via pickup directory, just leave the SmtpServer property empty.

There is a new strain of the Sober virus roaming inboxes lately.  Yahoo has more.  The virus arrives in an email with an attachment.  Many of the messages will proclaim they are from the CIA or FBI asking you to open the attachment to answer some questions.  Some attachments claim to be video of Paris Hilton or Nicole Richie.  In short don't open the attachments.

...Add this to the long line of virus that are avoided if you just don't open attachments or view email from people you don't know.  By this time everyone who owns a computer and gets email via Outlook or some other mail client should be running antivirus software.  A huge benefit of using web based email services like Hotmail is that most provide server side virus scanning on attachments before you download them.  If you connect via POP3 or IMAP to Hotmail or Yahoo! or *Mail then you are responsible for scanning mail and attachments with your personal antivirus software.

I had a customer email me today saying they resolved their CDO problem by installing SP 2 on their Exchange server and installing Outlook 2003.  Big mistake!  It's unfortunate and common but so many people put their Exchange implementations at risk by installing Outlook on top of Exchange.  One of our Escalation Engineers, Stephen Griffin, has a great post and follow up on the subject.  Exchange and Outlook both have their own versions of CDO and MAPI.  When you install Exchange on top of Outlook or Outlook on top of Exchange you are essentially mixing and matching these libraries and their underlying subsystems.  This scenario is not supported by PSS and if you have problems with code running on a server with Outlook and Exchange we can't help you.

...Don't get me wrong, the implementations are similar enough that you might not see any noticeable failures initially.  In fact, many have argued that they have a machine running for X number of days just fine and see no reason why you can't have both installed.  Take a look at Stephen's article, there are interfaces not implemented in the Outlook version that are implemented in the Exchange and vice versa.  As soon as you or Outlook or Exchange try to use one of those interfaces you will know why you shouldn't have both applications installed on the same box.

...A common and related issue is copying the server CDO 1.21 library to a non-Exchange server or client to get around the client version's security prompts.  This is not a supported solution for the same reason Exchange and Outlook can't coexist.

...Here is the KB article on the same issue, http://support.microsoft.com/default.aspx?scid=kb;en-us;q266418

...We all would like to see more supportability with .NET from our Exchange API's.  Exchange 12 could offer some more options to that end.  It is important to know the basics about all our API's, their functionality limitations, and supportability concerns.  Exchange development often requires blending multiple API's to get the job done; you should be open to that possibility.

I don't get any kickbacks I swear.  Check out MaxiVista it is truly a great product a number of people here use everyday.  It is a simple client/server application that provides software based multi-monitor and KVM functionality.

...Really, I don't have an affiliation with them what so ever.  It is just a great product.  If you bring a laptop to work like I do, it is a necessity.  Instant KVM and Multimon without waiting for new hardware.  Enjoy and please pay for it if you use it, they've earned it!

UPDATE 1/4/05 - Today is MW's first day here at MS!  Congrats!

...It was just too easy to steal from the Exchange Team's blog but I couldn't help myself

Welcome to my new blog, it goes well with my new job!  My name is Matt Stehle and I'm a developer support engineer at Microsoft at the Charlotte campus.  I work in the DS Messaging group which works closely with the Exchange and Outlook product teams to support development against both products.

Supporting these products is tricky business.  There are a lot of API's that do a lot of different things.  Supportability and functionality are often hard things to manage which is why I created this blog to address some of the issues I come across while working with you all.

I believe very strongly in what Product Support means to our products success and want to use this blog to not only educate you on messaging technologies but also PSS in general.  It is important to know what Microsoft does in order to leverage our services to better help you.

Enjoy...