Scott,
I'm going to address the DNS and DHCP cleanup first, then get back to the
migration question.
As far as I can see you didn't get an answer on this question. I think what
you are saying is that you (as an IT consultant) in the past have been
building a new server (new domain) by doing construction in your own office
LAN, then later installing the server at the production location (your
customer's LAN) but you have stray DNS entries accumulating in the DNS zones
that don't get cleared out?
If I have that correctly summarized, my first suggestion would be that you
should consider building your customer servers in a "construction LAN" by
simply isolating a subnet in your office with a router hung off of your
production LAN. In this way, you not only eliminate the population of
information on the server you are delivering to a customer, you eliminate
potential conflicts in DHCP and other network related traffic. This would
seem the most practical answer and it's good practice as well. You could
configure the router with the WAN interface on your own operating LAN, and
LAN interface as a separate subnet, potentially even setup with a different
subnet as necessary to address your customer's unique LAN. In the past I did
this and established my own operating LAN in a subnet never used by any of
my customers.
As for clean-up, you shouldn't really need to uninstall and reinstall DNS
and DHCP, that's pretty drastic even if it works. You should be able to just
remove the records in DNS yourself, but the Fix My Network wizard is
primarily concerned only with proper configuration of your network
operations, it's not going to remove stale records in your DNS or DHCP
databaseses unless that actually conflict with a production configuration of
your server.
Finally, you mention that you are replacing a server where you don't have
enough disk space to do preparation of the server for the migration. If you
are interested, you can us Swing Migration to do this migration without
modifying or updating the existing server. (This solves the disk space
issue.) In addition, with Swing Migration you can still build the new server
in your own location offsite and complete the majority of the construction
just as you have in the past, in the convenience of your own office, in
advance, and with any additional 3rd party applications and updates done
before you get to the customer location. The main concern once you get on
site will be the migration of the data (just as you have with a clean
install). However, with a Swing Migration you don't have to touch the
workstations, no rework of the profiles, it's significantly more convenient
for you as a consultant. You can move the Exchange Information Store as a
whole into a configuration that can go live immediately, or you can complete
the final mailbox level transfer before making the new server live. All of
this is possible in a Swing Migration via use of a TempDC construction
sequence which fully documented and supported via my website at
www.SBSmigration.com. Please note that this is a purchased solution, but I
would be happy to clarify any questions you have here or privately through
my website or direct email.
- Jeff Middleton SBS-MVP
YCST@newsgroup
"Scott" <Scott@newsgroup> wrote in message
news:6A160B67-6C70-42EB-8C05-625905B0FF19@newsgroup
>I am about to replace an SBS2003 server with an SBS2008 server & all of the
> information that I have read refers to "Migrating" from SBS2003 to
> SBS2008.
> The existing server has very limited disk space on the C drive, meaning
> that
> I cannot apply all of the required updates onto it.
> In the past I have performed clean SBS2008 installations as opposed to a
> migration & both times there have been issues with DNS picking up entries
> from my office network, despite changing the IP address of my network to
> match that of the clients. These issues had to be manually removed as the
> "Connect to the Internet" wizard did not change the incorrect settings
> when
> run on the new network.
> This involved editing DNS entries after reinstalling DNS & DHCP.
> Should I be installing the SBS part of the OS whilst located on the new
> network?
>