Frequently Asked Questions

(1)

PHONE EMAIL WEB

602.801.2400 [email protected] www.priasoft.com

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)

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)

 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-of-concept 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)

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)

Q: How does Priasoft handle mailbox folder delegates?

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 email 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)

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)

Q: How does Priasoft help with co-existence?

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 (email 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)

In the end, this all means that regardless of where the mail originates – internet, user selects from GAL, user replies to old email, 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. Mail-enabled users forward mail; mailbox-Mail-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)

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)

Q: Does Priasoft help with a Domain Migration?

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 2000. The

(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 3rd 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 3rd_{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)

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: email, calendar item, contact, etc.). If the aggregate total messages-per-second 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 32.545 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)

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: http://blogs.technet.com/b/exchange/archive/2004/10/25/247342.aspx.

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)

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 virus-scanning 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)

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)

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)

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

(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 [email protected], 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 email 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)

Q: How does the Mailbox Migration Manager handle corrupted emails?

A: MMM is designed to provide as few failures as possible. With regards to corrupted emails, MMM will skip and log all corrupted emails (if it can) in order to complete the migration of that mailbox. The default setting is such that on the 16th_{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 [email protected] 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 16th_{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.

(21)

Q: Are there features of a mailbox that are not migrated?

A: Yes. One of Priasoft’s main design pillars is to produce products that do not create an unsupportable situation. Because of this, there are aspects of Exchange mailboxes or Outlook specific features that are not migrated. As much as we’d like to be able to migrate every aspect of a mailbox, we choose not to migrate features that are undocumented, unsupported, or for which Microsoft guidance declares that we should not. Be wary of competitors or consultants claiming to have answers for the following gaps as they are likely in the realm of un-supportability, have reverse engineered Microsoft’s code or structures, and could place you in a difficult spot if there are issues post-migration.

Know that the following features listed do not impact the end user in any critical way nor does the lack of these features cause any issues with mail flow, access, or use. The features listed are cosmetic in most cases and should not cause concern with regards to the success of a migration. Furthermore, with the exception of Organization Forms, all other features are ones that end users can manage themselves. At worst, and especially if such info is not communicated prior to migration, there may be some elevation at the help desk as users discover these gaps, but such will be easy to handle thru a document, over the phone, or by email. Best case, and most common when communication is delivered prior to migration, is that users discover the gap and take it upon themselves to resolve.

Saved Search Folders – Priasoft does not currently migrate search folders found in a mailbox. The steps to

perform this are not very well documented and research and internal testing has proven this to be unsupportable. Our research and development teams periodically re-evaluate this feature and hope to support such in a future release. Users will need to re-create saved search folders.

Outlook Views – Priasoft does not currently migrate custom Outlook views. Outlook views are the custom

settings applied to a mail folder that control the columns in the message list, the location of the reading panel, body format used to view a message (plain, html, rtf, etc.), and other settings of the like. Currently there is little to no documentation on how these settings are persisted and even less on how to create them. For this reason, Priasoft does not support the migration of Outlook views.

Junk E-Mail Rules and Folder – Priasoft does not migrate the Junk E-mail rules from the source mailbox.

These rules are created and maintained by Outlook, not Exchange. The Junk E-mail rules are created by Outlook XP and later. In addition to the rules, Outlook creates a folder called ‘Junk E-Mail’ in the root of the mailbox to store the messages that are categorized by the Junk E-Mail rules. MMM will copy the Junk E-Mail folder to the target mailbox, however, it will rename the folder as ‘Migrated Junk E-Mail’ in the target mailbox.

Outlook creates the Junk E-Mail folder and rules the FIRST time it logs on to a mailbox. However, Outlook only does this work if the ‘Junk E-Mail’ folder DOES NOT EXIST. If there is a folder named ‘Junk E-Mail’ prior to Outlook’s first logon, it will not validate that the rules are present and the Junk E-mail processing will effectively be broken.

(22)

It is for this reason that we copy the source’s junk mail to a new folder named ‘Migrated Junk E-Mail’. Users can be instructed that it is safe to delete the ‘Migrated Junk E-mail’ folder at any time. Deleting the migrated junk folder will have no adverse effects on the mailbox.

Outlook Categories – Outlook allows a user to store and apply ‘Categories’ to item for each search and

grouping at a later time. Categories in Outlook are comprised of 2 parts: The category, and the assignment of such to an item. When a user creates a new category, the category name is stored in a private section of the user’s mailbox. When a user assigns a category to an item, the name of the category is attached to the item in a special property.

When Priasoft migrates an item, all properties of an item are migrated, including the categories assigned to the item. However, the actual ‘Category’ (stored elsewhere in the mailbox) is not migrated. This means that although the item has the category assigned, grouping by category is not available because when the user looks at the list of categories, the custom category created prior to migration is missing. If the user recreates the category, things will work again as expected.

Once again, Priasoft is limited by published documentation and developer support from Microsoft. We *could* probably reverse engineer how this all works, but then if Microsoft were to later change the format or structure of the category data, things would be broken and you, the customer, would be between 2 vendors pointing fingers at each other – we choose not to place you in that position.

Delegates: Private Items Visible & Delegate receives copies of… - Another set of Outlook specific features

that are related to delegates and are not migrated; these 2 features are seen as checkboxes on the Tools->Options->Delegates dialog in Outlook 2003 and later. As with previous Outlook features described in this section, these features are undocumented (or poorly documented) by Microsoft and as such are not migrated.

Note that with these specific features, the lack of support does not pose a potential global issue to your end user community. Firstly, the 2 features loosen restrictions on delegates when enabled. This means that by not migrating the features, users will at worst have more restrictive settings on their delegates than prior to the migration, and such are the default settings for a new delegate. Secondly, since these are features specific to the delegation option of Outlook, the scope and breadth of this support is already quite narrow. Consider that in most organizations (from our experience of over 12 years), the number of users that delegate access to their mailbox is about 10% of the organization. This means that for 3,000 users, maybe 300 users have delegated access. Then consider that the number of users that would enable one or both of these options is again some percentage of 300 and at 10% would only be 30 users.

In most cases it is sufficient to communicate to end users about this feature deficiency with instruction that IF they use the feature, they simple need to re-enable such after the migration.

Organizational Forms – Org Forms are not migrated. Org forms are stored in the Public Folder store and

contain custom forms that are typically designed around specific mail types. Org forms are not generated by Exchange and are often create by 3rd_{party software for special purposes. One example is Exchange} Archiving software; this software will often archive a message in a mailbox and replace the original

(23)

message with a new message of a different type. The new type is registered to use a special Org Form, and when a user accesses the ‘archive’ message, the code in the Org Form is used to retrieve the message from the archive.

Because of the likelihood of org forms to be created and managed by a 3rd_{party vendor, Priasoft chooses} not to migrate these org forms. Such forms often contain settings that are specific to the Exchange

Organization in which they reside and typically cannot simply be copied from source to target. Be cautious of software that migrates Org Forms for this reason.

Third Party Outlook Add-ins – Priasoft does not specifically migrate or modify Outlook add-ins. However,

the Outlook Profile Update Manager does not typically break or interfere with these add-ins either. If there are Outlook Add-ins that are dependent on access to the original source exchange server, and have ‘hard coded’ values, those add-ins are likely to not work properly since the Outlook profile will be

reconfigured to use an Exchange server in a different organization. Outlook profiles typically can only connect to a single exchange organization at any given time. Microsoft does not produce any tools or add-ons that allow a profile to access multiple organizatiadd-ons concurrently in a single profile, with the exception of Outlook 2010.

Public Folder ‘Per User Read/Unread Status’ – This deficiency only applies to a Public Folder migration.

Priasoft does not migrate the individual per-user read/unread status on items in a Public Folder. Exchange Public Folders can be configured on a folder-by-folder basis to track the read/unread status of messages in the folder at a per-user level. Priasoft cannot preserve this data because the location where this

information is stored is in a private area of each users mailbox. Microsoft provides NO ACCESS to this data to any developer.

Priasoft does, however, migrate the folder’s setting for per-user status (seen as a checkbox on the folder properties dialog). If a folder in the source store is configured to track per-user status, the folder

created/used in the target store will gain the same setting. This means that new messages that are added to the target Public Folder will be tracked on a per-user basis, but the messages that are migrated into the folder will not. This is a limitation of Microsoft Exchange and currently there appears to be no effort to provide a solution for this.

(24)

Q: How does the Public Folder Migration Manger migrate permissions?

A: The Public Folder Migration Manager (PFMM) work with folder permissions using Active Directory accounts and is the only product available that works with folder permissions using Active Directory accounts. Through much research and testing, Priasoft’s PFMM product migrates permissions using AD account information. Conversely, most other products and scripts work with folder permissions using Exchange objects (mailboxes, DLs, Custom Recipients, etc..).

There is a great benefit to using AD accounts for permissions instead of Exchange objects: it allows the setup of permissions on folders BEFORE mailboxes and mail attributes on groups have been migrated. This means that the permissions can be migrated ahead of the mailboxes, and as soon as a mailbox is migrated, the owner of the mailbox will have the same permissions to Public Folders as he/she had in the source organization.

This saves a tremendous amount of time because you no longer have to follow behind the migration of mailboxes with the re-establishment of permissions. Other products that use Exchange objects (versus AD objects) to assign permissions have to constantly perform post migration work for permissions. This is because until an Exchange object is available the permission cannot be configured.

Consider the following scenarios: Traditional migration:

1. Migrate Public Folders to target

a. Target folders have only default and anonymous permissions

b. Target folders cannot be assigned permissions to user accounts by any standard or 3rd_party tools.

2. Migrate one or more mailboxes

a. At this point, the mailboxes in the target exist, but do not have permissions on any Public Folders.

b. Users logging on to these target mailboxes will not have any access to any public folders (unless the folder’s default/anonymous permissions allow)

3. Go to each Public Folder for which the source mailbox had permissions and add the new target mailbox to the folder.

a. This must occur for each migrated mailbox

b. You must know up-front what folders the mailbox had access to Priasoft Migration:

1. Migrate Public Folders, with permissions

a. The PFMM will show all users that have permissions to one or more of the selected source folders

(25)

b. The PFMM will allow you to auto-match the source users to target AD objects c. The PFMM will allow you to force match source users to target AD objects

d. Folders in the target store will have permissions assigned the same as from the source. 2. Migrate Mailboxes

a. Target mailboxes already have the permissions to Public Folders in the same way as the source.

b. There is no post migration work to be performed.

Also note that because Priasoft uses windows accounts for Public Folder permissions, Priasoft is able to properly setup permissions to target folders for Linked Mailbox migrations. Priasoft will apply BOTH the source user account AND the target user account to the target folder. No other product or process does this. The addition of both the source user and target user are required for Linked Mailboxes to access public folders.

(26)

Q: How does Priasoft handle Outlook’s Nickname Cache?

Nickname Cache: The Outlook Nickname Cache is a feature of Outlook XP and later. The cache is the feature that is seen in Outlook as a list of recipients that appear as you start typing in one of the address boxes of a new (or reply/forward) mail item. The list of recipients is built up over time as you address more and more people.

A: The Outlook Profile Update Manager – profilemanager.exe – is an application that helps automate the migration of existing Outlook profiles to point to the new target mailbox.

Priasoft has the option to handle the cache by renaming the Outlook profile during an update. The cache file on disk is associated with the profile by name, and as such renaming the profile essentially disconnects the cache from the profile without having to search the disk for the file. This means that when a user uses Outlook after a migration, they will start with an empty cache. The original cache is still on disk, and can be ‘reattached’ simply by renaming the profile back to it’s original value. For simplicity and in order to not disturb power users, we rename a profile simply by adding a period (.) to the end of the original profile name, which is enough to cause Outlook to create a new cache the next time it is started.

In most cases, this is the most elegant way to avoid NON-DELIVERY messages due to items in the cache. However, if you can be reasonably sure that ALL possible mail objects from the source organization will exist in the target environment prior to migration, and that these target objects will have an X500 address of the related source objects (and thus match info in the cache), you probably don’t need to rename the profile. Note that by ALL possible mail objects we mean any object in the source that a user *could* have added as a recipient to a message (attendees of calendar items or tasks equate to the same). Users can just as easily send to a contact, distribution list, or public folder, as they can to a mailbox and each of those types have a unique X500 address. This is important because the value stored in a user’s nickname cache is a binary value followed by this X500 address. If the same cache file is to be used post migration, and a user replies to a cached value for which there is no matching object in the target environment, a NON-DELIVERY response will occur.

Priasoft evaluated managing the nickname cache directly several years ago and even had a beta version of profilemanager.exe sent out to customers. It became very unsupportable for many reasons, primarily because the use, structure, location, and management of the nickname cache is completely owned by the Microsoft Office development team and that team has never released any programming support for the nickname cache. The best that is available describes the filenames that are used and that they can be deleted if necessary.

Aside from being an undocumented feature of Outlook, the management of the nickname cache is problematic. In our research, the first problem encountered was determining the location of the cache files in the file system. Outlook does not store the location in any accessible location that can be queried – no information in the registry, none in any .ini files, and nothing in the user’s profile. The second problem was that different versions of Outlook used and managed the cache files in different locations. This

(27)

created a problem of determining where the cache files would be in order to handle them. Since there was no way to determine the location of the cache files we would have had to search the entire hard disk for them! This was not a direction that made since with a product that typically runs in a login script. Furthermore, searching the entire disk could lead to handling cache files that were not for the mailbox that was migrated since some workstation might have multiple users that login to it.

In addition to the above issues, the cache files have different extension depending on the version of Outlook and this created even more problems when searching for the cache files. In the end, the entire development path was reversed and removed as unsupportable.

Frequently Asked Questions

Table of Contents