Software

Decision Support: Configuration design prep in Exchange 2000 planning

When planning your Exchange 2000 migration, find out if you need data stores and storage groups, indexing, additional public folder trees, and Recipient Update Service (RUS) for multiple domains.


One of the final preparation steps for an Exchange 2000 migration involves examining some design implications of various parameter configurations. These settings include:
  • Data stores and storage groups
  • Indexing
  • Hard disk storage
  • Policies
  • Delegating control
  • Recipient Update Service (RUS) for multiple domains
  • Additional public folder trees

Carol Bailey's series on Exchange 2000 planning
Be sure to check out the other articles in this series:

Data stores and storage groups
The ability to have multiple data stores and multiple storage groups is new in Exchange 2000’s Enterprise version, so you need to evaluate whether you can use these features to your advantage. For example, Exchange 2000 allows you to have up to four storage groups, with up to five mailboxes of public folder data stores.

So should you use multiple data stores? Good reasons to do so include:
  • Quicker restores.
  • Specific policies for individual groups, such as different mailbox limits for different departments.
  • Indexing for fast searches on one data store (e.g., public folders), but not others (e.g., newsgroups).
  • Different logging requirements on different data stores, for example, circular logging for newsgroups and full logging for mailboxes.

When you have identified the need for a new data store, should it be in the same storage group or a new one? Good reasons to create a new storage group are:
  • Ability to have more than five data stores overall
  • Better security (data is more segregated)
  • Simplified backup and restore (NTBackup supports backup at the storage group level and supports simultaneous restores on storage groups)
  • Simplified management
  • Staggered or different backup routines and different policies on how long backups should be kept

However, multiple storage groups do have some drawbacks. They require 50 MB minimum of disk space, plus a minimum of 10 MB RAM for each data store; this amount increases as the size of the data store increases. Because you should place associated transaction logs on different physical disks for other storage groups, this results in requirements for additional storage and disk protection.

Indexing
If you want to use indexing on any of your stores to speed up searches—public folder stores are a popular choice for full text indexing; make sure you have sufficient disk space to accommodate the index. Microsoft says an index typically requires 20 percent of the disk space occupied by the files to index; remember, this space requirement will grow as the store grows.

Indexes must be rebuilt to reclaim disk space previously occupied by deleted items, so you’ll need to schedule this routine maintenance task during quiet periods. Carefully plan when you want to rebuild and repopulate indexes. This process is CPU-intensive, so find a maintenance window when the server is needed less, perhaps overnight when you’re not backing up or performing normal database defragmentation.

Note that you do not have to include provisions for indexing binary files and image files because these file types are not supported with indexing. There’s conflicting advice on whether you should back up indexes. Many admins say this is a waste of time and resources, since a lost index can easily be rebuilt.

Hard disk storage
When it comes to protecting your servers’ hard disk storage, the usual advice is to mirror the operating system and also to mirror disks that have transaction logs, keeping transaction logs separate from data stores. Use either RAID 1 or RAID 10 (mirror with stripe set) for better performance, and use a separate mirrored disk if possible for each transaction log. Use RAID 5 for the actual data stores. Again, employ one separate physical RAID array per store.

This is fairly standard stuff, but because the Enterprise version of Exchange 2000 supports multiple data stores and multiple storage groups—you can have up to 20 mailbox stores on one server instead of just one—you may need to increase your servers’ hard disk capacity to accommodate the new configuration and keep the same level of redundancy and performance. Fortunately, hard disks are relatively cheap these days, but your servers’ ability to physically accommodate them is another matter, so check this in advance when planning for multiple data stores or storage groups.

Note that the general recommendation is to keep 50 percent of your available disk space free. If the disk space gets to less than 10 MB, Exchange 2000 will stop to ensure database integrity.

Policies
Decide in advance what system and recipient policies you want to put in place. Policies in Exchange 2000 are similar in concept to Active Directory Group Policies in that they let you specify a single configuration and apply it to multiple objects. For example, policies can be applied to multiple servers, public stores, and mailbox stores.

When you later change a configuration option within a policy, changes are automatically applied to child objects beneath the policy through natural inheritance. For example, you may define a mailbox store policy that gives all users a certain storage limit. You later add more hardware that will allow you to increase storage limits. You would have to define the option only once, and the configuration could take effect on all (or some, if preferred) of your servers.

Other commonly used policy options include maintenance settings for both public and mailbox stores, replication intervals for public stores, and message tracking for servers.

Delegating control
Decide in advance which of the three Exchange roles you want administrators to have:
  • Exchange Full Administrator offers full control at the Organization level, including the ability to delegate control to others.
  • Exchange Administrator offers the ability to fully administer Exchange at the given level, but can’t modify permissions or delegate control.
  • Exchange View Only Administrator can view all configurations, but is unable to modify anything. However, a user with this permission can create a new mailbox-enabled user, a mail-enabled user, and a contact, if they can create a user in Active Directory—for example, if they are an Account Operator or are delegated access to a specific OU.

You typically would delegate control to Exchange administrators at the Administrative Group level. Note that Exchange Administrators can’t create new users or give users Exchange mailboxes unless they also have the equivalent of Account Operator permission. Similarly, Account Operators can’t create mailboxes or mail-enable users without also having the minimum of Exchange View Only Administrator permissions.

Once you have decided on the administration strategy you want to use, it’s relatively simple to use the Delegation of Control Wizard in Exchange’s System Manager; the process is similar to the Active Directory Delegation of Control Wizard. The difficult part, as with Active Directory delegation, is in deciding which permissions to grant to your administrators.

Recipient Update Service (RUS) for multiple domains
RUS is used to update the Global Address List (GAL), new mailboxes, new address lists, and recipient policies. You must have one instance of the RUS configured for every domain that has recipients, even in domains that have no Exchange servers in them.

When you upgrade your first Exchange server to Exchange 2000, the process creates two default RUS services—one for your enterprise and another for the domain. To create another instance of RUS for additional domains, you’ll need to first run the DomainPrep switch on a Windows 2000 server in the additional domain and then create a new RUS instance for each domain, specifying the Exchange server to run the service and a domain controller in that domain to use for recipient information.

Additional public folder trees
Although not accessible to MAPI clients, such as Outlook, this new feature in Exchange 2000 offers more flexibility in how publicly stored data is accessed, replicated, and viewed. For example, you could create a public folder tree that is visible only to a specific group or department to help ensure confidentiality and minimize confusion.

Additional public folder trees support deep searches through the entire tree and use Windows 2000 security permissions. They are also visible with Exchange 2000 Installable File System (IFS), NNTP clients, and through common Microsoft applications, such as Word. MAPI clients can access additional public folder trees if they view them as a Web page.

Ready to roll out
Of course, there’s much more to configuring Exchange 2000 than I’ve listed here, but I’ve mentioned some of the key configuration issues that you should consider when designing your upgrade strategy. Together with the other checklists, these should form the basis of a successful design plan to upgrade from Exchange 5.5 to Exchange 2000.

 

Editor's Picks

Free Newsletters, In your Inbox