"PorBar" <compsosinc@newsgroup> wrote in message
On Sep 1, 2:03 pm, "Ace Fekay [MCT]" <ace...@newsgroup>
> "PorBar" <compsos...@newsgroup> wrote in message
>>> I posted this to the wrong group..sorry for any cross-post:
>> I saw your post in the other group. I cross-posted it to this group,
>> I saw this one.
>> And yes, you multi-posted it, as Lanwench said. Cross-posting is when you
>> select multiple groups at the same time when posting it. You posted it
>> two separate postings.
> Ok -thanks for the input. With the new server, since this is just a 15-
> user network, and we did not "use" Exchange (meaning the users have no
> email and they did not send internally either), and some employees
> have left, etc..we plan on recreating the user & computer accounts.
> Had just the default GPO, default login scripts with SBS. Printers
> installed manually etc..very little if any "automation".
> Just curious if the SBS clients would have to "rejoin" the domain the
> new Server (ie run the network connection wizard on each) if the
> domain name is kept the same? Also the SBS clients have static IP
> addresses and we are thinking of letting the new sever be a DHCP & DNS
> Server. Any advice here?
> We do not intend to join the new server to the current domain. Just
> get it ready with its roles (DC, DNS, DHCP) then shutdown the SBS and
> start connecting the clients. We figured the client/user profiles will
> have to be recreated-they were not roaming, etc.
> Thanks again..await your feedback.
If you want to keep the same name, but not the same domain, meaning to start
fresh, then all the workstations will need to be disjoined first prior to
unplugging the current machine, because you can't have the current one up
and running when you install the new one. So it's better off disjoining them
first. Just make sure you know the local admin password prior to the
dis-joining. Once the new domain is up and running, then you can join them
to the new domain.
As far as keeping current GPOs, they will be part of the old domain, so they
will no longer exist in the new domain. However, you can copy them over, but
they must be saved to a file first before unplugging the old DC.
Migrating GPOs Across Domains
You can use a copy operation to transfer settings to a new GPO in the same
domain, another domain in the same forest, or a domain in another ... http://technet.microsoft.com/en-us/l...43(WS.10).aspx
Copy a Group Policy object using GPMC http://technet.microsoft.com/en-us/l...87(WS.10).aspx
Some tips and guidelines:
1. Before disjoining the workstations, copy all user data (My docs, Outlook
PSTs if any, data they may have saved on their desktops, etc, to a thumb
drive, your laptop, or somewhere else.
2. Make sure you don't select a single label name
2. DCPROMO will install DNS for you. Make sure you have a copy of the i386
folder on c: drive to make it easier. Make sure the copy of i386 is of the
same SP level or you will need to re-run the service pack after you install
a non-same level SP source to a greater SP level installation. This goes for
any other services such as WINS, DHCP, etc.
3. Since this is a non-SBS DC that you are creating, it is highly advised,
and recommended, to NOT multihome it nor install RRAS on it. SBS can handle
multihoming perfectly with the wizards. With non-SBS, it introduces
complications that will pull your hair out. Allow your firewall/router to
handle internet access. If there are two NICs on the new server, either
disable one of them, or team them, but do not use both on separate networks.
There are registry changes you can make, along with a handful of other
changes to make it work (I can provide a multipage step by step if you want)
to make a multihomed DC work, but it vastly changes a DC's default behavior.
4. Once dcpromo has changed, change the DNS address from the loopback
(127.0.0.1) to the actual IP of itself.
5. Make sure to not use the ISP's DNS, the router as a DNS address, or any
other external DNS server that has no reference to your internal AD DNS
6. If you need VPN services, install RRAS on a non-DC, or use your robust
firewall (such as a Cisco ASA, Netscreen, etc) to provide these services.
I hope that helps.