<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.technet.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Schema - What is the Best Practise for Updating ?</title><link>http://blogs.technet.com/janelewis/archive/2009/05/12/schema-what-is-the-best-practise-for-updating.aspx</link><description>This has been a question that has come up with several of my customers recently. Therefore I thought this would be a good topic to discuss. Modifying the Schema is something that is a necessary action prior to carrying out installation of Directory Enabled</description><dc:language>en-GB</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Schema - What is the Best Practise for Updating ?</title><link>http://blogs.technet.com/janelewis/archive/2009/05/12/schema-what-is-the-best-practise-for-updating.aspx#3239969</link><pubDate>Wed, 13 May 2009 00:28:04 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:3239969</guid><dc:creator>RiMot</dc:creator><description>&lt;p&gt;I totally agree that it is best practice do a schema extension offline. However you should keep in mind that more and more applications do not allow this.&lt;/p&gt;
&lt;p&gt;Two examples: 1) Exchange comes with an integrated setup which does a domain and forest prep which cannot be executed when your schema master is offline.&lt;/p&gt;
&lt;p&gt;2) LCS 2005 schema update needed the PDC to be reachable.&lt;/p&gt;
&lt;p&gt;What you can do in such cases is to bring one DC offline during the update which keeps the former schema and to disable outbound replication on the schema master.&lt;/p&gt;
&lt;p&gt;In cases where you can do an offline schema update you should also consider to separate more than one DC from the network so that you can quality assure that the new schema can be replicated to partners.&lt;/p&gt;</description></item><item><title>re: Schema - What is the Best Practise for Updating ?</title><link>http://blogs.technet.com/janelewis/archive/2009/05/12/schema-what-is-the-best-practise-for-updating.aspx#3262669</link><pubDate>Fri, 10 Jul 2009 12:19:26 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:3262669</guid><dc:creator>tonyszko</dc:creator><description>&lt;p&gt;As this is great post I would add just one comment to #7:&lt;/p&gt;
&lt;p&gt;(...) Isolate the new DC (remove network cable) and to ensure it is not replicating due to accidential re-insertion of the cable&lt;/p&gt;
&lt;p&gt; Repadmin /options &amp;lt;dcname&amp;gt; &amp;lt;+/-&amp;gt; &amp;lt;DISABLE_INBOUND_REPL/DISABLE_OUTBOUND_REPL (...)&lt;/p&gt;
&lt;p&gt;If this DC will be isolated you have to make sure that it will replicate with its partner before schema will be extended as otherwise it will refuse this operation. Because of that sometimes two DCs are being isolated in separated network, which gives you additional opportunity to check replication between those two before going with it forest wide.&lt;/p&gt;
&lt;p&gt;Second command is about repadmin usage: remeber that this will not prevent replication if admin will request it, for example with /force option. So make sure that all people with such privileges knows that they should not do this at this time.&lt;/p&gt;
&lt;p&gt;As this is valid approach it is more common that schema changes are being incorporated on-line after testing in lab environment and doing AD health check before operation. But it depends ... &lt;/p&gt;</description></item></channel></rss>