Re: Help with Swing Migration
- From: "yodrun@xxxxxxxxxxxxx" <yodrun@xxxxxxxxxxxxx>
- Date: 1 Oct 2005 16:18:02 -0700
Thank you, Frank, I will do so.
Frank McCallister wrote:
> Hi Yodrun
>
> I talked to Jeff this morning. Please resend your email to his support
> address. He has caught up with his backlog but your message may have been
> missed.
>
> Frank McCallister [SBS MVP]
> COMPUMAC
> <yodrun@xxxxxxxxxxxxx> wrote in message
> news:1128201603.805154.50120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 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.
> >
.
- References:
- Help with Swing Migration
- From: yodrun@xxxxxxxxxxxxx
- Re: Help with Swing Migration
- From: Frank McCallister
- Help with Swing Migration
- Prev by Date: Re: Help with Swing Migration
- Next by Date: Re: Sending Sharepoint alerts to a user outside of the SBS domain
- Previous by thread: Re: Help with Swing Migration
- Next by thread: Re: Sending Sharepoint alerts to a user outside of the SBS domain
- Index(es):
Relevant Pages
|
