- Understanding Your Users' Needs
- User Needs
- Internet Needs
- Security Needs
- Mobile User Needs
- Groupware and Public Folders Needs
- Real-Time Messaging Needs
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Groupware and Public Folders Needs
Most organizations tend to delay discussion of groupware functions and public folder design and deployment until after the basic messaging infrastructure is designed and deployed. This is normally done to limit the project scope and often simply because there is little understanding within most organizations about what truly can be accomplished. In our opinion, delaying planning and building of the basic public folder structure can increase frustrations later.
Aside from general client access issues and security, several other issues related to public folders should be noted and considered:
Administrative security control—In Exchange 5.5, it was possible for an Exchange administrator in one location to make an unauthorized replica of a public folder from a different location in the Exchange organization. In some cases, it was then possible for the remote administrator to take ownership of the folder and its content. Exchange 2000 now offers both folder security and administrative security to prevent this from happening on the administrative side. Furthermore, object-level security can be applied to prevent rogue access to public folder content.
Folder replication—s with Exchange 5.5 and earlier versions, public folders are replicated within the Exchange organization using the normal message-transfer functions that handle user-to-user traffic. Message sizes can be controlled for folder replication. It is wise to plan for the traffic associated with replication.
Event sinks—Exchange 5.5 offered server-side event scripting, and Exchange 2000 offers a much wider array of event-processing options built on standard COM application-development tools. As applications are built on Exchange, event sink functions should be tested carefully because processes can make large performance demands on the system.
Referrals—Exchange 5.5 used a concept called public folder affinity to allow users in one Exchange 5.5 site to access public folders in a different site even when there was no replicated copy of the folder locally. Exchange 2000 replaces the affinity concept with a similar process called referral. The function is essentially the same, but the feature is by default enabled when a Routing Group Connector is established. It is also two-way transitive. In the case of a hub-and-spoke configuration, it would not be desirable to have users in L.A. at the end of one spoke accessing folders in London due to a transitive referral in the hub site in Dallas!
When planning your public folder strategy, with Exchange 2000 it is now important to consider how many public folder trees you want to have and where the content of each will be replicated. An end-user education factor also should be considered because Outlook 2000 MAPI users will see only the default "first" public folder tree, whereas other clients—IMAP, NNTP, and HTTP—will see all available to them.