Sign in with
Sign up | Sign in
Your question

Upgrading AD to W2K3 - Connection object query

Last response: in Windows 2000/NT
Share
Anonymous
March 16, 2005 8:24:51 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Hi Folks,

I'm planning the upgrade of our Windows 2000 AD forest to Windows 2003.

It is a worldwide branch office type deployment with a hub datacentre and
just over 100 domain controllers worldwide. The replication topology is
manual with the KCC disabled and connection objects to/from remote domain
controllers created via script and load balanced across bridgehead domain
controllers in the datacentre.We plan to go with an automatic KCC in Windows
2003 at the end of the upgrade after we raise the forest function level, but
that's another story :) 

The required schema updates, forestpreps and domainpreps have already been
done (well over a year ago in fact) so we are well on the way. As regards
the 1 year hiatus - please don't go there :) 

Regarding the datacentre DCs, I plan to go for rebuilds rather than in-place
upgrades. My tentative plan is to introduce a new Windows 2003 domain
controller into each domain to temporarily hold the FSMO roles, while I
demote the existing domain controllers (one at a time of course!), and
rebuild them as Windows 2003 with the same name.

I'm worried about the Bridgehead Domain Controllers which each have dozens
of manual connection objects referencing them. If I were demote a bridgehead
domain controller and rebuild it with the same name, would the existing
manual connection objects referencing that domain controller name be
invalidated? I assume that rebuilding the domain controller would result in
a GUID change, would this mean that I need to delete and recreate all the
manual connection objects for the DC in question ?

Clarification on the above would be useful.

My second query - Would I encounter any problems in having the root domain
of our forest running at Windows 2003 Server Domain Function level while the
child domains are still in Windows 2000 Native Mode? All my research so far
has indicated that this is OK, still I'd like assurance that others have
been there done it.

Comments appreciated.

Best Wishes,

--
Peter <X-Files Fan>
Please Note: Emailed replies cc'd / bcc'd , containing HTML or attachments
auto-binned as spam
Anonymous
March 16, 2005 8:24:52 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

"Trust No One®" <dana.scully@usa.xnet> wrote in message
news:42386be2$0$32615$db0fefd9@news.zen.co.uk...
> Hi Folks,
>
> I'm planning the upgrade of our Windows 2000 AD forest to Windows 2003.
>
> It is a worldwide branch office type deployment with a hub datacentre and
> just over 100 domain controllers worldwide. The replication topology is
> manual with the KCC disabled and connection objects to/from remote domain
> controllers created via script and load balanced across bridgehead domain
> controllers in the datacentre.We plan to go with an automatic KCC in
Windows
> 2003 at the end of the upgrade after we raise the forest function level,
but
> that's another story :) 

> The required schema updates, forestpreps and domainpreps have already been
> done (well over a year ago in fact) so we are well on the way. As regards
> the 1 year hiatus - please don't go there :) 

Ok, but I was having MORE trouble with the manual
topology -- this size is nowhere near needing that kind
of effort even on Win2000 (in any case I have imagined
or heard explained.)

> Regarding the datacentre DCs, I plan to go for rebuilds rather than
in-place
> upgrades. My tentative plan is to introduce a new Windows 2003 domain
> controller into each domain to temporarily hold the FSMO roles, while I
> demote the existing domain controllers (one at a time of course!), and
> rebuild them as Windows 2003 with the same name.

Or you could upgrade them. (Even with hardware issues
this is quite easy to do.)

> I'm worried about the Bridgehead Domain Controllers which each have dozens
> of manual connection objects referencing them.

More reason to upgrade.

> If I were demote a bridgehead
> domain controller and rebuild it with the same name, would the existing
> manual connection objects referencing that domain controller name be
> invalidated?

Yes, so you really want to upgrade the DCs to
Win2003.


> I assume that rebuilding the domain controller would result in
> a GUID change, would this mean that I need to delete and recreate all the
> manual connection objects for the DC in question ?

Yes.

> Clarification on the above would be useful.
>
> My second query - Would I encounter any problems in having the root domain
> of our forest running at Windows 2003 Server Domain Function level while
the
> child domains are still in Windows 2000 Native Mode? All my research so
far
> has indicated that this is OK, still I'd like assurance that others have
> been there done it.

No, in fact were this an issue there would always be
"problems" since you cannot be expected to upgrade
all domains at the same moment .
Anonymous
March 16, 2005 11:52:03 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Herb Martin wrote:
>
> Ok, but I was having MORE trouble with the manual
> topology -- this size is nowhere near needing that kind
> of effort even on Win2000 (in any case I have imagined
> or heard explained.)
>
Fair comment. At the time we started there were many conflicting sources of
information regarding the size at which you should go to a manual
replication topology under Windows 2000. After discussions with external
consultants experienced in similar type deployments we decided on the manual
topology. Our deployment is hub and spoke with a large number of low
capacity (32K to 64K) circuits, some with very high latency. The problem
with the Win2K KCC is that it selects a single bridgehead within the hub
site against which it creates the connection objects.If this bridgehead goes
down then it selects another DC a the bridgehead and re-creates the
connection objects. There is performance penalty in creating the FRS vjoins
(moreso with slow links) and we were worried about the active bridgehead
being overloaded. I did also have in the back of my mind also the fact the
inbound replication is serial and again a large number of slow links might
overload a single bridgehead. With our manual topology we have load balanced
the connection objects across multiple bridgeheads with staggered schedules.
The benefits are that the load is evenly spread and there is resilience in
that replication can survive the loss of multiple bridgehead servers - it
just happens less frequently. We've been running for over 2 years now with
no major replication issues.

The KCC in Windows 2003 is much improved and supports hub and spoke
deployments with load balancing and schedule staggering - Nice :) 

>> Regarding the datacentre DCs, I plan to go for rebuilds rather than
>> in-place upgrades. My tentative plan is to introduce a new Windows
>> 2003 domain controller into each domain to temporarily hold the FSMO
>> roles, while I demote the existing domain controllers (one at a time
>> of course!), and rebuild them as Windows 2003 with the same name.
>
> Or you could upgrade them. (Even with hardware issues
> this is quite easy to do.)

Alas it is not quite that simple. There are a number of applications
(systems management, backups etc) that we run on our DCs that do not support
an in-place upgrade. Most are 3rd party but they do include the Win2K
support tools which also does not support an in-place upgrade.

More importantly we'd like to use the upgrade as a time to rectify certain
things we got wrong initially - namely partition sizes and the locations of
the AD log files. Finally we'd like a consistent C:\WINDOWS installation
directory across all our servers (both DCs and member) rather than have
C:\WINNT on some servers (in-place upgraded) and C:\WINDOWS on others which
have been rebuilt. This makes support (and scripting) somewhat easier. .

>
>
>> I assume that rebuilding the domain controller would result in
>> a GUID change, would this mean that I need to delete and recreate
>> all the manual connection objects for the DC in question ?
>
> Yes.
>
I was afraid that was going to be the case. I want to stick with the manual
topology temporarily, buying me some time to properly plan migration to an
automated topology.

>>
>> My second query - Would I encounter any problems in having the root
>> domain of our forest running at Windows 2003 Server Domain Function
>> level while the child domains are still in Windows 2000 Native Mode?
>> All my research so far has indicated that this is OK, still I'd like
>> assurance that others have been there done it.
>
> No, in fact were this an issue there would always be
> "problems" since you cannot be expected to upgrade
> all domains at the same moment .

Fine - thanks for confirming this. Sorry about the length of the reply!

--
Peter <X-Files Fan>
Please Note: Emailed replies cc'd / bcc'd , containing HTML or attachments
auto-binned as spam
Related resources
Can't find your answer ? Ask !
Anonymous
March 16, 2005 11:52:04 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

"Trust No One®" <dana.scully@usa.xnet> wrote in message
news:39rkkaF65d3l3U1@individual.net...
>
>
> Herb Martin wrote:
> >
> > Ok, but I was having MORE trouble with the manual
> > topology -- this size is nowhere near needing that kind
> > of effort even on Win2000 (in any case I have imagined
> > or heard explained.)
> >
> Fair comment. At the time we started there were many conflicting sources
of
> information regarding the size at which you should go to a manual
> replication topology under Windows 2000.

Now THAT makes sense. <really>

> After discussions with external
> consultants experienced in similar type deployments we decided on the
manual
> topology. Our deployment is hub and spoke with a large number of low
> capacity (32K to 64K) circuits, some with very high latency. The problem
> with the Win2K KCC is that it selects a single bridgehead within the hub
> site against which it creates the connection objects.If this bridgehead
goes
> down then it selects another DC a the bridgehead and re-creates the
> connection objects.

That feature can be disabled trivially
(which I am sure you know by now.)

> There is performance penalty in creating the FRS vjoins
> (moreso with slow links) and we were worried about the active bridgehead
> being overloaded. I did also have in the back of my mind also the fact the
> inbound replication is serial and again a large number of slow links might
> overload a single bridgehead. With our manual topology we have load
balanced
> the connection objects across multiple bridgeheads with staggered
schedules.

The manual objects are not the oddest part of
this design -- since manual objects will override
the KCC it could have remained enabled and used
for those areas that didn't need "careful attention".


> The benefits are that the load is evenly spread and there is resilience in
> that replication can survive the loss of multiple bridgehead servers - it
> just happens less frequently. We've been running for over 2 years now with
> no major replication issues.

Then it works for you.

> The KCC in Windows 2003 is much improved and supports hub and spoke
> deployments with load balancing and schedule staggering - Nice :) 
>
> >> Regarding the datacentre DCs, I plan to go for rebuilds rather than
> >> in-place upgrades. My tentative plan is to introduce a new Windows
> >> 2003 domain controller into each domain to temporarily hold the FSMO
> >> roles, while I demote the existing domain controllers (one at a time
> >> of course!), and rebuild them as Windows 2003 with the same name.
> >
> > Or you could upgrade them. (Even with hardware issues
> > this is quite easy to do.)
>
> Alas it is not quite that simple. There are a number of applications
> (systems management, backups etc) that we run on our DCs that do not
support
> an in-place upgrade. Most are 3rd party but they do include the Win2K
> support tools which also does not support an in-place upgrade.

The support tools can be upgraded immediately after the
upgrade -- within moments.

> More importantly we'd like to use the upgrade as a time to rectify certain
> things we got wrong initially - namely partition sizes and the locations
of
> the AD log files.

Those can be fixed too during the
upgrade.

In fact the fix for the usual objection ("hardware doesn't
support upgrade") fixes this too: Backup and restore it
to new hardware with different partition sizes etc, then
perform a "Repair Install" to straighten out any hardware
discrepancies (if necessary).

Then do the upgrade to Win2003 etc.

> Finally we'd like a consistent C:\WINDOWS installation
> directory across all our servers (both DCs and member) rather than have
> C:\WINNT on some servers (in-place upgraded) and C:\WINDOWS on others
which
> have been rebuilt. This makes support (and scripting) somewhat easier. .

Probably not a real issue -- I can fix this for
you right now (at least so you won't notice
the discrpancy)....

linkd.exe (Is your friend)

> >> I assume that rebuilding the domain controller would result in
> >> a GUID change, would this mean that I need to delete and recreate
> >> all the manual connection objects for the DC in question ?
> >
> > Yes.
> >
> I was afraid that was going to be the case. I want to stick with the
manual
> topology temporarily, buying me some time to properly plan migration to
an
> automated topology.

Which the upgrade will solve -- I haven't really
heard anything that argues for moving the DCs
around, and everything argues for upgrading them.

> >> My second query - Would I encounter any problems in having the root
> >> domain of our forest running at Windows 2003 Server Domain Function
> >> level while the child domains are still in Windows 2000 Native Mode?
> >> All my research so far has indicated that this is OK, still I'd like
> >> assurance that others have been there done it.
> >
> > No, in fact were this an issue there would always be
> > "problems" since you cannot be expected to upgrade
> > all domains at the same moment .
>
> Fine - thanks for confirming this. Sorry about the length of the reply!

Not an issue. Glad to help.
Anonymous
March 17, 2005 1:05:48 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Peter,

I did exactly this for a multinational and brought them to the same place
you seem to be going with your AD implementation. I would suggest that you
look at the MS Branch Office Deployment guide. The implementation portions
of the guide will not directly apply but a lot of the design considerations
will help -- especially the two chapters on managing replication topology
and handling specificity of bridgehead servers. I generally don't believe
in in-place upgrades of production servers as there is too much uncertainty
involved and I would rather augment services than to have anything in a
"downed" state as even careful planning can be shown to be flawed.

As to having the root management domain at the 2003 functional level, this
works well and there are a number of benefits to hosting the forest-wise
FSMO roles on 2003 servers once you have extended the schema.

Also, if you don't already have a monitoring system in place, take a look at
the Branch Office Manager until you get something more robust in place. It
will help you watch replication and server state changes during the
migration.
--
Ryan Hanisco
MCSE, MCDBA
FlagShip Integration Services
Chicago, IL

"Trust No One®" <dana.scully@usa.xnet> wrote in message
news:42386be2$0$32615$db0fefd9@news.zen.co.uk...
> Hi Folks,
>
> I'm planning the upgrade of our Windows 2000 AD forest to Windows 2003.
>
> It is a worldwide branch office type deployment with a hub datacentre and
> just over 100 domain controllers worldwide. The replication topology is
> manual with the KCC disabled and connection objects to/from remote domain
> controllers created via script and load balanced across bridgehead domain
> controllers in the datacentre.We plan to go with an automatic KCC in
> Windows
> 2003 at the end of the upgrade after we raise the forest function level,
> but
> that's another story :) 
>
> The required schema updates, forestpreps and domainpreps have already been
> done (well over a year ago in fact) so we are well on the way. As regards
> the 1 year hiatus - please don't go there :) 
>
> Regarding the datacentre DCs, I plan to go for rebuilds rather than
> in-place
> upgrades. My tentative plan is to introduce a new Windows 2003 domain
> controller into each domain to temporarily hold the FSMO roles, while I
> demote the existing domain controllers (one at a time of course!), and
> rebuild them as Windows 2003 with the same name.
>
> I'm worried about the Bridgehead Domain Controllers which each have dozens
> of manual connection objects referencing them. If I were demote a
> bridgehead
> domain controller and rebuild it with the same name, would the existing
> manual connection objects referencing that domain controller name be
> invalidated? I assume that rebuilding the domain controller would result
> in
> a GUID change, would this mean that I need to delete and recreate all the
> manual connection objects for the DC in question ?
>
> Clarification on the above would be useful.
>
> My second query - Would I encounter any problems in having the root domain
> of our forest running at Windows 2003 Server Domain Function level while
> the
> child domains are still in Windows 2000 Native Mode? All my research so
> far
> has indicated that this is OK, still I'd like assurance that others have
> been there done it.
>
> Comments appreciated.
>
> Best Wishes,
>
> --
> Peter <X-Files Fan>
> Please Note: Emailed replies cc'd / bcc'd , containing HTML or attachments
> auto-binned as spam
>
>
Anonymous
March 17, 2005 1:37:43 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Herb Martin wrote:
>
> > After discussions with external
> > consultants experienced in similar type deployments we decided on
the
> manual
> > topology. Our deployment is hub and spoke with a large number of
low
> > capacity (32K to 64K) circuits, some with very high latency. The
problem
> > with the Win2K KCC is that it selects a single bridgehead within
the hub
> > site against which it creates the connection objects.If this
bridgehead
> goes
> > down then it selects another DC a the bridgehead and re-creates the
> > connection objects.
>
> That feature can be disabled trivially
> (which I am sure you know by now.)
>
Herb,

I'm not sure I fully understand what you mean by "that feature that can
be disabled trivially". Could you clarify?

Thanks.
--
Peter
Anonymous
March 17, 2005 9:38:40 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

"Trust No One" <dana.scully@usa.net> wrote in message
news:1111041463.242230.12650@l41g2000cwc.googlegroups.com...
> Herb Martin wrote:
> >
> > > After discussions with external
> > > consultants experienced in similar type deployments we decided on
> the
> > manual
> > > topology. Our deployment is hub and spoke with a large number of
> low
> > > capacity (32K to 64K) circuits, some with very high latency. The
> problem
> > > with the Win2K KCC is that it selects a single bridgehead within
> the hub
> > > site against which it creates the connection objects.If this
> bridgehead
> > goes
> > > down then it selects another DC a the bridgehead and re-creates the
> > > connection objects.
> >
> > That feature can be disabled trivially
> > (which I am sure you know by now.)
> >
> Herb,
>
> I'm not sure I fully understand what you mean by "that feature that can
> be disabled trivially". Could you clarify?

One can disable automatic Bridge Head server selection
by providing your own (limited) set. If only one is provided,
there is NO auto bridge head selection, with 2 it stops after
the second bridge head server.
!