Archived from groups: microsoft.public.win2000.active_directory (
More info?)
> so, we can use the new dc's in the new forest for dns resolution for the
> existing forest? can our existing clients not yet migrated use the new
> dc's dns then?
Yes. If you have physical access to a DNS server, and that DNS server is
not locked down, then yes you can query it.
> can the new forests dns zones be ad integrated and still have a zone for
> the existing forest?
That's how you've got to do it. You need to have AD-Integrated for your new
forest, and hold a secondary copy of the old forest/ domain on there too.
There's one other consideration here, and DHCP can't (as far as I'm aware)
cater for it - DNS suffix search list. If your clients are going to be
resolving names in both forests you are going to be querying multiple
different namespaces. In order to do this you need to configure the DNS
Suffix Search list on the TCP/IP settings of each NIC. DHCP can't do this;
it can only do the primary DNS suffix. In order to do this you have two
choices: manually, or via a script.
The script is the only option. This is simply a multi-valued registry
string. So you can do it via a startup script, Kix logon script, or a
script that you run manually and goes off and does the job. Without the DNS
suffix search list, you won't be able to resolve (no fully qualified) names
that aren't part of your namespace.
--
Paul Williams
http://www.msresource.net/
http://forums.msresource.net/
"Andrew" <newbiepds@hotmailDOTcom> wrote in message
news:OgCecVqCFHA.3936@TK2MSFTNGP09.phx.gbl...
Thanks for the info mate,
so, we can use the new dc's in the new forest for dns resolution for the
existing forest? can our existing clients not yet migrated use the new dc's
dns then? can the new forests dns zones be ad integrated and still have a
zone for the existing forest?
cheers
"Philip Nunn" <bigphil@newsgroups.nospam> wrote in message
news:emiBdDlCFHA.3688@TK2MSFTNGP14.phx.gbl...
> if you get your dns infrastructure for the new domain in place with
> secondary zones for your old domains then you should be able to change
your
> clients to point to the new servers. i wouldnt do this unless you have
the
> dns system setup and working to allow this.
>
> Philip Nunn
>
> "Andrew" <newbiepds@hotmailDOTcom> wrote in message
> news:OYDztIdCFHA.520@TK2MSFTNGP09.phx.gbl...
> > Thanks Ryan (again)
> >
> > What of dhcp though, as we will be using the same subnet etc, and only
one
> > dhcp server can be used, how can the migrated accounts be directed
towards
> > the correct wins,dns etc....again, if i am not very clear pls ask.
> >
> > thanks for your help, andrew
> >
> > "Ryan Hanisco" <rhanisco@flagshipis.com> wrote in message
> > news:uFx2exaCFHA.1260@TK2MSFTNGP12.phx.gbl...
> >> Andrew,
> >>
> >> I usually do this by migrating the user accounts and workstations
first.
> >> Leaving the old SID in the SIDHistory attribute allows you to migrate
the
> >> actual resources one by one as long as the trust is in place with SID
> >> filtering disabled.
> >>
> >> You can choose to migrate the users and computers one OU at a time
which
> >> will further let you test and control who and what are migrated against
> > your
> >> overall project timeline.
> >>
> >> Remember that a Migration between forests can be very manageable, but
you
> >> have to PLAN very carefully and take your time. Always use the test
> >> migrations and remediate problems before doing anything permanent.
> > Nothing
> >> is more devastating than a global migration gone wrong -- believe me I
> > know.
> >>
> >> Of the services, DNS is the most important. The trick here is to
Migrate
> >> the workstations' DNS to the target domain before doing the migration
and
> >> have the New DNS forward to the OLD domain. This way the workstations
> >> are
> >> always aware of both domains.
> >>
> >> Make sense?
> >>
> >> --
> >> Ryan Hanisco
> >> MCSE, MCDBA
> >> Flagship Integration Services
> >>
> >> "Andrew" <newbiepds@hotmailDOTcom> wrote in message
> >> news:%23FyCACUCFHA.3592@TK2MSFTNGP09.phx.gbl...
> >> > Ryan,
> >> >
> >> > How do you deal with migrating gradualy when on the same lan as the
> >> > existing
> >> > forest. Regarding dns, wins and dhcp, how can you diferentiate
> >> > settings
> >> > between the old and new forests to your clients. If I'm not being
> >> > veryu
> >> > clear pls say (it;s been a long day!)
> >> >
> >> > Thanks, Andrew
> >> >
> >> > "Ryan Hanisco" <rhanisco@flagshipis.com> wrote in message
> >> > news:e9nLjNOCFHA.1524@TK2MSFTNGP09.phx.gbl...
> >> >> Arc,
> >> >>
> >> >> You can check to see if the SIDHistory attribute was correctly
applied
> >> > using
> >> >> the ADSI Utility in the Support Tools. (If you didn't install the
> >> >> Support
> >> >> Tools on your DCs, you can get it off the Server 2000/2003 CD -- you
> >> > should
> >> >> make this standard in a DC build.)
> >> >>
> >> >> Run ADSIEdit and navigate to the User object of a migrated user.
> > Scroll
> >> >> through the Attributes to see the value of SIDHistory.
> >> >>
> >> >> If these didn't migrate you may have one of two problems. Either
your
> >> >> target domain wasn't in Native Mode (either 2000 or 2003 Native
mode)
> > or
> >> >> your trust wasn't set up correctly to turn off SID Filtering. You
can
> >> >> verify this using the NETDOM tool.
> >> >>
> >> >>
> >> >
> >
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/Resources/Documentation/windowsserv/2003/all/techref/en-us/NetDom.asp
> >> >>
> >> >> Make sure you are using the newest version of the NETDOM utility --
> >> >> either
> >> >> off of the 2003 CD or downloaded from the MS site.
> >> >>
> >> >> It is very important to do the Test Migrations in ADMTv2 and to read
> > the
> >> > Log
> >> >> files. Go back and verify these things -- depending on the size of
> > your
> >> >> environment, you may have to do the migration again or scramble to
> > reset
> >> >> permissions across the trust.
> >> >>
> >> >> One last note... many people recommend that once the migration is
> >> >> complete
> >> >> that you use the WScript tools to remove the SIDHistory attribute as
> > this
> >> > is
> >> >> a potential security hole. Make sure your workstation security
> >> > translation
> >> >> was successful or you'll end up in a situation where the local
> >> >> workstation
> >> >> profiles all dissociate. Then you'll have a bad week... a very bad
> > week.
> >> >> --
> >> >> Ryan Hanisco
> >> >> MCSE, MCDBA
> >> >> Flagship Integration Services
> >> >>
> >> >> "Arc J. Thames" <revarcjt@hotmail.com> wrote in message
> >> >> news:OTjZ34JCFHA.2380@tk2msftngp13.phx.gbl...
> >> >> >I am getting ready to migrate our users over to a new domain in a
> >> > seperate
> >> >> > forest. I have the trust relationships set up and working. My
> > problem
> >> > is
> >> >> > coming when I try to access resources in the old domain with my
new
> >> >> > user
> >> >> > account. I copied over the SID's using the sid history feature of
> > the
> >> >> > domain migration tool, but when I try to access old resources with
> > the
> >> >> > migrated account...it says "access denied". Is there some
> >> >> > additional
> >> >> > option
> >> >> > I need to check to ensure access is allowed for these migrated
> >> >> > users?
> >> >> >
> >> >> > Thanks!
> >> >> > Arc
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
Facebook
Twitter
Instagram