Schema update Q.

[d1nnsear]

Single W2k3 Forest with 1 x Child domain.

The root domain has no resources in it.

The child domain has all users and resources. Unity UM will be setup in the child.

My cust would like to build a 'temp' DC in the root domain, move the FSMO roles to this DC, take the DC offline, perform the schema update on the DC, then when they are happy connect the DC back to the network & let replication do it's thing, then move the roles back. (Obviously with numerous DC systate backups).

I think this is the way to go. Any changes made to the schema master in this way will replicate to the child domain ok. My query is with the 'hidded' objects created by the schema update, eg for Unity location objects. I guess these will get created only in the root domain & not the child domain. Is this right & if so ok? They will want Digital Networking in the future.

How would I go about getting the Unity objects created only in the root domain?

Any tips'd be appreciated.

Cheers,

NJ.

[kechambe · Accepted solution]

I don't think this is the way to go about doing things. Customers shouldn't test with the production network like this. Yes AD allows you to move roles around but this isn't what that functionality was intended for.

Microsoft has indicated to us that as of Windows 2000 SP2, schema replication will only occur if other replicating partners (domain controllers) are all online. Several customers have seen the error 'The role owner attribute could not be read' while trying to extend the schema with other DCs offline.

The Unity schema is tried and true. We have never damaged a customer’s schema. What you are proposing here much more risky in my opinion and not something Cisco will endorse or support.

When we extended the schema we create the new object type for Location Objects but we don't actually create an instance of the object. That isn't created until you run setup and then the Location Object will then be created in the same domain that Unity is a member of.

Thanks,

Keith

[d1nnsear]

Thanks for the advice Keith.

The intension isn't to test this, just to update the schema in the safest possible way. This cust has been burnt by schema updates before. It starts getting rather complicated though when thinking of worst case scenarios & restoring the schema if it does one.

I've never had a prob updating schemas either, it's just an option that was thrown down. As you say there may be more risk doing it this way.

Cheers,

NJ.