I would like to setup a new server (SBS 2008) and bring clients over
to it 2 at a time while the others are working on the old setup (SBS
2003) -- if i had them on separate networks (so the two didn't see
each other) and they each had their own static IP for internet, what
would the drawbacks be? That way i could bring our network up to the
new server over a week instead of having downtime?



The reason i want to do it slower is to convert each client computer
to windows 7 (or back to XP for some) with clean installs since we
had a nasty virus issue a bit ago and i don't believe it is completely
eradicated.

jared

Several drawbacks that I can see.

1) Email routing. If you use exchange, since he external domain would
presumably be he same, getting the email routed to the proper internal
server will be downright tedious since it has to be done per user.

2) File access. Separate networks means the clients don't see both servers
and the servers don't see each other. If you use SBS as a file server *at
all* (and I'd be surprised if you don't, but I guess it is possible) then
how do clients on the different networks share files? Sneakernet?
Introducing a big chance of file-version creep with that one.

3) Sharepoint access. Same issue as above, but for sharepoint instead of
files.

4) I'm also not a fan of introducing new OS's at the same time as a
file-server upgrade. Troubleshooting problems *really* becomes a nightmare.
Someone reports that they aren't getting some emails. IS that the server?
Is it a bug with outlook 200(x) on Win(Y)? ....just bad mojo.

In short? Do the client conversion first. I'd want to be 100% sure my
network is clean of malware *before* introducing a new server. Address any
OS/machine bizarreness and make sure your network is operating at peak
efficiency. THEN do the server migration, which you can now do without the
complication of upgrading clients and can thus do a planned phased migration
where both servers see each other and services are moved within the 21-day
grace period. Avoids all 4 of the hurdles I mention above.

-Cliff


"Jaredean" <shop@newsgroup> wrote in message
news:iq5qi590ei2chr4qk80fkt2mi9jdjmspen@newsgroup

> I would like to setup a new server (SBS 2008) and bring clients over
> to it 2 at a time while the others are working on the old setup (SBS
> 2003) -- if i had them on separate networks (so the two didn't see
> each other) and they each had their own static IP for internet, what
> would the drawbacks be? That way i could bring our network up to the
> new server over a week instead of having downtime?
>
> The reason i want to do it slower is to convert each client computer
> to windows 7 (or back to XP for some) with clean installs since we
> had a nasty virus issue a bit ago and i don't believe it is completely
> eradicated.
>
> jared

Thanks Cliff - i appreciate your feedback and have decided you are
right - not a good idea...

Just looking for the least amound of downtime possible...

As far as doing the client update first, what if there are issues with
the server and i clean a client off and then put it back into the
network with the old server and they are "served" the issue again in
the background? I've been told you can never be 100% sure that you
are all clean, so short of doing clients/server all at once i don't
see any other way of knowing 100%...

jared

On Sat, 19 Dec 2009 13:41:08 -0700, "Cliff Galiher"
<cgaliher@newsgroup> wrote:

>Several drawbacks that I can see.
>
>1) Email routing. If you use exchange, since he external domain would
>presumably be he same, getting the email routed to the proper internal
>server will be downright tedious since it has to be done per user.
>
>2) File access. Separate networks means the clients don't see both servers
>and the servers don't see each other. If you use SBS as a file server *at
>all* (and I'd be surprised if you don't, but I guess it is possible) then
>how do clients on the different networks share files? Sneakernet?
>Introducing a big chance of file-version creep with that one.
>
>3) Sharepoint access. Same issue as above, but for sharepoint instead of
>files.
>
>4) I'm also not a fan of introducing new OS's at the same time as a
>file-server upgrade. Troubleshooting problems *really* becomes a nightmare.
>Someone reports that they aren't getting some emails. IS that the server?
>Is it a bug with outlook 200(x) on Win(Y)? ....just bad mojo.
>
>In short? Do the client conversion first. I'd want to be 100% sure my
>network is clean of malware *before* introducing a new server. Address any
>OS/machine bizarreness and make sure your network is operating at peak
>efficiency. THEN do the server migration, which you can now do without the
>complication of upgrading clients and can thus do a planned phased migration
>where both servers see each other and services are moved within the 21-day
>grace period. Avoids all 4 of the hurdles I mention above.
>
>-Cliff
>
>
>"Jaredean" <shop@newsgroup> wrote in message
>news:iq5qi590ei2chr4qk80fkt2mi9jdjmspen@newsgroup

>> I would like to setup a new server (SBS 2008) and bring clients over
>> to it 2 at a time while the others are working on the old setup (SBS
>> 2003) -- if i had them on separate networks (so the two didn't see
>> each other) and they each had their own static IP for internet, what
>> would the drawbacks be? That way i could bring our network up to the
>> new server over a week instead of having downtime?
>>
>> The reason i want to do it slower is to convert each client computer
>> to windows 7 (or back to XP for some) with clean installs since we
>> had a nasty virus issue a bit ago and i don't believe it is completely
>> eradicated.
>>
>> jared

There's no need for any significant downtime anyway. With either the
Microsoft or the swing migration method, both servers are available to all
clients until there's nothing left to use the old one for (or the 21 days
max allowed for the transition)

You do have to move Exchange--and I'd recommend starting early or mid week,
and moving mailboxes over a weekend--that worked well for me. I had
expected to need to babysit the process in the office, and that wasn't
needed at all--I did some of the work in normal working hours in the office,
and then some things that took longer--moving Exchange, over that weekend,
working from home.

Read the docs--buy your hardware--do a test install of a trial version of
SBS 2008 to be sure you've got the right drivers for the system to be rock
solid stable before you start the real thing--read both the migration
document and the checklist, have multiple copies on hand various places so
you can always refer to them--and do a good job of cleaning the old machine
up. I didn't bother with cleaning up mailboxes or reducing their size--but
I had a gigabit network to move them over. But I did run the BPA analyzers
and others on the old server and did some cleanup before starting out.



"Jaredean" <shop@newsgroup> wrote in message
news:iq5qi590ei2chr4qk80fkt2mi9jdjmspen@newsgroup

> I would like to setup a new server (SBS 2008) and bring clients over
> to it 2 at a time while the others are working on the old setup (SBS
> 2003) -- if i had them on separate networks (so the two didn't see
> each other) and they each had their own static IP for internet, what
> would the drawbacks be? That way i could bring our network up to the
> new server over a week instead of having downtime?
>
> The reason i want to do it slower is to convert each client computer
> to windows 7 (or back to XP for some) with clean installs since we
> had a nasty virus issue a bit ago and i don't believe it is completely
> eradicated.
>
> jared

It is commonly accepted (and I agree) that once a *machine* is compromised,
because it can install DLL's and such, that you can't be sure that you've
gotten rid of a virus without a clean install. That logic does *not* extend
to the network. You can install a machine, fully patched, into a network as
long as you know what exploit caused the problem and make sure the machine
is protected from that exploit out of the gate.

But yes, if your server was also compromised (very very bad) then you will
be looking at a disruptive install. Migration is no longer a legitimate
option because a virus could have created its own accounts or changed
settings in Active Directory on behalf of an operator to grant the operator
access later. Even an OS re-install won't clean up AD automatically since
migrations move that data over.

So the real question is, was your server compromised?

-Cliff


"Jaredean" <shop@newsgroup> wrote in message
news:tkfri5tqsu4ekks1nrc57hrkrfohkfruuo@newsgroup

> Thanks Cliff - i appreciate your feedback and have decided you are
> right - not a good idea...
>
> Just looking for the least amound of downtime possible...
>
> As far as doing the client update first, what if there are issues with
> the server and i clean a client off and then put it back into the
> network with the old server and they are "served" the issue again in
> the background? I've been told you can never be 100% sure that you
> are all clean, so short of doing clients/server all at once i don't
> see any other way of knowing 100%...
>
> jared
>
> On Sat, 19 Dec 2009 13:41:08 -0700, "Cliff Galiher"
> <cgaliher@newsgroup> wrote:
>

>>Several drawbacks that I can see.
>>
>>1) Email routing. If you use exchange, since he external domain would
>>presumably be he same, getting the email routed to the proper internal
>>server will be downright tedious since it has to be done per user.
>>
>>2) File access. Separate networks means the clients don't see both
>>servers
>>and the servers don't see each other. If you use SBS as a file server *at
>>all* (and I'd be surprised if you don't, but I guess it is possible) then
>>how do clients on the different networks share files? Sneakernet?
>>Introducing a big chance of file-version creep with that one.
>>
>>3) Sharepoint access. Same issue as above, but for sharepoint instead of
>>files.
>>
>>4) I'm also not a fan of introducing new OS's at the same time as a
>>file-server upgrade. Troubleshooting problems *really* becomes a
>>nightmare.
>>Someone reports that they aren't getting some emails. IS that the server?
>>Is it a bug with outlook 200(x) on Win(Y)? ....just bad mojo.
>>
>>In short? Do the client conversion first. I'd want to be 100% sure my
>>network is clean of malware *before* introducing a new server. Address
>>any
>>OS/machine bizarreness and make sure your network is operating at peak
>>efficiency. THEN do the server migration, which you can now do without the
>>complication of upgrading clients and can thus do a planned phased
>>migration
>>where both servers see each other and services are moved within the 21-day
>>grace period. Avoids all 4 of the hurdles I mention above.
>>
>>-Cliff
>>
>>
>>"Jaredean" <shop@newsgroup> wrote in message
>>news:iq5qi590ei2chr4qk80fkt2mi9jdjmspen@newsgroup

>>> I would like to setup a new server (SBS 2008) and bring clients over
>>> to it 2 at a time while the others are working on the old setup (SBS
>>> 2003) -- if i had them on separate networks (so the two didn't see
>>> each other) and they each had their own static IP for internet, what
>>> would the drawbacks be? That way i could bring our network up to the
>>> new server over a week instead of having downtime?
>>>
>>> The reason i want to do it slower is to convert each client computer
>>> to windows 7 (or back to XP for some) with clean installs since we
>>> had a nasty virus issue a bit ago and i don't believe it is completely
>>> eradicated.
>>>
>>> jared

I don't believe the server was compromised, to the best of my
knowledge...there were two different instances and both were client
machines compromised and sending out tons of spam that got us
blacklisted...it took a while to lock them down again, but i think we
are pretty close to clean now - but i can't be positive...

jared

On Sun, 20 Dec 2009 14:44:24 -0700, "Cliff Galiher"
<cgaliher@newsgroup> wrote:

>It is commonly accepted (and I agree) that once a *machine* is compromised,
>because it can install DLL's and such, that you can't be sure that you've
>gotten rid of a virus without a clean install. That logic does *not* extend
>to the network. You can install a machine, fully patched, into a network as
>long as you know what exploit caused the problem and make sure the machine
>is protected from that exploit out of the gate.
>
>But yes, if your server was also compromised (very very bad) then you will
>be looking at a disruptive install. Migration is no longer a legitimate
>option because a virus could have created its own accounts or changed
>settings in Active Directory on behalf of an operator to grant the operator
>access later. Even an OS re-install won't clean up AD automatically since
>migrations move that data over.
>
>So the real question is, was your server compromised?
>
>-Cliff
>
>
>"Jaredean" <shop@newsgroup> wrote in message
>news:tkfri5tqsu4ekks1nrc57hrkrfohkfruuo@newsgroup

>> Thanks Cliff - i appreciate your feedback and have decided you are
>> right - not a good idea...
>>
>> Just looking for the least amound of downtime possible...
>>
>> As far as doing the client update first, what if there are issues with
>> the server and i clean a client off and then put it back into the
>> network with the old server and they are "served" the issue again in
>> the background? I've been told you can never be 100% sure that you
>> are all clean, so short of doing clients/server all at once i don't
>> see any other way of knowing 100%...
>>
>> jared
>>
>> On Sat, 19 Dec 2009 13:41:08 -0700, "Cliff Galiher"
>> <cgaliher@newsgroup> wrote:
>>

>>>Several drawbacks that I can see.
>>>
>>>1) Email routing. If you use exchange, since he external domain would
>>>presumably be he same, getting the email routed to the proper internal
>>>server will be downright tedious since it has to be done per user.
>>>
>>>2) File access. Separate networks means the clients don't see both
>>>servers
>>>and the servers don't see each other. If you use SBS as a file server *at
>>>all* (and I'd be surprised if you don't, but I guess it is possible) then
>>>how do clients on the different networks share files? Sneakernet?
>>>Introducing a big chance of file-version creep with that one.
>>>
>>>3) Sharepoint access. Same issue as above, but for sharepoint instead of
>>>files.
>>>
>>>4) I'm also not a fan of introducing new OS's at the same time as a
>>>file-server upgrade. Troubleshooting problems *really* becomes a
>>>nightmare.
>>>Someone reports that they aren't getting some emails. IS that the server?
>>>Is it a bug with outlook 200(x) on Win(Y)? ....just bad mojo.
>>>
>>>In short? Do the client conversion first. I'd want to be 100% sure my
>>>network is clean of malware *before* introducing a new server. Address
>>>any
>>>OS/machine bizarreness and make sure your network is operating at peak
>>>efficiency. THEN do the server migration, which you can now do without the
>>>complication of upgrading clients and can thus do a planned phased
>>>migration
>>>where both servers see each other and services are moved within the 21-day
>>>grace period. Avoids all 4 of the hurdles I mention above.
>>>
>>>-Cliff
>>>
>>>
>>>"Jaredean" <shop@newsgroup> wrote in message
>>>news:iq5qi590ei2chr4qk80fkt2mi9jdjmspen@newsgroup
>>>> I would like to setup a new server (SBS 2008) and bring clients over
>>>> to it 2 at a time while the others are working on the old setup (SBS
>>>> 2003) -- if i had them on separate networks (so the two didn't see
>>>> each other) and they each had their own static IP for internet, what
>>>> would the drawbacks be? That way i could bring our network up to the
>>>> new server over a week instead of having downtime?
>>>>
>>>> The reason i want to do it slower is to convert each client computer
>>>> to windows 7 (or back to XP for some) with clean installs since we
>>>> had a nasty virus issue a bit ago and i don't believe it is completely
>>>> eradicated.
>>>>
>>>> jared

Thanks Bill - in the past i think i've pretty done it by doing a clean
install on all systems, but then setting up the new server and not
moving Exchange over (wasn't using exchange on the 2000 sbs server),
but having the clients restore their mail from a backup and then
having that "feed" the exchange server...this time around facing the
moving on the exchange server i want to make sure i'm doing it the
best way possible...i assume moving it instead of backing up the
clients and restoring them to feed it is the preferred way :-)

But, we are having some indexing issues with Windows Search / Outlook
on one client that is baffling - i've replaced their OS with a clean
install of 7 and clean Outlook 2007...he is stll having issues where
he will search and get "nothing found" when there for sure are items
found...so, i wanted this transition to be another way to rule out it
being server side/ exchange...

jared

On Sun, 20 Dec 2009 16:32:38 -0500, "Bill Sanderson"
<bill_sanderson@newsgroup> wrote:

>There's no need for any significant downtime anyway. With either the
>Microsoft or the swing migration method, both servers are available to all
>clients until there's nothing left to use the old one for (or the 21 days
>max allowed for the transition)
>
>You do have to move Exchange--and I'd recommend starting early or mid week,
>and moving mailboxes over a weekend--that worked well for me. I had
>expected to need to babysit the process in the office, and that wasn't
>needed at all--I did some of the work in normal working hours in the office,
>and then some things that took longer--moving Exchange, over that weekend,
>working from home.
>
>Read the docs--buy your hardware--do a test install of a trial version of
>SBS 2008 to be sure you've got the right drivers for the system to be rock
>solid stable before you start the real thing--read both the migration
>document and the checklist, have multiple copies on hand various places so
>you can always refer to them--and do a good job of cleaning the old machine
>up. I didn't bother with cleaning up mailboxes or reducing their size--but
>I had a gigabit network to move them over. But I did run the BPA analyzers
>and others on the old server and did some cleanup before starting out.
>
>
>
>"Jaredean" <shop@newsgroup> wrote in message
>news:iq5qi590ei2chr4qk80fkt2mi9jdjmspen@newsgroup

>> I would like to setup a new server (SBS 2008) and bring clients over
>> to it 2 at a time while the others are working on the old setup (SBS
>> 2003) -- if i had them on separate networks (so the two didn't see
>> each other) and they each had their own static IP for internet, what
>> would the drawbacks be? That way i could bring our network up to the
>> new server over a week instead of having downtime?
>>
>> The reason i want to do it slower is to convert each client computer
>> to windows 7 (or back to XP for some) with clean installs since we
>> had a nasty virus issue a bit ago and i don't believe it is completely
>> eradicated.
>>
>> jared