Result Classification
OK, so we have quite a few questions and some answers. I expect you may already know what to do with these answers, but just to be sure, let’s take a few minutes to discuss some of the items.
- MAPI. Obviously, MAPI access requires the default Public Folder tree. The default Top Level Hierarchy (TLH) in Exchange 2000 allows MAPI access. Any new TLH cannot be accessed through MAPI. Now we move on to offline use, which is a particularly sore subject with many. Until further notice, MAPI will continue to provide the offline mechanism for Outlook. The Local Web Storage System has been postponed. If you re quire offline access to items in the Public Folder, you will either need to write a custom tool or use the MAPI store.
- WAN Impact. This question is to try to determine what kind of replication may be required in order to locate data close to the users. This question also sets the stage for a more thorough WAN analysis using a protocol analyzer, such as the SMS Network Monitor tools or other third-party applications. Although I did not mention this in the questionnaire, you might want to track server load on the application as well to monitor the web services and Exchange store.
- Custom Sinks. This question will probably land me in some hot water, but I must follow my conscience. Custom event sinks can potentially bring down a server. With Exchange 2000, you are no longer tied to the Event Service for our processing. This is a good thing because it allows you to create new event “services” that are tailored for a specific need. Such is the case for the Workflow sink. This is a bad thing because a poorly written sink or one that performs constant or uncontrollable execution, such as protocol sinks, could “steal” all of the processor time and cripple your server. I am not discouraging application development on Exchange 2000, but you need to consider these things in our testing environments and in the way we support our SLAs.
- Connections to other Databases or Legacy systems. Consider these processes the same as sinks. If you write a custom application to keep your data in-sync with an AS/400 database or phone system, your code could potentially take down the system. Especially if this code executes with a high frequency or is automatically based on changes. Even if the code is good and the frequency is too often, a system overload could result. Again, just consider this when determining the hardware required to support the applications. If you have two separate applications that require high-availability and each runs very frequent questionable sinks, you should consider separate servers. You don’t want one server to take down the other.
- FrontPage Extensions. FrontPage (2000) Extensions are required if you want to use Visual Interdev to build Exchange 2000 applications. There is a new version of the extensions in the works that actually acknowledges the Exchange Web Store, but the current version requires quite a bit of administrative overhead in that it is page (application) -specific and not TLH-specific. I can offer two ideas on this subject:
- Create a specific TLH for Interdev projects and build your applications within this page (application).
- Enable FrontPage extensions on an application-by-application basis and ignore the additional directories and files that are duplicated on the server.
- Persistent Searches. By design, persistent searches violate security. A search under one security context could provide unauthorized access to another person using a different security ID. Moreover, a search down the wrong folder tree could provide unauthorized access or incorrect searches into another application. In instances where persistent searches are required, consider a different TLH for the application.
- Schema. Here is where things get very interesting. One benefit of XML and Web Storage System programming is the ability to share schema definitions, methods, etc., and overall code-sharing ability. First, schemas are TLH-specific. If you create a schema folder on a TLH, applications within that folder structure can leverage the schema. You cannot jump folder hierarchies for schema references. One fine day, I will write an entire article on schema strategies, but for now we will mention that the good thing about sharing is the time saved in using existing code. The bad thing about sharing a schema with several applications is that a change to the schema could adversely affect the other applications. In supporting SLAs, remember that sharing a schema increases the risk to application(s).
|
