Re: SBS4.5 to SBS2000 Upgrade Problem by Jeff
Jeff
Sun Oct 26 12:24:46 CST 2003
FWIW, the route you started on can be solved for the issues you highlighted
regarding printers, shared, mapped drives and such, even with Autocad, but
the amount of complexity involved is exceptional. The method that I outlined
is a straight line, it involves some things that may not be familiar, but
they are all documented steps that MS supports, you just don't see them
lined up this way in the documentation.
"Peter Smith" <noreply@noreply.com> wrote in message
news:bnh241$pld$1$8300dec7@news.demon.co.uk...
> Jeff
>
> Thanks very much for your detailed explanation.
>
> It confirms my suspicions that I was not taking across the user database
and
> therefore my method was doomed from the start.
> Fortunately there are no shared folders or data on the SBS4.5 server to
> carry over, everything is on the member server so that should simplify
> things a great deal.
> As usual, Microsoft do not provide real-world examples to help people do
> this, they just assume that everyone sets up a network in a way they
expect
> them to. They live in a different world to the rest of us!
>
> As I will have to do a similar upgrade for a standard NT4 domain to a
> Windows 2003 Domain in a few months time this will be a good trial for
that
> as well.
>
> Thanks again.
>
> Peter
>
>
> "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> news:e$HAuj9mDHA.684@TK2MSFTNGP09.phx.gbl...
> > Hi Peter,
> >
> > I wish I could tell you that you have this really simple thing that you
> > missed, but I think that's not going to be the case. You are swimming
> > upstream against a pretty basic problem. You are not preserving the SAM
> from
> > the old domain, therefore when you move your workstations and member
> server
> > to the new domain, you are going to be forced to recreate the local
> profiles
> > at each workstation. The method of redirecting the profile folder
> > information doesn't preserve the portion of the profile that is stored
in
> > the registry, just the file/folder space. Unfortunately, the things you
> are
> > looking to preserve in the transition are almost entirely registry
based.
> I
> > don't think the method you are using is suitable to your goals. It's not
> > that it's impossible to make the shift in the way that you are doing
this,
> > rather that I don't think it's the easiest way to end up 100% intact on
> the
> > far end of the process.
> >
> > Here's my synopsis of your situation, just so that you can read what I'm
> > seeing and tell me if I've missed anything.
> >
> > You have a network made up almost entirely of NT family workstation,
most
> of
> > the W2K OS workstations. All the workstations are part of an existing
> domain
> > managed by an SBS 4.5, therefore an NT4 based domain. All of the user
> > accounts are defined in the current NT domain, therefore all the
> application
> > settings, workstation share resource references exist in the references
> > based upon this domain. You have applications which are either sensitive
> to
> > the registry/profile/folder pathings that are being maintain by
> workstation
> > shares, member server shares, or NTFS file permission configurations
based
> > in the original domain.
> >
> > The method you were starting with is to use the best available
> documentation
> > from MS which disregards the significant requirement you would
prioritize
> > which is to avoid renovating every workstation simply because you want
to
> > renovate the SBS, moving it from NT4 domain to W2K domain, plus
obtaining
> > access to the new SBS 2000 server applications you will have available.
> >
> > Ideally, what you really want is to upgrade the SBS in a manner which
> > preserves the references and relationships between the workstations and
> the
> > member server shared resources, plus any user account specific
information
> > possible.
> >
> > Okay, that's my summary, but the last paragraphs says it all. You want
to
> > change as little as possible about the workstations and member server, b
ut
> > upgrade the SBS to SBS 2000...that's the nutshell requirement.
Therefore,
> > what you really need is a plan that makes the SBS 2000 introduction
> > transparent to all the other workstation/member server configurations.
It
> > sounds like you don't have a lot of stuff on the SBS that is path
> critical,
> > nor shared printers and such that are based from the SBS, only that
> > everything is based upon the SBS domain accounts and anything that is
> > dependent upon that.
> >
> > The method that you need to follow that causes the minimum disruption
> would
> > be to preserve the current domain, not replace it with a new one. To
> > accomplish this, the method I would recommend you follow is to swing the
> > upgrade process from NT to AD domain using a surrogate BDC server to
> > maintain the accounts. I've talked about this type of upgrade several
> time
> > in the past, it sounds dramatically complex, but it's probably the best
> > answer in your situation because it brings all of the configuration
> > requirements only on the SBS, and leaves all other workstations in
totally
> > transparently untouched condition. If you complete the method that I'm
> going
> > to describe, you will have basically nothing to do at the workstations
or
> > member server...they will just work as before. Literally, you new SBS
> server
> > can snap into the existing domain with a substitution of the new server
> for
> > the old one, and all the preparation work can be completed offline. I
have
> > done upgrades of this type where the transition switch involves about 1
> hrs
> > of transition downtime.
> >
> > The key to what you want is to maintain the same domain accounts
> throughout
> > the process. The only way to do that is to create an upgrade process
that
> > keeps the domain intact by keeping a DC from the old domain, and
migrating
> > the domain progressively using the old accounts. Below is an outline of
> > what you are needing to do, in brief summary. Note, you will need a
> machine
> > temporarily to act as your BDC during about a 4 hrs period, so this is
> > actually possible with the use of a separate hard drive in a
workstation,
> > removing the production drive, then building the NT BDC on this machine,
> > then abandoning the installation when the time comes, and bringing the
> > workstation drive back online again. Therefore, to complete the upgrade,
> > here's a list of what you will need:
> >
> > - extra hard drive or an extra computer to use as a BDC temporarily.
> > - NT Server install media, or boot floppies for SBS 4.5 media to install
a
> > plain NT Server.
> > - W2k Server install media, or boot floppies for SBS 2000 media to
install
> a
> > plain W2K Server
> > - Your new SBS 2000 server hardware as separate machine from the SBS 4.5
> > machine.
> >
> > Note that this upgrade/migration process has the specific benefit of
> > allowing you to build the new SBS 2000 system into the same original
> domain
> > as the SBS 4.5, plus you can leave the SBS 4.5 running the domain
> > continuously while you finish constructing and configuring the SBS 2000
> > server. The transition point is when you move your data content off of
the
> > SBS 4.5 over to the SBS 2000 server, therefore this is when you have to
> take
> > the network production offline, but you can do this at your convenience
on
> a
> > weekend or after hours. The time required should be about as long as it
> > takes to do an XCOPY of the data files, because all the configuration is
> > done in advance and offline. When you move the data, you will not
require
> > any significant reconfiguration at the workstations or member servers.
> >
> > One more point. This outline is based upon the idea that you aren't
trying
> > to migrate an Exchange 5.5 up to Exchange 2000, though this too can be
> done
> > by one of a couple of methods. The easiest is exporting to PSTs and
> > reimporting using Exmerge....just as documented by MS for such tasks.
> > Alternatively, it's possible to migrate using direct load of the old EDB
> > database files into the new SBS 2000 Exchange 2K if the organization
name
> is
> > recreated with identical pathing.
> >
> > Okay, so here's the outline of what you need to do, assuming that you
> start
> > with your production network all online, you have workstations and a
> member
> > server, plus the SBS 4.5 is the only DC in the network.
> >
> > 1. Scratch build a temporary BDC in the existing domain using a
> temporary
> > computer, or an extra drive in one of the workstations you can do
without
> > for a day. Build the machine from scratch by install NT Server 4.0 and
> make
> > the machine a BDC in the existing domain. If you don't have NT 4.0
Server
> > media, you can build the three boot floppies for SBS 4.5 server and
delete
> > the .SIF file from the floppies. You must avoid this machine thinking
it's
> > supposed to be an SBS server, it's supposed to be just a plain NT 4.0
> > Server.
> >
> > 2. Once you have your NT 4.0 BDC configured as a BDC, this means the
> BDC
> > has all the computer and user account information. From this point, you
> are
> > going to take a very deliberate step to physically detach this temporary
> > computer from your production network. Do not reconnect this machine to
> the
> > production LAN for any reason after this step. What you are trying to do
> is
> > convince this server that the original production PDC is gone
permanently,
> > and this computer is to take over the domain entirely. As such, you
don't
> > want it seeing the rest of the LAN workstations or original PDC or
> problems
> > result. Detach this NT 4.0 temporary BDC from the network now. I'll
refer
> > to this machine as the "surrogate DC" from this point.
> >
> > 3. With the Surrogate DC detached from the network, follow the
process
> to
> > promote this machine to PDC of the network, and force the removal of the
> > original SBS server's identity from the domain controllers lists. This
is
> > documented by MS in KBs that make reference to "permanently shifting a
BDC
> > to PDC when the original PDC will never return to service." Keep in
mind,
> > this is an "alternate reality" domain from the one on your production
LAN.
> > As long as these separated DCs never see each other again, the Surrogate
> > doesn't know that the original SBS is in fact fine, running the
production
> > LAN....because they are out of contact permanently.
> >
> > 4. The Surrogate DC would now have the PDC designation, and no other
> DCs
> > exist in the domain as far as it knows. At this point, you can now
> perform
> > an in-place upgrade from NT to W2K domain on this Surrogate server. You
> > perform this using regular W2K Server media if you have it, or using the
> SBS
> > media provided that you do NOT proceed with the scripted portion of the
> SBS
> > 2000 Setup. In other words, you run the DCpromo command manually, as
well
> as
> > the ForestPrep commands. You would follow the normal KB info on an
> in-place
> > upgrade of a solo NT PDC to solo AD DC.
> >
> > 5. Once the Surrogate DC is running AD, and without running any SBS
> 2000
> > related tasks on it, you have a W2K domain using AD, you have the same
> > accounts as the original SBS 4.5 SAM, but you have an existing domain
now
> > which you are about to add a second DC.....the new machine you will
> > eventually configure as the SBS 2000 server. From this point, I'll call
> > this new machine that will become the SBS 2000 your "Permanent DC"
> >
> > 6. Using either standard W2k Server media or boot floppies from the
SBS
> > 2000 media from which the .SIF file has been removed, you perform a
normal
> > W2k Server install on this Permanent DC hardware. You want to name this
> new
> > server "exactly the same name" as the original SBS 4.5 server. That's
> > critical if you want to preserve the namespace at the conclusion of this
> > migration. After completing the basic installation, you perform the
normal
> > DCpromo process to join this machine as an additional DC in the domain
> being
> > maintained by the Surrogate DC. Once that process is complete, you now
> have
> > this "offline domain" as a copy of the original domain, same accounts,
but
> > still detached from the production LAN.
> >
> > 7. You now are going to DCpromo demote the Surrogate DC from the
> offline
> > domain. The result will be your Permanent DC will be the only DC, it
will
> > have all the server DC roles, will have the name of the original SBS,
and
> > therefore it can basically substitute back into the production LAN at a
> > future time that is convenient, and the remainder of the member servers
> and
> > workstations will now know the difference. :)
> >
> > 8. Before you are ready to put the new server online, you want to
> finish
> > configuring as much as possible while it is still offline. This will
> > minimize your downtime. Therefore, now you complete the SBS 2000
specific
> > installation process as usual as if you were actually upgrading a W2K
> Server
> > based domain to make it now an SBS 2000 domain. You can install all of
the
> > SBS 2000 server apps to this machine if you wish. This is also the point
> > that if you were upgrading a domain that original was SBS 4.5 with
> Exchange
> > 4.5 and you wanted to preserve the ability to directly import the EDB
> files,
> > you would need to manually install Exchange....not using the SBS install
> > wizard. The reason is that the SBS wizard will use the default Exchange
> 2000
> > named organization of "First Storage Group", rather than the standard
used
> > in previous versions of Exchange with SBS where the org name was the
same
> as
> > the server name by default. If you are instead planning to using
Exmerge,
> > not using Exchange, or not upgrading an Exchange, you can use the SBS
> > Wizards for installing Exchange with no problem.
> >
> > 9. After you complete the SBS 2000 specific installation, finish
adding
> > any additional applications to fully install the server, such as AV,
> backup
> > software, whatever.
> >
> > 10. If you have finished installing all applications, you still have
> some
> > steps remaining on this Permanent DC that will be your SBS 2000. You now
> > want to recreate any shared folders and printers that you previously had
> > defined as local resources on your original SBS 4.5, using the same name
> > space. You have the option to change the permissions is that suits you,
or
> > you can recreate them by referring to the original SBS 4.5 that is still
> > operating the production LAN. You are concerned with making all the
shared
> > resources look the same on this computer as they did to the workstation
> > seeing the SBS 4.5. You may also need to create similar shares for
> > modemshare, fax or whatever.
> >
> > 11. Transition Time! This is where you will take the production LAN
> > offline line, and begin the shift to permanently remove the old SBS 4.5,
> > replacing it with the SBS 2000. At some point, you will have this new
SBS
> > 2000 server as close as possible to looking the same as the original SBS
> 4.5
> > from a network access standpoint. The critical point is that this
machine
> > still has the identical account SAM as the original domain. As long as
> you
> > have not revised the machine memberships or user accounts and passwords
> > since the time the Surrogate DC was created, you will not have to revise
> > anything on the new SBS 2000 when you connect it to the production LAN.
> The
> > only thing that remains to be done is migrate the data files themselves.
> You
> > can do this by physically attaching the SBS 4.5 production drives to
this
> > machine, or using an extra hard disk to do an XCOPY from the SBS 4.5 to
> the
> > drive for transport, then XCOPY onto the new DC. While it is possible to
> > directly connect the two machines back to back, I strongly discourage
> anyone
> > from doing this simply for concern that you are creating a very
dangerous
> > and complex situation that isn't supposed to every happen: two machines
> that
> > think they are the same machine, the same DC in the same domain, trying
to
> > talk to each other. That's an advance problem to deal with.
> >
> > 12. Advanced Issues. Once you have the data moved over, if you have
> > Exchange data, you can migrate it as well. This step would depend upon
the
> > process you planned. Once you have the Exchange migrated, you can
proceed
> > with the final step of the migration which follows. Other advanced
> problems
> > would be dealing with any customized changes you made with DHCP, WINS,
or
> > RRAS permissions in the original domain. All of the domain account
> > information was brought over in the early steps, but these other "server
> > application configuration" issues are just dependent upon what you did
in
> > the life of your SBS 4.5
> >
> > 13 Depending upon the amount of time that has passed, or the
> > configuration of your domain security, you can now do a normal powerdown
> of
> > the old SBS and plug in the new SBS 2000 in it's place. If the time
> passage
> > was significant, you may find that the workstations and member server
> can't
> > access the new SBS without removing and rejoining to the domain. This
will
> > not cause a profile problem, it just refreshes the account
> "authentication"
> > token. After rejoining the domain, the next logon should look
essentially
> > identical. You may need to verify that if you had done any customized
> logon
> > script changes, ensure that those are still present in the Netlogon
> > folder....they should be.
> >
> >
> > As a final comment, you may be wonder if there's a problem that you
> created
> > a temporary DC in the SBS 4.5 and never deleted it. That doesn't matter,
> you
> > might see some replication errors reported by the SBS 4.5 because it's
BDC
> > is missing, but that's it. As long as you faithfully recreated all of
the
> > shared folders and printers using the same name on the new SBS 2000 as
you
> > did in the original SBS 4.5, everything will be pretty transparent to
the
> > workstations. You will have the option to upgrade the client
applications
> > for all the workstations as your final step, and the only step other
than
> > the domain rejoin for workstations with stale accounts in the last step
of
> > the process.
> >
> >
> >
> > "Peter Smith" <noreply@noreply.com> wrote in message
> > news:bng0f0$obt$1$830fa17d@news.demon.co.uk...
> > > Hi
> > >
> > > This problem has probably been discussed many times before but anyway
> here
> > > goes:
> > >
> > > I have an SBS4.5 server with around 25 client machines (most are W2K,
1
> x
> > > W95, maybe 4 x NT4) plus one W2K server as a member server.
> > > I want to upgrade to SBS2000 on new hardware whilst preserving all the
> > > settings on the clients including printers and drive letters.
Currently
> > the
> > > SBS4.5 server only deals with domain controller authentication and
acts
> as
> > a
> > > proxy server for web access. SQL Server is not used at all and email
is
> > > currently handled by a third-party product so neither of these are an
> > issue
> > > at this stage ( although Exchange 2K will eventually be used on the
new
> > > server).
> > > I followed the advice of the Microsoft White Paper on upgrading to new
> > > hardware so I now have a new SBS2000 server with user accounts and
> groups
> > on
> > > it. The web proxy works at least for local logins to the server and
all
> > > seems OK.
> > >
> > > The W2K member server currently has all data for the network on it and
> all
> > > printers and plotters are hosted by it. Therefore all clients have
> printer
> > > and file shares to this machine. The idea was that this would simplify
> the
> > > changeover to the new small business server. Many of the client
machines
> > use
> > > AutoCAD which seems sensitive to plotter setups so I didn't want to
> > disturb
> > > them by having to change machines for printer shares. Also, many of
the
> > > clients using a drawing package with a network license file kept on
the
> > > member server. If the location of this license file changes in terms
of
> > > hostname or drive letter, it stops working and the only solution
appears
> > to
> > > be to regenerate the license file from the manufacturer and reinstall
> the
> > > software on each client machine! Clearly I didn't want to do this
hence
> > the
> > > emphasis on maintaining shares on the existing member server during
> > > changeover.
> > >
> > > My problem is this:
> > >
> > > The Microsoft White Paper does not detail how to carry profiles over
to
> > the
> > > new server, which is now Active Directory. Also how are file and share
> > > permissions maintained in the move.
> > > I set up two client machines, one W2K and one NT4, where I imaged the
> > system
> > > partition so I could undo any changes if there was a problem.
> > >
> > > I then did the following:
> > >
> > > Copied the profile of each main user of each client machine to a
> separate
> > > location on the local disk using the Microsoft Copy Profile option in
> > > control panel..
> > > Shutdown all other machines and started up the new SBS2000 server
which
> > has
> > > the same Domain name, NetBIOS name and IP address as the old SBS4.5
> > server.
> > > Moved each client machine out of the domain, rebooted and brought it
> back
> > > into the domain (note that DHCP is not used on the network so I don't
> > > necessarily need the network setup floppy which SBS2000 generates
> although
> > > in truth I tried doing the changeover both with and without this).
> > > Copied the main user profile from the local disk of each client
machine
> to
> > a
> > > location on the server and amended the Active Directory entry for each
> of
> > > these users to point to this profile. I assume this sets each user up
> with
> > a
> > > roaming profile (which I do not ultimately want) in the new domain.
> > > Finally I logged in on the client machines as the main user.
> > > This seemed to work fine in that the profile pointed to in AD was
> > downloaded
> > > to the local machine except the users had lost all printer and file
> shares
> > > which was one of the key things I wanted to preserve!
> > >
> > > What I need to know is this:
> > >
> > > How do I preserve the file and printer shares?
> > > Can I move back to local profiles on the client machines at a later
> stage?
> > > Will file and share permissions and the shares themselves be
maintained
> on
> > > the member server when it is moved to the new domain?
> > >
> > > I need to implement the changeover during a weekend with limited
> resources
> > > (i.e. me plus maybe one other!) so the whole exercise is time
critical -
> > > they must be up and running entirely by Monday morning!
> > >
> > > Thanks for your patience in reading this and any help gratefully
> received.
> > >
> > > Peter
> > >
> > >
> >
> >
>
>