Exchange 2003 is the latest version of the extremely powerful, feature-rich, and popular client-server messaging application from

Microsoft. As Microsoft Windows networks and messaging requirements have evolved over time, so has Microsoft's flagship messaging and groupware product. With Exchange 2003, Microsoft has raised the bar by which any serious enterprise-level messaging and groupware application are measured. Exchange 2003 provides the following features to an organization: E-mail messaging using Microsoft Outlook 2003 and other POP3 (Post Office Protocol version 3) and IMAP4 (Internet Message Access Protocol version 4) clients. OWA (Outlook Web Access), which closely mimics the user experience of Outlook 2003 when Microsoft Internet Explorer 5.0 or later is used. Outlook Mobile Access, which replaces MIS (Mobile Information Server), and provides seamless Exchange access to mobile clients. Public folders, which support document sharing and collaboration and numerous third-party applications. Integrated administration and management capabilities that allow an entire enterprise Exchange organization to be easily managed from a single location or numerous locations as business requirements dictate. Delegated administrative responsibility, allowing the senior Exchange administrator to delegate responsibility for discrete portions of the Exchange organization to other administrators by job function or geographical location. Tight integration with Active Directory for increased security and reliability, simpler management and scalability. Multiple address lists that can be created and managed to fulfill specific business or security requirements within the organization. Highly available and redundant messaging system access through the use of NLB (Network Load Balancing) front-end clusters and MSCS (Microsoft Clustering Service) back-end clusters. Increased messaging security using RPC (Remote Procedure Call) over HTTP (Hypertext Transfer Protocol) for remote Outlook access, HTTP with SSL (Secure Sockets Layer) for remote OWA access and POP3 and IMAP4 with SSL for remote client access. Interoperability with foreign messaging systems, such as Lotus Notes, Novell GroupWise, X.400 systems, and Internet mail. Migration paths from numerous legacy and foreign messaging systems, such as Lotus Notes, Lotus cc:Mail, Novell GroupWise, X.400 systems, MS Mail, and previous versions of Exchange Server.

Exchange 2003 is more than just a fresh face and an updated name over its predecessor; it has a host of new and improved features that you'll find out about in this course. The changes in Exchange 2003 since the Exchange 2000 Server version can be broken down into three areas for easier digestion: What's new in Exchange 2003? What's improved in Exchange 2003? What's no longer supported in Exchange 2003?

Bear in mind, however, that this is just the tip of the iceberg. If you'd like to get a complete listing of what's new in Exchange 2003, be sure to visit the Microsoft Exchange Server Web site. This section covers the new features that Exchange 2003 offers over Exchange 2000 Server.

Query-based distribution groups One of the most time-consuming responsibilities an Exchange administrator faces daily is managing and maintaining distribution groups so their membership is always accurate. When users join or leave the organization or move to a different business unit or department, one or more distribution lists must be updated to reflect the changes. This distribution list management is expensive -- in both administrative time and effort, as well as the network traffic that ensues after a change has been made. Distribution and security groups are covered in more detail in Lesson 4. To help alleviate this problem, Exchange 2003 features an entirely new type of distribution group: the query-based distribution group. Query-based distribution groups have their group membership dynamically determined each time a message is sent to the group through the results of an LDAP (Lightweight Directory Access Protocol) query that's performed against Active Directory. Only those recipient objects that match the query parameters are returned; therefore, only those recipients receive a copy of the message that is sent to that distribution group. If a malformed LDAP query is specified, a user who sends a message to the query-based distribution group receives an NDR (Non Delivery Report); however, if the LDAP query returns an empty group (no matches made), no NDR is generated. More specifically, the query is performed against a Global Catalog server. This is important because not every attribute of an object is replicated to the Global Catalog; therefore, the LDAP query used to create a query-based distribution group must be created with this fact in mind. Although query-based distribution groups may sound like the end-all solution for distribution group management, note that the power and flexibility they provide does come with a price. Each time a message is sent to the group, the specified LDAP query must be run. This can potentially place a large demand on your Global Catalog servers and your network's data throughput capability. Proper design and forethought, however, can usually prevent these problems from becoming significantly detrimental. Recovery storage group As powerful and robust as Exchange Server is, data backup and recovery has consistently been one of its weak points. The new recovery storage group feature of Exchange 2003 aims to take a large bite out of that problem. Traditionally, when you needed to recover one or more stores within a single storage group, you had to dismount all stores within that storage group. When using the recovery storage group method of store restoration, the store is only dismounted for a short period of time (a few minutes or less typically) as the recovered store is mounted and made accessible to users. Compare this with the 30 or more minutes that you might spend performing a restoration of a store (depending on its size and how many backup tapes you need to use) and the benefits are very easy to see. The recovery storage group does have some usage limitations that you should be aware of: Public folder stores cannot be restored using the recovery storage group. The recovery storage group can only be used to recover mailbox stores. The server hosting the recovery storage group must be located in the same administrative group as the server from which the mailbox store was backed up. The storage group from which the mailbox store was backed up must be located on an Exchange 2000 Server Service Pack 3 (SP3) or later Exchange Server computer. Only one storage group may be restored at a time, although multiple mailbox stores within that storage may be restored simultaneously. Backups made using volume shadow copy (discussed next) cannot be restored using the recovery storage group.

Volume shadow copy One of the improvements in Microsoft Windows Server 2003 is support for the volume shadow copy technology, which was first introduced in Microsoft Windows XP. When performing backups using volume shadow copy, open files can be backed up as if they were closed, with their content current as of the time of the backup process. This allows for greater flexibility with scheduled backups and ensures that a higher percentage of your desired backup items are actually backed up. The volume shadow copy process, like the Windows Backup Utility itself, is extended when Exchange 2003 or the Exchange System Manager is installed on a computer -- be it a server or workstation. As nice as volume shadow copy is, it too has its limitations when used with Exchange 2003. For example, if your system files and Exchange databases are located on the same volume, you cannot backup both items at the same time.

Additionally, you cannot use volume shadow copy to create backups that you'll later want to restore using the recovery storage group. RPC over HTTP As good as Outlook Web Access is (and it's even better in Exchange 2003), there are many times when you'd still like to be able to connect remotely to the Exchange organization using Microsoft Outlook. In the past, this has been done using Microsoft or third-party created VPNs because there was no inherent security in this setup. When Exchange 2003 is used on the back-end with Outlook 2003, clients can now connect securely to the Exchange 2003 organization without the need for a VPN connection using RPC over HTTP. Standard RPC communications are not designed for use on the Internet and do not work very well with firewalls; however, when you tunnel RPC over HTTP, the remote user can easily create connections to a front-end server running IIS (Internet Information Services) via HTTP, and then connect to the Exchange servers using RPC. This scenario is supported regardless of how the client and server are located, even if they're both behind different firewalls on different networks. The only requirement is that RPC over HTTP must be configured on the client and server side in the Exchange organization and HTTP must be available for use. When RPC over HTTP is used to connect Outlook 2003 clients to Exchange 2003, use SSL for security because all authentication is done using basic authentication (which submits user's credentials in clear text). The complexity of setting up and maintaining an RPC over HTTP solution may not be right for every organization, especially those that already have mature, stable, VPN solutions in place, but it does provide another low-cost solution to this problem What's improved in Exchange 2003 Many improvements are found in Exchange 2003 over Exchange 2000 Server, including the removal of the KMS (Key Management System), which is discussed in the following section, increased security, better performance, and easier management. In this section, you briefly examine one of the more predominant improvements that your users will appreciate. Outlook Web Access On the client side, next to Outlook 2003, OWA in Exchange 2003 has seen the biggest improvement over its counterpart in Exchange 2000 Server. OWA is provided in two modes, Premium and Basic, depending on the user's browser and personal preferences. OWA Premium is available for use when clients connect to the OWA server using Microsoft Internet Explorer 5.01 or later and provides almost every feature available in OWA under Exchange 2003. Microsoft Internet Explorer 6.0 or later is still required for some of the most advanced features, such as automatic credential cache clearing upon logoff. Users using these browsers can select either Premium or Basic OWA, depending on their preferences and connection speeds. OWA Basic is available for users using all other browsers that do not meet the requirements for use with OWA Premium. It still provides the basic messaging functionality that users expect when connecting to OWA. The actual improvements that have been made to OWA are too numerous to discuss. The bottom line is that when users use OWA Premium, their experiences will almost exactly match those provided by Outlook 2003, including features such as rules, address books, spell checking, message flagging, and public folders. What's no longer supported in Exchange 2003 As with any new release, some features of previous versions of Exchange Server are no longer supported in Exchange 2003. The following are some of the more important areas that you need to be cognizant of if your future plans include upgrades or migrations to Exchange 2003 from other messaging systems, including Exchange 2000 Server. Lotus cc:Mail and MS Mail connectors Exchange 2000 Server shipped with the Lotus cc:Mail and MS Mail connectors to allow interoperability with these legacy messaging systems -- Exchange 2003 does not, and furthermore, no longer supports these connectors. You cannot upgrade any Exchange 2000 server that's running these connectors, or manage any Exchange 2000 servers running these connectors with the Exchange 2003 version of the Exchange System Manager. Should your organization still have a need to use connectors, you need to retain one or more Exchange 2000 Server SP3 (or better) servers on your network.

Exchange 2000 Server KMS Exchange 2000 Server provided a giant leap forward in integrated messaging security management with its KMS. KMS worked with the Windows 2000 Server Certificate Services to create and manage a PKI (public key infrastructure) to allow secure messaging, including key archival and recovery functionality. As nice a feature as KMS was, it was cumbersome to administrate. With the improvements in Windows Server 2003 Certificate Services, the KMS is no longer part of Exchange Server. Exchange 2003 now supports any standard X.509v3 PKI implementation, including the one provided by Windows Server 2003. Furthermore, the PKI provided in Windows Server 2003 now provides advanced functionality, such as key archival and recovery. The KMS must be removed from any server that will be upgraded from Exchange 2000 Server. Chat and Instant Messaging Exchange 2000 Server supported a number of realtime communications features, such as chat and instant messaging natively, and offered support for additional features via the add-on Exchange Conferencing Server. All of these features have been removed from Exchange 2003 to provide a simpler and more manageable solution for the majority of organizations running Exchange as their messaging system. Functionality for realtime communications is now provided via Office Live Communications Server. You must remove all realtime communications-related features from any server that will be upgraded from Exchange 2000 Server. The M: drive Exchange 2000 Server mapped the M: drive to the network to the Exchange store located at \\.\BackOfficeStorage\. In Exchange 2003, this mapping is no longer created (by default), although you can still interact with the Exchange store using the UNC (Universal Naming Convention) path. Many cases of database corruption occurred with the mapping in place due to file system operations, such as virus scanning or backups, being performed directly against the M: drive. In response to this problem, Microsoft removed this dangerous functionality in Exchange 2003 and strongly recommends that any remaining Exchange 2000 servers remove it as well.

E Like most products, Exchange 2003 comes in more than one version. Two different versions of Exchange 2003 exist: Exchange 2003 Standard Edition and Exchange 2003 Enterprise Edition. How large your budget is and what exactly you need or plan to do with Exchange 2003 determines which version you need to purchase. The following table illustrates the differences between the two versions of Exchange 2003.

Feature

Standard Edition Two 16 GB Yes No Yes Yes No

Enterprise Edition Four Five No set limit Four Yes Yes Yes Yes Yes Yes

Maximum number of storage groups One Maximum number of databases per storage group Maximum database size Recovery storage group available? Can be used in a cluster? Can be used as a front-end server? Utilizes Volume Shadow Copy? Includes the X.400 connector?

Number of storage groups supported One

Includes the GroupWise connector? Yes

Includes the Notes connector?

Yes

Yes

Table 1-1: A feature comparison of Exchange 2003 Standard Edition versus Exchange 2003 Enterprise Edition. This course focuses on the Standard Edition. Moving on In this lesson, you learned the basics of Exchange 2003, as well as the differences between it and Exchange 2000 Server. In Lesson 2, you find out why Exchange 2003 depends on Active Directory. Before you move on, do the assignment and tackle the quiz. If you have any questions, post them on the Message Board. Even if you don't have questions, it's worth visiting the Message Board to touch base with your instructor and see what your fellow students are up to Active Directory overview It's easy to get confused when you hear the term Active Directory and then people start talking about Active Directory and it's components as if they were living entities. In a way, Active Directory is a living entity -- at least from the standpoint that it's perhaps the single most important part of any medium- to large-sized network. Although it's true that you can operate even the largest of networks without ever using Active Directory (as versions of Microsoft Windows prior to Microsoft Windows 2000 Server did for years), to truly have a network operating system that can provide the robust features and security controls that are required today, Active Directory must be used. Like any complex machine -- and that is what Active Directory is when you get right down to it -- many parts and processes must all interact with each other to achieve the final result. Active Directory may be the heart of the Windows Server 2003 network, but it's supported by (and requires) several other key network services. That discussion, however, is beyond the scope of what you examine in this lesson. In the next few sections, you get an overview of Active Directory by examining it from dynamically different viewpoints: Active Directory as a logical entity and Active Directory as a physical entity. When you're done, you'll have a better understanding of how Active Directory works to provide streamlined management and control over even the largest of networks. Active Directory architecture

Unlike Microsoft Windows NT, Microsoft Windows 2000 and Windows Server 2003 do not require you to create a domain controller during the initial installation of the operating systems. As such, Active Directory is not automatically part of the operating system on a newly installed Windows Server 2003 machine -- although you can certainly change this fact at any time as needed. Newly installed Windows Server 2003 machines are, by default, created as member servers -either a workgroup or a domain. When member servers (and workstations) are part of a workgroup, they use a security architecture that resides locally on the computer. When member servers (and workstations) are joined to an Active Directory domain, they use a centralized security and directory architecture that's maintained by Active Directory. Even after a server (or workstation) is joined to a domain, however, it still maintains its local security database -- only when a server is turned in into a domain controller does the local security database cease to exist. To that end, there's no local Administrative account on any Windows Server 2003 domain controller -- an important fact to bear in mind. Active Directory uses an organizational model that's based tightly on the DNS (Domain Name System) model. In fact, Active Directory naming is in many cases identical to DNS naming within an organization. A tree contains domains and each tree has one or more root domains, in which all other domains are created. All domains under a root domain share a common, contiguous DNS namespace. Organizational units and containers exist internally to each domain. They are used by Active Directory to create a more defined tree structure. Organizational units and containers can be nested within one another, although only organizational units can be used to assign configuration and security settings to objects within them. Containers are merely a construct used to organize objects. Objects can be created to represent both logical and physical components of the network, such as users, computers, and sites. The resulting product is a directory service that can be scaled up or down for an organization of any size or geographical organization. Figure 2-1 illustrates how an Active Directory organization might be created using two root domains, each with several layers of child domains below them.

Figure 2-1: A Windows Server 2003 forest. Enlarge image All domains within the same root domain trust each other transitively, which is a major departure from the way that Windows NT domains were created. Additionally, all root domains within the same forest also automatically transitively trust each other. Trusts can be manually created directly between different domains within a forest at any level (shortcut trusts), externally to other organizations and in Windows Server 2003 between forests provided that certain prerequisites are met. When two domains or forests trust each other, objects in either domain are allowed access to all resources, limited only by their configured permissions and the configuration of the trust itself. Figure 2-2 shows how the various trusts within an Active Directory organization might look.

Figure 2-2: A Windows Server 2003 forest with various trusts. Enlarge image

T As you've already seen, the logical structure of Active Directory is based on the DNS model. Forests contain root domains, root domains contain child domains, and within each child domain (or root domain if no children exist) are the actual objects that form the reason why the network exists in the first place. Organizational units, containers, and various objects exist within each domain and are managed by Active Directory. The schema determines which properties each of these objects is allowed to have so the entire directory service structure that Active Directory provides can be maintained in an orderly and predictable fashion. In the following sections, you'll examine the components that make up the logical structure of Active Directory. Forests The forest is the top of the Active Directory organization and serves as the administrative and security boundary for an

organization. All objects within the forest share a common schema, configuration, and global catalog. The forest is typically referred to by the name of its root domain (if only one root domain exists) or by the name of the first root domain (if multiple root domains exist). As you've already seen, within the forest exists one or more groups of domain trees that trust each other using transitive and hierarchical trust relations that are automatically created and managed using the default Kerberos security trust model of Active Directory. Looking back at Figure 2-1, you can see a forest with two domain trees in it. These two domain trees, although largely independent of each other, are still tied to each other because of their membership within the same forest. In the Exchange 2003 organization, the forest forms an organizational boundary, which cannot be crossed by a single Exchange organization. Microsoft Exchange Server 5.5 was not limited in this way because it maintained it's own directory service; however, the tight integration with Active Directory in Exchange 2003 imposes this limitation. SMTP and X.400 connectors can be used to link Exchange 2003 organizations that span multiple forests. Trees Within forests exist trees, and trees provide the hierarchical organization of domains. A tree can have multiple branches and nested containers, much like the file system on a computer. If you compare the top of a tree to the root of a hard disk, the similarities start to become apparent. Nested containers in the tree are similar to folders in a file system. Within these containers are users, objects and other resources on the network. Within a folder on your hardware are files and applications. A domain tree is a group of one or more contiguous domains that all share the same namespace and are tied to each other by a default transitive trust between parent and child. The contoso.com domain, shown in Figure 2-1, consists of five domains at three levels that are all tied to each other by namespace and trust. Domains A domain is branch, or node, of the forest and is typically created to satisfy organizational or geographical needs for distribution objects below it. A domain can span a LAN (local area network) or WAN (wide area network) as desired, depending on the network design and subsequent implementation and changes. As shown in Figure 2-1, multiple domains can exist within a single LAN or can be separated by WAN links. All domains under a root domain share a common namespace and trust each other through a series of transitive trusts. Additionally, all domains under a root domain share a common global catalog that lists users, resources, and other objects. Within each domain, you start to deal with the physical components of Active Directory, such as user objects, computer objects, and other objects. In addition, domains house the more granular logical components of Active Directory, such as organizational units, containers, and groups. Certain Group Policy settings, such as password settings can only be configured at the domain level. Schema If the forest is the container within which Active Directory is housed, the schema is the set of instructions and specifications by which Active Directory operates. The schema defines which types of objects can exist within Active Directory and which properties these objects should have. A very simple schema might only allow for three objects: a server, an organizational unit, and a user. Each of these three objects then has a set of attributes that are specified by the schema that are used to define and describe it, for example: The server might have attributes of host name and IP (Internet Protocol) address The organizational unit might have attributes of name and objects allowed within it The user might have attributes of first name, last name, and e-mail address

When Active Directory is installed for the first time in an organization, the default schema is created. The default schema is extensively vast and contains tens of thousands of entries that define all manner of things related to Active Directory -- the vast majority of which is beyond the scope of this course. The schema can be extended by other applications after it's initially created, such as by Exchange 2003. The default schema configuration of a user object in Active Directory makes no allowance for a mailbox. Exchange 2003 extends the schema and makes the mailbox (and other related attributes) an attribute of users and groups. Additionally, other objects that the schema defines have their attributes extended (added to) by Exchange 2003. The schema is an integral part of Active Directory and is stored within the Active Directory database along with objects and all other items related to Active Directory. NTFS (New Technology File System) permissions and ACLs (Access Control Lists) are used to control who has access to manage the schema. In addition, a special domain controller that has the Operations Master role of Schema Master must be contacted before any change can be made to the schema. It goes without saying that the schema is absolutely critical to the proper operation of Active Directory.

Although the schema can be extended (added to), items can never be removed from the schema. You can, however, turn off items in the schema, which makes them effectively unavailable for use. Global catalog Just as the schema is the set of instructions and specifications by which Active Directory operates, the global catalog is the phone book that lists all objects within Active Directory. Just like a phone book, the global catalog is a simple index of objects and, therefore, does not contain every possible attribute for an object. A phone book might list first name, last name, street address, and phone number, but does not list where the individual works, what his e-mail address is, and what type of car he drives. Just the same, the global catalog only indexes the more common attributes of objects within Active Directory and makes them available for querying. Although this may seem like a disadvantage, consider the fact that even if a desired attribute is not contained with the global catalog, enough information exists about the object to pass the query to a domain controller that has a replica of the Active Directory partition. As a result, it has a complete and detailed listing of all attributes of the desired object. Global catalogs purpose within the Active Directory organization is to speed up queries that are performed against Active Directory and to alleviate domain controllers of this additional responsibility when possible. Global catalogs are hosted on global catalog servers, of which only one is created by default. The first domain controller in an organization is automatically configured as a global catalog server. After that, an administrator must manually configure additional global catalog servers. Global catalogs are crucial to the success of Exchange 2003 in an organization because they're used to process the numerous LDAP queries required to efficiently provide enterprise messaging services. The failure of an Exchange 2003 machine to contact a global catalog server will cause many problems, including failure of the Exchange Server to perform its function. Organizational units Within a domain, organizational units can be used to organize objects, such as users and computers, into logical groups that can be effectively and intelligently managed and assigned permissions and privileges. Organizational units in Windows Server 2003 completely replace the complicated and difficult to maintain resource domain model used in Microsoft Windows NT 4.0. You can nest organizational units, like domains, and configurations made at the parent level can inherit (by default) all child-level organizational units. When applying Group Policy settings in Active Directory, organizational units are the most granular level at which Group Policy can be applied; therefore, you can configure very specific settings for each organizational unit on an as needed basis. Although organizational units can contain security groups, which can have permissions and rights configured on them, security groups cannot directly receive Group Policy settings. Figure 2-3 illustrates how you might use organizational units to intelligently segregate your users and computers for easier administration and granular configuration.

Figure 2-3: Using organizational units to apply different Group Policy settings. Containers Containers perform one of the functions of organizational units, and one function only. A container can be used to segregate objects into easier to manage groups, but it cannot be used to apply permissions or Group Policy settings. Several default containers are created during the creation of Active Directory, such as the User container and the Computers container. By default, all users and computers created are placed in their respective

containers. Security groups Whereas the organizational unit is the lowest level at which you can apply Group Policy settings, security groups can still be used to apply permissions and rights to multiple objects at a time. Groups can contain users, computers, and even other groups within them, and then be configured with the desired permissions and rights. Groups are typically placed within an appropriate organizational unit so that all members of the group can receive the Group Policy settings that are applied to the organizational unit. Several default groups are created when Windows Server 2003 is installed and many others are created when Active Directory is installed. As an example, all users who require no other special permissions other than being able to perform backups and restorations are part of the Backup Operators group. You can use the default groups or create groups of your own to meet your needs. Distribution groups In all actuality, two types of groups exist: security and distribution. Up to this point I've been talking exclusively about security groups. Distribution groups are used by an application to send e-mail messages quickly to all members of the group that have been configured with an e-mail address. Distribution groups cannot be used to configure permissions and rights on their members as security groups can; however, security groups can also be configured with an e-mail address that allows applications, such as Exchange 2003, to send messages to all members of the security group as well.

T Unlike the previous discussion about the logical structure of Active Directory, the following discussion on the physical structure of Active Directory discusses items that you can actually put your hands on and see outside of the confines of using a management console on your workstation or server. Items such as sites, domain controllers, servers, workstations, users, printers, and other objects are all physical entities that have a key role in the operation of Active Directory. In reality, the physical components of Active Directory necessitate the logical components. After all, the entire function of the network (and hence Active Directory) is to allow users to perform their tasks so that the business of the organization can be carried in an efficient and productive manner. Sites The official definition of a site is "one or more IP subnets that are connected to each other by a fast and reliable connection." You will, in most cases, consider sites to be geographically different locations in which users and servers are located. Sites are typically made of one of more IP subnets that share a fast and reliable connection, such as a standard Ethernet or Gigabit Ethernet backbone common to most organizations. Sites are then connected to one another by WAN links of various speeds and reliabilities. Although a site can span a WAN link, the WAN link typically becomes a severely limiting part of the site design. Domain controllers within a site are automatically configured to perform replication with each other. When users log on to the network, the authentication process is also affected by site design. By default, authentication is attempted on a global catalog (or domain controller) in the same site as the client. If no domain controllers or global catalog servers can be found in the local site, the client is forced to perform authentication across a potentially slower WAN link. By having authentication performed local to the client, the client (and the entire network) experience better performance with less latency. Domain controllers You've encountered the term domain controller many times up to this point, but don't yet know what its function is in relation to Active Directory as a whole. As its name implies, the domain controller is in control of the domain more or less. Domain controllers are responsible for managing and maintaining network services, resources, and access. In Windows NT, there were two types of domain controllers: PDC (Primary Domain Controller) and BDC (Backup Domain Controller). Only the PDC had a writeable copy of the domain database. In Active Directory, all domain controllers are created equal (more or less, you'll see why later) and operate in the multimaster mode. This is where any one domain controller can make changes to the Active Directory data, such as updating an attribute on a user account or creating a new shared resource, such as a printer.

As mentioned earlier, the first domain controller in an organization is automatically assigned the global catalog server role. There are five other Operations Masters roles that are also assigned to this domain controller that later should be reassigned (for reliability) to other domain controllers: Domain naming master: Only one domain naming master exists per Active Directory forest. The domain naming master has control over the addition or removal of domains in the forest. Schema master: Only one schema master exists per Active Directory forest. The schema master is responsible for all updates and modifications to the schema. Updates to the schema cannot be made without contacting the schema master. PDC emulator master: Only one PDC emulator exists per domain. The PDC emulator performs a few different roles depending on the nature of the network. In networks that still have Windows NT BDCs, the PDC emulator functions as a PDC, allowing normal communications between the legacy BDCs and Active Directory. The PDC emulator also maintains time synchronization within the domain and receives preferential notification of any password change made within the domain. Should a logon attempt fail due to a bad password, the PDC emulator is asked to authenticate the logon because it would likely know of any recent changes to the password. RID (relative identifier) master: Only one RID master exists per domain. Each object created within Active Directory has a unique SID (Security Identifier). The SID consists of a domain SID, which is the same for all objects created within that domain and a RID, which is unique for all objects in that domain. The RID master ensures that each RID is unique. Infrastructure master: Only one infrastructure master exists per domain. The infrastructure master compares its domain's data with that of the global catalog. Global catalogs contain information about all domains through replication events, so the global catalog is considered to always be up to date. If the infrastructure master finds data within its domain that is out of date, it requests an update from the global catalog, and then replicates this data to the remaining domain controllers in its domain.

Unless only one domain controller exists within the domain, the domain controller that holds the Infrastructure Master role should never also hold the Global Catalog server role. If the same server holds both roles, the infrastructure master will never find any data that is out of date and will cease to perform its intended function. Therefore, changes will never be replicated to other domain controllers in the domain. The only exception to this is when all domain controllers are also acting as global catalog servers. In this case, all domain controllers will already have the current data set and it does not matter which domain controller holds the infrastructure master role. Servers and workstations Servers and workstations are among the easiest of all objects to comprehend. Users use workstations, which interact with servers to perform tasks required of the organization. All computers, like users, have accounts within Active Directory that allow them to participate in the Active Directory organization. In addition, computers can receive Group Policy settings to configure their settings and behaviors. Users Users, while not always easy to comprehend, are certainly easy enough to envision as a physical component of your network and therefore of Active Directory. The entire network exists to serve the users to allow them to perform their intended tasks, all of which typically contribute to the bottom line of the organization. Exchange 2003, for example, can be installed into the organization to extend the functionality of users by providing them a messaging and collaboration platform to increase productivity. Many other objects exist within Active Directory that are beyond the scope of this course. Some of them include printers, shares, services, and even groups, which you've already examined. H By now, it should be fairly evident that Active Directory is the very heart and soul of a Windows Server 2003 network. To that same end, Active Directory is what allows Exchange 2003 to be such a powerful messaging and collaboration platform. In Exchange Server 5.5, Exchange recipient objects (contacts and users for example) were maintained in their own directory service. There was absolutely no correlation between Windows NT 4.0 domain accounts and Exchange

Server 5.5 mailboxes. A single user could have multiple mailboxes assigned (often referred to as resource mailboxes) and oftentimes did. In Active Directory, this separation is no longer available, which is largely a very good change. Existing Exchange recipient objects in Active Directory simply have their schema extended, allowing them to directly interact with Exchange Server. A mailbox is now a property that can be configured for a user by making the user mailbox enabled. To the same end, a user can be mail-enabled by entering an external e-mail address. The need for Exchange to maintain its own directory service no longer exists -- all messaging attributes that a recipient object might posses are now simply extensions to the schema. Although this all might sound confusing, the payoff comes in simpler management and implementation. A single administrator can easily manage the network, including both typical user account issues, such as forgotten passwords and network share usage as well as Exchange-related tasks such as mailbox creation and management. The secret behind this tight integration, as you've already guessed, is extension of the schema to facilitate Exchange simply dropping into place in an existing Active Directory network. To that end, you must know that you cannot install Exchange 2003 into a network that does not have Active Directory configured and operating normally. Additionally, you cannot install Exchange 2003 onto a member server that's not already joined to the domain. Management of Exchange 2003 is accomplished primarily through two different consoles: Exchange System Manager and ADUC (Active Directory User and Computers). After an installation of Exchange (or simply the Exchange System Manager on a workstation), ADUC is modified such that Exchange-related tasks can be performed using the Exchange Tasks Wizard. Additionally, several new tabs are present on user account Properties that are Exchange specific. With little exception, everything you do in Exchange 2003 is directly dependant on Active Directory or one of its supporting services. Moving on In this lesson, you learned about Active Directory and how it works with Exchange 2003. In Lesson 3, you find out how to plan for an Exchange 2003 server. Before you move on, do the assignment and tackle the quiz. If you have any questions, post them on the Message Board. Even if you don't have questions, it's worth visiting the Message Board to touch base with your instructor and see what your fellow students are up to.

Hardware requirements to install Exchange 2003

When it comes to installing Exchange2003, you certainly don't have to have top- of-the-line equipment with the fastest processors and the most RAM (random access memory) possible, but it certainly doesn't hurt. Exchange, like any enterprise quality application, can be very demanding on hardware resources, especially as an organization grows and the number of users increases. Although Microsoft Windows Server 2003 has its own hardware requirements that must be met prior to its installation, you need to be specifically concerned with what Exchange2003 requires. As with any hardware requirements listing you'll deal with, you should always strive to exceed the minimum requirements. Furthermore, a well-planned and designed solution exceeds the recommended requirements. Ample forethought ensures that you can implement a solution that will last for several years. In regards to your Exchange2003 installation, you should not plan to meet your needs for today. Instead, forecast what your needs will be three, four, or even five years from now. It's unlikely that your solution will stand unmodified for five years, but in some cases it might. Either way, by planning for the future, your solution will be ready to deliver the required services to your users today. The following table outlines the minimum and recommended hardware configuration that you should have in place before installing Exchange2003 onto a computer.

Item

Minimum

Recommended 733 MHz Pentium

CPU (central 133 MHz processing Pentium unit) RAM Disk space 256 MB

512 MB

500 MB 500 MB available on the available on the Exchange drive *200 MB

Exchange drive200 MB available on the system drive CD-ROM Video Display Required VGA (Video Graphics Adapter) or better

available on the system drive* Space above this value as required, with the databases kept on fault tolerant drive sets Required VGA or better

Table 3-1: The minimum and recommended hardware specifications to install Exchange 2003. Software requirements to install Exchange2003 Just as Exchange2003 has specific hardware requirements to support its installation, it also has a set of software requirements that must be in place to support its installation. The requirements outlined here are all encompassing within the Windows Server 2003 operating system, both to the local computer and on the network itself. Operating system Exchange2003 only supports installations on the following versions of Microsoft Windows: Windows Server 2003 Standard Edition Windows Server 2003 Enterprise Edition Windows Server 2003 Datacenter Edition Windows 2000 Server SP3 or later Windows 2000 Advanced Server SP3 or later Windows 2000 Datacenter Server SP3 or later

File system You must format the following partitions (or volumes) with the NTFS file system to support installation of Exchange2003: System partition Partition or volume that where the Exchange binaries will be installed Partitions or volumes that will house the transaction log files Partitions or volumes that will house the database files Partitions containing other Exchange files

Active Directory Active Directory must be on the network to support the installation of Exchange2003. Any domain controller or global catalog server that Exchange2003 may contact must be running Windows Server 2003 or Windows 2000 Server SP3 or later. Additionally, there must be at least one global catalog server in each Active Directory site in which an Exchange2003 will be installed. The server on which Exchange 2003 will be installed must already be joined to the Active Directory domain and have a functional computer account prior to the installation of Exchange 2003. IIS Exchange 2003 relies on several core IIS services provided by Windows Server 2003. Before you can install Exchange 2003 onto a Windows Server 2003 computer, it must have the following IIS components installed and operational: The World Wide Web Publishing service The NNTP (Network News Transport Protocol) service

The SMTP (Simple Mail Transfer Protocol) service The ASP.NET components

Before you can install Exchange 2003 onto a Windows 2000 Server SP3 or later server, you must have installed the first three IIS services listed previously. The Exchange setup routine installs and configures ASP.NET as part of its installation. DNS and TCP/IP DNS is required to support Active Directory and is highly utilized by Exchange 2003. Active Directory integrated zones are preferred due to their superior security, redundancy, and elimination of zone transfer traffic, but any standard DNS zone solution that meets the requirements to support the installation of Active Directory will suffice. In addition, any computer that will host an installation of Exchange 2003 or be used to connect to an Exchange 2003 computer must have TCP/IP (Transmission Control Protocol/Internet Protocol) installed and properly configured to support reliable network connectivity. Servers should have manually configured static IP addresses or DHCP (Dynamic Host Configuration Protocol) server reservations. Clients can use either DHCP leases or manually configured static IP addresses depending on your organizations specifications. Exchange 2003 licensing issues One of the most complicated parts of planning for an Exchange 2003 deployment is licensing it. This sad fact, however, does not have to be true if you take the time to understand the specific licensing issues that surround Exchange 2003. When discussing licensing and Exchange, there are three different licenses you must have purchased (and in an adequate quantity) before you can legally install and connect clients to your Exchange 2003 organization. Server licenses Each server licensed you own grants you the legal right to install Exchange 2003 on a single server. Additionally, you can install the Exchange System Manager to allow for remote administration or backup of the Exchange store on as many additional computers as desired with no additional licensing fees. User CAL CALs (client access licenses) can be purchased in one of two ways: per user or per device. A per-user CAL is purchased to allow a single user to access any Exchange server in the organization from any location inside or outside of the organization. A per-device CAL is purchased to allow any number of users to access any Exchange server in the organization from a single computer, such as a kiosk. Both types of CALs cost approximately the same, although your final cost is determined by many factors, including geographic location, number of CALs purchased, and licensing programs in which you're participating. CALs for Exchange Server are not provided in any version of Windows or Microsoft Office, and must be specifically purchased to legally allow client connections to Exchange servers. Client License A client license is required to allow an instance of an application, such as Microsoft Outlook 2003, to be installed on a client computer. This client license is needed for the installation of the application only and is not related to needing a CAL to connect that client to the Exchange organization. Having a client license to install an application does not automatically grant you a CAL; you must purchase each type of required license separately Going above the minimums As alluded to previously, even though you can successfully install and operate Exchange using the minimum or even the recommended requirements, you cannot guarantee an optimal environment for your users unless you seek to exceed the minimum and recommendation hardware values detailed in the previous table. There are many things that you can do to improve the user's experience in your Exchange organization. You'll examine some of the more common actions in the next few sections. Fast SCSI hard disks Exchange 2003 is extremely demanding of all physical resources, but perhaps most demanding of the disk subsystems in the servers on which it runs and the arrays and external storage devices used to support it. Unlike processors, memory, or network interface adapters that can be fairly easily upgraded after the Exchange installation has occurred, disks are a

more complex problem. Taking the time -- and spending the money -- ahead of time to ensure that you're getting the best performing disks that your company can afford will go a long way towards making your Exchange organization perform at its best. In all but the very smallest companies, you'll do well to stay away from using IDE (Integrated Drive Electronics) disks for your Exchange organization. Fast 10,000 or 15,000 RPM SCSI (Small Computer System Interface) disks with fast controllers and cabling will go a long ways towards ensuring that the disk subsystem does not become an irreparable bottleneck in your Exchange organization's performance. Microsoft provides the Jetstress tool to test and verify disk performance by simulating an actual Exchange Server disk I/O (input/output) load by simulating the database and transaction log loading that can be expected to result from a specific number of users. By monitoring the disk system with the System Monitor, you can collect data about the performance of the disk subsystem during the Jetstress test to determine if it meets or exceeds the performance criteria you've established. RAID-1 arrays RAID-1 (redundant array of independent, or inexpensive, disks) otherwise known as mirroring, can be inexpensively implemented and used to create a basic level of redundancy for disks that contain items of some importance, such as the operating system files. Should a single disk in the mirror set fail, you can restart the computer on the other disk from the set and recreate the mirror once a new disk has been installed. There's no true data redundancy with RAID-1 like you have with RAID-5, but then again, it should only be used where the costs and complexities of implementing RAID-5 cannot be justified. RAID-1 can be easily implemented within Windows itself or can be implemented through specialized hardware devices that have been optimized for this purpose alone. RAID-5 arrays For mission-critical data, RAID-5 provides an ideal solution for both accessibility and recoverability. Critical Exchange information, such as the Exchange databases and the transaction logs, should be placed on RAID-5 arrays when possible. Should a single disk in a RAID-5 array fail, its contents can be recovered dynamically from the other remaining disks after it's been physically replaced. If two or more disks in a RAID-5 array fail at the same time or a second disk fails before the data set has been restored from a previously failed disk, you won't be able to recover any data from the set and the array is lost. Thus, the necessity for a well-conceived disaster recovery plan as you'll see later. Clustering Clustering provides an even higher level of redundancy and availability than RAID-1 and RAID-5 solutions alone do. Clustering is the process of configuring two or more physical servers to act as a single logical entity that responds to inbound client requests for service. Exchange 2003 supports two types of clustering, as compared to previous versions of Exchange Server that only supported one type of clustering or the other, but never both. You can create active/active clusters or active/passive clusters in Exchange 2003. Clustering is managed by the MCSC (Microsoft Clustering Service) and has exceptionally high hardware requirements that go far above those required to install Exchange 2003 in a nonclustered environment. An external Fiber Channel or SCSI device that can be reliably contacted by all clusters nodes must be used to hold the quorum disk, which is the disk that holds the definitive information about the cluster's configuration and its operational status. The quorum disk should be created on a RAID-5 array of disks to ensure its redundancy because without this information the cluster cannot function. The high cost of the shared external storage device, along with the hardware required to connect servers to it, is enough, in many cases, to force a smaller organization to avoid clustering as a means to ensure messaging availability. If messaging is critical to your company's business, then clustering can usually be justified as a necessary addition to your Exchange organization. For example, you might purchase a 2U rack-mounted SCSI disk array that's capable of holding 14 disks. You install and configure three disks in a RAID-5 array for the quorum disk, another three disks in a RAID-5 array for the transaction logs, and the remaining eight disks in a RAID-5 array for the Exchange databases. Active/active clustering An active/active cluster uses two physical Exchange 2003 servers that are configured as a single logical server. Both servers actively respond to client requests and both servers are typically (ideally) configured to hold 50 percent of the total Exchange organization load that they're clustering. The largest drawback to active/active clustering is that it's significantly limited in the amount of storage groups and users that it can support. Because a single Exchange 2003 server can only mount four storage groups, no more than four total storage groups should exist between both nodes of an active/active cluster. In addition, a single Exchange 2003 server in

an active/active cluster should not hold mailboxes for more than 1,900 users or a performance decrease can be expected to occur.

Active/passive clustering An active/passive cluster uses between two and eight physical Exchange 2003 servers to create a single logical server. At least one server must be active (actively responding to client requests for service) and at least one server must be passive (in standby waiting for resources to be failed over to it), although you can configure the cluster in any arrangement you wish above these minimums. You could, for example, have a six-node active/passive cluster with four active nodes and two passive nodes. The passive nodes in an active/passive cluster can perform no other tasks and must sit idly by waiting for the MCSC to fail over the resources from an active node. This is oftentimes the hardest selling point about active/passive clustering as these passive nodes are seen as a waste because in most cases, they never actually do anything. That myth is quickly dispelled, however, when active nodes start to fail for whatever reason and the operation of the messaging organization continues with barely a hiccup. As an offset to the increased cost, and complexity, of configuring active/passive clusters both performance and scalability are increased. A single Exchange server can once again hold four full storage groups and a number of users that limited only by performance. Should this node fail, an identically configured (both in hardware and software) node is waiting to receive its resources and continue to serve client requests. Active/passive clusters also provide a simplified way to perform hardware and software upgrades and replacements as compared to active/active clusters. Disaster recovery No matter what else you do in planning for your Exchange organization, no matter how redundant and reliable you think it is -- disaster will find you one day. Whether they are natural or man-made, disasters are a fact of life that must be planned for and mitigated as much as practical. A disaster is, in simple terms, any event that precludes your company from carrying out its normal business operations. By that definition, disaster might come in the form of two failed disks in a RAID-5 array, a fire that causes your server room to receive smoke and water damage, or perhaps it might come in the form of intentional sabotage. The best thing you can do is to realize that a disaster will happen and plan ahead of time to mitigate its effects. A solid data backup and restoration plan should be a key part of your disaster recovery plan. Of course, there are many other parts of a disaster recovery plan outside of just making backups and being able to restore them on demand. This is the reason why you must take adequate time to plan, document, and prove your disaster recovery plan. Disaster recovery is a topic that could fill an entire book; therefore, it's not discussed further in this lesson. The following are some resources on the Microsoft Web site that will provide you with more information: Exchange 2003 Disaster Recovery, from the TechNet briefings Planning for Disaster Recovery, from the Windows Server 2003 Deployment Kit. Disaster Recovery for Microsoft Exchange 2000 Server (although for a previous version, it still provides many valid points of reference) Exchange 2003 Disaster Recovery Operations Guide, available in June, 2004 (scroll to the bottom of the Web page)

Moving on In this lesson, you learned the basic hardware and software requirements that must be met to install Exchange 2003. You also learned what you can do to go above these minimums and improve the reliability, availability, and usability of your Exchange organization. In Lesson 4, you'll actually get your hands dirty as we dive into working with Exchange 2003 by installing it and working with some recipient objects. Before you move on, do the assignment and tackle the quiz. If you have any questions, post them on the Message Board. Even if you don't have questions, it's worth visiting the Message Board to touch base with your instructor and see what your fellow students are up to Preparing the environment for the Exchange 2003 installation Page 1 of 4

Even after you've done all of the preparation discussed in the previous lessons, you're still not ready to perform the actual installation of Exchange 2003 in your organization. Before you install Exchange 2003, you must first prepare Active Directory. In a small organization, you can actually skip the two steps discussed in this section, although you should consider performing them because it gives you the opportunity to configure how your Exchange organization will be created before you actually perform the first Exchange 2003 installation. There are two tools within the Exchange 2003 setup routine that help you prepare the Active Directory schema (and the forest itself), as well as the domains within that forest: ForestPrep: The ForestPrep tool must be run one time within a forest to prepare the forest and to extend the Active Directory schema with the objects necessary to run Exchange 2003. DomainPrep: The DomainPrep tool must be run one time in each domain that will have Exchange servers installed, has Exchange recipient objects, or has users who will be administering the Exchange organization.

Although this might seem like a complex routine, especially for smaller organizations, it does provide you with some advantages. In many networks, the administrative duties (and therefore abilities) of administering domains, the schema, and Exchange Server are divided among multiple groups. One group might be responsible for maintaining the schema and the forest root, one group might be responsible for all child domains, and yet another group might be tasked with the administration of the Exchange organization. By splitting the Exchange setup routine into distinct steps, each step can be performed by the administrative group that holds the required permissions and privileges. Running ForestPrep As discussed previously, the ForestPrep tool must be run one time within an Active Directory forest that is to receive an Exchange 2003 organization. ForestPrep performs the following tasks when it's run: Extends the schema with the required Exchange-related objects and attributes. It creates an Exchange organization in Active Directory. In a forest with no previous Exchange organization, it prompts you to specify the name of the new Exchange organization and creates the organization object within Active Directory. In a network with an existing Microsoft Exchange Server 5.5 organization, it creates the organization object within Active Directory. It assigns the role of Exchange Full Administrator to the Active Directory domain user account you specify. Subsequently, this account will have the ability to install and manage Exchange Server anywhere within the forest.

To run the ForestPrep tool, your user account must belong to the following: llowing: The Schema Admins group The Enterprise Admins group The local Administrators group on the server on which ForestPrep is run

To run the ForestPrep tool, follow these steps:

1. Insert your Exchange Server 2003 CD in the server's CD-ROM drive. The Welcome Exchange Server 2003 Setup 2. 3.
page opens as long as the CD-ROM is configured for Autoplay. If it does not start, you can start it by doubleclicking the setup.exe file located in the root of the CD. Click the Exchange Deployment Tools link. The Exchange Server Deployment Tools screen, shown in Figure 4-1, appears. Click the Deploy the First Exchange 2003 Server.

Figure 4-1: The Exchange Server Deployment Tools screen.

4. The Deploy the First Exchange Server 2003 screen appears. Click New Exchange Server 2003 Installation. 5. The New Exchange Server 2003 Installation screen appears, as shown in Figure 4-2. Click the Run ForestPrep
Now link, which appears in Step 6 (not shown in the figure). Steps 1 to 5 on this screen are all preliminary steps that must be done before you can continue, although they are not covered here.

Figure 4-2: The New Exchange Server 2003 Installation page. Enlarge image

6. Accept the EULA (End-User License Agreement) when prompted. Click Next. 7. Enter the 25-digit product key when prompted. Click Next. 8. The Component Selection dialog box appears, as shown in Figure 4-3. Note that the ForestPrep option is already
selected for you. Click Next to begin the ForestPrep process.

Figure 4-3: Starting ForestPrep. Enlarge image

9. The Microsoft Exchange Server Administrator Account dialog box appears. Designate the user account that will
receive the Exchange Full Administrator role. Use the format of domain\user, as shown in Figure 4-4. Click Next.

Figure 4-4: Specifying the Exchange Full Administrator account.

10. ForestPrep now begins its update actions. In some cases, you may be prompted with a dialog box to verify the
update. If this occurs, click OK.

11. When the ForestPrep process is complete, the Completion screen appears. Click Finish.
You can also run ForestPrep tool from the command line by entering f:\setup\i386\setup.exe /forestprep, assuming that volume F represents the correct location of the Exchange 2003 installation files. Running DomainPrep After you run the ForestPrep tool, you must then run the DomainPrep tool to prepare each domain in the forest that meets the following conditions: Will have an Exchange 2003 server installed. Will have ExchanExchange mailbox-enabled recipients in it.

Will have a user account that's used to administer the Exchange 2003 organization in it.

To run the DomainPrep tool, your user account must belong to the following: The Domain Admins group for that domain The local Administrators group on the server on which DomainPrep is run

The DomainPrep tool performs the following tasks for the domain: It creates the Exchange Enterprise Servers local group. It creates the Exchange Domain Servers global group. It adds the Exchange Domain Servers group to the Exchange Enterprise Servers group. It creates the Exchange System Objects container within Active Directory, which is used for mail-enabled public folders. It adds the Exchange Domain Servers group to the pre-Microsoft Windows 2000 Compatible Access group. It configures permissions for the Exchange Enterprise Servers group at the root of the domain to allow the Recipient Update Service to function properly. It grants the required permissions to Exchange servers and administrators.

To run the DomainPrep tool, follow these steps:

1. Insert your Exchange Server 2003 CD. In the Welcome Exchange Server 2003 Setup page, click the Exchange
Deployment Tools link.

2. In the Exchange Server Deployment Tools screen appears, click the Deploy the first Exchange 2003 server link, 3. 4. 5. 6. 7. 8.
shown in Figure 4-1. The Deploy the First Exchange Server 2003 screen appears. Click the New Exchange Server 2003 Installation link. The New Exchange Server 2003 Installation screen appears. Click the Run DomainPrep Now link, which is in Step 7. Accept the EULA when prompted. Click Next. Enter the 25-digit product key when prompted. Click Next. The Component Selection dialog box appears. Note that the DomainPrep option is already selected. Click Next to begin the DomainPrep process. On the Completion screen, click Finish.

You can also run DomainPrep tool from the command line by entering f:\setup\i386\setup.exe /domainprep, assuming that volume F represents the correct location of the Exchange 2003 installation files

Installing the first Exchange 2003 computer With the ForestPrep and DomainPrep steps out of the way, and presuming that you've completed all of the other required prerequisite steps, you're ready to finally get down to business and install the first Exchange 2003 computer in your forest. The actual installation process is rather anticlimatic, assuming that you're not performing a cluster installation or an installation into an existing Exchange Server 5.5 organization, neither of which are discussed in this course. You have three options to select from in regards to the scope of the installation as detailed here: Typical: Installs the Messaging and Collaboration Services and the System Management Tools only.

Minimum: Installs the Messaging and Collaboration Services component only. Custom: Allows you to select only the components you want and is the only way to install all components.

To install the first Exchange 2003 server, follow these steps:

1. Insert your Exchange Server 2003 CD. In the Welcome Exchange Server 2003 Setup screen, click Exchange
Deployment Tools.

2. The Exchange Server Deployment Tools screen appears. Click the Deploy the first Exchange 2003 server link. 3. The Deploy the First Exchange Server 2003 screen appears. Click the New Exchange Server 2003 Installation 4. 5. 6. 7.
link. The New Exchange Server 2003 Installation screen appears. Click the Run Setup Now link, which is in Step 8. Accept the EULA when prompted. Click Next. Enter the 25-digit product key when prompted. Click Next. The Component Selection screen appears, as shown in Figure 4-5. Select an installation type by clicking the arrow below the Action label. You can also change the installation path for the Exchange binaries if desired. Click Next.

Figure 4-5: Component Selection screen. Enlarge image

9. The Installation Type screen appears, as shown in Figure 4-6. Select which type of installation you're performing.
In this case, select Create a new Exchange Organization. Click Next.

Figure 4-6: Installation Type screen.

10. The Organization Name dialog screen appears, as shownin Figure 4-7. Pick the Exchange organization name
carefully because you cannot change it later. This serves as the root of your Exchange organization. Click Next.

Figure 4-7: Organization Name screen.

11. The Licensing Agreement screen, shown in Figure 4-8, appears that explains how Exchange 2003 is licensed.
You must select the I agree that I have read and will be bound by the license agreements for this product option to complete the installation. Click Next.

Figure 4-8: Licensing Agreement screen.

12. The Installation Summary screen appears asking you to confirm your installation choices. When you're ready to
complete the installation, click Next.

13. When the installation is done, a Congratulations screen appears, informing you that the installation is complete.
Click Finish. After you've completed the installation, you might want to open the Exchange System Manager (click Start > Programs > Exchange > System Manager) to examine your newly created Exchange organization, as shown in Figure 4-9.

Figure 4-9: The Exchange System Manager Installing additional Exchange 2003 computers After you've completely installed the first Exchange 2003 computer in a domain, you can then easily install as many additional servers as you wish. The installation process for additional servers is virtually identical to that discussed previously for the first server, except that you'll be asked two additional questions during the installation process: Which administrative group do you want the new server to be a part of?

Which routing group within that administrative group do you want the new server to be a part of?

You're only asked these two questions if you've configured additional administrative and routing groups in your Exchange organization. Administrative groups and routing groups are covered in Lesson 6. Introduction to recipient objects In an Exchange organization, any object that interacts with Exchange server, either to send or receive e-mail is considered a recipient object. There are four types of recipient objects that you need to be aware of and understand as an Exchange administrator: Users Contacts Groups Public Folders

As part of the installation routine, new objects are added to the Active Directory schema and pre-existing objects, such as users, groups, and contacts, are modified by having their attributes changed and added to. You manage these objects using Active Directory Users and Computers just as you did before Exchange was installed. The only difference is that Active Directory Users and Computers has some new capabilities that did not exist before. Users User recipient objects can exist in one of three different states of messaging capability: No Exchange abilities: The user object has no ability to send or receive e-mail using the Exchange organization or to use any other Exchange messaging functionality. Mailbox enabled: The user object has a mailbox defined on an Exchange server within the Exchange organization and uses that mailbox to send and receive e-mail both internally and externally to the organization. The user is listed in the Global Address List, allowing other users to lookup the user's e-mail address and send e-mail to the user's mailbox. Mail enabled: The user does not have a mailbox defined on an Exchange server, but does have an e-mail address configured that references a mailbox located on an external server, such as a POP3 account provided by an ISP (Internet Service Provider). All e-mail is sent and received using this external account, although the user is listed in the Global Address List.

With the exception of the built-in Administrator account, all user objects that existed within the forest before the installation of Exchange 2003 are not mailbox-enabled or mail-enabled. After the installation is complete, you can configure one of these options if you want. User objects that are created after Exchange has been installed may be mailbox enabled as part of the object creation process if desired. You cannot mail enable a user object during its creation, but you can after do so manually after the user object has been created. User mailboxes are located in mailbox stores, which are located within storage groups. You find out more about stores and storage groups in Lesson 5. As mentioned previously, administration of Exchange recipient objects takes place from within the Active Directory Users and Computers console for the most part. Select a user object in Active Directory Users and Computers, right click, and then select Exchange Tasks to open the Exchange Tasks Wizard, which can be used to perform many useful Exchangerelated tasks, such as the following: Create a mailbox, which mailbox-enables the object Delete a mailbox Move a mailbox to a different server and mailbox store (or a different mailbox store on the same server) Establish an e-mail address, which mail-enables the user object Remove all Exchange attributes from the object Configure access to mobile services Configure access to protocols, such as HTTP, POP3, and IMAP4

A user object cannot be mailbox enabled and mail enabled at the same time.

Moving on In this lesson you performed the required steps to prepare the forest and domain for the Exchange 2003 installation. After that, you performed the installation of the first Exchange 2003 organization and got a brief introduction to Exchange recipient objects. In Lesson 5, you'll examine and work with storage groups, stores, and policies. Before you move on, do the assignment and tackle the quiz. If you have any questions, post them on the Message Board. Even if you don't have questions, it's worth visiting the Message Board to touch base with your instructor and see what your fellow students are up to.