Removing Schema Changes

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

We are planning to implement Cognos in our environment, and it has the
ability to create its own namespace in AD by extending the schema. I have
tested this in a lab and it works ok, but we need to have a disaster recovery
plan in place in the event that something goes wrong.

I've read that it is not possible to restore the schema partition so what I
am trying to do is isolate the upgrade to one server before rolling it out to
the rest of the enterprise. My thinking was to do the following:

1. In one of our forest root domain controllers, transfer the schema master
role to this server.
2. Run the commands repadmin /options +disable_outbound_repl and
+disable_inbound_repl to prevent any changes from being replicated to/from
this server.
3. Once I verify that the change was successful, I will then re-enable
replication and let things flow normally.

Now, if something goes wrong, I believe what I have is a DC, holding the
schema master role, with changes that I don't want replicated. What I want
is a way to back out of this. My thoughts of doing this are as follows:

1. Shut down the offending DC
2. Seize the schema master role
3. Perform a metadata cleanup as per KB 216498
4. Rebuild server from scratch and do a DCPROMO on it again to bring it
online.

Can anyone tell me if this will work, or is there a better way of doing
things?

Thank you for your time,

Brian
 
BrianC said:
Hello,

We are planning to implement Cognos in our environment, and it has the
ability to create its own namespace in AD by extending the schema. I have
tested this in a lab and it works ok, but we need to have a disaster recovery
plan in place in the event that something goes wrong.

I've read that it is not possible to restore the schema partition so what I
am trying to do is isolate the upgrade to one server before rolling it out to
the rest of the enterprise. My thinking was to do the following:
Click to expand...

You should be disconnected in a lab environment.
1. In one of our forest root domain controllers, transfer the schema master
role to this server.
2. Run the commands repadmin /options +disable_outbound_repl and
+disable_inbound_repl to prevent any changes from being replicated to/from
this server.
3. Once I verify that the change was successful, I will then re-enable
replication and let things flow normally.
Click to expand...

I would actually just separate the networks.

Now, if something goes wrong, I believe what I have is a DC, holding the
schema master role, with changes that I don't want replicated. What I want
is a way to back out of this. My thoughts of doing this are as follows:

1. Shut down the offending DC
2. Seize the schema master role
3. Perform a metadata cleanup as per KB 216498
Yes.

4. Rebuild server from scratch and do a DCPROMO on it again to bring it
online.
Click to expand...

Not necessary to rebuild the server BUT a DCPromo "cycle"
is needed: DCPromo to non-DC, DCPromo back to DC.

Bringing it online permanent it NOT supported (nor wise)
but bringing it online long enough to do the first DCPromo
and avoid the metadata cleanup seems to be fine and will
allow skipping step 3, the metadata cleanup.
 
Thank you very much for replying Herb. I tried to do a dcpromo in the lab
environment, but since I had replication turned off (because I didn't want
the changes to go out to the other servers), when I ran DCPROMO it failed
saying it couldn't replicate local changes. My fear is if I turn replication
back on it will replicate first, then do a dcpromo. Would another option be
instead of shutting it down, keep repliation off and do a dcpromo
/forceremoval and then do the metadata cleanup? If so, does the shema master
role need to be seized or will a /forceremoval transfer the role?

Thanks again,

Brian
 
BrianC said:
Thank you very much for replying Herb. I tried to do a dcpromo in the lab
environment, but since I had replication turned off (because I didn't want
the changes to go out to the other servers), when I ran DCPROMO it failed
saying it couldn't replicate local changes.
Click to expand...

To install the DC it must of course replicate.

To remove a DC offline you may use the "/forceremoval" switch when you
run DCPromo.
My fear is if I turn replication
back on it will replicate first, then do a dcpromo.
Click to expand...

THis is why I suggest disconnected networks rather than
relying on switches. I even recommend taping over the net
ports if you MERELY unplug it.

This prevent someone (else) from saying, "Gee, why's the
network cable unplugged....?"
Would another option be
instead of shutting it down, keep repliation off and do a dcpromo
/forceremoval and then do the metadata cleanup?
Click to expand...

One thing I wasn't clear on, is that I would NOT have transferred
the Schema role to the test machine ONLINE but would have had
it "seize" that roles while offline -- the real schema master would
still be online.
If so, does the shema master
role need to be seized or will a /forceremoval transfer the role?
Click to expand...

Forceremoval has nothing to do with the role and it
can only transfer if you transfer or seize it online.
 
Back
Top