Re: Install new hardware for SBS 2003

I agree Cliff and having done a Swing migration myself I can attest to the
simplicity and efficiency of the the process. But hey for charging over $100
an hour it is to his advantage to take as much time and make as much money
as possible. Yes he may be over charging but in the end the client will be
getting a "clean" and efficient install.
I think he prefers this way because the aren't many user accounts and
mailboxes plus it would appear he is not worried about NTFS permissions.

Frankster,
Just one other suggestion seeing how amount of time and work is not an issue
with you. I would remove the computers from AD first and join them to a
workgroup. that way there is no domain information attached to the SIDs. For
copying data over I would not use robocopy. I use this freware program
called GoodSync and it is way faster than robocopy. Plus it has a one way
copy over or a two-way sync copy.

Good luck and perhaps you can send over some of them mega bucks you will be
making on this over my way :)


"Cliff Galiher" <cgaliher@xxxxxxxxx> wrote in message
news:uSMp4iTEKHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
Allen:

His original outline did not mention file permissions either way, nor did
it mention that he was aware that he'd have to rejoin the computers to the
domain. So...as outlined, his plan would not work. You add those
stipulations and I do agree though (which he conceded in a later post.)

I don't think we are disagreeing here, but I did want to make sure that he
(the OP) was aware of the drawbacks to his plan. If he was, for example,
going to copy the data over with a program that keeps ACLs, such as
robocopy, then the new accounts would obviously cause a mismatch...and
that is a legitimate thing to point out and take into consideration...and
his plan was not specific in this regard either way.

So I think it was fair to say that his plan would *not* work as outlined.
That there would be extra steps (rejoining the computers to the domain,
which requires touching each PC) and resetting permissions. Can you
*make* the plan work? Yep. Does it work "out of the box?" Nope. So I
stand by my answer. :)

Anyways, I think we are on the same page now. Just a difference of
interpretation.

-Cliff


"AllenM" <NoReply@xxxxxxxxxxx> wrote in message
news:OMAiXeTEKHA.4376@xxxxxxxxxxxxxxxxxxxxxxx
The plan will work. Pretty much he is starting from scratch and he
doesn't seem to mind the extra work. Nobody claimed the work will take
less time and that more of it or that the Swing migration is not a better
method. He simply asked if it would work and not if it was his best
option. Of course there is also the down time to consider. I would
certainly also export the mailboxes to a pst for backup to exmerge.

"Cliff Galiher" <cgaliher@xxxxxxxxx> wrote in message
news:%23sXYrOTEKHA.1248@xxxxxxxxxxxxxxxxxxxxxxx
No, this will not work. The problem with your plan is that, even if you
create new user accounts and computer accounts with the *exact* same
names in AD, internally Windows does not use "names" to match accounts.
Each account gets a randomly generated SID during creation, so the "new"
accounts won't match and thus all of your computers will have to be
manually rejoined and all permissions on shares will have to be reset.

Personally I'd recommend a "swing" migration. This is a process/kit
that has been developed by an MVP, refined, and has been used by many of
the experts here many times over. It may not be the "official" MS
migration process, but it is darn near bulletproof.

-Cliff


"Frankster" <frank@xxxxxxxxxxxxxx> wrote in message
news:pZednS6BbO-ZX-zXnZ2dnUVZ_vOdnZ2d@xxxxxxxxxxxxxxx
My question is: Does this sound sensible?

I am experienced with Windows Servers and Active Directory Domains, but
not SBS.

I need to replace an aging low performance machine with a new machine
on an SBS2003 installation.

After reading about "migration", (general nightmare, I think) I have
decided to simply build a new box using the same SBS license/software.
Then configure to match the old machine, exactly, then recreate all the
shares, users, install all the printers, the Workspace Web, Exchange
(with all new user accounts to match, of course.) Once I have it tested
using a crossover cable for a client, just do the real cutover and
decommission the old box. It seems that this would be the least risky
instead of the "joining the domain with a 7 day limit" thingy, etc.

Other than simply copying the data over (from the shares, etc) I will
have to get the current Exchange mail over too. For Exchange I plan on
exporting each user to a PST file using that users logon (I'm told
Outlook can do this?) and then simply use the exported PST to import
their existing mail into the new installation of Exchange. Does anyone
know if that'll work? Is another method better?

I realize that this may sound like overkill to some and that some may
recommend "migration". But this sounds like the "safest" way to me, not
disturbing the old box. So a "backout" plan would just be to reconnect
the old box. Downtime (in terms of a day or two) is not a big probem.
More than that would be.

There are only about 10 users and 10 remote connected computers. They
use Workspace Web for remote sessions and Exchange email (Exchange is
directly on the Internet, not POP, IMAP or anything.

Comments please?

Thanks all...

-Frank





.

Relevant Pages

  • RE: Multiple NT 4.0 Domains to 2003 Migration
    ... This is a good plan on the operating system side. ... Active Directory Migration Tool v.2.0 ... Windows Server 2003 Active Directory ... I believe you will get informative and detailed suggestions on Exchange ...
    (microsoft.public.windows.server.migration)
  • Re: Install new hardware for SBS 2003
    ... I think he prefers this way because the aren't many user accounts and mailboxes plus it would appear he is not worried about NTFS permissions. ... His original outline did not mention file permissions either way, nor did it mention that he was aware that he'd have to rejoin the computers to the domain. ... I don't think we are disagreeing here, but I did want to make sure that he was aware of the drawbacks to his plan. ... Other than simply copying the data over I will have to get the current Exchange mail over too. ...
    (microsoft.public.windows.server.sbs)
  • Re: Exchange 5.5
    ... stuff cause the builtin accounts aren't migrated and all seemed ok. ... then you have no upgrade path. ... It's strictly a migration. ... > and want to upgrade Exchange but migrate the Windows accounts, ...
    (microsoft.public.exchange.setup)
  • NT 4 Exchange 5.5 to AD and Exchange 2003
    ... have completed migration of user accounts, sid histories, ... Installation of Exchange 2003 in AD domain on new server ... accounts to this location in a sub org called recipients. ... In the root org is also a sub org called users to which it ...
    (microsoft.public.exchange2000.setup.installation)
  • Re: Integrating a newly acquired subsidiary of a big corporation.
    ... I wouldn't use CSVDE because of delimiter problems, but LDIFDE is ... accounts, so groups should be migrated after the accounts. ... because of GUID ties to the source exchange ... I found when I used the exchange migration wizard on the source ...
    (microsoft.public.windows.server.active_directory)
Loading