Article ID: 264889
Article Last Modified on 2/21/2007
APPLIES TO
- Microsoft Exchange 2000 Server Standard Edition
This article was previously published under Q264889
SUMMARY
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.
MORE INFORMATION
Ramifications if Public Folder Connection Agreements Are Not In Place
- The Exchange Server 5.5 global address list and Exchange 2000 global address list may not look identical because public folders that are visible in the address book do not appear in the Exchange 2000 global address list.
- Applications cannot send e-mail to public folders if the submitting message goes through Active Directory or an Exchange 2000 server.
- You cannot easily upgrade Exchange Server 5.5 to Exchange 2000.
- There may be situations where public folders on Exchange 2000 are re-homed to Exchange Server 5.5.
Minimum Public Folder Connection Agreements Recommended
It 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:
- For any Exchange Server 5.5 site that contains visible public folders in the address book that also need to be visible in Active Directory and Exchange 2000.
- For any Exchange Server 5.5 site that is currently in a mixed site (both Exchange Server 5.5 and Exchange 2000), or for any site that will soon be mixed.
- For any site that contains an Exchange Server 5.5 computer that will soon be upgraded to Exchange 2000, and you need to replicate it before the upgrade takes place.
- If you are creating mail-enabled public folders in Exchange 2000 and you want them to be visible in Exchange Server 5.5.
- If you are managing public folders from Exchange 2000 in Exchange Server 5.5.
The effects of not meeting the recommended minimum are:
Situation
- Inconvenience.
- Exchange 2000 public folders might be rehomed to Exchange Server 5.5 if an Exchange Server 5.5 administrator runs the DS/IS consistency adjustor.
- Catastrophic. The upgrade will work, but public folders will not be accessible. The only recourse is to restore back to Exchange Server 5.5.
- Inconvenience and a potential of rehoming.
- Inconvenience and a potential of rehoming.
NOTE: Public folder Connection Agreements do not in any way affect the ability to view public folders in the hierarchy from clients such as Microsoft Outlook. They do not prevent public folders from being replicated, nor do they affect ACLs on public folders. All of these things are controlled automatically by the information store.
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.
Keywords: kbinfo KB264889
