Thank you Jeff for your answer.
I saw your site before, but since there was not mentioned neither
a path for migration to Exchange 2010, neither one for consolidating
two different existing SBS I thought you deal only with a true "swing"
migration, meaning replacing a SBS2003 server with a different server
(either same or superior SBS version, either upgrading to standard
Windows + Exchange up to 2007). So you have a migration path that can
apply for this kind of project (going from 2 SBS2003 servers to a
single Win 2008+Exchange 2010)?
I don't really care if the final domain will be one of the
existing ones, a new domain in one of the existing forests or a
complretelly new forest. Now both SBS2003 are of the same company
(they had to use 2 SBS2003 due to bandwidth restrictions, so a Win
2003 server in the existing domain was not a choice due to the 20
users having to access the Exchange on the remote site) and they will
move to a new location, where all users will be in the same place. The
domains have different names (luckily), but the users have the same
email address space (with Exchange configuration for forwarding mail
for unknown users to their internet provider, from where the POP3
connector downloads their internet mail).
As soon I will get the new hardware (two-three weeks from now I
hope) I will do some tests in order to see if I can use the third path
as you recommended. Fortunately they intend to use Vmware so I will be
able to virtualize and test in a virtual environment most of the
procedure before doing it for real. The more detailed procedure thay I
came up with is the following (I omitted the safe parts, like backup
everything and so one, indicating only the actual migration parts):
1. Install Service packs in both SBS domains A and B.
2. Install a Win 2003 Standard in both domains (actually one of them
has alreay one).
3. Make the Win 2003 a domain controller and a global catalog. Check
for actually transferring all data and do a reboot , checking for the
events showing that it acts as a GC.
4. Use exmerge to export the mailboxes of the users in Domain B (just
to be sure).
5. Transfer all 5 FSMO roles to the new DC in domains.
6. Use ADMT to transfer users and machines from domain B to domain A.
6. Transfer mailboxes of users in domain B to Exchange on SBS in
domain A.
7. After checking that all users were correctly transferred and that
they can work in domain A proceed to an upgrade of the A domain into a
new Win 2008 DC and move mailboxes to a new Exchange 2010 server (as
alreay documented around the net).
Practically I will divide the procedure in two different steps: one
for consolidating the two different SBS into one and afterwards a
second one for moving from SBS2003 to Win2008+Exchange2010. I don't
care much about the users files in domain B (I will transfer it over
only in the end to the new server and reapply correct ACL by using a
scripted cacls type -already done that different times, so this is not
a problem), and I'm not very much concerned about their profiles
(since there are only 20 users in the worst case I can manually move
their profile from the old server to the new one and assign the ACL
for accessing the profile directory as well as manually loading the
ntuser.dat hive and assign ACL for accessing the registry keys).
Well I will wait for the new hardware and do some testing before
deciding how to proceed. I would sure love to know that you have a
documented procedure that I can buy in case the things are not sorting
out well during the testing.
Post by Jeff Middleton [SBS-MVP]Rumburak,
Larry mentioned SBSmigration.com, that's my website and this is among the
project scenarios that I can provide you with full documentation from end to
end, support, and a construction path that doesn't require significant
disruption to your domain operations. Though you won't see this domain
consolidation project listed on the standard packages offered, it's a
project I have outlined in details and support. I just require folks to
prequalify with me to ensure that they understand the full scale of this
project, it's not a trivial project, it requires a fair amount of planning.
Each of the outlines you have suggested are potentially an option, the last
one you address is most similar to what I would recommend as your best
option, it's the path I have documented with some additional variations
available.
You haven't really addressed one of the key points here as you go through
this discussion, that being that you talked about bringing these domains
together but I never saw you make reference to the Forest and Domain
identifications of these respective domains or whether you care to
prioritize having new Forest identity.
Ultimately I can provide you with documentation and support on any one of
the three paths, but I don't think that either of the first two options make
sense once you understand the full implications of the third option
performed as a Swing Migration. The way you described it isn't exactly the
construction path I would recommend, but it's got the core concepts of
integrating the domains in a convenient way. I believe you getting hung up
on the SBS concepts here as if it is a special case, and it's not.
Jeff Middleton SBS-MVPwww.SBSmigration.com