Sun Java Communications Suite 5 Deployment Planning Guide

Part I Deployment Planning Overview

This part contains the following chapters:

Chapter 1 Introduction to Deploying Communications Suite

This chapter provides an overview of Sun Java Communications Suite 5, the business reasoning behind deploying Communications Suite, and the deployment process itself.

This chapter contains the following sections:

Communications Suite Overview

Sun Java Communications Suite 5 is a secure, cost-effective communications and collaborations offering. Communications Suite addresses customer concerns about costs, capabilities, and the security of the traditional communications infrastructure by offering a secure, scalable, lower total cost of ownership alternative to other communications and collaboration solutions.

Communications Suite provides the email, calendar, and instant messaging solutions necessary to meet both enterprise and ISP communications and collaboration needs. The products and services that form Communications Suite provide a compelling response to common business requirements. All organizations need communications, and many are required to provide these services across large, diverse, and geographically distributed communities of users. Traditional communications solutions are costly, and not sufficient to meet today’s requirements for scalability and security. Communications Suite enables organizations to deploy solutions at a total cost of ownership they can afford.

In addition, Communications Suite provides differentiated services and full-featured collaboration functionality that are required by a diverse audience. Finally, a Communications Suite deployment meets your increased security needs when extending communications outside of a corporate firewall and to mobile users through multiple devices.

The Communications Suite core solution consists of the following component products:

Additional features that enhance the Communications Suite solution include:

Taken as a whole, Communications Suite provides a standards-based, integrated communications and collaboration suite of products for enterprise deployments of many thousands of users, and ISP deployments of hundreds of thousands of users. Communications Suite delivers a robust and flexible platform meeting the diverse communications needs of all types of organizations. Communications Suite is an optimal solution to connect remote offices, distributed workgroups, and global corporate locations.

About Messaging Server

Sun Java System Messaging Server 6.3 is a high-performance, highly secure messaging platform. Scaling from thousands to millions of users, Messaging Server is suitable for businesses interested in consolidating email servers and reducing the total cost of ownership of the communications infrastructure. Messaging Server provides extensive security features that help ensure the integrity of communications through user authentication, session encryption, and the appropriate content filtering to help prevent spam and viruses. Messaging Server also can provide an archive for instant messaging communications. Furthermore, Messaging Server supports archiving through the AXS-One message archiving system to provide an industrial strength message archiving solution for both compliance and operational archiving.

With Messaging Server, organizations can provide secure, reliable messaging services for entire communities of employees, partners, and customers.

Messaging Server currently ships with two native client user interfaces (UI):

Going forward, no new features will be added to the Messenger Express user interface. It has been deprecated in favor of the Communications Express user interface. Sun Microsystems, Inc. will announce an end-of-life timeline for Messenger Express at a future date.

See Part II, Deploying Messaging Server for more information on Messaging Server concepts and other deployment aspects.

About Calendar Server

Sun Java System Calendar Server 6.3 facilitates team collaboration by enabling users to manage and coordinate appointments, events, tasks, and resources. Through an integrated Web interface or connectors to other calendar clients (including Microsoft Outlook), Calendar Server enables end users to access their personal, public, or group calendars anytime from anywhere, from a Web browser. Deployments use Calendar Server, along with the Messaging Server and Instant Messaging, to offer users a comprehensive communications and collaborative environment.

Calendar Server currently ships with two native client user interfaces (UI):

Calendar Express has been deprecated in favor of the new Communications Express user interface. Going forward, no new features will be added to the Calendar Express user interface. Sun Microsystems, Inc. will announce an end-of-life time line for Calendar Express at a future date.

See Part III, Deploying Calendar Server for more information on Calendar Server concepts and other deployment aspects.

About Instant Messaging

Sun Java System Instant Messaging 7.2 enables secure, real-time communication and collaboration. Instant Messaging combines presence awareness with instant messaging capabilities such as chat, conferences, alerts, news, polls, and file transfers to create a rich collaborative environment. These features enable one-to-one as well as group collaboration through either short-lived communications or persistent venues such as conference rooms or news channels. Instant Messaging, along with Calendar Server and Messaging Server, offers users a comprehensive communications and collaboration environment.

Instant Messaging ensures the integrity of communications through its multiple authentication mechanisms and secure SSL connections. Integration with Sun Java System Portal Server and Sun Java System Access Manager brings additional security features, services-based provisioning access policy, user management, and secure remote access. Furthermore, Instant Messaging supports the Extensible Messaging and Presence Protocol (XMPP). XMPP enables you to use a number of third-party clients, gateways, and components. Some of these clients aggregate contacts from the public networks. In one client, you can have contacts from AIM, Yahoo, MSN, Sun and other XMPP-based servers.

See Part IV, Deploying Instant Messaging for more information on Instant Messaging concepts and deployment aspects.

About Communications Express

Sun Java System Communications Express 6.3 provides an integrated web-based communications and collaboration client. Communications Express is a common component between Messaging Server and Calendar Server, providing end users with a web interface to their calendar information and mail, as well as an address book.

See Part V, Deploying Communications Express for more information on Communications Express concepts and deployment aspects.

About Communications Sync

Sun Java System Communications Sync 3.0 (formerly Sun ONE Synchronization) is a software product that runs on a Windows personal computer and enables users to synchronize Communications Suite events, tasks, and contacts with mobile devices and personal information managers (PIMs) such as Microsoft Outlook.

See the Communications Sync documentation at the following location for more information:

http://docs.sun.com/app/docs/coll/1313.2

About Connector for Microsoft Outlook

Sun Java System Connector for Microsoft Outlook 7.2 enables Outlook to be used as a desktop client with Messaging Server and Calendar Server.

Connector for Microsoft Outlook is an Outlook plug-in that you install on end-users' desktops. Connector for Microsoft Outlook queries Messaging Server for folder hierarchies and email messages. Connector for Microsoft Outlook then converts the information into Messaging API (MAPI) properties that Outlook can display. Similarly, Connector for Microsoft Outlook queries Calendar Server for events and tasks, which are then converted into MAPI properties. Finally, Connector for Microsoft Outlook uses Web Address Book Protocol (WABP) to query Address Book Server for contacts, which are then converted into MAPI properties. With this model, Connector for Microsoft Outlook builds an end-user Outlook view from three separate information sources: mail from Messaging Server, calendar information from Calendar Server, and contacts from Address Book Server.

See the Connector for Microsoft Outlook documentation at the following location for more information:

http://docs.sun.com/coll/1312.2

Communications Suite Component Product Dependencies

Communications Suite products depend on other Sun Java System component products that provide infrastructure services. These component products include Sun Java System Directory Server and, optionally, Sun Java System Access Manager. Additionally, Communications Suite products depend on a web container to serve HTML content and provide HTML connections. You can use Sun Java System Web Server (formerly Sun ONE Web Server) or Sun Java Application Server to fulfill this need.

Communications Suite products also depend on the existence of DNS. You need to have a functioning DNS server before you can install the Communications Suite products.

See Chapter 3, Understanding Product Requirements and Considerations for more information on product dependencies.

How Communications Suite Satisfies Business Needs

Organizations want to deploy services that simultaneously reduce cost and complexity while providing a robust set of features. The architecture of services must add requirements for security and scalability that enable users to have more than just a single means of accessing information critical to their daily work. Communications Suite meets these needs through providing scalable messaging, calendaring, and instant messaging at a total cost of ownership businesses can afford.

Communications Suite enables you to develop an architecture that incorporates ease of deployment and maintenance with a complete set of features and functionality. Most important, a Communications Suite architecture builds security into each service element. These elements include the network infrastructure, operating environment, and the Communications Suite component products themselves.

How Messaging Server Satisfies Business Needs

Messaging Server promotes superior reliability and productivity as well as reduced administrative and operational costs. Messaging Server uses committed transactions, which means that messages are not acknowledged as received until they are committed to disk. This reliability feature protects mail messages from loss and corruption. Additionally, the Message Store is built around a custom-designed database that employs a write-once data store and a two-level index to achieve excellent performance and data integrity.

How Calendar Server Satisfies Business Needs

Calendar Server provides one of the industry’s most open, interoperable, and high-performance time and resource management solutions. Calendar Server provides the features you need at a lower total cost of ownership than alternative solutions. Through its flexible and extensible architecture, Calendar Server scales both vertically (by increasing the number of CPUs per system) and horizontally (by adding more servers to the network).

How Instant Messaging Satisfies Business Needs

Instant Messaging software is closely integrated with Java Enterprise System, helping you to shorten the project life cycle and deploy new services affordably. In addition, Instant Messaging works with Portal Server, Access Manager, Messaging Server, and Calendar Server. This integration provides users with a full-featured, secure, scalable communications and collaboration services platform from a single vendor. The well-documented Java APIs included in Instant Messaging provide open standards for ease of integration, as well as multiple platform support, platform extensibility, and customization of real-time communications and collaboration features. These features can thus be embedded in existing applications or become the basis of new applications. Also, XMPP interoperability provides a great advantage to those businesses seeking to extend their ability to practice real-time communication with their partners and customers, many of which might have separate instant messaging systems.

How Communications Express Satisfies Business Needs

Communications Express provides an integrated web-based communication and collaboration client that caters to the needs of Internet service providers, enterprises, and OEMs. Communications Express has an integrated user interface for calendar, mail, and address book and enables the access of one client module from another without re-authenticating user credentials. Communication between mail and calendar is automatically established since both applications are deployed within a single web container. Also, you can optionally use Access Manager to provide the single sign-on mechanism. Both calendar and mail applications share the same address book. All modules share the common user preferences specified in the Options tab of Communications Express.

Summary of Communications Suite Benefits

The Communications Suite components have been traditionally deployed in large-scale, carrier-class deployments. The same dependability required for the large-scale deployments can be used in the enterprise.

The following table summarizes the benefits provided by Communications Suite.

Table 1–1 How Communications Suite Benefits Your Organization

Key Feature  

Benefits  

High performance and scalability 

Enables efficient communications and improves quality of service for both enterprises and ISPs. 

Extensive security features 

Protects the integrity of communications and data and the privacy of employees, customers and partners, and enables compliance with industry regulations. 

Virtual domain hosting and delegated administration

Messaging Server, Calendar Server, and Instant Messaging enable you to host messaging for several companies on one server, or corporate IT to host multiple departments within the organization, reducing number of servers needed, and lowering TCO. 

Scalable, robust and extensible components 

Enables deployment of unified communication services, bringing together telephone services with email notification, faxing, paging, and other technologies. 

Extensible collaboration platform for scheduling events, and for managing tasks and resources 

Calendar Server improves time and resource management, and enhances user productivity. 

Group scheduling for meetings and events 

Calendar Server improves team collaboration and communication across the organization. 

Information sharing through hyperlinks in events or tasks 

Calendar Server facilitates collaboration through exchange of information relevant to tasks or events. 

Multiple client support 

Enables access from a wide variety of clients and devices such as web-based clients, multiple rich clients including Evolution and Microsoft Outlook, and web-enabled devices such as phones and PDAs. 

Open, modular, and standards-based architecture 

Enables customers to deploy customized and personalized solutions. 

Making the Communications Suite Deployment Highly Available

You can configure Messaging Server, Calendar Server, and Instant Messaging to be highly available by using clustering software. Messaging Server supports both Sun Cluster and Veritas Cluster Server software. Calendar Server and Instant Messaging support Sun Cluster software. When using clustering software, a secondary Messaging Server, Calendar Server, or Instant Messaging host provides services to users if the primary system is taken offline for maintenance or is down due to a problem.

Even without the use of Sun Cluster, Messaging Server has built-in monitoring capabilities that continuously check the status of server processes and service availability. Messaging Server can restart processes and services automatically, if necessary. Messaging Server logs failures and recovery operations, which you can use for reporting and analysis.

Instant Messaging may make use of server pools to provide redundancy. In a server pool, two or more Instant Messaging servers provide the instant messaging services for a single domain. If a server fails, another server in the pool handles the additional load.

Additionally, you can deploy the Communications Suite products in a highly available configuration through use of redundant components. This kind of deployment gives services a high level of uptime. A highly available deployment of this sort requires the redundancy of every component in the service architecture. These components include a duplicate data store server, duplicate network interface cards, and duplicate system storage.


Note –

This guide does not discuss the details of using Sun Cluster in highly available deployments for Communications Suite. See the Sun Cluster, Messaging Server, Calendar Server, and Instant Messaging documentation for more information on this topic.


Using Portal Server with Communications Suite

You can install Communications Suite products with Portal Server to provide access to messaging and calendar services (by creating portlets in a portal page). For example, you can create these portlets to provide a summary of messaging information, calendar schedules, and address book information. The integration of Portal Server includes single sign-on capabilities between Portal Server, Calendar Express, Messenger Express, and the Communications Express client.


Note –

You can run Communications Express in both Sun Java System Schema 1 and Schema 2 environments. If you are using Schema 2, then you can use Access Manager authentication and single sign-on for Communications Express.


Portal Server also supports message archiving for Instant Messaging. In addition, the Messenger Express, Calendar Express, and Instant Messenger clients are made available to users through the Portal Server Desktop.

The following two components of Portal Server provide additional functionality to a basic Communications Suite deployment:


Note –

This guide does not discuss deploying Communications Suite in a portal environment. See the Portal Server documentation for more information.


Understanding the Deployment Process

The Communications Suite deployment process consists of the following general phases, referred to as the Solution Life Cycle:

The deployment phases are not rigid; the deployment process is iterative in nature. Nevertheless, the following subsections discuss each of the deployment phases independently.

For detailed information on the deployment process for Communications Suite, and Java Enterprise System components, see the Sun Java Enterprise System Deployment Planning Guide.

Analyzing Business Requirements

In the business analysis phase, you define the business goal of a deployment project and state the business requirements that must be met to achieve that goal. When stating the business requirements, consider any business constraints that might impact the ability to achieve the business goal. The business analysis phase results in business requirements documents that you later use in the Technical Requirements phase. Throughout the life cycle, you measure the success of your deployment planning, and ultimately your deployed system, according to the analysis performed in the business analysis phase.

Analyzing Technical Requirements

In the technical requirements phase, you start with the business requirements and business constraints defined during the business analysis phase and translate them into technical specifications that can be used to design the deployment architecture. The technical specifications measure quality of service features, such as performance, availability, security, and others.

During the technical requirements phase you prepare the following information:

The resulting set of usage analysis, use cases, and system requirements documents are inputs to the logical design phase of the Solution Life Cycle. During technical requirements analysis, you might also specify service level requirements, which are the terms under which customer support must be provided to remedy a deployed system failure to meet system requirements. Service level requirements are the basis for service level agreements signed during project approval.

Designing the Logical Architecture

In the logical design phase, you identify the services required to implement the deployment. Once the services are identified, you map logically distinct components providing those services within a logical architecture that shows the dependencies among the components. The logical architecture, together with the technical requirement specifications from the business analysis phase, characterize a deployment scenario.

The logical architecture does not specify the actual hardware required to implement the deployment scenario. However, it helps you visualize the interrelationship among components, provides a basis for further analysis of use cases and identified usage patterns, and becomes the starting point for the deployment design phase.

Additional work might be necessary, either in extending services through the use of APIs, or in customizing look and feel, for example, introducing a corporate branding.

For some solutions, development and customization might be quite extensive, requiring you to develop new business and presentation services. In other cases, it might be sufficient to customize existing graphical user interfaces, such as the Portal Server desktop, to achieve the functionality required.

For more information on using product APIs and customizing product functionality, see the appropriate component product documentation, including:

Designing the Deployment Architecture

During the design phase, you map the logical components specified in the logical architecture to physical components in a deployment architecture. You also produce design documents that aid in the implementation of the deployment. Successful deployment design results in the following:

Implementing the Deployment

During implementation phase, you work from design documents created during deployment design to build out the deployment architecture and implement the deployment. Depending on the nature of your deployment project, this phase includes some or all of the following steps:

Once a deployment is in production, you need to continue to monitor, test, and tune the deployment to ensure that it fulfills the business goals.

Chapter 2 Analyzing Your Communications Suite Requirements

Planning your Communications Suite deployment requires that you first analyze your organization’s business and technical requirements. This chapter helps you to gather and assess your requirements, which you then use to determine your Communications Suite design.

This chapter contains the following sections:

For detailed information on the deployment process for Communications Suite, and Java Enterprise System components, see the Sun Java Enterprise System Deployment Planning Guide.

Identifying Deployment Goals

Before you purchase or deploy Communications Suite hardware or software, you need to identify your deployment goals. Deployment requirements can come from various sources within an organization. In many cases, requirements are expressed in vague terms, requiring you to clarify them towards determining a specific goal.

The outcome of your requirements analysis should be a clear, succinct, and measurable set of goals by which to gauge the deployment’s success. Proceeding without clear goals that have been accepted by the stake holders of the project is precarious at best.

Some of the requirements you need to examine before you can plan your deployment include:

Defining Business Requirements

Your business objectives affect deployment decisions. Specifically, you need to understand your users’ behavior, your site distribution, and the potential political issues that could affect your deployment. If you do not understand these business requirements, you can easily make wrong assumptions that impact the accuracy of your deployment design.

Operational Requirements

Express operational requirements as a set of functional requirements with straightforward goals. Typically, you might come across informal specifications for:

For example, translate a requirement for “adequate end-user response time” into measurable terms such that all stake holders understand what is “adequate” and how the response time is measured.

Culture and Politics

A deployment needs to take into account your corporate culture and politics. Demands can arise from areas that end up representing a business requirement. For example:

Defining Technical Requirements

Technical requirements (or functional requirements) are the details of your organization’s system needs.

Supporting Existing Usage Patterns

Express existing usage patterns as clearly measurable goals for the deployment to achieve. Here are some questions that will help you determine such goals.

Study the users who will access your services. Factors such as when they will use existing services are keys to identifying your deployment requirements and therefore goals. If your organization’s experience cannot provide these patterns, study the experience of other organizations to estimate your own.

Regions in organizations that have heavy usage might need their own servers. Generally, if your users are far away from the actual servers (with slow links), they will experience slower response times. Consider whether the response times will be acceptable.

Site Distribution

Use these questions to understand how site distribution impacts your deployment goals:

Network Requirements

Here are some questions to help you understand your network requirements:


Note –

Answering yes to these questions suggests a two-tiered architecture.


Existing Infrastructure

You might be able to centralize servers if you have more reliable and higher available bandwidth.

Support Personnel

24-hour, seven-day-a-week (24 x 7) support might only be available at certain sites. A simpler architecture with fewer servers will be easier to support.

Defining Financial Requirements

Financial restrictions impact how you construct your deployment. Financial requirements tend to be clearly defined from an overall perspective providing a limit or target of the deployment.

Beyond the obvious hardware, software, and maintenance costs, a number of other costs can impact the overall project cost, including:

You can avoid financial issues associated with the project by applying sufficient attention and analysis to the many factors associated with the project requirements.

Defining Service Level Agreements (SLAs)

You should develop SLAs for your deployment around such areas as uptime, response time, message delivery time, and disaster recovery. An SLA itself should account for such items as an overview of the system, the roles and responsibilities of support organizations, response times, how to measure service levels, change requests, and so forth.

Identifying your organization’s expectations around system availability is key in determining the scope of your SLAs. System availability is often expressed as a percentage of the system uptime. A basic equation to calculate system availability is:

Availability = uptime / (uptime + downtime) * 100

For instance, a service level agreement uptime of four nines (99.99 percent) means that in a month the system can be unavailable for about four minutes.

Furthermore, system downtime is the total time the system is not available for use. This total includes not only unplanned downtime, such as hardware failures and network outages, but also planned downtime, preventive maintenance, software upgrade, patches, and so on. If the system is supposed to be available 7x24 (seven days a week, 24 hours a day), the architecture needs to include redundancy to avoid planned and unplanned downtime to ensure high availability.

Determining Project Goals

Your investigation and analysis should reveal your project’s requirements. Next, you should be able to determine a clearly measurable set of goals. Specify these goals in such a manner that personnel not directly associated with the project can understand the goals and how to measure the project against them.

Stake holders need to accept the project goals. The project goals need to be measured in a post-implementation review to determine the success of the project.

Planning for Growth

In addition to determining what capacity you need today, assess what capacity you need in the future, within a time frame that you can plan for. Typically, a growth time line is in the range of 12 to 18 months. Growth expectations and changes in usage characteristics are factors that you need to take into account to accommodate growth.

As the number of users and messages increase, you should outline successful guidelines for capacity planning. You need to plan for increases in message traffic for the various servers, a larger volume of users, larger mailbox sizes, more calendar appointments, and so forth. As growth occurs in the user population, usage characteristics change over time. Your deployment goals (and therefore deployment design) must respond accordingly to be viable into the future.

Ideally, you should design your architecture to easily accommodate future growth. For example, use logical names for the Communications Suite services themselves. See Using Logical Service Names for more information. Monitoring the deployment, once it enters its production phase, is also crucial to being able to understand when and by how much a deployment needs to grow.

Understanding Total Cost of Ownership

Total Cost of Ownership (TCO) is another factor that affects capacity planning. This includes choosing the hardware upon which to deploy your Communications Suite. The following table presents some factors to consider as to whether to deploy more smaller hardware systems or fewer larger hardware systems.

Table 2–1 Considerations for Total Cost of Ownership

Hardware Choice  

Pros  

Cons  

More, smaller hardware systems 

  • Smaller hardware systems generally cost less.

  • More, smaller hardware systems can be deployed across many locations to support a distributed business environment.

  • More, smaller hardware systems can mean less down time for system maintenance, upgrade, and migration because traffic can be routed to other servers that are still online while others are being maintained.

  • Smaller hardware systems have a more limited capacity, so more of them are needed. Management, administration, and maintenance costs go up as the number of hardware systems goes up.

  • More, smaller hardware systems require more system maintenance because there are more of them to maintain.

Fewer, larger hardware systems 

  • Fewer hardware systems means fewer fixed management costs per server. If your management costs are a recurring monthly bill, whether internal or from an ISP, costs will be lower, because you have fewer hardware systems to manage.

  • Fewer hardware systems can also mean easier system maintenance, upgrade, and migration because there are fewer systems to maintain.

  • Larger hardware systems generally cost more initially.

  • Fewer hardware systems can mean a greater system down-time for maintenance, upgrade and migration.

Chapter 3 Understanding Product Requirements and Considerations

This chapter describes requirements and considerations that impact the design of your deployment. You need to understand these requirements and considerations to accurately determine your Communications Suite architecture.

This chapter contains the following sections:

Planning for Various Components

When designing your Communications Suite deployment architecture, take into account the requirements of the various component products of your deployment. For example, if you have a technical requirement to integrate Communications Suite with other Java System products, you need to choose your schema accordingly. Inter-product dependencies, for example, how Communications Suite accesses and places load on Directory Server, present deployment choices as well.

Understanding the individual components of each product enables you to plan for the type of architecture to best suit your requirements. Depending on your deployment, you need to potentially understand and plan for the following components:

Understanding Service Components and Service Tiers

When planning a Communications Suite deployment for multiple component products or services, you need to understand the composition of each component product (or service) itself.

Figure 3–1 illustrates how you can separate each service into components that can be deployed on separate hosts, and the particular tier each component occupies. Though you can deploy all components on a single host, or deploy a particular service’s components on the same host, consider moving to a tiered architecture. A tiered architecture, whether it be single-tiered, or two-tiered, provides a number of benefits. See Benefits of a Single-tiered Architecture and Benefits of a Two-tiered Architecture for more information.

Figure 3–1 Communications Suite Components

This diagram shows the various Communications Suite client,
access, and data components.

In the preceding figure, the client components consist of the Outlook Connector plugin, thick clients such as Evolution, browsers, and standard email applications. These components reside on end users’ client computers. The access layer components consist of front-end services from Messaging Server (MMP and MTA); Calendar Server; Communications Express and Webmail Server; Instant Messaging (Instant Messaging Proxy); Portal Server (SRA and Core); Access Manager for authentication; and a corporate directory, which provides address book lookup. The data layer components consist of back-end services from Directory Server (which, in itself, can consist of front-end and back-end components); Messaging Server (Message Store); Calendar Server (Calendar Store); and Instant Messaging. A Storage Area Network (SAN) “cloud” represents the physical data storage.


Note –

The corporate directory shown in this figure is not a component product in itself. It represents a “copy” of the corporate directory that enterprises typically deploy in the access layer for clients to perform address-book type lookups.


The following sections explain these various components in more detail.

LDAP Directory Information Tree Requirements

The Directory Information Tree (DIT) is a way to organize directory entries in a tree structure, or schema, with nodes representing domains, subdomains, users, and groups. Sun Java Enterprise System introduces a fundamental change to how the directory is structured by implementing a one-tree structure.

Changes in the DIT Structure

Messaging Server and Calendar Server have introduced a one-tree structure, where there is no Domain Component (DC) Tree. All domain information is held in domain nodes in the Organization Tree. Aliasing is handled entirely differently in the new one-DIT structure.

The bottom half of Figure 3–2 illustrates a one-tree LDAP structure.

Figure 3–2 Two-Tree LDAP Structure Compared With One-Tree Structure

This diagram compares the one-tree LDAP structure, introduced
by Messaging Server 6.0, with the previous two-tree structure.

Benefits of a One-Tree DIT Structure

The main advantages to using the one-tree structure Schema 2 native mode are:

As illustrated in the following figure, in the two-tree structure, some nodes point directly to a node in the Organization Tree (using the attribute inetDomainBaseDN). Other nodes are aliased nodes, which instead of pointing directly to an Organization Tree node, point to another DC Tree node, using the aliasedObjectName attribute.

Figure 3–3 Two-Tree Aliasing With aliasedDomainName and inetDomainBaseDN

This diagram shows the two-tree LDAP with an aliasedObjectName
set up.

In the previous figure, sesta.com in the DC Tree points to siroe.com in the DC Tree using aliasedObjectName, and siroe.com points to the like named node in the Organization Tree, using inetDomainBaseDN.

Furthermore, as shown in Figure 3–4, there could be one or more nodes in the DC Tree using inetDomainBaseDN to point directly to the same node in the Organization Tree. In this case, a “tie-breaker” attribute, inetCanonicalDomainName, is necessary on one of the DC Tree nodes to designate which is the “real” domain name (the domain where the mail actually resides and where the mail is routed).

Figure 3–4 Two-Tree Aliasing With inetCanonicalDomainName

This diagram shows the two-tree LDAP with two DC Tree
nodes pointing to the same Organization Tree node, using inetCanonicalDomainName.

By contrast, a one-tree structure contains only an Organization Tree, as shown in the following figure.

Figure 3–5 One-Tree Aliasing With associatedDomain

This diagram demonstrates the simplified way aliases
are handled in Sun ONE Schema, v.2.

In the one-tree structure, domain nodes in the Organization Tree contain all the domain attributes formerly found on the DC Tree. Each domain node is identified by the sunManagedOrganization object class and sunPreferredDomain attribute, which contains the DNS domain name. A domain node can also have one or more associatedDomain attributes, which list the alias names this domain is known by. Contrary to the two-tree structure, there are no duplicate nodes for the alias names.

A one-tree DIT structure is beneficial in how you partition data for organization-specific access control. That is, each organization can have a separate subtree in the DIT where user and group entries are located. Access to that data can be limited to users in that part of the subtree. This allows localized applications to operate securely.

In addition, for new deployments of Calendar Server or Messaging Server, a one-tree structure maps better to existing single-DIT LDAP applications.

Schema Requirements

Before you install any of the Communications Suite products, you need to understand which schema you will use. The schema is the set of definitions describing what types of information can be stored as entries in the directory. Two schema choices, Sun Java System LDAP Schema 1 and Sun Java System LDAP Schema 2, are available and supported with Communications Suite. Your choice of schema depends on the following criteria:

Use Schema 2 if you:


Note –

You do not have to use Access Manager 6 to provide SSO. If you choose, you can still use the trusted circle type of SSO, which does not rely on Access Manager 6.


Use Schema 1 if you:

See Chapter 8, Understanding Schema and Provisioning Options for more information on schema choices.

Directory Server Considerations

Sun Java System Directory Server provides flexible, multi-tiered data storage for intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. You can extend Directory Server to manage user profiles and preferences, as well as extranet user authentication.

All custom LDAP schemas, such as those from Portal Server, Access Manager, Messaging Server, Calendar Server, and Instant Messaging, install into a single Directory.

There are many ways to architect your data environment and many factors to consider that depend on your business objective and expected usage patterns. Your directory design should address the following areas:

See the Directory Server documentation for a complete description of these factors and suggestions about how to architect your data environment:

http://docs.sun.com/coll/1316.1

Directory Server and Tiered Architecture Considerations

In moving from a single-tiered architecture to a multiple-tiered architecture, Directory Server should be the first component that you “split out” onto its own machine. At a certain point of load, Directory Server and Messaging Server on the same host have inherent performance impacts. This is due to the way Messaging Server is architected to work with Directory Server. Separating Directory Server onto its own machine is the first step to improve performance for a deployment.

See Chapter 5, Developing a Communications Suite Logical Architecture for more information on tiered architectures.


Note –

You can install Directory Server in such a way to have a clear separation between the directory user management and the software application configuration. Should you want to remove the software application configuration piece, this separation provides a cleaner way of removing that information from Directory Server.


Directory Server Topology Considerations

Though it is feasible to build a deployment around an instance of Directory Server installed on a single machine, the other Communications Suite components depend upon the directory as a core service to function. Thus, beyond trivial deployments, you should plan to deploy Directory Server in a redundant or highly availability configuration.

The first step toward making Directory Server more available is to establish a pair of master directory servers. Next, multimaster replication can be used to improve the LDAP write throughput and availability. If Sun Cluster is used for a high-availability deployment, then the two LDAP masters are clustered together. See Directory Server and High Availability for more information.

Directory Server Capacity Planning

While there are no hard and fast rules for Directory Server capacity planning, actively monitoring the directory is essential to ensure that performance metrics are met. When the system is not meeting these metrics, then it is time to add an additional directory consumer. Typically, you will want to monitor:

Evaluate the above metrics against a target response time of 10 Milliseconds. The IOWAIT should not exceed 10 Milliseconds, and the sum of the CPU utilization in this tier should not exceed 70 percent.

Directory Server and Calendar Server Interaction Considerations

Calendar Server performs multiple writes to user entries stored in Directory Server. The bulk of these writes occur when the user logs into Calendar Server for the first time and when the user performs certain actions. These actions include creating a calendar, subscribing to a calendar, changing a preference, and so on. If you do not take these actions into consideration, the Directory Master Server can experience heavy loads.

If you use Directory replication, the LDAP Master Server is replicating entries to the LDAP Replica servers. As Calendar users perform one of these actions, Calendar Server will only be able to write changes to the Master Directory Server. This is because the Replicas are read-only.

A second interaction consideration exists in these replicated Directory structures. As users make preference changes, their changes might not be rendered successful until the change is successfully replicated from the Master Directory Server to the Directory Replica, which is in use by the Calendar Server. A workaround is available, in which you configure Calendar Express (cshttpd) attempts to cache the change locally to avoid this latency delay. See Planning for the Calendar Server LDAP Data Cache for more information.

Directory Server and Personal Address Book Considerations

The Messenger Express Client supports the concept of a Personal Address Book (PAB). This enables users to store personal contacts (for example, business contacts, friends, and family) in the Directory Server. Each time a new personal contact is added to the user’s PAB, a write is made on the Directory Server. If you do not take these actions into consideration, the LDAP Master Server can face heavy loads (regardless of the Directory replication strategy).

One method to avoid performance issues on the User and Group Directory Server is to place the PAB information on a separate Directory Server. This enables PAB interactions to avoid placing a load on the LDAP Master Server.


Note –

If you are running both the current Communications Express client and also the deprecated Messenger Express Web mail interface, the address books used by these two clients do not share information. If end users switch between the two client interfaces, the two address books will contain different entries.


Messaging Server Considerations

In developing your Communications Suite architecture, you need to evaluate the performance aspects of the following Messaging Server components:

For a complete discussion of the performance aspects of these components, and potential hardware solutions, see Performance Considerations for a Messaging Server Architecture.

Calendar Server Considerations

Calendar Server consists of five major services:

In a scalable Calendar Server deployment, you would deploy front-end systems in conjunction with a back-end server. The front-end systems would contain one instance of the cshttpd daemon per processor and a single Administration Service. A back-end server would contain an instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service.

Authentication and XML / XSLT transformation are two Calendar Service activities that generate heavy load. Additional CPUs can be added to meet quality of service requirements. In a scalable environment, these heavy load activities take place on the front-end system(s), permitting more CPUs to be added to individual front-end systems, or more front-end systems to be added, to meet quality of service requirements.


Note –

The preceding paragraph is not applicable if the Communications Express Calendar client is used for calendar access. Communications Express uses the WCAP protocol to access Calendar Server data and therefore the Calendar Server infrastructure is not doing the XML/XSLT translations. See Part V, Deploying Communications Express deploying Communications Express.


Calendar back-end services usually require half the number of CPUs sized for the Calendar front-end services. To support quality of service by the Calendar front-end system, the Calendar back-end system should use around two-thirds of the front-end CPUs.

Consider early on in your deployment planning to separate the Calendar Service into front-end and back-end services.

The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. Thus, account for peak calendar usage and choose sufficient front-end processing power to accommodate the expected peak HTTP sessions. Typically, you would make the Calendar Server front end more available through redundancy, that is, by deploying multiple front-end hosts. As the front-end systems do not maintain any persistent calendar data, they are not good candidates for HA solutions like Sun Cluster or Veritas. Moreover, the additional hardware and administrative overhead of such solutions make deploying HA for Calendar Server front ends both expensive and time-consuming.


Note –

The only configuration for Calendar front ends that might warrant a true HA solution is where you have deployed the Calendar front end on the same host that contains a Messaging Server MTA router. Even in this configuration, however, the overhead of such a solution should be carefully weighed against the slight benefit.


A good choice of hardware for the Calendar Server front ends is a single or dual processor server. You would deploy one instance of the Calendar Server cshttpd process per processor. Such a deployment affords a cost-effective solution, enabling you to start with some level of initial client concurrency capability and add client session capacity as you discover peak usage levels on your existing configuration.

When you deploy multiple front ends, a load balancer (with sticky/persistent connections) is necessary to distribute the load across the front-end services.


Note –

Communications Express does not scale beyond two processors. The same hardware choices explained previously for Calendar Server apply to Communications Express deployments.


The Calendar Server back-end services are well balanced in resource consumption and show no evidence of bottleneck formation either in CPU or I/O (disk or network). Thus, a good choice of hardware for the back end would be a SPARC server with a single striped volume. Such a machine presents considerable capacity for large-peak calendar loads.

If your requirements include high availability, it makes sense to deploy the Calendar Server back end with Sun Cluster, as the back end does contain persistent data.


Note –

In a configuration with both front-end and back-end Calendar Server hosts, all hosts must be running:


Instant Messaging Considerations

As with other Communications Suite components, you can create an architecture in which you separate Instant Messaging into front-end (Instant Messaging multiplexor) and back-end components (server and store). See Developing Instant Messaging Architectural Strategies for more information.

Portal Server Considerations

You can install Communications Suite products with Portal Server to provide an “umbrella” front end to access messaging, calendar, and instant messaging applications. The integration of Portal Server includes single sign-on capabilities between Portal Server, Calendar Express web client, Messaging Express web client and Communications Express client. In addition, the Messaging Express, Calendar Express, and Instant Messaging clients are made available to users through the Portal Server desktop.

See the Sun Java System Portal Server 7.1 Deployment Planning Guide and the Sun Java System Access Manager 7.1 Deployment Planning Guide for more information.

Connector for Microsoft Outlook Considerations

This section describes some deployment issues you will encounter deploying Connector for Microsoft Outlook. For complete information, see the Connector for Microsoft Outlook documentation:

http://docs.sun.com/app/docs/coll/1312.2

Sun Java System Connector for Microsoft Outlook enables Outlook to be used as a desktop client with Sun Java Enterprise System. Connector for Microsoft Outlook is an Outlook plug-in that must be installed on the end-user's desktop. Connector for Microsoft Outlook queries Messaging Server for folder hierarchies and email messages. It converts the information into Messaging API (MAPI) properties that Outlook can display. Similarly, it uses the WCAP protocol to query Calendar Server for events and tasks which are then converted into MAPI properties. With this model, Connector for Microsoft Outlook builds an end-user Outlook view from two separate information sources: mail from Messaging Server and calendar information from Calendar Server.

When users create and modify items through Outlook, Connector for Microsoft Outlook passes the new message along to the appropriate server depending on its message type. It sends new outgoing email to an SMTP mail server for delivery, and sends modified email messages back to the user's IMAP folder for storage. New calendar events and tasks are converted into a standard format to be stored in the Calendar Server database.

Connector for Microsoft Outlook Component Product Dependencies

To use Connector for Microsoft Outlook, both Messaging Server and Calendar Server are required in the same deployment. See those products' release notes for information on supported versions.

For Connector for Microsoft Outlook to function correctly, the following LDAP attributes in the Sun Java System Directory Server should be indexed for at least presence and equality to improve the overall performance:

See Chapter 7, Sun Java System Connector for Microsoft Outlook 7.2 Release Notes, in Sun Java Communications Suite 5 Release Notes for a complete list of product dependencies.

Migrating Sun ONE Calendar Server Data

If you are using a version of Calendar Server prior to Sun ONE Calendar Server 6.0, you need to engage Sun Client Services to convert and migrate the data to the new format. This Calendar Server data migration is required for the use of Outlook, and is necessary because of the underlying changes in the storage and management of recurring events. No migration service is required for new customers of Sun Java System Calendar Server.

Migrating Exchange Server Data

Connector for Microsoft Outlook does not convert Microsoft Exchange Server messages on the Exchange Server. You need to engage with Sun Client Services to convert the data.

Communications Express Considerations

Sun Java System Communications Express provides an integrated web-based communications and collaboration client. Communications Express is a common part of Messaging Server and Calendar Server, providing end users with a web interface to their calendar information and mail, as well as an address book.

Communications Express consists of three client modules: Calendar, Address Book, and Mail. The Calendar and Address Book client modules are deployed as a single application on a web container. Messenger Express is the standalone web-based mail application that uses the HTTP service of the Messaging Server. Messenger Express should be deployed on the same system as Communications Express.

Communications Express depends upon the following Sun Java System component products:

S/MIME Considerations

Communications Express Mail includes the security advantages of the Secure/Multipurpose Internet Mail Extension (S/MIME). Communications Express Mail users who are set up to use S/MIME can exchange signed or encrypted messages with other Communications Express Mail users, and with users of the Microsoft Outlook mail system.

See Requirements for Using S/MIME with Communications Express Mail in Sun Java Communications Suite 5 Installation Guide for more information.

Chapter 4 Determining Your Network Infrastructure Needs

Your network infrastructure is the underlying foundation of the system. It forms the services that create the operating makeup of your network. In a Communications Suite deployment, determining your network infrastructure from the project goals ensures that you will have an architecture that can scale and grow.

This chapter contains the following sections:

Understanding Your Existing Network

You need to understand your existing network infrastructure to determine how well it can meet the needs of your deployment goals. By examining your existing infrastructure, you identify if you need to upgrade existing network components or purchase new network components. You should build up a complete map of the existing network by covering these areas:

  1. Physical communication links, such as cable length, grade, and so forth

  2. Communication links, such as analog, ISDN, VPN, T3, and so forth, and available bandwidth and latency between sites

  3. Server information, including:

    • Host names

    • IP addresses

    • Domain Name System (DNS) server for domain membership

  4. Locations of devices on your network, including:

    • Hubs

    • Switches

    • Modems

    • Routers and bridges

    • Proxy servers

  5. Number of users at each site, including mobile users

After completing this inventory, you need to review that information in conjunction with your project goals to determine what changes are required so that you can successfully deliver the deployment.

Understanding Network Infrastructure Components

The following common network infrastructure components have a direct impact upon the success of your deployment:

Routers and Switches

Routers connect networks of your infrastructure, enabling systems to communicate. You need to ensure that the routers have spare capacity after the deployment to cope with projected growth and usage.

In a similar vein, switches connect systems within a network.

Routers or switches running at capacity tend to induce escalating bottlenecks, which result in significantly longer times for clients to submit messages to servers on different networks. In such cases, the lack of foresight or expenditure to upgrade the router or switch could have a personnel productivity impact far greater than the cost.

Firewall Access Control

Firewalls sit between a router and application servers to provide access control. Firewalls were originally used to protect a trusted network (yours) from the untrusted network (the Internet). These days, it is becoming more common to protect application servers on their own (trusted, isolated) network from the untrusted networks (your network and the Internet).

Router configurations add to the collective firewall capability by screening the data presented to the firewall. Router configurations can potentially block undesired services (such as NFS, NIS, and so forth) and use packet-level filtering to block traffic from untrusted hosts or networks.

In addition, when installing a Sun server in an environment that is exposed to the Internet, or any untrusted network, reduce the Solaris software installation to the minimum number of packages necessary to support the applications to be hosted. Achieving minimization in services, libraries, and applications helps increase security by reducing the number of subsystems that must be maintained. The Solaris Security Toolkit provides a flexible and extensible mechanism to minimize, harden, and secure Solaris systems.

Your Site Security Policy should provide direction on such issues.

Load Balancers

Use load balancers to distribute overall load on your Web or application servers, or to distribute demand according to the kind of task to be performed. If, for example, you have a variety of dedicated applications and hence different application servers, you might use load balancers according to the kind of application the user requests.

If you have multiple data centers, you should consider geographic load balancing. Geographic load balancing distributes load according to demand, site capacity, and closest location to the user. If one center should go down, the geographic load balancer provides failover ability.

For load balancers on Web farms, place the hardware load balancers in front of the servers and behind routers because they direct routed traffic to appropriate servers. Software load balancing solutions reside on the Web servers themselves. With software solutions, one of the servers typically acts a traffic scheduler.

A load balancing solution is able to read headers and contents of incoming packets. This enables you to balance load by the kind of information within the packet, including the user and the type of request. A load balancing solution that reads packet headers enables you to identify privileged users and to direct requests to servers handling specific tasks.

You need to investigate how dynamically the load balancer communicates with all the servers it caters to. Does the scheduler ping each server or create “live” agents that reside on the servers to ascertain load data? You should also examine how the load balancer parses TCP packets. Pay attention to how quickly the load balancer can process a packet. Some load balancers will be more efficient than others. Load balancer efficiency is typically measured in throughput.

Storage Area Networks (SANs)

Understanding the data requirements of the storage system is necessary for a successful deployment. Increasingly, SANs are being deployed so that the storage is independent of the servers used in conjunction with it. Deploying SANs can represent a decrease in the time to recover from a non-functional server as the machine can be replaced without having to relocate the storage drives.

Use these questions to evaluate if your deployment storage requirements would be best served through a SAN:

Domain Name System (DNS)

Servers which make heavy usage of DNS queries should be equipped with a local caching DNS server to reduce lookup latency as well as network traffic.

When determining your requirements, consider allocating host names for functions such as mailstore, mail-relay-in, mail-relay-out, and so forth. You should consider this policy even if the host names all are currently hosted on one machine. With services configured in such a way, relocation of the services to alternate hardware significantly reduces the impacts of the change.

Planning Your Network Infrastructure Layout

In deriving your infrastructure topology, you need to consider the following topics:

Demilitarized Zone (DMZ)

These days, most company networks are configured for a DMZ. The DMZ separates the corporate network from the Internet. The DMZ is a tightly secured area into which you place servers providing Internet services and facilities (for example, web servers). These machines are hardened to withstand the attacks they might face. To limit exposure in case of a security breach from such attacks, these servers typically contain no information about the internal network. For example, the nameserver facilities only include the server and the routers to the Internet.

Progressively, DMZ implementations have moved the segment behind the firewall as firewall security and facilities have increased in robustness. However, the DMZ still remains segmented from the internal networks. You should continue to locate all machines hosting Web servers, FTP servers, mail servers, and external DNS on a DMZ segment.

A simpler network design might only define separate DMZ segments for Internet services, VPN access, and remote access. However, security issues exist with VPN and remote access traffic. You need to separate appropriate connections of these types from the rest of the network.

The firewall providing the DMZ segmentation should allow only inbound packets destined to the corresponding service ports and hosts offering the services within the DMZ. Also, limit outbound initiated traffic to the Internet to those machines requiring access to the Internet to carry out the service they are providing (for example, DNS and mail). You might want to segment an inbound-only DMZ and an outbound-only DMZ, with respect to the type of connection requests. However, given the potential of a denial-of-service attack interrupting DNS or email, consider creating separate inbound and outbound servers to provide these services. Should an email-based Trojan horse or worm get out of control and overrun your outbound mail server, inbound email can still be received. Apply the same approach to DNS servers.

Intranet

The DMZ provides a network segment for hosts that offer services to the Internet. This design protects your internal hosts, as they do not reside on the same segment as hosts that could be compromised by an external attack. Internally, you also have similar services to offer (Web, mail, file serving, internal DNS, and so on) that are meant solely for internal users. Just as the Internet services are segmented, so too, are the internal services. Separation of services in this manner also permits tighter controls to be placed on the router filtering.

Just as you separate the Internet-facing services into the DMZ for security, your private internal services should reside in their own internal DMZ. In addition, just as multiple DMZs can be beneficial—depending on your services and your network’s size—multiple intranets might also be helpful.

The firewall rules providing the segmentation should be configured similarly to the rules used for the DMZ’s firewall. Inbound traffic should come solely from machines relaying information from the DMZ (such as inbound email being passed to internal mail servers) and machines residing on the internal network.

Internal Network

The segments that remain make up your internal network segments. These segments house users’ machines or departmental workstations. These machines request information from hosts residing on the intranet. Development, lab, and test network segments are also included in this list. Use a firewall between each internal network segment to filter traffic to provide additional security between departments. Identify the type of internal network traffic and services used on each of these segments to determine if an internal firewall would be beneficial.

Machines on internal networks should not communicate directly with machines on the Internet. Preferably, these machines avoid direct communication with machines in the DMZ. Ultimately, the services they require should reside on hosts in the intranet. A host on the intranet can in turn communicate with a host in the DMZ to complete a service (such as outbound email or DNS). This indirect communication is acceptable.

Proxy Hosts

Only the machines directly communicating with machines on the Internet should reside in the DMZ. If users require Internet access, though, this creates a problem based on your previous topology decisions. In this situation, proxies become helpful. Place a proxy on an internal network segment, or, better yet, an intranet segment. A machine requiring access to the Internet can pass its request onto the proxy, which in turn makes the request on the machine’s behalf. This relay out to the Internet helps shield the machine from any potential danger it might encounter.

Because the proxy communicates directly with machines on the Internet, it should reside in the DMZ. However, this conflicts with the desire to prevent internal machines from directly communicating with DMZ machines. To keep this communication indirect, use a double proxy system. A second proxy residing in the intranet passes connection requests of the internal machines to the proxy in the DMZ, which in turn makes the actual connection out on the Internet.

Firewall Configuration

In addition to the typical packet-filtering features, most firewalls provide features to prevent IP spoofing. Use IP-spoofing protection whenever possible.

For instance, if there is only one entry point into your network from the Internet and a packet is received from the Internet with a source address of one of your internal machines, it was likely spoofed. Based on your network’s topology, the only packets containing a source IP address from your internal machines should come from within the network itself, not from the Internet. By preventing IP spoofing, this possibility is eliminated, and the potential for bypassing IP address-based authorization and the other firewall-filtering rules is reduced. Use the same IP-spoofing protection on any internal firewall as well.

Mobile Users

When you have remote or mobile users, pay attention to how you will provide them access to the facilities. Will there be any facilities they cannot access? What kind of security policies do you need to address? Will you require SSL for authentication? Also, examine whether your mobile user population is stable or is expected to increase over time.

Chapter 5 Developing a Communications Suite Logical Architecture

This chapter describes how to develop your Communications Suite logical architecture. The logical architecture is a design that depicts the logical building blocks of the Communications Suite components and the infrastructure services needed to support them.

This chapter contains the following sections:

Communications Suite Deployment Logical Architectures Overview

You can deploy Communications Suite in either a single-tiered or two-tiered logical architecture. Deciding on your logical architecture is crucial, as it determines which machine types you will need, as well as how many.

In general, enterprise corporate deployments use a single-tiered architecture while internet service providers (ISPs) and telecommunications deployments use a two-tiered architecture. However, as with all generalities, the exceptions prove the rule. Small ISPs might just as well deploy on a single machine, and larger, centralized enterprises might deploy in a two-tiered architecture for many of the same reasons that ISPs do. As more and more corporations look to offer ease of access to employees working remotely, their deployments will begin to look more and more like an ISP.

This section discuss the following Communications Suite logical architectures:

Whether you deploy Communications Suite in a single-tiered or multiple-tiered architecture, you need to understand the advantages and disadvantages of both models.

Single-tiered Logical Architecture for One Host

As its name implies, the single-tiered logical architecture for one host locates all services onto a single machine. In general, such an architecture is best suited for enterprises that are:

The following figure represents the single-tiered logical architecture for one host.

Figure 5–1 Single-tiered Architecture for One Host

This diagram shows the single-tiered logical architecture
for one host.

End-user client programs, such as Outlook and Messenger Express, form the User Tier. Tier 1 is a single machine running all services, including messaging, calendar, instant messaging, and directory. If you deploy Communications Express, the single machine is also running Web Server (or Application Server). The distinction of the single tier deployment is that end users communicate directly to the stores, and not through proxies or other agents.

The single-tiered logical architecture for one host requires a machine that provides sufficient CPU, memory, and storage. You should work with your Sun representative to determine the machine that best meets your organization’s needs for this type of deployment.

When implementing the single-tiered logical architecture for one host, you can position the deployment for growth into a multi-tiered architecture by assigning logical names to services. Such a configuration makes use of DNS mapping to direct users to the same front-end process (machine). If, in the future, you need to make changes to accommodate growth, such as splitting out services in a tiered fashion, users do not need to reconfigure their client applications. See Using Logical Service Names for more information.

Single-tiered Logical Architecture for Multiple Hosts

The single-tiered logical architecture for multiple hosts is a set of servers that each run the services particular to a component product. For example, the Messaging Server host is installed and configured to run all the Messaging Server services, the Calendar Server host is installed and configured to run all the Calendar Server services, and so on. This architecture might also be configured for high availability.

The distinction of the single-tiered logical architecture is that end users communicate directly to the data stores, and not through proxies or other agents. For example, in Messaging Server, users would not be routed through MMPs or MTAs. The single-tiered logical architecture might have standalone MTA routers for routing mail between servers, or in and out of the corporate network, but end users submit mail to the MTA on their message stores. No MMPs are involved in intranet connection to the message stores.

The same idea applies to both Calendar Server and Instant Messaging. In the single-tiered logical architecture, no front-end processes are located on separate machines.

Figure 5–2 represents the single-tiered logical architecture for multiple hosts.

Figure 5–2 Single-tiered Architecture for Multiple Hosts

This diagram shows the single-tiered architecture for
multiple hosts.

In the preceding figure, end-user client programs, such as Outlook and Messenger Express, form the User Tier. Tier 1 is a set of four servers. One server runs the Calendar Server processes, the second runs the Messaging Server processes, the third runs the Instant Messaging processes, and the fourth runs the Directory Server process. If you are deploying Communications Express, the Messaging Server host also includes a web server, either Web Server or Application Server, (for Webmail).

Single-tiered Distributed Logical Architecture

The single-tiered distributed logical architecture is a variant of the single-tiered architecture in that the Directory Server is deployed in two tiers. Such a deployment works well for enterprises with small departments or organizations that are geographically distributed. Each department or office has its own services (mail, calendar, instant messaging) and a local directory instance (consumer). All the local directory instances are cached, but are synchronized with the centralized, master corporate repository. This is a fairly common scenario for offices with low bandwidth connectivity. The directory is architected in a two-tiered fashion and replicated over the low-bandwidth to keep data local.

Figure 5–3 represents the single-tiered distributed logical architecture.

Figure 5–3 Single-tiered Distributed Architecture

This diagram shows the single-tiered distributed logical
architecture.

In the preceding figure, end-user client programs, such as Outlook and Messenger Express, form the User Tier. Tier 0 consists of load balancers that distribute load across the Tier 1 layer. Tier 1 is a set of multiple servers for the Communications Suite processes. Multiple servers run the Calendar Server processes, multiple servers run the Messaging Server processes, and multiple servers run the Instant Messaging processes. Directory Server processes are split between a consumer server in Tier 1 running a local, replicated copy of the directory, and another server situated in Tier 2, which contains the master copy of the directory. Notice that in this kind of deployment, client queries are directed to the local directory copy, not to the master copy. Only the local Directory Server communicates to the master Directory Server.


Note –

When deploying a single-tiered architecture with Internet connectivity, use a separate access layer. For example, you direct access to the data stores from inside the intranet without having to use SSL. However, you direct access to the data stores from the Internet through an access layer over SSL. This offloads much of the SSL load on the data stores to the access layer that separates it from the Internet.

The downside to this type of deployment is that users who make use of the server from a system that is sometimes on the corporate intranet and sometimes accessing the server from the Internet must configure their client applications to use SSL all the time. This is because it is too much trouble to switch back and forth. Therefore, there will still be a substantial percentage of SSL traffic being put on the stores directly. By using an access layer inside the intranet, you can remove that problem and by limiting connection directions further protect the intranet from illegal access.


Two-tiered Logical Architecture

In a two-tiered logical architecture, the data stores communicate through front-end processes. In the case of Messaging Server, this means MMPs and MTAs are residing on separate machines from the data store processes. A two-tiered architecture enables the mail store to offload important and common tasks and focus on receiving and delivering mail. In the case of Calendar Server, this means the HTTP service and Administration service reside on a separate machine from the store processes. In the case of Instant Messaging, this means the proxy service is residing on a separate machine from the back-end processes.

There might be some level of cohabitation with other services. For example, you could have the Calendar store and the Message Store on the same machine. Similarly, you could have the calendar front end on the MMP machine.

In a two-tiered logical architecture, Directory Server is usually a complex deployment in its own right, with multi-master and replication to a set of load-balanced consumer directories.

Figure 5–4 represents the two-tiered logical architecture.

Figure 5–4 Two-tiered Architecture

This diagram shows the two-tiered logical architecture.

In the preceding figure, end-user client programs, such as Outlook and Messenger Express, form the User Tier. The load balancers form Tier 0. The Calendar Server, Messaging Server, Instant Messaging, and web proxy front ends form Tier 1. Finally, the Directory Server, Calendar Server, Messaging Server, and Instant Messaging back ends form Tier 2. When deploying Communications Express, you could have Web Server in Tier 2 as well.

A two-tiered architecture enables you to deploy Tier 1 and Tier 2 elements as separate instances, increasing overall flexibility of design. Additionally, you enhance system security by assigning discrete functions to individual instances.

For typical deployments, place the messaging and calendar front ends within the network Demilitarized Zone (DMZ), connecting to the main messaging and calendar services through a firewall. This configuration enables you to scale the system horizontally, as the Tier 1 elements can be scaled independently. Do not scale these elements beyond the capacity of the back-end servers.

When the front-end elements have reached the capacity of the back-end servers, you can scale the back-end Tier 2 elements to support more users. In general, the front end should scale as a function of the traffic. The back end should be scaled as a function of the number of users.


Note –

For specific instructions on sizing components in single-tiered or two-tiered architectures, contact your Client Services representative.


Edge Logical Architecture

The edge logical architecture adds security for remote access to the two-tiered logical architecture. An edge deployment grants access to a remote, mobile workforce over the public Internet by using only name/password authentication (SMTPAuth). As messages travel to and from the corporate network over the public Internet, they are encrypted through the use of SSL. No virtual private network is involved. The internal side of the communications transmission is “in the clear” for maximum performance. Access is contained on the “edge” of the deployment, protecting the data stores from unauthorized intrusion.

Business reasons for an edge deployment include:

Figure 5–5 represents the edge logical architecture.

Figure 5–5 Edge Architecture

This diagram shows the edge logical architecture.

In the preceding figure, the data stores are located in Tier 2, which is a secure, private network, connected only to the “edge” and “internal” front-end servers. Remote clients connect to front-end servers by using SSL. Internal clients do not need to use SSL to connect, as the assumption is made that internal access is inherently secure.

Edge Architecture Design Recommendations

Benefits of a Single-tiered Architecture

The benefits of the single-tiered architecture come down to cost savings, as you do not have to purchase nor maintain additional hardware.

Answer the following questions to help decide if the single-tiered architecture is best for your enterprise:

Answering yes to these questions suggests that your enterprise could use a single-tiered architecture.

Benefits of a Two-tiered Architecture

All services within the Communications Suite offering rely on network capabilities. A two-tiered architecture provides for a network design with two separate networks: the public (user-facing) network, and the private (data center) network.

Separating your network into two tiers provides the following benefits:

Horizontal Scalability Strategy

Scalability is critical to organizations needing to make the most cost-effective use of their computing resources, handle peak workloads, and grow their infrastructure as rapidly as their business grows. Keep these points in mind:

When deployed in a two-tiered architecture, the Communications Suite offering is meant to scale very effectively in a horizontal manner. Each functional element can support increased load by adding additional machines to a given tier.

Scaling Front-end and Back-end Services

In practice, the method for scaling the front-end and back-end services differs slightly.

For Tier 1 elements, you start the scaling process when traffic to the front end grows beyond current capacity. You add relatively low cost machines to the tier and load balance across these machines. Thus, load balancers can precede each of the Tier 1 service functions as overall system load, service distribution, and scalability requirements dictate.

For Tier 2 elements, you start the scaling process when the back-end services have exceeded user or data capacity. As a general rule, design the Tier 2 services to accommodate just under double the load capacity of the Tier 1 services.

For example, for an architecture designed for 5,000 users, the Tier 1 front-end services are designed to support 5,000 users. The back-end services are then doubled, and designed to accommodate 10,000 users. If the system capacity exceeds 5,000 users, the front-end services can be horizontally scaled. If the overall capacity reaches 5,000 users, then the back-end services can be scaled to accommodate. Such design enables flexibility for growth, whether the growth is in terms of users or throughput.

Other Deployment Issues

This section describes some common Communications Suite deployment best practices and other deployment considerations.

Implementing Local Message Transfer Protocol (LMTP) for Messaging Server

Best practices say you should implement LMTP to replace SMTP for message insertion. An LMTP architecture is more efficient for delivering to the back-end Message Store because it:

You need a two-tiered architecture to implement LMTP. See To Configure LMTP Delivery in Sun Java System Messaging Server 6.3 Administration Guide for instructions on configuring LMTP.


Note –

By design, LMTP is intended for use in multi-tier deployments. It is not possible to use LMTP with single-system deployments. Also, the Messaging Server's LMTP service as implemented is not designed to work with other LMTP servers or other LMTP clients.


Implementing Realtime Blackhole List (RBL)

The Mail Abuse Protection System’s Realtime Blackhole List (MAPS RBL) is a dynamically updated list of known unsolicited bulk email (UBE) sources identified by source IP address. The Messaging Server SMTP server supports use of the RBL and can reject mail coming from sources identified by the RBL as originators of UBE or spam.

Implementing an RBL should be a consideration of every deployment. In general, a good RBL deployed in front of MTAs reduces traffic to the MTAs by a minimum of 10 percent, and in some cases, much higher.

RBLs, and anti-spam and anti-virus servers, such as BrightMail, can work together. For example, if your anti-spam server rejects 95 to 99 out of 100 emails from a particular IP address, you can add that IP address to the RBL. You can also adjust the RBL for BrightMail’s false positives when you conduct your BrightMail analysis. Thus, you make the RBL much more proactive in handling a specific wave of UBE.

See Sun Java System Messaging Server 6.3 Administration Reference for information on configuring the ENABLE_RBL option of the MTA Dispatcher.

Using Logical Service Names

Design your deployment around the use of logical names for Communications Suite servers. You should use logical names even on a single-system deployment, to position it for ease of future growth and expansion. Using logical names does not impose any additional deployment setup costs other than populating your DNS.

You can think of these logical names as falling into two categories: those that affect end users, such as settings in email client programs; and those affecting back-end administration, such as inbound SMTP servers.

The following tables describes these logical entities.

Table 5–1 User Facing Logical Names

Example  

Description  

mail.siroe.com

Name of the server from which end users collect their email. 

imap.siroe.com

Name of the IMAP server from which end users collect their email.

pop.siroe.com

Name of the POP server from which the end users collect their email.

smtp.siroe.com

Name of the SMTP server users set as outgoing mail server. 

webcal.siroe.com or ce.siroe.com

Name of the Communications Express (formerly Calendar Express) server. 

Table 5–2 Maintenance Level Logical Names

Example  

Description  

relay-in.siroe.com

Corresponds to a bank of inbound SMTP servers. 

relay-out.siroe.com

Corresponds to a bank of outbound SMTP servers. 

mmp.siroe.com

Corresponds to a bank of MMP servers. 

storeAA.siroe.com

Back-end message store. Select a naming scheme to work with your topology, for example, storeAA.siroe.com through storeZZ.siroe.com.

calstoreAA.siroe.com

Back-end calendar store. Select naming scheme to work with topology, for example, calstoreAA.siroe.com through calstoreZZ.siroe.com.

Table 5–3 Mapping of User Level to Maintenance Level Logical Names

Maintenance Level  

User Level  

relay-in.siroe.com

N/A 

relay-out.siroe.com

smtp.siroe.com

mmp.siroe.com

Any one or more of mmp.siroe.com, pop.siroe.com, and imap.siroe.com

storeAA.siroe.com - storeZZ.siroe.com

N/A, hidden from end users 

calstore_aa.siroe.com - calstore_az.siroe.com

N/A, hidden from end users 

Chapter 6 Designing for Service Availability

Once you have decided on your logical architecture, the next step is deciding what level of service availability is right for your site. The level of service availability you can expect is related to hardware chosen as well as the software infrastructure and maintenance practices you use. This chapter discusses several choices, their value, and their costs.

This chapter contains the following sections:

High Availability Solutions Overview

High availability solutions for Communications Suite vary from product to product.

For example, Messaging Server supports two different high availability solutions, Sun Cluster and Veritas Cluster Server (VCS). Messaging Server provides agents for each of these solutions.

Messaging Server and Calendar Server support different cluster topologies. Refer to the appropriate cluster product documentation for more information.

If you choose to use Application Server as a web container, you can take advantage of its high availability, load balancing, and cluster management capabilities.

Instant Messaging also provides a Sun Cluster agent, but it does not support VCS. You can also create a “more available” deployment by deploying redundant Instant Messaging multiplexors. In such a deployment, if one multiplexor fails, Instant Messaging clients are able to communicate to the back-end server through another available multiplexor.

In addition, you can build in availability to your Communications Suite deployment by making infrastructure components, such as Directory Server, highly available.

The following sections in this chapter explain the options available for each component.

Automatic System Reconfiguration (ASR)

In addition to evaluating a purely highly available (HA) solution, you should consider deploying hardware that is capable of ASR.

ASR is a process by which hardware failure related downtime can be minimized. If a server is capable of ASR, it is possible that individual component failures in the hardware result in only minimal downtime. ASR enables the server to reboot itself and configure the failed components out of operation until they can be replaced. The downside is that a failed component that is taken out of service could result in a less performing system. For example, a CPU failure could result in a machine rebooting with fewer CPUs available. A system I/O board or chip failure could result in system with diminished or alternative I/O paths in use.

Different Sun SPARC systems support very different levels of ASR. Some systems support no ASR, while others support very high levels. As a general rule, the more ASR capabilities a server has, the more it costs. In the absence of high availability software, choose machines with a significant amount of hardware redundancy and ASR capability for your data stores, assuming that it is not cost prohibitive.

Directory Server and High Availability

From the Communications Suite standpoint, the most important factor in planning your directory service is availability. As an infrastructure service, the directory must provide as near-continuous service as possible to the higher-level applications for authorization, access, email routing, and so forth.

A key feature of Directory Server that provides for high availability is replication. Replication is the mechanism that automatically copies directory data from one Directory Server to another. Replication enables you to provide a highly available directory service, and to geographically distribute your data. In practical terms, replication brings the following benefits:

The following table shows how you can design your directory for availability.

Table 6–1 Designing Directory Server for High Availability

Method  

Description  

Single-master replication 

A server acting as a supplier copies a master replica directly to one or more consumer servers. In this configuration, all directory modifications are made to the master replica stored on the supplier, and the consumers contain read-only copies of the data. 

Two-way, multi-master replication 

In a multi-master environment between two suppliers that share responsibility for the same data, you create two replication agreements. Supplier A and Supplier B each hold a master replica of the same data and there are two replication agreements governing the replication flow of this multi-master configuration. 

Four-way multi-master 

Provides a pair of Directory Server masters, usually in two separate data centers. This configuration uses four-way MultiMaster Replication (MMR) for replication. Thanks to its four-way master failover configuration, this fully-connected topology provides a highly-available solution that guarantees data integrity. When used with hubs in the replication topology, load distribution is facilitated, and the four consumers in each data center allow this topology to scale for read (lookup) operations. 

Sun Cluster Agent for Directory Server

Using Sun Cluster software provides the highest level of availability for your directory implementation. In the case of failure of an active Directory Server node, Sun Cluster provides for transparent failover of services to a backup node. However, the administrative (and hardware) costs of installing, configuring, and maintaining a cluster are typically higher than the Directory Server replication methods. 

See the Directory Server documentation for more information:

http://docs.sun.com/coll/1316.2

Application Server and High Availability

Because Communications Express is deployed in a web container (either Web Server or Application Server), consider making the web container highly available.

For example, Application Server Enterprise Edition enhances the core application server platform with high availability, load balancing and cluster management capabilities. The management capabilities of the Platform Edition are extended in Enterprise Edition to account for multi-instance and multi-machine deployments.

Application Server’s clustering support includes easy-to-configure groups of cloned application server instances to which client requests can be load balanced. Both external load balancers and load balancing web tier-based proxies are supported by this edition. Application Server EE provides failover for HTTP sessions and stateful session beans using the highly available database (HADB).

See the Application Server Enterprise Edition 8.2 documentation for more information:

http://docs.sun.com/app/docs/coll/1310.3

Messaging Server and Calendar Server and High Availability

You can configure Messaging Server and Calendar Server to be highly available by using clustering software. Messaging Server supports both Sun Cluster and Veritas Cluster Server software. Calendar Server supports Sun Cluster software.

In a tiered Communications Suite architecture, where front-end and back-end components are distributed onto separate machines, you would want to make the back-end components highly available through cluster technology as the back ends are the “stores” maintaining persistent data. Cluster technology is not typically warranted on the Messaging Server or Calendar Server front ends as they do not hold persistent data. Typically, you would want to make the Messaging Server MTA and MMP, Webmail Server, and Calendar Server front ends highly available through redundancy, that is, by deploying multiple front-end hosts. You could also add high availability to the MTA by protecting its disk subsystems through RAID technology.

See Chapter 2, Key Concepts for Hardware Service Providers, in Sun Cluster Concepts Guide for Solaris OS for more information on Sun Cluster topologies.

See Chapter 3, Configuring High Availability, in Sun Java System Messaging Server 6.3 Administration Guide for more information on configuring Messaging Server for high availability.

See Chapter 6, Configuring Calendar Server 6.3 Software for High Availability (Failover Service), in Sun Java System Calendar Server 6.3 Administration Guide for more information on configuring Calendar Server for high availability.

Instant Messaging and High Availability

Instant Messaging provides a Sun Cluster agent, but it does not support Veritas Cluster Service. You can also create a “more available” environment by deploying redundant Instant Messaging multiplexors, and by taking advantage of the Instant Messaging watchdog process.

Instant Messaging High Availability Overview

Configuring Instant Messaging for high availability (HA) by using the Sun Cluster agent provides for monitoring of and recovery from software and hardware failures. The high availability feature is implemented as a failover data service, not a scalable service, and is currently supported only on Solaris.


Note –

You can have multiple Instant Messaging nodes in an HA environment using the same SMTP server.


Before implementing an Instant Messaging HA environment using the Sun Cluster agent, decide which of the following HA deployments best meets your needs.

Using Multiple Instant Messaging Multiplexors

In an Instant Messaging deployment of multiple multiplexors, if one multiplexor fails, Instant Messaging clients are able to communicate to the back-end server through another available multiplexor. Currently, you can only configure multiple multiplexors to speak to a single instance of Instant Messaging server. You cannot configure multiple multiplexors to talk to multiple instances of Instant Messaging.

Using the Instant Messaging Watchdog Process

Instant Messaging includes a watchdog process, which monitors the Sun Cluster agent, and restarts the services that become unavailable for some reason (such as server lockup, crash, and so forth). In the event that you configure the watchdog process, and an Instant Messaging component stops functioning, the watchdog process shuts down then restarts the component.

Using Enabling Techniques and Technologies

In addition to the high availability solutions discussed in the previous section, you can use enabling techniques and technologies to improve both availability and performance. These techniques and technologies include load balancers, Sun Java System Directory Proxy Server, and replica role promotion.

Using Load Balancers

You can use load balancers to ensure the functional availability of each tier in your architecture, providing high availability of the entire end-to-end system. Load balancers can be either a dedicated hardware appliance or a strictly software solution.

Load balancing is the best way to avoid a single application instance, server, or network as a single point of failure while at the same time improving the performance of the service. One of the primary goals of load balancing is to increase horizontal capacity of a service. For example, with a directory service, load balancers increase the aggregate number of simultaneous LDAP connections and LDAP operations per second that the directory service can handle.

Using Directory Proxy Server

Sun Java System Directory Proxy Server (formerly Sun ONE Directory Proxy Server) provides many proxy type features. One of these features is LDAP load balancing. Though Directory Proxy Server might not perform as well as dedicated load balancers, consider using it for failover, referral following, security, and mapping features.

See the Directory Proxy Server documentation for more information:

http://docs.sun.com/coll/1317.3

Using Replica Role Promotion

Directory Server includes a way of promoting and demoting the replica role of a directory instance. This feature enables you to promote a replica hub to a multi-master supplier or vice versa. You can also promote a consumer to the role of replica hub and vice versa. However, you cannot promote a consumer directly to a multi-master supplier or vice versa. In this case, the consumer must first become a replica hub and then it can be promoted from a hub to a multi-master replica. The same is true in the reverse direction.

Replica role promotion is useful in distributed deployments. Consider the case when you have six geographically dispersed sites. You would like to have a multi-master supplier at each site but are limited to only one per site for up to four sites. If you put at least one hub at each of the other two sites, you could promote them if one of the other multi-master suppliers is taken offline or decommissioned for some reason.

See the Directory Server documentation for more information:

http://docs.sun.com/app/docs/coll/1310.3

Locating High Availability Product Reference Information

For more information on high availability models, see the following product documentation:

Sun Cluster

Veritas Cluster Server: Veritas Cluster Server User’s Guide: http://seer.support.veritas.com/docs/275725.htm

Understanding Remote Site Failover

Remote site failover is the ability to bring up a service at a site that is WAN connected to the primary site in the event of a catastrophic failure to the primary site. There are several forms of remote site failover and they come at different costs.

For all cases of remote site failover, you need additional servers and storage capable of running all or part of the users’ load for the service installed and configured at the remote site. By all or part, this means that some customers might have priority users and non-priority users. Such a situation exists for both ISPs and enterprises. ISPs might have premium subscribers, who pay more for this feature. Enterprises might have divisions that provide email to all of their employees but deem this level of support too expensive for some portion of those users. For example, an enterprise might choose to have remote site failover for mail for those users that are directly involved in customer support but not provide remote site failover for people who work the manufacturing line. Thus, the remote hardware must be capable of handling the load of the users that are allowed to access remote failover mail servers.

While restricting the usage to only a portion of the user base reduces the amount of redundant server and storage hardware needed, it also complicates configuration and management of fail back. Such a policy can also have other unexpected impacts on users in the long term. For instance, if a domain mail router is unavailable for 48 hours, the other MTA routers on the Internet will hold the mail destined for that domain. At some point, the mail will be delivered when the server comes back online. Further, if you do not configure all users in a failover remote site, then the MTA will be up and give permanent failures (bounces) for the users not configured. Lastly, if you configure mail for all users to be accepted, then you have to fail back all users or set up the MTA router to hold mail for the nonfunctional accounts while the failover is active and stream it back out once a failback has occurred.

Potential remote site failover solutions include:

There are a variety of costs to these solutions, from hardware and software, to administrative, power, heat, and networking costs. These are all fairly straightforward to account for and calculate. Nevertheless, it is difficult to account for some costs: the cost of mistakes when putting a rarely practiced set of procedures in place, the inherent cost of downtime, the cost of data loss, and so forth. There are no fixed answers to these types of costs. For some customers, downtime and data loss are extremely expensive or totally unacceptable. For others, it is probably no more than an annoyance.

In doing remote site failover, you also need to ensure that the remote directory is at least as up to date as the messaging data you are planning to recover. If you are using a restore method for the remote site, the directory restore needs to be completed before beginning the message restore. Also, it is imperative that when users are removed from the system that they are only tagged as disabled in the directory. Do not remove users from the directory for at least as long as the messaging backup tapes that will be used might contain those users’ data.

Questions for Remote Site Failover

Use the following questions to assist you in planning for remote site failover:


Note –

Do not use both Sun Cluster for local HA and Veritas software for remote site failover. Sun Cluster does not support remote site failover at this time.

Also, do not allow the software to automatically failover from the primary site to the backup site. The possibility for false positive detection of failure of the primary site from the secondary site is too high. Instead, configure the software to monitor the primary site and alert you when it detects a failure. Then, confirm that the failure has happened before beginning the automated process of failing over to the backup site.


Chapter 7 Designing for Security

This chapter provides an overview of security methods, describes common security threats, and outlines the steps in analyzing your security needs.

This chapter contains the following sections:

For detailed product security information, see Chapter 13, Planning Messaging Server Security, Chapter 17, Planning Calendar Server Security, and Chapter 22, Planning Instant Messaging Security.

Communications Suite Security Overview

You manage security for a Communications Suite deployment by taking a “defense in depth” approach. By individually securing the network, hardware platform, operating system, and applications themselves, you make each layer of the architecture secure. Security includes hardening each layer by closing unnecessary network ports and access mechanisms. You also minimize the number of installed software packages so that only those packages required by the system are available. Finally, you secure and insulate the layers from unintended access within the network.

You can implement a Messaging Server proxy server to augment data security. A proxy server placed on the firewall with the Messaging Server behind it prevents attacks on the information on the Messaging Server.

Calendar Server provides a number of security levels to protect users against eavesdropping, unsanctioned usage, or external attack. The basic level of security is through authentication. Calendar Server uses LDAP authentication by default, but also supports the use of an authentication plugin for cases where an alternate means of authentication is desired. Integration with Access Manager enables Calendar Server to take advantage of its single sign-on capability.

Instant Messaging ensures the integrity of communications through its multiple authentication mechanisms and secure SSL connections. Integration with Portal Server and Access Manager bring additional security features, services-based provisioning access policy, user management, and secure remote access.


Note –

To ensure a completely secure environment, the deployment needs a time server to synchronize the internal clocks of the hosts being secured.


Creating a Security Strategy

Creating a security strategy is one of the most important steps in planning your deployment. Your strategy should meet your organization’s security needs and provide a secure messaging environment without being overbearing to your users.

In addition, your security strategy needs to be simple enough to administer. A complex security strategy can lead to mistakes that prevent users from accessing their mail, or it can allow users and unauthorized intruders to modify or retrieve information that you don’t want them to access.

The five steps to developing a security strategy, as listed in RFC 2196, the Site Security Handbook, include:

  1. Identifying what you are trying to protect.

    For example, your list might include hardware, software, data, people, documentation, network infrastructure, or your organization’s reputation.

  2. Determining what you are trying to protect it from.

    For example: unauthorized users, spammers, or denial of service attacks.

  3. Estimating how likely threats are to your system.

    If you are a large service provider, your chances of security threats could be greater than a small organization. In addition, the nature of your organization could provoke security threats.

  4. Implementing measures that will protect your assets in a cost-effective manner.

    For example, the extra overhead in setting up an SSL connection can put a performance burden on your Messaging deployment. In designing your security strategy, you need to balance security needs against server capacity.

  5. Continuously reviewing your strategy and make improvements each time a weakness is found.

    Conduct regular audits to verify the efficiency of your overall security policy. You can do this by examining log files and information recorded by the SNMP agents. For more information on SNMP, refer to the Sun Java System Messaging Server 6.3 Administration Guide.

Your security strategy should also plan for:

Physical Security

Limit physical access to important parts of your infrastructure. For example, place physical limits on routers, servers, wiring closets, server rooms, or data centers to prevent theft, tampering, or other misuse. Network and server security become a moot point if any unauthorized person can walk into your server room an unplug your routers.

Server Security

Limiting access to important operating system accounts and data is also part of any security strategy. Protection is achieved through the authentication and access control mechanisms available in the operating system.

In addition, you should install the most recent operating environment security patches and set up procedures to update the patches once every few months and in response to security alerts from the vendor.

Operating System Security

Reduce potential risk of security breaches in the operating environment by performing the following, often termed “system hardening:”

Network Security

The recommended deployment configuration, to support both horizontal scalability and service security, is to place the access layer of the architecture behind a firewall. In a two-tiered architecture, use two firewalls, creating a DMZ. This enables access to the information delivery elements, the calendar and messaging front ends, while protecting the main service elements on the internal network behind a second firewall. Such a configuration also enables the access layer and data layer elements to be scaled independently, accommodating traffic and storage elements.

Limiting access to your network is an important part of your security strategy. Normally, overall access to networks is limited through the use of firewalls. However, email must be made available outside your site. SMTP is one such service.

To secure your network, you should:

Messaging Security

Messaging Server offers the following sets of security features:

See Chapter 13, Planning Messaging Server Security for more information.

Application Security

The Communications Suite product portfolio provides features that ensure the security and integrity of business communications. Communications Suite offers extensive “built-in” security features, such as:

Implementing Secure Connections

Communications Suite supports security standards such as SSL/TLS, S/MIME, and SAML. SSL/TLS enables all communication between clients and servers to take place inside an encrypted session. Through integration with Portal Server, additional authentication mechanisms are available out-of-the-box, as well as single sign-on capabilities across the applications.


Note –

There is no SSL support between the Communications Express application in the web server and the Calendar Server cshttpd daemon.


If you want to implement public key data security, you must select mail clients that support public key infrastructure and key choice. Communications Suite products are capable, out of the box, of participating in the transmission and storage of messages so encrypted. Secure/Multipurpose Internet Mail Extension (S/MIME) is available on the Communications Express Mail client. Communications Express Mail users who are set up to use S/MIME can exchange signed or encrypted messages with other users of Communications Express Mail, Microsoft Outlook Express, and Mozilla mail systems.


Note –

The Webmail client from previous versions of Messaging Server is not capable of generating or decoding encrypted messages.


A more commonly used mechanism for data security protects the data across the wire only (that is, from client to server) by using SSL encryption on the connections used to transmit data between various messaging agents. This solution is not as complete as public key encryption, but is far easier to implement and is supported by many more products and service providers.

What problem does using SSL from client to server solve? An organization assumes that it controls its own corporate network and that data transmitted on that network is safe from non-employees. Mail sent to anyone from outside the corporate network using the corporation’s infrastructure transmits the data over an encrypted connection to the corporation’s network. Likewise, all mail picked up by a corporate user from outside the corporate network will be transmitted over an encrypted connection. Thus, if the enterprise’s assumption about the safety of the internal network is true, and its employees use only sanctioned servers for transmission between themselves and other employees, mail between employees is safe from external attack.

What problem doesn’t this solution solve? First of all, this approach does not protect the data from unintended viewing by non-intended recipients of the data who have access to the organization’s internal network. Secondly, there is no protection offered for data being transmitted between employees and their external partners, customers, or suppliers. The data travels across the public Internet in a completely insecure fashion.

However, this problem can be remedied by configuring SSL encryption between MTA routers at both the enterprise’s and customer’s network. This type of solution requires setup for each private connection you want to use. In so doing, you add an important additional layer of security with customer or partner data being sent or received via email. Using MTAs and SSL, companies can save money by using the public Internet as the transport, but force the MTAs to use SSL for their partners. This solution does not take into account other network traffic to and from partners. Nevertheless, mail is usually a large proportion of the traffic, and because companies can pay based on data transmitted, using the public Internet is usually cheaper.

Implementing Secure Connections Using Two Different Certificate Authorities (CAs)

You can implement SSL connections between server and clients, for example, from Messaging Server, and to other servers in your deployment as well (Web Server, Calendar Server, Directory Server). If desired, you can use two different Certificate Authorities (CAs), one for the server and one for the client.

In such a scenario, you can use one CA to issue server certificates, and another CA to issue client certificates. If you want the client to accept the server’s certificate as genuine, you will need to load the CA certificate for the server into the client’s certificate DB. If you want the server to accept the client as genuine, you will need to load the CA certificate for the client into the server’s certificate DB.

Understanding Security Misconceptions

This section describes common misconceptions that are counterproductive to the security needs of your deployment.

Other Security Resources

For more information on designing a secure Communications Suite deployment, review the Computer Emergency Response Team (CERT) Coordination Center site:

http://www.cert.org

Chapter 8 Understanding Schema and Provisioning Options

This chapter describes the schema and provisioning options for Communications Suite. Because of the complexity in provisioning Communications Suite products, you need to understand your options before installing the product.

This chapter contains the following sections:

Understanding Schema Choices

This section describes the schema options that are available and supported with Communications Suite, and how to decide which to use.

Understanding Messaging Server Schema Choices

Two schema options are available and supported with Messaging Server: Sun Java System LDAP Schema version 1 and Sun Java System LDAP Schema version 2.


Note –

See the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for information on how to migrate from Sun Java System LDAP Schema version 1 to Sun Java System LDAP Schema version 2.


Deciding Which Schema to Use for Messaging Server

Choosing the schema that’s right for your Messaging Server installation depends on your provisioning needs:

LDAP Schema 1 and Messaging Server

LDAP Schema 1 is a provisioning schema that consists of both an Organization Tree and a DC Tree. This set of schema (at the time, it was simply called “schema”) was supported in previous Messaging Server 5.x versions.

In Schema 1, when Messaging Server searches for user or group entries, it looks at the user's or group’s domain node in the DC Tree and extracts the value of the inetDomainBaseDN attribute. This attribute holds a DN reference to the organization subtree containing the actual user or group entry.

Only sites that have installed previous versions of Messaging Server should use Schema 1.


Note –

Migrating to Schema 2 is imperative if you plan to install Messaging Server with other Sun Java System products in the future.


LDAP Schema 1 and Messaging Server Supported Provisioning Tools

Schema 1 supports Sun ONE Delegated Administrator for Messaging (formerly called iPlanet Delegated Administrator) as well as LDAP provisioning tools. For more information, see Understanding Provisioning Tools.

LDAP Schema 2 (Native Mode) and Messaging Server

LDAP Schema 2 is a set of provisioning definitions that describes the types of information that can be stored as entries by using the Directory Server LDAP.

The native mode uses search templates to search the LDAP directory server. Once the domain is found by using the domain search template, the user or group search templates are used to find a specific user or group.

You should use native mode if you are installing Communications Suite for the first time and you do not have other applications on your machine that are dependent on a two-tree provisioning model. You should also use this mode if you want to install other products in the Java Enterprise System product suite.

If you have an existing Communications Suite 5.x installation that uses Schema 1, and you want to integrate Communications Suite with other Java Enterprise Server products, you should migrate your directory to Schema 2 after you upgrade to Communications Suite 6. Refer to the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for information on how to migrate from LDAP Schema version 1 to LDAP Schema version 2.


Note –

Schema 2 Native Mode is the recommended provisioning model for all Sun Java System products in the Java Enterprise System product suite.


LDAP Schema 2 and Messaging Server Supported Provisioning Tools

Schema 2 supports Sun Java System Delegated Administrator. For more information, see Understanding Provisioning Tools.

LDAP Schema 2 Compatibility Mode and Messaging Server

Schema 2 compatibility mode is an interim mode between Schema 1 and Schema 2 native mode. Schema 2 compatibility mode supports both schemas and enables you to retain the existing two-tree design you already have. Schema 2 compatibility mode also assumes that you have installed Access Manager prior to installing Messaging Server.

Use Schema 2 Compatibility if you have existing applications that require Schema 1, but you also need functionality that requires Schema 2, for example, Access Manager, single sign-on, and so forth.


Note –

Schema 2 compatibility mode is provided as a convenience in migrating to the Schema 2 Native mode. Do not use Schema 2 compatibility mode as your final schema choice. The migration process from Schema 1 to Schema 2 compatibility mode and then finally to Schema 2 native mode is more complex that simply migrating from Schema 1 to Schema 2 native mode. See the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for more information.


Understanding Calendar Server Schema Choices

Two schema options are available and supported with Calendar Server: Sun Java System LDAP Schema version 1 and Sun Java System LDAP Schema version 2.


Note –

Refer to the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for information on how to migrate from Sun Java System LDAP Schema version 1 to Sun Java System LDAP Schema version 2.


Deciding Which Schema to Use for Calendar Server

Choosing the schema that’s right for your Calendar Server installation depends on your provisioning needs:

LDAP Schema 1 and Calendar Server

LDAP Schema 1 is a provisioning schema that consists of both an Organization Tree and a DC Tree. This set of schema (at the time, it was simply called “schema”) was supported in previous Calendar Server 5.x versions.

When Calendar Server searches for user or group entries, it looks at the user's or group’s domain node in the DC Tree and extracts the value of the inetDomainBaseDN attribute. This attribute holds a DN reference to the organization subtree containing the actual user or group entry.

Only sites that have installed previous versions of Calendar Server should use Schema 1.


Note –

Migrating to Schema 2 is imperative if you plan to install Calendar Server with other Sun Java System products in the future.


LDAP Schema 1 and Calendar Server Supported Provisioning Tools

Schema 1 supports LDAP provisioning tools. For more information, see Understanding Provisioning Tools.

LDAP Schema 2 (Native Mode) and Calendar Server

Schema 2 is a set of provisioning definitions that describes the types of information that can be stored as entries by using the Directory Server LDAP.

The native mode uses search templates to search the LDAP directory server. Once the domain is found by using the domain search template, the user or group search templates are used to find a specific user or group.

You should use native mode if you are installing Communications Suite for the first time and you do not have other applications on your machine that are dependent on a two-tree provisioning model. You should also use this mode if you want to install other products in the Java Enterprise System product suite.

If you have an existing Communications Suite 5.x installation that uses Schema 1, and you want to integrate Communications Suite with other Java Enterprise Server products, you should migrate your directory to Schema 2 after you upgrade to Communications Suite 6. Refer to the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for information on how to migrate from LDAP Schema version 1 to LDAP Schema version 2.


Note –

Schema 2 Native Mode is the recommended provisioning model for all Sun Java System products in the Java Enterprise System product suite.


LDAP Schema 2 and Calendar Server Supported Provisioning Tools

Schema 2 supports Sun Java System Delegated Administrator. For more information, see Understanding Provisioning Tools.

LDAP Schema 2 Compatibility Mode and Calendar Server

Schema 2 compatibility mode is an interim mode between Schema 1 and Schema 2 native mode. Schema 2 compatibility mode supports both schemas and enables you to retain the existing two-tree design you already have. Schema 2 compatibility mode also assumes that you have installed Access Manager prior to installing Messaging Server.

Use Schema 2 Compatibility if you have existing applications that require Schema 1, but you also need functionality that requires Schema 2, for example, Access Manager, single sign-on, and so forth.


Note –

Schema 2 compatibility mode is provided as a convenience in migrating to the Schema 2 Native mode. Do not use Schema 2 compatibility mode as your final schema choice. The migration process from Schema 1 to Schema 2 compatibility mode and then finally to Schema 2 native mode is more complex that simply migrating from Schema 1 to Schema 2 native mode. See the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for more information.


Understanding Provisioning Tools

This section describes supported provisioning tools that enable you to query, modify, add, or delete user, group, and domain entry information in your LDAP directory.

Understanding Messaging Server Provisioning Tools

Through supported Messaging Server provisioning tools, you can query, modify, add, or delete user, group, and domain entry information in your LDAP directory. This section examines these Messaging Server provisioning tools.

In addition to the questions asked in Deciding Which Schema to Use for Messaging Server, you should use Table 8–1 to evaluate your schema and provisioning tool options.


Note –

Prior to installing and configuring Messaging Server, you need to decide upon a schema model and tool or tools for provisioning your Messaging Server entries.


The following sections provide high-level information about the supported provisioning tools:

Sun ONE Delegated Administrator for Messaging

Sun ONE Delegated Administrator for Messaging (formerly called iPlanet Delegated Administrator) provides both a command-line and a graphical user interface to provision users and groups. Delegated Administrator uses Sun LDAP Schema 1, which is the Messaging Server 5.x version of provisioning definitions.

LDAP Provisioning Tools for Messaging Server

Schema 1 users and groups can be provisioned using the LDAP Directory tools (Schema 2 is not supported). Unlike the Delegated Administrator graphical and command-line interfaces, you can directly provision users and groups by adding, removing, and modifying the LDIF records through LDAP without having to use a user interface.

Delegated Administrator and Messaging Server

Access Manager uses Schema 2. Because the Sun Java System component products in the Java Enterprise System product suite use Schema 2, use Delegated Administrator 6.4. This should particularly be the case if you are using more than one Java Enterprise System product, or if you are performing a brand new installation of Messaging Server.

See the Sun Java System Delegated Administrator 6.4 Administration Guide for installation details.

Comparing Messaging Server Provisioning Tool Options

Table 8–1 shows the various supported schema, provisioning tools, provisioning limitations, and recommended documentation for additional information.

Table 8–1 Messaging Server Provisioning Mechanisms

Supported Provisioning Tool  

Provisioning Tool Functionality  

Provisioning Tool Limitations  

For Further Information  

Sun ONE Delegated Administrator for Messaging Graphical User Interface 

Uses: Schema 1 

Provides a graphical user interface for administrators to manage users, groups, domains, and mailing lists. End users can manage vacation messages and Sieve filters. 

  • Only available to existing Messaging Server 5.x customers who are now upgrading to Messaging Server 6.

  • Can only be used with Sun ONE Web Server 6.0 (which is only available with the Messaging Server 5.2 bundle). It cannot be used with Sun ONE Web Server 6.1.

  • Incompatible with Sun Schema 2 and with other Java Enterprise System products.

  • Unable to use mail filters through Sun Java System Messenger Express. Must use filters through Delegated Administrator.

  • Must use auto reply channel which is only available in Messaging Server 5.2 product.

Read the Sun ONE Delegated Administrator for Messaging 1.2 documentation. 

Describes how to install and administer the Sun ONE Delegated Administrator interface. 

Sun ONE Delegated Administrator for Messaging Command-line Interface 

Uses: Schema 1 

Provides a command-line interface for administrators to manage users, groups, domains, and mailing lists. 

  • Incompatible with Sun Schema 2 and with other Java Enterprise System products.

Read the Sun ONE Delegated Administrator for Messaging 1.2 documentation. 

Provides syntax and usage for Sun ONE Delegated Administrator command-line utilities.

LDAP Provisioning Tools

Uses: Schema 1 

Provides tools to directly modify LDAP entries or for creating custom provisioning tools. 

  • Incompatible with Sun Schema 2 and with other Java Enterprise System products.

Read the iPlanet Messaging Server 5.2 Provisioning Guide and the iPlanet Messaging and Collaboration Schema Reference.

Describes the Sun LDAP Schema 1 provisioning model. 

In addition, these guides explain how to use LDAP provisioning tools and the usage of specific attributes and object classes. 

Delegated Administrator

Uses: Schema 2 

Provides graphical and command-line interfaces for administrators to manage users, groups, domains, and mailing lists. 

Compatible with other Java Enterprise System products. 

  • Not backwardly compatible with Sun Schema 1.

  • No GUI provisioning tool to use with Sun Java System Access Manager.

  • Sun Java System Access Manager must be installed to enable this interface.

Read the Sun Java System Delegated Administrator 6.4 Administration Guide.

Provides syntax and usage for the command-line utility. 

Understanding Calendar Server Provisioning Tools

Through supported Calendar Server provisioning tools, you can query, modify, add, or delete user, group, and domain entry information in your LDAP directory. This section examines these Calendar Server provisioning tools.

In addition to the questions asked in Deciding Which Schema to Use for Calendar Server, you should use Table 8–2 to evaluate your schema and provisioning tool options.


Note –

Prior to installing and configuring Calendar Server, you need to decide upon a schema model and tool or tools for provisioning your Calendar Server entries.


The following sections provide high-level information about the supported provisioning tools:

LDAP Provisioning Tools for Calendar Server

Schema 1 users and groups can be provisioned using the LDAP Directory tools (Schema 2 is not supported). You can directly provision users and groups by adding, removing, and modifying the LDIF records through LDAP without having to use a user interface.

Delegated Administrator and Calendar Server

Access Manager uses Schema 2. Because the Sun Java System component products in the Java Enterprise System product suite use Schema 2, use Delegated Administrator 6.4. This should particularly be the case if you are using more than one Java Enterprise System product, or if you are performing a brand new installation of Calendar Server.

See the Sun Java System Delegated Administrator 6.4 Administration Guide for installation details.

Comparing Calendar Server Provisioning Tool Options

The following table shows the various supported schema, provisioning tools, provisioning limitations, and recommended documentation for additional information.

Table 8–2 Calendar Server Provisioning Mechanisms

Supported Provisioning Tool  

Provisioning Tool Functionality  

Provisioning Tool Limitations  

For Further Information  

LDAP Provisioning Tools

Uses: Schema 1 

Provides tools to directly modify LDAP entries or for creating custom provisioning tools. 

Incompatible with Sun Schema 2 and with other Java Enterprise System products. 

Read the iPlanet Messaging Server 5.2 Provisioning Guide and the iPlanet Messaging and Collaboration Schema Reference.

Describes the Sun LDAP Schema 1 provisioning model. 

In addition, these guides explain how to use LDAP provisioning tools and the usage of specific attributes and object classes. 

Delegated Administrator

Uses: Schema 2 

Provides graphical and command-line interfaces for administrators to manage users, groups, domains, and resources. 

Compatible with other Java Enterprise System products. 

  • Not backwardly compatible with Sun Schema 1.

  • Sun Java System Access Manager must be installed to enable this interface.

Read the Sun Java System Delegated Administrator 6.4 Administration Guide.

Provides syntax and usage for the command-line utility.