Meet Me ASP

Tom Moran
Microsoft Corporation

December 28, 1998

The following article was originally published in the Site Builder Network Magazine "Servin' It Up" column (now MSDN Online Voices "Servin' It Up" column).

I hope your holiday season has been as good as mine, and that you're not working too hard. How are those New Year's resolutions going, anyway? One of mine is to make sure I get my column done and to my editor on time. But then, you know how New Year's resolutions go. My three-year-old even promised to be good; I'm sure that will last the year.

Let's Do a Meeting

After I wrote a column discussing how to send e-mail via ASP scripting, many of you sent questions concerning other, related tasks. This month, I'll answer a question from Lisa in North Carolina, who also gets a fab T-shirt. Lisa asks "How do I send a meeting request?"

I chose this because it is not quite as simple as it sounds, and there are a lot of decisions that need to be made along the way. Unlike sending an e-mail, you cannot do this with SMTP and the Windows NT Option Pack. You must have Exchange Server installed to get Collaboration Data Objects (CDO).

I downloaded the Exchange Server 5.5 Evaluation Edition, which is available in the BackOffice Download and Trial Center. The file is only 22MB, and doesn't take too long to download. I even downloaded it on my home machine at 28.8bps, but I don't recommend that. When you install, you do not need to install the entire product. Simply choose Outlook Web Access in the options, and deselect everything else. In doing this, there are a couple important assumptions I am making:

Basic Authentication

Assumption # 1: Basic authentication is okay. This means my password will be sent around in Base 64. Why do I need to do this? Think about how Windows NT authentication happens. No password is ever sent over the wire. Instead, the client creates a hashed value, or token, based on the password, and sends it to the server requesting authentication. That server asks the primary domain controller (PDC) to come up with a value based on its record of the password. These are then compared, and if there is a match, you're okay. If not, you're a criminal (or a bad typist). In a nutshell, this means that Internet Information Server (IIS) cannot authenticate you to Exchange, because IIS does not know your password. So instead of using NTLM, we use Basic. I am using this on an intranet and I believe my network is secure, so I figure that it's an acceptable security risk. And no, the previous statement is not an open invitation to any hackers out there. There are some other ways of approaching this as well. One could, for example, set everything up for anonymous access. In an Internet situation, you might need to do this -- depending on what you want to accomplish. The other possibility is to have IIS and Exchange Server on the same box. This avoids any problems with authentication, because no passwords need to be sent over the wire, but it possibly adds some unwanted complexity in architecture. For those of you who are worried about the passwords, keep in mind it is possible to use Secure Sockets Layer (SSL) with Basic authentication.

Send a Request

Assumption #2: It is okay to send an appointment request instead of directly scheduling the appointment on the user's calendar. Merely sending an appointment request means that we don't have to worry about permissions. Generally, anyone can send out a message with an appointment request, but to change something directly on a user's calendar requires specific permissions to be set for each specific calendar. That is definitely more than I want to do at this point. I am a big fan of starting off simple to make sure everything works, and then adding in pieces as I go. Too many times, I've tried to do everything at once, and then spent more time troubleshooting than I have on the rest of the project.

It won't be too difficult later to have my Exchange administrator/helpdesk create a new user called "AutoSchedule," or something like that, and then send out mail to my team asking each person to ensure that this account has privilege to create an appointment in their calendars.

History of CDO

You may have heard of OLE Messaging, Active Messaging, and CDO. Basically, they're all the same in that they are Microsoft's Messaging object library; they're just different versions. CDONTS is really a different beast, and is an SMTP server that allows only sending e-mail through a Web application. Since we want to schedule an appointment, we'll use CDO 1.2, which comes with Exchange Server 5.5. Prior to that version, there was no easy way to work with appointments and schedules. To get the absolute latest version, CDO 1.21, you'll need to download Service Pack 1 for Exchange Server 5.5, which is available in the same place you downloaded the Evaluation version of Exchange.

Getting Started

Be sure you have the following:

Windows NT 4.0 with Service Pack 4
IIS 4.0
Exchange Server 5.5, although all you really need from it is Outlook Web Access. Remember, if you don't have it, there is an Evaluation version available on the Web.
Visual InterDev, or your favorite ASP-development tool.

Step One

Using Visual InterDev, create a new project. I called mine CreateAppt and created a new Web for it. Using the Internet Service Manager, which comes with the Windows NT Option Pack, do the following:

open your default Web
right-click on the new Web you've created
select properties
select Directory Security
ensure that only Basic Authentication is selected. You will get a warning about it being a security risk. Remember that when you use Basic, the password entered by the user is sent over the wire, unlike using NTLM.

Step Two

The first thing to do in code is to create a session object and logon. We'll also set a couple constants. You can do this in a few lines of code by adding the following to your ASP file:

  <%

   '========================================================
   'Constants
  
   CONST CdoDefaultFolderCalendar      = 0
   CONST CdoMeeting            = 1
  
   '========================================================
     
   'create session and logon 
   strProfileInfo = "MY-SERVER" & vbLf & "MY-LOGON-NAME"
   Set objSession = Server.CreateObject("MAPI.Session")
   objSession.Logon "", "", False, True, 0, True, strProfileInfo
      
   'very minimal error checking
   If objSession Is Nothing Then
   Response.Write("Error - no session")
   Response.End
   End If

Remember to change the server and logon names to something that makes sense for you. Note that I have taken a couple shortcuts in the above to make the app as simple as possible for clarity sake. Doing this in a real application can cause some timing problems. To avoid this, it is strongly recommended that you add the logon.inc file from the samples section at the end of this article. This will force the browser to authenticate the user.

Step Three

Next, create the meeting request. Add the following to your ASP file:

   Dim myCalendarFolder
   Dim myAppointment
   Dim myMeetingRequest
   Dim myRecipient
   
   On Error Resume Next
   
   Set myCalendarFolder = 
     objSession.GetDefaultFolder(CdoDefaultFolderCalendar)
   Set myAppointment = myCalendarFolder.Messages
   Set myMeetingRequest = myAppointment.Add
   Set myRecipient = myMeetingRequest.Recipients.Add
   
   'Set the specifics of the meeting, and then Resolve addresses
   myMeetingRequest.MeetingStatus = CdoMeeting
   myMeetingRequest.StartTime="01/01/99 7:00 AM"
   myMeetingRequest.EndTime = "01/01/99 8:00 AM"
   myMeetingRequest.Subject = "Call Boss"
   myRecipient.Name = "you@yourcompany.com"
   myRecipient.Resolve
  
   'Now send the request we just created
   myMeetingRequest.Send

Step Four

The last thing to do is to clean up. Really, all you want to do is to destroy your objects. Add the following at the bottom of your ASP page:

   objSession.Logoff
   Set ObjSession = Nothing
   Set myAppointment = Nothing
   Set myMeetingRequest = Nothing
   Set myRecipient = Nothing
   
   %>

Now you can run the ASP application in your browser, and you should receive a meeting request -- as long as you've changed the appropriate variables. There are many variations on this theme: You can display calendars on the Web, schedule meetings, create a service that automates scheduling, allow anonymous users to send mail and requests, or set reminders for customer requests. Once you have basic functionality working, you can easily get the information from the user via a form or directly from a database.

To improve this application, you can test for a variety of error conditions. You can create a form that gets the information from the user, and has far more properties that can be set. Adding multiple recipients (using the AddMultiple method of the Recipients Collection), checking for free/busy time, and so forth are all things that you can do. The CDO Help file will be indispensable, and has good examples and documentation of all properties and methods.

Additional resources

If you are going to move beyond sending mail with CDONTS and do more using CDO, I've pulled together a list of resources for you to look at:

Downloadable Sample Apps from Microsoft TechNet

Getting Started with ASP Messaging

Extending Web-Based Knowledge Management with Microsoft Exchange Server

Authentication & Security for Internet Developers

KB Article: Active Messaging and Collaboration Data Objects (CDO)

KB Article: Where to Acquire the Collaboration Data Objects Libraries

KB Article: What is the Difference Between CDO and CDONTS?

KB Article: View Public Folder Contents from an ASP Page

KB Article: Display Free/Busy Information from an ASP Page

KB Article: Render a Calendar to an ASP Page with CDO