Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Programming Microsoft Outlook and Microsoft Exchange 2003
  • Alternative view 1 of Programming Microsoft Outlook and Microsoft Exchange 2003
  • Alternative view 2 of Programming Microsoft Outlook and Microsoft Exchange 2003

Programming Microsoft Outlook and Microsoft Exchange 2003

by Thomas Rizzo

Create rich, collaborative messaging solutions for your business—and extend them to corporate Web portals—with code and instruction straight from the source. This classic reference—now in its third edition—shows how to exploit the enhanced collaborative capabilities in Outlook 2003 and Exchange Server 2003, including knowledge management,


Create rich, collaborative messaging solutions for your business—and extend them to corporate Web portals—with code and instruction straight from the source. This classic reference—now in its third edition—shows how to exploit the enhanced collaborative capabilities in Outlook 2003 and Exchange Server 2003, including knowledge management, information publishing, and search capabilities. Author Thomas Rizzo, a veteran of the Microsoft Exchange and Outlook teams, shares a wealth of practical, how-to examples for crafting collaborative business applications. To extend your learning, the companion Web site features 500+ pages of bonus material on Microsoft SharePoint Portal Server, as well as the book’s entire cache of code—downloadable for use in your own applications.

Discover how to:

  • Manipulate Outlook objects using the Outlook Object Model
  • Write your own COM add-ins to extend Outlook functionality
  • Create smart tags and smart documents to link actions to content, customize the UI, and track interactions
  • Use Collaboration Data Objects (CDO) to develop Web-based messaging and collaboration applications
  • Help protect your network applications with Outlook Security Update and Microsoft ASP.NET authentication
  • Increase your control over Exchange Server with the CDO library and ADSI
  • Better manage the Exchange infrastructure via CDO for Exchange Management (EMO) and Microsoft Windows Management Instrumentation (WMI)
  • Develop real-time collaboration solutions using the Exchange Conferencing Server and Instant Messaging

A Note Regarding the CD or DVD

The print version of this book ships with a CD or DVD. For those customers purchasing one of the digital formats in which this book is available, we are pleased to offer the CD/DVD content as a free download via O'Reilly Media's Digital Distribution services. To download this content, please visit O'Reilly's web site, search for the title of this book to find its catalog page, and click on the link below the cover image (Examples, Companion Content, or Practice Files). Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to booktech@oreilly.com.

Product Details

Microsoft Press
Publication date:
Edition description:
3rd ed.
Product dimensions:
7.56(w) x 9.30(h) x 2.11(d)

Read an Excerpt

Chapter 8.Outlook and the Web

  • Outlook Today
    • Outlook Today Technologies
    • Customizing Outlook Today
  • Active Server Pages
    • ASP Fundamentals
    • Global.asa
    • Built-In ASP Objects
    • Server-Side Include Files
    • Server Components
  • Outlook Web Access
    • Installing Outlook Web Access
    • Outlook Web Access and ASP Security
    • Special Considerations for Setting Up Outlook Web Access
  • The Outlook HTML Form Converter
    • Software Requirements of the Converter
    • Components of the Converter
    • Features of the Converter
    • Stepping Through a Conversion
    • Examples of Conversions
    • Files Created for Converted Forms
    • Web Forms Library
    • Making HTML Forms Available in Outlook
    • Tips for Developing HTML-Ready Outlook Apps

Chapter Eight Outlook and the Web

This chapter looks at how Microsoft Outlook ties into the World Wide Web and is broken into four main sections: Outlook Today, Active Server Pages, Outlook Web Access, and The Outlook HTML Form Converter. We start by examining Outlook Today, which is an HTML feature introduced in Outlook 98. Then we’ll cover the basics of Microsoft Active Server Pages (ASP)—the foundation for Outlook and the Web. We’ll move on to overview installing and configuring Outlook Web Access. Outlook Web Access technology is based on Active Server Pages and Microsoft Collaborative Data Objects, and it’s used to access information on Microsoft Exchange Server and Microsoft Internet Information Server (IIS). We’ll finish with a discussion of the Outlook HTML Form Converter. The Form Converter is a tool to help you convert your Outlook forms into a web-based format that integrates Outlook Web Access.

Outlook Today

As you learned at the end of Chapter 7, Outlook 98 includes a feature that takes advantage of the HTML support in Outlook—Outlook Today. Outlook Today allows users to view information in an HTML window, as shown in Figure 8-1 on the next page, rather than as separate modules. You can also customize Outlook Today’s HTML code. For example, a customized Outlook Today page might include hyperlinks to Public Folder favorites, intranet sites, or Internet sites. You can even link to other applications, such as a web-based SQL Server application. You can also create multiple Outlook Today pages for the different types of users of your application. Let’s take a look at how the Outlook Today page functions and how you modify the Outlook Today page for your specific application needs.

Figure 8-1 Outlook Today is an HTML feature added to Outlook 98. Users can see different types of information in a single window. (Image unavailable)

Outlook Today Technologies

The standard Outlook Today page takes advantage of a feature in Microsoft Internet Explorer called data binding. Data binding allows Outlook to quickly display the user interface for the Outlook Today page while asynchronously downloading data from the Exchange Server to the Outlook client. Once the data is downloaded, Outlook can modify the data without making additional trips to the server. On the default Outlook Today page, there are three separate data binding tables for your Calendar, Tasks, and Mail. To modify the location of these tables or to add new functionality to the Outlook Today page, you need to know how to modify HTML. Since Outlook Today leverages Internet Explorer, you can even use Dynamic HTML (DHTML) in your customization. However, remember these limitations when customizing the Outlook Today page:

  • Modifying the page might slow performance because Outlook has to retrieve information from other data sources. Try not to build complex applications in the Outlook Today window; instead, build either an Outlook form or a standard HTML application, and then add the HTML application to Outlook Web Access.
  • Although you can add external links to Internet sites on your Outlook Today page, Outlook Today will not verify the security of the site. To use the security capabilities you have in your browser, you could add a link in Outlook Today that launches a separate browser, such as Internet Explorer, to render the page. If you are sure of the content that you are linking to, you do not have to browse the link in a separate browser.
  • You cannot add the Outlook Today page as an Active Desktop item. Currently, the Outlook Today functionality works only when hosted in the Outlook window.

The standard Outlook Today pages are hosted in a resource dynamic link library (DLL), which improves the performance of the Outlook Today application. When modifying your Outlook Today pages, you have the option to place your custom HTML pages and images in a resource DLL. However, this book covers only customizing Outlook Today and saving these customizations as HTML files. To learn how to compile your files into a resource DLL for Outlook Today, refer to the Outlook 98 Deployment Kit. The Deployment Kit is presently not available for retail purchase or download from the Web, but you can access the Deployment Kit documentation from http://www.microsoft.com/office/98/outlook/documents/O98DKdoc.htm.

Customizing Outlook Today

Customizing the Outlook Today page and saving the result as an HTML file involves a few steps, which are outlined in the following sections.

Retrieving the Outlook Today Source

To view the source of an HTML page in Internet Explorer, you can right-click on the page and select View Source from the context menu. If you right-click on the Outlook Today page to view the source of the HTML page, however, you will notice that the View Source option is not available—Outlook disables this option. To retrieve the HTML source for the Outlook Today page, you can copy the Outlook.htm file from the Outlook 98 Deployment Kit, or you can use Internet Explorer to retrieve the source by following these steps:

  1. Start Internet Explorer. In the address box, type the following URL, adjusting the path as necessary:
  2. res://c:\Program Files\Microsoft Office\Office\Outlwvw.dll/Outlook.htm

  3. After you press Enter, you will get a script error. Select No to decline continuing running scripts and debugging the current page.
  4. From the View menu, select Source to display the source in Notepad.
  5. From the File menu in Notepad, select Save As and save the file to your hard disk as Outlook.htm.
  6. Perform a search in Notepad for the three instances of display:none, and replace them with display:.

Modifying the Registry

You need to modify your Registry settings so that Outlook knows you want Outlook Today to point to a new file for its functionality. You could write a program that performs this step for your customers:

  1. Start the Registry Editor (Regedit.exe).
  2. Find the following Registry key:
  3. HKEY_CURRENT_USER\Software\Microsoft\Office\8.0\Outlook\Today

    If the Today key does not exist, create it. Right-click on the Outlook key, point to New, and select Key. Type Today for the name of the key.

  4. Add a new string value to the Today key by right-clicking on the Today key, pointing to New, and selecting String Value. Type Url for the value name.
  5. Double-click on the URL string icon to edit it. For its value data, type the path to the Outlook.htm file that you saved previously. For example, file://C:\Outlook.htm. When finished, click OK.

Customizing the HTML File

The final step is to customize the HTML file with your functionality. The easiest way to do this is by using a text editor, because the HTML code in the page contains special formatting that will make the file appear incorrectly in Microsoft FrontPage. Let’s review some of the ways you can customize the Outlook Today HTML page.

Changing fonts  Since Outlook Today uses cascading style sheets, you can easily change fonts and styles by modifying the style sheet. For example, you could change the font for important items by changing the .itemImportant {color:red} line in the style sheet to the desired font and color.

Adding text, images, and hyperlinks  Using HTML, you can add new text, images, or hyperlinks to your Outlook Today page. Remember that if you link to an external web site, Outlook will not implement the security that you set in your standard web browser. So use the following code when placing external links in the Outlook Today page:

<a style="cursor:hand" class="itemNormal" onclick=
Exchange web site</a>

Adding components  Since Outlook Today leverages Internet Explorer, you can place any components on your page as long as Internet Explorer supports them. These components can include ActiveX controls as well as Java applets. However, make sure you trust the source of the component because Outlook does not check the component’s security credentials.

Adding script  Outlook Today supports both JScript as well as VBScript. From script, you can access the Outlook object library and use its functions in your Outlook Today page. You can see an example of a customized Outlook Today page for the Account Tracking application in Chapter 7.

Active Server Pages

In this section, we’ll explore Microsoft Active Server Pages (ASP) technology. You should know about ASP for several reasons. First, the Outlook HTML Form Converter, a conversion tool that migrates Outlook forms to HTML forms, utilizes this technology. We’ll examine the converter later in this chapter. Second, ASP is used in other areas, including Collaborative Data Objects (CDO) and Active Directory Services Interfaces (ADSI). We look more closely at CDO in Chapter 11 and ADSI in Chapter 14.

ASP Fundamentals

Active Server Pages are standard text files that contain HTML and script. The script can be written using any ActiveX scripting language, such as VBScript or JScript. The HTML files that most web developers write differ from ASP files in two significant ways. First, instead of having an .htm or .html file extension, ASP files have an .asp file extension. When you install IIS, an Internet Server Application Programming Interface (ISAPI) component is installed that processes all files with an .asp extension. This ISAPI component parses the ASP file and executes the appropriate script. Second, the actual script is processed on the web server. The processed results can include client-side scripting code but for the most part is just simple HMTL. Returning only HTML has two benefits: any modern web browser can view the results of an ASP application and the additional capabilities of the browser is less of an issue.

Since Active Server Pages supports VBScript, you can easily move from developing Outlook forms to developing Active Server Pages. The only difference in the development process is that you should use the CDO library to write your Active Server Pages application rather than the Outlook object library, because CDO was designed to be multiuser and server-based.

The following code is an example of an Active Server Pages application. This example uses the VBScript function Now to print out the date and time that the Active Server Pages application ran on the web server.


<H1>I was created on <%=Now()%></H1>

As you can see, the syntax of the ASP script is a little bit different from the syntax for Outlook code. To tell the web server that you want to run a script on the server, you must enclose it in special characters: <% and %>. Active Server Pages supports placing your script directly in your HTML code—the script does not have to be in a separate section of the HTML file.

Take a look at the first line of the code:


ASP assumes that the default language for server-side script is VBScript. If you replace VBSCRIPT with JSCRIPT, you can write server-side JScript code.

You can specify the default ASP language for an application in the Management Console for IIS. Open the Properties window for an application, and in the Applications Settings area, click the Configuration button. On the App Options tab, type the desired default language in the Default ASP Language text box.

You might be wondering what the <%=Now()%> code does in this example. The equal sign (=) indicates that the code should evaluate the expression, which in this case returns the current date and time. As you will see, the equal sign in ASP is a shortcut for calling the Write method of the Response object.


If you’ve viewed the actual directories that contain .asp files, you might have noticed a certain file with the .asa extension: Global.asa. This is a special file in ASP applications that allows you to include global code that executes when an application starts and ends and also when a session starts and ends. One thing to remember is that the Global.asa is an optional file for your web applications. A skeleton Global.asa file is shown here:

    Sub Session_OnStart
        ‘Put your session startup code here
    End Sub
    Sub Session_OnEnd
        ‘Put your session termination code here
    End Sub
    Sub Application_OnStart
        ‘Put your application startup code here
    End Sub
    Sub Application_OnEnd
        ‘Put your application termination code here
    End Sub

The Global.asa file contain stubs for your session and application start and end subroutines. To understand when these subroutines are called, you must understand what exactly constitutes a session and an application inside ASP.

Normally when you browse web pages, the web server does not remember who you are, where you have been, or any variables associated with you. One of the great things about ASP is that it transforms the applications you can build on the HTTP protocol from being stateless to being able to track the state of users. This ultimately lets you create global variables that are maintained for users throughout an application.

An ASP application consists of a virtual directory and associated files. But to understand when an ASP application starts and ends, you’ll need a little bit more explanation of how ASP works. For your Application_OnStart subroutine to be called, the first user must request an .asp file from the virtual directory of your ASP application. The user can request an HTML file or other types of files from that directory. However, these requests will not cause the Application_OnStart subroutine to be called. The user must explicitly request an ASP file. This is the only time this subroutine will be called, unless you restart the application. Restarting the application usually consists of restarting the Web service.

You should use the Application_OnStart subroutine to initialize global variables across the lifetime of the web application. For example, a good example of a variable to initialize or set in your Application_OnStart subroutine is one that counts the number of users who have used your application. To improve performance, for every user in your ASP application, you should initialize in the Application_OnStart subroutine any server components that you will use. Figure 8-2 illustrates a web browser sending a request to an ASP application for the first time.

Figure 8-2 When the first user of an application requests an .asp file, the Application_OnStart event is fired and then the Session_OnStart event fires. (Image unavailable)

When the user who first requested the ASP page also browses an .asp file in your application, the Session_OnStart subroutine is called. Unlike the Application_OnStart subroutine, the Session_OnStart subroutine is called for any user who makes an application file request. With ASP, each user of your application is considered to have a distinct session with the web server. As a user browses web pages in your ASP application, ASP implements and maintains state in a session by using cookies—whenever a user connects to your application, a file containing information (a cookie) is saved on the user’s machine. When his session ends and he closes his web browser, the cookie is removed and the session is invalidated. If he reconnected to your application, his machine would receive a new cookie and a new session would be started. For this reason, the users of your application must support and accept cookies; otherwise, your ASP applications will not fully function. You can still use the server-side script of ASP, but you cannot maintain state information for any of your users.

The Session_OnStart subroutine is best used to initialize session variables for individual users. Session scope variables include a connection to Exchange Server for an individual user and personalized information that a user has set in your application—for example, a user could specify a background color for web pages that is stored in a session variable. Then, each page the user accesses from your site during a session could be displayed in his personalized background color. Figure 8-3 shows each web browser starting a new session when accessing an ASP application.

Figure 8-3 Whenever a new user accesses your ASP application, the Session_OnStart event fires. Application_OnStart fires only when the first user accesses your application. (Image unavailable)

The Session_OnEnd subroutine is called when the session with the web server ends. This end state can be reached in two ways:

  • When the user has not requested or refreshed a web page in the application for a specified amount of time
  • By explicitly calling the Abandon method on the Session object

By default, IIS sets the timeout interval at 20 minutes. You can change this interval either through the administration program for IIS or by setting the TimeOut property on the intrinsic Session object in ASP. For example, to set a particular script timeout to 10 minutes, you would write the following code in your ASP application:

<% Session.TimeOut = 10 %>

The second way to reach the end state—by explicitly calling the Abandon method on the Session object—immediately ends the session and calls the Session_OnEnd subroutine.

Applications discussed in later chapters (CDO Help Desk, Event Scripting Expense Report, Routing Objects Expense Report) provide a logout menu option. This option calls another ASP file, which calls the Abandon method on the Session object to end the session.

One final note about sessions: you have to be careful when you redirect people to other virtual directories in your application. Developers, including me, commonly make the mistake of redirecting users to another virtual root and forget that this is considered by ASP to be an application. When you do this, the session variables you establish in one application will not transfer to the other application. If you want to share session variables between the two applications, you should place the second application under the same virtual directory in IIS as the first application.

When a web application ends, the Application_OnEnd subroutine is called. You end a web application in one of two ways: by shutting down the web server, or by stopping your application by using the Unload button in the IIS administrator. To use the Unload button, you must be running your web application in a separate memory space. So make sure you save any application scope variables to a persistent medium, such as to your Exchange Server or to a database, so that when your application restarts, the Application_OnStart subroutine can reload the values. For example, you don’t want a user-counter variable to restart at zero every time your application restarts. You should also destroy any server objects that you have created with an application scope. This will eliminate potential memory leaks on your server.

Built-In ASP Objects

The real power of ASP applications is that you can write server-side scripts and use their intrinsic objects. ASP and its built-in objects enable you to generate custom responses and maintain state information. The following section describes, in detail, five built-in objects in ASP: Application, Session, Request, Response, and Server.

The only object not covered here is the ObjectContext object, available in IIS version 4.0. This object can be used for creating ASP applications with transaction capabilities. For more information on the ObjectContext object and transactions, consult the IIS product documentation.

Application Object

The Application object is used to store global data related to an application that can be shared among all users. By using the methods and properties of this object in your application, you can create and set variables that have an application scope. To make sure that you do not run into concurrency issues when setting your application-level variables, since multiple users can be using the same application simultaneously, the Application object provides two methods named Lock and Unlock. These methods serialize the access to application-level variables so that only one client at a time can read or modify the values. The following example shows how to use the Lock and Unlock methods to increment a user-counter variable whenever a user accesses the application. The example also shows you how to set and retrieve application-level variables by using the Application("VariableName") syntax:

<TITLE>Example: Application Object</TITLE>
    Application("NumVisitors") = Application("NumVisitors") + 1
Welcome! You are visitor #<%=Application("NumVisitors")%>.

The Application object also contains two other collections beyond the variables collection—Contents and StaticObjects—which allow you to browse through the application-level objects and variables you have created. You probably won’t use either of these collections in your final applications, but both of them provide great debugging functionality. For example, the Contents collection enables you to list all the items that have been added to your application through a script command, and the StaticObjects collection enables you to list all the items with an application scope that have been added using the <OBJECT> tag. By adding debug code to your application at design time, when you run into application object problems, you can make ASP list all the objects you have created with an application scope. The following code illustrates creating debug code for both the Contents and StaticObjects collections. You can see the code output in Figure 8-4 on the following page.

<TITLE>Debugging Application Objects</TITLE>
    ‘Create some application variables
    Set Application("oCDOSession") = _
    Application("counter") = 10
<P>Objects from the Contents Collection<BR>
    for each tempObj in Application.Contents
        response.write tempObj & "<BR>"
<P>Objects from the StaticObjects Collection<BR>
    for each tempObj in Application.StaticObjects
        response.write tempObj & "<BR>"

Figure 8-4 The debug output for the Contents and StaticObjects collections. As you can see, objects and variables both can have an application scope. (Image unavailable)

Session Object

The Session object is one you’ll use a lot in your web applications. It holds the variables for individual users across the web pages in your application. When you place a variable in the Session object, that variable is valid only for the current user and cannot be shared across users in the same way that an Application variable can.

Like the Application object, the Session object contains the Contents and StaticObjects collections. You can also create session variables in the same way you create Application variables, by using the syntax Session("VariableName").

The properties for the Session object include CodePage, LCID, SessionID, and TimeOut. The CodePage property represents the language code page that will be used to display the content for the HTML page. The Outlook HTML Form Converter, which you’ll learn about later in this chapter, uses this property in its converted forms, as shown here:


You can use the LCID, or locale identifier, property in conjunction with the CodePage property. The LCID property stores a standard international abbreviation that uniquely identifies a system-defined locale.

The SessionID property returns to you the unique session identifier for the current user. You should remember, however, that this ID is unique only during the lifetime of the ASP application. If you restart your web server and therefore restart your web applications, the web server might generate the same IDs it already generated for the users before the web application was restarted. For this reason, you should avoid storing these IDs and attempting to use them to uniquely identify a user of your application. If you always need to uniquely identify your users whenever they access your application, you should use globally unique identifiers (GUIDs) in cookies, which are saved on the users’ computers.

The fourth property of the Session object is the Timeout property. This property enables you to change the timeout period associated with a particular ASP session. Remember that by default, the timeout is set to 20 minutes. If you know that your application will be used for less than 20 minutes, you might want to decrease the duration of the timeout so that sessions end more quickly and resources are returned to the web server at a faster rate.

The only method of the Session object is the Abandon method. As mentioned earlier, by calling this method, the user’s session with the web server as well as any associated objects and variables for that session are destroyed. If the user attempts to reconnect to the web application, a new session starts on the server.

Request Object

The Request object allows you to access the information that was passed from the web browser to your web application. The Request object is crucial in ASP applications since it enables you to access user input for your server-side scripts. For example, suppose a user fills out an HTML form that you created. Once the user clicks the Submit button on the form, the Request object contains the form information that was passed to the server. By using the collections of the Request object, you can retrieve that information and design your application to respond based on the user’s input.

Request object collections  The Request object collections are created when the user submits a request to the web server either by requesting an ASP file or by submitting an HTML form via clicking the Submit button. The three collections of the Request object that you’ll primarily work with in your ASP applications are the Form, QueryString, and ServerVariables collections.

For information on the other two collections, ClientCertificate and Cookies, refer to the IIS documentation.

To understand when to use these collections, you first need to know about the different ways information can be passed from the web browser to the web server. Normally in your web applications, you use HTML forms to gather input from the user so that you can use it in your calculations or store it in a data source. There are two main ways input can get passed to the web server from the client browser: via the GET method and via the POST method. The following example shows an HTML page that contains both methods on the same page:

<title>Forms Galore</title>
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
<form method="GET" action="getinfo.asp" name="GetForm">
    <p>What is your email address?</p>
    <p><input type="text" name="email" size="20"></p>
    <p><input type="submit" value="Submit" name="GetSubmit"> </p>

<form method="POST" action="getinfo.asp" name="PostForm">
    <p>What is your First Name?</p>
    <p><input type="text" name="firstname" size="20"></p>
    <p><input type="submit" value="Submit" name="PostSubmit"> </p>

The Action attribute for each of the HTML forms specifies the same ASP file, getinfo.asp. The getinfo.asp file is shown here:

<TITLE>Post and Get Methods Example</TITLE>
<%txtRequestMethod = Request.ServerVariables("REQUEST_METHOD")%>
You selected to use the <B><%=txtRequestMethod%></B> Method.
<P><% if txtRequestMethod="GET" then %>
You entered your e-mail address as:
<% else %>
You entered your first name as:&nbsp
<% end if %>

This ASP code uses the ServerVariables collection of the Request object to check whether the form’s Request method was a POST or a GET method. Once the file determines which method was used, it displays the correct information for that particular type of form. Figure 8-5 shows a sample of the GET method.

Figure 8-5 When a user types an e-mail address and submits the form, the GET method is used to pass the information to the Request object. (Image unavailable)

You can also retrieve other server variables such as HTTP_USER_AGENT, which returns information about which browser the client is using; and LOGON_USER, which represents the Microsoft Windows NT account the user is currently logged on to. For a complete list of server variables, please see the IIS documentation.

As you can see in Figure 8-5 with the GET method, the information from the form is actually appended to the URL-for example: http://exserver/examples/getinfo.asp?email=thomriz@microsoft.com&GetSubmit=Submit. When data is appended to the URL using the GET method of a form, you use the Query-String collection of the Request object to retrieve the data. When using the QueryString collection, follow this format to retrieve the information:


Because the information that is passed to your application appears in the address of the user’s browser, the user can see it, so you might want to limit when you use the GET method. Instead, consider using the POST method.

The POST method places the form information inside the HTTP header, hiding the information from the client. However, when the POST method is used to submit form variables, you cannot use the QueryString collection. Instead, you need to use the Forms collection of the Request object. In the preceding example, the line


retrieves the information the user typed into the First Name text box on the form. You can use this same syntax in your applications to retrieve information from an HTML form.

Response Object

The Response object is used to control the content that is returned to the client. For example, when you calculate a value on the server, you need a way to tell the ASP engine that you want to send the information back to the client. You do this by using the Write method of the Response object.

The Write method of the Response object will be the most commonly used method in your ASP applications. Even though you have not seen any explicit Response.Write statements in the examples, they are there. The syntax <%=Variant%> is equivalent to <% Response.Write Variant %>. The shorthand version makes it easier for you to put these statements in your code quickly.

The Response object has a number of other collections, properties, and methods that you can use, such as the Expires property, which tells the web browser how long to cache a particular page before it expires. If you do not want your clients to cache your web pages, you would add the following line to your ASP files to cause your web page to expire immediately on the user’s local machine:

<% Response.Expires = 0 %>

The Response object allows you to buffer the output of your ASP page. This is useful if you want to hold back the output of your ASP code until the script completes its processing. The best example for using buffering is to capture errors in your code. For example, by turning buffering on using the command Response.Buffer = True, you can check throughout your ASP code whether an error has occurred. If one has, you can clear the buffer without sending it by using the Response.Clear method, and then you can replace the output with new output such as Response.Write "An error has occurred. Please contact the administrator." Finally, you can call the Response.End method, which sends the new buffer to the client and stops processing any further scripts in the ASP.

Server Object

The Server object provides you with utility methods and properties to modify the information on your web server. This object is used extensively in ASP applications because it contains both the CreateObject method and the ScriptTimeout property.

The CreateObject method allows you to create an object on the web server by passing in the ProgID for the object. Let’s look at an example. To create a CDO object, you would type this in your ASP file:

Set oSession = Server.CreateObject("MAPI.Session")

ASP creates an object and passes that object to you in the oSession variable. By default, when you do this on an ASP page, the object has page-level scope. This means that when ASP is done processing the current page, the object is destroyed. Therefore, you might want to create objects on a page and then store them by assigning them to either session variables or application variables, as shown in this code snippet:

    Set oSession = Server.CreateObject("MAPI.Session")
    Set Session("oSession") = oSession

As you learned earlier, an object that is assigned either a session or an application scope will be destroyed when either the session or the application ends, respectively. The one issue to watch out for with the CreateObject method and some objects is potential performance loss. You can instantiate almost every object on your web server as an ASP object, but some objects are specifically designed to run in a server-based, multiuser environment such as CDO. When you instantiate an object that was not designed for an ASP environment, the application performance might suffer if many people hit the page containing that object at the same time.

The ScriptTimeout property of the Server object allows you to specify how long a script should run before it is terminated. By default, an ASP script can run for 90 seconds before it is terminated, but this might not be enough time to retrieve data from a data source. By using the following syntax for this property, you can increase or decrease the amount of time the script will run before termination:

Server.ScriptTimeout = numseconds

Avoid increasing this number much beyond 90 seconds, because users who are waiting for long periods of time might assume the page did not load correctly, and they might hit their Stop and then Refresh buttons continuously, flooding your web server with requests.

Server-Side Include Files

One other powerful feature beyond the intrinsic objects of ASP is the ability to use Server-Side Include files in your ASP files. Include files are just text files containing script or HTML that you want to add to your ASP page. Microsoft Outlook Web Access, which you will learn about later in this chapter, relies heavily on Server-Side Includes for common code libraries in its ASP files. The following lines are examples of Server-Side Includes:

<!-- #include file="library/vbsfunctions.inc" --> 

<!-- #include virtual="/library/vbsfunctions.inc" -->

Server Components

ASP can take advantage of built-in objects and also use server components to add functionality to ASP. An example of two such components are Microsoft ActiveX Data Objects (ADO) and CDO. ADO allows you to connect to many types of databases; CDO allows you to connect to Exchange Server and other messaging servers. You can also write your own components using any COM-based development tool.

There are a number of other components packaged with ASP that you can use in your applications, including Ad Rotator, Browser Capability, Content Linking, Content Rotator, File Access, Page Counter, and Permission Checker. If you want to learn more about these components, you should refer to the documentation that ships with IIS version 4.0.

Outlook Web Access

Microsoft Outlook Web Access is an ASP application that Microsoft ships with Exchange Server version 5.5. This ASP application allows you to access your mailbox, calendar, and contacts as well as directory information using any standard web client. The Outlook Web Access application is built on CDO and is one of the best tools for learning CDO.

In this section, you’ll learn how to install Outlook Web Access on your web server, which also installs the CDO library. You’ll also learn about security when using Outlook Web Access. This security architecture is important since it also applies to any custom CDO applications you develop using ASP.

Installing Outlook Web Access

Before installing Outlook Web Access, you must have installed either IIS version 3.0 or IIS version 4.0 with Active Server Pages. IIS 4.0 and Exchange Server 5.5 both require Windows NT 4.0 Service Pack 3, but it is recommended that you install Service Pack 4. You can download the Window NT 4.0 Service Pack 4 from http://www.microsoft.com/windows/downloads/. If you don’t install Service Pack 4, you will need to install the Windows NT related fixes required for Outlook Web Access. You can download these hot fixes from ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp3/roll-up/.

You can install Outlook Web Access on the same server as your Exchange Server or on a separate server. Be aware that if you do install Outlook Web Access on a separate server, you cannot use Windows NT Challenge/Response as your authentication method. You’ll learn more about security implications later in the chapter.

The architecture for your web servers and Exchange Servers can vary depending on the topology of your network environment and requirements of your applications. For example, if few users will be accessing Outlook Web Access but you have a number of Exchange Servers and you do not want to set up multiple Outlook Web Access servers for each Exchange Server, you can set up just one Outlook Web Access server to talk to multiple Exchange Servers. The opposite is true as well. You can have multiple Outlook Web Access servers talking to just one Exchange Server. Think of it as a web farm of Outlook Web Access servers. This will work as long as you make sure that when a user starts a session with an Outlook Web Access server in a web farm, that user stays with the same Outlook Web Access server until her session expires or she logs out. Remember that ASP sessions do not span separate ASP applications. If you use DNS round-robin techniques to farm a user out to multiple Outlook Web Access servers, that user’s session will be lost when she changes to a different server.

To install Outlook Web Access, follow these steps:

  1. Insert the Exchange Server version 5.5 CD in your CD-ROM Drive.
  2. If the Exchange Server welcome screen does not start automatically, launch it by double-clicking on Launch.exe.
  3. Click on Server Setup And Components.
  4. Click on Microsoft Exchange Server 5.5.
  5. When setup starts, click Complete/Custom installation. (If you already have Exchange Server installed, click Add/Remove.)
  6. In the Options list, check Outlook Web Access and click Continue. If you don’t have the Windows NT Service Pack 4 (or the Windows NT related fixes) and IIS installed, a message box will be displayed and you won’t be able to continue the installation of Outlook Web Access.
  7. The setup program will prompt you for the name of an Exchange Server that Outlook Web Access should connect to. Type a name of a server that contains an entire replica of the Exchange Server directory. This sets up Outlook Web Access so that it automatically redirects itself to the Exchange Server where the mailbox of the user resides. It also allows you to set up one Outlook Web Access web server that talks to multiple Exchange Servers.

After completing the Outlook Web Access installation, you need to update it by installing Service Pack 1 for Exchange Server 5.5. You can download or order this service pack from http://backoffice.microsoft.com/downtrial/moreinfo/ex55sp1.asp. This service pack includes a number of enhancements for the Outlook Web Access client, such as the ability to access Outlook contacts from the Web.

After running the update, you need to set the proper permissions in the User Manager For Domains. Ensure that the Exchange users who will use Outlook Web Access have the following rights: "Log On Locally" and "Access This Computer From Network".

Access your new Outlook Web Access server by typing the following URL in your browser: http://OWAServer/exchange, replacing OWAServer with your Outlook Web Access server name. From the displayed page, you can log in as an Exchange user or log in with anonymous access. (Anonymous access is discussed in more detail in Chapter 11. Figure 8-6 shows how Outlook Web Access looks when you log on as an Exchange user.)

Figure 8-6 Outlook Web Access. (Image unavailable)

Outlook Web Access and ASP Security

Since the Outlook Web Access application utilizes Active Server Pages, you need to understand the ASP security architecture and how best to configure it for your environment. If you configure the environment incorrectly, you will run into problems when attempting to use authenticated access to the Outlook Web Access application or to any of your CDO web applications requiring authenticated access. This section describes how ASP security works and how you should set up Windows NT to support the type of security you want for your web applications.

ASP Security

When IIS is first installed, it creates a Windows NT user account called IUSR_computername, where computername corresponds to the current computer name. This account is assigned to the Guests account group, is given a random password, and is granted the right to Log On Locally. Whenever a user browses a web page, this account attempts to access the page on behalf of the user. If the IUSR_computername account does not have the proper permissions to access the page, the request is rejected with this error message: 401 Access Denied. The web server then informs the web browser which authentication methods the web server will support—either Basic authentication or Windows NT Challenge/Response authentication—depending on your settings for your IIS server.

Basic authentication  Basic authentication is supported across all web browsers. When the web server informs the client that it supports Basic authentication, the web browser displays a message box asking the user for a user name and password. Once the user types this information in, the web server tries to invoke the request using the identity of the supplied user rather than the IIS anonymous account. It is a good idea to pass in your domain name as well as the user name in the authentication dialog box in the web browser using the syntax domain\username.

Basic authentication, if used over Internet connections, can present some security concerns because the user name and password typed into the authentication dialog box is transmitted to the server as clear text. If you do use Basic authentication over Internet connections, use it in conjunction with Secure Sockets Layer (SSL). SSL will encrypt the connection between the web browser and the web server so that any information passed between the two cannot be viewed by unwanted individuals.

For the web server to impersonate the user whose name is typed into the authentication dialog box, the web server must log on as that user. By default, Windows NT does not give regular users the Log On Locally right on the server computer. For this reason, you must give all the users you expect will use your web application with Basic authentication enabled the Log On Locally right on your Windows NT server, which runs your web server. The easiest way to do this is to grant all your domain users the Log On Locally right in the User Manager for Domains.

Windows NT Challenge/Response authentication  Windows NT Challenge/Response, or NTLM, authentication is the most secure form of authentication because the user name and password are not sent from the web browser to the web server. Instead an encrypted challenge/response handshake mechanism is used. Unlike Basic authentication, NTLM typically does not prompt the user for a name and password. The Windows NT security credentials of the web user currently logged on are sent to IIS and are used to access the requested resource. IIS then changes to the context of the specified user and attempts to access the resource. If this fails, the user will be prompted for a user name and password.

For Windows NT Challenge/Response to work correctly, the users you are trying to authenticate must have "Access This Computer From Network" rights in User Manager for Domains. This is normally enabled for users by default.

A one-way encryption method is used, meaning the mechanism validates the user without sending the password to IIS. IIS doesn’t know the user information and cannot use it to access other resources on other machines. Essentially, this is a problem of delegation. When IIS attempts to access a resource on another machine, the other machine will prompt IIS for user credentials. Since IIS does not have the password for the user, it cannot return the correct information to the other machine. For this reason, you cannot use the Windows NT Challenge/Response authentication method with Outlook Web Access when your Outlook Web Access server is on a server different from your Exchange Server. IIS cannot remotely send the authentication to the Exchange Server when the Windows NT Challenge/Response method is used. This problem is being fixed for Windows 2000, but it’s a gotcha for now.

A second gotcha of the Windows NT Challenge/Response method is that you cannot use it over proxy connections for the same reasons just discussed. So when setting up your web server, consider NTLM’s security advantages as well as its limitations.

A third gotcha for NTLM is that at the time of this book’s publication, NTLM is supported only by Microsoft Internet Explorer. This means that if you have a mixture of web browser clients accessing your application, you might want to enable both Windows NT Challenge/Response as well as Basic authentication. If you enable only Windows NT Challenge/Response, when your Netscape Navigator users attempt to access a secure resource or page, they’ll receive a message denying them permission. With both security methods set up, if Windows NT Challenge/Response fails, Basic authentication will be used.

ACLs  Another way to restrict access to your web pages is by setting NTFS file permissions, or access control lists (ACLs), on your actual ASP files and directories. Doing so controls who can and cannot read the files. IIS respects the ACLs on the files, and if you have authentication enabled on your IIS server, IIS will use it to attempt to verify users and their individual permissions on the files. Be careful when setting permissions on files, however, because if the permissions you set are too restrictive, users will not be able to use your application.

Special Considerations for Setting Up Outlook Web Access

ASP security and Outlook Web Access security work in the same way when a user is being authenticated, but when you set up Outlook Web Access on your web server, you need to keep some access issues in mind. The following section describes file permission issues when users try to access Outlook Web Access on a web server, problems that could ultimately cause trouble in your CDO applications.

File Permissions for the Outlook Web Access Files

Outlook Web Access is installed by default in a subfolder under Exchsrvr, named Webdata. If you change the NTFS file permissions for this folder, at the minimum you should enable Read access on it and its subfolders. For temporary work, Outlook Web Access uses another subfolder under Exchsrvr, named WebTemp. Make sure that the permission for this folder is set to Change because Outlook Web Access needs to create and delete items in it.

Exchange Server Search Permissions

If you are using the new Search permissions in Exchange Server version 5.5 to restrict access to information in the Exchange Server directory for your users, you need to make sure that the Everyone and Directory Anonymous accounts have Search permissions at the Exchange Site or Configuration container level. If you do not grant these permissions, a user might get an error message stating that the Exchange Server is down or that HTTP access has been disabled. Your CDO applications could fail as well. For more information on this error, be sure to check out the following Knowledge Base articles in MSDN: Q173455 "OWA Returns Exchange Server Down Error Message"; Q175892 "Permissions Required for Outlook Web Access"; Q180417 "Error Msg: Sorry! The Microsoft Exchange Server Is Down."

Installing Outlook 8.03 on Your Outlook Web Access Server

If you install Outlook 8.03 on your web server after installing Outlook Web Access, Outlook will register an older version of the CDO library. Most commonly, users won’t be able to access or render calendar information in Outlook Web Access or CDO applications because the older version of the library did not support this. To fix this problem, type the following at the Run command, which is accessed from the Start menu on your Outlook Web Access server: regsvr32 cdo.dll.

The Outlook HTML Form Converter

In previous chapters, you learned how to develop Outlook solutions using the features of Outlook, such as forms. These forms, however, work only with Outlook on machines running Microsoft Windows 95 or later version, or Microsoft Windows NT 4.0 or later versions. There are still many 16-bit, UNIX, and Macintosh clients for whom developers need to design collaborative solutions. To provide cross-platform support for forms, Microsoft offers the Outlook HTML Form Converter. This converter allows you to take your Outlook solutions and turn them into HTML, ASP, and CDO-based applications that can be viewed by any standard browser such as Internet Explorer and Netscape Navigator. Once you convert your application to HTML, you can use any standard web development tool—for example, Microsoft FrontPage—to edit the HTML output of the converter. Once you convert the form, your users can work with either the Outlook version of the application or the HTML version of the application.

While this technology is a great step forward for cross-platform collaborative solutions, the HTML environment has some limitations and does not provide the same level of functionality as Outlook. This section describes what the Outlook HTML Form Converter is, how the converter works, and what the web forms library for Outlook Web Access is. I also provide tips for developing Outlook solutions that can be more easily converted to web solutions.

Software Requirements of the Converter

Before you attempt to convert your forms, you must meet a few software requirements. First, you must have Outlook Web Access installed on one of your Internet Information Servers. Installing Outlook Web Access was discussed in the previous section. Second, you must have either Outlook 97 (version 8.03 or later), Outlook 98, or Outlook 2000 installed on the machine on which you are going to convert the forms. Make sure that you install the converter after you install one of these versions of Outlook. Third, you need to have Exchange Server 5.5 with Service Pack 1. The service pack includes the Outlook HTML Form Converter as well as some improvements to Outlook Web Access that allow you to view Outlook contacts from any standard web browser. To install the Outlook HTML Form Converter, run Fcsetup.exe in the Formscnv folder of the Service Pack 1 CD for Exchange 5.5. Finally, on the client, users of converted forms can use any version of Outlook or no version of Outlook— that is, they don’t even need to have Outlook. They need only a web browser to use the forms.

Components of the Converter

The Outlook HTML Form Converter’s architecture consists of a number of components:

  • Conversion wizard. This is the user interface that walks you through converting the form.
  • OFT-HTML COM object. This reads the layout and data-binding information from the Outlook form and writes the corresponding HTML code to one or more files on the web server.
  • Form Converter templates. These templates are used as base templates for the converted file.
  • Template processor object. This object customizes the base templates to create the converted form.

Features of the Converter

Before stepping through the actual Outlook HTML Form Converter, you should know about its features. The Form Converter does provide a large feature set that you can take advantage of, but it also has some limitations.

Form Locations

The Form Converter allows you to convert forms from multiple forms libraries as well as forms from the file system that are saved as .oft files. The types of forms libraries that the Form Converter supports are the Personal Forms Library, the Organizational Forms Library, and the Folder Forms Library. Using the Form Converter wizard, you can specify either the forms library or the specific .oft files you want to use. The Form Converter also supports selecting multiple forms for simultaneous conversion.

Form Types

The Form Converter currently supports forms based on the following types:

  • IPM.Note. Mail message
  • IPM.Post. Post form
  • IPM.Contact. Contact form

IPM.Task, IPM.Appointment, and IPM.Activity (journal entry) are not supported by the Form Converter, but if you need to convert the user interface for any of them, you can copy their controls to a supported form type. You can then convert the supported form type with the copied controls and customize the converted form using an HTML development tool. If you try to convert an unsupported form type, the Form Converter will display an error message.

Convertible Features

The Form Converter can convert many of the Outlook controls with their corresponding layouts. Following is a list of features that the Form Converter can convert to HTML. Limitations are described.

  • Label control.
  • TextBox control.
  • ComboBox control. If the Outlook form contains an editable ComboBox control, the Form Converter changes it to a noneditable ComboBox.
  • ListBox control.
  • CheckBox control.
  • OptionButton control.
  • Frame control.
  • CommandButton control. Any images placed on the CommandButton control are lost since HTML does not support images on buttons.
  • MultiPage control.
  • Image control. Images that are bitmaps are converted to GIF files automatically by the Form Converter. In addition, any images that are clipped in Outlook by the Image control are shrunk automatically by the Form Converter for the HTML version of the form.
  • Background images on a form.
  • ActiveX controls. The Form Converter adds a commented out Object tag to the HTML form for the ActiveX control. However, the Form Converter does not package the ActiveX control as a CAB file nor does it add a CodeBase statement to the Object tag to point to the control’s CAB file. To make the control appear on the form, you can package the control, add the CodeBase statement, and then remove the Form Converter–generated comments.
  • Initial values.
  • Required fields. If a user attempts to change a tab in the HTML version of the form, the form will display a warning message that one of the fields is required on the form and also display the identifier text of the field. This text might appear in a format like SUBJECT_
    41_0_G, which might not be meaningful to your users. You can modify the error code to make it display the friendly name of the control rather than the identifier text.
  • Type checking and formatting.
  • Read and compose layout.
  • Hidden controls. In most cases, the initial values of hidden controls are not maintained.
  • Built-in and custom actions. If your actions call a custom form, be sure to also convert these forms, or the HTML version will return an error when the user invokes the custom action. The HTML version of the form can use only two rows of buttons to invoke custom actions. Since the width of the button is based on the amount of text on the button, and you’re allowed only two rows of buttons, keep the length of the names of custom actions to a minimum.
  • Limited support for non-English forms. The Form Converter provides limited support for non-English forms. It generates the ASP files and places them on the client machine in the correct subfolder for the language. For example, the output of a German form will be placed under the GER folder in Outlook Web Access, not under the USA folder. The Form Converter also places in the Form.ini file the appropriate code page for the language in which the form must be rendered. You must have installed on Outlook Web Access the language pack for the character set of the form you want to convert before running the Form Converter wizard. If you do not, you will not get the international options in the wizard.

Unconvertible Features

Following is a list of features that are not supported by the Form Converter. Details are provided for a few of these.

  • ScrollBar control.
  • SpinButton control.
  • TabStrip control.
  • ToggleButton control.
  • Formulas. Even though the Form Converter does not convert formulas, it places the code for the formulas in commented out text in the HTML file. You can then uncomment and modify the formulas according to the needs of your application.
  • Script code. The VBScript behind an Outlook form is not converted. Instead, it is placed in a text file, named Script.txt, which is in the folder that contains the ASP files for the converted form. The reason VBScript is not included in the HTML form is to accommodate cross-browser support. Since Netscape browsers do not support VBScript, you can either change the script in your form to server-side VB.Script or rewrite the script as client-side JavaScript.
  • Overlapped controls. Since HTML does a poor job of supporting overlapped controls and layouts, the Form Converter does not convert overlapped controls. Instead, it places the controls as close as possible to one another on the form.
  • Calculated fields. In a Contact form in Outlook, there are calculated fields such as FullName whose values are derived from other fields, such as FirstName and LastName. The Form Converter will convert forms that contain calculated fields, but these fields will become static fields. For example, the FullName field will not automatically change in an HTML form when either the FirstName or LastName field is changed.

Stepping Through a Conversion

Before you attempt to convert a form, you must first share the Webdata folder on your Outlook Web Access web server. For a default installation of Outlook Web Access, this folder is located at C:\exchsrvr\Webdata. You must give yourself and other developers in your organization who will use the Form Converter at least Read and Write access to the share. Also, be sure to name the share Webdata. If you do not share this folder, the Form Converter will not allow you to finish the wizard.

To start the Form Converter, click the Start button, point to Programs, and select Microsoft Outlook HTML Form Converter. This will display a starting screen for the Form Converter. Click Next to begin the conversion process.

Selecting a Form Location

On the second screen of the Form Converter, shown in Figure 8-7, you can select the type of form you want to convert. As mentioned earlier, you can select forms from the Personal Forms Library, the Organizational Forms Library, and the Folder Forms Library or Outlook templates from the file system. On the second screen, you also specify the name of the Outlook Web Access Server where the ASP file will be placed after the conversion.

Figure 8-7 Selecting the type of form and specifying the Outlook Web Access server in the Form Converter wizard. (Image unavailable)

Selecting Specific Forms

Clicking Next might display a Choose Profile dialog box. If so, choose a profile or create a new profile, and click OK. Depending on the type of form you selected in the second screen, the Form Converter wizard will present you with a forms library view, shown in Figure 8-8, or the Open Outlook Template dialog box, shown in Figure 8-9. You can select multiple forms from either of these interfaces. The forms library view enables you to display form categories rather than form names in the Outlook Forms list box. For forms in which these category properties were specified, this can make finding forms easier.

Choosing Conversion Options

In the final step of the conversion process, shown in Figure 8-10 on page 244, you can choose how you want the forms converted. If there are international language packs installed on the Outlook Web Access server, this screen also provides a drop-down list from which you can select the language for the converted form. This final step of the wizard also gives you the option of always overwriting your existing form. If you do not check this option, the Form Converter will prompt you during the conversion about overwriting the existing form. Checking the Layout Debug Mode check box enables debug mode on the converted form. If debug mode is enabled, the table borders for the HTML version of the form will be made visible so that you can easily see where and how the tables are laid out. You can use the borders to adjust the size and placement of controls on the converted form.

Figure 8-8 The Forms Library view of the Form Converter wizard. You can view your forms by category or by display name. (Image unavailable)

Figure 8-9 The Open Outlook Template dialog box presented by the Form Converter wizard. You can select multiple forms to convert from the dialog box by using the Ctrl key. (Image unavailable)

Figure 8-10 On this page, you choose options for conversion: you can overwrite your existing forms or enable the debug mode for your converted forms. (Image unavailable)

Results of the Conversion Process

When you click the Finish button, the wizard converts your form. At the end of the conversion, the wizard displays its results. There can be three results:

  • Successful conversion. This result means that the form was converted and the Form Converter has no suggestions for improving the layout and functionality of the form through post-conversion edits. A successful conversion is shown in Figure 8-11.
  • Figure 8-11 The Form Converter lets you know when you’ve converted a form successfully. (Image unavailable)

  • Successful conversion with To-Do list. This result means that although the form was converted successfully overall, the Form Converter describes some post-conversion enhancements that you can make or some functionality on the form that did not convert. The Form Converter creates a text version of the To-Do list it displays, named ToDo.txt, and copies it into the same folder it places the ASP files for the converted form. Figure 8-12 shows a successful conversion with a To-Do list.
  • Figure 8-12 A successful conversion with a To-Do list offers suggestions. (Image unavailable)

  • No Conversion. This result means that the Form Converter could not convert the specified form. This unsuccessful conversion could be due to a number of issues, the most common being that the form you are trying to convert does not fall into one of the three supported form types. Figure 8-13 shows an example of an unsuccessful attempt to convert a Task form from an .oft file.
  • Figure 8-13 Attempting to convert a task form results in the Form Converter returning a No Conversion result. (Image unavailable)

Viewing the Results

The most common way to view the results of your conversion is to launch your web browser and type http://OWAServer/exchange/ for the URL, replacing OWAServer with your Outlook Web Access server name. When the Outlook Web Access Log On page is displayed, log on. Select Custom Form from the Compose New drop-down list as shown in Figure 8-14, and click the Compose New link.

Figure 8-14 Selecting Custom Form from the Compose New drop-down list in Outlook Web Access to view forms converted with the HTML Form Converter. (Image unavailable)

After you select Custom Form and click the Compose New link, the Launch Custom Forms window is displayed, as shown in Figure 8-15. This window lists the custom forms in your web forms library; the forms you converted using the Form Converter will be listed here. Click the link of the custom form that you want to test.

Figure 8-15 The Launch Custom Forms window lists the forms in your web forms library. (Image unavailable)

Examples of Conversions

Now let’s take a look at a few figures showing Outlook forms before and after being run through the Form Converter. Some of the figures contain the limitations mentioned earlier.

Figure 8-16 shows the converted Compose form for the Account Tracking application discussed in Chapter 7. The Account Tracking application was not designed with conversion to the web in mind; therefore, a large amount of dynamic user-interface script was generated for the form. Typically, when forms use a lot of script to change user interface elements (for example, when you dynamically disable controls on your form based on the values a user types in another control), you will need to manually code many of the changes on the converted HTML form.

Figure 8-16 The Compose form for the Account Tracking application. Notice how the picture does not come across on the CommandButton control. (Image unavailable)

Figure 8-17 on the next page shows the Read form for the Account Tracking application. The form’s custom actions display as buttons in the HTML version. Also notice that the Form Converter automatically converts the Read form for your Outlook application. The CDO rendering library, which you will learn about in Chapter 11, also automatically recognizes that the user is reading information for an application and thus launches the Read form when that user clicks on data in your application. All the binding of data in the form is generated by the Form Converter. You should be aware, however, that the HTML version of this form does not have the full functionality of the Outlook version. For example, the HTML version cannot display the embedded Tasks or Contacts for the account because these are populated by using VBScript in the Outlook form.

Figure 8-17 The Read form for the Account Tracking application. Notice that the custom actions come across as buttons on the converted form. (Image unavailable)

Figure 8-18 shows a helpdesk application before conversion to HTML, and Figure 8-19 shows the application after conversion. Notice the Opened By text box is automatically filled for the Outlook version but not filled for the web version. However, the web version does have text boxes where the default values are specified.

Figure 8-20 and Figure 8-21 on page 250 show the before and after versions, respectively, of another helpdesk application. The Form Converter automatically converts the rocks bitmap to a GIF.

Figure 8-18 The Outlook version of a helpdesk application. (Image unavailable)

Figure 8-19 The web version of a helpdesk application. (Image unavailable)

Figure 8-20 The Outlook version of another helpdesk application. (Image unavailable)

Figure 8-21 The web version of the helpdesk application in Figure 8-20. (Image unavailable)

Files Created for Converted Forms

Forms converted by the Outlook HTML Form Converter consist of a number of files that you can customize. These files are placed in the web forms library, which we will discuss in the next section. Let’s look at the set of HTML and ASP files that comprise the core architecture of the Form Converter.


This file is the entry point of the converted or custom form. For the Form Converter, this file includes script and an HTML frameset that displays the other components of the form. This file is discussed more in the next section on the web forms library.


This file is the frame of the form, located near the top of the screen. This frame contains the toolbar and the tab strip. The main purpose of this file is to handle form commands generated by clicking the toolbar buttons and the tab strip.

Page_N.asp and Page_N-Read.asp

Every page in a converted form is represented by a separate .asp file. Certain pages of a form have predefined names—for example, the Options tab is named Options.asp. Custom pages of a form are assigned system-generated names, such as Page_3.asp. These custom form pages are generated by the Form Converter. If you created a separate compose and read layout for a particular form page, its file will have two different versions: Page_N.asp for composing the custom form, and Page_N-Read.asp for reading the custom form.


Commands.asp is used to implement utility functions and event handlers for the converted form. Commands.asp is never seen by the user but rather is a hidden .asp file that is called to handle functions such as standard actions (On_Send, On_Reply, and so on) and also custom action event handlers.


The Form Converter automatically creates and publishes a Form.ini file for your application. This file contains the form’s display name and code page, and indicates whether the form should be hidden in the Launch Custom Forms window. This file is discussed more in the next section on the web forms library.

Web Forms Library

After the Outlook HTML Form Converter wizard is run and the necessary files are created, the files are copied to the web forms library in Outlook Web Access. You might be wondering what the web forms library is—well, it’s nothing more than a folder, named Webdata, on the server where Outlook Web Access was installed and some associated files. CDO uses the Webdata folder to allow developers to publish custom forms for the Outlook Web Access client. By default, the Webdata folder is located at C:\exchsrvr\Webdata. Within the Webdata folder are additional subfolders that contain converted forms and other files.

If you browse the Webdata folder, you will see a folder structure similar to that shown in Figure 8-22. In the Webdata folder is a subfolder named for the language pack you installed for Outlook Web Access—probably USA. Open it to find the Forms subfolder. This is where all the default forms for this particular web server are stored.

Figure 8-22 The web forms library folder structure. This structure is used by Outlook Web Access to show available web applications to users. (Image unavailable)

All folders under the Forms subfolder correspond to custom message classes in Outlook. For example, if you have a custom form in Outlook with the message class IPM.Post.Project, the Form Converter creates a subfolder under the IPM\Post folder named Project, and copies all ASP and related files for that converted form into the Project subfolder. When a user views the custom forms in Outlook Web Access, she will see a new form named Project. A user can refresh the custom forms listing in the Launch Custom Forms window because the CDO object library allows this. Once the user clicks on the Project link in the Launch Custom Forms window, the converted Outlook form appears in her browser.

The web forms library does not have to include converted Outlook forms only. You can place your own web-based applications there. The applications you place in the library do not even have to be Exchange Server applications. You can add any application that can be used on a Web server. For example, you can place a SQL-based web application in the web forms library. This can make it easier for users because they can find the web-based enterprise applications they need in a single location. Furthermore, since Outlook Web Access can authenticate users in your ASP session, you can use this authentication in other Web-based applications stored in the web forms library.

Adding Web-Based Applications to the Web Forms Library

To add a web-based application to the web forms library, you first need to create a subfolder for your application under the Forms folder. Then you need to specify certain names for your ASP files so that Outlook Web Access can recognize your application. You need to place three files in the form’s subfolder: Form.ini, FrmRoot.asp, and Icon.jpg.

Form.ini  Form.ini includes the following three values:

  • The friendly display name of a form, which avoids display of the message class name, such as IPM.Post.Project.
  • The language code page of the form.
  • Whether the form should be hidden in the Launch Custom Forms window. (Hide it if you want to make it available only as a response form.)

This is an example of a Form.ini file:

DisplayName=My Custom Exchange and SQL Application

Setting the Hidden variable to 0 makes a hyperlink to this application available in the Launch Custom Forms window. Setting Hidden to 1 hides the hyperlink. If your form is going to appear correctly when a user clicks on its name in the Launch Custom Forms window, you need to create a file named FrmRoot.asp in the form’s subfolder. When the CDO Rendering Objects trace the Webdata folder tree, they recognize the Form.ini file and automatically add a hyperlink in the Launch Custom Forms window to the file FrmRoot.asp. If you do not create this file, your application name will appear as a hyperlink, but the link will be broken. In your FrmRoot.asp, you can redirect users to the web server that contains your application or place your application code directly in the file. Include any necessary files in the subfolder you created for the application. If you place your application code in the same subfolder as Outlook Web Access, you can take advantage of the authentication and Exchange Server ASP Session objects that Outlook Web Access creates for you. If your application requires authentication and you redirect the browser to a separate web location, you will have to create your own authentication code and CDO session for the Exchange Server.

Icon.jpg  To make an icon appear to the left of the hyperlink for your web-based application in the Launch Custom Forms window, you must place a JPEG file, named Icon.jpg, in the form’s subfolder. If you do not do this, the image will be displayed as missing.

Making HTML Forms Available in Outlook

You might want to make your converted forms and web applications in the web forms library available to users who are running Outlook 97, Outlook 98, Outlook 2000, Outlook for the Macintosh, or Outlook for Windows 3.1. To do this, you need to set some options in the Outlook client by following these steps:

  1. In Outlook, from the Tools menu, select Options.
  2. For Outlook 98, click on the Other tab, click the Advanced Options button, click the Custom Forms button, and then click the Web Services button. This displays the Web Services dialog box. A configured Web Services dialog box for Outlook 98 is displayed in Figure 8-23.

  3. NOTE:
    The version of Outlook that your users have determines the location of the Web Services button. Users can always find it, however, by clicking the Custom Forms button.

    Figure 8-23 A fully configured Web Services dialog box in Outlook 98. (Image unavailable)

  4. Check the Use Outlook Web Access To Open Messages Not Understood By The Outlook Client check box.
  5. In the Web Services Location text box, type the following URL, replacing OWAServer with the name of your Outlook Web Access server:
  6. http://OWAServer/exchange/forms/openitem.asp

    This option causes Outlook to search the web forms library if it receives an item with a message class that does not have a corresponding Outlook form. Outlook looks in the web forms library for a web-based form that matches the message class.

  7. If you want to prompt the user before Outlook opens the web form, check the Prompt User Before Opening Each Form check box. If you enable this option, users will see a message similar to Figure 8-24.
  8. Figure 8-24 A prompt telling the user that Outlook is going to look for the custom form in the web forms library. (Image unavailable)

  9. Check the Activate Web Forms Link On Actions Menu check box.
  10. In the Directory Page Location text box, type the following URL, replacing OWAServer with the name of your Outlook Web Access server:
  11. http://OWAServer/exchange/forms/pickform.asp

    This adds the Web Form option under Actions menu to the Outlook client. If a user selects this option from the menu, Outlook will automatically launch the user’s web browser and display the Launch Custom Forms window. Users can then pick the desired web-based form.

  12. Click OK four times.

You should now have an option named Web Form on the Actions menu. If you select this option, the Launch Custom Forms window should appear when you log on.

Tips for Developing HTML-Ready Outlook Apps

This section discusses a few techniques that will simplify the process of converting your Outlook applications to HTML.

Align Your Controls on the Form

The Outlook HTML Form Converter uses HTML tables to position controls, so always use the layout capabilities of the Outlook design environment to line up your controls when you can. HTML tables are not as sophisticated as Outlook’s layout tools, so relying on them for composition is risky. Using the layout tools helps the Form Converter figure out the best layout for your form in HTML, such as where the controls on your form should be relative to one another.

Avoid Calling the Outlook Object Library Interface Objects

As you learned in Chapter 6, the Outlook object library can be divided into an interface library with objects like the Explorer and the Inspector and a data access library with objects like MAPIFolder or Items. If you want to enable the cleanest conversion for your application, avoid dynamically changing the user interface using the Outlook object library because that code cannot be ported directly to HTML. If you require this, keep the changes to a minimum so that you can manually code them easily in the web version of the application.

Avoid Overlapping Controls

Standard HTML today does not support overlapping controls on a web page. If any of the controls overlap, the Form Converter will automatically move one of the controls in the HTML version. If your controls completely overlap, the Form Converter will probably skip converting one of the controls altogether because it won’t be able to resolve which should be converted.

Avoid Using Images on CommandButtons

Since HTML does not support placing images on buttons, your images on CommandButtons will not be converted to HTML.

Do Not Customize the First Page of a Contact Form

The Form Converter works with both Outlook 97 and Outlook 98 forms. Because Outlook 97 did not support first-page customization for a Contact form, the Form Converter will not convert a modified first page of a Contact form to HTML. The Form Converter ignores your modifications.

Do Not Save the Form Definition with the Item

For your form to retain its correct message class, do not save the form definition with the item. If you do save the form definition with the item and convert it, web browser users will see only the form that corresponds to the default message class for the item, such as IPM.Note.

Avoid Using Unsupported Controls

If you can, avoid using the unsupported controls listed in the section "Features of the Converter," which appears earlier in the chapter. If you find that you do need to use them, you can instantiate them as ActiveX controls on an HTML form. You would then have to write the script to enable interaction between the ActiveX controls and the ASP application.

Set AutoSize to True with Image Controls

When working with Image controls, always set the AutoSize property to True under the Advanced Properties for the control. This will force the control to change size based on the size of the image and help avoid unintended sizing when the converter converts the form to HTML.

Meet the Author

Thomas Rizzo is a product manager with the Microsoft Exchange group, where he focuses on building customer confidence and productivity with the platform. He’s also served as a system engineer on the Exchange team and wrote the first two editions of this popular book.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews