Lesson 1: Support for Internet Protocols | MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration

From the moment you install Exchange 2000 Server, your messaging environment relies on Internet protocols. Simple Mail Transfer Protocol (SMTP), for instance, is the native e-mail transport protocol for Exchange 2000 Server. Other protocols, such as POP3, IMAP4, Network News Transfer Protocol (NNTP), and HTTP, provide users with a variety of options for accessing their mailboxes and public folders. All of these protocols are part of IIS 5.0. Their implementation and communication with the Information Store was discussed in Chapter 3, "Microsoft Exchange 2000 Server Architecture."

This lesson provides a brief overview of the supported Internet protocols and illustrates their features in the context of accessing Exchange 2000 data. This lesson concludes with a brief introduction of Lightweight Directory Access Protocol (LDAP), which is a component of Windows 2000 rather than Exchange 2000, yet is still important for address book lookups in Internet mail clients, such as Microsoft Outlook Express.

At the end of this lesson, you will be able to:

Describe the characteristics of supported Internet protocols.
Access mailbox and public folder resources through Internet protocols.

Estimated time to complete this lesson: 90 minutes

Simple Mail Transfer Protocol

SMTP is an industry standard for the Internet, which rules the transfer of e-mail messages between two messaging hosts. It also defines the message formats. An extension to SMTP is SMTP Service Extensions (ESMTP). ESMTP overcomes several critical limitations of the Internet mail transport. For instance, it allows users to request delivery status notifications on their outgoing messages, and it provides the ability to specify a message size limit for incoming ESMTP connections. Both SMTP and ESMTP require a connection-based transport mechanism; in practice this is the TCP/IP protocol.

NOTE
SMTP is described in RFC 821 (the protocol) and RFC 822 (the format of SMTP messages). ESMTP features are defined in RFC 1869.

Sending Messages Using SMTP

To send a message, an SMTP/ESMTP process first connects to TCP port 25 of the remote host. The remote SMTP system, such as a server running Exchange 2000 Server, then answers the incoming request. The SMTP communication will be established and e-mail messages can be transferred (see Figure 11.1).

click to view at full size

Figure 11.1 An SMTP connection over TCP/IP

SMTP defines the commands and responses at the application layer, which must be used between SMTP systems to transfer messages. These commands are used to begin the message sending while responses acknowledge the reception. The most important elements of every SMTP exchange are the welcome message, which the server returns to the client, the HELO (or EHLO for ESMTP) command to start the session, the MAIL FROM command to indicate an originator address, RCPT TO to specify mail recipients, and DATA to initiate the transfer of the message. The QUIT command ends the current session and initiates the termination of the connection (see Figure 11.2).

SMTP Service Extensions

ESMTP provides a framework for two types of SMTP extensions: registered and unregistered extensions. A good example of a registered extension is the DSN command, which notifies the receiving system that a delivery status notification should be returned to the sending host. Another example is SIZE, which allows restricting the size of incoming messages prior to their transmission. Unregistered commands, also known as local verbs, must start with an X to indicate that they are not standardized. The XEXCH50 command, as it is supported by the SMTP service, represents such a local verb. XEXCH50 is used to allow Exchange-specific content information in messages.

NOTE
Every ESMTP session begins with the EHLO command, in contrast to HELO, which initiates an ordinary SMTP session.

Name Resolution

To establish a connection, the SMTP service must determine the remote host's IP address. Windows 2000 supports several name resolution mechanisms, including the HOSTS file, DNS, Windows Internet Name Service (WINS), the LMHOSTS file, and Active Directory directory service. Exchange 2000 servers that belong to the same organization are able to locate each other using Active Directory.

click to view at full size

Figure 11.2 Sending SMTP messages

DNS Name Resolution

DNS will most likely be used to accomplish name resolution when communicating with hosts directly on the Internet. To retrieve the IP address of an SMTP host, the SMTP service uses a component of the TCP/IP protocol stack, known as the Resolver, to contact the local DNS server. If the domain name cannot be resolved locally, the local DNS server on behalf of the actual Resolver will query another DNS server. Eventually, the IP address of an SMTP host is finally returned to the Resolver, which in turn passes it to the SMTP service. The SMTP service is then able to establish the connection and transfer the message.

Mail Exchanger Records

DNS mail exchanger (MX) records point to computers that are able to handle SMTP connections. It is common to have multiple SMTP servers within an organization, so more than one MX record may exist per Internet domain. It is possible to identify more important and less important hosts by assigning priorities to MX records. Only in cases where most important hosts (those with lowest preference values) are unavailable will lower priority hosts be contacted. Hosts with the same priority are pooled together, and DNS returns their IP addresses according to the round-robin principle, which determines that the order of the hosts in the list is changed in a cyclic permutation, so the host that was first in the previous list is last in the new list. Multiple mail exchangers can provide load balancing and fault tolerance for incoming messaging connections.

Exercise 1: Examining DNS MX Records

In this exercise you will verify the existence of DNS records for Internet domains. You will use the NSLookup utility on a real-life connection to examine Microsoft's MX entries.

To view a multimedia demonstration that displays how to perform this procedure, run the EX1CH11.AVI files from the \Exercise_Information\Chapter11 folder on the Supplemental Course Materials CD.

Prerequisites

Your workstation running Windows 2000 is connected to the Internet.
The interface to the Internet (network card or modem) is manually or automatically configured for a DNS server.

To use NSLookup for DNS MX queries

Click Start and select Run to display the Run dialog box, where you need to type cmd and click OK to open a Windows 2000 command prompt.
Type nslookup and press Enter.
Type set type=mx and press Enter.
Type microsoft.com and press Enter.
At this point, you should be able to examine the MX entries for the domain microsoft.com (see Figure 11.3).
Type exit and press Enter to exit the NSLookup utility.

Figure 11.3 Testing the DNS name resolution

Exercise Summary

The TCP/IP utility NSLookup allows you to check DNS records, which is especially useful if you are experiencing SMTP connection problems on Internet links. One or more MX hosts should be returned per domain. If a domain does not contain mail exchangers, the SMTP service will not be able to resolve the domain name through DNS. You may then associate the IP address with the e-mail domain name in the HOSTS file, which can be found in the \Winnt\ System32\Drivers\Etc directory, or you can configure an SMTP Connector to directly deliver messages to the target domain's SMTP server. The configuration of SMTP Connectors is the topic of Chapter 16, "Message Routing Administration."

Post Office Protocol, Version 3

POP3 is a messaging protocol that defines commands to download messages from a host. In other words, it is a read-only protocol allowing you to download messages from your server-based Inbox only. Access to other server-based message folders is not possible. Examples of POP3 clients are Outlook Express, Eudora, and Netscape Navigator Mail. The POP3 features are described in RFC 1939.

Important
To send messages, POP3 users rely on SMTP. Consequently, you need to provide your users with an SMTP server in addition to a POP3 host for complete messaging functionality. SMTP and POP3 hosts can be the same or different servers.

Commands and Responses

POP3 commands are not case sensitive. They consist of a keyword followed by arguments, if necessary. Each keyword is separated from its arguments by a single space. Only printable ASCII characters are allowed. POP3 responses, on the other hand, are a combination of a status indicator and a keyword. Additional information may follow. Again, only printable ASCII characters can be used. The two existing status indicators are the positive (+OK) and negative (-ERR) response; both appear in uppercase letters. To give an example of a positive indicator, the server's typical response to an incoming connection on port 110 is +OK Microsoft Exchange 2000 POP3 Server Version 6.0.4417.0 (bluesky-srv1.BlueSky-inc-10.com) Ready.

POP3 Session States

A POP3 session progresses through three states, called Authorization, Transaction, and Update. The Authorization state is reached when a server's welcome message is received after the client has opened a connection to TCP port 110. In this state, the user account information can be sent to the server. Once the user has been validated, the session enters the Transaction state. Now, the user can read, download, or delete e-mail messages as desired. The session is released by sending the QUIT command to the server. At this point, the session enters the Update state, in which the POP3 server sends a goodbye message to the client and releases the TCP/IP connection (see Figure 11.4). It is important to note that the POP3 host performs the actual message processing on the server during the Update state once the client connection has been released. In other words, as long as you are connected with a POP3 client, messages are still available in the Inbox even though you might already have downloaded them. When you disconnect, the server purges the messages.

click to view at full size

Figure 11.4 POP3 session lifetime

Exercise 2: Examining the POP3 Communication

In this exercise you will examine the POP3 communication. You will use the Telnet utility to manually connect to your server-based mailbox via the Default POP3 Virtual Server of Exchange 2000 Server.

To view a multimedia demonstration that displays how to perform this procedure, run the EX2CH11.AVI files from the \Exercise_Information\Chapter11 folder on the Supplemental Course Materials CD.

Prerequisites

Make sure BLUESKY-SRV1 is prepared according to the descriptions given in the "Getting Started" section of "About This Book" and running Exchange 2000 Server.
Log on as Administrator to BLUESKY-SRV1.

To use Telnet for POP3 tests

Click Start and select Run to display the Run dialog box, where you need to type cmd and click OK to display the Windows 2000 command prompt.
Type telnet and press Enter.
Type set LOCAL_ECHO and press Enter to enable the local echo, or you will not be able to see what you type when you connect to the POP3 host.
Type open localhost 110 and press Enter. Verify that you are connected to the POP3 virtual server and that the welcome message +OK Microsoft Exchange 2000 POP3 Server Version. 6.0.4417.0 (bluesky-srv1.BlueSky-inc-10.com) Ready is displayed.
Type user administrator and press Enter. Verify that the server response is +OK.
Type pass password and press Enter. Verify that the server response is +OK User Successfully Logged On.
Type list and press Enter. A positive response, together with a list of messages in your Inbox, will be returned.
Make sure at least one message exists in your Inbox, then type retr 1 to retrieve the first message, and press Enter.
At this point, the POP3 virtual server should return the message in Multiple Internet Mail Extensions (MIME)-encoded format. Telnet will display bitmaps and other graphical elements as plain text (see Figure 11.5).
Type quit, press Enter, and, when the connection is terminated, press any key to continue.

Figure 11.5 Retrieving a message using POP3
At the Microsoft Telnet prompt, type quit, and press Enter, then close the command prompt window.

Exercise Summary

POP3 is a simple protocol that you can test manually when using the Telnet utility. Because Telnet has no way to use the integrated Windows 2000 Authentication mechanism, you need to supply a user name and password and rely on the Basic Authentication (clear text). As soon as you are logged on to your mailbox, you can list and download messages from the Inbox. Other folders, however, are not accessible. The authentication mechanisms are covered in more detail in Lesson 2.

Internet Mail Access Protocol Version 4

IMAP4 is a modern Internet protocol that allows you to access all kinds of server-based messaging folders. In other words, using an IMAP4-compliant client, you are not restricted to Inbox access only, as you would be using POP3. This allows you to maintain all messages entirely at the server. However, it is also possible to create a local message store, for instance, if you need to work disconnected from the server and let the IMAP4 client, such as Outlook Express, synchronize the local repository with the data on the server. IMAP4 is described in a series of RFCs, most importantly in RFC 2060.

NOTE
IMAP4 is defined in RFCs 1731, 1732, 1733, 2060, 2061, 2086, 2087, 2088, 2095, 2177, and 2180.

IMAP4 Session States

IMAP4 defines four subsequent session states, which are the Non-Authenticated, Authenticated, Selected, and Logout states (see Figure 11.6). The Non-Authenticated state will be entered as soon as an IMAP4 client connects to TCP port 143 at the server. In this state, the client must supply authentication credentials. Most commands cannot be used yet. The server's greeting * OK Microsoft Exchange 2000 IMAP4rev1 Server Version 6.0.4417.0 (bluesky-srv1.BlueSky-inc-10.com) Ready is an example of a response allowed in this state.

As soon as the client logs on using the LOGIN command, the session enters the Authenticated state. The important task a client has to accomplish now is selecting a folder from the mailbox. The client will use the SELECT command for this purpose, in this way entering the Selected state. In this state most of the IMAP4 commands are available. STORE and FETCH are good examples of such commands. Users work with their IMAP4 clients typically in Selected state. Once the work is finished, the user will log off. Consequently, the client transmits the LOGOUT command to the server, and the connection enters the Logout state. The connection is being terminated, and the server will close the connection, sending its goodbye notification.

click to view at full size

Figure 11.6 IMAP4 session state

Commands and Responses

IMAP4 commands are case-insensitive strings of printable ASCII characters, which consist of a tag followed by a keyword and its arguments, if necessary. Every keyword is separated from its arguments by a single space. An identifier, known as a tag, prefixes each client command. Those tags are necessary because multiple commands may be in progress simultaneously. As the server responds to a command, it will use the tag to identify the command to which the response belongs. Data transmitted by the host and status notifications that are not associated with a client command must be prefixed with the token "*". These constructs are called untagged responses.

Exercise 3: Examining the IMAP4 Communication

In this exercise you will examine the IMAP4 protocol in action. You will use the Telnet utility again to manually connect to your server-based mailbox, this time via the Default IMAP4 Virtual Server of Exchange 2000 Server.

To view a multimedia demonstration that displays how to perform this procedure, run the EX3CH11.AVI files from the \Exercise_Information\Chapter11 folder on the Supplemental Course Materials CD.

Prerequisites

Make sure BLUESKY-SRV1 is prepared according to the descriptions given in the "Getting Started" section of "About This Book" and running Exchange 2000 Server.
Log on as Administrator to BLUESKY-SRV1.

To use Telnet for IMAP4 tests

Click Start and select Run to display the Run dialog box, where you need to type cmd and click OK to display the Windows 2000 command prompt.
Type telnet and press Enter.
Type set LOCAL_ECHO and press Enter to enable the local echo, or you will not be able to see what you type when you connect to the POP3 host.
Type open localhost 143 and press Enter. Verify that you are connected to the IMAP4 virtual server and that the welcome message * OK Microsoft Exchange 2000 IMAP4rev1 Server Version 6.0.4417.0 (bluesky-srv1.BlueSky-inc-10.com) Ready is returned to you.
Type 0000 login administrator password and press Enter. Verify that the server response is 0000 OK LOGIN Completed.
Type 0001 select "inbox" and press Enter. A positive response (0001 OK [READ-WRITE] SELECT Completed.), together with information about the messages in your Inbox, will be returned.
Type 0002 fetch 1 all and press Enter. Verify that you receive a positive response of 0002 OK FETCH Completed.
At this point, you should be able to examine the header information, which the IMAP4 virtual server returns to your Telnet client (see Figure 11.7).
Type 0003 logout and press Enter.

Figure 11.7 Retrieving a message using IMAP4

Exercise Summary

IMAP4 is more powerful than POP3 because it allows you to work with all kinds of messaging folders, including public folders. You need to select the folder you want to access explicitly after you log on. You need to supply a mailbox name and password when examining the IMAP4 protocol in Telnet. The authentication mechanisms are covered in Lesson 2.

Network News Transfer Protocol

USENET is a communication network based on NNTP, which relies on distributed discussion forums known as newsgroups. A vast number of newsgroups exist, but it is not always easy to find the desired information. A good Web site, such as http://www.usenet.org/, can simplify use of the USENET network.

NOTE
NNTP is described in RFC 977. The actual format of USENET articles is defined in RFC 1036; attachments are encoded using either Unix to Unix Encoding (UUENCODE) or MIME.

Newsgroups

Newsgroups can be compared to regular public folders in Exchange 2000 Server. They represent the context of discussions, as do public folders. Articles posted in newsgroups represent bits and pieces of discussions, as do messages in public folders. Last but not least, articles will be replicated to all instances of a particular newsgroup across the USENET, as messages are replicated to all instances of a particular public folder across the organization. Newsgroup replication requires newsfeeds, whereas the public folder replication relies on Information Store replication links. Public folder replication is discussed in Chapter 18, "Public Folder Replication."

Newsreaders

A newsreader application is a client program that can be used to read newsgroup articles. In more technical terms, a newsreader is able to communicate via NNTP. Public folders can be accessed because Exchange 2000 Server supports newsreaders via the extended NNTP service of Windows 2000. In every case, the client needs to establish a connection to TCP port 119 to exchange commands and responses with the server (see Figure 11.8).

click to view at full size

Figure 11.8 Accessing newsgroups over NNTP

Newsfeeds

Multiple instances of one particular newsgroup reside typically on multiple servers. Hence, a mechanism must exist to replicate articles between the instances of the same newsgroup. Processes that accomplish this task are known as newsfeeds. You can think of a newsfeed as a user working with a newsreader. Let's say you want to receive new changes from a remote server. Accordingly, you will connect to the remote server's port 119 first. You can then check the remote server for new articles and request those that you haven't yet received. As you pull new articles, you are acting as a pull feed. On the other hand, you may also have new articles to post. Using your newsreader, you can simply upload them to the remote server. In complicated language, you push your information into the host, acting like a push feed. Through control messages, a newsfeed may even create new newsgroups on the remote host.

NOTE
In general, two forms of NNTP data transfer exist. They are the pull and the push transfer.

The terms push and pull may also be used to specify which host initiates the communication:

Pull feed. The local host initiates the connection to the remote server and pulls the information.
Push feed. The remote server (such as a provider's host) initiates the connection and pushes the information into the local host.

Pull Versus Push

Usage of NTTP differs slightly between pull and push feeds. Whereas pull feeds need a command set for querying remote servers about available articles, push feeds need a command set for newsgroup creation and article posting. Pull feeds are more flexible than push feeds because they allow you to select the newsgroups you want to receive. On the other hand, push feeds provide advantages if the replicated amount of information is large. When configuring push feeds, you typically will need the cooperation of your service provider to specify the newsgroups you want to feed into your organization.

NNTP Communication

NNTP works similar to SMTP, POP3, and IMAP4. Newsreader applications open a connection to TCP port 119 to establish a session. The NNTP server sends its welcome message back to the client, such as 200 NNTP Service 5.00.0984 Version: 5.0.2195.1608 Posting Allowed. After that, client and host can exchange NNTP command and response sequences. NNTP commands are not case sensitive. They are represented as keywords followed by arguments, which are separated by a single space. Only printable ASCII characters are valid.

Exercise 4: Examining the NNTP Communication

In this exercise you will examine the communication with the extended NNTP service of Windows 2000. Similar to Exercises 2 and 3, you will use the Telnet client to establish a session and exchange typical commands and responses.

To view a multimedia demonstration that displays how to perform this procedure, run the EX4CH11.AVI files from the \Exercise_Information\Chapter11 folder on the Supplemental Course Materials CD.

Prerequisites

Make sure BLUESKY-SRV1 is prepared according to the descriptions given in the "Getting Started" section of "About This Book" and running Exchange 2000 Server.
Log on as Administrator to BLUESKY-SRV1.

To use Telnet for NNTP tests

Click Start and select Run to display the Run dialog box, where you need to type cmd and click OK to display the Windows 2000 command prompt.
Type telnet and press Enter.
Type set LOCAL_ECHO and press Enter to enable the local echo, or you will not be able to see what you type when you connect to the POP3 host.
Type open localhost 119 and press Enter. Verify that you are connected to the IMAP4 virtual server and that the welcome message 200 NNTP Service 5.00.0984 Version: 5.0.2195.1608 Posting Allowed is returned to you.
Type list and press Enter to display a list of newsgroups that this server maintains (by default, control.cancel, control.newgroup, and control.rmgroup are listed, which are used to store newsfeed control messages).
Type group control.cancel and press Enter. Notice the positive response and the number of e-mails in the newsgroup (most likely there are no messages in this group).
At this point, you have successfully tested the NNTP connectivity to your Exchange 2000 Server and queried existing newsgroups (see Figure 11.9).
Type quit and press Enter.

Figure 11.9 Using Telnet as a newsreader application

Exercise Summary

You can use Telnet to log on to a NNTP newsgroup host. You must provide valid authentication information using the AUTHINFO USER command. The host will return a positive response, 381 Waiting For Password, which indicates that it is now time to enter the password through the AUTHINFO PASS command. A positive response would be 281 Authentication OK. At this point, access to available newsgroups is possible and articles can be retrieved or posted.

NOTE
The HELP command is useful if you want to explore the set of supported NNTP commands in Telnet.

Hypertext Transfer Protocol

HTTP is the data vehicle of the World Wide Web. Its first version (now referred to as HTTP/0.9) was a simple protocol to transfer data, such as Web pages, across the Internet. In 1996, a revision known as HTTP/1.0 significantly improved and standardized the protocol, which was again superseded by HTTP/1.1 in 1997. The current version of HTTP is defined in RFC 2616.

To transfer data, an HTTP-compliant client, such as Microsoft Internet Explorer or Netscape Navigator, needs to connect to an HTTP (Web) server, such as the World Wide Web Publishing Service of Windows 2000 Server. By default, the Web browser connects to the server's TCP port 80, although you can use custom ports as well.

URIs and URLs

To tell the Web server which document to return, the browser has to provide a uniform resource identifier (URI), most commonly known as a Web address, shortcut, or URL. A URL is actually a specific type of URI that identifies a resource through its location on the network, for instance, http://www.microsoft.com/exchange/default.htm. The other possible type of URI is a uniform resource name (URN), which identifies a resource through its globally unique distinguished name. URI, URL, and URN are described in RFC 2396.

HTTP Extensions for Distributed Authoring

The Distributed Authoring and Versioning Protocol usually referred to as WebDAV is an extension of HTTP/1.1. Unlike HTTP, which is primarily used to request Web pages from a server, WebDAV specifies methods, headers, and content types for the management of resource properties directly on the server, as well as the creation of resource collections, the manipulation of namespaces, and the locking of resources to avoid collisions due to concurrent access from multiple clients. WebDAV can encode data elements either in Extensible Markup Language (XML) or in HTTP headers. The WebDAV protocol is defined in RFC 2518.

IIS 5.0 fully supports WebDAV if Exchange 2000 Server is installed, meaning you can publish a WebDAV directory on your Web server and let your users easily collaborate on documents over the Internet. WebDAV provides methods for resource locking, so other people are blocked from reading a particular document when you are modifying it on the server. When working with Microsoft Office 2000 applications, for instance, you can create, edit, and save documents directly into a WebDAV directory by specifying its URL instead of a Universal Naming Convention (UNC) path. It is likewise possible to connect to a WebDAV directory in Windows 2000 via My Network Places and the Add Network Place Wizard in much the same way you would connect to any ordinary network share.

Microsoft Exchange 2000 Web Storage System

Exercise 4 of Chapter 1, "Introduction to Microsoft Exchange 2000," demonstrated how standard Office 2000 applications could read and write items directly from and to mailboxes and public folders. File system access to Exchange resources is supported by means of the Web Storage System and a component called Exchange Installable File System (ExIFS). Don't get confused: ExIFS relies on the Web Storage System, but they are not the same. The Web Storage System is also involved when accessing Exchange resources via WebDAV, but ExIFS is not.

Every item within in the Web Storage System is accessible via the WebDAV protocol. This means that you are able to publish a public folder, for example, in the form of a WebDAV directory and let your users connect to it using the Add Network Place Wizard and the folder's URL (see Figure 11.10). Every folder and each message or other document in a folder has a URL associated with it.

click to view at full size

Figure 11.10 Collaborating on documents through WebDAV and the Web Storage System

The Web Storage System associates items accessible through URLs with Web forms, which are comparable to Outlook forms, although they are entirely HTML-based and provide more extensibility capabilities. The Web Storage System relies on content classes to associate particular items with their corresponding forms. Any Web browser that supports HTML 3.2 or later can work with Web forms. Outlook Web Access (OWA) of Exchange 2000 Server, for example, relies on the association of Outlook folders and intrinsic message items with Web views and forms. You can read more about the architecture of the Web Storage System in Chapter 23, "Microsoft Exchange 2000 Web Storage System."

Exercise 5: Working with Published WebDAV Resources and the Web Storage System

In this exercise you will examine how easy it is to access public folders residing in the Information Store via WebDAV. You will use Windows Explorer to access published folder repositories.

To view a multimedia demonstration that displays how to perform this procedure, run the EX5CH11.AVI files from the \Exercise_Information\Chapter11 folder on the Supplemental Course Materials CD.

Prerequisites

Reboot BLUESKY-SRV1, start BLUESKY-WKSTA, and log on as Administrator.

To work with published Exchange-WebDAV directories

On BLUESKY-WKSTA, on the desktop, right-click on My Network Places, and then select Explore.
In the right pane of the My Network Places window, double-click on Add Network Place.
In the Add Network Place Wizard, under Type The Location Of The Network Place, type http://bluesky-srv1/public, and then click Next.
In the Completing The Add Network Place wizard screen, under Enter A Name For This Network Place, type All Public Folders on BLUESKY-SRV1, and then click Finish.
At this point, you have successful created a connection to the Web Storage System of BLUESKY-SRV1 (see Figure 11.11).

Figure 11.11 Connecting to public folders via WebDAV
The All Public Folders On BLUESKY-SRV1 window will be opened automatically, displaying a subfolder named Internet Newsgroups, which corresponds to the Internet Newsgroups public folder.
Open the File menu, point to New, and select Folder. Then press Enter to accept the default name, New Folder. You now have created a new public folder on BLUESKY-SRV1.
Use Windows Explorer to copy a file into the New Folder repository.
Click Start, select Run, and, in the Run dialog box, type http://bluesky-srv1/exchange, then click OK to launch a session with Outlook Web Access.
If this is the first time you have launched Internet Explorer, the Internet Connection Wizard appears. Select I Want To Set Up My Internet Connection Manually, click Next, select I Connect Through A Local Area Network (LAN), click Next twice, and answer the question, Do You Want To Set Up An Internet Mail Account Now, with No. Click Next, and then click Finish.
In Outlook Web Access, in the left frame, click on Folders, and then expand the Public Folders tree.
At this point, you can select the public folder called New Folder and verify that items copied into this public folder are listed (see Figure 11.12).

Figure 11.12 Cross-platform collaboration via WebDAV and the Web Storage System

Exercise Summary

By default, every user can access Exchange 2000 Server resources in the context of their access permissions via HTTP and WebDAV. WebDAV relies on the security features offered by Windows 2000, IIS 5.0, and Exchange 2000 Server. For instance, you may use the Add Network Places Wizard to add a connection to the public folder tree, but when you click on a folder for which you don't have the Read permission, the Enter Network Password dialog box will be displayed, prompting you for a different account name and password. If you don't have the Folder Visible permission, the public folder will not be listed in Windows Explorer at all. The management of public folders is the topic of Chapter 17, "Public Folder Management."

NOTE
HTTP and WebDAV are Internet standards supported on all client platforms. Macintosh or UNIX client computers can rely on WebDAV to share information with Windows users directly.

Lightweight Directory Access Protocol

LDAP is a derivation of X.500 Directory Access Protocol . It was originally developed at the University of Michigan to provide a more efficient way to build and access a hierarchical directory based on object attributes. This industry standard is described in RFC 1777.

LDAP Features

As designed for the Internet, LDAP uses the TCP/IP transport mechanism for client-server communication. The server "listens" for incoming requests on TCP port 389 by default. To provide security, LDAP uses an encoding scheme called Basic Encoding Rules (BER). The encoding is performed on top of the transport layer (the layer at which the Transport Control Protocol [TCP] operates).

LDAP implementations assume support for the X.500 naming model for maximum interoperability between client and server. In other words, systems that reference directory objects through distinguished names (for example, a Windows 2000 Global Catalog server) provide an ideal platform for LDAP clients.

Available Versions

Three LDAP versions currently exist, although the third version has not yet been specified completely. In Exchange 2000 Server organizations, LDAP is available through Active Directory and Global Catalog servers. Any LDAP application, such as Outlook Express, can therefore be used to look up the directory and address information as soon as Active Directory is configured. Active Directory supports the full set of LDAP features as outlined in the third protocol version.

LDAP and Windows 2000 Active Directory Directory Services

If you plan to use Internet mail clients, such as Outlook Express, to participate in an Exchange 2000 Server organization, required address information is available via LDAP and Active Directory. All Exchange 2000 recipient objects are maintained in Active Directory, and their most common attributes are replicated to the Global Catalog for address name resolution, as explained in Chapter 2, "Integration with Microsoft Windows 2000." The Global Catalog holds the recipient information for the entire forest. It is therefore advisable to configure an LDAP connection to a Global Catalog server to be able to search the full set of address information from your organization. When configuring your LDAP client, make sure to connect to TCP port 3268 instead of the default port 389 to reach the Global Catalog.

The following ports allow you to connect to Active Directory via LDAP:

Port 389 for Active Directory domain controllers
Port 636 for Active Directory domain controllers over Secure Sockets Layer (SSL)
Port 3268 for Global Catalog servers
Port 3269 for Global Catalog servers over SSL

NOTE
When accessing TCP port 389, only the objects within the home domain of the Active Directory domain controller are searchable. A query to port 3268 gives you the ability to search address information in the entire forest, although only the properties tagged for replication to the Global Catalog will be returned.

The configuration of LDAP searches and the address name resolution are covered in the Windows 2000 Server Distributed Systems Guide of the Windows 2000 Server Resource Kit.