Help with Swing Migration
- From: "yodrun@xxxxxxxxxxxxx" <yodrun@xxxxxxxxxxxxx>
- Date: 1 Oct 2005 14:20:03 -0700
This is extremely long and I apologize for that. I am looking for help
from anyone who has used Jeff Middleton's Swing Migration Kit. Jeff
has been unreachable for a while due to the problems in New Orleans, so
I'm hoping others who have used his kit might be able to answer some of
my quesions. I bought the Swing Migration Technician's KIT (it
includes the tools) to do a SBS 4.5 to SBS 2003 migration to new server
hardware. This is a slightly revised copy of a letter a sent to Jeff
about 10 days ago.
1. Is there an addendum for the tools that come with the kit?
Specifically I am looking for instructions on how to use the DNSpurge
tool but can't find them anywhere in the stuff you've sent me. Is it
on your web site maybe? If yes, how do I navigate to it and download
it?
2. I don't think I have the addendum for doing an Exchange fork lift.
Can you send that to me or direct me to a place where I can download
it?
Background info before I launch into my next set of questions: I'm
migrating from SBS 4.5 to SBS 2003. SBS2003 will be installed on new
server hardware. I am using your SBS 4.5 to SBS 2003 Migration
instructions. So far I have completed Phase I, Phase II, and most of
Phase III.
3. I have found Phase III to be very confusing in places. I think it
is primarily because I'm having trouble translating the server names
and references from Phase II to Phase III, do you know what I mean? I
think Phase III really ought to have it's own full and complete
documentation: even if the most of the procedures are the same, the
names and references are different. It would make things a lot less
confusing (at least for dumb 'ol me). Problem is, because you tell the
user that Phase III is a repeat of Phase II only using different
machines, you can't use your server name references consistently in the
Phase II/III document. On page 11 of the "Overview: How to perform a
Swing Migration" you take pains to explain that the kit documentation
uses four server name references, and they are: "Existing SBS",
"MigrationDC", "SBSnameDC", "Final SBS". Yet Phase II/III is filled
with references to "new machine", "the machine", "established DC",
"existing DC", "established SBS server", "opposite server", "original
domain controller" and many more. As an example, look at Phase II.A.6
(on page 29): you write "the next steps that follow require this
computer to communicate with the existing DC for this domain"...well,
if I'm in Phase II and I use your naming convention, then "existing DC"
should be translated to "Existing SBS", right? If I'm in Phase III,
then "existing DC" should be translated to "MigrationDC" right? I
know your arrows down below this try to clarify this, but they come 4
paragraphs later and are therefore out of context (you need to move
them up so they sit immediately under the above referenced text). And
even the arrows that attempt to clarify this use inconsistent naming in
that the top arrow refers to the "Existing SBS" machine as "the
established SBS server", which, again, deviates from your naming
convention. I'm not trying to be critical about this...I'm just trying
to follow your documentation to the "T". As I'm going through the
instructions step-by-step, if I hit a paragraph or a particular
instruction that seems confusing or incorrect, I stop right there and
try to figure out why it seems wrong rather than just guessing at at
your intent and plowing ahead and hoping for the best. I need to KNOW
that what I'm doing is correct at each step along the way -- I'm too
fearful that one incorrect move will land me with a server that
exhibits quirky, unpredictable, and unstable behavior for the next 4
years of it's life; I provide tech support on a flat monthly fee no
matter how many hours I have to put in - the last thing I need is a
server that is unreliable from the first day of its life because I
built it wrong! I mean, these things are quirky enough even when you
build them perfectly! I certainly don't want to make them more so by
misinterpreting any of your instructions!
4. See Phase II.A.4.6: This step tells me what IP address I should
plug in to the Primary DNS Server field when configuring the server's
Internal NIC. Your arrows underneath this instruction are very
confusing - the top arrow says that if I'm configuring the internal NIC
of the MigrationDC, then the IP address for the Primary DNS Server
should be a unique, available IP - that's wrong, isn't it? Shouldn't
the DNS IP address be the address of the "Existing SBS" server? The
arrow beneath this one says that if I'm configuring the internal NIC of
the SBSnameDC, then the IP address I should enter into the Primary DNS
Server field should be the same as the "original SBS server's" primary
LAN IP...which machine are you referring to when you use the term
"original SBS server"? Is it the "Existing SBS" (per your naming
convention)? In any case, this statement is also wrong isn't it?
Doesn't the DNS Server address for the SBSNameDC NIC need to point to
IP address of the MigrationDC at this point in the procedure? Once
replication from the MigrationDC to the SBSnameDC is completed, THEN I
should change the DNS Server address for the SBSNameDC NIC to point to
the IP address of its own internal NIC, right? Only then will the DNS
server address of the internal NIC of the SBSnameDC be the same as the
DNS server address of the internal NIC of the "Existing SBS", right?
5. See the NOTE under Phase II.B.2: The NOTE says I must be logged on
as a Domain Administrator to do this. Which domain? If I'm working on
the MigrationDC, I should be logged on as an "Existing SBS" domain
administrator, right? If I'm working on a SBSnameDC, I should be
logged on as a "MigrationDC" domain administrator right? As a
suggestion, I think you should add "Existing LAN", "Migration LAN", and
"Final LAN" and "Existing Domain", "Migration Domain", and "Final
Domain" to your naming scheme.
6. See Phase II.B.3.5 and the associated NOTE in the Technical
Background: After I complete II.B.3.4 should I wait 15 minutes before
restarting (step II.B.3.5) or should I restart and then wait 15 minutes
before performing the next step (II.B.4)?
7. See Phase II.B.3.5 and the associated NOTE in the Technical
Background again: the NOTE states "...before your remove the global
catalog from the original domain controller..." What are you talking
about here? This statement implies that I am supposed to remove the
global catalog but no where in the documentation (that I could find)
does it when this is supposed to be done, how it is done, or
unambiguously which machine it is supposed to be done on. Am I
supposed to remove the global catalog from the original domain
controller? Which one is the "original domain controller"? Where are
the instructions for doing that? At what point in this sequence of
tasks is that supposed to be done? Where in the kit does it explain
how do this? I can't find it.
8. See the technical NOTE under Phase II.B.3.5 - It says "allow
sufficient time for the account and the schema information to replicate
to the new global catalog server...". You say 15 minutes is typically
sufficient. Isn't there some way to force the replication to occur?
And isn't there some way to verify that the replication has occurred?
I don't want to assume 15 minutes is sufficient. Neither do I want to
wait 15 minutes if I don't have to.
9. See Phase II.B.4 and the two bullets under Phase II.B.5: Why are
these bullets under II.B.5? Don't they simply elaborate on the
instructions given in step II.B.4? And if so, why are they under
II.B.5? Again, I ask this not because I want to point out simple
mistakes you've made in your documentation (assuming this was a
mistake), but because I want to understand the process and the logic
involved in these steps - maybe you purposely placed these bullets
under II.B.5 instead of II.B.4 but if you did, then I clearly don't
understand what's going on which worries me and causes me to think
maybe I should stop trying to decipher the Swing kit, give up on it,
and use some other method for performing this migration.
10. See II.B.4 and II.B.5 again: Your instructions say I should
confirm that DNS replication has occured. I should probably know how
to do this, but I don't, and your instructions for doing so aren't
clear to me. I'm not exactly clear on how I am supposed to perform
this confirmation. It sounds like I'm supposed to compare the server
DNS entries for the two machines. Exactly which entries am I supposed
to compare? All of them? There are many sub-folders in the forward
and reverse lookup zones - do I compare them all? What about the
entries in the DNS Cache folders - am I supposed to compare them too?
And if there are any differences, does that indicate a problem?
11. Do the Adpurge and FSMOstat tools exist yet?
12. See II.E.3: It says "when you reinstall DHCP Server later..."
Well, DHCP service is not installed now...should it have been by now?
Earlier in the process, step In II.A.5 to be specific, you say to
"ensure that DHCP Service is disabled, or not yet installed". I
therefore did not install it. Then I get to this step II.E.3 that
talks about re-installing DHCP later (it was never installed in the
first place, so how can it be re-installed?) and about deleting "DHCP
authority reference objects" that don't even exist in my SBSnameDC (at
least not that I can find). No where in the documentation could I find
WHEN I'm supposed to install DHCP service. Please explain.
13. See II.E.4: The first sentence of this step refers to "...local
machine matching the Servername they were created for originally". I
have no idea which machine or machines (plural) you are referring to in
this sentence. Nor can I decipher which machines you are talking about
in the subsequent paragraph in which you refer to "a DC you have
removed", "a new server", "the current server" and "a new IIS server".
I'm totally lost here. All I can tell you is that I have an "Existing
SBS", a "SBSnameDC" (to which I've given the same name as my "Existing
SBS", which is "Server1"), and a MigrationDC. Being unable to decipher
this task, I simply deleted ALL IWAM_Servername and IUSR_Servername
accounts in my SBSnameDC. Sometime later I rebooted SBSnameDC and
noticed a yellow warning in the Application event log stating that
IISadmin had recreated the IWAM_SBSnameDC account and the
IUSR_SBSnameDC account. Does this indicate a problem? Did I screw up
this task?
14. See II.E.5 DNS Records cleanup: I can't figure out what I'm
supposed to do here. I'd use your DNSpurge tool expect there are no
instructions on how to use that tool.
15. See II.E.7: DHCP Service is not even installed...I can't perform
that task. Should DHCP have been installed by now?
16. See II.E.8: again, DHCP service is not installed. Since I'm
actually working in Phase III, does the "retired DC" you mention refer
to "MigrationDC"?
17. I tried using the technician kit tools on my SBS 4.5 machine but
they don't work - I get error messages when I run them. Are they
incompatible with SBS 4.5? Are they intented for use only on SBS 2000
machines. I found nothing in the documentation that would indicate so.
Jeff, sorry to inundate you with all this. Maybe these are really dumb
questions I'm asking. Maybe someone with more knowledge than I have
would be able to easily understand what you "meant" to say. Maybe you
assumed the reader of your kit has a greater understanding and
knowledge of this material than I. Or maybe in my anxiety to get it
right, I am parsing your words to the extreme, reading too deeply, and
over-analyzing. Whatever the case, I need your help. Please get back
to me as soon as you can.
.
- Follow-Ups:
- Re: Help with Swing Migration
- From: Frank McCallister
- Re: Help with Swing Migration
- From: Frank McCallister
- Re: Help with Swing Migration
- Prev by Date: 802.1x / Radius Wireless client *always* disconnects a few mins after login, but is fine thereafter
- Next by Date: Re: Help with Swing Migration
- Previous by thread: 802.1x / Radius Wireless client *always* disconnects a few mins after login, but is fine thereafter
- Next by thread: Re: Help with Swing Migration
- Index(es):
Relevant Pages
|