Exchange 2000 and Exchange Server 5.5 Public-Folder Interoperability

Understanding the subtleties of permissions

Even in Exchange Server 5.5, understanding and controlling public-folder replication is more art than science. The landscape is more complicated with the advent of Exchange 2000 Server because mixed environments must consider the interoperability of Exchange 2000 and Exchange Server 5.5 public-folder replication and ultimately the migration of Exchange Server 5.5 public folders to Exchange 2000.

Let's look at some of the core aspects of public folders in a mixed Exchange Server 5.5 environment, including public-folder connection agreements (CAs), public-folder hierarchy replication, and permissions interoperability with groups and distribution lists (DLs).

Public-Folder CAs
Previous articles have described configuration and recipient CAs; "Related Articles in Previous Issues," lists two of those articles. The Exchange 2000 Active Directory Connector (ADC) provides a special type of CA for dealing with public folders. The public folder CA replicates mail addresses for Exchange Server 5.5 public folders into Active Directory (AD) so that Exchange 2000 users can send email messages directly to public folders just as they can in Exchange Server 5.5. Furthermore, you frequently find public folders as recipients of Exchange Server 5.5 DLs so that the public folders can provide an archive for all messages sent to the DL. For public folders to function this way, you must set permissions on the public folder to allow anonymous contributions.

A recipient CA synchronizes a DL as a Universal Distribution Group (UDG) into AD, but you can't include the public folder's mail address in the UDG unless the mail address is specifically synchronized into AD. In ADC beta releases, Microsoft built the synchronization of public-folder mail addresses into the recipient CA, but the company unbundled this functionality into a specific public-folder CA by the time it released Exchange 2000 to manufacturing.

By default, all public folders in an Exchange Server 5.5 organization have mail addresses associated with them. Exchange Server 5.5 creates public folders' directory entries in the site's Recipients container unless you modify the Public Folder container property on the General property page of the Information Store Site Configuration. The public-folder directory entries are hidden from the Global Address List (GAL) by default. Figure 1 shows the E-mail Addresses tab of a public folder on my system. As you can see, it looks like any other mail-enabled object in the Exchange Server 5.5 Directory Service (DS).

To create a public-folder CA, you follow the same procedure that you use to create a recipient CA. Use the Microsoft Management Console (MMC) Active Directory Connector Management snap-in, and select the menu option to create a new CA. At the prompt, select New, Public Folder Connection Agreement, then fill in the various property pages. Set up one public-folder CA for every Exchange Server 5.5 site that has mail-enabled public-folder entries. The Web-exclusive sidebar "Other Good Reasons to Use Public-Folder CAs," http://www.exchangeadmin.com, InstantDoc ID 20332, explains several benefits of public-folder CAs.

By using a specific CA for public-folder mail addresses, Microsoft has been able to predefine most of the configuration, unlike recipient CAs in which you need to perform much of the setup manually. For example, public-folder CAs don't have an option to make a CA one-way. Public-folder CAs are two-way by default, and you can't change the default. Other predefined options that you can't change include the settings in the From Exchange and the From Windows Properties tabs. You can't specify the source or destination containers or organizational units (OUs) on either page—they're inaccessible—and the only objects that you can synchronize are public folders, as Figure 2 shows.

If you're synchronizing folders from Exchange Server 5.5 to Exchange 2000, you don't define the source container for public-folder directory entries because the ADC searches for Public Folder Store objects in all containers from the site level on down, even though you typically create public folders in the Recipients container. Similarly, you don't define a target location for the synchronized objects because you always create these objects in the Microsoft Exchange System Objects container in AD.

If you're synchronizing folders from Exchange 2000 to Exchange Server 5.5, the ADC searches for Exchange 2000 public-folder AD objects only in the Microsoft Exchange System Objects container. The ADC creates directory objects in the Exchange Server 5.5 DS container that the legacyExchangeDN attribute of the Exchange 2000 public folder specifies. This container is typically the Recipients container unless you've changed the default location for Exchange Server 5.5 public folders. The Microsoft Exchange System Objects container isn't part of AD by default, but the Exchange 2000 installation creates it.

Public-Folder Permissions
Exchange 2000 and Exchange Server 5.5 handle public-folder permissions very differently. Exchange Server 5.5 uses ACLs to manage public-folder permissions. An ACL defines the access rights (e.g., read, create, edit, delete) that a user has on a public folder. In Exchange Server 5.5, the ACL isn't stored directly as a property of the public folder; instead, each public folder has an ACLID property that points to an entry in an ACLID table held in the Public Folder Store. Each entry in the ACLID table identifies the access rights for the ACL, including the public-folder owner. The entry in turn points to entries in an ACL-members table in the Public Folder Store. The ACL-members table entries are effectively the distinguished names (DNs) of Exchange Server 5.5 users, as Figure 3 shows. During public-folder replication between Exchange Server 5.5 servers, the ACL information is packaged into a property named ptagACLData, and the receiving Exchange Server 5.5 server unpacks the ptagACLData property and uses the information to update its ACL tables.

In Exchange 2000, the Public Folder Store in Exchange 2000 holds the ACL directly as a property of the public folder. The property, named ptagNTSD and held in the Public Folder Store, contains the Windows 2000 SIDs of the users or groups that are in the ACLs. The difference here is clear: Exchange Server 5.5 completely manages permissions and ACLs. Exchange 2000 relies on Win2K's permissions and ACLs and uses Win2K's security model.

Public-Folder Replication
Exchange Server 5.5 uses the concept of a single public-folder hierarchy, or Public Folder Tree (PFT). Exchange 2000 lets you use multiple public-folder hierarchies. In Exchange 2000, the term MAPI PFT—also known as a Top Level Hierarchy (TLH)—refers to the default PFT, which is common to both Exchange 2000 and Exchange Server 5.5. In Exchange 2000, the MAPI PFT is accessible from Messaging API (MAPI) clients such as Microsoft Outlook and IMAP clients such as Outlook Express. You can access other PFTs that you define yourself—usually referred to as Application PFTs—only with HTTP-DAV clients such as Outlook Web Access (OWA). In Exchange Server 5.5, only the MAPI PFT is available. Therefore, public-folder replication between Exchange 2000 and Exchange Server 5.5 refers to replication of public folders in the MAPI PFT. You can't replicate Application PFTs to Exchange Server 5.5 because that version has no concept of multiple PFTs. In general, avoid Application PFTs because of the predominance of MAPI clients.

All Public Folder Stores contain a special public folder that holds the hierarchy information for the PFT associated with that store. In Exchange Server 5.5, the public-folder hierarchy is replicated by default (even if you disable public-folder replication) to all Public Folder Stores in the organization. The same is true for a PFT in Exchange 2000. Similarly, when you install an Exchange 2000 server into an Exchange Server 5.5 site, the Configuration CA identifies the Exchange 2000 Public Folder Store associated with the MAPI PFT to the existing Exchange Server 5.5 servers, and the Exchange Server 5.5 public-folder hierarchy is replicated to the Exchange 2000 server.

Replicating public folders from Exchange Server 5.5 to Exchange 2000 is no more complicated than replicating public folders from one Exchange Server 5.5 public store to another. You add the Exchange 2000 default Public Folder Store to the list of replicas for the Exchange Server 5.5 public folder, and the replication process takes care of replicating the public-folder content as usual. In the opposite direction, you use the same technique, adding the Exchange Server 5.5 Public Folder Store to the list of replicas for the Exchange 2000 public folder.

The process for replicating the public-folder hierarchy is the same as replicating the content of any other public folder. However, in hierarchy replication, the content being replicated describes the hierarchy of the PFT. Public-folder replication takes place by bundling content into discrete email messages, sending the email messages to the Public Folder Store that holds the replica, unbundling the messages, and applying the content to the Public Folder Store. Note that you don't need to have a public-folder CA in place for this replication to occur. A public-folder CA creates directory entries with mail addresses for public folders; public-folder replication takes place by one Public Folder Store emailing another. Creating a new Public Folder Store in Exchange 2000 automatically associates a mail address with the store; this address is the address that the replication process uses.

Permissions Handling During Mixed-Version Replication
As I've demonstrated, mixed-version replication of public-folder content between Exchange Server 5.5 and Exchange 2000 is relatively straight-forward. However, mixed-version public-folder replication becomes more interesting when ACLs are present on public folders.

An Exchange Server 5.5 public-folder ACL uses the DN to identify a user with permissions, and an Exchange 2000 public-folder ACL uses the SID of a Win2K object. Therefore, when an Exchange Server 5.5 public folder is replicated to an Exchange 2000 Public Folder Store, the ACL data must be converted.

Exchange Server 5.5 sends ACL information for the public folder in the ptagACLData property when it sends an outbound replication message. When an Exchange 2000 Public Folder Store is to host a replica of an Exchange Server 5.5 public folder, it receives this ACL information but must promote the information into its ACL storage property, ptagNTSD. The receiving Exchange 2000 Public Folder Store extracts the ptagACLData information into a temporary table, and for every DN specified in the Exchange Server 5.5 version of the ACL, the Exchange 2000 Public Folder Store looks up information in AD to convert the DN to a SID. This conversion process is possible only if a recipient CA has already synchronized Exchange Server 5.5 mailbox information into AD. As a recipient CA creates an object in AD for an Exchange Server 5.5 mailbox, it writes the DN of the Exchange Server 5.5 mailbox into the legacyExchangeDN attribute of the newly created Win2K object. The Exchange 2000 Public Folder Store can thus build the new ACL by searching AD for objects with a legacyExchangeDN that matches the DN specified in the Exchange Server 5.5­style ACL and using the SID of the matching object. After all the DNs have been resolved to SIDs, the Public Folder Store removes the temporary tables and associates the native Exchange 2000 ptagNTSD property with the public folder. Figure 4 shows this process.

If you've configured the recipient CA to create disabled user objects rather than enabled user objects in AD, the SID of the disabled user object is of little use with respect to enforcing permissions because no user will be logged on as the disabled user object. In this case, the disabled object is present only to provide a complete GAL, as is the case in most migrations. As the ADC creates a disabled user object in AD for an Exchange Server 5.5 mailbox with a Windows NT 4.0 account, the msExchMasterAccountSID attribute of the AD object is populated with the SID of the NT 4.0 account associated with the Exchange Server 5.5 mailbox. If a trust relationship exists between the Win2K domain that holds the disabled user object and the NT domain that holds the Associated-Nt-Account, then the SID of this NT account will be used in the ptagNTSD property. The NT account is the associated external account.

If Exchange 2000 can't resolve the AD lookup for any one of the DNs specified in the ptagACLData, the Public Folder Store doesn't promote the entire list of users associated with the ACL into the ptagNTSD property. Effectively, the Public Folder Store doesn't apply the ACL to the replicated public folder, and no Exchange 2000 users have access rights to the public folder. Anonymous access to the public folder is also prevented. If just one DN can't be resolved, no Exchange 2000 users (apart from the public-folder owners) can access the public folder in case that one user has been explicitly denied access to the public folder but is a member of a group that has read access. Under such circumstances, Exchange 2000 retains the temporary files, and the Public Folder Store attempts to complete the promotion of ptagACLData permissions to the ptagNTSD property every time that a client accesses the folder replica or when replication is attempted.

If AD contains disabled user objects with associated external accounts to represent the Exchange Server 5.5 mailboxes, the trust relationship must exist between the domains for the DN-to-SID conversion to take place. If no trust is in place or other problems accessing the associated external account occur, the Public Folder Store doesn't build the ptagNTSD property and the public-folder replica will be unavailable to Exchange 2000 users. You can draw an immediate conclusion from this behavior: Careful implementation of recipient CAs is crucial for Exchange 2000 and Exchange Server 5.5 public-folder interoperability.

When replication from Exchange 2000 to Exchange Server 5.5 takes place, the outgoing replication message from the Exchange 2000 Public Folder Store includes the ptagACLData property so that the Exchange Server 5.5 server can correctly interpret any ACL information. In addition to providing the properties that the Exchange Server 5.5 Public Folder Store can understand, the outgoing replication message includes the ptagNTSD property that Exchange 2000 uses to replicate public-folder ACL information natively. However, because Exchange Server 5.5 servers can't understand this property, the Exchange Server 5.5 Public Folder Store ignores it, but the property will exist on the Exchange Server 5.5 public-folder replica. If you modify the public-folder replica on the Exchange Server 5.5 Public Folder Store, the outgoing replication messages include this property. Because Exchange Server 5.5 can't enforce any security on this property, any Exchange 2000 Public Folder Stores that receive replication messages from Exchange Server 5.5 will ignore the property.

Exchange Server 5.5 DLs and ACLs
In addition to granting permissions individually to Exchange Server 5.5 mailboxes to use public folders, you can use DLs to control access to public folders, which makes the administrative process easier. Adding users to a DL with access permissions is much simpler than individually managing hundreds or thousands of users in an ACL.

In Win2K, the AD concept of a UDG supersedes the concept of the Exchange Server 5.5 DL. Both the ADC process and the Exchange 2000 upgrade process convert Exchange Server 5.5 DLs into UDGs. Although a UDG offers the same functionality as a DL in terms of mail-address expansion, a UDG isn't a security principal and therefore you can't use a UDG in an ACL to enforce permissions. To use groups to secure access to public folders, Exchange 2000 uses a Universal Security Group (USG). A USG offers the same functionality as a UDG, but you can use USGs in ACLs.

However, USGs can exist only in native-mode Win2K domains. If you use DLs to protect public folders in Exchange Server 5.5 and want to have a coexisting Exchange 2000 and Exchange Server 5.5 environment, you must ensure that any Win2K domains that will hold USGs are in native mode. When you configure recipient CAs to synchronize DLs, the ADC will warn you if the target Win2K domain isn't in native mode. This problem is a good reason to restructure NT 4.0 domains with new Win2K domains rather than upgrade, although the complexity of your NT environment will ultimately dictate the approach that you take.

The Exchange 2000 Public Folder Store will convert UDGs that the ADC has created to become USGs in several circumstances:

If the UDG-to-USG conversion process fails for any reason (e.g., the UDG is in a mixed-mode domain, the membership of a UDG hasn't been replicated), the Public Folder Store will retry the conversion the next time a client accesses the folder or if public-folder replication occurs again from the Exchange Server 5.5 server with a modification to the ACL.

The Public Folder Store won't attempt to convert a UDG in an ACL to a USG in some circumstances:

Some Closing Thoughts
Most of this article has described how Exchange enforces ACLs for both individual users and groups when it replicates an Exchange Server 5.5 public folder to an Exchange 2000 public folder. Essentially, the same process takes place when you upgrade an Exchange Server 5.5 Public Folder Store to become an Exchange 2000 Public Folder Store. In this case, the upgrade process analyzes existing Exchange Server 5.5-style ACLs and converts them to Exchange 2000-style ACLs by resolving the legacyExchangeDN against the AD to retrieve an SID.

Creating public-folder CAs is important. But first you must build a solid infrastructure to let this kind of coexistence take place. Careful attention to domains, trust relationships, the topology of recipient CAs, and thoughtful account migration is indispensable.