Re: Using Exchange 2003 Deployment Tools (incl. ADC) for 2000 upgrade

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Richard Roddy [MSFT] (rroddy_at_online.microsoft.com)
Date: 04/28/04 

Date: Wed, 28 Apr 2004 16:53:38 GMT

One other option is to hold off for at least another month or two and wait
for SP1 for Exchange 2003, which is scheduled to introduce a set of
cross-site mailbox move tools for use in mixed-mode Exchange orgs. One
reason for the tools is aiding you in consolidation of your org when you
have a lot of existing sites and wish to collapse into fewer sites, just as
you want to.

Thanks,
Richard Roddy
Microsoft Exchange Support

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>From: "Ed Crowley [MVP]" <curspice@mvpsnospam.net>
>References: <A85B71A4-F709-4EBF-820A-3D9950C4FF58@microsoft.com>
>Subject: Re: Using Exchange 2003 Deployment Tools (incl. ADC) for 2000
upgrade
>Date: Mon, 26 Apr 2004 22:18:05 -0700
>Lines: 60
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
>Message-ID: <O2R6GcBLEHA.1312@TK2MSFTNGP12.phx.gbl>
>Newsgroups: microsoft.public.exchange.admin
>NNTP-Posting-Host: adsl-216-103-85-85.dsl.snfc21.pacbell.net 216.103.85.85
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12
phx.gbl
>Xref: cpmsftngxa10.phx.gbl microsoft.public.exchange.admin:424330
>X-Tomcat-NG: microsoft.public.exchange.admin
>
>You can move mailboxes between administrative groups when you're in native
>mode. If you can get all 21 sites upgraded to Exchange 2003, you can then
>switch to native mode and then move all the mailboxes to the central
>administrative group.
>
>You can use Exmerge to move the mail from the old sites to the new one, but
>that will involve a lot more user hand-holding and administrative effort.
>--
>Ed Crowley
>MVP - Exchange
>"Protecting the world from PSTs and brick backups!"
>
>"Greg" <greglara@yahoo.com> wrote in message
>news:A85B71A4-F709-4EBF-820A-3D9950C4FF58@microsoft.com...
>> After researching and testing various migration strategies for upgrading
>our organization from Exchange 5.5 on Win2k to Exchange 2003 on Win2k, it
>seems that the best method will be to first upgrade our various sites to
>Exchange 2000, then consolidate the users to a fewer number of Exchange
2003
>servers. I'm interested in getting feedback on this strategy. I'll explain
>our situation further.
>>
>> We have 21 sites in our Exchange organization, one each per regional
>office (though some offices do not have an Exchange server). Given that we
>only have 450 users in our org, we want to consolidate a number of these
>into four larger, regional "hub" sites. All servers are currently running
>Windows 2k SP3, are DCs (generally are the only server in a given
location),
>running Exchange 5.5 SP4.
>>
>> The problem with upgrading to Exchange comes when it is time to move the
>mailboxes to the hub site. We can't do this with the built-in tools, as
>cross-site mailbox moves aren't supported. We've investigated 3rd party
>migration tools, but they're either way too expensive (for a non-profit),
>they're too complex, or they simply don't work (well). As an alternative
>migration path, we've decided to start testing based on the following
>scenario.
>>
>> At our headquarters and regional hub sites, the migration will be fairly
>straightforward. We'll install a new Exchange 2000 (or Exchange 2003)
server
>into the site, move that site's mailboxes to the new server and we're good
>to go (following the standard procedures for this path - forest prep,
domain
>prep, ADC, etc.).
>>
>> The regional sites to be consolidated provide a trickier path however.
>We're looking at using the "swing" method: install a 2nd Exchange 2000
>server into the site, move the mailboxes from the 5.5 server to this new
>server, upgrade the 5.5 box to 2000, then move the mailboxes back. We'd
>follow this path throughout the organization until all servers have been
>upgraded. At that point, we can go to native mode, and consolidate as
>necessary.
>>
>> Barring all the potential sticky points while upgrading servers (I know
>issues will arise), are there any major reasons why we shouldn't go down
>this road? It seems to me that we could take it at a pace that's
comfortable
>for us, and give us a reasonable rollback strategy should an individual
>server upgrade not work out. I'd love to hear anyone's thoughts on this.
>>
>> Thanks,
>> Greg
>
>
>

Quantcast