Looks like a plan. I'll assume from 9. that this is talking about your Exchange Organization A, which you are doing a Typical Migration on (put E2K servers into your E55 org and move users).
As for the Exchange Ogranization B, which you have selected to use EXMERGE, this is a Foreign Mail System Migration and EXMERGE is a decent tool for this. To explain more about redirection, here goes. There is a SINGLE, proper method of migrating from foreign email systems. This is the ONLY method that ensure that no messages are lost. If anyone tells you that there is another method, they are wrong. Here is the overview: 1. Get both systems up and running 2. Get message flow going between the two systems either via SMTP or a proprietary connector 3. Syncrhonize directories between the two systems so that mailboxes from system SOURCE show up in System TARGET's address book as foreign mail entries (i.e. contacts) Again, this can be done a number of different ways depending on the systems involved. 4. To migrate a mailbox, first, convert the foreign mail entry in the TARGET system to a mailbox, preserving all addresses 5. Now, perform email redirection on the other systems to point them to the newly created mailbox in the TARGET system. 6. Once redirection is complete, export the SOURCE mailbox and import it into the TARGET mailbox What this does is completely eliminate any problems with missing messages during migrations. If performed correctly, you will never lose an email or get a bounced message during migration. Now, to be more specific about email redirection; since you asked. The issue that email redirection attempts to solve is preserving address fidelity, or the ability for users to address or respond to email during the migration process. A typical scenario that can occur is the following: 1. User A sends an email to User B 2. User A migrates to the new system 3. User B responds to message and it bounces Now, why does this occur? Well, for the most part it occurs because people that write email systems are apparently brain dead. For example, E55 stamps an internal X500 FROM address on every message an Exchange user sends out. This is actually a hold-over from MS Mail which used the ever popular 10/10/10 format. If you simply delete the Exchange mailbox and create a contact pointing to the new system, you have broken address fidelity because the new contact has a different X500 address than the old mailbox. Bad. The slickest way to solve this problem that I have found is to create a contact in the SOURCE system pointing to the new mailbox in the TARGET system. Then, use Exchange's handy dandy alternate recipient to define an alternate recipient of that contact. You can then export the mailbox info and import it to the new system and you will never break address fidelity. An alternate approach is to record all of the various email addresses and X500 address from the SOURCE mailbox and add them to your contact. You can preserve address fidelity in that manner as well, but if you do it this way you will have a gap in your migration process where you might miss a message. Now, you also have this problem: 1. User A sends a message to User B 2. User A migrates to new system 3. User B migrates to new system 4. User B responds to User A's message and it bounces. What is going on here? Well, that sweet, loveable X500 address is still sitting there stamped on that message. Unless you have that X500 address associated with a mailbox on the new system, your messages will bounce in this scenario. So again, you have to move all of your addresses from the legacy system, including the X500 address to the new system. Now, all of this is really not difficult, especially with the proper automation tools and techniques. However, email redirection is by far the most over-looked aspect of email migrations. And it can get pretty complicated when multiple systems are involved. It works out to something like n! scenarios that you have to take a look at. However, most of those scenarios typically end up being invalid. For some reason, people have reached the conclusion that email migrations mean missed messages and bounced email, but that does not have to be the case. With proper planning, design and engineering, email migrations can be flawless. I've been doing flawless email migrations for a long time now. This process works and is the ONLY thing that works. > Greg, > > Thanks for your thorough response! > Here are some clarifications and comments on your response. > > As far as I can understand it, this is how they want to do this: > > 1. Install a new server w/ NT 4 as a BDC. > 2. Install a 2nd server w/ NT 4 as a BDC. Keep it as a backup. > 3. Replicate new BDC and promote it to PDC. Make sure existing PDC is > demoted. > 4. Replicate new PDC. > 5. Upgrade PDC to WIN2K OS and make sure it communicates with location A's > DC > 8. Install AD and give it a child domain name of child.newdomain.com. > 9. Make sure the new PDC can pass AD back and forth with other locations > which already have EX2K/W2K/AD > 10. Install ADC on EX55 and create a one-way from 55 EX2K server. > 11. Use EXMERGE to move mail from 55s to EX2K. > 12. Once it's tested thoroughly the EX55 boxes in A & B will be abondoned. > > Also one thing in your response I didn't quite understand was redirection. > How and where is it done exactly? > > > Thanks > > --Alex > > > > -----Original Message----- > From: Greg Deckler [mailto:greg@;infonition.com] > Sent: Friday, November 01, 2002 2:48 PM > To: Exchange Discussions > Subject: Re: Interesting EX2K migration solution > > > Alex, > > I have performed these types of migrations before. In particular for a large > 12,000 seat fast-food restaurant system composed of a number of different > email systems including 2 E55, 1 cc:Mail and 1 MS Mail systems. Here are the > main issues with these types of migrations (between 2 disparate Exchange > organizations): > > 1. It sounds like you will be integrating E2K servers into one of your > existing E55 organizations. I call this a Typical Exchange 2000 Migration. > Depending on how many sites you have, you will want to put an E2K > server in each of those sites. Once this is done you can move the users from > the E55 servers to your E2K servers. You can do this via the admin tools, > but it is a pain selecting and migrating them manually. Because I have done > this before, I actually have a tool that will batch-automate this process > that we have used with a lot of success. > > 2. The second E55 system will be migrated as a Foreign Mail System. This is > referred to as a Foreign Mail System Exchange 2000 Migration. More on this > in a minute as this raises a number of issues you will need to be concerned > about. > > 3. Before you do anything, you will want to upgrade your NT4 PDC to Windows > 2000 and integrate it with your AD design. This is the NT4 domain where you > will be performing the Typical Exchange Migration. You will also want to > install the ADC into this domain. Then, you can install your first E2K > server and join it to your E55 organization. > > 4. Because you are joining your E2K system into your existing E55 system, > you have solved most/all of your coexistence problems, GAL, messaging > connectivity, Free/Busy information and public folders. > > 5. Because you are joining your E2K system into your existing E55 system, > you have solved most/all of your migration problems in terms of getting the > mailbox and other data to your new E2K environment. The only issue here is > if you want to do this all manually or automate the process. > > 6. Because your other E55 system is being treated as a Foreign Mail System, > you have coexistence and migration issues with this system. Luckily, the > migration issues can be addressed through the use of the Exchange Migration > Wizard which semi-supports E55. The reason for the semi-support is that > unlike every other mail system that the Migration Wizard supports, E55 > migrations are implemented by using a PST file for its export medium instead > of the standard PRI, PKL, SEC files used for all other migrations. This is a > pain because the migration wizard puts a random password on all of those > PST's. Again, this can be a real pain to do manually. And again, I have > tools, Rocket, to help automate this process. Also, more on migration issues > below... > > 7. Now, coexistence is an issue for the foreign E55 system. You will > probably want to think about some type of coexistence between the two > systems. Not sure what you have in place today in terms of coexistence, but > the main things you will want to be concerned with are a GAL, Messaging > connectivity, Free/Busy connectivity and Public Folder synchronization. > There are various, largely unsupported tools on various resource kits and > other locations that can aid in this effort. However, in all honesty, they > are not the greatest tools in the world. Again, since we have run into this > before, we created Furnace, which allows one to easily exchange directory, > free/busy and public folder information between two disparate Exchange > systems (E55 and E2K). This gives you a GAL in each system that contains > everything from both systems. > > 8. Once you get all of your Typical Migration complete, you can switch to > Native Mode in Exchange and consolidate your Administrative Groups to > simplify your life and no longer be bound by your E55 site definitions. > > 9. As far as the user logon and access piece of this, depending on how you > are configured, you will probably want to clone all of your user accounts in > the Foreign Exchange NT domains into your AD structure as mail-enabled users > or contacts. This can be done using the ADC or the ADMT tools. Different > issues with each of these and different methods will work for different > situations. The main item is that users will continue to use their existing > account and mailbox until they are migrated. > > 10. Migration involves a lot of issues and some things will depend on how > you do it. You could use certain tools to move the entire "foreign" Exchange > server into the E2K/E55 organization. Lots of pros and cons to this > approach. The other method, as I mentioned, was the Migration Wizard. Again, > pros and cons. Regardless of how you do it, if not everyone will be migrated > at the same time, then you have to look at closely at your migration > Process. This is very important. You will need to create the mailbox, > perform mail redirection, export the data and import the data. Obviously > this is simplifying what is involved. The important piece that you will want > to think about is email redirection. Exchange uses an X500 address that gets > stamped on all messages sent within the Exchange environment. If you do not > perform email redirection correctly, users will get bounced mail messages > when they reply to the messages of people moved to the new system that were > sent prior to the move. > > Anyway, hope this helps. Feel free to contact me with any questions. And I > agree with Ed. (For perhaps the first time!!) You really should bring in an > email migration expert to help you through the process. And yes, that is a > shameless plug. > > > Our company runs EX 5.5 in 2 separate Organizations & NT domains, as > > well as 2 separate locations. To save in migration cost to EX2K, > > they've decided to migrate to EX2K/W2K/AD in only 1 location and move > > all the mailboxes from other location there. The other location will > > retain its NT domain scheme, however these users will have to log on > > the remote W2K domain now, to access EX2K, across a Frame Relay > > (1024kbps). I thought there has to be a local GC in each location for > > this work, but obviously that's not possible in an NT4 domain. > > > > So I'm just wondering, will this work?! > > > > Thanks > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:leave-exchange@;ls.swynk.com > Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:leave-exchange@;ls.swynk.com Exchange List admin: [EMAIL PROTECTED]
