Академический Документы
Профессиональный Документы
Культура Документы
Active Directory Integration Scalable Database Architechture o Upto 16 tb per mailbox database and upto 20 mailbox database per server. Coexistance with earlier version of exchange Enhance Security Enhance Administrative tools for mailbox management Outlook Web Access Integrated Support for mobile devices Integration with Outlook 2003 High availability support for 8 node cluster Faster Deployment Overcome from 26-drive letter. Interoperate with multiple clients
Mobile Service for Exchange Outlook Mobile Access Enhanced Recipient management with Tasks Wizards in System Manager Visibility to more message queues in Exchange 2003 Public Folder Migration with PFMigrate Mailbox Recovery Center Message Tracking Center Exchdump.exe utility Query based distribution groups Improved ability to restrict submission to Users and Distribution lists Enhance Exchange Features on Users Properties Moving mailboxes in Exchange System Manager Link State Improvement Virtual Address Space Improvement Changing X.400 (MTA) file location using system manager Changing SMTP root directory location using system manager Improved Virtual Memory Blocks Support upto 8 node cluster Improved dependencies hierarchy for exchange services Cross Forest collaboration Internet mail wizard for SMTP server Improved DSN (Delivery Status Notification) Diaganostic Logging and codes Improved Ability to Restrict Submissions to an SMTP Virtual Server Improved Ability to Restrict Relaying on an SMTP Virtual Server Shadow copy backup Recovery Storage Group New Exchange Server Deployment Tools for Public Folder New Exchange Server Deployment Tools for ADC Exchange Server 2003 Setup Improvements
???
Hardware Requirements
Intel Pentium or compatible 133 MHz or faster processor 256 MB of RAM recommended minimum; 128 MB supported minimum 500 MB of available disk space on the drive on which you install Exchange 200 MB of available disk space on the system drive CD-ROM drive VGA or higher-resolution monitor
Exchange 2003 Setup ensures that the Exchange Domain Servers and Exchange Enterprise Servers groups are intact. If the administrator moves, deletes, or renames these groups, Setup stops, and a warning message appears. Permissions to access mailboxes Exchange 2003 Setup locks down security on the database objects; therefore Exchange administrators cannot open other user's mailboxes. Outlook Mobile Access and Microsoft Exchange Server ActiveSync components installed by Setup By default, Exchange 2003 includes support for mobile devices. The services that enable these devices are called Outlook Mobile Access and Exchange ActiveSync. Previously, to use these services, you had to install Microsoft Mobile Information Server. Now, the built-in mobile device support in Exchange 2003 supersedes the Mobile Information Server product. Automatic installation of required Windows Server 2003 services on Microsoft Windows 2000 If you are installing Exchange 2003 on a server running Windows 2000, Exchange Setup automatically installs and enables .NET Framework and ASP.NET. Automatic configuration of Internet Information Services (IIS) 6.0 In Windows Server 2003, IIS 6.0 introduces a new "worker process isolation mode," which offers greater reliability and security to Web servers. Worker process isolation mode ensures that all of the authentication, authorization, Web application processes, and ISAPI extensions that are associated with a particular application are isolated from all other applications. To take advantage of these benefits, when you install Exchange Server 2003 on Windows Server 2003, Exchange Setup automatically sets IIS 6.0 to worker process isolation mode. Exchange Setup also enables certain ISAPI extensions. By default, during Windows Server 2003 installation, ISAPI extensions are not allowed to load. However, Exchange 2003 requires certain ISAPI extensions for features such as Microsoft Outlook Web Access, WebDAV, and Exchange Web Forms; therefore, Exchange 2003 enables the required ISAPI extensions during setup. No action is necessary; Exchange Setup automatically configures the ISAPI extensions. The IsapiRestrictionList metabase key controls the ISAPI extension behavior. Exchange Setup sets the metabase key appropriately so that the ISAPI extensions can load; however, if the key is modified after Exchange is installed, certain parts of Exchange may not function correctly. Automatic IIS 6.0 Configuration during Windows 2000 to Windows Server 2003 upgrade If you install Exchange 2003 on Windows 2000 and subsequently upgrade to Windows Server 2003, Exchange System Attendant automatically sets the IIS 6.0 mode to worker process isolation mode. Event Viewer will contain an event indicating that this mode change has occurred. After the upgrade, you may find that some of the ISAPI extensions for other applications do not function properly in worker process isolation mode. Although you can set the IIS 6.0 mode to "IIS 5 isolation mode" to ensure compatibility with your ISAPI extensions, it is recommended that you continue to run IIS 6.0 in worker process isolation mode; Exchange 2003 features such as Outlook Web Access, WebDAV, and Web forms, will not work in IIS 5 isolation mode. Installing Exchange System Management Tools Only To administer Exchange servers from a computer running Windows XP, Windows Server 2003, or Windows 2000 Server SP3, you can use Exchange Setup to install only Microsoft Exchange System Management Tools.
You must ensure that the computer meets the following requirements:
The computer is running Windows XP, Windows Server 2003, Windows 2000 Professional, or Windows 2000 Server SP3. The computer name does not contain unsupported characters. The language version matches any previous installation of Exchange 2000 System Management Tools (except for upgrades from English to Korean, Traditional Chinese, or Simplified Chinese).
Also, depending on the version of Windows that is running on the computer, you will need to install the required services.
Importance of naming
The first point on your migration checklist should be naming. What will be the name of your Microsoft Exchange 2003 organization? Is this the same name as the existing Exchange 5.5, or are you restructuring and creating a new organization? How does the Window Server 2003 domain name compare with the NT 4.0 domain name? Perhaps the most difficult naming system to master is DNS, nevertheless DNS is essential for locating Active Directory logon services, sites, and Global Catalog servers. The extra DNS factor with exchange is creating MX records so that SMTP can route mail to the correct server.
Phase one - Move user accounts from NT 4.0 and Dir.edb to Active Directory
The Exchange 2003 migration project will become easier when you divide the project into two distinct phases. The first phase is to get the directory information from Exchange 5.5 into Active Directory - preferably Windows Server 2003. Only when you have migrated that user account information should you consider moving the actual mailboxes with email to your new Exchange 2003 server.
mailboxes, custom recipients, and distribution lists. The ADC uses Connection Agreements to define individual configurations for replication. Two versions of the ADC exist; one for Windows 2003 and one for Exchange 2003. When you migrate, you need some way to move your directory objects from the Exchange Server 5.5 directory into Active Directory. Active Directory Connector (ADC) is the solution. The ADC is what will synchronize the Exchange Server 5.5 directory with Active Directory. This is done through the use of Connection Agreements. There are three types of Connection Agreements that the ADC for Exchange 2000 Server and later supports:
2.
3.
Note:Always use the most recent version of the Exchange Server ADC and not a Microsoft Windows ADC, which was released on the Windows 2000 CD, because the Windows 2000 ADC is not capable of doing many things that the Exchange 2000 Server ADC can do and it has not been updated since its release.
Phase two - Move the accounts from Exchange 5.5 to Exchange 2003.
Now that the mailbox owner and security information has been added to Active Directory, you can turn your attention to moving the email stores from Exchange 5.5 to Exchange 2003. Unlike an Exchange 2000 migration, when you upgrade Exchange 5.5 you have to use the move mailbox strategy, an in-place upgrade is not an option.
To make sure that all of the mailboxes in the Exchange Server 5.5 directory are represented in Active Directory, along with all of the mail attributes that are associated with the mailboxes. This ensures that the Exchange 2000 Global Address List is complete, even if the Windows NT migration to move all of the user accounts from Windows NT 4.0 to Active Directory is not 100 percent complete. To allow an administrator to move a user's mailbox from an Exchange Server 5.5 computer to an Exchange 2000 server, even if the user's logon account is not migrated to Active Directory yet and is still in a Windows NT 4.0 domain.
If you enable these disabled accounts, and then users use these accounts (without additional modification) to log on, issues will occur with public folders and delegation in Exchange. Enabling and Removing ADC-Created Disabled Accounts Microsoft does not recommend that you enable the disabled accounts that are generated by the ADC. However, if there is a critical business requirement that requires you to enable them, follow these instructions to enable and to use the ADC-created disabled accounts: Use a Windows NT migration tool to merge the SID of the Windows NT 4.0 account into the Active Directory account as the sIDHistory value to preserve the permissions. Enable the account. Remove the msExchMasterAccountSID attribute.
Active Directory
The Windows 2000 directory service replaces the Security Accounts Manager (SAM) in Microsoft Windows NT version 4.0. Active Directory consists of a forest, domain(s), organization units, containers, and objects. Different classes of objects can be represented within Active Directory including users, groups, computers, printers, and applications. The use of Active Directory is governed by its schema.
A directory service abstraction interface that allows programming languages those are compatible with the Component Object Model (COM), such as Visual Basic, VBScript, JavaScript, C, and C+ + to make common directory calls to an underlying directory service. ADSI providers include Lightweight Directory Access Protocol (LDAP), NDS, Bindery, and Windows NT (SAM). Programmers and system administrators normally use ADSI to automate or script the bulk manipulation of directory entries.
ADSI Edit
A Microsoft Management Console (MMC) snap-in used to view all objects in the directory (including schema and configuration information), modify objects, and set access control lists on objects.
Connection Agreement CA
The configuration of information to be replicated using the Active Directory Connector. This configuration information includes the servers that participate in the replication, which object classes (mailbox, custom recipient, distribution list, user, contact, and group) to replicate, containers and organizational units to use for object placement, and the activity time schedule.
Domain tree
Domain Tree is a collection of domains that have a contiguous namespace, such as microsoft.com, dog.microsoft.com and cat.microsoft.com. Domains within the forest that do not have the same hierarchical domain name are located in a different domain tree. A disjoint namespace is the term used to describe the relationship between different domain trees in the forest.
Global Catalog
A server that holds a complete replica of the configuration and schema naming contexts for the forest, a complete replica of the domain naming context in which the server is installed, and a partial replica of all other domains in the forest. The global catalog knows about every object in the forest and has representations for them in its directory, however, it may not know about all
attributes (such as job title and physical address) for objects in other domains. The attributes that are tagged for replication to the global catalog are assigned through the Active Directory Schema Manager Microsoft Management Console (MMC) snap-in. There is only one policy for global catalog attribute replication in the forest. A global catalog will listen on port 3268 for LDAP queries (that are global to the forest), and port 389, which standard domain controllers use (for local domain queries). A domain controller can be made into a global catalog (and vice versa) by selecting or deselecting a check box in the Active Directory Sites and Services MMC snap-in.
Schema
Schema is the metadata (data about data) that describes the use of objects within a given structure. In Active Directory, the schema governs the type of objects that can exist and the mandatory and optional attributes of each object. Windows 2000 Active Directory has an extensible schema that allows third parties to create their own object classes. Schemas also exist for other components such as the message transfer agent and information store in Exchange Server.
Forest (Enterprise)
Forest is a collection of domains and domain trees. The implicit name of the forest is the name of the first domain installed. All domain controllers within a forest share the same configuration and schema naming contexts. To join an existing forest, the Dcpromo utility is used. The first domain within the forest cannot be removed.
Site
Site a collection of IP subnets. All computers that are in the same site have high-speed connectivitylocal area network (LAN) speedswith one another. Unlike an Exchange site, an Active Directory site does not include a unit of namespace; for example, multiple sites may exist within a single domain, and conversely, a single site may span multiple domains.
Administrative Group
Its the administrative collection of servers running Exchange 2000 that can be administered as a single unit. An administration group can include zero or more policies, routing groups, public folder trees, monitors, servers, conferencing services, and chat networks. When security settings (permissions) are applied to an administration group, all child objects in the DS tree inherit the same Access Control Lists (ACLs) as the administration group node. Note that an administration group does not define the routing topology for messages; this is handled by routing groups.
Routing Groups
Exchange Server 2003 supports the concept of routing groups to control the message flow between Exchange Servers. Routing groups are groups of servers running Exchange Server 2003 that are connected over permanent highspeed network links. Within routing groups, Exchange Server always transfers messages over SMTP. There is one special Server called the Routing Group Master which is responsible for tracking and maintaining the routing information which is necessary for determining the best path for message delivery. The default Routing Group Master is the first server in the routing group. If you wish to transfer the Routing Group Master role you must do so manually in the Exchange System Manager.
Routing service
A component in Exchange 2000 that builds link state information.
Routing Objects
Component Object Model (COM) objects that are used to program Exchanges routing engine behavior. These objects allow the creation and manipulation of process maps, which define the series of states to be tracked by the routing engine and the activities to be performed at each step. Routing objects are used primarily in workflow applications. Rendezvous Protocol (RVP) (Note that this name is preliminary). The Microsoft published protocol that is used between the MSN Messenger service and the Instant Messaging server that is implemented on Exchange 2000. RVP uses an extended subset of HTTP-DAV with an Extensible Markup Language (XML) payload to send subscriptions and notifications between Instant Messaging clients and servers.
Schema
The metadata (data about data) that describes how objects are used within a given structure. In relation to Exchange, this term may be used in the context of Active Directory, but it can also be used to describe the structure within the store or the MTA.
SMTP A major standards-based protocol that allows for the transfer of messages between different messaging servers. SMTP is defined under RFC821 and uses simple command verbs to facilitate message transport over TCP/IP port 25.
Online Backups
When Exchange Server 2003 performs an online backup, all services, including the Exchange store, continue to run normally throughout the backup process. This allows users to continue to use their mailboxes during a backup process, whether the backup is incremental, differential, or full. During a full online backup, the .edb, .stm, and .log files that comprise the Exchange store are backed up and checked for corruption at the file system level. Unreliable hardware, firmware, or disks can all cause file system corruption. The check verifies the checksums on each 4-kilobyte (KB) block or page in the database. If there is a checksum failure, backup aborts. Therefore, after an online backup is complete, you should check the Event Viewer to find out whether your Exchange store is corrupted. If you see a failed backup with a page read error event in Event Viewer, there may be a problem in the database.
Store
The generic name given to the storage subsystem on a server running Exchange. This term is used interchangeably to describe the Store.exe process and Exchange databases.
Storage group
A collection of Exchange databases on a server running Exchange 2003 that share the same Extensible Storage Engine (ESE) instance and transaction log. Individual databases within a storage group can be mounted and dismounted. Each server running Exchange 2003 can architecturally host up to 20 storage groups, although only four can be defined through the Exchange System Manager: 1. In Exchange Enterprise 2003 4 Storage Group. 2. Each Storage group can have 5 database.
MDBEF
In Exchange 5.5 message are always written to the database in MS Datbabase Encapsulated Format (MDBEF). Even if the message in non-MDBEF format and needs to be written to the database, the Imail process converts it to MDBEF forrmat so that it can be written to the information store.
Mailbox Recovery
What happens when a user deletes some e-mails or you lose a mailbox or more through a hardware failure or a disaster like a fire or water damage? Exchange 2003 has some nice features to prevent damage from a disaster or to recover Mailbox items and mailboxes. Some of these features are: Deleted item Recovery in Outlook Mailbox Recovery through Mailbox Recovery Storage Group Mailbox Recovery through Keep Deleted Mailbox for XX days Mailbox Recovery Center Deleted item Recovery in Outlook If you delete an object in Outlook, it is usually moved to the deleted items container in Outlook. Be sure that you dont activate the deletion of Objects from the deleted items container when you close Outlook (you can configure this setting in Outlook under Options).
Use
Private information store, the location for all user mailboxes Streaming File Public information store, the location for all public and system folders Streaming File Directory store Current transaction log Old transaction logs, numbered (hexadecimal) from 00001 eg. Edb00006.log Res1.log and Res2.log Reserved transaction logs, used to flush transactions out of memory if disk space is exceeded Edb.chk Checkpoint file marking the last buffer that has been committed to a database Tmp.edb Temporary database file created when a database is compacted Tempdfrg.edb Temporary database file created when a database is compacted
ESEUTIL Basics
The output is shown above of ESEUTIL offline defragmentation. Note When you defragment an .edb database file, the associated .stm file is defragmented also. Be sure to defragment your database whenever you move users between servers or delete a lot of information. You can also know how much space can be saved by checking the event viewer for event ID 1221 message description contains the following text:
The database "storage_group\mailbox_store (server_name)" has nnn megabytes of free space after online defragmentation has terminated.
Output of Isinteg SYMPTOMS in Exchange 2003 When the mailbox store database in Microsoft Exchange Server 2003 Standard Edition reaches the 16-gigabyte (GB) size limit, the mailbox store does not mount. Additionally, the following event IDs may be logged in the Application event log:
Event Type: Error Event Source: MSExchangeIS Event Category: General Event ID: 1112 Description: The database "Mailbox Store (Server Name)" has reached the maximum allowed size. Attempting to unmount the database. Event Type: Warning Event Source: ESE Event Category: Space Management Event ID: 445 Description: Information Store (3160) The database D:\Program Files\Exchsrvr\MDBDATA\priv1.edb has reached its maximum size of 16383 MB. If the database cannot be restarted, an offline defragmentation may be performed to reduce its size.
Note Although the description for event ID 445 states that the Priv1.edb file has reached a size of 16,383 megabytes (MB), this may not be true. Event ID 445 is triggered if the combined size of the Priv1.edb file and the Priv1.stm file reaches 16,383 MB. The Priv1.edb file by itself may be smaller than 16,383 MB.
The Exchange System Attendant is a multi-faceted and sometimes mysterious service. To remove some of the mystery & hopefully provide a bit of clarity to MAD here are the cliff notes version of what it actually does. Initialization and Tasks 1. Binds to Domain Controller upon startup a. Uses ADSI to do a server-less binding to find a DC b. Temporarily binds to GC for tasks like proxy generation 2. Loads various Exchange components upon startup a. DSAccess, DS Proxy, DS2MB, etc... 3. Has various background tasks a. Example: verifies machine account is present in the Exchange Domain Servers Inventory of Functions in MAD 1. DSAccess (Directory Service Access) - dsaccess.dll a. Builds a list of available Domain Controllers (DCs) that will be used by Exchange b. proxies LDAP queries from multiple components to the AD and maintains results in cache for a better overall system performance c. Other components besides MAD can load & initialize DSAccess 2. DS2MB (Directory Service to Metabase Update Service) - ds2mb.dll a. Mainly replicates protocol settings from the active directory to metabase b. Also creates exchange application pool & adds Exchange virtual roots to application pool in upgrade scenarios to Windows 2003 to support IIS6 Dedicated App Mode 3. RUS (Recipient Update Service) - abv_dg.dll a. Proxy generation - Bases proxyAddresses attribute for users on recipient policies, calls MAD to evaluate recipient policies & generate proxies b. Address List - stamps showInAddressBook attribute on users/distribution lists 4. DSProxy (also known as DS referral) - dsproxy.dll a. Relays all "MAPI to DS" communication for older MAPI clients 5. Offline Address List - Oabgen.dll a. Set of address lists in files that are created and stored on an offline address list server 6. Free/Busy - madfb.dll a. Mad Free/Busy (MADFB) is used by OWA to publish free/busy b. Store extracts free/busy from clients calendar and sends messages to System Attendant mailbox c. MADFB picks up messages and publishes to free/busy public folder 7. Mailbox Manager - logic in MAD a. Used to enforce corporate message retention policies & manage information store size b. Mailbox Manager Task runs every 15 minutes to see if the schedule information indicates it needs to call the mailbox clean task 8. Monitoring - logic in MAD a. System Attendant monitors server resources based on an interval b. Updates the routing table via WMI based on current status 9. RPC-HTTP Polling - logic in MAD a. RPC-HTTP polling thread to configure FE & BE (added in exchange 2003 SP1)
DSProxy
The Directory Service Proxy (DSProxy) is the Exchange Server 2003 component that provides an address book service to Microsoft Outlook clients. DSProxy is implemented in DSProxy.dll. DSProxy has two functions: Emulate a MAPI address book service Proxy requests to an Active Directory server
DSProxy provides both proxy and referral services. MAPI clients running Outlook 2002 Service Release 1 and earlier versions use the proxy functionality because these clients were designed to use Exchange Server as its Directory Service. This was true for Microsoft Exchange Server from 4.0 to 5.5 but beginning with Exchange Server 2000, Microsoft Active Directory takes the part of the Exchange Directory services. Therefore, DSProxy emulates a directory service, so that earlier clients can function. Exchange Server 2003 server forwards the requests to Active Directory. Later versions of Outlook, such as Outlook 2000 with SR-2 and Outlook 2002/2003, are designed with the assumption that Exchange Server 2003 does not have its own directory service. After DSProxy refers one of these later clients to a global catalog server, the client communicates directly with Active Directory. DSProxy obtains its list of working global catalog servers from DSAccess. DSAccess handles only LDAP queries. However, DSProxy fully relies on DSAccess to provide global catalog failover support.
DSProxy Operations
DSProxy performs the following operations: It collects a list of working global catalog Servers from DSAccess and selects only global catalog Servers that are in the Server's local Active Directory site.
It proxies MAPI queries from earlier Outlook clients to the remaining global catalog Servers. The mechanism used to direct Outlook clients to one of the remaining global catalog Servers is a round robin mechanism. DSProxy initially runs single threaded and can support up to 512 client connections. DSProxy automatically creates an additional thread for every 512 client connections. Unlike DSAccess, DSProxy has no caching mechanism. Every MAPI query processed through DSProxy is sent to a Global Catalog Server.
DSAccess
Exchange 2003 services access information that is stored in Active Directory and write information to Active Directory. If this communication occurred directly between each service and Active Directory, Exchange 2003 could overwhelm an Active Directory domain controller with communication requests. DSAccess is the component which controls the interaction between Exchange requests and Active Directory. DSAccess is a shared API that is used by multiple components in Exchange 2003 to query Active Directory and obtain both configuration and recipient information. DSAccess is implemented in DSAccess.dll, which is loaded by both Exchange and non-Exchange components. The components are: System Attendant Message Transfer Agent (MTA) Microsoft Exchange Information Store Exchange Management Service Internet Information Services (IIS) Windows Management Instrumentation (WMI)
DSAccess discovers the Active Directory topology, detects domain controllers and Global Catalog servers, and maintains a list of valid directory servers that are suitable for use by Exchange components. In addition, DSAccess maintains a cache that is used to minimize the load on Active Directory by reducing the number of Lightweight Directory Access Protocol (LDAP) requests that individual components send to Active Directory servers. The DSAccess Cache is configurable through several Registry Keys.
Managing the Exchange Server Proxy E-Mail addresses and for creating and updating email addresses for Exchange Server recipients and Exchange core components.
There is one RUS service in every domain where Exchange is installed and one Exchange Recipient Update Service for the Enterprise Configuration (the whole Exchange Organization). Exchange Server 2003 communicates with directory servers to update recipient objects (such as mailbox-enabled user accounts and mail-enabled groups) with e-mail addresses, according to the recipient policies defined for the organization. To do this, Exchange Server 2003 uses Recipient Update Service, a component of System Attendant. Recipient Update Service creates and maintains Exchange Server 2003specific attribute values in Active Directory. If you create a mailbox for a user, Recipient Update Service automatically generates the user's SMTP address and any other proxy addresses that you defined for your recipients.
1. Enterprise configuration Recipient Update Service There is only one instance of this
Recipient Update Service in the organization, because the Enterprise Recipient Update Service is used to update the configuration directory partition, and there is only a single configuration directory partition shared by the entire forest. Domain Recipient Update Service You must have a Recipient Update Service for each domain that contains mailbox-enabled users.
2.
For each particular domain in a forest, Recipient Update Service associates one Exchange Server 2003 computer (on which Recipient Update Service runs) with one domain controller (on which the directory objects are updated). Only one Recipient Update Service can be associated with any directory server at any given time. Updating Recipient Objects The method that Recipient Update Service uses to perform a search is determined by the actions that an Exchange administrator takes in Exchange System Manager. For example, in Exchange System Manager, you can right-click a Recipient Update Service configuration object and select the Rebuild command to recalculate address list memberships and the recipient policy settings of all recipients in a domain at the next scheduled interval. You can also select the Update Now command to perform this processing immediately. Recipient Update Service searches the directory for objects to update in the following three ways: Update new and modified objects only. This is the default behavior that Recipient Update Service exhibits each time it searches for objects to update. This is also the default behavior that Recipient Update Service exhibits when you use Update Now, if you do not select the Rebuild option, and none of the policies were modified or applied. Recipient Update Service tracks the last change that occurred on the domain controller, against which Recipient Update Service is configured to run. Based on the schedule that is set on the Recipient Update Service object, Recipient Update Service periodically checks for objects that have been created or updated since it last checked.
The Update Now function in Exchange System Manager sets the msExchReplicateNow attribute to TRUE, and causes Recipient Update Service to temporarily ignore its schedule and immediately query for new changes and take appropriate action on those objects. After the Update Now process is finished, msExchReplicateNow is reset to FALSE.
Update all objects When you select the Rebuild option in Exchange System Manager, you set the msExchDoFullReplication attribute on Recipient Update Service to TRUE. After msExchDoFullReplication is set to TRUE, the next time that Recipient Update Service starts, it looks at every object, instead of querying only for new objects. When the Rebuild process finishes, msExchDoFullReplication is reset to FALSE. Update objects that correspond to a specific recipient policy You can modify the filter on a policy (the purportedSearch attribute) to cause Recipient Update Service to take action beyond its default behavior. When you modify the filter on a policy, the policy can apply to a completely different set of users than those to whom it applied previously. Because of this, if the filter on a policy is modified, Recipient Update Service queries for every user who matches both the later filter and the earlier filter. This occurs the next time that Recipient Update Service is started by the schedule or by the Update Now command. Recipient Update Service runs against all users who match either filter and updates their msExchPoliciesIncluded attribute to reflect the filter that now applies. Recipient Update Service updates the proxy addresses on all users that match the corresponding policy filter.
and maintains its own specific message queues outside the Exchange store in the \Program Files\Exchsrvr\Mtadata directory. The registry key is HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\MSExchangeMTA
The IIS Admin service also provides access to the IIS configuration information to other applications, such as to the metabase update service, which is an internal component of System Attendant. The registry key for the IIS Admin service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin. The IIS Admin service depends on the Remote Procedure Call (RPC) service and Security Accounts Manager (SAM) service.
PUBLIC FOLDERS
For the administrator, public folders are a separate database.
Figure 1
This screenshot shows the Exchange databases on a single Exchange 2003 Standard server. The priv1 database, composed of both an EDB and an STM file, contains the user mailboxes. The pub1 database contains the public folders. Both databases in Exchange 2000 and in Exchange 2003 up to SP2 had a limit of 16GB. In the fast moving Internet days, 16GB is not much. However, most mail accumulates in user mailboxes, leaving the public folder database pretty empty. Later on I will show how public folders can be better used to even this out, so you get a smaller mailbox database and more room to grow. Public Folders contain the same type of folders you can access using Outlook, and can hold mail, calendaring and task information. You can set security on these folders so that only specific people will have specific types of access to these folders.
Public folders can be created using Exchange System Manager or the Outlook client.
Figure 2
Outlook 2003 sort of hides the public folders, so you first have to access the Folder list, then on the right side, open the Public Folder List, All Public Folders and the select New Folder
Figure 3
Exchange System Manager can only create folders that hold mail items, such as your Inbox and Sent Items folders, while Outlook can also create other types of folders such as Calendar items.
Figure 4
You can also create Public Folders using Outlook Web Access.
Figure 5
Public Folders have two types of security mechanisms administration and client access. Public Folder Administration security can only be set by Exchange System Manager. It allows you to decide which of the Exchange administrators have the right to manage security for the public folder and administrate the database (also called information store).
Figure 7
In most cases, in a small to medium company you would mostly need to set client permissions and not administrative rights. These can be set by the Outlook client and Exchange System Manager, but not the Outlook Web Access client.
Figure 8
Figure 9
The above screenshots show the default security settings for Public Folders. The owner of a public folder is the user who created it and gets full control of the folder. Authenticated users (designated here as Default) are granted the right to add items and delete their own items and anonymous users can add items but not read them. When creating a new public folder that you want a user to administer, you can simply add the user to the permission list and change the permission level to Owner.
Figure 10 The owner would be able to create subfolders for the folder you created and set further permissions on it.
MX Record
As long as the mail server is using SMTP as the e-mail transfer mechanism we need to configure the MX Records for our domain. MX is an acronym for Mail eXchange. It specifies the name and relative preference of mail servers for the zone. MX is a DNS record used to define the host(s) willing to accept mail for a given domain. I.e. an MX record indicates which computer is responsible for handling the mail for a particular domain. Without proper MX Records for your domain, only internal e-mail will be delivered to your users. External e-mail from other mail servers in the world will not be able to reach your server simply because these foreign servers cannot tell to which server they need to "talk" (or open a connection to) in order to send the mail destined for that domain.
You can have multiple MX records for a single domain name, ranked in preference order. If a host has three MX records, a mailer will try to deliver to all three before queuing the mail. MX Records must be in the following format: domain.com. IN MX 10 mail.domain.com.
The Preference field is relative to any other MX Record for the zone and can be on any value between 0 and 65535. Low values are more preferred. The preferred value is usually 10 but this is just a convention, not a thumb rule. Any number of MX Records may be defined. If the host is in the domain it requires an A Record. MX Records do not need to point to a host in the same zone, i.e. an MX Record can. point to an A Record that is listed in any zone on that DNS or any other DNS server When connecting your mail server to the Internet (or to another ex-organizational mailing system that uses SMTP) you must always make sure that the rest of the world can successfully resolve your domain's MX Record. Failing to do so will cause e-mail traffic not to be delivered to you. In order to properly configure your domain's MX Record you should contact your ISP (Internet Service Provider) or the party responsible for hosting your DNS Domain name. They will ask you for your FQDN (Fully Qualified Domain Name) and IP address of your mail server. Make sure you know them.
1.
Schema Master:
The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.
2.
The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest.
3.
Infrastructure Master:
When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain. Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.
4.
The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain. Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.
5.
PDC Emulator:
The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows 2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage. The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner. In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions: Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator. Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
Account lockout is processed on the PDC emulator. Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator. The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients. This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows 2000/2003 environment. At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.
Transfer the RID Master, PDC Emulator, and Infrastructure Master Roles
1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers. 2. Right-click Active Directory Users and Computers, and then click Connect to Domain Controller. NOTE: You must perform this step if you are not on the domain controller to which you want to transfer the role. You do not have to perform this step if you are already connected to the domain controller whose role you want to transfer. 3. Do one of the following: In the Enter the name of another domain controller box, type the name of the domain controller that will be the new role holder, and then click OK. -or In the Or, select an available domain controller list, click the domain controller that will be the new role holder, and then click OK.
4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Master. 5. Click the appropriate tab for the role that you want to transfer (RID, PDC, or Infrastructure), and then click Change. 6. Click OK to confirm that you want to transfer the role, and then click Close.
23 25 53 80 109 110 119 135 143 161 162 220 366 369 389 379 443 636 691 563 992 993 994 995 3268
Telnet. SMTP, Simple Mail Transfer Protocol. (Transmission Control Protocol [TCP], User Datagram Protocol [UDP]) - Domain Name System (DNS) to all DNS Servers listed in the front-end server's IP configuration. HTTP, HyperText Transfer Protocol. POP, Post Office Protocol, version 2. POP, Post Office Protocol, version 3. NNTP, Network News Transfer Protocol. Exchange 2003 RPC Applications uses TCP port 135 IMAP, Interactive Mail Access Protocol. SNMP, Simple Network Management Protocol. SNMP, Simple Network Management Protocol traps. IMAP, Interactive Mail Access Protocol, version 3. SMTP, Simple Mail Transfer Protocol. ODMR, On-Demand Mail Relay. rpc2portmap. LDAP, Lightweight Directory Access Protoco AND CLDAP, Connection-less Lightweight X.500 Directory Access Protocol. SRS in Exchange 2003 uses 379 for LDAP because 389 is locked by Windows Server for LDAP HTTPS, HTTP over SSL/TLS. For SSL authentication, the port that the Exchange Server computer listens Exchange Server uses 691 for Link State Table within the routing group NNTP over TLS/SSL (was snntp). telnet over TLS/SSL. imap4 over TLS/SSL. irc over TLS/SSL. pop3 over TLS/SSL (was spop3). (TCP) - LDAP to global catalog servers.
- Sending messages
When POP3 clients send messages, the Exchange Server computer is communicating with an SMTP (Simple Mail Transfer Protocol) host. This requires access to TCP port 25. The Internet Mail Connector and the Internet Mail Service use TCP port 25 for inbound SMTP messages as defined by RFC-821. For inbound SMTP messages, the Internet Mail Connector and Internet Mail
Service monitor port 25 for incoming connections from other SMTP hosts. Microsoft Exchange Server supports POP3 as defined in the RFC- 1734 and RFC- 1957 specifications
- Sending messages
As discussed above for POP3 clients sending messages, when IMAP4 clients send messages, the Exchange Server computer is communicating with an SMTP host. This requires access to TCP port 25. The Internet Mail Connector and Internet Mail Service use TCP port 25 for inbound SMTP messages as defined by RFC-821. For inbound SMTP messages, the Internet Mail Connector and Internet Mail Service monitor port 25 for incoming connections from other SMTP hosts. Microsoft Exchange Server supports IMAP4 as defined in the RFC-2060 and RFC- 2061.
An Exchange Client computer on a LAN or WAN link uses remote procedure call (RPC) to communicate with an Exchange Server computer. The Exchange Server computer, an RPCbased application, uses TCP port 135, also referred to as the location service that helps RPC applications to query for the port number of a service. The Exchange Server computer monitors port 135 for client connections to the RPC endpoint mapper service. After a client connects to a socket, the Exchange Server computer allocates the client two random ports to use to communicate with the directory and the information store. The client does not communicate with other components of the Exchange Server computer. If security concerns for a network infrastructure require blocking of any ports other than the ones used, then the random assignment of ports for communication with the directory and the information store can become a roadblock. To avoid this, Exchange Server versions 4.0 and later allow you to statically allocate these ports. At this juncture, for successful communication between client and server, the firewall needs to be configured to allow TCP connections to port 135 and all statically allocated ports. If you need to monitor traffic for analysis, these are the ports to monitor. Back to the top Communication between two Exchange Server computers in the same site All intrasite communication between Exchange Server computers uses RPC. Consequently, access to TCP port 135 becomes an important variable in the ability of Exchange Server computers to communicate if they are separated using routers and firewalls. Communication between two Exchange Server computers within a site is between the two message transfer agents (MTAs) and the two directory services. No other components of the Exchange Server computers communicate directly. As discussed above in client to server communication, an Exchange Server computer monitors port 135 for connections to the RPC endpoint mapper service. When an initiating Exchange Server computer connects to a socket, the receiving Exchange Server computer assigns two random ports to use to communicate with the directory and the MTA. Already discussed above was the possibility of static allocation of a TCP port for the directory to listen and communicate on a specific port number. With the release of Exchange Server 4.0 Service Pack 4 and all releases of Exchange Server 5.0, a similar adjustment can be made for the MTA. The endpoint mapper will then relay the appropriate port number, so that further communication can be achieved by going to the port number specified. For establishing a static allocation of port for the MTA, refer to the latter part of Knowledge Base article 161931 (http://support.microsoft.com/kb/161931/EN-US/), "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens." This explains the use of the registry value "TCP/IP port for RPC listens". Consequently, for successful communication between two servers, the firewall needs to be configured to allow TCP connections to port 135 and all statically allocated ports. If you need to monitor traffic for analysis, these are the ports to monitor. For more information about the ramifications and guidelines for static port assignment of Exchange services, please see the following article in the Microsoft Knowledge Base: 180795 (http://support.microsoft.com/kb/180795/EN-US/) XADM: Intrasite Directory Replication Fails with Error 1720 Back to the top Communication between two Exchange Server computers in different sites
- Intersite link uses site connector (RPC) Most of the discussion on intersite communication via site connectors mirrors the situation of intrasite communication between Exchange Server computers. The only difference is that communication between Exchange Server computers installed in two different sites is only via the corresponding message transfer agents (MTAs). Although you continue to need the services of the RPC locator service and thereby port 135, the only adjustment you may need for static allocation of a port would be for the MTA. Again, refer to Knowledge Base article Q161931, "XCON: Configuring MTA TCP/IP Port # for X.400 and RPC Listens." This article discusses the use of the registry value "TCP/IP port for RPC listens". This feature is available with Exchange Server Service Pack 4 and all releases of Exchange Server 5.0. - Intersite link is an X.400 connector If the intersite link is an X.400 connector, then the communication between the two Exchange Server computers continues to be between corresponding MTAs only. However, RPC is not the means of such communication. Communication between the MTAs follows the RFC1006: ISO over TCP/IP. Consequently Exchange Server computers, by default, use TCP port 102 for all such communication between the MTAs. There is no need for TCP port 135 as far the Exchange communication is concerned, because no RPC traffic is involved. Exchange Server Service Pack 4 and all releases of Exchange Server 5.0 provide the ability to change this default port assignment of port 102. Article 161931 (http://support.microsoft.com/kb/161931/EN-US/), referred to above, discusses the use of the registry value "RFC1006 Port Number". In this setting, for successful communication between two servers, the firewall must be configured to allow TCP connections to TCP port 102 or the manually assigned replacement port. If you need to monitor traffic for analysis, these are the ports to monitor. IMPORTANT: If the port number for RFC1006 is changed from the default value of 102 on one server, then it is absolutely essential that all servers communicating via the X.400 connector incorporate this change. All MTAs must use the same port number.
Naming context
It is a self-contained section of a directory hierarchy that has its own properties, such as replication configuration and permissions structure. Active Directory includes the domain, configuration, and schema naming contexts. Exchange Server 5.5 also uses naming contexts; Organization, Address Book Views, Site, Configuration, and Schema.
Namespace
It is a logical collection of resources that can be managed as a single unit. Within Active Directory, a domain defines a namespace.
Security principal
It is a user who can log on to a domain and have access to network resources. In Active Directory, a user object is a security principal. A non-security principal is an object represented in Active Directory that cannot access resources within the enterprise. User Principal Name UPN A multi-valued attribute of each user object that the system administrator can set. A UPN allows the underlying domain structure and complexity to be hidden from users; for example, although 50 domains may exist within a forest, users would seamlessly log on as if they were in the same domain. For consistency purposes, system administrators can make the UPN and users SMTP address the same. A user can log on to Active Directory through a number of different methods: a. By specifying the user name and domain name b. By using the convention of username@domain-name in the user box c. By using his or her UPN, such as e-mailalias@microsoft.com
9. The sending server looks up the recipients mailbox in Active Directory, conducts a DNS lookup for the mail exchanger MX record associated with the destination server on which recipients mailbox is stored. 10. TCP port 25 Connection to desination server. 11. Message transmitted to destination. 12. Exchange Store Driver 13. Information Store 14. Client receive the message
D. To Foreign Domain
1. 2. 3. 4. 5. 6. 7. 8. Clients submit the message Goes to Information Store Message passed Precategorization queue Message Categorizer Post Categorizer Routing Engine Creates a Outgoing SMTP message Queue SMTP Service reads out the message of this queue and sends it tover TCP port 25 to SMTP server. 9. Delivered to Foreign Domain.
Figure 4.2 Sending messages from Exchange 2003 to a remote SMTP host
Information Store (Store.exe) The Microsoft Exchange Server Information Store (Store.exe) is the end point for e-mails sent to users on this server. It is also the start point for e-mails which are sent by MAPI clients, like Microsoft Outlook 2003, which directly connect to the MSExchangeIS.
EXIPC is responsible for Data Transfer between Internet Information Server 6.0 (IIS) and the Microsoft Exchange Server Information Store (MSExchangeIS). EXIPC provides a layered service between both components to achieve the best possible performance between IIS
dependant components and the Exchange databases. As you might know, all Internet Client Access Protocols like HTTP/S, SMTP, POP3 and IMAP4 are configured and managed by IIS with some exceptions.
Figure 2: EXIPC Layer This interaction allows Exchange to be in a FrontEnd, and BackEnd, Server scenario. Through Virtual Servers, multiple configurations of the same protocol can exist on a single Exchange Server
implemented as an Event Sink. The Message Categorizer is also responsible for splitting messages into RTF or MAPI.
Routing Engine
The Exchange Routing Engine uses Link State information for e-mail routing. The Routing Engine will forward this information to the Advanced Queuing Engine. Please note: The SMTP Stack from Windows Server 2003 will be extended through the Exchange Server installation process with several enhancements. One of these enhancements is the implementation of the XLINKSTATE protocol. The Routing Engine creates and maintains the Link State information for every Exchange Server and is also responsible for routing the messages to inbound or outbound destinations.
SMTP Service
The SMTP Service processes incoming traffic from any SMTP host. SMTP is also used in most communications between Exchange Servers (except Exchange 5.x Servers which use RPC for message transferring). SMTP is also responsible for some advanced Exchange Server functions like Message Journaling. During the Exchange installation, the built in SMTP Serivce from Windows Server 2003 will be extended with several new functions. Some of the Enhancements are: Moving the Message Queue Directories to the Exchange installation Directory Providing support for the LSA (Link State Algorithm) in SMTP Moving SMTP Messaging from IIS to the Exchange System Manager
Because understanding the e-mail message flow is important, I will list some high level steps in the message flow: MAPI client sends a message to a remote recipient Information Store (Store.exe) receives the message The created MailMsg object is forwarded to the Advanced Queue Engine (AQE) The Message Categorizer from the AQE processes the MailMsg object and splits it into MIME or RTF as necessary The Message Categorizer expands groups and checks defined Message limits on Exchange The MailMsg object is then transferred to the Remote Destination Domain within the AQE The AQE passes the destination address to the Exchange Routing Engine SMTP initiates an SMTP session with the remote SMTP host After the SMTP session with the remote host has been established, the information store retrieves the body of the message and converts the message as necessary SMTP sends the Message from the Queue to the Remote Host
The following Exchange Features require the use of SMTP: Intra Server Message Delivery Inter Server Message Delivery Message Delivery to the Internet Exchange of Routing Information
Intra Server Message Delivery SMTP will be used for Intra Server Message Delivery for several components like Message Journaling and Message categorization. Exchange Servers in the same Routing Group use SMTP to communicate with each other. Message delivery to the Internet SMTP is often used to deliver e-mail to other exchange organizations or other messaging systems. Exchange Server 2003 can use the Virtual SMTP Server to deliver messages, or one or more Exchange SMTP Connectors or Routing Group Connectors. Exchange of Routing Information SMTP is also used to exchange Link State information between routing groups Relaying SMTP Relaying occurs when one SMTP host forwards e-mail to another SMTP host. Open SMTP relaying occurs when the SMTP host accepts messages from recipients outside the organization and forwards the messages to other recipients that are also outside the organization.
Figure 4: Relaying
If the Exchange Server allows everyone without authentication to deliver messages, the server is called an Open Relay. Open Relays can be used to send UCE (Unsolicited Commercial E-Mail). By default Exchange Server 200x is not an open relay. The following steps describe the process: The unauthorized user sends an e-mail message to the SMTP Server and addresses multiple recipients in the message. The recipients in the e-mail are in domains external to the Exchange Server's Messaging Organization. The Exchange Server accepts the Message. After Exchange has accepted the message, Exchange delivers this message to an outside SMTP host because there is no match in the recipient policies in the exchange organization.
Queues - If you are looking for e-mail messages which were not delivered to their recipients,
one of the first places to look to see where the Message has gone is the Queue Viewer. You can find the Queue Viewer in the Exchange System Manager directly under the Server Node. There are several Queues of interest and you should have a look at the state of the Queues and the number of messages in the Queue. If there are any messages in the Queue, you can select the Queue and you will see more information about possible problems in the info pane. If you right click the Queue you can force a connection if the problem is only temporarily.
DSN messages pending submission This folder contains Delivery Status Notifications awaiting delivery. Its primarily used for NDRs Non Delivery Reports. Failed message retry queue Contains outbound messages which couldnt be delivered to their destination but will be given another attempt. Local delivery Contains inbound messages for delivery to mailboxes on the Exchange server. Messages awaiting directory lookup Contains inbound messages awaiting recipient lookup in Active Directory. Messages pending submission Contains messages accepted by the SMTP virtual server, but havent yet been processed. Messages queued for deferred delivery Contains messages queued for deferred delivery (later time). Messages waiting to be routed Contains outbound SMTP/X400 messages still waiting to be routed to their destination server, when it has been determined the message will be sent.
For Troubleshooting reasons it is also possible to Stop all Outbound Mail if you click the Symbol in the Queue viewer. Please note that in the picture above Outgoing Mail has already been stopped. Outbound e-mail delivery was stopped for the purposes of this article so that some Messages in the Queues can be easily shown.
SMTP Logging
With Exchange Server 2003 it is possible to use extended SMTP Logging for troubleshooting purposes. If SMTP Logging is enabled, Exchange will write every outgoing mail through SMTP in a special logfile located by default in \Windows\System32\Logfiles\SMTPSVC1 where SVC1 is the first Virtual SMTP Server. You must enable this feature in the Exchange System Manager under the potocol container from the Exchange Server object.
Diagnostic Logging must be enabled in the Exchange System Manager under the Exchange Server object. After enabling the Diagnostic Logging feature the Event Viewer can be analyzed for specific problems.
Message Categorizer
Message Caterorizer retriews attributes from the active directory and it apply those attributes to message. For example: It checks size limits for incoming as well as outgoing messages, check delivery restrictions, forwarding specifications, any restrictions settings, adding disclaimer, running an antivirus program.
A special Connection Agreement implemented as part of the Active Directory Connector that replicates configuration naming context data from downlevel Exchange 5.x sites to administration groups in Active Directory and vice versa. ConfigCAs work in conjunction with the Site Replication Service.
Connection Agreement
It is the configuration of information to replicate using the Active Directory Connector. Configuration information includes the servers that participate in the replication; which object classes (mailbox, custom recipient, distribution list and user, contact, and group) to replicate; containers and organization units to use for object placement; and the activity time schedule.
Distributed Authoring and Versioning DAV (also known as HTTP-DAV and Web-DAV)
Its an extension to the Hypertext Transfer Protocol 1.1 (HTTP/1.1) that allows for the manipulation (reading and writing) of objects and attributes on a Web server. Exchange 2000 natively supports WebDAV. Although not specifically designed for the purpose, DAV allows for the control of data using a filing system-like protocol. DAV commands include Lock, Unlock, Propfind and Proppatch.
Event sink
It is a piece of code that is activated by a defined trigger, such as the reception of a new message. The code is normally written in any COM-compatible programming language such as Visual Basic, VBScript, JavaScript, C, or C++. Exchange 2000 supports the following event sinks: Transport Protocol Store Event sinks on the store can be synchronous (code executes as the event is triggered) or asynchronous (code executes sometime after the event).
C:\Program Files/Exchsrvr/BIN/>ESEUTIL /? Microsoft(R) Exchange Server(TM) Database Utilities<BR/> Version 6.0<BR/> Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. DESCRIPTION: Maintenance utilities for Microsoft(R) Exchange Server databases. MODES OF OPERATION: Defragmentation: ESEUTIL /d <database name> [options] Recovery: ESEUTIL /r [options] Integrity: ESEUTIL /g <database name [options] File Dump: ESEUTIL /m[mode-modifier] <filename> Repair: ESEUTIL /p <database name [options] Restore: ESEUTIL /c[mode-modifier] <path name> [options] <<<<< Press a key for more help >>>>> D=Defragmentation, R=Recovery, G=Integrity, M=File Dump, P=Repair, C=Restore => DEFRAGMENTATION/COMPACTION: DESCRIPTION: Performs off-line compaction of a database. SYNTAX: ESEUTIL /d <database name> [options] PARAMETERS: <database name> - filename of database to compact OPTIONS: zero or more of the following switches, separated by a space: /b<db> - make backup copy under the specified name /t<db> - set temp. database name default: TEMPDFRG.EDB) /s<file> - set streaming file name (default: NONE) /f<file> - set temp. streaming file name (default: TEMPDFRG.STM) /p - preserve temporary database (i.e., don't instate) /o - suppress logo /i - do not defragment streaming file NOTES: 1) If instating is disabled (i.e., /p), the original database is preserved uncompacted, and the temporary database will contain the defragmented version of the database. RECOVERY: DESCRIPTION: Performs recovery, bringing all databases to a consistent state. SYNTAX: ESEUTIL /r (3 character logfile base name)[options] OPTIONS: zero or more of the following switches, separated by a space: /l<path> - location of log files (default: current directory) /s<path> - location of system files (e.g., checkpoint file) (default: current directory) /i - ignore mismatched/missing database attachments /o - suppress logo INTEGRITY: DESCRIPTION: Verifies integrity of a database. SYNTAX: ESEUTIL /g <database name> [options] PARAMETERS: <database name> - filename of database to verify OPTIONS: zero or more of the following switches, separated by a space: /t<db> - set temp. database name (default:TEMPINTEG704.EDB)
/s<file> - set streaming file name (default: NONE) /f<name> - set prefix to user for name of report files (default: <I>database</I>.integ.raw) /o - suppress logo NOTES: 1) The consistency-checker performs no recovery and always assumes that the database is in a consistent state, returning an error if this is not the case. FILE DUMP: DESCRIPTION: Generates formatted output of various database file types. SYNTAX: ESEUTIL /m<mode-modifier> <filename> [options] PARAMETERS: <mode-modifier> - an optional letter designating the type of file dump to perform. Valid values are: h - dump database header (default) k - dump checkpoint file l - dump log file or set of logs m - dump meta-data s - dump space usage <filename> - name of file to dump. The type of the specified file should match the dump type being requested. (eg. if using /mh, then <filename> must be the name of a database. OPTIONS: zero or more of the following switches, separated by a space: /v - verbose<BR/> /s<file> - set streaming file name (default: NONE) /t <table> - dump nodes for a certain table <dump modes mode only> REPAIR: DESCRIPTION: Repairs a corrupted or damaged database. SYNTAX: ESEUTIL /p <database name> [options] PARAMETERS: <database name> - filename of database to repair OPTIONS: zero or more of the following switches, separated by a space: /s<file> - set streaming file name (default: NONE) /t<db> - set temp. database name (default: TEMPREPAIR*.EDB) /f<name> - set prefix to use for name of report files (default: <database>.integ.raw) /i - bypass the database and streaming file mismatch error /g - run integrity check before repairing /createstm - create empty streaming file if the file is missing /o - suppress logo NOTES: 1) Repair does not run database recovery. If a database is in a "Dirty Shutdown" state it is strongly recommended that before proceeding with repair, recovery is first run to properly complete database operations for the previous shutdown. 2) The /i option ignores the signature mismatch error in the check phase if the database and streaming file do not match each other. The database and streaming file will receive new signatures in the repair phase. Without using this option, repair will terminate immediately once the database and streaming file mismatch error occurs. 3) The /g option pauses the utility for user input before
repair is performed if corruption is detected. This option overrides /createstm and /o options. 4) The /createstm option is irreversible. Once you start the repair process a new streaming file will be created. Any streaming file that existed before the repair will no longer work with this database.
Event Service
A Windows NT service that is installed by Exchange Server 5.5. This service allows programmers to write programs that use Exchanges Event Handler to process events that occur in a Public Folder or Mailbox. Hosted organization (also known as virtual server, virtual machine, virtual organization)
A collection of Exchange services including, but not limited to virtual servers (that is, instances of IMAP4, SMTP, POP3, NNTP, HTTP, RVP), storage space, and real-time collaboration facilities that exist to serve the needs of a single company. A hosted organization is normally used by Internet Service Providers to host multiple companies on the same physical computer. However, a hosted organization is not limited to a single server running Exchange 2000.
MDB
An instance of a database implemented in Exchange server. A single MDB is normally identified as being public or private depending on the type of data that it stores. A single server running Exchange 2000 can accommodate up to 20 active MDBs.
Metabase
Metabase is a store that contains metadata such as that used by Internet Information Server IIS to obtain its configuration data. The metabase can be viewed through utilities such as Metaedit.
OLE DB
An Application Programming Interface (API) that allows low-level programming languages such as C and C++ to access dissimilar data stores through a common query language. OLE DB is seen as the replacement for Open Database Connectivity (ODBC). Data stores such as those in Exchange 2000 and SQL Server allow for OLE DB access, which makes application development easier and faster. High-level programming languages such as Visual Basic can use ActiveX Data Objects (ADO) to issue queries through OLE DB
Outlook Web Access Basic Outlook Web Access Basic is designed to work in browsers that support the HTML 3.2 and the European Computer Manufacturers Association (ECMA) script standards. It provides a subset of the features available in Outlook Web Access Premium.
New Features
Logon / Logoff improvement New user interface improvements like colors, display, toolbar etc. View improvement like reading pan, auto-preview, mail icons, items per page etc. Navigation improvements like navigation pan, search folders, notification, public folders, logoff option on toolbar etc. Mail workflow improvement like spelling checker, global address list properties sheets, add to contacts, auto signature, default mail editor, read receipts, attachment blocking junk email filtering, Rules improvement like user can create server based rules Task improvement like user can create and manage personal tasks and receive reminders for these items. Calendar improvement like users can not reply to sender of meeting requests or forward meeting to other users. Performance improvement.
Protocol farm
A collection of virtual servers that are used as the primary connection point for users in an organization. The farm abstracts the connection protocols from the location of the back-end data, which allows users to access information without having to know its physical location.
Public folder tree (also known as public folder root and top level hierarchy TLH)
A collection of public folders created under the same hierarchical namespace. Previous releases of Exchange server used only a single tree (called: All Public Folders), whereas multiple trees can be defined in Exchange 2000. Each tree is a unit of hierarchy replication and can be replicated to one or more Public MDBs. A Public MDB can host only one tree. Messaging Application Programming Interface (MAPI) clients such as Outlook can only access a single tree called All Public Folders, whereas other clients such as a Web browser or a networking client using the Microsoft Web Storage System can access any tree that is defined.
for accessing mailboxes and public folders, and servers running Exchange 2000 communicate with the Exchange Server 5.x Message Transfer Agent (MTA) using RPC (in a mixed-vintage organization).
Resource mailbox
A mailbox that is associated with a resource instead of a user (such as a conference room for reservation purposes). In Exchange 5.5 one user (Windows security principal) may have had several mailbox accounts associated with it such as a receptionist with a personal mailbox and a conference room mailbox associated. In Exchange 2000, there must be a one-to-one correspondence between a Windows 2000 security principal and a mailbox. Consequently, Exchange 5.5 resource mailboxes must have a Windows 2000 security principal (usually with no logon rights) associated with it, and a resource mailbox owner (with their own personal mailbox) is given delegated access to the resource mailbox.
Public Calendar
A public calendar is also a useful tool. It can also save you money, because unlike a dedicated mailbox, a public folder doesnt require a license. You can have as many public folders as you like. So, instead of creating a mailbox enabled user in Active Directory for scheduling meetings in, say, a meeting room, you can simply create an accessible public calendar folder. Unfortunately, public calendar folders are not published in the free/busy folder, so you cant really do advanced scheduling with these folders.
Figure 16 If you use Outlook 2003, after adding a folder to the public folder favorites you will be able to access it using the regular sections without the need to browse all the way to the folder list.
Figure 17
If you have public calendar favorites, you will be able view them side by side to determine which calendar is free and compare them to your own calendar.
Figure 18 You can also modify your Exchange account in Outlook 2003 Cache mode to download public folder favorites so they are automatically available offline. From the Outlook menu choose Tool > E-mail Accounts > Exchange Server Settings > More Settings > Advanced.
Figure 19
80 88
123
front-end server. This is not required for Windows 2000 logon capability, but it may be configured or required by the network administrator. 135 389 (TCP) - EndPointMapper to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (TCP, UDP) - Lightweight Directory Access Protocol (LDAP) to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (TCP) - Server message block (SMB) for Netlogon, LDAP conversion and Microsoft Distributed File System (DFS) discovery to all domain controllers that are in the same Active Directory site as the Exchange front-end server. (TCP) - LDAP to global catalog servers.
445
3268
Connectors for Lotus cc:Mail and MS Mail The Connector for Lotus cc:Mail and Connector for MS Mail components are not supplied with Exchange 2003. Using Exchange 2003 System Manager to manage MS Mail or cc:Mail connectors on Exchange 2000 servers is not supported. If you need to manage these connectors, use the Exchange 2000 SP3 or later version of System Manager. If you want to upgrade an existing Exchange 2000 server to Exchange 2003 and either of these connectors is installed, you must use the Exchange 2000 Setup program to remove the connector before upgrading. If you want to retain these services in your organization, you should not upgrade the Exchange 2000 servers that are running these components. Instead, you should install Exchange 2003 on other servers in your organization. Real-time Collaboration Features Exchange 2000 supports numerous real-time collaboration features such as chat, Instant Messaging, conferencing (using Microsoft Exchange Conferencing Server), and multimedia messaging (also known as unified messaging). These features have been removed from Exchange 2003. A new dedicated real-time communications and collaboration server (currently under developmentcode-named Greenwich) will provide these real-time collaboration features. M: Drive The Exchange store (which uses the \\.\BackOfficeStorage\ namespace) has traditionally been mapped to the M: drive on an Exchange server. M: drive mapping provided file system access to the Exchange store. The M: drive is disabled, by default, in Exchange 2003. You can still use the file system to interact with the Exchange store, but you must enter the path directly using the \\.\BackOfficeStorage\ namespace. For example, to view the contents of the mailbox store on an
Exchange server in the mail.adatum.com domain, you would type the following at a command prompt: dir \\.\BackOfficeStorage\mail.adatum.com\mbx The reason for removing the M: drive mapping is because, in some cases, the mailbox store would become corrupted from file system operations, such as running a file-level virus scanner on the M: drive or running file backup software on the drive. Key Management Service Exchange 2000 includes Key Management Service, which works with Windows 2000 Certificate Services to create a public key infrastructure (PKI) for performing secure messaging. With PKI in place, users can send signed and encrypted messages to each other. Exchange 2000 Key Management Service provides a mechanism for enrolling users in Advanced Security, and manages key archival and recovery functions. Exchange 2003 no longer includes Key Management Service. Exchange 2003 supports standard X.509v3 certificate implementation, and works with PKI solutions that support X.509v3 certificates. For example, you can use the PKI included with Windows Server 2003 in place of Key Management Service. Specifically, Windows Server 2003 PKI includes the ability to manage the key archival and recovery tasks that are performed by Key Management Service in Exchange 2000.
This protocol allows remote Outlook 2003 clients to connect to Exchange 2003 Servers using HTTP or HTTPS. The RPC protocol commands and data are "wrapped" (as known as encapsulated) in an HTTP header. The firewall in front of the Outlook 2003 MAPI client only sees the HTTP header and passes the outbound connection through. The RPC over HTTP protocols allows your remote users to get around what might be considered an overly zealous approach to outbound access control.
The Outlook 2003 client connects to an RPC over HTTP proxy server. The RPC over HTTP proxy server can be a front-end Exchange Server running IIS 6.0 on Windows Server 2003, or the RPC over HTTP proxy server can be a machine running the IIS 6.0 RPC over HTTP proxy service on a machine that is not configured as a front-end Exchange Server. The Outlook 2003 client only needs to connect to a Windows Server 2003 machine configured as a RPC over HTTP proxy. An example of such a configuration is shown in the figure below.
Que: Is there option to install Exchange 2003 on Windows 2003 64 Bit Edition?
Ans: Exchange 2003 cannot be installed on Windows 2003 64 Bit. The major reason for this limitation is that the Installable File System (ExIFS) driver runs under 32-Bit Kernel mode. Exchange Server 2003 doesn't include an Installable File System (ExIFS) 64-Bit driver version. Running 32 Bit Kernel mode drivers under 64 Bit Windows 2003 is not supported.
The system can use either SSP to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection and the preferences of the individual application that is being used. The Microsoft SSPI is the foundation for authentication in Windows Server 2003. That is, applications and infrastructure services that require authentication use SSPI to provide it. Windows Server 2003 implements the Kerberos V5 authentication protocol as a Security Support Provider (SSP), a dynamic-link library (DLL) supplied with the operating system. Windows Server 2003 includes an SSP for NTLM authentication as well. By default, both SSPs are loaded by the Local Security Authority (LSA) on a Windows Server 2003 computer when the system boots. The system can use either SSP to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection and the preferences of the individual application that is being used. The Microsoft SSPI is the foundation for authentication in Windows Server 2003. That is, applications and infrastructure services that require authentication use SSPI to provide it.
Kerberos SSP
Windows Server 2003 implements the Kerberos V5 authentication protocol as an SSP, a DLL supplied with the operating system. The system uses the Kerberos SSP, Kerberos.dll, as its first choice for authentication. After the LSA establishes a security context for an interactive user, another instance of the Kerberos SSP can be loaded by a process running in the user's security context to support the signing and sealing of messages. Because the Kerberos protocol is the preferred authentication protocol for Windows Server 2003, all domain services support the Kerberos SSP, including: Active Directory queries using the Lightweight Directory Access Protocol (LDAP) Remote server or workstation management using RPC calls Print services Client-server authentication Remote file access using the Common Internet File System/Server Message Block (CIFS/SMB) Distributed file system management and referrals
Intranet authentication to Internet Information Services (IIS) Security authority authentication for Internet Protocol Security (IPSec) Certificate requests to Certificate Services for domain users and computers
The Difference between a Mailbox enabled recipient and a Mail enabled recipient?
A Mailbox enabled recipient can log on to network resources and can access domain resources. Users can be added to groups and appear in the global address list. Mailboxenabled recipients can send and receive messages and store messages on their Exchange server mailboxes. You can use mailbox enabled recipients for all aspects and functions in Exchange Server 2003. A Mail enabled recipient can receive messages only at an external e-mail address. The mail enabled recipient cannot send or store messages on Exchange message stores. A mail enabled user has an account in Active Directory but no Exchange mailbox. A mail enabled user is listed in the global address list. This enables other users to easily locate and send email to a mail enabled user even if the account does not have a mailbox in the Exchange organization. For example, you may create a mail enabled user for onsite contract employees who require access to the network but who want to continue receiving their e-mail through their Internet service provider.
The Difference
POP3 works by reviewing the inbox on the mail server, and downloading the new messages to your computer. IMAP downloads the headers of the new messages on the server, then retrieves the message you want to read when you click on it. When using POP3, your mail is stored on your PC. When using IMAP, the mail is stored on the mail server. Unless you copy a message to a "Local Folder" the messages are never copied to your PC. Scenarios of Use POP3 You only check e-mail from one computer. You want to remove your e-mail from the mail server. IMAP You check e-mail from multiple locations.
Similarties:
Handle mail access only; relying on SMTP for sending. Rely on mail delivery to a, usually shared, "always up" mail server. Allow access to new mail from a variety of client platform types. Allow access to new mail from anywhere on the network.
Fully support the offline (download and delete) access model. Support persistent message identifiers for disconnected use. Have freely available implementations (including source) available. Have client implementations available for PCs, Macs, and Unix. Have commercial implementations available. Are open protocols, defined by Internet RFCs. Are native Internet protocols; no mail gateways required.
HTTPS is conducted over a Secure Socket Layer (SSL) connection. This encrypts your data for optimal security. Standard HTTP login transfers your data over the Internet like a standard Web page. Most Web-based e-mail accounts are limited to this format. The advantage of using the Standard HTTP is that it is faster than the Secure HTTPS.
About ESEutil
ESEutil checks and fixes individual database tables but does not check the mail data contained in the Extensible Storage Engine (ESE) database. Object-oriented databases like Microsoft Exchange consist of big, structured sequential files connected by a set of indexes. The underlying database technology that controls these files is called Indexed Sequential Access Method, or ISAM. The ESE database engine exposes the flat ISAM structure as a hierarchy of objects. The function of ESEutil is to examine these individually indexed object pages, check them for correctness by comparing a computed checksum against a checksum stored in the page header, and verify that each page's data is consistent. ESEutil isn't for casual use. So, don't use ESEutil unless you absolutely need to run it and you understand what it does. To understand ESEutil, you need to know about the format of the ESE database in which ESEutil works and you need to be familiar with ESEutil's many modes of operation. ESEutil is a useful tool because it can operate in many modes. Each mode, however performs different functions with limitations or caveats. Defragmentation: ESEutil /d [options] Recovery: ESEutil /r [options] Integrity: ESEutil /g Repair: ESEutil /p [options] Checksum: ESEutil /k [options] The way that each of these functions is executed within the utility is to use a cryptic MS-DOS-like command structure as the parameter qualifier. For example, in order to run the defragmenter portion of the utility, an administrator would run ESEutil /d [options] and so on. We are not going to attempt to cover all the potential pitfalls with ESEutil, however, here are a few major issues regarding ESEutil to keep in mind: There are times when it is appropriate to use ESEutil on its own, however, a complete maintenance process includes the combined use of specific ESEutil and ISinteg commands, as well as other steps that must be undertaken. ESEutil is very powerful tool and, if the commands are entered improperly or in an incorrect order, the results can be catastrophic. The ESEutil command structure can be very confusing and, at times, misleading. Changing one letter in the command structure executes a completely different utility function, and the results to an Exchange database can be disastrous. Below are a few of the many different available modes and options for ESEutil, each of which can have very different results on a database. NOTE: For brevity we have not included entire command statements. - ESEutil /d will defragment the designated database and is a fairly straight forward mode of operation that is commonly used. Running a manual offline defragmentation is only part of the process that should be completed in order to keep the databases healthy. Many administrators run ESEutil on a database to remove deleted items and regain white space then, mistakenly assume that by doing so, the process is complete. Performing this task, however, doesn't check or address issues that may exist within the mail data itself, and it won't fix the links between the tables of an ESE database. The database now contains a higher percentage of errors, warnings, and minor inconsistencies than it did prior to defragmentation. NOTE: Running ESEutil repeatedly without implementing a complete offline maintenance process is certain recipe for disaster. - ESEutil /d /p will have a slightly different result. The /d tells ESEutil to defragment the designated database. The /p option used with the /d instructs ESEutil to leave the newly created defragmented database in the temporary work area and not to overwrite the original database. - Now slightly modify the command to ESEutil /p and the actions taken on the designated database are extremely different. The /p evokes the Exchange Repair mode. At first glance
this sounds like a great thing to do, and it couldnt hurt to try because repairing the database should be beneficial right? Wrong! This command actually invokes a Hard Repair mode of ESEutil. This means that ESEutil will attempt to repair corrupt pages, but it makes no attempt to put the database in a consistent state. If it finds problems that cannot be corrected, then those pages will be discarded. Each page contains data therefore each discarded page represents data loss. Discarding certain pages of the database can actually render it useless. In other words, wave goodbye to your data. Sometimes, using the repair mode is the only way to fix a database. In the vast majority of situations, however, it should be avoided except as a last resort and there are specific steps that should be taken pre and post use of Repair /p mode.
About ISinteg
The purpose of the Microsoft ISinteg utility is to inspect and fix weaknesses within the information store (IS). ISinteg looks at the mailboxes, public folders, and other parts of the IS, checking for anything that appears to be out of place. ISinteg scans the tables and Btrees that organize the ESE pages into their logical structures. In addition, the tool looks for orphaned objects, or objects that have incorrect values or references. Because ISinteg focuses on the logical level rather than physical database structure, it can repair and recover data that ESEutil can't. When looking at the physical database level, ESEutil might find the data to be valid because it looks for things such as page integrity and B-Tree structure. Data that appears valid to ESEutil from a physical view of the database might not be valid from a logical view. For example, data for various IS tables like the message, folder, or attachments table may be intact, but the relationships among tables or records within tables may be broken or incorrect because of corruption in the logical structure. This corruption can render the database unusable. Logical corruption of your Exchange Server databases is problematic and much more difficult to diagnose and repair than physical corruption. The user and administrator are, typically, unaware of a logical corruption occurrence. No specific symptoms identify logical corruption. Often, when an administrator discovers the logical corruption, it's too late for any repairs to take place. You can run ISinteg one of two ways: Default mode, in which the tool runs the tests you specify and reports its findings. Fix mode, where you specify optional switches instructing ISinteg to run the specified tests and attempt to fix whatever it can. The most important thing about running ISinteg is to run the command until it no longer reports any problems. Just running the command once does not guarantee that the information store is functioning properly. Depending on the size of the information store, the process can take a long time, however, it ensures that the databases are properly functional
The Client Access Server can be configured for internal access or can be Internet-facing named "First CAS". If there is no Internet-facing Client Access Server in the same site as the mailbox, then the request will be proxied from the Internet-facing Client Access Server to the internal Client Access Server named "Second CAS". All the traffic between First CAS and Second CAS is over http(s). Note: By default Exchange 2007 installs a self certificate when you install the Client Access Server role. As a recommendation you should install a public or a private certificate. Proxying is supported for clients that use Outlook Web Access, Exchange ActiveSync, Exchange Web Services, and the Availability service.
An Exchange 2007 Client Access Server can proxy requests in the following two scenarios: Between Exchange 2007 Client Access Servers Organizations that have multiple Active Directory sites can designate one Client Access Server as an Internet-facing server, named "First CAS", and have that server proxy requests to Client Access Servers in sites that have no Internet presence, named "Second CAS". The First CAS then proxies the request to the Client Access Server that is closest "Second CAS" to the user's mailbox. This is known as CAS-CAS proxying as we can in see the following illustration:
The mailbox of User2 is located on a mailbox server MBX2 in a remote active directory site without presence on the Internet. When the User2 accesses his mailbox via OWA or ActiveSync, the First CAS which is present on the Internet receives the request and then proxies to the Second CAS in the same AD site where the User2 mailbox is located. Note: Integrated Windows authentication for /owa virtual directory must be enabled via Exchange Management Console or Exchange Management Shell on the Second CAS. For /Microsoft-Server-ActiveSync virtual directory on Exchange 2007 SP1, you can enable via Exchange Management Shell via cmdlet Set-ActiveSyncVirtualDirectory. Between an Exchange 2007 Client Access Server and an Exchange Server 2003 Back-end server Proxying requests between an Exchange 2007 Client Access server and a Microsoft Exchange Server 2003 frontend server enables Exchange 2007 and Exchange 2003 to coexist in the same organization. External clients who connect to Outlook Web Access by using the /Exchange virtual directory or connect to Exchange ActiveSync by using the /Microsoft-Server-ActiveSync virtual directory will have their requests proxied to the appropriate Exchange 2003 back-end server (click to see a bigger version):
The above illustration presents the scenario where the mailbox of User2 is located on Exchange 2003 back-end server in an Active Directory remote site. When the User2 access his mailbox via OWA or ActiveSync, the First
CAS proxies the request not to the Second CAS or any Exchange 2003 front-end server but straight to the Exchange 2003 back-end server via http where the user mailbox is located. If the mailbox is located on a Exchange 2003 backend server in the same Active Directory site as the CAS, such as User1, the First CAS proxies the request straight to the Exchange 2003back-end server via http. Note: Integrated Windows authentication for /Exchange and /Microsoft-Server-ActiveSync virtual directories must be enabled via Exchange System Manager on Exchange 2003 back-end server. Proxying and Redirection both do not support virtual directories that use Basic authentication. For client communications to be proxied or redirected between virtual directories on different servers, Integrated Windows authentication must be turn on the Second CAS for /owa and /Microsoft-Server-ActiveSync, as well as on an Exchange 2003 back-end server for the virtual directories /Exchange and /Microsoft-Server-ActiveSync. Note: CAS-CAS Proxying will not work for Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4 (IMAP4) clients. A client who is using POP3 or IMAP4 must connect to a Client Access server in the same Active Directory site as their Mailbox server. If the user mailbox is located on a Exchange 2003 backend server, POP3 and IMAP4 request will be proxied from CAS to Exchange 2003 back-end server. Understanding CAS Redirection Redirection is used when the organization has multiple Exchange 2007 Client Access Servers, in different Active Directory sites, facing to the Internet with the ExternalURL attribute enabled. Outlook Web Access users who access an Internet-facing Client Access server that is in a different Active Directory site than the site that contains their mailbox can be redirected to the Client Access server that is in the same site as their Mailbox server if that Client Access server is Internet-facing. When Outlook Web Access users try to connect to a Client Access server that is outside the Active Directory site that contains their Mailbox server, they will see a Web page that contains a link to the correct Client Access server for their mailbox. The scenario bellow presents how redirection works for Outlook Web Access and ActiveSync users. The mailbox of User2 is located on a mailbox server MBX2 in a remote Active Directory site where the Second CAS is Internet-facing, the ExternalURL attribute is set on for /owa virtual directory. When the User2 accesses his mailbox via OWA pointing to the First CAS. The First CAS checks if the ExternalURL is configured on the Second CAS. In this case the First CAS will return a web page that contains a link to the correct Client Access server for their mailbox, in the case, the Second CAS in AD Remote site.
The mailbox of User2 is located on a mailbox server MBX2 in a remote Active Directory site where the Second CAS is Internet-facing, the ExternalURL attribute is set on for /Microsoft-Server-ActiveSync virtual directory. When the User2 accesses his mailbox via ActiveSync pointing to the First CAS, the First CAS checks if the ExternalURL attribute is configure on the Second CAS. In this case the First CAS will return an HTTP error code 451 and an application Event ID 1008. In this case, you have to recreate the partnership with the device pointing to the right Exchange 2007 Client Access Server. Note: Redirection is supported only for clients that use Outlook Web Access. Clients that use Exchange ActiveSync, Exchange Web Services, POP3, and IMAP4 cannot use redirection. In next two blog posts on the subject, I will cover how Exchange 2007 CAS Proxying works for ActiveSync and OWA clients.
How Exchange Server 2007 CAS Proxying works for Outlook Web Access (OWA). Proxying for Outlook Web Access is used when there is only one Internet-facing CAS Server. In this scenario the will be proxied to the CAS server where his mailbox server is located. This requires more intensive resource on the CAS server than doing redirection. The main benefit to this is your users can have a single point of access from external and proxying is transparent to the end user. CAS-CAS Proxying is quite similar with the process described in the future topic "How CAS proxying works for ActiveSync". There are a few differences regarding the errors and logs.
Please see the following flowchart that will help you understand this process. To view the full version, please click on the thumbnail. We wanted to publish the flowchart in high resolution:
1. The First CAS queries the Active Directory to determine the location of the user's mailbox and the version of Microsoft Exchange that is installed on the Mailbox server. If the mailbox is on Exchange 2007, the First CAS will determine the best CAS, a Client Access Server in the same AD site as the user's mailbox server. If the user's mailbox is on an Exchange 2003 server, the request will be proxied directly to the destination Exchange 2003 back-end server, even if there is an Exchange 2007 Client Access server within the destination Active Directory site. Windows Integrated authentication is required on Exchange 2003 /Exchange virtual directory. Once is determined where the user mailbox is located, in this case on a Mailbox Exchange 2007 Server named Chicago.fourthcoffee.com. The First CAS has already made the decision to talk directly to a mailbox server in the same site, proxy the request to the Second CAS or return a web page link with the ExternalURL from the Second CAS where the user mailbox is located. As the mailbox is on an AD remote site, the request is proxied to the Second CAS named Dallas.fourthcoffee.com. 2. If the First CAS itself is the best CAS for the request it will handle the request and initialize a mailbox session via RPC with the Exchange 2007 mailbox server. If it is an Exchange 2003 Server the communication will be via http(s) and Windows Integrated authentication is required on Exchange 2003 /Exchange virtual directory. If there is a Client Access server that is closer to the user's Mailbox server, Exchange 2007 determines whether the Client Access server has the InternalURL property configured on /owa virtual directory Exchange and if the authentication method is Integrated Windows authentication. If so, the user is proxied to the Client Access server specified by the InternalURL property. Otherwise will return an error message to the client if could not find the best CAS. Error: Outlook Web Access is not currently available for the user mailbox that you are trying to access. Please try again in a few minutes. If the problem continues, contact technical support for your organization and tell them the following: The available Microsoft Exchange Client Access servers in the target Active Directory site are not responding. If the Integrated Windows authentication is not set on the Second CAS, it will return an error message to the client.
Error: Outlook Web Access is not available. If the problem continues, contact technical support for your organization and tell them the following: There is no Microsoft Exchange Client Access server that has the necessary configuration in the Active Directory site where the mailbox is stored. 3. The server hosting https://dallas.fourthcoffee.com/owa may be configured not to allow Kerberos authentication. It might be set to use Windows Integrated authentication for the Outlook Web Access virtual directory, but be configured to only use NTLM (not Kerberos) authentication for Windows Integrated authentication. See the IIS documentation for additional troubleshooting steps if you suspect this may be the cause of the failure. 4. If the best CAS has an "ExternalURL" set on the /owa virtual directory, than then First CAS will return a web page link to the client with the ExternalURL from the Second CAS. 5. When attempting to connect to a proxy request, if the Second CAS returns a HTTP_441 response, it indicates that the second CAS did not have the CSC for the SID that was passed. The First CAS will obtain the CSC, serialized into XML and issues a proxy login request. Note: InternalURL is configured automatically during Exchange 2007 Setup. For Client Access servers that do not have an Internet presence, the ExternalURL property should be set to $null 6. The Second CAS initializes a new mailbox session to sync the user mailbox.
Stage 2 - Encryption verification When the ETP.DAT message arrives at the messaging server, the BlackBerry Messaging Agent which is monitoring the users mailbox checks the message contents. The BlackBerry Enterprise Server processes the data attached to the message, first verifying that the encrypted password matches the one set for the BlackBerry device user. So the password that was entered by the user is matched with the one that was set by the Administrator on the BES. If they match, then the BlackBerry Messaging Agent generates a new permanent encryption key using either Triple Data Encryption Standard (Triple DES) or Advanced Encryption Standard (AES) and sends it to the BlackBerry device. The BlackBerry device displays a status of Verifying Encryption. Stage 3 - Receiving services The BlackBerry Enterprise Server and the BlackBerry device now establish a master encryption key. The BlackBerry device and the BlackBerry Enterprise Server verify their knowledge of the master key to each other. The BlackBerry device implements the new encryption key and displays the following message: Encryption Verified. Waiting for Services. This key will be used to encrypt all data that is sent from the device to the BES infrastructure. The BlackBerry Messaging Agent forwards a request to the BlackBerry Policy Service to generate service books. The BlackBerry Policy Service receives and queues the request, and then sends out an IT policy update to the BlackBerry device. The BlackBerry device registers that the policy is applied successfully. The BlackBerry Policy Service generates and sends the service books to the BlackBerry device, which is now able to send messages and displays the Services Received status. The BlackBerry device then displays the following message: Your email address, <user@domain.com> is now enabled. Synchronization service Desktop [S<SRP_Identifier>]
Stage 4 - Slow synchronization Once the [CMIME] service book has arrived, the BlackBerry device will be able
to reconcile messages with the BlackBerry device user's email account. You can configure reconciliation as required. All the service books should arrive at the same time, but only the [CMIME] is required for email reconciliation. The BlackBerry device registers the receipt of its service books to the BlackBerry Enterprise Server and the activation process completes. The message Activation Complete is shown. The slow synchronization process begins with a BlackBerry device request, synchronizing data from the calendar first (using the [CICAL] service book) and then the other organizer databases with the BlackBerry device. For wireless synchronization to occur, the Desktop [SYNC] service book is sent to the BlackBerry device. The [SYNC] service book allows for organizer data synchronization, wireless backup and restore capability, and synchronization of email settings and filters. The process is managed by the BlackBerry Messaging Agent for the Calendar, and the BlackBerry Synchronization Service for the remaining organizer databases. The appropriate service books and IT policies are sent from the BlackBerry Enterprise Server to the BlackBerry device. The BlackBerry device user is now able to send and receive email messages on the BlackBerry device. If the BlackBerry device user is configured for wireless organizer data synchronization and wireless backup, the BlackBerry Enterprise Server will send the following data to the BlackBerry device: Calendar entries Address Book entries Tasks Memos Email messages Existing BlackBerry device options that were backed up through automatic wireless backup When the enterprise activation process is complete, the BlackBerry device displays a status of Activation Complete. Role of the ETP.DAT message in the enterprise activation process
Once the BlackBerry device user selects Activate in the Enterprise Activation application on the BlackBerry device, the following actions occur: The ETP.DAT message is sent to the BlackBerry Infrastructure, which forwards
it to the email address that was typed in the Enterprise Activation application. The BlackBerry Enterprise Server, which monitors the BlackBerry device users mailbox, picks up the ETP.DAT message. The activation process begins. The BlackBerry Enterprise Server sends the acknowledgement and encryption information to the BlackBerry device. The IT policy is sent to the BlackBerry device. Once the BlackBerry Enterprise Server verifies that the policy has been applied successfully, it sends the required service books to the BlackBerry device. When the BlackBerry Enterprise Server has sent all the required information to the BlackBerry device, the following message is displayed: Your email address <user@domain.com> is now enabled The slow synchronization process begins.
"The server is not responding. Please contact your system administrator" appears on the BlackBerry smartphone during the enterprise activation process
Overview During the enterprise activation process, the following error message appears indicating that the activation process failed: The server is not responding. Please contact your system administrator.
Cause
This issue might be caused by one of the following: 1. The activation password has not been set on the BlackBerry Enterprise Server.
2. The email address or password has been incorrectly entered on the BlackBerry smartphone. 3. The temporary password has expired. 4. The BlackBerry user's mailbox is full. 5. The ETP.DAT activation message is not arriving in the BlackBerry smartphone user's mailbox. 6. The BlackBerry smartphone does not have BlackBerry Enterprise Server and email transfer protocol (ETP) services turned on. 7. The BlackBerry smartphone is not assigned the BlackBerry Enterprise Server service class.
Resolution
Perform the appropriate resolution for the cause of the issue. Cause 1 The activation password has not been set on the BlackBerry Enterprise Server. Resolution 1 Set the activation password in BlackBerry Manager.
Cause 2 The email address or password has been incorrectly entered on the BlackBerry smartphone. Resolution 2 Have the BlackBerry smartphone user type the correct email address and password on the BlackBerry smartphone.
Five activation attempts failed. The BlackBerry smartphone was not activated within 48 hours after the password was created.
The BlackBerry smartphone user typed the password correctly once, but the enterprise activation process could not complete for reasons such as IT policy rejection or a cancelled activation.
Resolution 3 Create a new temporary password for the account in BlackBerry Manager.
Cause 4 The BlackBerry smartphone user's mailbox is full. Resolution 4 Clear the contents from the mailbox.
Cause 5 The ETP.DAT activation message has not arrived in the BlackBerry smartphone user's mailbox. Resolution 5 Make sure the messaging server is not filtering ETP.DAT attachments.
Cause 6 The BlackBerry smartphone does not have BlackBerry Enterprise Server and email transfer protocol (ETP) services turned on. Resolution 6 BlackBerry smartphone users with only BlackBerry Internet Service cannot activate the BlackBerry smartphone using the enterprise activation process.
Cause 7 The BlackBerry smartphone is not assigned the BlackBerry Enterprise Server service class. Resolution 7
Have the BlackBerry smartphone user contact the wireless service provider to request that BlackBerry enterprise services be assigned to the BlackBerry smartphone .