This Exchange 2003 Guidelines document is a work in progress, and is current as of May 5, 2004.

Transcription

1 This Exchange 2003 Guidelines document is a work in progress, and is current as of May 5, 2004.

2 docad.cgiar.org Home Exchange 2003 Site Map Exch 2003 Site Map System-wide Policies - open for review Architecture Overview Policies Based Upon Constraints Prerequisites to the first center Exchange 2003 Upgrade Preparation of the Root at CGNET Active Directory Coverage Policies Applicable to Exchange Sites That Have Not Yet Migrated to AD Connection Agreements Cleanup Server Placement Policies Based Upon Recommendations System-Wide Migration Goal Center AD Status for Local Adoption of Exchange 2003 Center Migration Policy Prerequisites to Exchange 2003 Upgrades Center Migration Upgrade Path Root Policies Center Policies Routing Center Policies Security Addressing Routing Policy Options Star via Hub Mixed Mesh Implementation Guidelines - to be posted May 5 Document revision history 4/21/04 Initial release

3 docad.cgiar.org Home Exchange 2003 Guidelines Exch 2003 Site Map System-wide Policies - open for review Implementation Guidelines - to be posted May 5 Exchange 2003 Site Map Active Directory Guidelines Specification of Architecture Policies Overview Best Practices Recommendations for Centers Case Histories from the CGIAR Centers Active Directory Site Map Document revision history 4/21/04 Initial release - Exchange 2003 Guidelines 3/18/03 Initial release - Active Directory Guidelines Copyright 2004 docad.cgiar.org

4 Copyright 2004 docad.cgiar.org

5 docad.cgiar.org Home Exchange 2003: System-wide Policies Exch 2003 Site Map Architecture Overview Policies Based Upon Constraints Policies Based Upon Recommendations Routing Policy Options Home Exchange 2003: Implementation Guidelines Document revision history 4/21/04 Initial release Copyright 2004 docad.cgiar.org

6 docad.cgiar.org Home Exch 2003 Site Map Prev Next Exchange 2003: System-wide Policies Architecture Overview The CGIAR is transitioning its Exchange organization from reliance on Microsoft Windows NT and Exchange 5.5 to Windows 2003 and Exchange The essential first step was to upgrade from Windows NT to Windows 2000 and Active Directory ( AD ), which was started in 2003 and is currently over half complete. At present, two centers use Windows 2003 with AD, most use Windows 2000 with AD, some use Windows NT, and all use Exchange 5.5. In contemplating the next step, upgrades to Windows 2003 and Exchange 2003 must be sequenced carefully. With multiple Windows and Exchange versions available, there are many combinations possible. With many CGIAR sites that have independently scheduled upgrades, it is important to make a few architectural choices from the start to limit the complexity and maximize the integrity of the resulting Exchange organization. The CGIAR decided to leapfrog over Exchange 2000 into Exchange 2003, which helps considerably to reduce the potential upgrade effort and system complexity. In addition, to preserve the full functionality of Exchange 2003, Microsoft suggests that a site upgrade its Windows Active Directory Domain Controllers to Windows 2003 before upgrading to Exchange Any time thereafter, it can upgrade from Exchange 5.5 to Exchange The result of these two choices leads us to anticipate four site configurations that must co-exist in the CGIAR organization as it upgrades. In this list, Windows 2000 indicates a site where all domain controllers are running Windows 2000 with AD, and Windows 2003 indicates a site where all domain controllers are running Windows 2003 with AD: 1. Windows NT with Exchange Windows 2000 with Exchange Windows 2003 with Exchange Windows 2003 with Exchange 2003 There is another configuration listed here that deserves special comment: Windows 2003 with Exchange As part of an upgrade-in-place of a site from Exchange 5.5 to Exchange 2003, a site may choose to upgrade to Exchange 2000 and then immediately upgrade to Exchange This would be a temporary step, however, lasting perhaps hours, and would not be visible to the rest of the organization. Based on Microsoft s recommendations and CGNET s in-house testing, the diagram below shows how information may flow among sites in these four configurations. (Click on diagram to view larger version.)

7 There are some functions in Exchange 2003 that are available only in Exchange 2003 Native Mode, which is achieved when all sites run Exchange 2003 and there are none left running Exchange 5.5. (This corresponds to having only one configuration in the organization instead of the four that will be supported.) For example, query-based distribution groups can be created only in Exchange 2003 Native Mode. These groups will probably be quite useful for address list manipulation in the CGIAR. As a result, while each site will independently schedule its own upgrade process, there will be benefits to the conversion of all sites. In addition, there are complications when some sites are running NT and Exchange 5.5 while others run Exchange 2000 or There is an object duplication problem: when Exchange 5.5 and Exchange 2000/2003 co-exist, an Active Directory Connector duplicates directory information from an Exchange 5.5 in an NT4 domain to a separate AD domain. Microsoft has confirmed that duplicate objects will remain in the AD when an NT site upgrades to AD while the Active Directory Connector exists. In other words, Microsoft has made a clean upgrade out of Exchange 5.5 possible when all sites in an organization first upgrade to Windows 2000/2003 with AD. If an Exchange organization upgrades before its Windows NT sites upgrade to Active Directory, there will be problems in the AD that must be fixed manually, object-by-object. This problem could be avoided completely if the CGIAR supported only three configurations in its architecture instead of four i.e., if it all sites stayed with Exchange 5.5 until the last site upgraded to Windows 2000 or 2003 with Active Directory. However, given the diversity of CGIAR sites, this solution is not very appealing. Fortunately, the object duplication problem is proportional to the size of the NT sites. If the sites with the most directory objects upgrade to Windows 2000 or 2003 with Active Directory, the problem is minimized. As a result, the policies below will encourage the

8 largest sites to adopt Active Directory before the first Exchange upgrade takes place. One final issue concerns the flow of messages among Exchange 2003 servers. There are a few options that are left to the CGIAR to decide on as a group. This is covered in section 4, Routing Policy Options. Document revision history 4/21/04 Initial release Prev Next Exchange 2003: System-wide Policies Copyright 2004 docad.cgiar.org

9

10 docad.cgiar.org Home Exch 2003 Site Map Prev Next Exchange 2003: System-wide Policies Policies Based Upon Constraints CGNET strongly recommends adoption of all policies in this section. The first two items are prerequisites to the first center s upgrade to Exchange To maintain the project schedule, CGNET requests that these first two polices, Preparation of the Root and Active Directory Coverage be reviewed and finalized by 5 May. Prerequisites to the First Center Exchange 2003 Upgrade Preparation of the Root at CGNET CGNET extends forest schema for Windows 2003 and replicates to all domains (done). CGIARAD.ORG root domain raised to Windows 2003 functional level. CGNET extends forest schema for Exchange Exchange 2003 server installed in Nochub Exchange site at CGNET. Active Directory Coverage The migration of the first center to Exchange 2003 should not occur before all the remaining Headquarters sites and any Remote sites having over 100 users have migrated to AD. This corresponds to 90% or more of the users. Policies Applicable to Exchange Sites That Have Not Yet Migrated to AD Connection Agreements One-way AD connectors will be installed between all remaining non-ad domains and the CGIARAD.ORG domain. Connection Agreements will be created for mailboxes only, with NO Connection Agreements to be created for Public Folders. This is to be done before the upgrade of any center sites to Exchange Cleanup NT centers will work with CGNET on cleaning out residual objects resulting from installation of AD Connectors in a mixed

11 NT/Exchange 2003 environment. This cleanup will be done during the site s AD upgrade process. Server Placement 1. In remote offices that service more than 10 users, one Window 2003 global catalog server must be installed in each physical location that contains Exchange 2003 servers. Deploying two Windows 2003 global catalog servers for redundancy is ideal. If a physical site does not have two global catalog servers, existing domain controllers should be configured as Windows 2003 global catalog servers. 2. At least one Windows 2003 global catalog server must be installed in each domain that contains an Exchange 2003 server. Document revision history 4/21/04 Initial release Prev Next Exchange 2003: System-wide Policies Copyright 2004 docad.cgiar.org

12 docad.cgiar.org Home Exch 2003 Site Map Prev Next Exchange 2003: System-wide Policies Policies Based Upon Recommendations System-Wide Migration Goal CGNET encourages eventual migration of entire CGIAR to Exchange Removal of all Exchange 5.5 servers is required for raising level of organization to Exchange 2003 Native Mode. Query-based distribution groups cannot be created until organization is in Exchange 2003 Native Mode. Center AD Status for Local Adoption of Exchange 2003 Before a Headquarters center migrates their Exchange 5.5 to Exchange 2003, all their field sites should be migrated to Active Directory. (This will do much to minimize the object duplication incurred by mixed Exchange 2003/NT environments). Center Migration Policy Prerequisites to Exchange 2003 Upgrades 1. Center switches domain to Windows 2000 Native mode. 2. Center preps their domain for Windows 2003 and waits at least one day for replication. 3. Center upgrades all DCs to Windows Center installs Windows 2003 support tools. 5. Center raises domain functional level to Windows Center Migration Upgrade Path 1. Recommended path: Center joins new Exchange 2003 server to existing exchange site and migrates objects to new server. 2. In-place upgrade is also supported, although not the recommended path. (Note: Direct upgrade of Exchange 5.5 server to Exchange 2003 is not possible. In-place upgrade requires Exchange 2000 license in addition to Exchange 2003 license or upgrade.) 3. External upgrade i.e., creating a server in a new site is not supported. Root Policies 1. Handling of mail from external sources to be continued in same manner as it is currently: All mail from external sources virus scanned at CGNET mail switch All mail from external sources spam filtered at CGNET mail

13 switch All mail from external sources chronoed at CGNET mail switch 2. CGNET will maintain a DNS entry for each center such that outlook.center.cgiar.org always refers to the center's OWA server. Center Policies Routing 1. The SMTP Connector is recommended for connecting between Routing Groups in the CGIAR Exchange organization. 2. SMTP Service of center s Exchange 2003 server should be configured to allow relay from Authenticated Users. This will allow center s remote users and travelers to use their center s Exchange server for outbound SMTP. Center Policies Security 1. All Exchange servers protected with Server Antivirus software. 2. All Exchange Information store servers protected with mailbox scanning Antivirus software. 3. SMTP Service of center s Exchange server should be configured to allow connections only from CGNET Messaging IPs (mailswitch hubs and Exchange 2003 exchange server, and, in the case of inter-center connections, these particular Exchange site servers as well) in addition to the relay from authenticated users. Centers should configure their firewalls to allow port 25 traffic from the CGNET Messaging IPs (mailswitch hubs and Exchange 2003 exchange server). 4. All Exchange Information stores should be backed periodically during the day using a backup software which supports Volume Shadow Copy service. 5. Windows update should be executed periodically. Addressing 1. Initially addressing will continue to be site-based, as user@center.exch.cgiar.org. 2. At some point internal Exchange addressing will be switched to user@cgiar.org addressing and the Dirmaster role for CGIAR addressing eliminated. This will be done at a particular threshold, when at least 75% of users have migrated to Exchange Because this has to be done at every center in the organization, and is somewhat labor intensive, this should not be done during the early stages of the Exchange migration. Note - In moving to user@cgiar.org addressing, the usernames must be unique in the entire organization, and care must be taken to ease the transition for any usernames that need to be modified to accommodate this requirement. 3. An initial set of Address Book Views will be created from the CGIARAD root. The Address Book Views that are currently available in Exchange 5.5 do not translate to the Active Directory, but need to be created independently in the Active Directory. An Address Book View

14 4. container will be created for each CGIAR center - based upon the center.exch.cgiar.org internal address. This will allow the creation of Address Book Views without the need for adding attributes to any user accounts. The centers will also have the permissions to create additional Address Book Views as needed. The CGNET Members container holds custom recipients for members of other organizations, and for CGIAR staff (or ex-staff) who have non-exchange addresses. It is maintained by dirmaster@cgnet.com. The CGIAR has been moving toward phasing out the CGNET Members address list. CGIAR Exchange users were removed from CGNET Members in Several organizations are restricting distribution of their address lists, and have left the CGNET members list. Many addresses maintained in the list are never used and can be safely removed. Dirmaster functions will be discontinued eventually with the switch to user@cgiar.org addressing. In the long run, CGIAR centers will maintain and share external addresses through their own contacts lists in AD and Exchange. Initially, it will be necessary to replicate the Exchange 5.5 CGNET Members container to the Active Directory, in order to prevent having Exchange 5.5 addresses that are not repliable by Exchange 2003 users. CGNET is reviewing the addresses still in use and planning to phase out most of them at the start of the Exchange 2003 upgrade. The others can be phased out as Centers adopt Exchange Document revision history 4/21/04 Initial release Prev Next Exchange 2003: System-wide Policies Copyright 2004 docad.cgiar.org

15 docad.cgiar.org Home Exch 2003 Site Map Prev Next Exchange 2003: System-wide Policies Routing Policy Options The CGIAR should adopt a system-wide policy on routing. CGNET can support a range of policies, at the CGIAR s request, among Exchange Routing Groups in the Organization. There are three good options. In a star, all mail leaving a site would pass through the CGNET NOC (as it does today). In a mesh, every site could send directly to every other site. In a mixed configuration, each site could choose on its own. The following table describes these routing options with their advantages and disadvantages in terms of four features. Three stars indicates the most complete implementation of the feature, one star indicates the least. Star via Hub The configuration in which all centers smart-host their traffic to CGNET would result in all inter-center traffic getting chronoed once all the centers were moved to Exchange (Like today, traffic originating from Exchange 5.5 sites would not be chronoed.) Once all centers have migrated to Exchange 2003, having 100% smart-hosting via the CGNET NOC would permit certainty about whether a message could be replayed from the chrono all messages leaving all servers would be chronoed. Under a star configuration, when one center is down it would not impact any other center s outbound queues because all the queues would be managed at CGNET. Message routing would be predictable and the message tracking would be simple: a single check at the NOC would tell what happened to any message.

16 CGNET would be able to put in blocks centrally to defuse inter-center virus storms. Mixed If routing options are left to each center, some sites may send their inter-center traffic via the NOC while others will send it directly. As a result, some inter-center messages will be chronoed, while others will not. In a mixed configuration, centers that smart-hosted their traffic to CGNET would not, in terms of their outbound queues, feel the impact of another center being down because the queuing would be handled by CGNET. The centers that used connectors to other centers could, on the other hand, be impacted. Connectivity routing would be more difficult to predict and message tracking more complex. For example, a message sent from one center to all DG s would travel different paths for the different DGs, involving site administrators at some centers as well as the CGNET NOC. CGNET would have limited access to assist with controlling inter-center virus storms. Mesh In a mesh configuration, each center could send its traffic directly to any other center using SMTP. The central advantage would be speedier inter-center deliveries. In addition, should a center s link to CGNET be down, it might be able to send to destination centers directly or even route all mail via another center. The only messages chronoed at the NOC would be those arriving from the Internet. This is similar to the situation existing today, in which most inter-center traffic travels via X400 and does not pass through the CGNET chrono. (Under Exchange 2003, travels via SMTP, and thus can be captured for chrono retention and replay.) In a mesh, all centers would manage their own outbound queues of mail that could not be immediately delivered. If a center were down for a few days, traffic would queue up at every center with connectors to that center. Message tracking would be more complex. Checking for arrival and delivery could require checking with other site administrators. CGNET would have little access to assist with controlling inter-center virus storms. Document revision history 4/21/04 Initial release Prev Next Exchange 2003: System-wide Policies Copyright 2004 docad.cgiar.org