Creating a Store
You can create two kinds of stores in a storage group, a mailbox store for messages and a public folder store for public folder use. Each store will have its own .EDB and .STM files. You can't create a store until you have created a storage group. When you first install Exchange 2000 Server, it creates a storage group named First Storage Group (which you can rename) as well as a mailbox store and a public folder store inside that storage group.
Creating a Mailbox Store
To create a new mailbox store, right-click the storage group in which you would like to create the store, point to New, and then choose Mailbox Store. Figure 11-6 shows the property sheet that appears. On the General tab, enter the name of the mailbox store, and then click the Browse button next to the Default Public Store field to see a list of public folder stores with which you can associate the mailbox store (Figure 11-7). Choose a public folder store from the list, and click OK.
Figure 11-6. General tab of the property sheet for a new mailbox store.
Figure 11-7. Selecting a default public folder store for the new mailbox store.
NOTE
Selecting a public folder store to associate with the new mailbox is required because each Exchange user must have a default public folder store for public folder access. Selecting a public folder store here does not limit the user's ability to access other public folder stores or public folder trees. Instead, it provides an entry point into the whole public folder area.
After selecting a public folder store to associate with your mailbox store, click Browse next to the Offline Address List field to choose a default offline address list for users homed in this store (Figure 11-8). Users will still be able to download other offline address lists; this option simply specifies the default. For more information on offline address lists, see Chapter 9.
Figure 11-8. Selecting a default offline address list for the new mailbox store.
If you want the mailbox store to support Secure/Multipurpose Internet Mail Extensions (S/MIME), select the Clients Support S/MIME Signatures check box. (See Chapter 20 to learn more about S/MIME and when you would want to use it.) And if you want all incoming messages converted to 10-point Courier, select the Display Plain Text Messages In A Fixed-Sized Font check box.
On the Database tab of the property sheet (Figure 11-9), you can specify where you want the two files that make up this store to be physically located. Even though you can navigate to a remote share point on another server, Exchange 2000 Server will not allow you to map either of your files to a network share. However, you can create a volume mount point and specify it as the location for either of your files. This can be helpful if you know that a particular database will house large files or many files, since you can create a special partition for them. You can also specify the time at which you want the store maintenance utilities to run for this particular store.
Figure 11-9. Database tab of the property sheet for a new mailbox store.
The Do Not Mount This Store At Start-Up check box allows you to specify that the store not be mounted at startup. The default is to have the store mounted when Exchange services start. Finally, you can select the This Database Can Be Overwritten By A Restore check box. This option relates to the database's globally unique identifier (GUID).
Each database has a GUID. This GUID is stored in the ESE database in one of the general purpose tables. (For more information on ESE, consult Chapter 2.) The database GUID, along with its physical path on the hard disk drive, is also stored in Active Directory. When the Store.exe process starts, one of its tasks is to attempt to mount the database. Before mounting the database, however, the Store.exe process compares the database GUID it finds in the database to the database GUID for that database in Active Directory. The directory paths are also compared.
If everything matches, the database is mounted. If there is a mismatch in any of the information, the Store.exe process refuses to start up the database. This failure can occur if the database files are moved from a different server or directory to their present location. The reason the Store.exe process requires the GUID to match is to prevent a database from being accidentally moved to a different location and having it start up under a different storage group with different transaction logs.
If the This Database Can Be Overwritten By A Restore check box is selected, the Store.exe process assumes you really want to move the database to this present location. So at startup, the Store.exe process will "fix" the database by changing the GUID in the database to the GUID that is in Active Directory; then at the next mounting, the GUIDs will match and the database will mount. Finally, the check box is cleared as part of this process.
NOTE
If there is no database found in the path when the Store.exe process is trying to mount the database, it will prompt you with an option to create a new database. The This Database Can Be Overwritten By A Restore check box is really only invoked when the Store.exe process finds a database in the path it is instructed to look in and finds what it believes is the wrong database because the GUID is different.
This check box functions similarly during a restore. During the AddDatabase() call, Ntbackup passes in the GUID, database name, and storage group name to the Store.exe process. If these match, then the Store.exe process passes back the locations where the files should be restored. If the GUID doesn't match, the Store.exe process looks at this check box, and if selected, it passes the database back to the backup process where the database files should be written.
NOTE
By moving databases around and selecting the This Database Can Be Overwritten By A Restore check box, it is possible to create multiple, different databases with the same GUID on your Exchange 2000 Server. If you try to mount both databases, only one will mount because of the conflicting GUIDs. Under no circumstances does Microsoft recommend keeping two databases with the same GUID or "swapping" databases for any reason. Unexpected and undesirable results can occur.
The Limits tab (Figure 11-10) allows you to set deleted-item retention times and storage warning limits for the mailbox store. You can also set these options globally by creating a mailbox policy under the Policies container. Values set via a policy cannot be overridden at the server level.
Figure 11-10. Limits tab of the property sheet for a new mailbox store.
The Full-Text Indexing features will be dimmed during the creation of your mailbox store. However, after the store has been created, you'll be able to enable full-text indexing by right-clicking the store in the Exchange System snap-in, pointing to All Tasks, and choosing Create Full Text Index. Once this index is created, additional objects will appear under the Full-Text Indexing container (Figure 11-11) and the features on the Full-Text Indexing tab will be available for configuration. For more information on the architecture of full-text indexing, see Chapter 2. To learn more about how to work with full-text indexing, see "Creating a Full-Text Index" later in this chapter.
On the Details tab of the mailbox store's property sheet, you can enter administrative notes about the mailbox store, such as who created it and its purpose. The Security tab, which will show up only on the property sheet of a successfully created mailbox store, lists the permissions for the users and groups that have access to the mailbox store. It's best to leave these at their default values unless you have specific reasons for altering them. Finally, the Policies tab lists any group policies that apply to this database. You cannot configure the group policy from this location, however.
Figure 11-11. Objects in the Full-Text Indexing container for Mailbox Store (California).
Creating a Public Folder Store
Creating a public folder store is similar to creating a mailbox store, with certain significant differences. One item to note is the relationship between the public folder store and a public folder tree. You cannot associate more than one store in each storage group with a given public folder tree. If you attempt to do so, you'll receive the message in Figure 11-12.
Figure 11-12. Public folder store error message.
You must associate individual public folders with a public folder tree. Depending on the type of client that will be using the public folder, you are not required to keep all of your public folders in one large, monolithic hierarchy that is replicated to every server in the organization. In Exchange 2000 Server, you can create public folder trees for various reasons: for projects, by department, or by location, to name just three. Bear in mind that additional public folder trees are not accessible by MAPI clients and can be accessed only by applications (such as Microsoft Word, Excel, or PowerPoint), Web-based clients, and the ExIFS. In this section, we'll use an example of a tree that will contain public folders for an Exchange 2000 migration project. Each store will deal with different aspects of the migration: planning, implementation, troubleshooting, and so on. Dividing up the folders for a project allows you to assign permissions to the folder for just those users who need it, thus isolating this information from the rest of the network. Figure 11-13 shows the creation of the Exchange Migration Planning public folder for the Exchange 2000 Migration Project public folder tree.
Figure 11-13. Creating an Exchange Migration Planning public folder.
NOTE
Each public folder store must be associated with a public folder tree. The confusing part is that you cannot associate more than one store on a given server with the same tree. Hence, associations are done on a per store/per server/per tree basis. For example, if you want to associate two different public stores created on the same server with the same tree, you won't be allowed to do this. Instead, you'll need to create the two public stores on two different servers and associate them with the same tree.
When you click the Browse button next to the Associated Public Folder Tree field, you see a dialog box listing all of the public folder trees that do not have a public folder store associated with them on your local server (Figure 11-14). Note that this list is based on all of the public folder trees in your organization, not just the ones on the local server. You'll want to develop your own naming convention for your public folder trees before you begin your migration or new installation of Exchange 2000 Server. A lack of planning at this stage will likely result in public folder trees that are misnamed or too similarly named, which will lead to confusion in the long run.
Figure 11-14. Selecting a public folder tree to associate with the new public folder store.
On the Database tab of the public folder store's property sheet, shown in Figure 11-15, you can select the locations where the physical databases should be created and the maintenance schedule for the store. You can also force manual mounting of the public folder store by selecting the Do Not Mount This Store At Start-Up check box.
Figure 11-15. Database tab of the property sheet for a new public folder store.
The Replication tab, shown in Figure 11-16, has several nice features. Here's where you schedule when replication of the public folder store should occur. Make your choice from the Replicate Public Folder Changes drop-down list; the selections include the following:
- Always Run
- Never Run
- Run Every Hour
- Run Every 2 Hours
- Run Every 4 Hours
- Use Custom Schedule
The default for Always Run is every 15 minutes. However, in the Limits area, you can enter the exact interval at which you want replication to occur when Always Run is selected. For instance, suppose that you have a companywide memos folder that is constantly being updated with new customer information. If you would like replication of this folder to occur every 30 minutes instead of every 15 minutes, you would enter 30 into the Replication Interval For Always (Minutes) field. This is much easier than selecting Use Custom Schedule in the Replicate Public Folder Changes list and then setting replication to occur every 30 minutes, although that is also a valid way to accomplish the same task.
Figure 11-16. Replication tab of the property sheet for a new public folder store.
If you are concerned about the size of the replication messages sent between your servers, you can adjust the value in the Replication Message Size Limit (KB) field. The default is 300 KB, but you can lower this limit if your connection is either slow or unreliable.
The Limits tab, shown in Figure 11-17, is where you set storage limits, deletion options, and age limits. The Keep Deleted Items For (Days) option specifies how long you want to retain items that have been deleted from this public folder. The items will remain hidden in the database for the number of days you specify, allowing you to recover them, if necessary
Figure 11-17. Limits tab of the property sheet for a new public folder store.
Suppose, for example, that you've set the deleted items option to 90 days. On May 1, you delete a posting titled March Memo. The deleted posting is stripped of its permissions, marked as hidden, and stamped with a future date and time that is exactly 90 days from the second that you deleted it. Now suppose that on July 18 you need some information that was in the March Memo. All you need to do is use your Microsoft Outlook client to recover the deleted item back into the public folder. The posting will be given its permissions back, the future deletion timestamp will be stripped from the object, and the memo will be available for use again. If you retrieve the information you need and then delete the March Memo item again, the same process will occur and another timestamp will be affixed to the object, indicating that it will be deleted in 90 days.
In addition, you can force the store to retain deleted items until the store has been backed up. To do so, select the Do Not Permanently Delete Items Until The Store Has Been Backed Up check box. You can also set age limits by entering a value in the Age Limit For All Folders In This Store (Days) box. Items that exceed this value based on the date and timestamp will expire automatically during the next garbage collection interval.
The Full-Text Indexing tab is dimmed during the creation of the public folder store, but the Details tab is not. On the Details tab, you can enter information about the store, such as its purpose or organizational information that might pertain to the store. Figure 11-18 shows an example of how the Details tab might be used.
Figure 11-18. Administrative notes for a public folder store.
Also, in Figure 11-18, you'll notice a Policies tab. This tab will inform you about the Exchange policies that are currently being applied to this public folder store. Exchange has two kinds of policies: system and recipient. System policies are created to apply to servers, mailbox stores, and public stores. To learn more about public folder store policies, refer to Chapter 12.
EAN: N/A
Pages: 193