Greg, I'm not sure if you got the email I sent you yesterday, but I want to clarify one more thing: One EX55 box will be moved physically to another location, where its contents will be moved using EXMERGE. Therefore there'll be no chance to get the message flowing between the 2 Exchange boxes.
Thanks --Alex -----Original Message----- From: Greg Deckler [mailto:greg@;infonition.com] Sent: Tuesday, November 05, 2002 2:22 PM To: Exchange Discussions Subject: RE: Interesting EX2K migration solution 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] _________________________________________________________________ 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]
