Article ID: 264889 - View products that this article applies to.
This article was previously published under Q264889
This article has been archived. It is offered "as is" and will no longer be updated.
In Microsoft Exchange Server 5.5, public folders are represented in two places: in the information store (hierarchy, [ACLs], and data content), and in the directory service. The directory representation is used mainly for revealing the public folders in the global address list, and for applications to send mail to each public folder. In Exchange Server 5.5, every public folder is represented in the directory and information store, and every public folder has to be mail-enabled (that is, have an e-mail address); this is automatic, not optional.
In Exchange 2000, it is recommended that you ensure that the Exchange Server 5.5 model is retained so as to not break Exchange Server 5.5 topologies. You may notice that most of the public folder Connection Agreement user interface (UI) is hard-coded, and that there is very little for you to do to set one up. For example, public folder Connection Agreements must be two-way, deletions turned on, the From Exchange and From Windows tabs populated for you, and so on. As a result, some people have concerns about implementing them.
It is recommended that you create a public folder Connection Agreement to Active Directory from each one of your existing Exchange Server 5.5 sites. This ensures that all Exchange Server 5.5 public folders are represented in Active Directory, and that all mail-enabled public folders created in Exchange 2000 are represented in the Exchange Server 5.5 directory (public folder Connection Agreements are always two-way). It does not really matter which domains the public folder Connection Agreements replicate to, as long as they exist in Active Directory somewhere.
Ramifications if Public Folder Connection Agreements Are Not In Place
Minimum Public Folder Connection Agreements RecommendedIt can take a while to get public folder Connection Agreements in place and there may be some political challenges to getting them created. Therefore, as a minimum, in the following situations you need a public folder Connection Agreement:
Some customers have chosen to locate the Exchange Server 5.5 Public Folder objects in a special Recipients container in Exchange Server 5.5. This means that Public Folder objects are not in the standard Recipients container. When you create a public folder Connection Agreement, the From Windows and From Exchange tabs are not filled in until you save the Connection Agreement. The public folder Connection Agreement has logic to determine that the location has changed, and it identifies the alternate container.
The importance of getting recipient Connection Agreements in place for a mixed Exchange Server 5.5/Exchange 2000 environment is critical. In Exchange Server 5.5, access control to public folders is based on mailboxes, and in particular, on the X.500 Distinguished Name (DN). Therefore, internally, Exchange Server 5.5 identifies user /o=MSFT/ou=Redmond/ou=Recipients/cn=user as having Editor access to the Public Folders\Technical\Exchange folder. In Exchange 2000, all access control is based on Microsoft Windows 2000 security identifiers (SIDs). Therefore, in a mixed site, the public information store on the Exchange 2000 server has a blank public folder hierarchy. After a short period of time, the information store detects that many public folders exist in the organization and converts their distinguished names to security IDs (SIDs).
Through the process of public folder status messages, the Exchange Server 5.5 computers send their hierarchies to the new Exchange 2000 server. After a public folder hierarchy message is received, Exchange 2000 takes all the existing ACLs (in X.500 distinguished name format) and performs a search in Active Directory. If the Recipient Connection Agreements are in place and replicating, these X.500 distinguished names are held for each user under an attribute called legacyExchangeDN. Therefore, Exchange 2000 can retrieve the SID for the associated user that has the distinguished name, and stamp it on the public folder object that Exchange 2000 just received. If the Recipient Connection Agreement is not in place, the information store cannot match on the legacyExchangeDN attribute, and generates a 9551 event in the Application Log stating that it couldn't upgrade the ACL. To correct this salutation, after the user object has been replicated, you must remove the user object from the Exchange Server 5.5 public folder, and recreate the user object in Active Directory, allowing the SID to be visible in the Exchange 2000 public folder.
Contact us for more help
Connect with Answer Desk for expert help.