Frequently Asked Questions

Transcription

1 Frequently Asked Questions Priasoft Migration Suite for Exchange Table of Contents Q: Can Priasoft pre-stage or trickle or synchronize mailbox data to the target environment?... 2 Q: How does Priasoft handle mailbox folder delegates?... 6 Q: How does Priasoft help with co-existence?... 8 Q: Does Priasoft handle Free/Busy Synchronization? Q: Does Priasoft help with a Domain Migration? Q: How much time will an Exchange Migration consume? Q: In what order should I perform the migration? Q: How does the Mailbox Migrator match source account to target accounts? Q: How does the Mailbox Migration Manager handle corrupted s? Q: Are there features of a mailbox that are not migrated? Q: How does the Public Folder Migration Manger migrate permissions? Q: How does Priasoft handle Outlook s Nickname Cache? PHONE WEB support@priasoft.com

2 2 Q: Can Priasoft pre-stage or trickle or synchronize mailbox data to the target environment? Explanation of terms: Trickle: The ability to slowly move mailbox data, on background threads, to the target mailbox before the user actually starts using the new mailbox. The concept is to move a large bulk of user mail data forward, prior to the new mailbox s use, and on migration day, cutover the user to the new mailbox and bring over any unsynchronized data during the cutover. A: Priasoft does not currently trickle mail data. This ability is actually EXTREMELY misleading and should not be casually accepted. Please consider the following: All other factors being equal, if it takes 1 hour to migrate 72,000 items and there are 7.2 million items to be migrated, it will take 100 hours to migrate all of the data. Trickling the data does not make a migration perform faster. In most cases it will actually run slower because the work is being done during idle time and has more work to do than just a direct copy of data. Consider the following concepts that are required for any kind of synchronization of data: o Source items that exist in the target (previously copied) must be identified Comparison of key information must be analyzed to determine if the source has changed and requires a re-copy Additional logic has to be employed if both the source AND target items have changed, which add additional time to the process. This means that data from both the source and target exchange server must be pulled into memory for analysis, potentially over a WAN connection. If, after analysis, it is determined that no changes were made, time and bandwidth were wasted in the sense that data was pulled for no additional value. o Source items that don t exist in the target have to be discovered Once discovered, logic has to be applied to determine if the source item should be recopied, or if the source item should be deleted (to reflect a delete that occurred in the target mailbox) This operation is also time consuming and requires either a search of the target mailbox in order to NOT FIND the item, or requires the use of an external database (like SQL). If an external database is used, this becomes another point of failure in the system and also adds to the infrastructure requirements that MUST be maintained for the duration of the migration project. Additionally, the size of this database begins to grow quite large with historical information due to changes in the environment during the project lifetime and therefore adds even more management burden in the sense of protection and backup of this information.

3 3 o The same 2 above operations then have to then be performed in reverse: target -> source The contents of the target mailbox have to be compared to the contents of the source This has to be done to adhere to the concept of synchronization, which means that changes on one side are reflected on the other. o Consider this complexity multiplied by the number of items in a mailbox multiplied by the number of mailboxes for the project. Such should highlight the complexity, dependence, and load that are placed on the trickle logic and the server that hosts this logic. Then imagine if this server was lost in some way or was caused to be offline for any period of time. As more and more mailboxes participate in the trickle service (a separate service that keeps the mailboxes up to date, possibly on separate hardware) the load on the service increases, which in turn slows down the entire process. Another side effect relates to an increasing quantity of mailboxes requiring synchronization; the potential is for the trickle service to become deadlocked or even for it to crash. Priasoft has had direct reports from customers of a trickle service having to be rebooted EVERY day in order to handle the increased load of work to perform. Visibility of when-to-cutover is difficult. Products that trickle data do not notify you of the optimal time to begin cutting over mailboxes to the new system, and in most cases, it is a guess. Cutting over a mailbox too early puts a burden on the end user. In once scenario, if a mailbox is switched over to the new account too soon, the end user will be missing mail that has yet to be replicated to the target mailbox. The end user will have to wait for that mail to arrive if the user needs that data and the delay can be minutes, hours, or even days and due to lack of reporting, it will be difficult to tell the user how long it will be before they have the data they need. Furthermore, often this last bit of data that is missing is usually the most current mail data, not old data. This means that if only 50% of a 2GB mailbox was trickled forward and the user is cutover, they will be looking at the oldest 1GB of data, and will have to wait for the other 1GB of data in order to effectively use the mailbox. Trickling data also has an unseen side effect with regards to the source Exchange Servers: o You cannot effectively remove a source mailbox until the user is cutover to the new mailbox AND all the data from the source has been placed in the new mailbox. o The knowledge of when you can safely remove the source mailbox is obscure since data could be queued up for deliver to the source mailbox during the cutover. o The source Exchange servers will continue to have storage growth since the nearly all of the source mailboxes will still be in use during the migration, even though 90% or more of the data was duplicated into the target mailbox. Log files will continue to grow, storage management is still a high priority, backups are still a high priority. o In addition to having to manage all of the source environment, the target environment now has to be managed in much the same way, even when there are possibly little to no users in the target environment. o Current Exchange administrators will not receive a release of responsibility for any portion of the source environment until EVERY MAILBOX IS CUTOVER AND ALL SOURCE DATA HAS BEEN VERIFIBLY REPLICATED

4 4 There is additional infrastructure and management required. In order to synchronize data, regardless of the systems involved, a separate service has to be employed. In most cases, this separate service demands new hardware, licenses, management, and human resources to manage it. As the size of an environment increases, so does the likelihood for having to increase the number of sync servers deployed. In addition, often some sort of tracking is required in order for the system to maintain state of objects. This tracking is typically in the form of a database (or multiple databases), which means more infrastructure, licenses, management, and human resources. In addition to the infrastructure build up, there is often a client deployment that must be implemented. Often a trickle will place some of the final burden of the cutover on the client computers, meaning that after cutover, each user that is cutover will have an agent or some sort of outlook add-in that will handle the final pieces of the migration. Imagine several thousand end user desktops demanding the Exchange system s time and resources for even and handful of last minute updates. This could mean tens of thousands of requests for changes at the same time. The complexity of setting up and managing a trickle style of migration increases costs like: time, training, licenses, and management of the complex system. These costs are outside of any licensing costs of a product, and can easily cause a budget to overrun, especially if the human resources that are expected to manage the system require advanced training. Imagine paying for training for a product in which after its use will most likely not be used again for many years, and even at such time will probably require more training! In addition to the costs of such complexity is the effort required to remove the system once the migration is completed. Proper protocols have to be taken when removing databases and servers/services from a domain. Proper and verified communication with peers and management have to be taken to make sure that only the migration related items are taken offline and that in doing so, nothing else is affected. Note that the concerns listed above are often never exposed in a proof-of-concept since the testing protocol is to define whether a product works or does not work. Be assured that in testing, the work performed is almost always setup such that it is expected to work. No vendor, including Priasoft would provide a proof-of-concept that failed. However, there is great difference in a solution technically working, and the same being satisfactory in a production environment. It is our experience that the concerns listed above often do not appear until the solution is accepted and is applied to a production environment, where the scale and load come to bear. Due to Priasoft s simplistic deployment, ease of use, and safety-by-design, you can perform TRUE proof-ofconcept in a test environment through the use of our Dry-Run mode, but also just as quickly and safely in a production environment. In fact, Priasoft always recommends performing a proof-of-concept in the production environment so that the ALL of the factors that affect a migration can be considered. In addition to a POC, our Dry-Run mode allows you to validate the fidelity, performance, duration, and feasibility of the migration before committing to the production execution. Priasoft s migration strategy migrates some (perhaps the most recent 30 days), or all of the mailbox data at the time of migration, after which the user is cutover and begins using the new mailbox. The migration

5 5 is done completely on-the-wire meaning no double copy of data (once from source to temp file, then again from temp file to target mailbox) and is the fastest way to move data. Priasoft s strategy also means complete understanding of progress and no delays by the end user. Priasoft provides transparency to end-users through the use of mail forwarding, when required. As users are migrated, mail that would have been delivered to their old mailbox is instead forwarded to the target mailbox. There is an unseen advantage here in that you can choose to delete the source mailbox very soon after the mailbox has been migrated (even immediately) which will create valuable white-space in the source server to help control its storage requirements during the migration. Even if you choose not to delete the source mailbox, the source server s growth rate begins to diminish immediately with the first mailbox migrated because of the forwarding of mail and the fact that migrated users are no longer generating activity. In addition, because mailboxes are finitely migrated, once all mailboxes have been migrated from a specific Exchange server, work can be started to remove that Exchange server from the environment at the same time as migrations are occurring on other Exchange servers. As more and more Exchange servers are brought down, several options and benefits become available: Hardware reuse: After an Exchange server is removed, the hardware can immediately be reallocated for other uses, perhaps as a new Exchange server in the target environment. Replication reduction: After an Exchange server is removed, there is less replication of data in the network. Multiple Exchange servers, especially prior to Exchange 2007, replicate Public Folder data between servers. Each Exchange server in an environment also reads and writes data to Global Catalog servers very often in order to read and keep the Address Book up to date. Network utilization reduction: Every Exchange server removed reduces large amounts of network utilization, which on large, already congested networks means that data will flow more freely as the environment is reduced.

6 6 Q: How does Priasoft handle mailbox folder delegates? Explanation of terms: Delegate: An entry on a folder in a user s mailbox, which defines access permissions to the folder. This entry determines what a user may do in another person s mailbox. The delegate entry is stored on each folder in a mailbox. There is no central database of delegates from which to perform analysis. Delegate also can mean Send-on-behalf-of which is a special permission that lets one user send mail on-behalf-of another user. A: Priasoft handles delegates by capturing and storing delegate information from each folder in the source mailbox and from send-on-behalf-of information found in the directory (AD or Exch5.5). The Mailbox Migration Manager (MMM) will store this information in a property on the mirroring folder in the target mailbox. The information stored will be either the X500 address of the source entry, the NT SID (if the X500 is not available) of the entry, or else the Domain\Username of the entry. A folder may have more than one delegate entry, and some of the entries may be orphaned, in that the entry exists, but no object exists in Exchange or Active Directory for which it relates. MMM will still persist orphaned delegates because the entry may actually exist in the target environment. Having stored the delegate information for each folder in the target mailbox, a separate process, run automatically by MMM, called the Delegate Resolver, will do the work of restoring delegate entries on the target folders. This separate process runs when all mailboxes selected have been migrated by MMM. This process can also be run manually on demand at any time. The process performs as follows: 1. The Delegate Resolver (DR) queries the target directory for all user accounts with mailboxes, that have an address of HASDELEG:TRUE. During migration, MMM will add this address if the mailbox has at least one folder delegate that needs resolution. 2. Working from the list of mailboxes with unresolved delegates, it logs in to each mailbox in the list in turn. 3. Once logged on, it enumerates all of the folders in the mailbox looking for the persisted delegate information that was stored there by MMM. Only folders that had delegates in the source will have this property. 4. The DR parses the list and for each item in the list does a Global Catalog search for the delegate in the target environment. If such an object is found, the DR will add the entry to the folder s delegate list with the same access permissions as it had in the source mailbox. 5. As it updates a folder s delegates, it removes the resolved items from the persisted list, and re-saves the list to the folder if any remain unresolved. 6. If all of a folder s delegates have been resolved, the DR removes the property from the folder so that on a future execution the DR can skip the folder quickly.

7 7 All of the activity of delegate restoration occurs in the target environment. There is no requirement to access the source ever again for delegate information. The DR looks at all mailboxes that are marked HASDELEG:TRUE in the directory. An mailbox user will not have this value removed until all the folder delegates have been restored. This approach allows the DR to re-balance delegate permissions as the environment changes. The benefit of this is that if the Delegator and the Delegate are migrated at different times, as soon as they are both in the same environment the DR will restore the delegate permissions. This creates fewer burdens on the migration project because even if you fail to migrate groups of mailboxes with delegate relationships at the same time, you can recover just as quickly by migrating the accounts that were missed. Consider this scenario: Joe CEO has given Jane Delegate permissions to manage his calendar. If Joe s mailbox is migrated tonight (and Jane is not) tomorrow when Jane attempts to manage Joe s calendar, she will not be able to since his mailbox is now hidden and effectively unavailable (also note that it is a limitation of Exchange that Jane cannot open Joe s calendar across a Forest boundary). Jane will most likely end up at the company s help-desk, explaining her need to manage Joe s calendar. The help desk associate, Jack, would know that a migration is in process, and that Joe s mailbox was migrated. He ll explain to her that as soon as she s migrated, her access will be restored. Jack informs the migration team of this and, due to the high profile nature of Joe, will migrate Jane s mailbox immediately, possibly on-the-spot. As soon as Jane s mailbox is migrated and the Delegate Resolver is executed, she ll have access to Joe s calendar again. Bear in mind also that this is an extreme situation. In real world cases, there would be better identification of such relationships and Joe and Jane would have been migrated together in the same batch so as to avoid this issue outright. The explanation is important however because in a large organization it is difficult to know all delegate relationships up-front.

8 8 Q: How does Priasoft help with co-existence? Explanation of terms: Co-existence: A typical situation in a large organization. The situation is one where due to the size, quantity, or diversity of an organization the likelihood of completing the migration of all accounts in a single event is very low. This means that during the migration project, some users will be migrated and using the new environment while some are left behind in the old environment. Business usage will continue, however the users in the 2 environments will need to communicate with each other. This need for communication between the 2 systems is co-existence. A: Priasoft helps you deal with a co-existence scenario in several ways. One of the primary ways Priasoft helps is by use of an option to create forwarding objects in the source organization. These forwarding objects (known as Contacts in Active Directory and Custom Recipients in Exchange 5.5) can be created by the Mailbox Migration Manager (MMM) during a migration. As MMM migrates mailboxes to the target environment, it keeps track of information in the source and target environments. When all the mail data has been copied to the target mailbox, MMM begins it Active Directory work. One of the AD tasks it has deals with creating forwarding objects in the source directory. It will do this only if the mail data is successfully copied to the target. After it creates the forwarding object it copies all of the display attributes (First Name, Last Name, phone numbers, etc.) to the new forwarding object. In addition, it copies select Exchange properties ( addresses, mail alias, etc.) to the forwarding object as well. After copying all the attributes necessary, it will modify those same attributes on the original, source mailbox so as to prevent any ambiguity and conflicts. In turn, this means that the forwarding object effectively becomes the new addressable object in the Global Address List. Users looking to send mail to the migrated user will see the exact same information as prior to the migration and mail will now be forwarded to the new target mailbox. For transparency purposes, MMM also adds the forwarding object to all the same Distribution Lists of which the original source mailbox was a member. This ensures that for users that typically address people using a DL, that the mail will reach the migrated mailbox. Lastly, great care is taken with respects to reply-ability. Specifically this means that MMM will capture the LegacyExchangeDN of the source mailbox and add the value to the forwarding object as an X500: address. Furthermore, MMM will add the LegacyExchangeDN of both the source mailbox AND the forwarding object to the target mailbox as X500: addresses.

9 9 In the end, this all means that regardless of where the mail originates internet, user selects from GAL, user replies to old , user sends mail to DL or replies to DL the message will be delivered to the new target mailbox. And as a final resort, for even the most unlikely scenarios, MMM will add the new forwarding object as an Alternate Recipient to the original source mailbox. So, even if, somehow, mail was delivered to the hidden, migrated, source mailbox, that mail would still be delivered to the target mailbox. A secondary question that is introduced when discussing this topic is with regards to the target environment. As users migrate into the new target environment without any change to the current paradigm the GAL for that environment will be empty except for the newly migrated accounts. As time passes and more accounts are migrated the GAL will become more populated and eventually will be completed as the last mailboxes are migrated into the environment. If the migration is designed to be a one-time event, this paradigm is usually acceptable. This situation is sometimes not ideal and the question is posed as to how to handle this. Priasoft doesn t require any specific form of directory synchronization in order to migrate, and due to this fact, provides one of the most flexible migration solutions available. However, Priasoft does have a migration specific directory synchronization tool. The most common use of this tool is to pre-stage the target environment with a fully populated Global Address List. The objects created are usually mail-enabled user accounts that forward mail to the source mailboxes (until they are migrated). Note that mail-enabled is not the same as mailbox-enabled; the 2 terms are distinct and separate. Mailenabled users forward mail; mailbox-enabled users receive mail. You are not required to use our tool, though it is often the best choice since it has been created to support a migration and not just generic directory synchronizations. Some alternative suggestions are Microsoft s IIFP (aka ILM) or MIIS. In reality, any solution that can mail-enable (not mailbox-enable) user accounts will be sufficient, provided the solution also carries over the source s X500 address. The mail-enabled accounts in the target will forward mail back to the source mailboxes until the time that they are migrated. In summary, co-existence is often a business driven requirement and not a technical one, and is often best to avoid. Regardless of the technologies in use, the support for each end of the migration (source and target) to have full visibility of the other can be very complicated if managed manually and without expertise. Priasoft is well skilled in the requirements and can offer many suggestions with regards to best implementation, based on the business needs and the state of the environments.

10 10 Q: Does Priasoft handle Free/Busy Synchronization? A: The simple answer is no. Priasoft, at this time, does not have any tool or utility that will keep Free/Busy data up to date during a migration. HOWEVER, do not be discouraged by this apparent lack of feature there are other options when needed. Firstly, it must be understood that concern over Free/Busy details are ONLY valid when you have chosen to perform a coexisted migration. In such a scenario users are split between to Exchange Organizations and therefore are split between 2 Free/Busy databases. Priasoft guides as many customers as are possible to design the migration to avoid coexistence. Our guidance actually has little to do with Free/Busy, although it is a reason, but has more to do with the overall perceived success of the project. For better understanding, please review the One-Time vs Coexistence document (link embedded). If you are forced to coexist, AND Free/Busy is of grand importance, you do have some options. However, before exploring the options, you should consider if it s worth the effort as very often upon analysis it can be determined that the quantity of users that absolutely rely on this feature is very small, and usually can be migrated together, thus eliminating the need for the synchronization. Firstly, consider realistically what percentage of your organization are calendar producers, meaning those users that would likely be ones to generate a calendar event that other should attend. Often this is a small percentage maybe 10 to 20 percent or less of an organization. In a smaller organization, this might only be a few dozen users or less. Additionally, you probably already know these users by category VIPs, Executives, Managers, and Assistants. If all of these classes of users plus their constituents migrate to the new environment in the same batch, there s likely little need for cross-forest Free/Busy information. Two options exist for Free/Busy synchronization, depending upon the version of exchange. If the target version is Exchange 2010, you can use the Availability service to have it proxy look ups of Free/Busy info. Refer to this link for detailed information about the service: Availability Service (TECHNET). This service allows Outlook 2007 and later to perform Free/Busy lookups to remote exchange environments. Priasoft can help further with this setup by way of the Priasoft Collaboration Suite tools that can properly setup X500 addressing between 2 organizations a critical link that allows the availability service to work cross-forest. The following link describes cross-forest setup of the Availability Service: Cross-Forest Availability Service (TECHNET). For all other scenarios (and from field reports Exchange 2010 SP2 and later), the Microsoft application known as the Inter-Org Replication tool (IOREPL) can be used. This application is a long-standing tool that can replicate Free/Busy information between organizations. The application is a bit quirky to setup and has to be setup EXACTLY as described, but once setup does handle the Free/Busy sync. The key thing to know about IOREPL is that it is a MAPI application so, rules that apply for MAPI to work between your 2 Exchange Organizations will apply for this tool. You ll find a detailed document about IOREPL here: IOREPL and Exchange 2010 Support (TECHNET) and here: IOREPL (TECHNET).

11 11 Q: Does Priasoft help with a Domain Migration? Explanation of terms: Domain Migration: A Domain Migration is effectively the migration of windows user accounts, their workstation profiles, and potentially other servers or services that depend on the domain to a new domain in another Active Directory Forest. A Domain Migration affects how users interact with network resources due to the fact that in most cases a user s authentication changes to reflect the new Domain. A: Priasoft does not yet produce software for Domain Migrations. Although we have much experience with Active Directory and Windows Domains, Priasoft is focused on being experts in Microsoft Exchange. It is undetermined at this point as to whether Priasoft will broaden its scope to include Windows Domain migrations. However, this information is not cause for alarm and should be seen as a benefit to the customer. This means that all of Priasoft s resources are focused on providing the best software available for Microsoft Exchange. Due to the design of our migration solution, Priasoft offers what no other vendor currently offers with regards to the relationship of Windows and Exchange: Choice. Implementers and architects of Priasoft s Exchange migration solution can choose to migrate Exchange mailboxes before migrating Windows. Or, if decided, the project can be designed to migrate Windows first followed by Exchange. This provides previously unrealized flexibility to the design and implementation of a migration. Because of this ability, an Exchange migration does not inherently have a dependency on Windows anymore. This allows the overall migration to be better controlled since there will be a separation of projects: a Windows migration project and an Exchange migration project. They can be run concurrently or separately with regards to timelines, but the management of each is separate. It is Priasoft s recommendation to determine which of the two projects is more business critical and focus on that one first. In more cases than not, Microsoft Exchange trumps Windows with regards to criticality. Even in cases where it is determined that Exchange should take a second position to Windows, performing an Exchange migration first may be more beneficial. Consider these key differences in approach: When Exchange is chosen to migrate first, Priasoft can setup the new target mailboxes in such a way that the source Windows account is still considered the Owner of the mailbox. This means that end users will still login with their existing user account, but will access the mailbox in an external Forest. This ability was not invented by Priasoft and has been available and supported by Microsoft since Exchange The

12 12 terms associated with this approach are: Associated External Account (AEA) in Exchange 2000 and 2003, and as Linked Mailboxes in Exchange 2007, 2010 and later. The benefits of performing an Exchange migration first are many: From a perceptual standpoint, the most business critical system is completed quickly and with little (if any) interruption to end-users. This shows very well to upper management, stakeholders, and key decision makers. When follow on projects are started there will typically be less concern as to the outcome due to the previous success. From a technical standpoint, what is truly a complex system is transferred to a new environment very easily and seamlessly. Many hours of research, testing, analysis, and execution are curtailed by using software that is specifically designed for such a task. End users do not have to be retrained or be introduced to any new processes in order to perform their daily tasks. In essence, the business continues on as it has. From a business standpoint, the amount of support that might normally be expected with a migration is dramatically reduced. Given the level of transparency that Priasoft provides to a migration, it is unlikely that an increase in internal support would even be necessary. In addition, by separating two complex projects Windows and Exchange it is easier for support staff to categorize issues as they appear. If it is known that currently only an Exchange migration is in process, the support staff can more readily identify issues that are related to the migration from those that are not. If the 2 projects are comingled, support staff can end up incorrectly associating an issue that is actually an Exchange issue to problems in a Windows migration, or vice-versa. It is also Priasoft s standpoint that since Windows and Active Directory actually control security into an environment; much more diligence needs to be taken in the design and execution of a Domain Migration. Such efforts, by nature, take considerable amounts of time. The time spent on discovery and planning of a Domain Migration should not require anyone to delay other projects unnecessarily. During the time spent on planning and design of a Domain migration another team can be execute the Exchange Migration. For those looking to Priasoft to provide recommendations for a Domain Migration, it is our experience that Microsoft does provide tools for this, namely the Active Directory Migration Tool (ADMT). This application provides the necessary features that alleviate issues that typically make a Domain migration difficult such as passwords, Sid-History, user workstation profiles, and security groups. Furthermore, being that Active Directory is the security authentication system, who better to support such a migration than Microsoft, especially if issue do arise you will want to get support from the source (Microsoft) rather than a 3 rd party. To restate, know that Priasoft s Exchange migration solution does not require any specific tool to be used for a Domain Migration. This means that the best tools can be chosen for the task without interference. In some cases, customers choose to handle a Domain Migration by using 3 rd party, non-microsoft tools. Due to the flexibility of Priasoft s design, customers are free to do so without cause to worry about adverse effects.

13 13 Q: How much time will an Exchange Migration consume? A: It Depends. Not necessarily the most succinct answer. The reason for this is due to the many factors that affect the performance of a migration. What can be stated at this point is that Priasoft s solution is typically seen migrating about 8-15 or more messages per second, per mailbox, on a local LAN (multiple mailboxes can migrate concurrently, and even on multiple workstations). We have seen the solution in some production environments perform as much as 35+ messages per second, and seen some that do only 1 or 2 messages per second. You may notice that unlike other vendors we discuss performance in terms of messages per second and not mailboxes per hour or gigabytes per hour. This is because the most critical factor determining the duration of a migration is how many total items there are and how many per second can be moved. For illustration, consider an environment where there are 3 million messages total (messages in this case are anything found in a mailbox: , calendar item, contact, etc.). If the aggregate total messages-persecond is 20, you can expect to complete the migration in about 40 hours (3mil / 20 msg/sec = 41 hours), which is well within a single-event timeframe. So, in order to provide an answer to the question, metric tests have to be performed. The metric tests are done using the Priasoft product in Dry-Run mode to determine the throughput between the source and target environments and the overall duration. This provides a nearly guaranteed forecast as to how long a migration will take since the dry-run execution uses the EXACT same codebase as the production migration would. If a dry-run of 3000 mailboxes takes hours, you can state with confidence that the production migration will take nearly the same amount of time, + or a few minutes (or maybe an hour) depending on how much difference there is in the environment between when the dry-run was performed and the production migration is executed. Factors that affect performance are many and the ones that most commonly affect such are provided below. Network Latency this is usually an issue when the source and target environments are separated by a WAN. These network connections inherently introduce latency (not to be confused with bandwidth) and this latency increases with the physical distance between the source and target environments. The effect of latency on migration performance can be severe. Microsoft Exchange and the protocols used to access it are quite chatty and were never initially designed with high latency in mind. Some recommendations are, if possible, to bring the source and target exchange servers as physically close in proximity as possible prior to the migration (one idea suggests virtualizing one environment and then bringing it online locally), introduce a WAN optimizer/accelerator, and/or reduce the amount of data that needs to be migrated.

14 14 Another option that can help in high-latency networks is to increase the number of concurrent tasks, that is to say, migrate more mailboxes at the same time and possibly by having more migration workstations running at the same time. Essentially concurrency combats latency. Disk Performance in essence, Microsoft Exchange stores mail data in a specialized database. The data in the database can become fragmented over time. If the source database has not been defragmented in a long time (or ever), reading information from the database can be quite slow. Exchange 2000 and later have automated processes to perform database defragmentation, however, there are situations where these processes are unable to complete or are not able to defragment optimally. Regardless of how, any efforts that can be made to compact and defragment the Exchange data will have a positive effect on the migration. It may be valuable to review the following Microsoft article about defragging: If performance is of considerable concern, and fragmentation is listed as a way to improve the performance (perhaps by exhausting all other performance adjustments), the best is an offline defrag of the exchange database, which is also referenced in the above article. Server Load although obvious, it should not be casually ignored. Server load can affect a migration as much or more than anything else. Priasoft s solutions for migration behave and appear as a mail client to Exchange. This is a positive benefit in that Priasoft can never really collapse an Exchange server (much like 3000 users wouldn t), but due to the optimizations over the past 10 years, Priasoft can ask for data faster than the server (an ultimately the underlying storage system) can deliver it, which can cause delays to anyone attached to the server, including the Priasoft tools. Additionally, if at the same time some other process capitalizes the Exchange server s resources, the migration will suffer along with all other clients as well. Along with the server load is over capitalization of the underlying disk system. When the disk system is over-committed, queuing occurs the disk system gets backlogged with read requests which ultimately slow down the migration. Proper analysis of the disk system during dry-run tests will help determine maximum concurrency. Of specific importance is analysis of SAN utilization. Often a SAN is a multi-use playground, meaning that more than one service can utilize the storage on the SAN. The importance of this centers around disk spin events. During a dry-run or a production migration, if at the same time some other consumer of the SAN also causes the disks to spin, such will reduce the available I/O for the migration effort. A common example is a SQL database that shares the same physical disks on the SAN as the Exchange database and for which an application or DBA executes an complicated and intensive database event. Such will spike the read operations (which are already elevated due to migration activities) and can likely cause queuing and delays for both events (SQL and migration). There are many things that can affect an Exchange server s processor load, and some are as obvious as others. In good practice, a full inspection of each Exchange server should be made looking for services or applications that work either directly with Exchange, or merely work on the server itself. The less obvious are services and applications that are external to the Exchange server but which do

15 15 intense operations upon it or the underlying storage system. The least obvious and most difficult to track down are those processes that do work when the server is supposedly idle. By the time you log in to the server to inspect it, the intense process will have suspended itself because it has determined the server not to be idle anymore because you logged in to the server. Some examples that can increase load on an Exchange server are: Backup software Antivirus Software Antispam Software Fax and Unified Messaging software Mobile services like blackberry Additional server roles DNS, WINS, DHCP, SQL, etc.. Screen Savers it shouldn t have to be said Archive software Terminal Services Exchange specific Anti-Virus an Exchange virus scanner can adversely affect the performance of a migration. It is suggested that if the time window for a migration is of great concern that the Exchange Anti Virus be suspended/disabled during the migration. There is obvious concern with changing the state of a virus scanner, however, such should be weighed by the business needs with regards to the performance and desired duration of the migration. When an Exchange Virus scanner is installed, the virus scan engine is loaded directly into the Exchange store process (store.exe). The engine is designed to look at messages as they are being requested and before a client renders them. This design is efficient for daily use as the virusscanning engine will only perform scans as data is requested versus crawling through the entire database. However, there is a little known side effect of this: older messages are not scanned except when accessed again. A virus scanner works off of a database of virus signatures from which it compares to items as they are requested. When a recent message is retrieved, it most likely was scanned within the past few days, and if no new virus signatures have been received from the vendor, the message is quickly handed off to the requester. If new virus signatures have been received, only the new signatures are compared against the item, which is still very quick. However, the older a message is, with regards to the last time it was accessed, the more signatures that have to be enumerated and compared. In many cases, there are messages that existed BEFORE the Exchange virus scanner was installed. Accessing one of the very old messages means that the item has to be analyzed against ALL of the signatures in the virus scan database. In usage-time, this happens in milliseconds or even 1 or 2 seconds, and is not really perceived by an end user. However, add up 1 or 2 seconds over several million messages in an Exchange Server and considerable delay has been introduced.

16 16 This delay is not the only issue. A migration can actually fail if an item is complex or simply has a large amount of virus signatures to compare to. The failure comes as a result of a timeout where our asking for data fails because it takes too long. This timeout is not controllable either by Priasoft or Exchange. Lastly, simply disabling an Exchange virus scanner may not be sufficient. As described earlier, the scan engine is loaded with the store process. Often the scan engine is still scanning items as they are requested but is simply not reporting anything to the virus scan service. If it is suspected that an Exchange virus scanner is affecting performance, the only recourse may be to disable the virus scanner be sure to do this using the vendor s provided control panel as simply stopping the underlying windows service may not be enough and then stop and restart the store process. This is the only way to truly unload the virus scan engine from the store process. Mailbox Characteristics the characteristics of the data to be migrated can have as much to do with the performance of a migration as all of the above combined. To explain this better, an analogy may help. The file system has much of the same issue with performance, as does an Exchange mailbox, with regards to the copying of data. In the file system it is well known that the amount of time consumed to copy a 1GB file is dramatically less than 1GB of 10k files (that would be 100,000 files!). The difference in time is because of the context switching that occurs over the many files. For each new file to be copied, there is a bit of delay before the data actually starts copying. This delay constitutes various checks and analysis of the file in question: does it still exist, can it be copied, proper permissions, can the target file system accept it, etc. The delay may only be in milliseconds, but even 500ms over 100,000 files adds up to 50,000 seconds, which is over 13 hours of just waiting! In Exchange, a mailbox with thousands of small messages will migrate slower than a mailbox of several hundred messages, even if they are the same size. A complexity that Exchange has over the file system analogy is the fact that items in a mailbox (messages, calendars, etc.) are really containers of information (analogous to a zip file). The complete structure of an item in a mailbox has many parts properties, attachments, recipients, etc. that are not necessarily stored contiguously in the exchange database. This becomes more apparent when you consider the Single Instance Storage feature of Exchange (for versions of Exchange that have it) or in Exchange 2010 the fact that Attachments are stored (internally) separately from the message. As a message is requested, Exchange must gather all the data for the message from various parts of the database (and now further consider the previous highlight of fragmentation). So, the characteristics of a mailbox definitely affects performance of a migration, AND those same characteristics have an even more profound effect on the previously explained items that affect performance. If the mailbox scheduled for migration is very large, has a large amount of items with many of them having attachments, AND the database is fragmented, and they are most old and

17 17 have to be rescanned by a virus scanner, and the attachments are large or complex, the performance for that mailbox will be slow. In summary, if the duration of the migration is of critical importance, any work done to prepare the source exchange servers will be well worth it, and the determination of how important the duration is highlights again the importance of the ability to dry-run the project one or more times before committing to the production execution.

18 18 Q: In what order should I perform the migration? A: This question comes from a realization that there is more to a migration than just the mailboxes in the exchange environment. There are also Public Folders, Distribution Lists, Contacts, Outlook profiles, and Mail Gateways. The specific answer to this is not always the same and really depends on how the migration is being designed. If the migration meets the criteria for a One Time Migration a migration in which the entire migration is performed during single event the order is really not so important. If the migration will span considerable time and there is high likelihood of users having mailboxes on both the source and target at the same time during normal business, the order should be considered. Priasoft makes no demands of any specific order. No component of the solution is tightly dependent upon another. However, the typical usage of the Exchange system often dictates the importance of the interrelated dependencies. Priasoft s recommendation is as follows: 1. Deploy Outlook Profile Update Manager 2. Pre-stage the target environment 3. Migrate/Synchronize Distribution Lists 4. Migrate Public Folders this is listed after DLs because some folder permissions are issued using DLs 5. Migrate Mailboxes this is listed last so that as users arrive in the target Exchange organization, DLs and Public Folders will already be available for them to use. Regarding mail gateways, these should be left until the migration is completed. If additional mail gateways need to be created (in order to mirror behavior of the source environment), such will have to be manually created in the target environment and this effort usually only takes a few minutes. Another aspect of Exchange, and messaging in general, is the configuration of Internet MX (mail exchange) records in DNS. The adjustment of where the MX record points may or may not be necessary. The determining factor for this is based on where the MX record currently points. If the MX record points directly to the source Exchange environment, an adjustment will be necessary as some point before the source Exchange servers are taken offline. The adjustment of the MX record is typically easy to do, but may take up to 48 hours to replicate to most other Internet DNS servers. However, if the MX record currently points to a routing agent SendMail and Postini are examples there may be no need to adjust the MX record. However, adjustments to the specific routing agent may need to be made. Ultimately and understanding of how mail flows in and out of the organization will help determine how adjustments should be made, if any.

19 19 Q: How does the Mailbox Migrator match source account to target accounts? A: When performing a migration one of the steps in the Mailbox Migration Manager is to match source user accounts to target user accounts. This matching is necessary because there are 2 directories involved. MMM uses information from the source user in order to find an account in the target. MMM gathers the source account s SamAccountName (aka Pre-Windows 2000 account name) and the source account s primary SMTP address. MMM uses those properties and performs an LDAP search of the target domain asking for any user accounts where either one of the 2 properties matches in the target domain. If the results of the search return more than one object, the application will leave the source object as unmatched. It may not be apparent as to how this can happen; if there are 2 user accounts in the target, one with a primary SMTP of joeuser1@domain.com, and a different one with a logon name of joeuser1, the search will return both objects, which will be ambiguous to the application. In most cases a single object is returned and the match is successful. For those that are not, you have to either browse for the matching object, or create a new user account (provided that it does not already exist somewhere else in the directory). Steps can be taken prior to a migration to mitigate the chance of ambiguous returns and non-matches by pre-staging the target environment with user accounts with matching properties. It is not required that the target accounts have mailboxes or addresses in order to migrate or to have successful matches. The best method of pre-staging, for the purpose of matching, is to use Priasoft s directory sync solution (mentioned previously) to pre-stage the target environment with mail-enabled user accounts. Alternatively is to use Microsoft s ADMT to create new user accounts in the target domain. When using the ADMT, the only properties that need to be copied are the logon name (SamAccountName) and display name; all other properties are optional and will, by default, be copied by MMM. An optional configuration of MMM is also available so that a custom-matching algorithm can be used. This option allows the matching of a single property from the source account to be searched for in the target domain. This single property matching option can be the same property or different properties between the source and target objects. For instance, the custom matching can be setup to match users where the source account s extensionattribute15 value is found on a target account s userprincipalname value.

20 20 Q: How does the Mailbox Migration Manager handle corrupted s? A: MMM is designed to provide as few failures as possible. With regards to corrupted s, MMM will skip and log all corrupted s (if it can) in order to complete the migration of that mailbox. The default setting is such that on the 16 th item failure the mailbox is failed. The setting can be overridden via the windows registry and can be configured such that if an entire mailbox is corrupted, the migration of that mailbox will succeed, however the target mailbox will most likely contain no data. This is an extreme case, and to date has never been experienced. The threshold for message copy failures, such as corrupted messages, is configurable via a registry setting (contact support@priasoft.com if you feel you need this override). The threshold defines the maximum number of messages that can fail to copy before the migration of the mailbox is considered failed. As expressed in the previous paragraph, the default behavior is to fail at the 16 th item failure. MMM does not mark nor delete the corrupted messages in the source mailbox. However, such messages are logged to the migration log in the windows event log system (eventvwr.exe) and can be reviewed post migration. The subject of the message that was corrupted is listed (when possible) in the log entry in case you wish to work on those messages in the source mailbox. Note that if a source item is truly corrupted, it is unlikely that we will be able to report the subject of the message since it s corrupted. Deductive analysis will need to be used in order to handle such a case. The Priasoft log file for a mailbox (an html file produced by the migrator) will show the last mailbox folder that was migrated and such will tell you where to start. The time stamp between when the folder entry was logged and when the message failure occurred will give some indication as to how deep in the folder the corrupted item resides.