Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Post by Mark » Thu, 04 Jul 2002 14:58:50



Hi All,

Currently determining the best way to upgrade SBS 4.5 to SBS 2000 on the
same hardware.

Ever since SBS 4.0 was installed here in 1997, the client setup disks have
never been used to add our ~25 users to the SBS server.

To add new users, I manually make/share their home folders under 'users
shared folders' and manually set their options in User Manager for Domains.
I also manually install outllook/proxy client on the client pcs.

All our client machines are Win2k, and a few XP pro.

Aside from the SBS console not working, (IIS settings issue after trying to
publish the company website to the sbs server for internal testing), there
are no other significant problems with the way the server runs.

I'm guessing we would be a candidate for an inplace upgrade, but was just
wondering if the manual user setup from the past will cause any problems or
create extra work? Also, I assume the SBS 2k console will overwrite any
problems with our current ISA settings?

I guess I want to know if I have to sort these problems out before the
upgrade, or if they are trivial and should pose no major problems during the
upgrade process.

Thanks

 
 
 

Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Post by Pat Horridg » Thu, 04 Jul 2002 18:51:52



Quote:> Hi All,

> Currently determining the best way to upgrade SBS 4.5 to SBS 2000 on the
> same hardware.

> Ever since SBS 4.0 was installed here in 1997, the client setup disks have
> never been used to add our ~25 users to the SBS server.

> To add new users, I manually make/share their home folders under 'users
> shared folders' and manually set their options in User Manager for
Domains.
> I also manually install outllook/proxy client on the client pcs.

> All our client machines are Win2k, and a few XP pro.

> Aside from the SBS console not working, (IIS settings issue after trying
to
> publish the company website to the sbs server for internal testing), there
> are no other significant problems with the way the server runs.

> I'm guessing we would be a candidate for an inplace upgrade, but was just
> wondering if the manual user setup from the past will cause any problems
or
> create extra work? Also, I assume the SBS 2k console will overwrite any
> problems with our current ISA settings?

> I guess I want to know if I have to sort these problems out before the
> upgrade, or if they are trivial and should pose no major problems during
the
> upgrade process.

> Thanks

My advse would be don't upgrade but do a clean install. There are processes
you can follow to minimise the work required to get everything back. It's
the best way to get a "clean" setup.

 
 
 

Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Post by Jeff Middleton [SBS-MVP » Thu, 04 Jul 2002 21:57:35


I did most of my SBS 4.5 upgrades as in-place upgrades. The only serious
problems related to cleaning out old product versions before the upgrade,
and confirming that the correct device drivers were in use after the initial
conversion from NT to W2K.

As for the upgrade of a cracked install. I did exactly what you are
referring to. I performed an SBS 2K upgrade of an SBS 4.5 with IIS broken
and none functional. Dr. Watson launched when the server started everytime
due to IIS issues. After trying for an hour or two to fix IIS, I decided to
just roll through the upgrade to see if it made it. It did. Absolutely no
problem. In fact, when I did this upgrade, this server (for reasons I'll not
explain) upgraded with only 2.3G free on the system partition, and 1.5G free
on the data partition. When I finished, I had 800 Mb on the system
partition, and 1G on the back partition because I redirected the clientapps
to the back partition during the install.

I believe that either approach to the upgrade is workable, you just need to
choose your battle.




> > Hi All,

> > Currently determining the best way to upgrade SBS 4.5 to SBS 2000 on the
> > same hardware.

> > Ever since SBS 4.0 was installed here in 1997, the client setup disks
have
> > never been used to add our ~25 users to the SBS server.

> > To add new users, I manually make/share their home folders under 'users
> > shared folders' and manually set their options in User Manager for
> Domains.
> > I also manually install outllook/proxy client on the client pcs.

> > All our client machines are Win2k, and a few XP pro.

> > Aside from the SBS console not working, (IIS settings issue after trying
> to
> > publish the company website to the sbs server for internal testing),
there
> > are no other significant problems with the way the server runs.

> > I'm guessing we would be a candidate for an inplace upgrade, but was
just
> > wondering if the manual user setup from the past will cause any problems
> or
> > create extra work? Also, I assume the SBS 2k console will overwrite any
> > problems with our current ISA settings?

> > I guess I want to know if I have to sort these problems out before the
> > upgrade, or if they are trivial and should pose no major problems during
> the
> > upgrade process.

> > Thanks

> My advse would be don't upgrade but do a clean install. There are
processes
> you can follow to minimise the work required to get everything back. It's
> the best way to get a "clean" setup.

 
 
 

Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Post by IB1 » Thu, 04 Jul 2002 21:57:45


is there a list of these processes anywhere?
i want to do a clean install on the same hardware.
it currently runs sbs 4.5 i want to do an upgrade via clean install to 2000.




> > Hi All,

> > Currently determining the best way to upgrade SBS 4.5 to SBS 2000 on the
> > same hardware.

> > Ever since SBS 4.0 was installed here in 1997, the client setup disks
have
> > never been used to add our ~25 users to the SBS server.

> > To add new users, I manually make/share their home folders under 'users
> > shared folders' and manually set their options in User Manager for
> Domains.
> > I also manually install outllook/proxy client on the client pcs.

> > All our client machines are Win2k, and a few XP pro.

> > Aside from the SBS console not working, (IIS settings issue after trying
> to
> > publish the company website to the sbs server for internal testing),
there
> > are no other significant problems with the way the server runs.

> > I'm guessing we would be a candidate for an inplace upgrade, but was
just
> > wondering if the manual user setup from the past will cause any problems
> or
> > create extra work? Also, I assume the SBS 2k console will overwrite any
> > problems with our current ISA settings?

> > I guess I want to know if I have to sort these problems out before the
> > upgrade, or if they are trivial and should pose no major problems during
> the
> > upgrade process.

> > Thanks

> My advse would be don't upgrade but do a clean install. There are
processes
> you can follow to minimise the work required to get everything back. It's
> the best way to get a "clean" setup.

 
 
 

Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Post by Mark » Fri, 05 Jul 2002 08:55:18


Hi,

I researched the clean install upgrade to SBS 2k option.

If you have a lot of WinNT/2K/XP client machines on the SBS Lan, it may be
worthwhile taking extra steps to preserve the domain SAM and profile SIDs.
This stops you having to add all the client PCs to the lan, and mess around
with all the users profiles.

This procedure is documented in Jeff's excellent posts titled "Re: Off Line
upgrade and managing the client profiles" written on 25 April and 30 April
this year. These posts describe the steps involved in doing a fresh SBS 2000
install while retaining the old Domain SAM.

If you don't have many NT/2K/XP clients, then it might not be worth while
taking the extra steps to preserve the domain SAM.

Cheers


> is there a list of these processes anywhere?
> i want to do a clean install on the same hardware.
> it currently runs sbs 4.5 i want to do an upgrade via clean install to
2000.





> > > Hi All,

> > > Currently determining the best way to upgrade SBS 4.5 to SBS 2000 on
the
> > > same hardware.

> > > Ever since SBS 4.0 was installed here in 1997, the client setup disks
> have
> > > never been used to add our ~25 users to the SBS server.

> > > To add new users, I manually make/share their home folders under
'users
> > > shared folders' and manually set their options in User Manager for
> > Domains.
> > > I also manually install outllook/proxy client on the client pcs.

> > > All our client machines are Win2k, and a few XP pro.

> > > Aside from the SBS console not working, (IIS settings issue after
trying
> > to
> > > publish the company website to the sbs server for internal testing),
> there
> > > are no other significant problems with the way the server runs.

> > > I'm guessing we would be a candidate for an inplace upgrade, but was
> just
> > > wondering if the manual user setup from the past will cause any
problems
> > or
> > > create extra work? Also, I assume the SBS 2k console will overwrite
any
> > > problems with our current ISA settings?

> > > I guess I want to know if I have to sort these problems out before the
> > > upgrade, or if they are trivial and should pose no major problems
during
> > the
> > > upgrade process.

> > > Thanks

> > My advse would be don't upgrade but do a clean install. There are
> processes
> > you can follow to minimise the work required to get everything back.
It's
> > the best way to get a "clean" setup.

 
 
 

Will minor issues on 4.5 cause problems with inplace upgrade to SBS 2000?

Post by Susan Bradley, CPA aka » Sat, 06 Jul 2002 03:06:17


It's worth it.  The Win2k/XP's will truly build a new client profile even though
they are connecting to the same box.  I've clean installed/rebuilt my server at
home a couple of times and obviously the SID changes.... pain in the you know
what to move those profiles plus every Frontpage web site that I do has lost the
"saved" password for publishing and I have to look those dang passwords up
again.....

---------------------------------
From: Jeff Middleton [SBS-MVP] (j...@cfisolutions.com)
Subject: Re: Off Line upgrade and managing the client profiles
Newsgroups: microsoft.public.backoffice.smallbiz2000
View: Complete Thread (8 articles) | Original Format
Date: 2002-04-24 08:36:59 PST

Don't do it that way?   :)

Yup, that's a problem with a distinctly separate and parallel installation.
Doesn't matter that you use all the same names and settings, the servers
actually are based upon totally different Security Account Management
databases (SAM). Therefore, the Security Identifiers (SIDs) for each user
and workstation are uniquely not the same. This means that anything based
upon security IDs will be broken, and that means everything. All the
profiles, network shares, file ownerships, folder permissions, Exchange
mailbox ownerships, ISA firewall settings, Security Groups.....it's a whole
new thing.

The way to avoid this is to preserve the old domain from the old server.
Think of this as the way that the centuries old traditions of preserving
bloodlines worked. Either keep the king, queen or marry into the family.

Your SBS 4.5 server is the Domain Controller for your domain, I'm sure you
know. If you want to migrate to a new server, and you have NT/W2K/XP
workstations, the only way to preserve the SAM/SIDs is to preserve the
"domain database" itself. Each NT family workstation/server has a local SAM.
When you create a domain, the first server's SAM  becomes the SAM for the
domain. Each new DC (NT called them BDCs) you add to the domain obtains a
copy of the very same SAM. Replication of changes to the SAM ensures that
over time, all DCs maintain a copy of the very same SAM. This is the
marriage bloodline thing.

If you have only one DC, the SBS 4.5 PDC, the only ways to preserve the SAM
is to either "migrate" the NT installation to the new hardware, or to use
the Domain tools to add a new server to the domain as a BDC, then detach it,
make it the new PDC and go from there. If you are intending this computer to
remain the PDC and actually become the original SBS on new hardware, you
would have to rename the computer after that to agree to what you originally
had. This can work, but it can involve some complexities.  Migrating the
installation is along the lines of 'move the hard drive to another computer'
and hope it will work there. That's got some technical issues.

Yet another twist on the PDC/BDC migration method is to do it "twice".
Introduce a BDC on a temporary machine. Let it hold the SAM. Now, introduce
the new server you really intend to be the permanent SBS on new hardware.
After promoting your temporary BDC to the PDC, you kill of the old SBS from
this server's understanding of the domain, and now you install your new SBS
reusing the old SBS name and settings as you did in your process described
in your post. By making it a BDC, you again pull the SAM over to it. Same
SAM, same SIDS, you have the bloodline preserved.

The only problem here is that with SBS 4.5, you couldn't do this. SBS 4.5
didn't allow you to preserve or upgrade a scratch installed SBS server and
bring the SAM from another server. However, With SBS 2000, this can be done.
You must accomplish it once you have the computer upgraded to a Windows 2000
DC.

Therefore, to get the sequence down, you have an old SBS 4.5. You create a
new BDC in NT. Detach the BDC, convince it the original SBS 4.5 is gone and
dead, promote this computer to PDC of the domain. Now, if this is going to
be the SBS server, you would have to rename the server while it has nothing
more than NT on it (no other applications). This has some complications, but
it can work.  Next, upgrade this server to Windows 2000. From here, you now
install the SBS 2000 software and you have preserved the SAM.

Alternatively, if you are trying to use the double PDC swap to get a new
machine build from scratch to be SBS 2000 and not start as an NT BDC then
upgraded, you would leave the NT BDC named something other than the SBS, the
way you created it when you made it a BDC. Kill off the old SBS. Next, with
the temporary server you upgrade it to W2K, install AD. Now you have the SAM
preserved and an AD structure. You now build a new W2K Server from scratch
named for your final SBS name and such, and introduce it as a DC in this AD
domain. This computer now has the name of the SBS, it's a DC, and it's got
AD installed.  You kill off the temporary DC and you proceed to complete the
SBS upgrade.

If all of that sounds too confusing, then you really are stuck with the
wealth of issues that come from having different profiles, security
accounts, shares and such.

Overall, this is why I personally prefer to migrate the original SBS to new
hardware, don't deal with the BDC thing, just move the installed system.
From there, I upgrade as normal, just have new hardware under it. This
involves some technical complications, but since they are all accomplished
in the first steps, I prefer it.

"Theo" <t...@makingitwork.co.uk> wrote in message

news:aa6fka$l61$1@paris.btinternet.com...

> We have had to rebuild an SBS 2000 server and got in a bit of a mess with
> the user profiles on each PC. Even with the same domain name the users were
> seen as new and we had to recover and move stuff from the "old" desktop,
> mydocuments, favorites etc.
> In this situation or when upgrading 4.5 to 2000 on new hardware is there a
> recommended procedure for managing this?

From: Jeff Middleton [SBS-MVP] (j...@cfisolutions.com)
Subject: Re: Off Line upgrade and managing the client profiles
Newsgroups: microsoft.public.backoffice.smallbiz2000
View: Complete Thread (8 articles) | Original Format
Date: 2002-04-29 10:41:44 PST

Doing the parallel installation of the server as a BDC, but replacing the
previous SBS has a specific catch to the process. If you intend to bring the
accounts over from the existing SBS by adding another machine as a DC, you
have to understand a technical complication that is different in NT DCs vs.
W2K AD DCs.  It's a pretty straightforward process to rename a DC in NT, it
a non-starter suggestion in AD. Here's why.

NT DCs have a common SAM, and that's what makes them recognize their
security structure and membership. (oversimplification, but okay)  If you
have a BDC in NT, you detach from the domain, you can instruct that computer
to promote to PDC, delete the old computer account for the previous PDC, and
now you run the show on this computer. If it's the only DC in the domain,
you can now even rename the computer itself provided that you don't have
other applications installed on it like SQL or Exchange. Therefore, it's
possible to move the accounts over to the machine while it's a BDC, detach
it, delete the old PDC from the domain (as far as this machine is concerned)
and rename the server to actually be what the previous PDC was. From there,
if you upgrade to W2K, then add AD, you have "the same server name" and the
same SAM that feeds into AD when it is constructed. This works. You then
install Exchange using the same site and organization name as the previous
SBS used, and you have a functional slipstream server construction. You
simply take the actual Exchange .edb files and mount them on this new
server.

Now, if you try the same idea in W2K once you have AD structure, it doesn't
work. You can't rename a server in AD like that if it's the only DC.
Technically, the way you rename DCs in AD is you DCpromot demote them, then
rename, then DCpromo them back as a DC. This way, the computer may be
technically renamed, but as far as AD is concerned, it's a different
computer.

Therefore in W2K, if you have an SBS server named SBSORIGINAL, and you want
to add a new server to take over the role of the SBS, have the same name as
the original, but you already have the server you are trying to rename in
AD, you have to provide yet another DC to make that possible.  Therefore you
will need 3 servers over time. You need SBSORIGINAL, DCTEMP, and SBSFINAL.
The sequence would be parallel to the first one for getting from NT to AD,
but you use a temporary server to get the SAM from NT to AD. Here how:

SBSORIGINAL is running SBS 4.5. You add a new server termporarily to the NT
domain, running NT. You make it named DCTEMP, make it a BDC. Now, detach it,
delete (in it's realm) the SBSORIGINAL from the domain and promote DCTEMP to
PDC. Now, upgrade DCTEMP to W2K, build the AD structure. Now you have a W2K
Server, AD constructed based upon the original SAM. Now you scratch build
your desired SBS2K machine by installing W2K Server in a normal (not SBS
scripted) way. You make this machine have the same name as the original SBS
did. Once you have it ready, you make it a DC. Now it's got the same Netbios
name, same SAM, and it's an AD DC. At this point, you DCpromo demote the
DCTEMP to remove it from AD, and to leave the new SBS box as the only DC in
a W2K Domain. Now you have what you needed: A scratch build SBS, never ran
NT, pure loaded in W2K as a W2K server and is the entire AD server role on
one box. You can now run SBS 2000 upgrade as if this were a brand new domain
being upgraded from W2K to SBS2000. When you get to the part about
installing Exchange, you can either use an exmerge to import the files, or
again, if you name the Organization and Site the same as the old SBS server
used, you can actually just load the .edb files directly from the old
server.  In order to do this trick, you must not install Exchange 2000 using
the SBS wizard setup, you must do a manual installation of Exchange ...

read more »