Transitioning Exchange 2003 to VMware Virtual Exchange 2007 Using EMC CLARiiON or EMC Celerra

Transcription

1 Transitioning Exchange 2003 to VMware Virtual Exchange 2007 Using EMC CLARiiON or EMC Celerra Best Practices Planning Abstract This white paper describes the transition of a physical Exchange 2003 or 2000 environment into a virtual Exchange 2007 environment leveraging technologies such as VMware, and EMC CLARiiON and EMC Celerra. May 2008

2 Copyright 2007, 2008 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part Number H Best Practices Planning 2

3 Table of Contents Executive summary...4 Introduction...4 Audience... 4 VMware ESX Server overview...4 CLARiiON overview...5 Celerra overview...6 Why Microsoft Exchange Server 2007?...6 Planning the transition to Exchange Server Allocating CLARiiON or Celerra storage during the transition... 8 Option 1: Using existing capacity... 9 Option 2: Adding spindles for capacity... 9 Option 3: Adding a new storage array... 9 Configuring your ESX Server... 9 Virtual machine configuration... 9 CLARiiON storage configuration Celerra storage configuration Transitioning to Exchange Installation of Exchange 2007 server roles Client Access role Hub Transport role Mailbox role A transitioning example The Transition (step by step) Conclusion...18 References...18 Best Practices Planning 3

4 Executive summary It is important to note that there is no in-place upgrade to Microsoft Exchange 2007 from previous versions of Exchange. To perform this transition, you must install Exchange 2007 and move the mailboxes from your old messaging system to Exchange This is an opportune time to deploy Exchange 2007 into VMware s virtual environment and begin utilizing VMware s leading-edge technology. This white paper explains how to perform this transition. Introduction This white paper explains how to transition a physical Exchange 2003 environment into a virtual Exchange 2007 environment. It provides a detailed example, and discusses items to consider when making this transition with Exchange, VMware, and EMC CLARiiON and Celerra. Audience This white paper is for Exchange administrators and system architects who plan to transition from Exchange 2003 to Exchange The reader should have some basic knowledge of Exchange, VMware, CLARiiON, and Celerra. VMware ESX Server overview VMware ESX Server consists of virtualization software that provides server consolidation by allowing several instances of similar and dissimilar operating systems to run as virtual machines on one physical machine. This cost-effective, highly scalable virtual machine platform offers advanced resource management capabilities. VMware ESX Server minimizes the total cost of ownership of a computing infrastructure by: Increasing resource utilization Decreasing the number of servers and all associated costs Maximizing server manageability Best Practices Planning 4

5 Figure 1 shows the architecture of two VMware ESX Servers, ESX Server 1 and ESX Server 2. Figure 1. Architecture of the VMware ESX Server ESX Server 1 and ESX Server 2 run directly on the hardware. VMware provides a virtualization layer for each server. The virtualization layer supports guest operating systems (GOS), which in turn support different applications. The combination of a guest operating system and its applications is referred to as a virtual machine (VM). You manage ESX servers with a Management User Interface (MUI). Virtual Infrastructure Client, a VMware MUI, allows you to manage a number of ESX Servers, as well as to perform operations such as VMotion, VMware DRS, and VMware HA. CLARiiON overview The EMC CLARiiON family of networked storage systems brings best-in-class performance to the midtier with a wide range of storage solutions all based on the powerful, proven, eight generations of CLARiiON architecture. CLARiiON provides multiple tiers of storage (both Fibre Channel and ATA) in a single storage system, which significantly reduces acquisition costs and management costs by allowing multiple tiers to be managed with a single management interface. The CX3 UltraScale series CLARiiON systems can provide an end-to-end 4 Gb/s design that is optimized to deliver native 4 Gb/s performance. Products with multiple back ends, such as the CX3-40 and CX3-80, can support disks operating at both 2 Gb/s and 4 Gb/s simultaneously. CLARiiON storage systems address a wide range of storage requirements by providing flexible levels of capacity, functionality, and performance. The AX150 and AX100 are entry-level systems that consist of single- and dual-controller models. They provide raw capacities of 3 TB and connectivity for up to eight hosts. The CX3-20 provides up to 59 TB of raw capacity and connectivity for up to 128 high availability (HA) connected hosts. The CX3-40 storage system expands the family, supporting up to 128 HA hosts and raw storage capacities of up to 119 TB. The high-end CX3-80 adds even more capability, supporting up to 256 HA hosts and up to 239 TB raw capacity. For midsize environments that require the economy and familiarity of IP networking through iscsi host connectivity, while still providing fibre capabilities, the Best Practices Planning 5

6 EMC CLARiiON CX3-10c (c = combo arrays), CX3-20c, and CX3-40c storage systems are available to handle Fibre Channel and/or iscsi. Celerra overview The Celerra family delivers best-in-class availability, scalability, and performance from the midrange Celerra NS Series to the data-center class Celerra NSX gateway. A Celerra FC series provides the most cost-effective way to add enterprise IP storage capabilities to an existing CLARiiON or Symmetrix SAN. NS Series integrated (NS20, NS40, NS80) is the best choice for customers who want to package enterpriseclass IP storage for specific applications, departments, or locations. Advanced, scalable management software makes it easy for customers to access, manage, and optimize an entire IP storage infrastructure from a single console. Celerra is the leader in providing high availability without compromise, based on capabilities like an active-passive N+1 clustering architecture. With the Celerra NS Series integrated platforms based on the CLARiiON UltraScale architecture (NS20, NS40, NS80), customers are experiencing an industry first for a midrange: five 9s availability in the real world. Celerra offers the most comprehensive suite of built-in features that add significant value to VMware deployments, including snapshots, automated volume management, and thin provisioning. NAS, iscsi, and Fibre Channel connectivity in a single package give customers the greatest flexibility and investment protection. Celerra has focused on making the entire installation, deployment, and storage management process easier than ever. In virtualized server environments this becomes paramount. When users can deploy a new server in seconds, they also need to be able to deploy storage with the same efficiency. Why Microsoft Exchange Server 2007? By now, most of the Exchange community is familiar with the new features and enhancements in Microsoft s Exchange Features for replication have been added into Exchange such as Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), and Stand-by Continuous Replication (SCR) as part of Exchange 2007 SP1. These replication technologies, which are built right into Exchange, provide simple replication methods and in some cases provide high availability. Exchange 2007 requires a 64-bit architecture that provides better performance and scalability by utilizing servers CPUs, memory, and disk subsystems more efficiently. Administration changes in this design allow you to install different roles that provide different features. Roles include the following: Mailbox Provides storage of all messages and scheduling services for Outlook clients. Client Access (CAS) Allows clients to connect through Outlook Web Access (OWA), POP, IMAP, and other devices. Hub Transport (HUB) Provides routing for purposes within Active Directory. Unified Messaging (UM) Provides connectivity to telephony. Edge Transport (Edge) Provides SPAM filtering and antivirus protection, and enforces messaging security policies. This version of Exchange is the first of its kind to provide a new management shell interface, called PowerShell, that allows administrators to quickly create many types of scripts that automate tasks. Exchange 2007 provides a robust, collaborative messaging platform that far exceeds its predecessors. Most customers have probably already started thinking about transitioning to Exchange 2007 for several reasons, such as: Support for earlier versions of Exchange will eventually diminish. Problems in earlier versions make it beneficial to restructure and transition sooner. Best Practices Planning 6

7 They need features that Exchange 2007 provides. Planning the transition to Exchange Server 2007 It is important to ensure that everything is in order before beginning the transition to Exchange This means ensuring that the current Exchange 2003 environment is problem free, and being aware of what can co-exist between Exchange 2007 and Exchange To help do this, run Microsoft Exchange Best Practice Analyzer (ExBPA), which can be found on Microsoft s website, to make sure that your Exchange 2003 is functioning correctly. This helps verify that your current environment is error free and flags anything that is not correct. You also need to make sure that the following requirements for Active Directory are met when planning a transition to Exchange 2007: The AD sites that will be hosting Exchange 2007 must have an AD global catalog server that is running Windows Server 2003 SP1. The domain controller (DC) hosting the schema master must be running Microsoft Windows Server 2003 Service Pack 1. The Active Directory (AD) functional level must be set to Windows 2000 or higher, as shown in Figure 2. Figure 2. Active Directory functional level Following are the Exchange organizational requirements for planning a transition to Exchange 2007: Microsoft Exchange 2007 cannot co-exist with Exchange 5.5 (or an earlier) version. Microsoft Exchange 2003 servers must be running service pack 2. Microsoft Exchange 2000 servers must be running service pack 3. Microsoft Exchange organization operation mode must be set to Native Mode (no pre-exchange 2000 servers) as shown in Figure 3. Best Practices Planning 7

8 Figure 3. Operation mode setting prior to transition The following are legacy features (from both Exchange 2000 and Exchange 2003) that are no longer available in Exchange Server 2007: Lotus Notes Connector GroupWise Connector X.400 Connector Microsoft Mail Connector CC: Mail Connector Instant Messaging Service Key Management Service Exchange Chat Services Exchange 2000 Conference Server Microsoft Mobile Information Server To maintain these types of features that are not supported in Exchange 2007, you need to maintain at least one legacy Exchange server in your Exchange configuration. Proper planning is important to make sure that all features can be supported during the transition, and are decommissioned when the feature is no longer necessary. If maintaining these physical servers is cumbersome, you can use VMware Converter to move your physical machine into a virtual machine; this option can consolidate these legacy server features and provide a cleaner way to decommission the server when the feature is no longer needed. Allocating CLARiiON or Celerra storage during the transition Being able to perform an in-place upgrade to Exchange 2007 would have alleviated any concerns about allocating enough storage during the transition process. However, since the only procedure available is a transition from your old legacy Exchange environment to Exchange 2007 using mailbox moves, you need to allocate enough storage to concurrently support the new Exchange 2007 environment and the old legacy environment. In other words, you need to configure at least double the amount of storage during the transition phase. There are a few ways this procedure can be handled, each having advantages and disadvantages. Best Practices Planning 8

9 Option 1: Using existing capacity If your existing storage subsystem has enough capacity and spindles to support the new Exchange 2007 environment while the CLARiiON/Celerra Exchange 2003 is still running, then carving up the array s additional spindles is an option. There are many things that need to be considered, such as the size of the mailboxes in the new Exchange 2007 environment. Following the Exchange 2007 best practices guidelines will help in this planning process. Option 2: Adding spindles for capacity If your existing storage subsystem does not have enough capacity and spindles to support the new Exchange 2007 environment while the legacy Exchange 2003 storage is still running, then adding additional disk shelves to your existing CLARiiON or Celerra subsystem is another approach. It is best to carve up the array s added spindles to take best advantage of the new capacity; decommission the old Exchange 2003 environment, destroy all LUN configurations, and then move the new Exchange 2007 environment from the temporarily storage shelves to the spindles that contained the Exchange 2003 data. Array technologies, such as LUN migration on CLARiiON or iscsi clones on Celerra, can lessen the impact of this process. Option 3: Adding a new storage array This could be the perfect time to upgrade your storage array to EMC s cutting-edge CX3/NS Series array. Having two storage arrays prevents the added planning of juggling and manipulating space on the existing system to perform the Exchange transition. If this option is chosen, carve up the array following Exchange 2007 best practices, and perform the transition to the newly configured CX3/NS Series subsystem. During the planning phase, storage is an extremely important piece of the migration to consider. A simple test shows that if you move a 100 MB mailbox from Exchange 2003 to Exchange 2007, you will grow the Exchange 2007 target EDB file 100 MB more in size and you will generate 100 MB in Exchange log files (when circular logging is not enabled). This is important to note when you consider sizing the Exchange 2007 environment for storage. Configuring your ESX Server Before transitioning from a physical Exchange 2003 environment to a virtual Exchange 2007 environment, you must plan the hardware configuration for the ESX Server, how the server s VMs will share resources, and how the storage will be laid out and presented to the VMs. If you are using Intel microprocessors, you will have to verify that your Intel CPU is VT-enabled before installing a 64-bit OS onto a VM. Your CPU might support this feature; however, the BIOS will not allow you to enable it. To resolve this issue, there may be a BIOS update available that allows you to enable the feature on the system. (The References section provides more information on lists of supported processors.) REV F of AMD processors is required and comes VT-enabled. NOTE: The information provided in this paper is based on tests conducted in EMC s labs. The configuration of the lab is described in the following sections. More information about sizing Exchange 2007 in virtual environments will be publicly available at a later point in time. Virtual machine configuration Our tests of a physical Exchange 2007 environment supporting 4,000 users reveal the optimal physical amount of RAM for the Mailbox role is 16 GB; increasing RAM beyond 16 GB had diminishing returns at which the return outweighed the increase of cache in the system. This is perfect for a single Exchange server transition scenario into a VM. With ESX Server the configurations are endless; for example, you can create one VM to support all 4,000 users or create four VMs to support 1,000 users per GOS. Decisions about how to carve up your ESX Server, and the different types of virtual software to use, should be directly correlated to your service level agreements (SLAs). However you slice your virtual Exchange 2007 environment, it is important to make Best Practices Planning 9

10 sure that you provide enough hardware for each GOS to support the number of users the GOS will be running. In our lab we had a dedicated ESX Server for our Mailbox server role that consists of two dualcore Intel Xeon processors at 2.4 GHz, with 16 GB of RAM. We configured a single VM hosting a GOS to support 4,000 Exchange 2007 users. The CAS and HUB roles should be hosted in a GOS on their own VMs, but configured together on the same ESX Server. However, you should dedicate an ESX Server for your Mailbox role to avoid resource contention. You also need to decide whether to use two or more ESX Servers in a clustered fashion so that your VMs can be configured to leverage VMware HA and VMware DRS. Again SLAs should help you decide what is appropriate. The VM that will be hosting your CAS GOS should contain at least 4 GB of RAM. The VM that will be hosting your HUB should contain at least 4 GB of RAM, thus the ESX Server hosting these two VMs should have at least 8 GB of RAM. The newest processor speeds can handle both of these roles on the same ESX Server. A popular configuration used in the labs that host the CAS and HUB roles consists of a single server with two dual-core Intel Xeon processors at 2.4 GHz with 8 GB of RAM. In our test lab, we had two ESX Servers clustered to leverage VMware HA and DRS technology. The ESX Server with 16 GB of RAM was dedicated to the Mailbox role, while the other ESX Server with 8 GB of RAM hosts both the CAS and HUB roles. In some cases, it is better to have both servers contain the same amount of RAM at 16 GB, but a lab environment does not need this extra expense. To maintain HA it is best to have at least two HBAs and at least two NICs per ESX Server in case one hardware device fails. CLARiiON storage configuration When connecting an ESX Server to a CLARiiON storage system, LUN masking (using Access Logix ) must be enabled on the CLARiiON storage system. CLARiiON assigns the LUNs to the ESX Server and not directly to the VM; after the LUNs are presented to the ESX Server they can then be presented to a VM (at that point, the LUNs are referred to as virtual disks). Virtual disks that are assigned to the ESX Server are not automatically assigned to a specific VM. Using Virtual Infrastructure Client, the management user interface for ESX Server, you can assign virtual disks to the individual virtual machines. Of the storage options described in the previous section Allocating CLARiiON or Celerra storage during the transition, we chose option number 3, adding a new storage array. We had the physical Exchange 2003 environment connected to a CX500 while the virtual Exchange 2007 was connected to a CX3-40, thus the transition was to a newly configured CX3-40. R DB2 R DB3 R DB4 R DB5 R DB1 Shelf 0_2 Shelf 1_1 UNUSED R SG1 & 2 LOGS R SG3, 4, 5 LOGS Shelf 0_0 Figure 4. Exchange 2007 disk layout when transitioning to CX3-40 Best Practices Planning 10

11 NOTE: The layout in Figure 4 was chosen based on the constraints of the lab environment. Best practices will always suggest providing a hot spare per shelf, and this layout has no hot spares defined. Again, a lab environment can arguably eliminate the need for hot spares. In Figure 4, all the LUNs are dispersed evenly between the two storage processors on the CX3-40 array; each R RAID group contains a single DB LUN. The R RAID group holds two Exchange LOG LUNs, and the R holds three Exchange LOG LUNs. All disks in the illustration are 146 GB 15k rpm fibre drives. All DB LUNs are 200 GB and all Log LUNs are 50 GB. The GOS s boot volume should be located on a separate CLARiiON LUN presented through ESX as a VMFS virtual disk. The amount of VMFS disks that can be carved out of a single CLARiiON LUN and used for the GOS boot volume is directly correlated to the number of spindles and the load the OS incurs, so plan accordingly. We configured a single CLARiiON LUN to host the three GOS boot volumes as VMFS virtual disks to avoid contention with the Exchange data. However, in some cases it is better to dedicate each GOS to their own set of spindles unless enough spindles have been allocated up front to handle the OS s I/O demands. When presenting the LUNs to the GOSs that will be holding the Exchange data, you need to consider how they will be used so that you can present them correctly. For example, if you plan to use Replication Manager, present the Exchange LUNs to the GOS as Raw Device Mapping (RDM) devices (using iscsi array capabilities and using the MS iscsi Initiators within the VM allows for the use of VMFS with RM). RDMs present the entire device to the GOS, acting as a pass-through by passing the ESX Server directly to the VM. This helps administrators avoid overloading a set of spindles by placing multiple VMFSs on a single LUN. If you plan to use VMware technology, such as Virtual Infrastructure Client cloning and VMware Consolidated Backup (VCB), then VMFS will work best. When creating VMFS on the LUNs for Exchange, it is best to use the entire device (as to not share the capacity with another GOS which may impair performance). NOTE: The size of LUNs should follow Exchange 2007 best practices guidelines to accommodate white space, mailbox sizes, deleted item retention, online defragmentation, and so forth. Celerra storage configuration In this test we use option number 3, which is described in the section Allocating CLARiiON or Celerra storage during the transition. The physical Exchange 2003 environment is connected to a NS500, and virtual Exchange 2007 is connected to a NS40, thus the transition will be to a newly configured NS40. In the Celerra NS40 used in this testing, two shelves of FC drives run Exchange 2007 and back up the Exchange 2007 databases. This testing uses a building block approach. This building block is two log spindles and four database spindles. The configuration tested uses two times the building block. This is shown in Figure 5: Best Practices Planning 11

12 Figure 5. Exchange 2007 disk layout when transitioning to NS40 In Figure 5, the two Celerra dvolumes in RAID group (RG) 8 are placed in a Celerra user-defined storage pool named LogSG1_SG2. The Celerra file system used for storing the Exchange Logs for Storage Group 1 and Storage Group 2 is created from the LogSG1_SG2 storage pool. If the desired file system size is larger than the capacity of a single dvolume, Celerra will automatically concatenate the two dvolumes. Similarly, the two Celerra dvolumes in RG 9 are placed in the Celerra user-defined storage pool LogSG3_SG4 to store the Exchange logs for Storage Groups 3 and 4. For the Exchange database, the two Celerra dvolumes in RG 10 are concatenated with a Celerra metavolume. Similarly, the two Celerra dvolumes in RG 11 are concatenated with a Celerra metavolume. A Celerra stripe volume with a stripe size of 32 KB is then created across these two metavolumes. This stripe volume is placed in a Celerra user-defined storage pool named DbSG1_SG2. The Celerra file system used to store the Exchange database for Storage Groups 1 and 2 is created from the DbSG1_SG2 storage pool. Similarly, a Celerra user-defined storage pool named DbSG3_SG4 is created from dvolumes RG 12 and RG 13 to store the Exchange database for Storage Groups 3 and 4. The iscsi LUNs are created from the files systems that were created from these pools, and are then presented to the VM. In this example, the GOS s boot volume is located on a local device connected to the ESX Server. Whether the GOS is located locally or on the Celerra, it is important that enough spindles are allocated to handle the load that the OS incurs, so plan accordingly. NOTE: The LUN sizes adhere to Exchange 2007 best practices guidelines so that they have room for white space, mailbox sizes, deleted item retention, online defragmentation, and so forth. Transitioning to Exchange 2007 After your VMware ESX Server is configured with VMs all running the 64-bit version of Windows Server 2003, the next step in the transition process is to begin installing the different Exchange 2007 Server roles. As mentioned earlier, an Exchange 2007 deployment consists of three to five different server roles. The Client Access role is the first server role to be installed, followed by the HUB, then finally the Mailbox server role. The Edge and UM roles can be installed later, if at all. If installing the Edge server role, it has Best Practices Planning 12

13 to be installed on its own VM. The Mailbox role should also be installed on its own VM. However, to really take advantage of VMware, it is best to separate each role within its own VM. Installation of Exchange 2007 server roles Client Access role The Client Access (CAS) role must be installed first. To best leverage VMware technologies, the CAS should exist in a separate GOS from the Mailbox role, but it can reside on the same GOS as the HUB Transport role. Begin by running the Exchange 2007 setup on the designated GOS that will host the CAS role. A number of prerequisites need to be installed before setting up the CAS role. Figure 6 illustrates how to configure the CAS role. Figure 6. Installing the Client Access role Hub Transport role After you have installed the CAS role, you can install the Hub Transport (HUB) role. Depending on your configuration, you can install the HUB along with the CAS. However, as mentioned earlier, we recommend that you install this role on a GOS separate from the GOS on which you installed the CAS role. This isolates the programs each GOS is running, which leverages VMware technologies more efficiently. Next, install Exchange 2007, this time selecting the Hub Transport Role, and continue with an installation that is nearly identical to the CAS role installation. Best Practices Planning 13

14 Mailbox role The Mailbox role should be installed in its own GOS, due to the amount of memory and processing power that this type of role consumes. To start this process, run the Exchange 2007 setup and select Mailbox Role. In this example we are performing a transition to Exchange 2007 from legacy versions of Exchange, thus during setup specify the same Exchange Organization in which the legacy servers exist, as shown in Figure 7. Figure 7. Selecting the Exchange Organization for Exchange 2007 to be installed into After finishing the installation of Exchange 2007, you are ready to carve up the Exchange 2007 server to support the migration process. A transitioning example In this example, the Exchange 2003 configuration consists of 4,000 users in a configuration with: Four Exchange Storage Groups Five DBs per SG 200 users per DB or 1,000 users per SG Average ~100 MB Mailbox size The Virtual Exchange 2007 environment will be configured: Best Practices Planning 14

15 To reside on a single VM within the ESX Server with 16 GB of RAM As five Exchange Storage Groups (SLAs and backup windows should dictate how many Exchange Storage Groups to configure; our lab environment was limited in the number of spindles thus the reason for choosing five Exchange Storage Groups) With one DB per SG With 800 users per DB With these LUN sizes: o DB LUN sizes are all 200 GB o LOG LUN sizes are all 50 GB The Transition (step by step) It is important to list the users that you plan to transition to Exchange 2007, and the location of the users from a disk perspective. When transitioning users the mailbox move can handle four users per instance of the move mailbox application. It is conceivable that by pulling users from different Exchange Storage Groups (which should be on different spindles), faster transition rates can be achieved because more spindles are being used. In our test, the transition consisted of one Exchange 2003 Storage Group at a time (within one mailbox move instance), which means the rates we achieved were not the best that we could have achieved. From within the Exchange 2007 management interface, highlight the legacy users you would like to transition and select Move Mailbox in the right-hand actions pane. This opens the Move Mailbox: Introduction dialog box shown in Figure 8. Figure 8. Move Mailbox: Introduction dialog box Select the new Exchange 2007 server, Storage Group, and Database into which you plan to move these legacy users. Click the next icon to open the Move Options dialog box, in which you specify how corrupt messages will be handled during the transition, as shown in Figure 9. Best Practices Planning 15

16 Figure 9. Move Mailbox: Move Options dialog box After specifying the desired options, click next to open the Move Mailbox: Move Schedule dialog box, shown in Figure 10. Figure 10. Move Mailbox: Move Schedule dialog box Scheduling options allow you to either perform the move immediately or to schedule the move for a later time. In this example, we are performing the move of 100 users at a time immediately. Click next and a confirmation opens. Check the confirmation summary and begin the transition by clicking Move. When the move completes, you will receive the Move Mailbox: Completion dialog box shown in Figure 11. Best Practices Planning 16

17 Figure 11. Move Mailbox: Completion dialog box As you can see, to move 100 user mailboxes (averaging 100 MB in size) took just over one hour to complete. It is important to note that this mailbox move process can be performed via an Exchange commandlet, as well as through the GUI as shown above. It is also important to understand that this move generates an equivalent EDB and log files for the size of the mailboxes being moved. For example, when moving a single 100 MB mailbox, it generates MB Exchange log files for 100 MB total, and it grows the Exchange Database file to 100 MB in size as well. Enabling circular logging on the target server reduces the log space required but could slow the transition process down. The following is an example commandlet to move mailboxes: Get-Mailbox -Database userx\sg1\db1 Mov box configurationonly - TargetDatabase e2k7vm1\sg1\sg1db1 Best Practices Planning 17

18 Conclusion Since there is no in-place upgrade to Exchange 2007, building an Exchange 2007 virtual infrastructure on 64-bit systems makes lots of sense. Several organizations have already virtualized Exchange 2003 successfully, and now with the opportunity to transition from a physical environment to a virtual environment, your organization can begin to utilize the capabilities of VMware technology in addition to its added savings benefits. This white paper shows how this transition can be accomplished, and discuses things you need to consider when deploying Exchange 2007 into a virtual infrastructure. References The following can provide more information: For more on CPUs supporting virtual technology for x64-based GOSs: Compare the Intel Xeon Processor Family page on Intel.com Product Information page on AMD.com Support policy for Microsoft software running in non-microsoft hardware virtualization software On Powerlink, EMC s password-protected extranet for partners and customers: CLARiiON Integration with VMware ESX Server white paper Using EMC Celerra IP Storage with VMware Infrastructure 3 over iscsi and NFS - Best Practices Planning white paper Best Practices Planning 18