Collected from internet
Take a copy of your production environment (e.g. a virtual machine that is promoted as a RWDC) and get that to your test environment. Cleanup the metadata of the virtual DC “http://technet.microsoft.com/en-us/library/cc736378(WS.10).aspx” in the production environment. Then power the virtual DC on in the test environment and make it healthy by:
- Seizing ALL the FSMO roles to it using NTDSUTIL
- Making it a GC if it isn’t one
- Cleanup the metadata of all the other DCs (http://technet.microsoft.com/en-us/library/cc736378(WS.10).aspx)
- Promote another RWDC into that test environment
- Before the schema create snapshots so that you can revert back to your starting scenario when needed
- Now do the schema update
- Check event logs
- Check AD replication
In your production environment
- Make sure the DC with the schema master FSMO role (NETDOM QUERY FSMO to find that one) has replicated!!! (Important because of the initial synchronization requirements for FSMO role owners) You could just go into Sites and Services and force inbound replication
- Disable AD replication (inbound and outbound) on the DC that has the schema master FSMO role (NETDOM QUERY FSMO to find that one) – (repadmin /options +DISABLE_INBOUND_REPL & repadmin /options +DISABLE_OUTBOUND_REPL)
- Disable AD replication (inbound and outbound) on a NEARBY DC (very important)
- Update the AD schema by specifying the DC with the schema FSMO as the target DC
- Check the event logs on the schema FSMO
- Force AD replication between the schema FSMO DC and the nearby DC using REPADMIN /replicate /force
- Check the event logs on the nearby DC
- If all is good, enable replication on the schema FSMO and the nearby DC
Just before the schema update do a system state backup of the DCs involved. That way you have the most update backup you can get. If something goes wrong, you need to do a non-authoritative restore. Because it just involves the schema, make sure to TRANSFER all the FSMO roles of the schema master DC (if any) to another DC. That saves you the headache from ALSO restoring the other FSMO roles (do this prior to the backup, so that it contains the new FSMO role configuration)
Take a copy of your production environment (e.g. a virtual machine that is promoted as a RWDC) and get that to your test environment. Cleanup the metadata of the virtual DC “http://technet.microsoft.com/en-us/library/cc736378(WS.10).aspx” in the production environment. Then power the virtual DC on in the test environment and make it healthy by:
- Seizing ALL the FSMO roles to it using NTDSUTIL
- Making it a GC if it isn’t one
- Cleanup the metadata of all the other DCs (http://technet.microsoft.com/en-us/library/cc736378(WS.10).aspx)
- Promote another RWDC into that test environment
- Before the schema create snapshots so that you can revert back to your starting scenario when needed
- Now do the schema update
- Check event logs
- Check AD replication
In your production environment
- Make sure the DC with the schema master FSMO role (NETDOM QUERY FSMO to find that one) has replicated!!! (Important because of the initial synchronization requirements for FSMO role owners) You could just go into Sites and Services and force inbound replication
- Disable AD replication (inbound and outbound) on the DC that has the schema master FSMO role (NETDOM QUERY FSMO to find that one) – (repadmin /options
- Disable AD replication (inbound and outbound) on a NEARBY DC (very important)
- Update the AD schema by specifying the DC with the schema FSMO as the target DC
- Check the event logs on the schema FSMO
- Force AD replication between the schema FSMO DC and the nearby DC using REPADMIN /replicate
- Check the event logs on the nearby DC
- If all is good, enable replication on the schema FSMO and the nearby DC
Just before the schema update do a system state backup of the DCs involved. That way you have the most update backup you can get. If something goes wrong, you need to do a non-authoritative restore. Because it just involves the schema, make sure to TRANSFER all the FSMO roles of the schema master DC (if any) to another DC. That saves you the headache from ALSO restoring the other FSMO roles (do this prior to the backup, so that it contains the new FSMO role configuration)
No comments:
Post a Comment