Is DCPromo to demote a lengthy process?

  • Thread starter Thread starter needin4mation
  • Start date Start date
N

needin4mation

Is that something that can be done during business hours or would it
knock out everything to complete its run? I only have experience with
installation. That was lengthy. It is a DC being demoted to a member
server. It is not the last server in the forest. Thanks.
 
It is generally very quick. That doesn't mean it won't impact you though. It
could impact any machines that are currently using it, especially Exchange or
Outlook. A generally good practice is to move a DC into a site that isn't used
by any other servers or clients and then after a few days shut it down. If there
are no issues, fire it back up and demote it.

joe
 
Is that something that can be done during business hours or would it
knock out everything to complete its run? I only have experience with
installation. That was lengthy. It is a DC being demoted to a member
server. It is not the last server in the forest. Thanks.
Click to expand...

That's pretty much not an issue. There is very little (but some)
communication for DEMOTION.

DCPromo itself is not very intensive, but the required replication
for a NEW DC (a promotion) is as large as the database.

Even then, if you have to ask you are unlikely to have a database
that is excessively large.

What would a few hundred megabytes of file transfer do to your
network? Probably nothing, and so a small AD will have little
effect in the same manner.

A rather large company can be stored in the default AD which
is less than 100 megabytes of total FILES (transfer is somewhat
less usually.)
 
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5 off-shift....
 
Hank Arnold said:
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5 off-shift....
Click to expand...

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.
 
What about switching to native mode? DIfferent question, I know, but
didn't think it was worthy of a new thread. How long would that take
speaking about Windows Native mode, switching to native. Not Exchange,
though I have to do that too.
 
another way could be to move the DC to a site with no server/clients, leave
it there for a while (day or two) until clients/servers/apps detect another
DC/GC and then demote.
And if hosts any services you need to repoint servers/clients that use that
service (e.g. DNS, WINS)

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
Hank Arnold said:
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5 off-shift....
Click to expand...

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Click to expand...
 
"Jorge de Almeida Pinto"
another way could be to move the DC to a site with no server/clients,
leave it there for a while (day or two) until clients/servers/apps detect
another DC/GC and then demote.
Click to expand...

Lot of work for zero advantage -- for most people they would
actually be more likely to CAUSE trouble (due to failed DC-DC
authentication so the Demote would need to be forced.)

And even then, you cannot be CERTAIN that some (stupid) client
wouldn't use this DC anyway.

Since the (proper) DCPromo demotion cleans up BOTH changes
that need to replicate AND removes the departing DC from AD
it is a lot of work for no advantage and with likely new problems.
And if hosts any services you need to repoint servers/clients that use
that service (e.g. DNS, WINS)
Click to expand...

THAT is the real problem with most demotions -- failing to deal
with the ancillary services, and client changes to avoid using these.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
Hank Arnold said:
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5
off-shift....
Click to expand...

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--
Regards,
Hank Arnold

Is that something that can be done during business hours or would it
knock out everything to complete its run? I only have experience with
installation. That was lengthy. It is a DC being demoted to a member
server. It is not the last server in the forest. Thanks.
Click to expand...
Click to expand...
Click to expand...
 
concerning the site thing...
you could move the DC into another site that has not clients or servers.
as it has not clients or servers it will not be used for site
authentication. it could be used for domain authentication (when a client
ask for a DC in the domain instead of DC in a certain site, e.g. when
joining a client) that can also be prevented by configuring a GPO that tells
the DC not to register DC locator records (site wide and domain wide)

after moving the DC, clients, servers and exchange (if not hard coded) will
see and say...I need to use a DC in my site and will change accordingly...

isn't that true?

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
"Jorge de Almeida Pinto"
another way could be to move the DC to a site with no server/clients,
leave it there for a while (day or two) until clients/servers/apps detect
another DC/GC and then demote.
Click to expand...

Lot of work for zero advantage -- for most people they would
actually be more likely to CAUSE trouble (due to failed DC-DC
authentication so the Demote would need to be forced.)

And even then, you cannot be CERTAIN that some (stupid) client
wouldn't use this DC anyway.

Since the (proper) DCPromo demotion cleans up BOTH changes
that need to replicate AND removes the departing DC from AD
it is a lot of work for no advantage and with likely new problems.
And if hosts any services you need to repoint servers/clients that use
that service (e.g. DNS, WINS)
Click to expand...

THAT is the real problem with most demotions -- failing to deal
with the ancillary services, and client changes to avoid using these.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5
off-shift....

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


--
Regards,
Hank Arnold

Is that something that can be done during business hours or would it
knock out everything to complete its run? I only have experience with
installation. That was lengthy. It is a DC being demoted to a member
server. It is not the last server in the forest. Thanks.
Click to expand...
Click to expand...
Click to expand...
 
I am bewildered by the response to the first part concerning the sites Herb.

This is exactly how I tell people to do it in larger orgs. Removing the DC from
a site starts the cleanup of DNS while still allowing machines that are talking
to the DC to continue to talk to it until they pick up on the change. I have
seen several cases where demoting a DC within its original site can cause apps
to hang up as they continue to try and talk to that DC because DNS says it is a
DC, the machine is still responding to pings, yet LDAP isn't responding.
Exchange actually comes to mind in this circumstance as well as a couple of
custom/third party apps that only check DNS once every couple of hours for changes.

I realize that these are dev shortcomings but are real issues that admins will face.

I am also confused about the DC-DC authentication part. What do you mean?

joe
 
What about switching to native mode? DIfferent question, I know, but
didn't think it was worthy of a new thread. How long would that take
speaking about Windows Native mode, switching to native. Not Exchange,
though I have to do that too.
Click to expand...

As Jorge implied in his answer, mode changes are no
big deal so they happen fairly fast, and then replicate
at the rate you schedule/frequency on Site Links allow.
 
"Jorge de Almeida Pinto"
concerning the site thing...
you could move the DC into another site that has not clients or servers.
as it has not clients or servers it will not be used for site
authentication. it could be used for domain authentication (when a client
ask for a DC in the domain instead of DC in a certain site, e.g. when
joining a client) that can also be prevented by configuring a GPO that
tells the DC not to register DC locator records (site wide and domain
wide)

after moving the DC, clients, servers and exchange (if not hard coded)
will see and say...I need to use a DC in my site and will change
accordingly...

isn't that true?
Click to expand...

Not exactly nor by guarantee. They will tend to PREFER
a local DC, but are willing to use any DC if necessary
(can't find or preferred DCs are down.)

Also, clients that get moved to a "new site" try to use the
OLD site for one more authentication until the authenticating
DC instructs them that the site has changed. (This part might
not be directly relevant to THIS issue, but it is another
complication that deserved mentioning her.)


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
"Jorge de Almeida Pinto"
another way could be to move the DC to a site with no server/clients,
leave it there for a while (day or two) until clients/servers/apps
detect another DC/GC and then demote.
Click to expand...

Lot of work for zero advantage -- for most people they would
actually be more likely to CAUSE trouble (due to failed DC-DC
authentication so the Demote would need to be forced.)

And even then, you cannot be CERTAIN that some (stupid) client
wouldn't use this DC anyway.

Since the (proper) DCPromo demotion cleans up BOTH changes
that need to replicate AND removes the departing DC from AD
it is a lot of work for no advantage and with likely new problems.
And if hosts any services you need to repoint servers/clients that use
that service (e.g. DNS, WINS)
Click to expand...

THAT is the real problem with most demotions -- failing to deal
with the ancillary services, and client changes to avoid using these.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5
off-shift....

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


--
Regards,
Hank Arnold

Is that something that can be done during business hours or would it
knock out everything to complete its run? I only have experience
with
installation. That was lengthy. It is a DC being demoted to a
member
server. It is not the last server in the forest. Thanks.
Click to expand...
Click to expand...
Click to expand...
 
Joe Richards said:
I am bewildered by the response to the first part concerning the sites
Herb.

This is exactly how I tell people to do it in larger orgs. Removing the DC
from a site starts the cleanup of DNS while still allowing machines that
are talking to the DC to continue to talk to it until they pick up on the
change.
Click to expand...

If it is "just a DC" then the clients are just going to find a
new DC when it disappears, and the DNS should get cleaned
up on the demotion as much as on site removal which just
removes from one site and puts it into another site DNS
subdomain.

Also, one would assume in a large org that you DCPromo
off hours for that particular site.
I have seen several cases where demoting a DC within its original site can
cause apps to hang up as they continue to try and talk to that DC because
DNS says it is a DC, the machine is still responding to pings, yet LDAP
isn't responding. Exchange actually comes to mind in this circumstance as
well as a couple of custom/third party apps that only check DNS once every
couple of hours for changes.

I realize that these are dev shortcomings but are real issues that admins
will face.
Click to expand...

Yes, if you have specific app problems and it helps them to do
it this way then there is nothing actually wrong with it.

I was suggesting it is more work; it is unnecessary for the
vast majority (especially smaller domains/forests); and it
might actually cause as much or more problems (see next...)
I am also confused about the DC-DC authentication part. What do you mean?
Click to expand...

Here I am talking about the issue of moving a DC to
a new site and having trouble with their (existing) DNS
etc -- It is not an automatic problem but many people
will have more trouble do to such moves.

Not likely those people YOU are helping since their DNS
is going to be correct. (They are large AND they have you
helping them so I expect their DNS to be working.)
 
I still do not agree with what you are saying.

Is till believe moving the DC to be demoted to a separate site not used by
clients, servers and exchange will prevent problems when it concerns
directory services

When clients know in what site they are in they will query:
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName (site wide DC locator
records)

When clients do not know in what site they are or the DCs in the client's
site are not available they will query:
_ldap._tcp.dc._msdcs.DnsDomainName (domain wide DC locator records)


Alle DCs by default register site wide DC locator records and domain wide DC
locator records.

So if you create a site that will only be used by DCs that will be demoted
and create and link a GPO that prevents registration of site and domain wide
DC locator records, DCs in that special site will never be found and thus
used by clients or servers. Moving a DC to that site will prevent usage of
that DC by clients/servers.

Exchange on its own discovers AD (not DNS) to build an in-site list of DS
servers and an out-site list based op de site and site link cost structure.

So there are enough ways to prevent that DC (the one that will be demoted)
being used. Client will always use local DCs and after that they will use
DCs that have registered the domain wide DC locator records.

Thus by moving the DC away to another site gives clients, servers and
exchange the time to use other DCs/GCs


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
"Jorge de Almeida Pinto"
concerning the site thing...
you could move the DC into another site that has not clients or servers.
as it has not clients or servers it will not be used for site
authentication. it could be used for domain authentication (when a client
ask for a DC in the domain instead of DC in a certain site, e.g. when
joining a client) that can also be prevented by configuring a GPO that
tells the DC not to register DC locator records (site wide and domain
wide)

after moving the DC, clients, servers and exchange (if not hard coded)
will see and say...I need to use a DC in my site and will change
accordingly...

isn't that true?
Click to expand...

Not exactly nor by guarantee. They will tend to PREFER
a local DC, but are willing to use any DC if necessary
(can't find or preferred DCs are down.)

Also, clients that get moved to a "new site" try to use the
OLD site for one more authentication until the authenticating
DC instructs them that the site has changed. (This part might
not be directly relevant to THIS issue, but it is another
complication that deserved mentioning her.)


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
"Jorge de Almeida Pinto"
another way could be to move the DC to a site with no server/clients,
leave it there for a while (day or two) until clients/servers/apps
detect another DC/GC and then demote.

Lot of work for zero advantage -- for most people they would
actually be more likely to CAUSE trouble (due to failed DC-DC
authentication so the Demote would need to be forced.)

And even then, you cannot be CERTAIN that some (stupid) client
wouldn't use this DC anyway.

Since the (proper) DCPromo demotion cleans up BOTH changes
that need to replicate AND removes the departing DC from AD
it is a lot of work for no advantage and with likely new problems.

And if hosts any services you need to repoint servers/clients that use
that service (e.g. DNS, WINS)

THAT is the real problem with most demotions -- failing to deal
with the ancillary services, and client changes to avoid using these.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5
off-shift....

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


--
Regards,
Hank Arnold

Is that something that can be done during business hours or would it
knock out everything to complete its run? I only have experience
with
installation. That was lengthy. It is a DC being demoted to a
member
server. It is not the last server in the forest. Thanks.
Click to expand...
Click to expand...
Click to expand...
 
Also, one would assume in a large org that you DCPromo
off hours for that particular site.
Click to expand...

Many large orgs don't have off hours for their larger sites, that is the issue
and why they look to moving the DCs out of the site ahead of time to reduce the
number of machines using the DC.
Here I am talking about the issue of moving a DC to
a new site and having trouble with their (existing) DNS
etc -- It is not an automatic problem but many people
will have more trouble do to such moves.
Click to expand...

I am still curious as to what problem this might be.
 
"Jorge de Almeida Pinto"
I still do not agree with what you are saying.
Click to expand...

Ok. We don't have to agree on everything, and we have each
explained our position for those who wish to decide.
Thus by moving the DC away to another site gives clients, servers and
exchange the time to use other DCs/GCs
Click to expand...

Note that were this a serious problem then even rebooting
a DC would be an issue. DCs locking up, being updated, etc.

It really isn't such a big deal since any quality client service
or application should switch over to a working DC even if
it initially tries to contact a removed DC.

Were it a problem, many people would actually make there
domains LESS reliable by adding DCs since this would just
make failures of ONE more likely and reduce overall
reliability.

Any app that is heavily dependent on "yesterdays" DC is
by definition buggy or poorly designed.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Is till believe moving the DC to be demoted to a separate site not used by
clients, servers and exchange will prevent problems when it concerns
directory services

When clients know in what site they are in they will query:
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName (site wide DC locator
records)

When clients do not know in what site they are or the DCs in the client's
site are not available they will query:
_ldap._tcp.dc._msdcs.DnsDomainName (domain wide DC locator records)


Alle DCs by default register site wide DC locator records and domain wide
DC locator records.

So if you create a site that will only be used by DCs that will be demoted
and create and link a GPO that prevents registration of site and domain
wide DC locator records, DCs in that special site will never be found and
thus used by clients or servers. Moving a DC to that site will prevent
usage of that DC by clients/servers.

Exchange on its own discovers AD (not DNS) to build an in-site list of DS
servers and an out-site list based op de site and site link cost
structure.

So there are enough ways to prevent that DC (the one that will be demoted)
being used. Client will always use local DCs and after that they will use
DCs that have registered the domain wide DC locator records.

Thus by moving the DC away to another site gives clients, servers and
exchange the time to use other DCs/GCs


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Herb Martin said:
"Jorge de Almeida Pinto"
concerning the site thing...
you could move the DC into another site that has not clients or servers.
as it has not clients or servers it will not be used for site
authentication. it could be used for domain authentication (when a
client ask for a DC in the domain instead of DC in a certain site, e.g.
when joining a client) that can also be prevented by configuring a GPO
that tells the DC not to register DC locator records (site wide and
domain wide)

after moving the DC, clients, servers and exchange (if not hard coded)
will see and say...I need to use a DC in my site and will change
accordingly...

isn't that true?
Click to expand...

Not exactly nor by guarantee. They will tend to PREFER
a local DC, but are willing to use any DC if necessary
(can't find or preferred DCs are down.)

Also, clients that get moved to a "new site" try to use the
OLD site for one more authentication until the authenticating
DC instructs them that the site has changed. (This part might
not be directly relevant to THIS issue, but it is another
complication that deserved mentioning her.)


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
"Jorge de Almeida Pinto"
message another way could be to move the DC to a site with no server/clients,
leave it there for a while (day or two) until clients/servers/apps
detect another DC/GC and then demote.

Lot of work for zero advantage -- for most people they would
actually be more likely to CAUSE trouble (due to failed DC-DC
authentication so the Demote would need to be forced.)

And even then, you cannot be CERTAIN that some (stupid) client
wouldn't use this DC anyway.

Since the (proper) DCPromo demotion cleans up BOTH changes
that need to replicate AND removes the departing DC from AD
it is a lot of work for no advantage and with likely new problems.

And if hosts any services you need to repoint servers/clients that use
that service (e.g. DNS, WINS)

THAT is the real problem with most demotions -- failing to deal
with the ancillary services, and client changes to avoid using these.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)
# Jorge de Almeida Pinto #
BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no
rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5
off-shift....

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


--
Regards,
Hank Arnold

Is that something that can be done during business hours or would
it
knock out everything to complete its run? I only have experience
with
installation. That was lengthy. It is a DC being demoted to a
member
server. It is not the last server in the forest. Thanks.
Click to expand...
Click to expand...
Click to expand...
 
Here I am talking about the issue of moving a DC to
I am still curious as to what problem this might be.
Click to expand...

Sorry, thought it was obvious. It is quite common for
people to mess up their DNS and registration when moving
a DC to another site -- I thought that was obvious and
failed to specify it.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
Herb Martin said:
Hank Arnold said:
I would:

1) stop the NETLOGON process
2) wait a day or two
3) shut the server down
4) wait a day or two
5) power up the machine and DCPROMO it to a member

Being the anal administrator I am, I would do #1, #3 and #5 off-shift....
Click to expand...

I don't like the way 3-5 are organized as this may lead to
the following:

After fully replicating in 1-2, you now have the machine
come online as a DC in 5 and it MAY start immediately
accepting authentications AND changes (especially passwords)
before you can even begin (or complete) the DCPromo.

Were you to do the DCPromo to an offline machine you would
have left abandoned the DC object in AD and have another
mess to clean up.

Step 0 should be to transfer any roles, GC responsibilities,
and DNS to another machine.

Then just do the DCPromo in step 1. It will replicate and turn
any roles (missed in #0) over to the other DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
I defer to the expert.... ;-)
Click to expand...
 
Ok, that should auto update but there are circumstances where that wouldn't be
true such as static registration.
 
Back
Top