Upgrading AD to W2K3 - Connection object query

  • Thread starter Thread starter Trust No One®
  • Start date Start date
T

Trust No One®

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,
 
Trust No One® said:
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 :)
Click to expand...
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 :)
Click to expand...

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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

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.
Click to expand...

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 .
 
Herb said:
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.)
Click to expand...
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 :)
Or you could upgrade them. (Even with hardware issues
this is quite easy to do.)
Click to expand...

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. .
Yes.
Click to expand...
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.
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 .
Click to expand...

Fine - thanks for confirming this. Sorry about the length of the reply!
 
Trust No One® said:
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.
Click to expand...

Now THAT makes sense. said:
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.
Click to expand...

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
Click to expand...
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.
Click to expand...

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 :)


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.
Click to expand...

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.
Click to expand...

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. .
Click to expand...

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 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.
Click to expand...

Which the upgrade will solve -- I haven't really
heard anything that argues for moving the DCs
around, and everything argues for upgrading them.
Fine - thanks for confirming this. Sorry about the length of the reply!
Click to expand...

Not an issue. Glad to help.
 
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.
 
Herb said:
the bridgehead

That feature can be disabled trivially
(which I am sure you know by now.)
Click to expand...
Herb,

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

Thanks.
 
Trust No One said:
Herb,

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

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.
 
Back
Top