Re: Questions - installing SBS 2000 in an existing small network with W2K and E2K by Jeff
Jeff
Fri Jul 11 07:27:54 CDT 2003
Comments inline...
"Venger" <venger@augustmail.com> wrote in message
news:V_qdnWGb_flXnJOiRTvUqg@august.net...
>
> 1) It appears your recommendation is to load Windows 2000 as a DC in the
> existing domain, sieze operations roles (all of them), and then run an SBS
> installation over this to keep the existing AD structure intact - is this
> correct?
>
Yes this is correct. If you use W2K, you an add a DC. If you seize all
roles, your new server owns the domain. If you disconnect that DC and now
delete all references to other DCs in the AD, then effectively those servers
are permanently out of the picture. If you reintroduce a server with a name
previously listed in AD, but now removed, AD doesn't care, you can have that
same server name in use again which solves a way to retain all Netbios, URL,
UNC path references being held....everywhere....in batch files, links,
favorites, MRU...whatever. In fact, if the previous AD included Group
Policies with things like Redirected Folder, scripts and such that included
"hard paths" to the Netbios names, once you reintroduce a server with the
same name and establish the same paths, your workstations, users, policies,
and embedded path references don't know or care that it's a totally
different computer...and yet a DC as well. :)
> 2) The migration of the Exchange seems to be envisioned as dismounting the
> stores and then mounting them on the new server after the Exchange load in
> SBS. Some potential caveats - will this work properly moving from
Enterprise
> to effectively Standard exchange? The information about Exchange is nested
> in AD - would the upgrade to SBS and Exchange installation overwrite this
to
> properly reflect SBS/Standard Exchange? I would think so, though I think
it
> prudent to ask.
That leads to the Exchange part of the process. If you retain the
Site|Org|Server reference in the naming of the new server, you should be
able to directly mount the old stores...untouched. The stores will need to
conform to requirements for standard version, so I suppose there could be an
issue because you are stepping down from Enterprise, but I've no experience
on that point...you will have to google that somewhere I suppose. I have
however done the move of Exchange stores to other scratch build hosts that
maintained the name space. The only trick involved can be if the Exchange
originated as a pre-Exch2K version, in which case you have to install
Exchange manually (the way Exchange guru's do, rather than using the SBS
Setup wizard to automate the Exchange install itself. You can use the SBS
media for the install, just need to do it by going to Disk 3 (?), cd to the
correct folder and run setup, having done the DomainPrep manually. The key
issue is to manually set the Org and Site names to match those of the Store,
rather than the default First Storage Group that Exch2K does on it's own
now.
I believe that I once did an Exchange move without deleting the Exchange AD
reference, just reintroducing the same server name and "adopting" the same
Exchange information. As I recall, it simply behaved as if the Schema was
already extended. The only issue was with the Exchange System Account
reference being stale, so it needed to be deleted and recreated.
>
> 3) The problem of removing and adding back workstations seems to be a
> problem related to too much time elapsing between the dcpromo on the new
box
> and the final move of clients to connect with this box as authoritative
DC.
> Just want to confirm this - retaining existing user profiles is important.
> The fact that profiles are kept on the server is another minor hurdle.
Yes, that's correct. You could disable the expiriation timing on workstation
account refresh, or you could work faster. :) It's no problem to do the
toggle out/in as a rejoin, there's absolutely no loss of information or
operation involved.....the profiles are unaffected. In fact, as long as the
original domain SAM/accounts are brought forward, these are the same SID/RID
references that are used to assign the profiles and all security references
anyway....it's the same domain, the profiles at each station are unaffected.
If you domain was previously setup with Roaming Profiles or such things as
Offline Folders, so long as you recreate those share points, it all rolls
again on the next logon because the Group Policies and folder references can
be restablished. There's one caveat however. If you are doing
Intellimirror/Offline Folders that are manually references as opposed to
handled Administratively by Group Policy, these will be failed unless you
refresh them because they are probably stored in the local machine policies
per server or workstation, not in the AD. However, this is just the same
annoyances you have when you recreate a server from scratch and have to
recreate or get savvy and interested enough to literally migrate
printer/folder share settings, and shared resources in RRAS etc.
>
> We don't plan on using ISA (blech) or SQL, so I have no migration worries
> there.
>
> Thanks for your input. Trying to unscrew someone isn't nearly as fun as...
>
> Venger
>
I tend to share the attitude of not charging someone double to build a new
foundation from scratch plus charging them for the demolition of the
condemmed structure, but to an extent I think it's directly implied in the
process that you can't avoid it unless you just like to work for free. It's
reasonable for the IT guy to make a living, and it's reasonable for the
customer to retain their data and operations status. IT's also appropriate
to not overcharge for work because you are lazy, but what you are proposing
to do here is something that most IT people working in this scale business
don't normally offer to do. Technical upgrades that preserve all the
technical conditions transparently by doing an Enterprise class migration
rather than a "insert CD at every workstation, install from scratch,
recreate all user profiles, lose all internal namespace references"....these
are a real shock to the system. The choice between doing manual work at
every workstation or not should be, IMHO, driven by what serves the
customer's best interest and needs, not by what seems to be simpler to
accomplish for the IT guys.
I think we all at one time or another face a condition where we do work for
someone during the week that takes 4 hrs because its during the week and
they are using everything at the same time, whereas it could be done on a
Saturday in an hour if you can take the whole thing done. But if the
customer doesn't want the work to wait until the weekend, and you bill them
for 4 hrs service rather than the 1hr it really should require for Saturday
work, I don't think the customer has been overcharged. I think the Saturday
work can be billed at higher rate as well, and I think the customer has to
understand that "reinstalling a server" and leaving the technical processes
of the domain shattered in the process is one of the conditions of how to do
a job well, as opposed to just whitewashing it with the lost bid price IT
steps. Its the reason that many shops would be happy to bill the senior IT
guy at double the rate of the newbie trainie IT guy....it's not the number
of breaths the guy doing the work takes that measures the value of the work,
it's the value of the work. If you migrate a domain without losing the AD
integrety, nor the Group Policies, URLs, MRUs, Exchange references, and the
customer arrives on the backend of the deal with a clean and well supported
configuration......this is worth more than starting from scratch across the
board if what you are saving is worth saving. I consider it my
responsibility to do that for my customers.....that's the experience and
skill they probably believe they are paying for, right? Give them what they
expect and charge accordingly.
>