SBS 2k8 new install

[charlie]

Sometimes I perform 5 minutes operations for my customers that they
are not able to do and I get paid for.
>> 2. Whe MS is really interested (i.e. Vista to Win7 migration) they may
make miracles !

[natalie]

Not when you are jumping from 32 bit to 64bit. Which is what is
> happening here.
>
> Secondly Exchange does not support an inplace upgrade, nor will it to
> Exchange 2010.
>
> You have to live with the law of physics here.
>
> Even Microsoft does not support any sort of inplace upgrade from 32 bit
> to 64bit. There is no miracle here.

[natalie]

It could be sufficient to prepare a working AD migration tools for
exporting
> and re-importing users and computers (to a domain with the same name)

[boris]

But that's what the migration join does now. You install SBS 2008 in
"migration mode" ... basically you set up the answer file and have the
new server see the old server and it joins the new server to the domain,
the domain replication replicates across the usernames and computers as
part of the process.

These tools are available already to extract out information and import
it back in. But even if you do that you haven't migrated across the
SIDs of the computer. If you change the SIDs (security identifiers of
the computers), you'll break the domain join and have a boatload of
errors in your event log.
Using LDIFDE to import and export directory objects to Active Directory:
http://support. <http://support. microsoft. com/kb/237677>
microsoft.com/ kb/237677 <http://support.
<http://support. microsoft. com/kb/237677> microsoft.com/ kb/237677>

The best way to migrate is exactly what the SBS migration process is
doing. Take a new server, join the domain, let the AD information
replicate across.

It's just flat out a lot of work to rip out a fully functioning network
and replace a server. There's no short cuts here. I've said this for
several years about active directory.. I love the glue of the active
directory, but at the same time, that glue means that it's not as easy
as moving a workgroup would be.

[charlie]

And it wasn't that much easier in an NT4 domain. Most of the same problems
(SIDs and UNCs) are not just 'similar' but 'same'.

natalie is right in pointing out a certain point, particularly for single DC
implementations, which the great majority of SBS systems are. You are
replacing the very basis of your network, do not expect this to be easy.

OTOH, most of the swing (or swinglike) processes are specifically designed
to get around the limitations imposed by SBS Dev. These limitations were
implemented by MS to give SBS owners an inexpensive system.

MY (personal) appreciation of swing(like) processes has already been
mentioned. The ability to back out if it goes wrong. I hate to put words
into Jeff's mouth but believe I can get away with this one. One of Jeff's
primary considerations was that 'business continuance' occurs during the
migration. There is a point at which one must decide 'yep, I want this new
system' (or not) and if performed properly the swing process(es) minimises
disruption during this time.

[boris]

I see that the fastest way is to install the new server at
my site ,testing it for some days. Rejoining users one by on will take few
hours of a week end

[asbasb]

OK, people are starting to "get it".

Presumably there is a user count below which you're better off just building a new server on a new domain SID and manually migrating stuff. The questions would be:

a) at what user does that tend to occur? 5 User, say?

b) that are the best practices for doing so.

Because, frankly, if you approach a very small site that is a good candidate for upgrade to SBS 2008, and you tell them it will take an amount of work appropriate for a site two or three times that size... they may not look at you like you're nuts, but they'll think it.

So far nobody's disabused me of my notion that Jeff's swing is over-scale for that sort of thing, either.

It does seem really odd that there doesn't seem to be a way to preserve the SID on the new server while doing everything else like a new install. Could have sworn there used to be a technique where you did the first-stage build as a non-DC member server. Must have been imagining it.

[charlie]

I'd argue that it's not user count where this is important but how comfy
you feel with the Active Directory health.

Jeff's swing/swing ensures that you get the same experience as Microsoft
but you do not damage the original sbs 2003 box, you also get the bonus
of the same server name.

Microsoft method uses the AD concepts.

Clean install (and yes I did one in my own server network between SBS
2000 and SBS 2003. I spent Thanksgiving at the office. I did it
because I didn't like the AD naming.

No matter if it's a small network or not, clean install isn't
necessarily better, it's just a clean install.

[grestone]

You aren't imaging that intermediate step but 2008 is a whole new monster. It loads from imaged files and there's no opportunity to stop in the middle.

[charlie]

You said what I was going to say - the *number* is totally irrelevant, but the health of the existing AD is the important factor here. A healthy 5 person setup could be relatively easily migrated whereas an unhealthy 40 person setup would not be something I'd want to undertake. It really is a case where horses for courses is an appropriate phrase.

--

http://hiltont. blogspot. com/